How to Draw a Data Flow Diagram?
This is part 4 of a long-form series of setting up your Product Documentation.
You can read part 3 here, where I discuss how to write a Product One-Pager Document.
If you understand how to draw data flow diagrams, feel free to skip over to the next section where I discuss how to write a Product Requirement Document for your Engineering team to consume and build the Product Feature.
Out of all the UML diagrams, Data Flow Diagrams are the most used for Agile Product Building and Software Development since they help with conveying massive amounts of information encapsulated into bite-sized consumable form for all relevant stakeholders.
A Data Flow Diagram is a Product Flow diagram that’s used to illustrate to your team the flow of information in your Product, its conditional business logic, and the completion of a task for its user.
You should use data flow diagrams to bring your team together on the exact flow of information between different interacting systems or the life cycle of an entity within your system which can take up multiple possible statuses.
Components
Let’s briefly discuss the important components of a Data Flow Diagram —
Process Box
A process box is used to include a key pre-defined process for which input and output are already decided. These are represented by a rectangle shape in the diagram.
Input and Output Box
Input and Output boxes are used to indicate specifically in a Data Flow diagram input accepted and output displayed. Input and output boxes are represented by parallelograms in the diagram.
Decision Box
A decision box is used to include a key business logic decision that has a binary outcome such that two different legs emerge from it to define two flow conditions. A decision box is used to indicate the key possibilities in your Product Flow that the engineers or developers would have to account for while writing their code. A decision box is represented by a diamond or rhombus in the diagram.
Connector
A connector is used to indicate a place in the flow that connects to another flow that is already defined. Connectors are useful for including repeatable logic being reused in your Product flow in more than one place. A connector is represented by a circle in the diagram.
Terminator
A Terminator is used to indicate a ‘Start’ and ‘Stop’ state of the diagram or the terminal state beyond which the flow is supposed to stop. A terminator is represented by a capsule or an oval shape in the diagram.
There are some more components part of a Data Flow Diagram. However, I haven’t found any more components to be useful in my Product journey so far.
Data Flow Diagram Types
In your journey as a Product Manager, you would have to draw Data Flow Diagrams for the following use flows and use cases —
Product Flow Data Flow Diagram
Product Flow Data Flow Diagram is a diagram meant to illustrate the interconnectivity of different Products or systems together with each other. These types of diagrams help you at times when you’re building features that have users across different types of Products in your Product stack and involve to and fro information between these types of users for delivering a service experience to a user.
Let’s take the same example as taken in part 2 and part 3 of this series and a brief of what was discussed in the last part.
Let’s take the same example as taken in the last part while building the feature of delivery of food to a customer in the cab by the driver for EasyRide Technologies Private Limited. We had discussed the Product flow for the same as follows —
Let’s discuss this diagram’s entire flow in a little more detail —
- If there’s any inventory available with the driver with whom a consumer has booked a cab ride, it’d be displayed to the consumer on the app available for ordering
- If the consumer adds any food item to the cart, checks out, and ends up making the payment successfully, the same order will be sent to the EasyRide Inventory Management system for processing
- The EasyRide Inventory Management would block the food items placed in order by the customer to prevent any overbooking
- This notification will be sent to the driver to request fulfillment of the order to the customer
- After the driver hands over the food order item, the same will be updated to the Inventory System to delist the inventory, and record the order completion, and the same update will be sent to the customer on the Consumer App
Notice the interconnectivity of three Products — the ‘Consumer App’, ‘Driver App’, and the ‘Admin Dashboard’. Notice the key components used in the separation of each product and the key actions being taken in each Product flow. This level of diagramming should be enough for your engineering and design teams to pick up this flow to implement their respective deliverables.
You should be using Product Flow-type Data Flow Diagrams whenever you’re building flows that connect different Products together and whenever different types of users are involved in the end-to-end completion of one Product flow.
Entity State Flow Data Flow Diagram
Entity State Diagram is a diagram meant to illustrate the states of an important entity or entities in the execution or implementation flow of your Product.
As a Product Manager, you may have to come up with Product Requirements where you’d have to decide all the possible statuses of a new Entity or a group of Entities that you may build. In such cases, you’d have to come up with a Data Flow Diagram for defining the key action points at which the said entity acquires one of the statuses that you define.
It’s important for you to define these possible statuses and the exact flow of these statuses for your Engineering team to implement the flow.
Let’s take an example to understand the Entity State-type Data Flow Diagram -
Let’s assume that you intend to build the Inventory Management system for the food order flow discussed in the last part. Let’s assume that the food order that’s placed by the customer goes through some stages before being fulfilled and you want to track all the orders along with their respective stages.
Let’s discuss this Entity-State Diagram in a little more detail below -
- In the flow, we can observe that when an Item is ordered by a delivery hub and procured from the vendor, the state of the item is marked as ‘Procured’
- When the food item is brought to the delivery hub, it’s marked as ‘Stocked In’ to indicate that the food item is ready to be picked up for fulfillment in case of an order. This state ultimately informs the Delivery Hub Manager of the inventory level and when to place the reorder for stock
- When the food item is picked up by a driver interested in food order fulfillment, the item’s state is marked as ‘Driver Pickup’. At this stage, all the food items with this status would be the sum total of the available inventory for customers to order
- When an order is placed for food items, some specific items are marked as ‘Blocked’ to prevent re-order of the same inventory item
- When the food item is marked as fulfilled by the Driver from the EasyRide ‘Driver’ App, its state changes to ‘Order Fulfilled’ and this is the final or terminal state of a food item in inventory
Notice that an Entity State Flow-type Data Flow Diagram is agnostic of the type of the Products interacting with each other or the system of operation the logic is running inside of. Entity State diagrams represent the business logic concerning one specific entity and all the logic or Products and applications from which input can change the specific state of the entity.
You should use the Entity State diagrams for use cases where you’re introducing a new flow into your system or new states into an existing Entity that needs to be extended.
Third-Party Integration Data Flow Diagram
Third-Party Integration type Data Flow Diagram is a diagram used to illustrate to your engineering team the integration with another Product or Application whose services you may be using for some value add to your Product flow or for your users.
This Data Flow Diagram usually has the ‘Client’ and ‘Server’ side of two entities that interact with each other (usually server to server) that you choose to integrate into your product which provides some value that’s hard to build stand-alone.
Let’s take an example to understand the Third Party Integration-type Data Flow Diagram —
Let’s assume that for your Driver App, you want a self-service flow for onboarding new drivers to your ecosystem of EasyRide Product Stack. To enable a self-service signup flow, you’d need to do an on-the-spot KYC for each driver being onboarded. To do this KYC, let’s assume that you tie up with another organization ‘EasyKYC’ through their APIs to do a real-time KYC for all drivers.
- EasyKYC takes a Photo ID number (Driving License/Social Security/Permanent Account Number) and checks the same in the database for any existence
- It then asks for a live photograph of the user, checks if the photograph has been taken live and contains a human being or not
- Then it proceeds to check in the database if the photo taken live matches the photo in the Photo ID number provided by the user
Let’s briefly sketch the Data Flow Diagram for this flow —
Let’s discuss this Third-Party Integration-type Data Flow Diagram in a little more detail below -
- The user begins the onboarding journey and is asked to provide a Photo ID proof number that would be used for verification in the National ID database that EasyKYC has access to. This has been represented by parallelograms in the diagram.
- If there’s a match for this number, the user can proceed to the next step of clicking a selfie. If the provided Photo ID number doesn’t exist, the user is asked to retry with another Photo ID number.
- After clicking and uploading a selfie, the selfie is first checked for liveliness. The liveliness check defined whether a photograph has been clicked in real-time and if it contains a human being or not by providing scores for both. If the liveliness check is not passed, an error is flagged to the user and a retry is triggered. If the check is passed, then the next check is triggered to match the clicked selfie with the selfie provided in the Photo ID number’s photograph record
- If the selfie is successfully matched, the KYC is considered as passed and the signup is successful. If the selfie doesn’t match, an error is flagged to the user. In this case, the user can either reach out to the Crew team of EasyRide to do a manual KYC or retrigger the KYC process with another Photo ID number
Please note that there are 3 API integrations required as can be surmised from the diagram.
- The first is to check for the existence of the Photo ID number provided by the user
- The second is to check if the selfie clicked by the user is live or not
- The third is to check if the selfie provided by the user matches the Photo ID number’s associated photograph of the user
You should use the Third-Party Integration-type Data Flow Diagrams to indicate to your engineering team the entire workflow of integration with the Third-Party and their specific services being used at specific steps in the Product flow
Summary
Data Flow Diagrams are fantastic at encapsulating Product Requirements since they help in conveying the summary of a Product One-Pager or a Product Requirement Document to your Design and Engineering Team stakeholders.
Data Flow Diagrams also help Product Managers in clarifying their own Product Workflow in their minds and help them uncover corner cases and scenarios that they might have missed out on when just envisioning a Product flow in their mind.
In the next section, we’ll discuss how to use the Product One-Pager and Data Flow Diagrams discussed in this part and the previous one to write an exhaustive Product Requirement Document.
Do share your feedback with me at kshitj.saxena@gmail.com or connect with me on LinkedIn
