Right from the beginning, should you document your work? Explain it for POs, developers? Yes.

And there are few types of documentations which are useful, from startups to corporations. Here’s how they look.

Screen Flow

Screen flow is usually written on how users may move, which screens will be shown during any interaction. It can reveal a lot of scenarios that aren’t visible from the start. For example, while building onboarding flow, the user can take many different roads, and preparation for everyone is hard without a clear view. This should be prepared way before development, and it is essential to have it written.

Use Cases

Without the traditional “user cases,” the more defined way is to explain the use cases of the product. For example, if you run a website builder platform and have a use case to “create a website,” your description should look like this:

Participant Description
Matt, Freelancer For Matt to make his business model work, he must create websites for his clients.
A. Primary flow
1. The user lands on the homepage
2. The user selects a theme
3. The user finish the registration process
4. The user complete payment information setup
5. The flow is completed, and the website is created
B. Fails payment information setup
1. If the user can’t successfully submit his payment information in the setup, the user is notified and asked to contact customer support.
B. Fails registration process
1. Display error and report to the system about potential UX misunderstanding. (Send HotJar recording to UX Lead)

. . .

This documentation will display primary ways how the user interacts and achieves a particular goal. The examples will differ but additionally will save you a lot of time if some things don’t go as expected. In this written form of experience, you will notice one or few potential UX improvements (for example - maybe the registration is so painful that it should be at the last step?)

Page Functionality

Page functionality documentation usually includes two primary principles:

  • All functions of the page are written
  • Services have their purpose listed

For example, below, I’ll display one documentation from a product I’ve done recently.

Logo Customization Screen (/logo/customize):

Element Functionality
Color Button Allows changing color parameters
Symbol Button Allows adding spacing or increase logo symbol
Text Button Allows changing title, font, text color, size, and letter spacing
Slogan Button Allows adding/remove slogan
Align Button Allows changing logo alignment and horizontal, vertical positions
Save Button Shows mockups and displays continue button (to registration/login page)

This information displays everything you should know about your product features. In this case, you can either add even more functionality or delete not so important stuff. As you might know, less is more and sometimes can lead to a very unclear user experience flow.

. . .

In this short blog post, I’ve tried to illustrate the documentation types quickly. Those can take a lot of time in some projects, but keep in mind that you are an expert, crafting the best product available - a bet worth taking.

These things help to set some ground rules and keep everyone on the same level in my own experience. The best way is to try it out and evaluate how it affected your workflow.