The importance of UX documentation: How to convince others to walk a path in the future

Our work is about solving problems: business goals, adherence, conversion, interaction, feedback, user satisfaction. That is, we must find a solution and evaluate its success. With this, the importance of documenting this entire process arises.

How will we know if our work was done?

How to get substantiation on a button color change in an interface? Analyzing the results before and after, monitoring specific metrics and observing your improvements. Well, projects without goals hardly achieve any success. Documenting the path to the solution and measuring its success is also preserving the sanity of everyone involved.

What is the purpose of the project?

To avoid running out of time, it’s good practice to start documenting from the beginning of the project. And to ensure a good start today, during the first conversation, I fit in these three questions:

Start: What is the purpose of the project?
During: Are we getting there?
Delivery: Did we achieve the goal?

From the beginning to the end of a project, regardless of the methodology you are going to use, it is important to keep asking the stakeholders, the team and yourself. Many times we found out that the initial objective was not that interesting for the user or for the business, and continuing to question it also helps to reach that conclusion.

In short, your Design must do something for the business. That’s why it’s important to strike a balance in explaining the reasoning behind a proposed solution using words the business understands and whether that solution meets its needs.

Solving problems

There are no rules, the important thing is to do whatever is necessary to document your own thinking process and what you are going to pass on. So I’m going to explain my process very briefly with some tooltips that you can use as an example. And please adapt, improve and share with the community.

Start of the project

First meeting, kick-off, onboarding or whatever you want to call it and that’s when the first impact usually happens. While explaining the project, make sure you understand the purpose of the project, what methodologies and tools you can use, for example: Design Thinking, CSD Matrix, Stakeholder Map, Timeline, word, slideshow, Miro, Notion or even keep all entirely in Figma. The tool does not matter, but documenting, measuring the process until delivery.

During the Project

To better contextualize, imagine that there was a drop in the number of registrations on an online event platform. With that, the team began to investigate possible problems and managed to list one to explore. So, as a UX responsible, you come up with a solution proposal and together with the team, you try to define whether to go ahead or not, for example:

Problem:
After analyzing existing data and performing A/B Testing. An average of 63% of users who start the event registration process confuse the forward button with the back button. 17% of these users get frustrated and give up.

Solution:
1. Differentiate the states of the buttons visually;
2. Next button, like ‘primary’, completed state. Yeah, it’s what should be used more often;
3. Return to ‘secondary’, ghost state. Well, it must be used when you want to show two actions, but the first one is the main one;
4. Track the success of the solution through the metrics: TSR and UER.

To make the comparison more visual, in this case, you can also use the current interface and the new proposal. The important thing is that during the validation meetings, you should explain the process and the connection of the dots between the problem you are working on and how your proposed solution will solve it.

Project Delivery

Because executives value concise information, a good presentation practice for executives is to briefly describe the results, for example:

After analyzing existing data and performing A/B Testing. An average of 63% of users who start the event registration process confuse the forward button with the back button. With this, we identified that the best way will be to differentiate the states of the buttons visually and monitor the success of the solution through the TSR and UER metrics.

And when you can’t do research?

Being able to do research is still a delicate issue. Generally, companies prefer to go for building the product and then, when something starts to go really wrong, they decide to invest in research. However, we still have an opportunity in this type of scenario.

Regardless of the type of project you are on, seek to document your work. Below is an example of demand and documentation:

Demand:

+++Product: Insurance Contracting

In the insurance contract review stage, the following data must be removed:

+++Date/time of hiring

+++Protocol

Documentation:

+++Product: Insurance Contracting

In conversation with Maria (PO) and João (Dev), it was defined that, in the insurance contract review stage, the data below should be removed due to the fact that they are only generated once the voucher is created.

+++Date/time of hiring

+++Protocol

In Figma, you can document it on cards, with the date the demand reached you, how it arrived, why it arrived, deadline, conversations, why it was done that way and not otherwise. For this type of performance, I also suggest documenting monthly reports in ppt. That is, you will have the documentation in Figma and in ppt, because executives are more familiar with slides than with Figma. It’s a more viral way of reinforcing your work, which is actually being done, based on properly documented decisions.

Transform your thought process into something real, shareable and visible

Executives are increasingly realizing the value of our work and want to influence the entire process because the success of their business is at stake. Of course, sometimes you’ll have a lot of time to prepare, and sometimes you’ll need an immediate response. And no, our designs do not speak for themselves. So it takes research, analysis, testing, comparisons, data-driven decisions, documentation, and ongoing metrics tracking.

“UX Designers need to justify why they are making their design choices, they need to show user data, enter real field data, enter real test data and also the justification. You can’t just have someone else accept your design. It has to be credible and convincing. UX work has to be reliable.”

– Frank Spillers CEO/CXO/UX Designer Lead na Experience Dynamics Inc.

Practice documenting your process as much as you can until it becomes a habit. It’s important for the business and for yourself. Well, documenting and learning to argue articulately can also help you get incredible opportunities in the future.