Design the Product, Not the Documentation
The need for designers to stay engaged from concept to launch.
For most designers, their first priority is the quality of their work. It’s their pride and joy, their business card, and above all, their meal ticket. But a designer’s work takes two formats:
1. the sequence of endless decisions on which the product is created
2. the tangible artifacts created to illustrate those decisions
Too often the second is the focus. It’s the psds or the wireframes that seem connected to the proprietary set of skills a designer possesses. So when those documents are finished, there is an assumption that their work is over. But in reality it is just beginning.
I want to clarify that I’m not writing to criticize the deep discussions around prototyping options and documentations styles that are occurring in the industry right now. That’s a different discussion about efficiency and productivity that is important. But regardless of approach, they all produce a form of temporary design documentation; they do not produce the product itself.
Documentation will never be seen by the user,
your industry peers or the general public.
The only thing that actually matters is the quality of the final product and the design decisions evident in it. When the text is too large or the wrong transition is used, there’s no opportunity to say, “But look at my PDF. That wasn’t what I designed!” The product is the product. It’s all the consumers will see and, more importantly, all they will spend their money on. The responsibility is on the designer to make sure that all of the considered details manifest themselves in that product.
So why make so many documents? They are intended to facilitate communication. They are meant as a tool for designers to express ideas and work through their thoughts. And when passed to the development team, they should act like the blueprints for what is about to be built. But once they are used, those documents will only become server files hidden behind some long forgotten file path.
The reality is that unless a designer belongs to the rare species that is equal parts designer and developer, he/she doesn’t control the means of production and therefore must work with the larger team to see an idea through to reality. This requires more than just putting lots of thoughts on paper. It requires an open channel of communication, flexibility and the will to shepherd the work through every stage of the development process.
Keep your eyes on the build.
A designer, most fundamentally, is the user’s advocate. So look at what the user will see. The build is the most up to date record of what the product will be like if no further improvements are made. Use it to identify what is or isn’t working. Inevitably issues will be found while intuitively attempting an action that isn’t supported. Likewise, inconsistencies in the design can be identified. Use the build to work out the kinks before it makes it into the user’s hands.
Learn to communicate in an unfamiliar language.
Designers and developers speak differently but a difference in terminology doesn’t mean a difference in meaning. It’s not important to get the lingo right—focus on knowing enough to have a coherent conversation. Use metaphor and ask for extra explanations when something isn’t clear. This will show an interest in learning and a willingness to work together. When both teams understand the technical restraints and the design intent, the best solution will come to light. And where there is one successful collaboration, more will follow over time.
Remember your decisions.
All design decisions aren’t of the same magnitude. Some can be reversed easily with little effect on the experience. Others are deep-rooted and will cause a ripple effect of consequences not apparent at first glance. It’s important to know the difference which means the design rationale cannot be forgotten over time. Create ways to track the assumptions and the reasonings behind design decisions so that when changes are necessary, there is confidence that the new game plan will work.
Acknowledge that your work is not perfect.
As the design is executed questions will always arise around scenarios that were not previously considered. Of course, aim for thoroughness upfront, but realize that you’ll need to adapt and change course in the midst of the implementation. And make sure to welcome suggestions from all avenues because there may be a simple, clear solution that comes from an unexpected source.
The thoughts and opinions expressed here are my own and do not reflect the views or opinions of my employer.
