No-BS design collaboration “manifesto”

This has been simmering in my mind for some time now…and finally decided to jot it all down :-) Just a few strong proclamations to provoke vital team collaboration with non-designers/stakeholders and build great products and services, meant for Product Managers, Engineers, QA, and related folks. Warning: not for the faint of heart!! ;-)

Basically, if you want to achieve great design, you better be ready to do the work, break some old habits, and erase false expectations. Designing is NOT like throwing paint on walls with mere “skinning” of the interface! Instead, it takes some serious, tough, negotiated compromises and earnest debates to work together towards the best solution. Here we go…

1. “Need it by tomorrow” is not a schedule, it’s a freak-out. A design solution needs a proper runway of exploration/iteration/feedback to lift-off successfully and get it airborne. Plan for design time accordingly into your schedule! (Do you even have a schedule? If not, make one first!)

2. No documented business or technical requirements? No design for you! Get your stuff together first BEFORE asking for the designer to “make something”. If you need help with that, then best to stage some discovery workshops or strategy discussions with senior design leads, not “hey make a mockup and see if it sticks”.

3. Not everyone can be a driver AND approver AND contributor of a proposed design solution. Apply the DACI model (driver-approver-contributor-informed) to be effective, else you get the “too many cooks” problem. Sucks when making a stew at home, and it’s a nightmare when building a complex product.

3b. Relatedly, while everyone has an opinion about a design, the designer is not obliged to react to all of them. It’s true. Stop crying and leverage the designer’s professional judgment and experience. That’s why you hired that person, right??

4. Product Managers are not art directors. End of discussion.

5. No stakeholders or users/scenarios/markets identified yet? No design for you! See Number 2 above.

6. Want user feedback? Then fold it into the schedule and make sure the dev team is ready to uptake changes as needed. Don’t say you want user feedback and then scoff at changes. That’s called hypocrisy. Not a fan and won’t help your product or customers.

7. Email is not the record. Get a wiki, evernote, sharepoint, google docs, perforce, SVN, whatever. Just something defined as the central place for docs/reqs/specs. Not email! Way too chaotic.

8. A design sketch is never the spec. Neither are wireframes, which are hi-level blueprints. Specs must be reviewed and signed-off BEFORE implementation can begin.

9. Playing the “The [big name exec/director/VP] likes blue” is a crutch. Real defensible rationale please for design pushback/changes.

10. Design takes a full-body commitment. Not ready yet? Call the designer when you are. Or, admit you’re not ready and you’d like help getting ready. Senior designers are often very happy to help get your team on the right track towards product development prosperity, since it benefits everyone involved. Just don’t act like a crybaby when they suggest doing things you’re not used to, like writing down requirements or a design brief.

There’s so much more, but by following these essential points, the likelihood of team design success is much greater!

Add comment

Recent posts

Older Posts

Let’s go meta