Flowcharts, or ‘process charts’ have been adopted and adapted by people in all kinds of jobs, from engineers to business analysts, developers and designers. Their adaptability and their ability to demystify complex logic makes them a powerful communication tool.

As product people, we’re always keen to try new things, eager to get started defining how our latest feature will work. Therefore, we have tried every methodology under the sun for documenting processes and journeys, but we find that the one we keep coming back to time and time again is the humble flowchart. Whether it is documenting the journey through a website or the backend office process of a service, we believe that a flowchart can communicate complex systems more efficiently than many of the alternatives.

A century old strategy

Flowcharts have been used since the 1920s and were first presented by Frank and Lillian Gilbreth at the Annual meeting of the American Mechanical Engineers. In their foreword, they describe how every detail of a process is affected by every other detail within that process, so the entire process should be presented in a way that can allow the viewer to visualise it all at once.

The Gilbreths explain the adaptability of the process chart, “The process chart lends itself equally well to the routine of production, selling, accounting and finance”, and their ability to cut down on lengthy documentation and ‘obtrusive material’ created by engineers to document a process. We still see these benefits some 100 years later. 

A common mistake

In the excitement of creating something new, it is tempting to jump straight into the details by defining detailed user stories too early in the process. However this can often cause you to lose sight of the bigger picture and the reason why you’re creating the feature.  Also, producing so many outputs so early on makes it really difficult for others on your team to dive into a process midway through or for that matter, for you to easily pick up where you left off as priorities change and timelines shift. The problem we’ve found with Behaviour-Driven Development (‘Given When Then’ statements) or the circumstance-led Outcome-Driven Development (‘Jobs to be Done’ statements) is that because they result in a lot of written documentation, they can be difficult to amend or ‘unpick’ at a later date should the need arise. 

Since the key to success of these methodologies is their ability to aid communication and improve the efficiency of development, it’s essential that they reduce both the amount of time and the materials needed to succinctly communicate a complex concept across teams. If the time spent documenting processes, activities, decisions and outcomes result in walls of text that take ages to read, is this the best use of time for all involved?

Enter the flowchart

We encourage our designers, when designing a new aspect of a product or service to always map out the journey using a flow diagram. Tools like Miro have made their creation more simple than ever before and have in a way democratised their use. Now in workshop settings, flows can be used as a collaboration tool between designers and developers. If you have to write 4 hefty statements to explain a complex part of your journey then consider a humble flow first - at least while decisions are still being made. When you do this, ensure you map the ‘happy paths’ (parts of the flow that result in a positive outcome for the user) as well as the ‘unhappy paths’ (those that may not end so well) so you can imagine a balanced view of what it might be like to use your new shiny feature.

You will find yourself discussing the correlations and causes of different stages of the journey as well as how the journey works holistically before diving into the details. Which will ultimately result in a better experience for the lovely human beings we’re designing for.

Now off you flow.

Have an idea you want to discuss? Call us for a free consultation

get in touch