How to visualise user flows for common understanding between team members

by
Rich Cleeve

I was helping a friend to think about how users would interact with a platform he’s planning to build, and getting it clear in his own head, before communicating to developers and other stakeholders about what happens inside and outside of it. So I thought I’d write a post on how we go about doing this at Codestream. What we are aiming for is something unambiguous that all team members can understand.


To illustrate the process I’ll use an example from a platform we are currently working on for Corporate Secretaries to cut time & stress spent on compliance for the organisations they manage. 


When starting out it’s very tempting to think in terms of what the system needs to do, but it’s a lot easier to think about what the user needs to do and helps you to walk in their shoes. In this case we have 2 users - Corporate Secretary and Business Owner. The process we are going to map out is “Incorporate a new company”. Before starting on the process we would normally develop personas for these people so we can get right inside their heads, but that’s a subject for another post. 


Where to start? In this case it would be when the Business Owner starts thinking about creating a new business, because then we open up some real insights into the user journey and opportunities for innovation. However for brevity, let’s start at the 1st interaction that the Business Owner has with the Corporate Secretary. 


We have 2 “swim lanes” - one for the Business Owner and one for the Corporate Secretary; this lets us clearly see who is performing the actions. The black circle marks out the starting point, and the boxes contain actions that the user needs to do. The blue boxes capture actions that happen inside the platform and the yellow ones capture what happens outside of the platform. 


This is an Activity Diagram from UML (Unified Modelling Language). The yellow/blue separation are not part of the language specification; just our own technique for making it clearer.


Expanding the flow further, we can see that the Corporate Secretary has several distinct steps to complete before the next interaction with the Business Owner. This raises the question of how granular do you go? The somewhat vague answer is just enough and no more :)  


Starting with the Corporate Secretary, I have broken this into 3 steps before the next interaction. There is a lot more detail that can be written under each one, but it should be at a high enough level that the process can be easily digested. For example, “Generate documents” involves selecting a template, adding members or officers, and then editing the output before emailing the docs to the business owner, however if we added that level of detail here, it would be very hard to digest. In this instance it is simple enough to cover in a wireframe, but if an action is more complex than that, another activity diagram can be created.


For this process, I also wanted to figure out how it could be broken into trackable steps. Once it was mapped out, I looked at it in terms of what can be completed in one visit to the system, and put boxes around those. Between steps 2 and 3, there is a delay whilst waiting on something from ACRA.


Here is the whole incorporation process from start to finish.


There are plenty of opportunities for further development here, but we want to keep it as light as possible so there is less to develop, and we can ship early whilst still delivering value. It is also showing the path through the “happy case” without cluttering it up with logic checks. We take an agile approach, and start adding scenarios nearer to the development sprint for conditional logic. 

Summary

1. Think about what the user has to do, not what the system has to do.

2. Swim lanes are the best ever invention in software modelling; they really force you to think about what the user has to do, and they make it clear to everyone else.

3. Don't over complicate, keep at a level that is digestible and break down with further diagrams only if absolutely necessary.


Hopefully that has given you some ideas of how to think about the user flow and shows you some ways to model it. There are lots of tools you can use for this - pencil & paper, Visual Paradigm, LucidChart and Visio are just a few examples.