The idea of my blog post is to show you why you may need a flowchart, how to do it, share the resources that helped me and some tips from my latest experience.
Last week I needed to find the best way to represent a process in an easy to understand manner with as few words as possible while keeping it very visual and avoid skipping any important points between the parts in the process.
Does it sound familiar to you? Good communication and easy visualization of a process or a flow is even more important when your stakeholders are remote and in a different time zone, so you cannot grab a piece of paper, a pen or draw on your fancy whiteboard.
Honestly speaking, I do like explaining process and finding the linking bits, but I wasn’t such a fan of flowcharts (especially those deeply technical ones that would take a day to prepare) when I worked as an IT Business Analyst.
Why do you need flowcharts in your product management role?
As a product manager we’re wearing so many hats at once (from technical, market researchers, sales, marketing, support, product evangelism and beyond) that it’s important to be productive and mindful of our own time.
The mission of the product manager is to bring value with the product and solve user’s needs.
You need a flowchart (or workflow or whatever you want to call it 🙂 as long as you understand that it is a flow of charts that include interrelated elements) in the following cases:
- You want to describe a user flow.
- You want to describe how a process works and parties/systems involved.
- You want to draw the dependencies between systems and the different inputs, outputs, conditions.
I’ll share with you that getting a real good, self-explanatory flowchart is not as easy it looks like, but don’t be scared, just collect your information/requirements and let’s get started.
Power Tips for Better Flowcharts
Again, flowcharts can be a really effective, efficient way to show steps in a process. So if you just want to share a process that requires ‘yes / no’ type of response from a stakeholder / participant OR indicate that they need to perform an action, then the flowchart is a way to go.
Start
The very first thing that you need to do is to define where your flowchart starts and ends. Which are the key things that you’d like to convey? Is the focus on the system(s) or processes or integrations between different software applications?
It sounds basic, but the start and finish are your ‘friends’ to start ‘drawing’ from the big picture and decompose to each element.
Be consistent
There are key shapes that you should use for your flowchart, just scan through the resources that I’ve shared. No matter whether you’d like to stick to the common shapes or just have a more basic version of your flowchart, you’ll need to take care of consistency across the flowchart.
This will be reviewed by other people, so don’t confuse them.
Basic shapes
If you want to remember one thing, then let it be: oval shapes are for start and end of your flowchart. Do you remember that I’ve said that the start and finish are your top item aka canvas that prepares you for your picture?
All other steps could be rectangles as they denote actions and you can add a specific comment to them. Decisions are usually diamond shapes and documents should be visualized as such.
But, wait, what are decisions in this case? Decisions represent a question which is binary, yes or no and depending on the choice, then the flow changes where the process will progress to.
What’s the glue between the shapes? You may guess it right, arrows act as the connectors between the shapes in order to connect the different steps.
Colors are good or gold (depending on the situation and your reader)
Don’t start throwing too many colors, but keep in mind that sometimes colors could be helpful to make process steps clearer. For example, in my case, I’ve marked all steps in light green to outline to which step/extent we can deliver and put a clear line to show where the other systems need to be prepared to consume our data.
Some people are more schematic and others love color coding, so maybe it’s good to use different colors for decision shapes in your flowchart. Thus, you will attract the attention of a person who is a stakeholder and wants to see where a system / participant will make a decision without going through all your hard work 🙂
Let me read it
Most languages are LTR, left to right, so make sure that your flowchart has a good readability.
Repeatable steps
Do you see that a user performs an action repeatedly? Or would the system sends information continuously if a certain condition is met? Make sure that you draw the user icon and relate the repeated processes to better explain it.
Type of information
What’s the goal of each piece of information that is included/derived in a step in the flowchart?
I’d suggest you to grab the good old pen and paper to sketch a basic classification of your information before you start drawing.
- Input data
- Action
- Output
- Where do we update the data
- What’s the expected outcome
Tools that I use for flowcharts
Well, honestly, you can even draw your flowchart in Google slides as some shapes and arrows are easily available.
I’d recommend more professional tools, depending on the complexity of your flowchart. I personally use and like (ordered by my personal preference:
- Gliffy
- Draw.io
- Balsamiq (better for wireframes, but some easy diagrams could be also built)
Conclusion
Flowcharts / diagrams can help your product development. The use cases are endless: from pure project management (to draw where you collaborate and how, dependencies), communicate requirements / missing parts with stakeholders, collect information / inputs / outputs for your own thinking process to present very technical product features and system dependencies.
If yes, then do this, no, proceed with that. Give it a try. Start. End.
Resources on the web that I recommend you to start with:
- 5 Useful Diagrams for Product Managers
- Example of flowcharts
- How to improve product management skills with flowcharts
Image sources: