This is one of a series of essays about how to relate to common stakeholders. Here, I’ll provide some tips for working successfully with designers.
- The relationship between the designer(s) and pm is the determining factor in user experience. Their mutual understanding of the user is the software’s understanding of the user.
- Hopefully, it goes without saying that design encompasses more than how the buttons will look or what font to use. UX is not visual design. But it is metaphors, aesthetics and taste.
- If you have a good designer let the designer own the experience. Just set the stories and the priorities and let them go. If you have a junior, outsource, or less talented designer, still let them go first, but expect to edit and iterate a lot. If you do wireframes to convey the story or experience you want, either do it very low fidelity (whiteboard, etc) or give screenshot examples. If you’re doing high fidelity mock ups or prototypes, you’re a designer. Thats cool, you can be both, or may have to be, but those are design thinking tasks.
- Good, compelling, design is about a single vision or aesthetic shining though in a collaborative medium. Even in software, it’s easier to understand and transmit emotion via a single designer than a committee. If your product has had many brand, design or designer changes over time, consider the potential value of a normalizing effort to unify the look-and-feel.
- Designers are often emotional; creative people need to be passionate, but can also be dramatic. Just accept it. Don’t over-react but don’t treat their feelings as invalid or unreal. They are very real to them.
- Many designers, especially the young and inexperienced (or lazy) will give you one design and say “here’s the design”. Make them show their process. Like checking in source code and breaking down programming work into milestones, designers should be able to share their ideations, helping the team understand not just what they are proposing, but how they are got there and why they are not proposing other ideas.
- In complex software designers are often working on features or interfaces in isolation. It’s vital the PM work with design leadership to keep the holistic user view and big picture (how interfaces interact, patterns/metaphors/components consistency, and building shared intuitions) and most of all, priority. Design is prioritizing things visually and in terms of the interactive space (how much space to give to each potential user action, what gestures will do what, which actions to make easy or hard). The clearer you articulate your user’s priorities and hierarchy of needs to the designer, the clearer that should come through in the interface. Do the designs priorities match you’re users priorities?
- Don’t let design determine the roadmap. Design is about how the user experiences the product. Product should always own what the team focuses on and why.
- Provide an incidental creative outlet (team schwag, internal logos, UI of internal tools). Ask/expect them to own the visual space of the team, in whatever form.
- Know basic design jargon like you should know tech jargon: visual hierarchy, wire frame, high fidelity, evaluative vs generative design research, what the hell is an affordance?