Yesterday, Chris sent me the document that everyone had made as a result of the working sessions the other day. And I sent back my usual detail gripes, but also a more generalized one that was (at least partly) my fault. It didn't have any words to speak of.
I mean that in the sense that you can see in this sample (764kb PDF).
This uses all of the exercises outlined in my design process book, seeking problems and goals, analyzing them with design morphology, and coming up with a set of actionable design objectives. The end state of these exercises is then placed right in the first concept documents you hand over to the client, pretty much first thing.
So as you get to explaining design options – when you communicate the value of any idea, that description should automatically refer to the problem, and design objectives you put up front.
You cannot usually just get away with drawing your perfect solution. You have to communicate it, and ground the concept in the reality in which product owners, other designers and technical resources work and live.
I say, a lot, that it's good to step back from prototyping, high fidelity drawing and even drawing as a whole in order to gain perspective and to design and communicate in a common manner to which everyone can contribute. For this early, analytical phase, and their communication, it's worth re-stating again what it gets you:
- The process of creating design objectives provides you a solid understanding of the client, the brand, the product, the project, the brand and the scope.
- Communicating this to the client proves you have absorbed this, and are on the same page as them.
- If there is a mismatch when you first publish the problem statement and design objectives, that's the best time to get it out in the open. Even if only caught when the first design concepts are offered up, it's early enough to fix and reconsider.
- The words can, and should, be referred back to throughout the design process to prove to yourself you are on the right track. It is especially key to consider design objectives as you move from higher level to more detailed documentation.
- I also find it helpful when changes are considered late in the project. Instead of the quickest, easiest design, read those statements about the original needs of the project and consider what solution best meets them.
- Unless you work entirely alone, others in your organization need to be on the same page as you. If they are just looking at design documents, they are still guessing your intent. Even better is having your whole team help you create them, even if they will not all be working on it right away. Bring in the graphics folks and prototypers to help create design objectives up front.
And in the same way it's good to write things down so you understand and remember, it's good for me to write about this occasionally. As I said up top, I pretty much forgot about this. Projects get exciting, and you jump into them. But taking just a few minutes to make sure you are starting the right way is the best way to design, and much more efficient in the end.
Now I guess I have to go back and read my book myself, again.