Documenting UX

It does capture details; however, chances are when I see someone else’s wires, I may not like a solution. How do you support your solution?

A lot of companies today implement an agile process and the remaining ones like to call themselves agile. A few years back any designer (UX/IX) would pull out their hair because turning around design details wasn’t easy given the amount of time a sprint would end. Years go by and processes have evolved. Processes like LeanUX and staggered sprints or design and R&D sprints in parallel have more or less solved this issue. However these processes have reduced the amount of documentation.

We have user research data, but never used it to create personas. We have analytics data but never exported them out of their software/databases. There are a list of scenarios or stories that are important or have a higher priority, but they never made it to the official todo list or backlog. All, I see is wireframes, trolls of em. Some of them make sense like login screens and forgot passwords; the others I have no idea. Today wireframes have become one of the most important means of documentation. I even see scanned sketches, photographed whiteboards and clickable wireframes. One change in the use case or workflow, and you are back to square one.

It does capture details; however, chances are when I see someone else’s wires, I may not like a solution. How do you support your solution?

And I have made them all; mistakes. The fact that the requirements or priorities are in my head and not anywhere else does not do good for me to convince someone why these things need to be done the way I intend to.

Over the last couple of months I started maintaining a combination of few documents that has helped me transition stuff and propose design easily. Here is a short run down of these documents and processes:

We all do our bit by venturing out and talking to users. We capture notes and lot of em. When you do so, try to capture them as quotes. There are two important advantages in doing so. One, Its faster to write them while you are interviewing/talking to them and Two, it preserves the context.

"I have to apply the same filter every fucking time I visit this page"

“See I like this pages concept in OneNote. This way I can just have multiple notebooks and go and write down in pages within them..."

One of the important thing is to digitize these notes. It could be in a notepad or Evernote; I found excel helpful (yeah!). I was able to create buckets/categories and then write the quotes in these specific buckets. Also, when I digitized these notes; I was able to add attributes to them; like screen resolution, position, firm, interview date, system usage, type of user, etc. These become important when I really wanted to narrow down to specific kind of users.  Apart from that I color codeed these quotes - for example. Red for negative, Blue for positive and Greens for opportunities; this gave me an idea on the state of the existing software.

I haven’t created any personas (and I might not for the time being) for my work. But when I was working on a specific problem, I was able to filter down to a handful of target users in my excel sheet then parsing through notebooks of research data. Once I have narrowed it down to a bunch of users, it is easier for me to identify patterns in their quotes (colors added value). Those attributes that you add now allows you to see how much is in common between these users.

After looking at my excel, I note down tasks/use cases/stories. I maintain a list in a todo list. Apple reminders does the job for me. Nothing fancy. This allows me to scope out, prioritize stuff. Anything that is high priority gets a date and bubbles up, rest of them just remain at the bottom. Simple.

Analytics - If you have it, great. This comes in use when you really want to see what users are doing with existing systems. How are they using it. Export them and keep them handy. Don’t rely on your system that you did log in and get data. Historic data is fine. Patterns are not going to change overnight. Export them because you can quickly pivot data. That is important to figure out supporting numbers for your uses cases.

This accompanying my wireframes/sketches is a good combination. I try to ensure my wireframes are also not too elaborate. Stick to the specific workflow or use case and thats good enough.

Trying to Keeping it Simple and Stupid. So far it has worked for me. Maybe over the next few months or a year I will know if it was effective enough.

Please leave your comments and suggestions or any of the processes you personally follow or send an email to get in touch.

Subscribe to Optimistically Skeptical

Sign up now to get access to the library of members-only issues.
Jamie Larson
Subscribe