Working with flowcharts: Bridging gaps between business & user and development requirements
Imagine you are designing a new feature that would bring value to your users and to the business metrics. What is essential for a smooth development is alignment on the business, user and development logics of this new feature among teammates. Gherkin scenarios do a great job when communicating the logic of the new flow to the product team. Yet, they lack when it comes to visualize, and thus give tangibility to how the whole flow will look in the product. Having a visual representation for the newly designed feature/flow make lives of many stakeholders easier since it brings concreteness to the user logics. In that sense, mapping the feature flow helps the team know exactly users are going to be affected, how the system is going to respond to a particular user action and which specific interface to display at that moment. As Hilal, one of our team’s beloved backend developer, describes it:
“Flowcharts concretize abstract behavior of code. This helps us to run better and quicker technical analysis before starting a project. Eventually, we come up with fast and solid solutions.”
In Armut/HomeRun we love to work with flows as a product team. We combine flowcharts with corresponding UIs to communicate a newly designed feature/flow. This brings transparency to both feature logics and corresponding screens. Once user scenarios and designs are ready, we map our flowchart based on our flow components. Our usual components are: beginning/end of the flow, user action, decision question, decision response, ui to display and system response. We use Miro to do so, who is our best friend when it comes to mapping flows. In this article, we share the benefits and best practices as we experienced, when working with flowcharts as a product team.
Why working with flowcharts?
Visual > Text-based communication for the sake of team alignment
Let’s put this straight- presenting any kind of content in a visual manner brings clarity, ease and quick understanding among all stakeholders that are included in any project. Studies state that people tend to remember 10% of the things they hear and 20% of the things they read. This percentage increases to 80% when it comes to seeing and doing.* Especially in a fast-paced and multi-tasking required agile product development environment, alignment about project requirements (business, user and development) within a product team is one of the most crucial thing as we experience. That is why we seek for ways to express project logics in a visual manner. Flowcharts combined with interfaces do a great job in this. Working through flows shortens development time and brings the whole product team to the same page. It ensures a solid communication ground for product team members.
Seeing real UI with corresponding user action make logics tangible
The reason we prefer to present real user interface with the corresponding flowchart component is because it makes look and feel of the product tangible for all stakeholders. For instance, backend developers are not getting exposed to interfaces as much as designers and frontend developers. In that sense, they lack an understanding of how end user experiences our product when compared to other stakeholders in the team. Walking through flowcharts with corresponding UIs helped us to clear all the dust experienced by different members of our team.
What are flowcharts?
Flowcharts are basically representations of user flows formed by different components, each indicating a particular activity or reaction that designed feature/flow has.** Although there may be different components used by different UX professionals, we stick to these 6 components as they bring the perfect amount of clarity to all members of our product team.
- Begin/end: Is used to identify beginning and end of the flows.
- User action: Is what user does in a specific screen, where she clicks
- What we display: Shows the corresponding UI of a screen
- Logic question: Helps us to ask the correct question to decide which path to follow
- Logic response: Answer to the upper mentioned logic question
- What system does: Occasional component that is triggered with a user or system action, which does not necessarily have an interface
If you want to explore more about the flows in user experience field, we recommend Userflow and Flowchart articles of Interaction Design Foundation.
How to create flowcharts?
Start with indicating how your flow begins
This is the trigger that kicks-off the whole flow. In other words: what is the specific action that lets your flow start? Specifying this starting point, ensures developers to design back-end logics and decide on how clients and back-end is going to communicate.
Know to whom your feature feature is going to be applicable
By asking the correct logic questions throughout our flows, we make sure to cover all the possible scenarios that the particular flow affects. Questions like who will experience this feature, what are the criteria for users to be involved with this feature, will every user see the same thing, if not with which action(s) their experience will differ, are likely to be covered through the decision response component of your flow.
Don’t forget to think about multiple paths that will lead to the same end
In products where a particular outcome may be possible via different sources (eg: through actions of two different user groups), it is vital to consider all the parties that are involved. For instance, if a customer and service provider may perform the act of cancelling a job though the product, it is important to map both of their flowcharts so that everyone on the board can pinpoint which areas will get effected/which ones won’t with the new feature.
Practice and be open to iterations to find what works
Flowcharts are granular depending on the complexity of projects. Similar to this, depending on team members’ business, user and development needs the way you work with flowcharts is very likely to change over time. For some projects only commenting them in Miro would work, whereas in some cases you may need to map and think aloud through the flowchart as a whole team. Be open and don’t forget to wear your observer hat at all times to adjust your work flow depending on your team’s requirements.
Not rocket science, huh? All these helped us to be on the same page as a product team and let us move forward with development in an easy and clear way.
Hope you already found some useful insights from the read and are already looking forward to making use of flowcharts when collaborating with your developers and product managers.
Cheers ✌🏽
*: Morrison, Gary R et al. Designing Effective Instruction. John Wiley & Sons, Inc., 2019.
**: “What Are Flowcharts?”. The Interaction Design Foundation, 2021, https://www.interaction-design.org/literature/topics/flowcharts.
