large_Crossover Series NFTs.png

medium_Crossover Series NFTs.png

small_Crossover Series NFTs.png

thumbnail_Crossover Series NFTs.png

From Photography to NFT Art: Twisted Digital Landscapes with Nate Hill

From Design System to ‘NFT Design System’: Creating TinyFaces

Neurodiversity and Inclusion: Choosing Kinder Design

medium_652ccf22c8853584bde5553986a4eed0.png

small_652ccf22c8853584bde5553986a4eed0.png

thumbnail_652ccf22c8853584bde5553986a4eed0.png

Web5 is here. Goodbye Web3? TBD.

Published on <a href="https://blog.prototypr.io/ux-documentation-in-a-non-boring-format-84a9c2bb1422?source=rss----eb297ea1161a---4">| Prototyping: From UX to Front End &mdash; Medium</a> UX Boot Camp 
<h4>#30dayUXchallenge [Day 27]</h4>
<img alt="" src="https://cdn-images-1.medium.com/max/1024/1*hifSoZOPWTO3NCdtjdEbVA.png">
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&#8243;, 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.
<h4>What type of documentation are we talking about ?</h4>
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.
<h4>Why do we need it?</h4>
<ul>
<li>Reference &amp; 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 ?</li>
<li>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?</li>
<li>Stakeholder buy-ing: If our stakeholders want to see the project progress, can they find it? If they can find, can they understand it?</li>
</ul>
<blockquote>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.</blockquote>
<h4>“Documentation rules”</h4>
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:
<ul>
<li>It’s short &amp; painless so our teams can use it without spending hours going through documents and trying to make sense of it</li>
<li>The entire team adopts it. Invite your Product Owner, your engineers, the marketing &amp; support crew, etc, to contribute to it too. The more the team contributes to it, the more likely it is to be consumed!</li>
<li>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:</li>
</ul>
<blockquote>Documentation is like a Tamagoshi. If you don’t take care of, it will end up shit. (<a href="https://medium.com/u/60b03eb1c0f8">Fabiano Morais</a>)</blockquote>
<h4>Lean Documentation</h4>
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.
<img alt="" src="https://cdn-images-1.medium.com/max/1024/1*KwjE7K0zcQ44jbhvaJd3Uw.png">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:
<ul>
<li>Overview of the research findings (big deliverable) with links to a deck you presented to the team &amp; some raw data such as recordings, notes, etc (small wins)</li>
<li>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.</li>
</ul>
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:
<img alt="" src="https://cdn-images-1.medium.com/max/1024/1*JEcAT73CQJ2Kv_8eFGguvQ.png">
So at the end of the project your “Documentation Hub” could look like this:
<img alt="" src="https://cdn-images-1.medium.com/max/1024/1*DDHmmaQ7_601amXjpKNf1Q.png">
<h4>Tools that can help you</h4>
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:
<ul>
<li>Project Management tools: Confluence, Wrike, Basecamp, Notion</li>
<li>Alternatives: Your company’s intranet, Google Sites, Wikis on Github, Private blogs</li>
</ul>
And that’s it, Happy documentation!
<iframe src="https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fupscri.be%2F5eb5ba-2%3Fas_embed%3Dtrue&amp;url=https%3A%2F%2Fupscri.be%2F5eb5ba-2%2F&#038;image=https%3A%2F%2Fe.enpose.co%2F%3Fkey%3DdRXnS9Gplk%26w%3D700%26h%3D425%26url%3Dhttps%253A%252F%252Fupscri.be%252F5eb5ba-2%252F%253Fenpose&amp;key=a19fcc184b9711e1b4764040d3dc5c07&amp;type=text%2Fhtml&amp;schema=upscri" width="800" height="400" frameborder="0"><a href="https://medium.com/media/8d5e2c740a04faf463af9accfa7e3c31/href">https://medium.com/media/8d5e2c740a04faf463af9accfa7e3c31/href</a></iframe><img alt="" src="https://cdn-images-1.medium.com/max/119/1*g1xXlc-Yf5xkdPNdA_gxEg.png">Gabi Braga — UX Designer at Envato Elements, freelancer at Toptal &amp; beer enthusiast in her spare time
This post is part of the #30dayUXchallenge: you can read more about why we started it <a href="https://medium.com/envato/why-were-embarking-on-a-30dayuxchallenge-e3d9f1bc1ac6">here</a>, and don’t forget to follow us on <a href="https://twitter.com/ux_bootcamp">Twitter</a> and <a href="https://www.instagram.com/ux_bootcamp">Instagram</a>!
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=84a9c2bb1422" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou">
<hr>
<a href="https://blog.prototypr.io/ux-documentation-in-a-non-boring-format-84a9c2bb1422">UX Documentation (in a non-boring format)</a> was originally published in <a href="https://blog.prototypr.io">Prototypr</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

UX Documentation (in a non-boring format)

UX Documentation (in a non-boring format)

#30dayUXchallenge [Day 27]

Top Stories