Published on | Prototyping: From UX to Front End — Medium UX Boot Camp

#30dayUXchallenge [Day 27]

It’s day 27 of the #30dayUXchallenge and, at this point in our UX Cycle, we are pretty much delivering our first project.

Let’s assume our research is pretty much finished, our designs are high-fidelity and validated by test, we are already pairing with engineers to start implementing it and, on the other side of the company, we are probably already starting the cycle again to kick-off a new project.

At Envato, for example, on the day I write this post (27th of November!), I am pairing with engineers to finish implementation of “project one”, pairing with our researcher to start the research plan for “project two” and being added to a few meetings to discuss risks for “project 3″, which we will kick off only next year.

And I hope you already got my point, but if not, I will explain myself: there is no way my brain can absorb all this information. On my own, I would forget most of the discussions, lose track of what is happening and — even worse, wouldn’t be able to pass it ahead when needed. To make it even harder, if I am planning any holidays, for example, I really need to make sure my team finds what they need, when they need, without contacting me.

That’s why we need documentation.

What type of documentation are we talking about ?

Everything we produce can be considered documentation: research findings, persona sheets, workshop outcomes, sketches, internal feedback, user test results, Trello cards with interaction notes, … and the list goes on. Let’s call them deliverables.

Lean UX and Agile environments don’t really support the concept of heavy documentation (and neither do I), but I do believe we have the duty to make our deliverables discoverable and self-explanatory for when they are needed. It’s not about investing hours a week to create an entire wiki with decision logs, but it should be about having one source of truth for small milestones we achieve in the project.

Why do we need it?

Reference & Context: If we go on holidays, does our team have access to our assets — and do they understand the context behind them? If we want to find more context behind something that wasn’t done by ourselves, can we find it without contacting the owner ?
New team members: If someone joins the team next year, will they be able to find the research findings for a specific project and the rationale behind the decisions that were made, for example?
Stakeholder buy-ing: If our stakeholders want to see the project progress, can they find it? If they can find, can they understand it?

So let’s make sure we have a source of truth in place so things don’t get lost! It’s all about having one source of truth for our deliverables.

“Documentation rules”

We don’t want to waste hours working on pages of documentation that won’t be read by anyone, right? Documentation is just actionable if it is used, so we need to make sure:

It’s short & painless so our teams can use it without spending hours going through documents and trying to make sense of it
The entire team adopts it. Invite your Product Owner, your engineers, the marketing & support crew, etc, to contribute to it too. The more the team contributes to it, the more likely it is to be consumed!
But take care of it. Don’t make it too complicated to maintain otherwise things can fall through the cracks. As my favourite deliverable coach says:

Documentation is like a Tamagoshi. If you don’t take care of, it will end up shit. (Fabiano Morais)

Lean Documentation

How do we make sure it’s lean and smooth so it doesn’t disrupt our routine? So here goes my personal approach:

“Small wins” don’t go there, but can be linked to it.

“Big deliverables” do—so they are posted and explained.

I mentioned above that every asset we produce can be considered a type of documentation, so as you can see on the drawing below, over the UX cycle we will iterate on multiple small wins: sketches, prototypes, keynote presentations, site maps, user journeys, Trello cards, etc.

Source: UX Bootcamp

We don’t need to document the context of every small deliverable — but we can, for example, document a summary of the workshop outcomes (big deliverable) with photos of the activities, the presentation that was used, etc (small wins). That way, if you go back to it six months later, for example, you can still understand if the project is on track of its goals.

Another good examples of big vs. small deliverables could be:

Overview of the research findings (big deliverable) with links to a deck you presented to the team & some raw data such as recordings, notes, etc (small wins)
Screenshots or a link for the live product (big deliverable) with photos of sketches, middle-fidelity wireframes, previous explorations, etc (small wins). with some context of way big decisions were made.

Tip: both at Envato and IBM, we used Github issues as a central place for the entire team to collaborate, get feedback and get context behind the decisions. It is a great way to collaborate with the engineering team on their environment, while still using a handy tool for quick back and forth. Really recommend it! Here goes an example of how it can be used:

So at the end of the project your “Documentation Hub” could look like this:

Tools that can help you

The right tool is whatever tool that works for your team, so there is no right or wrong here either. But a few options for you to consider are:

Project Management tools:
Confluence, Wrike, Basecamp, Notion
Alternatives:
Your company’s intranet, Google Sites, Wikis on Github, Private blogs

And that’s it,
Happy documentation!

<a href="https://medium.com/media/8d5e2c740a04faf463af9accfa7e3c31/href">https://medium.com/media/8d5e2c740a04faf463af9accfa7e3c31/href</a>Gabi Braga — UX Designer at Envato Elements, freelancer at Toptal & beer enthusiast in her spare time

This post is part of the #30dayUXchallenge: you can read more about why we started it here, and don’t forget to follow us on Twitter and Instagram!

UX Documentation (in a non-boring format) was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

UX Documentation (in a non-boring format)

Cool stuff, every week

More Articles