Communicating Design (Revised)

Design process and how designers communicate their design decisions to others is kind of a obsession of mine. I’ve been lucky enough to have been involved in just about every aspect of digital product design and I’ve seen the process from the eyes of a product manager, a designer, a coder, a creative director, etc.

All of this thinking has led me to the following conclusion, which I think still holds true:

Communicating design, in general, needs to be less about documentation and more about clear, concise and ongoing two-way communication.

In other words: spend your time designing, not documenting. I don’t know about you, but contrary to what I sometimes hear from designers, I’m not in the business of making flow charts, personas and wireframes. In the end, these things literally do not matter. Even in the best cases they usually cost valuable time and energy. Worse, can be a source of miscommunication or used as an excuse for when a product’s experience fails. I’ve seen a few great ideas die a premature death due to an inability to gain consensus on documentation. It’s ridiculous.

Very often designers spend way to much time producing ineffective—yet often impressive—deliverables and not enough making sure the decisions within those deliverables are handled appropriately throughout the process.

There is no doubt that an essential part of the design process is communicating (not necessarily documenting) design decisions. But it’s those ideas and decisions—and their impact on the end product—that matter, not the documents themselves.

In most cases:

• if you’re doing high-level design (goals definition, roadmaps, feature definition, content planning, flows, etc.) you should be spending your time doing research, thinking/problem-solving and then, as briefly and clearly as possible, communicating the outcome of that thinking.
• if you’re doing detail-level design (visual design, UI, interaction) you should be working on the details and assets that go into the final product. If you have the ability, you should be producing (or working with an engineer directly to produce) fully functional prototypes or, often better, working on the final product itself. I’m a big fan of the “design in your medium” method.
• if you’re producing mid-level design documents—like wireframes and personas—do them with extreme care. Remember, these are means to an end, treat them as such and you’ll have fewer problems. There are a few cases where they work, for example, coming up with the tone (for copy and visuals) of an app or site.

I realize (trust me) that the above isn’t always doable. Usually it comes down to the makeup of your team. You might have UX folks who aren’t strong with look and feel, or a designer who doesn’t code much. And that can work out just fine, again, if they’re good communicators. I’m not going to touch the specialist vs. generalist argument, except to say that everyone on a product team should strive to have a solid understanding of what their teammates do.

Designers should, at the very least, be able to communicate effectively with engineers and vice versa. And if you’ve got people who’s skills span many parts of the stack, that’s awesome. Even if they don’t actually do all that work. For example I can code, but usually there is someone around who’s better at it than I am. It’s good for me have that ability, and to be able to speak to it, while at the same time letting my co-workers do what they do best.

(A quick side note: I’ve noticed that large teams are very often slower. More resources doesn’t usually equal speedier, or even better, product development. The issue this post is trying to tackle is more process related, but I think many of these issues could be solved by simply making teams smaller and more focused.)

Communication #

A designer’s ability to communicate: listen, answer questions, etc. is probably their number one asset. Keeping a clear and open line of communication between you, your teammates and your stakeholders can make all the difference.

All of this takes trust in those you work with as well as a willingness to let others in. You may feel like you’re giving up control, and it some ways you are, but through that sharing you will often actually have more control over the final outcome. You know, the thing that’s important.

I feel pretty strongly that designers should be willing to share and accept feedback throughout the process. I believe that great design requires a solid, singular vision but acknowledge that allowing more people into the process can be a good thing if it’s done right. It’s not about building consensus, it’s more about sharing and taking advantage of the full talents of your team. You can have a strong vision and still be open to new ideas and feedback. In fact, this is a big part of what makes a good designer great.

I love the idea of boiling the design process down to really quick rounds of design/build where designers and engineers work closely together and iterate often. Make no mistake, this is difficult and requires understanding on all sides as well as a remarkable ability to communicate.

Having said all of this, I think that at the end of the day, a designer should be flexible and able to adjust to whatever process works for the rest of his/her team. Ideally though, I’d prefer to spend most of my time working on my final product and less on the details of my design deliverables. These things can be useful and sometimes necessary, but, in my opinion, the focus should always be on that final product.

And, trust me, while you’re busy documenting your ideas, your competition is out there iterating on a product with real data. The quicker you can get a product out the door, even an imperfect one, the better. I think most would agree on that, so why do designers still waste time with this stuff?

*Note: This is a revision of a post I wrote a couple years back, I’d started writing something new and realized that I was echoing some thoughts I’d previously jotted down