Can Developers also be included in UX discussions?
Sometimes technical issues also hinder the UI layout and personas. How can one get this resolved when it happens?
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.Sign up to join this community
Are they? Often, no.
Should they be? YES!
As should be content folks, product owners, project managers, marketing (as much as we loathe them), IT, customer support, etc.
In other words, the best UX is UX that permeates all teams involved with the project. I strongly believe that UX should be much more of a methodology and philosophy more than it should be just a 'team' within the organization.
As for working more directly with development, read up on Lean UX, which brings Agile concepts to UX. A bit part of that is quick iterations with your developers so that you are producing more code, less paper documents:
Absolutely, though the degree to which developers are involved depends on the scale of the project.
Some of us (like me, currently) do all development, UI design and UX work on projects. This is common for smaller businesses or internal apps, and it's pretty much unavoidable.
In large projects, Developers aren't nearly as integrated into the UX; they're separate teams, maybe even separate departments with separate management.
However, the reason for the importance of developer input is generally the same in all situations; developer input is needed when technical possibility hinders what you want to get done. In large companies, you're a lot less restricted, but you still need to know what the development team can actually do. In a team of one, technical feasibility may be the only thing that matters; you do have to actually finish the product!
More generally, developers are a part of the product team. They should be included, technical limitations aside. They're the ones who are going to be implementing a lot of this stuff, they should have input on the product they're developing, and they should be on board when you're designing so they know not only the what but the why of what you're doing.
You'll find developers can be a lot more open to implementing "too difficult" design decisions when you effectively communicate the need for them. Even if the designer's word is god and the developer has to do what you say, bringing them on board means less mistakes when your design is translated to a working copy. Even very detailed design documents are not a substitute for actually understanding the design decisions you're making.
Its important to get developers' feedback as early as possible in design discussions to avoid redesign later. Different development teams will inevitably have some strengths and some limitations.. for e.g. expertise with a particular UI library. In fact, involving them early can actually help the UX team in leveraging their strengths.
Generally, there will be more than one good solution to design problems and the chosen solution should take into account the context of the product (users and team).
Another tool that can help is personas. It takes the focus away from being a personal battle between two teams to what actually is effective for the relevant persona.
Lastly, it really helps if the UX team themselves have some knowledge of development fundamentals. That makes it easier for them to see the developer's perpective.
Some thoughts of mine:
We've been using a method called Design Studio, which has been introduced by Todd Zaki Warfel. It has been used in various forms in other design processes.
The key part to the process is involving the whole project team in the process of designing, that's UX, designers and development. It uses rapid iterations of the design where each member of the team sketches their idea of the solution, and shares it with the rest of the team, ideas are shared and improved upon. By the end of the session there should be a good solution to start off with.
Key things required for a session is, a persona and scenario/problem to solve for the user on the platform.
This works well, because it allows input and buy in from the team, and also gives different perspectives to solutions from all members. And problems can be solved before any heavy development has been done.
The outcome is paper prototypes/sketches of the screens/flow.
It's best to conduct some initial testing on this before getting to the design and/or development stage.
This process can work well in Agile environments.
Watch a video about Design Studio here: http://www.ustream.tv/recorded/20692513
Whatever the official position the developers have to make it happen. If they cannot see the rationale behind decisions, they may well implement them badly. If they understand what the UX is trying to do, they may suggest changes or modifications that will make the build process easier, the performance better, and the UX no worse.
I am a developer, I should point out. I will do my best to interpret the design documentation in building an application ( or the scribbled ideas as to what it should do, more often ), but if I understand what the UX is trying to deliver and trying to do, I will do this better.