From the introduction: Describing vs. doing
Just drafted, the final passage of the introduction. It riffs on an idea that Nathan and I have been kicking around, that it’s easy for deliverables (and the act of making them) to separate the designer from the “real work”. This seems like a good theme for philosophically setting up the practical chapters that follow the introduction.
Caveat: just a draft, hasn’t been through editing yet.
Describing vs. doing
Do documents and design artifacts reflect “real work”? How much progress are you really making on the project by tweaking line weight on a wireframe or typography on a persona? How much does the design vision depend on your formalizing a deck of screen designs or creating PowerPoint presentations about personas?
Documentation can feel detached from the design process. Diagrams are abstractions of ideas that are in and of themselves abstractions. If we need to describe something that isn’t a direct reflection of a screen design (a site map, for example, or a visualization of the underlying assumptions), the documentation can feel even further detached. At least once on every project I push my chair back from my desk and wonder aloud, “What am I doing?” (Basement offices are the best places to wonder aloud. And listen to unpopular music genres.)
These moments of doubt are useful. They keep us honest relative to our process, and force us to renew our commitment to great design time and again. Stepping back and giving documentation a critical eye, I give myself a chance to validate my efforts and make sure I’m contributing to the design in a meaningful way. I look out for at least three things:
- Is the level of effort on the deliverable on par with the utility derived from the deliverable? Spending hours upon hours on a document that won’t see the light of day beyond a single meeting may not be worth it… Unless that meeting is meant to secure funding for the rest of the project. Spending a morning on a document that will drive and inform the design process for months to come may set the stage appropriately, but likely isn’t commensurate with its value.
- Am I having more fun making the document or working through the design problem? I love making diagrams. I love making diagrams that speak for themselves. I love making diagrams so much that sometimes I forget why I’m making them. The joy should be in solving the real design problem. If I’ve lost sight of that context, perhaps my efforts will be better served elsewhere.
- What I can I be doing that better reflects the final product? If I’m working in a diagramming program because that’s what I always do, I may be neglecting another approach that does a better job of demonstrating the design concept. Paper prototypes or animated PowerPoint slide transitions, while “less sexy” than polished diagrams may describe the design idea better.
Just one more philosophical reflection before you dive into the practical stuff. If I were to boil controversies about design methodology down into a single topic, this would be it. Our urge, as designers, is to get closer to the product, to be a craftsman who can effortlessly float between imagining and building. As products, production processes, and demand change, we create a greater disparity between the people who can think of good ideas and the people who can implement them. The urge to get closer to production encourages us to revisit our design processes, techniques, methods, tools, as well as communication mechanisms.
You’re about to read about seven different artifacts and techniques for assembling them into a story. These artifacts, little projects in and of themselves, are abstracted from the final product. Yet, while the final product may not reference them in the slightest, that product depends on these artifacts for its conception, design, and implementation. They are, therefore, open to interpretation, discussion, improvement, and evolution, to best meet the needs of the product and the team responsible for building it. The recipes herein are starting points and guidelines, ready for you to shape them with your own needs, your own circumstances, and your own experiences.