What do you think when you hear the words design documentation? Yawn. Sounds boring, right? It’s not as sexy as creative design or interactive experience, and that’s often why it ends up as an afterthought.
Many designers and team leaders postpone documenting the design process until it’s over. Time is already limited and they want to focus on design and product development first. They can worry about documentation later.
But this is a dangerous approach. Memories fade and something that was clear just a couple of weeks (or even days) ago may be hazy when you finally get around to writing your documentation… and it might be something crucial. This can have all sorts of consequences, from confusion to implementation mistakes. Documentation, therefore, should be viewed as a vital part of the design process.
I’ll show you why design documentation is so important. I’ll share my process so that you can easily keep track of all of the important information during your own project.
What is design documentation?
It keeps everyone on the same page and if there’s a new team member, it lets them know what’s been done, why it’s been done, how to implement certain elements, what’s next, and more.
Design documentation includes information about target users, product features, essential implementation details, design decisions that you have agreed upon, project deadlines, and anything else that the project requires you to keep track of.
Why you NEED design documentation
What happens if there’s no design documentation? Is it really that bad?
In my experience, you’ll start to notice cracks in your project sooner or later.
You can expect some or all of the following:
- Bits and pieces of information will get lost. Reasons for changes will be tough to recall. Either you’ll have to spend more time searching for answers as to why something was done, or you’ll have to move on without them.
- Insights will be disconnected. There’ll likely be plenty of data but no coherent source of findings that your team could benefit from.
- Team members won’t be on the same page and they’ll continue working in their own way. Marketing, UX, developers, graphic designers, and others won’t be in sync with one another.
- The design process won’t be efficient. Someone will either be constantly backtracking on things or micromanaging everyone.
These cracks can lead to the downfall of your project. Design documentation prevents them from happening. That’s a pretty good reason to have it, but it’s not the only one.
Design documentation benefits
Updated design documentation serves as your teams’ valuable source of truth (together with your design system) for the project. If someone needs answers or guidance, it’s the first place that they should look. It gives your coworkers clear directions, keeps everyone on the same page, and prevents all of the bad stuff that we mentioned above.
But there are also other reasons why you should keep your design documentation in mind.
Writing down various decisions, directions, and insights ensures that the writer must articulate their reasoning. This makes it much easier to detect the flaws in your teams’ logic. It often results in a “wait a minute!” moment when you realize that you might’ve missed something.
Design documentation forces you to clarify project requirements and specifications before you truly begin the project. If you need to gain stakeholder or executive approval, you should prepare proper documentation on how you are going to achieve the project’s goal. Recording everything in one document helps you to organize your thoughts, makes it easier to reach a mutual understanding, and ensures that there is no ambiguity. You can then create a fairly detailed schedule and properly estimate the costs.
Documenting design also streamlines design implementation. There will be multiple people working on a product. The people implementing the design may not be the ones who created it. In some cases, they might have joined the process at a later stage. Having design documentation with some implementation details, or even step-by-step instructions, will make their job much easier and will result in far fewer questions and mistakes.
Documenting design and design changes is also very helpful when it comes to analytics and metrics tracking. For instance, it enables us to connect any spikes in traffic or conversion rate fluctuations with certain changes and actions that we took. It gives us the ability to look back and see how design affected other areas, what worked, and what didn’t.
Last but not least, design documentation can actually motivate your team. Have you ever been in a situation where a team leader has sent you some files and after reading them, you’ve clearly understood why you are designing this and how the team wants to create it. It’s a nice feeling and makes you want to sit down and get to work.
How to properly document design
Although there are tools available that help with properly documenting design, you don’t really need them. As you’ll see later, I usually use Google Drive and Google Docs.
There are two factors that are more important than anything else when it comes to proper design documentation:
- Design documentation should be easy to use and searchable, or people won’t bother using it. Nowadays, documents can be accessed with one click and searched with another. Take advantage of that.
- The documentation process must be consistent and have a clear structure. People who add anything to the documentation must use this structure. By doing so, you’ll ensure that it remains easy to use.
Alongside these, there are some important aspects that you need to take care of:
Think about the target audience
You’ll prepare some documentation for your team members, some for the stakeholders, and maybe even a few for test users or end users. Keep in mind their needs, their interests, and what kind of language they’ll understand, then adapt your documentation accordingly.
Ensure documentation is up-to-date and clearly marked
What is the latest version of a certain document? Make sure that everybody knows how various versions are marked and minimize the risk of confusion and incorrect decisions.
Treat documentation as a living project
Design documentation is not a one-time activity. You won’t be able to create all of the documents before the project, and that’s not the point of it. You have to work on it incrementally. That’s why it’s so important to create a flexible, accessible structure which other team members can update as well.
Provide visuals and code samples
Now we’re moving into design system territory. However, if you can show actual design samples and resources in your documentation and what team members should use, it’ll be a lot easier for them to translate information from the documentation into design decisions and coherent design.
Prioritize based on your documentation
If your documentation is continuously updated and living, use it to your advantage and prioritize tasks based around it. This allows everyone to know and understand what the next step will be and why you’re doing it, so that all involved can speak the same language and feel a sense of shared ownership.
My design documentation process
As you’ll see, my process is a fairly simple one. It might work for you, it might not. As with most other things in design, I suggest that you test it with its ‘users’ – first and foremost, your design team. Get their feedback and see how you can improve it or if you should try something else.
I use Google Drive and Docs.
Why? Because everybody knows how to use Google Drive apps. There’s no onboarding and if you work with different teams, it’s a huge advantage. It’s also searchable and easily accessible.
Here’s my design documentation structure:
- Each department has its own folder – UX, Design, Marketing, Sales, Development.
- There’s one main document containing our goals, timeline, and the most important notes that everybody needs to know.
- Each document has a standardized title and follows a specific template, so that everyone writes and uses documents in the same way. It also makes it much easier when you need to find something.
- Every document has additional tags in the form of usual text. These tags make it easier to find certain information.
- Content like pictures or videos must be embedded in the file.
Consider implementing these metrics:
- Speed to market 💥 Is it faster since we implemented the system?
- Quality assurance time 🔁 How much time do we spend testing things and preparing reports?
- Github issues 🤨 How many are there and how many are getting resolved?
- Bugs 🤨 How many are there?
- Time spent for routine tasks 🔁 Designers need creative time. Repeating the same tasks kills creativity.
- Time lost to bottlenecks 🚧 – Are you aware of your current blockers? Who is responsible?
These metrics should show you whether or not your design documentation is working as intended. If there are a lot of bugs and open tasks, it means that there’s something wrong with the way that the project is being managed.
Documentation depends on the project, but there are some docs that you should always include, or at least consider.
A high-level overview of project goals, timelines, and important things that everyone needs to know. After reading this document, anyone should be able to understand the purpose of the project.
Weekly or bi-weekly plan:
- big picture (based on OKRs),
- to-do list,
- learnings and observations
Business and technical requirements of the design that have been agreed upon with your stakeholders. Constraints and assumptions should be included, as they’ll influence design decisions. <<
Target audience information
As you probably know by now if you follow this blog, user research is key. Your team needs to know relevant information about your audience, from user personas to data obtained via user research. That’s how everyone will know what good design means to your users and what they should base their decisions on.
Information about what your team will implement and deliver during the project (lo-fi wireframes, mock-ups, hi-fi prototypes, etc.).
Outlines possible paths that a user may take to reach their goal when using the product.
Design guidelines and style guides
Describes the components required to build the solution. Lists a set of standards for the stylization of design, including standardized components that are shared across the website, app, product line, or system. These may already be documented as part of an existing design system (in which case there is no need to repeat it). Styles, colors, and typefaces are essential parts of this guide.
Documents the requirements necessary to complete the implementation of the design. For complex projects, it can include a project timeline with information about the time required to complete each of the steps.
Design validation and user testing
Provides an overview of the product testing methods that you’ll use to verify that the product satisfies user needs.
Communicates how the application or website is structured, and typically represents an information (or functional) hierarchy.
That’s it! I hope that this article has shown you why design documentation can’t just be an afterthought and that it really isn’t that complicated. If you take care of it and keep it up-to-date, you’ll see how helpful it can be for both you and your team.
If you enjoyed this article and would like more design strategy, download my value-packed ebook The Ultimate Design Strategy.
Hungry for more?
👋 Oh hey, I’m Romina.
I am a Design Strategist who holds a Master of Business Administration. I have 15+ years of career experience in design work and consulting across both tech startups and several marquee tech unicorns such as Stellar.org, Outfit7, Databox, Xamarin, Chipolo, Singularity.NET, etc. I currently advise, coach and consult with companies on design strategy & management, visual design and user experience. My work has been published on Forbes, Hackernoon, Blockgeeks, Newsbtc, Bizjournals, and featured on Apple iTunes Store.