The 7 benefits of building a UX Flow Chart before writing a line of code (free template included)

Will Little

Product people love to talk to customers and refine concepts, creatives are happy designing mockups all day, and engineers just want to ship code with increasing velocity. Even with a very small team (or a solo founder with split personality disorder), this tension leads to the chaotic mess known as #StartupLife.

Having made my fair share of tech startup messes during my career, I’ve learned that — from an operational perspective — countless hours are saved as a team by first writing out an Overview Story, then building a UI Spec, then building a UX Flow Chart before hitting the Wireframes and Mockups.

The most heated debate should happen while writing the Overview Story (i.e. a rough collection of user stories that tell the entire view-by-view experience of people using your product). The debates should then get exponentially less heated as you move on to the UI Spec, UX Flow Chart, and wireframes/mockups. However, from experience I’ve found that the flow chart is the critical piece to get right to help ship your product as fast as possible.

What is a UX Flow Chart?

In short, you’ll want to create a representation of the view-by-view experience of a user (i.e. each “node” they will come across) that also gives your engineers sufficient data to hook things up correctly and load data appropriately into your application. 

Here’s a quick example for a web application (feel free to view/clone this template I built using Google Drawings):

And here’s a close-up of the Legend so it’s easier to read:

Practically speaking, the product people can decide which nodes should be where, the creatives can design beautiful UIs for the nodes, and the engineers can decide which kind of arrows are most suitable throughout the chart. 

Then, as the creatives work on the initial wireframe images for the nodes, those images can be stored in a folder somewhere (like gDrive or Dropbox) and a link to the image can be attached to a node like so:

Feel free to hit me up on twitter if you have any questions on the template. For a more complex example, check out this post I wrote a few years ago (you’ll see how the recent version is a bit more evolved).

The Seven Benefits of a UX Flow Chart

In case you are not yet convinced it’s worth your (and your team’s) time to build one, here are seven reasons why I’ve discovered over the past 10+ years that they are tremendously helpful: 

(1) Product people can create something visual and tangible to point creatives/engineers to based on the UX research and conversations with users, focus groups, etc… It’s a powerful way to visually communicate what’s been learned (and how to tweak the product as new information becomes available).

(2) Creatives have a place where they know the engineers and product people can find the latest wireframe/mockup of any particular node, and they can see the entire scope of the product in one view to feel more confident of the UIs they are building (and, thus, build better UIs).

(3) Engineers can start making critical decisions (before writing code) about how data will flow between the API server and the front-end. This is often the time when they need to tell the creatives and product people that a new node is needed, or that node X and node Y should actually be combined, etc… 

(4) The CEO (or any executive) can, at any time, jump into the flow chart and have an accurate picture of progress through this creation stage. Often the CEO gets nervous before a prototype is built (“are people actually doing anything?!”), so the UX Flow Chart serves as that functional prototype to keep executives happy. 

(5) Sales people can use the the flow chart as a tool to sit down with potential customers and walk them through what the product will be, even before the wireframe or mockup sets are complete. 

(6) Ambiguity is cleared up when something doesn’t feel right at the prototype stage because you all totally forgot about page X (!), so quickly adding in that node on the flow chart, with the corresponding wireframe linked to it, makes it clear to all involved how this will be implemented before writing another line of code to build it. 

(7) Future features are easier to implement across the board as you get into private and public beta and users are telling you what they want. In the same way that you wrote up a story, a spec, and built the flow chart when you were initially building the product, the process of building new features becomes easier and faster to execute. 

Author’s note: this is the 20th post in a series of articles outlining a framework for startup operations that my partners and I at Prota Ventures have developed. We’ve built a web app that was featured at the #2 spot on Product Hunt last month to help founders spin up new ventures efficiently and keep stakeholders updated on progress. Check it out for free here. Finally, subscribe to my newsletter and I’ll let you know when I get new content up. Thanks!