User Flow: A Process Analysis
Learning how to create a flowchart is not only helping the project, it also helps me to structure my thought and organise the information at my hands, even in daily life.
Last updated
Was this helpful?
Learning how to create a flowchart is not only helping the project, it also helps me to structure my thought and organise the information at my hands, even in daily life.
Last updated
Was this helpful?
Back in 2017, I started as Business Process Analyst months before I got promoted to Product Manager role. For me, creating "Process Flowchart" is the very first skill I learned to survive in project management field. Because most of the times, I found it was hard for the clients (or users) to speak clearly about what they have in mind, so it's my job to help them (and my team members) to be present at the same page about certain idea and requirement.
Here's flowchart analysis comes to the rescue! It is a simple tool to visualise idea, especially a process or system, that everyone can digest and understand in a quick manner. It could be a deep and detail process analysis or a very general one depending on how are you going to use it to communicate with others.
In this writing, I will focus more on Task flow and Wireflow, the types of flowchart that I frequently use in daily basis to develop products or system. They will help you at least with three things:
Organise, structure, and visualise your thinking about product ideas/process/system etc; that is putting all information in your head into a written and visualised form, so that you can have a clearer visibility on "what is actually going on".
Find and spot loophole that could cause potential pitfall (aka. negative scenarios) in your product ideas or users' jobs-to-be-done process, so that you can mitigate the risks early on to avoid wasting time and resources later.
Communicate your thought using visual docs will help your teams to receive information easier. Because they don't have to build mental model from scratch, as you have provided them with visual cues. This is to prevent misunderstanding from day one.
Please keep in mind that I'm not a Flowchart Master, nor I should be one. But, I will show you that the most basic and commonly used symbols in creating a flowchart can answer almost all of the process problems.
Reflective listening is a communication strategy involving two key steps: seeking to understand a speaker's idea, then offering the idea back to the speaker, to confirm the idea has been understood correctly. It attempts to "reconstruct what the client is thinking and feeling and to relay this understanding back to the client".
Both as PM and analyst, you'll likely spend most of your times observing and listening to others; your clients, users, superiors, customers, peers, team members, etc. So, it is in you best interest to make sure that all the information you received is actually the one your counterpart is trying to convey.
Using the reflective listening strategy, I usually do the following when communicating with others, especially in meeting format:
Listen carefully, with full attention, to everything is said by the speaker, although it's not always necessarily agreeing with them either.
Take note for any key message we can recognise, and order them according to topic or agenda section, so that it's easier to retrieve later.
Clarify or even challenge some of the speaker's contents that you are not sure about it (e.g. why did they prefer certain flow, when you think it could be done differently).
Offer your point-of-view and discuss it with them, even though they won't necessarily agree with it, but you have taken your job to speak up.
Lastly, try to recite and then recap the whole conversation's key messages, as it could be different or changed from what have been stated in the initial discussion.
Let's get started with real-life example! Supposed you are a PM for an e-commerce startup selling traditional herbal drink (aka. Jamu). Your team is responsible to design and build the checkout and payment journey using e-wallet for the new mobile app, and you've conducted several discussions with stakeholders and then come up with this conclusion:
User story: As a User, I would like to checkout the items in my cart and pay them using my e-wallets.
Choose item(s) they want to checkout
Tap checkout bottom from cart page
Select delivery address
Select delivery method or courier
Review order detail and total cost
Confirm checkout order
Select payment type: e-wallets
Pay the order using their e-wallets app
Get notification "payment received"
Did you notice that all the steps mentioned above is started with "verb"? Yeah, I bet you this is where the "Task Flow" term comes from (haven't looked it up at google, yet ✌🏽). Now, let's convert those steps into task flow diagram.
The very first draft of my task flow diagram will look like the picture above. I'll go first with linear flow from start to end, assuming the ideal case that could be happened and ignore any possible setback. From this draft version, what I'm trying to achieve is simply visualising the whole journey users will take to arrive at their destination; similar to direction in maps, you only focus on the starting point and the destination first.
After that, you could start asking yourself what negative scenarios that could possibly happen on every check point in the user flow. But, before we discuss further about it, let me walk you through the components presented in the picture above.
Actors; as the name suggests, Task Flow should have at least one actor to perform the task. In our case, User is obviously the main actor who does the tasks we have previously listed down. In addition, as an analyst I was thinking that since we are building a software product, the System that we build is actually an actor too 🤔. Because both of them will interact with each other to achieve the desired goal.
Swimlane; as you noticed in the picture above, there are two rectangles in the background. They act as border area for each of the actor. This is to tell which steps or processes performed by whom. In our case, we have two rows because we have 2 actors. You can actually have more than it, such as 4 rows depending on the system you are building (e.g. Raid-haling actors: Passenger as user/customer, GRAB as main system, OVO as payment gateway, and Driver as service provider).
Start/End; every flowchart must have both Start and End points. It is so that people can easily decide from which step they should start reading the diagram and which other step that will conclude it. A clear start to end flow will also help you think an orderly manner. As the system flow is very complex, the Start point of a task flow diagram could be likely the End of other diagram. In our example, we can guess that the "Choose Item(s)" step is possibly the End point of "Add-To-Cart Task Flow" diagram.
Process; also know as "step", it is the heart of every flowchart. We separate each task into rectangle box that represents process taken by the actors. It's recommended to write the task inside the box as concise as possible using "verb + object", as shown in the picture. That is why it's important for you to write down all the tasks first, before starting to draw any diagram, so you don't get stuck in the middle of it.
Arrow; every step or process inside the task flow diagram should be connected to each others by using arrow line, otherwise all will be meaningless. The arrow line told us "what's next" when people read the diagram step-by-step. In our case, since it's a linear flow, the arrow lines are pretty straight forward from Start to End, or one direction line. In most cases, it's not that simple. The arrow line could actually go back to previous steps instead of advancing, if it doesn't pass certain decision criteria.
Now that we have the linear task flow diagram laid down, it's time for us to question it and imagine what possible negative scenarios that could happen, which able to break the flow. You can start by reading the flow step-by-step and raise question, concern, and/or doubt to every process box, if any. Here are some the examples I could come up with at the moment:
What if users have not added their address?
What if users' address is outside of seller's delivery coverage?
What if system could not get the latest pricing from delivery 3rd party?
What if system fail to calculate the total cost due to system error?
What if users decide to not continue the checkout process?
What if users could not find "E-wallet" in the payment method list?
What if system fail to create order_id or invoice when users initiate payment?
What if system fail to notify 3rd party payment gateway to process?
What if 3rd party fail to notify our system that payment has succeeded?
and so on ...
After you've done with analysing some of the potential pitfall, now is the time to revisit and update your initial task flow diagram. Try to simulate all the negative scenarios above into your diagram. You could also consider to further divide it into several smaller diagrams as the system is getting more complex even for this particular "Checkout and payment" functionality. I would give you one other example below on how to incorporate one of the negative states above, as for the rest of it I hope you can try them yourself.
I have added the "Address is not available" state into the task flow diagram above. Using the Decision component (diamond shape), we could decide the follow up step or process user could take given certain criteria. The most commonly used decision checker is "Yes/No" validation. In our case, we can direct users who have no address yet to perform task "Input New Address" first before our system can calculate the estimated delivery cost.
In this writing, I won't go deep into "Wireframing technique", let's save it for another occasion, okay 😉
I usually use wireflow diagram to further add visual elements to the process flowchart. This is especially true if you are working on customer facing mobile apps or website that need interface design. This wireflow will hep you communicate the relationship between screens or pages before you break it down into workable tasks for both engineering and design team. It's also one of important documents you can prepare to get buy-in from your stakeholders.
When you try to convert Task flow into Wireflow diagram, you will notice that the steps to complete certain task are getting more details; means more stuff to consider. In some cases, you can possibly need more than 3 screen states to represent one task or step. In our example, the step to "Input New Address" could be broken down further into several states and then show how they relate to each others:
Address list empty state
Pick pin location on the maps
Input new address detail form
Save new delivery address
Select delivery address
Now you should be able to start imagining how to listen and think like a process analyst. If you are already a PM, I hope it can add another perspective to your toolkit. If you are aspiring to become one instead, I suggest you to put these skills into practice by analysing some of the popular apps you use in daily basis; it could be actually used to analyse the company's product you are planning to apply for later. A recap:
Select particular module or function
Define the User Story and its linear steps
Draft and revise the task flow diagram
Convert task flow to wireflow diagram
One thing to note tho, these diagrams are not the "final decision". Especially true for the first drafts, because it's a living document. Please encourage your engineering team to raise technical limitation or your design team to suggest better UX alternative. Because your ultimate job as PM is to find the right problem to solve and then let your team members to come up with the best solution to answer the problem; not to let others just doing everything you've told them so.
Before jumping to the "drawing" part, this is one important thing you need to master to help you become a better process analyst (even as a social being); namely Reflective Listening. Here is what said about the term:
In fact, I use flowchart as a way to reconstruct every information I have received then relay it back to every stakeholders involved, including my team members. This is again to make sure everyone is agreed on the same understanding. Check this article for the dos and don'ts of .
