I was working on a project once, and by the time I was deeply immersed into the research process, synthesizing information and insights, and transferring them into the ideation phase; the project was deprioritized.
β
Deprioritizing a project means deciding to focus less on it because there's not enough team or company capacity to handle everything at once. This decision is usually made by those in charge of planning the company's roadmap. When a project is deprioritized, it's put on hold so that the team can focus on more important tasks, using the resources and time that have been freed up.
A few months later, the same project was picked back up. However... due to the time that had past, the entire team had to re-learn what we had gathered, the insights we found and synthesized, as well as the wireflows we had already started.
Needles to say (otherwise there would be no point in mentioning it...), there was no documentation done for this project.
β
β
Well, you see... people tend to have priorities, and as things become more busy, priorities start to shift, and next thing you know, things just fall off the bandwidth and into the abysm that is deprioritization.
Of course, you shouldn't just park the project and leave it as it is... a minimum amount of wrapping up should happen, though for a lot of teams, this might not happen as you would expect based on what we talked about in this issue.
Oftentimes, this may look like "I will do it next week, when I wrap my head around the new timeline", or "I'll just continue to chip away at the documentation so I can properly park this project", and sometimes even "I'm not going to stop working on it, I can dedicate a few hours a week to it, to keep it rolling".
β
Jokes aside, the lack of documentation can cost a company much more than we think. From time, resources and actual solutions (an idea a team member had, that was not documented, forgotten and never explored...)
But these are not the only important benefits of having a good documentation system. Here are a few more:
Onboarding and knowledge transfer.
Getting proper feedback, create a cohesive handoff, and buy-in from team members and stakeholders.
Usability testing records and iterations.
These could be broken down into more subcategories, and there could be more (if you can think of any, hit the reply button, I want to hear your opinion!), but these are the essentials.
π ββοΈ The Consequences of Neglecting Documentation
As a consequence, you might understand that neglecting our documentation system can lead to a near disaster, if we don't get ahold of the situation.
Believe me, at some point it's going to catch up!
How, though?
Well... let's just assume for a second that you don't keep a documentation system:
Now, every time anybody on your team has a question, they will come and ask you. If they can't physically get ahold of you (perks of remote work, π₯€), they will blow up your Slack, email and any other communication tool they can get their hands on (Figma comments, Clickup messages...).
You'll They'll think...
β
However... every time you interrupt your busy / productive day for a 5 minute task (ask me what I do with 5 minute tasks!), it will take you approximately 25 minutes to get back into what you where doing...
Imagine three of your team members have a question and come to you every day... that's 1.5 hours every day, or 7.5 hours a week lost. That's almost a full time shift at work!
You now, effectively, work one day of the week for absolutely nothing, other than giving people repetitive answers, you could give them all at once.
Now... how to you create an effective documentation system?
Of course... the answer is multifaceted. What isn't, right?
On one side, it's a team effort. If nobody knows where your documentation lives, you might as well not create it at all. Find a common place, where everybody holds their documentation.
Capture every major change that happens in your department. What does that mean? What is major? The answer is simple: if it requires for anybody on the team to have to implement this change, or something that happens because of that change (like a color change in a product might alter the way marketing images might look), you should document it. Otherwise, your team is not going to know that changes happen, or if they do, they can't tell the difference between before and after.
Calculate how long it will take you to create documentation, and include that into the time estimate when working with productivity tools and management systems. Tell your team that your work is not complete, until the documentation is done. They can thank you later.
Use templates. You can pick one up online, there are a ton of tools that already have templates integrated; or create one from scratch. Once you have it down, stick with it. Use it, modify and adapt it, but stick with the base information your team needs to proceed.
BONUS tip: create recordings. In addition to written documentation, with visuals and screenshots, try to document your design decisions with video recordings and narrated screen shares. Narrated is key, otherwise nobody will know what you are pointing out. Ever watched a Youtube tutorial without explanations?
β β₯ The bottom line
Documentation is incredibly important, whether you work in a team or as a solo operation. Don't sleep on it, the future of your work product will likely depend on it at one point in time.
What do you think? Is documentation an important part of your workflow? How and when do you create it? Hit that reply button and let me know π
β
Not sure if design is for you?
Join the waitlist for Discover Product Design and find outwhat the design process is all about, from the moment you find a problem, to the point where you are ready to ship.
Before you go... quick tip! I've been reading Jenna Kutcher lately... her insights on Pinterest marketing are outstanding. I think you should check her out!
Jenna Kutcher
Host of Chart-Topping Goal Digger Podcast
I'm a Minnesota based podcaster, New York Times best selling author, digital marketer, speaker, educator, dreamer, mom of two, and the world's most curious human.