Should developer's ideas also be considered in UX discussions?

Question

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?

Answer 1

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:

http://uxdesign.smashingmagazine.com/2011/03/07/lean-ux-getting-out-of-the-deliverables-business/

Answer 2

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.

Answer 3

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.

Answer 4

Some thoughts of mine:

• With Lean UX and other agile methods you have to work together as team. Especially with the agile methodology developers have a very crucial role in the process.
• Developers will eventually build the product, not UX. Most often management will hold them responsible for the deadline, costs, quality etc. So I think it's good they can point out alternatives, risks and costs etc.
• If you want to remove developers' influence on your work you should consider outsourcing your work. Then you get what you specify and exactly that - let's hope you have then covered all the fringe use cases, too. (However, in my experience, the overall resulting quality is most often appalling.)
• Developers usually try to grasp the whole product all at once. It is an intellectual challenge for them, almost like a game, to think through all possible scenarios, error conditions, prerequisites, dependencies etc. etc. This can be intimidating at first, but once you get them to use the 80/20 rule, they will be more constructive. But acknowledge their objections and arguments, store them in a backlog and move on.
• That said, if you want them to be spec coders, they will have fun at finding the holes and fallacies in your design document. And if you've shut them out, they will want everything in writing, too. Then you better attend some secretary course in typing and document organisation.
• If you can, you should conduct user research and prototyping ahead of the major development efforts, but involve developers and other parties as early as possible. This can help the team to create a better foundation before the train is leaving the station... after building up some steam it will be hard to change foundations or take arbitrary turns.
• Be aware that you only specify the tip of the iceberg: underneath is a whole stack of technical issues, backends, libraries etc. They are not important for the user, however, for developers they can make it very hard to change directions.
• Sometimes teams will favor and decide for things they know well, but that might not be the optimal choice. That applies to technology as well as methodology...

Answer 5

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

Answer 6

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.

Answer 7

In a team everyone's ideas should matter. If this is not happening then something is terribly wrong. In my team developers often come with impressive ideas in terms of UX. I think this initiative should be encouraged.