Design doc in an ecosystem of collaboration
About design doc
The doc is a comprehensive guide for all the members to contemplate the fundamentals of the design proposed. It is a single document created in a word-processing tool like Microsoft Word, Dropbox Paper, or Google Docs. I preferred using Google Docs which made collaboration easier, with the help of tools like comments and suggestion mode.
If a project is expected to span for at least a month or more, a design doc should be written.
Side note: It is important to treat this design doc as a living document as you implement the design. Update the doc every time you learn something that leads to you making changes to the original solution or update your scoping.-Angela Zhang
The crux of the doc is to facilitate :
- Bridge the gap between designers and developers, at all the stages of product; and
- Translating design language into generic language for design sustainability.
One can say that design doc serves as a bible for the designers. It contains all the product-specific design guidelines in a single book.
The following components were an integral part:
1. General information
- Project title
- Name of team member; eg: product owner, tech owner
- Version date
- Quick links; Links to previous versions (if any), product doc, tech doc and prototype
Date: 02 April 2018
Product owner: Ashima Mathur
Tech owner: Sumeeti
Links to the following:
• Product doc
• Tech doc
Context contained a brief description of the problem statement which was followed by the impact of the product on the company’s quarterly goals (Objectives and Key Results).
3. Metrics to impact
Once the context was ready, I drew metrics from the product doc which were the target for this project. These metrics were then linked to the design elements, emphasising on how the design contributes to impact these metrics.
4. Current setup
I studied how the users were currently interacting with the product and analysed what needed to change, what had to be retained while optimising the impact and time curve.
5. Proposed setup and detailed scoping
All the plausible user journeys were penned down, and IA was constructed.
Once the architecture was ready, I did detailed scoping of each element. All the details which an engineer would have required while implementing the code were provided. At this step, a meeting between the stakeholders was called to discuss and finalise the flow. The design doc proved to be very handy during the walkthrough as it imparted all the information of design elements at a quick glance.
6. UI copy doc
The copy doc holds all the copy for a single project: a landing page, a series of mobile screens, a set of on-boarding emails, or anything else. The content needed a walkthrough and ideations again. Major key-words, error messages, field titles were some of the copy which needed changes.
Different designers incorporate copy docs at different stages of the design. In my case, once the wireframes and flow were ready I proceeded with the doc. Essential elements of a copy doc are:
- Header and project information
- A copy table and images to support the element
Whatever we do, if it fails to communicate, it is wasted effort. Clarity of intent will translate into the clarity of result, and that is of paramount importance in design.- Eugen Eşanu
Things to keep in mind while finalising the copy would be to
- not use words that people don’t understand
- not use flashy words or jargons
- not get too technical, keep things on a human level
Once the design entered in its advanced stages, I prepared a list of mailers. The list contained over two dozens emails which were to be sent to various parties involved, primarily the partner and their merchant.
After a couple of meetings and two coffee cups later, me and my product manager decided to categorise the emailers and write the content.