Documenting UX

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.

 

How about Graphic Recording for documentation?

As a Product Designer, wireframes, sketches act as a medium where I can think, explore, validate on a problem space. Be it a wire framing tool or just paper and pen, it works and I'm almost certain a lot of designers do. But the trouble is not there. That's a great approach; however the problem lies when it comes to documenting this. In the last few years, the amount of documentation that I find for existing products or my own design is almost nil. I see wireframes; big fat wireframes. The bigger the system, the more. 

I don't see a summary, or a workflow of the problem that someone is trying to solve. Wireframe is not a great tool to deliver that message; forget about a workflow. 

According to Will Evans

A picture is worth a thousand words; an interface is worth a thousand pictures; a theory is worth a thousand interfaces.

Earlier this month I got to attend LeanUX conference in Brooklyn. One of the best things at the conference was the Graphics Recording by Dean Meyers (@deanmeistr). His job although very creative was extremely important - record all the talks in a graphical way. Brilliant. I did not have to take down notes. All I had to do was once the talk was over and during a break walk over to the wall and snap a picture.

I came back to work with a solution to my cumbersome documenting issues. I quickly scribbled down workflows and summarized them in a graphical way. It was awesome. It was one of the best way to communicate the idea as to what exactly I'm trying to solve. I shared it with my team, bingo they got it right away. 

I shared it with someone else with no context to my project to bring them on board; they came back with 100 questions.

What went wrong? I thought I had nailed it. I thought it was simple and intuitive. Everyone understand the diagrams I came up with. I shared the LeanUX conference graphic recordings with my colleagues, and I realized, that a narration was also important. It was easier for me and my team to understand these diagrams because we have a great context around it.

So to solve that issue, what I did was come up with a story line - one liners (and explanation when I had to explain a concept) with bit sized graphics. This was perfect it explained the workflow bit by bit and then zoomed out to show the big picture. Something like what Prezi does and thats exactly what I did. 

If you have the patience to draw and scan, Prezi has been an excellent tool.