Documenting design changes

When you work in a product company your design is never done. You keep optimising, iterating and adding new features. Business requirements change, product objectives change, company strategy changes, sometimes things just don’t work out as desired so you need to try something else.

All these things together create a lot of mess. Now add to it several different product streams and a bunch of designers across 2 different countries. How do you keep track of your design decisions?

In this article, I’ll be sharing my solution to this problem + a link to a reusable template.

A bit of a backstory

2 years ago I joined my current company as a second designer. Soon after that my design colleague quit, and I was left alone.
I found myself surrounded by dozens of folders with a legacy from two previous designers. Some of their works were already implemented, some were developed partially, some were quite nice but no one could tell me why they are not on production, or why they were even created in the first place.

When companies scale things get messy. We went from 50 people to 100 in a bit more than a year. We hired 3 more designers and finally started to make more conscious product decisions backed by data. The product was split into 2 streams, then into 4. Communication got challenging.
In startups things change rapidly, something that you’ve been working on 2 weeks ago can become obsolete tomorrow. So no surprise when you’d ask someone why is there a huge new element on a home page or something behaves not as expected you won’t get a satisfying answer.

It was clear, this company needed a new hero.

Documentation isn’t the sexiest part of a designer’s job, yet it is essential when you’re working for a startup with more than 1 product stream. It’s a great way to capture changes and share your learning with the team. Besides, it’s a perfect exercise for you and your PO to think through all the details of your research.

I created a Google doc template that was shared with everyone across all product streams to document research and experiment learnings.
It takes only 10 minutes to fill in yet the value of it is huge.

Wait but why Google doc? Well, mostly because it’s one of the most versatile and accessible tools for everyone in the organisation. Everyone starting from the design team and ending with the marketing department can access it, leave comments and questions about your research methods and learnings.

Step 1. Assumption

Every research starts with an assumption. In the first part of the doc describe your assumptions as detailed as possible.
For instance:
We believe that our current 10 step registration flow is tedious and too complicated for our users, and by reducing the number of steps we might increase our registration metrics.

Step 2. Method

There are many ways to validate one’s assumptions. Field observations, user interviews, AB testing, you name it. This part is for defining what exactly are you going to do.
If you’re setting an AB or multivariate test how are you going to split your audience? (50/50 or 10/90, etc.)
If it’s a user interview tell how many people you’re going to talk to, list the questions you’re going to ask or a script.

For instance:
To prove our assumptions we’ll release this experiment for 50% of our users and another 50% won’t see any difference.

Step 3. How does success look like?

Okay, so now you have your assumption and a method you’ll use to validate it. But how are you going to evaluate your findings? When do you know that your results are statistically significant to make a conclusion? (here is the link to calculate significance for AB tests)

As you might have guessed, this part is exactly for that! Write down several metrics that you will use to assess your results.

Example:
We know we succeeded when we’ll increase the number of successful registrations from 10% to 20% and decrease the bounce rate from 50% to 30%.

Or
We know we succeeded when 12 out of 15 users will complete our task flow during the usability testing.

And off you go to challenge your designs!

Step 4. Results

This part is filled at the end of the research/experiment. Share your learnings, were your assumptions correct? Were they wrong?
Tell it all. If it was an interview — put responses and your observations here, if it was quantitive research leave the actual numbers of metrics you kept your eye on.

Step 5. Action points & next steps

This is the final part of a doc, where you tell what are you going to do depending on the results you’ve gotten. Are you going to change the design? Or are you going to test it again? Put your thoughts and ideas in this section.

Hope the doc with these 5 simple steps will help you to keep track of your decisions inside your company 🙌
Here is the link do the template I use.