Recently, I've come to discover the power and beauty of using FigJam as a way of defining user stories. For whatever reason, I hadn't spent a ton of time diagramming user flows like this, and instead have relied on drafting wireframes to get ideas down on paper.

But, with some practice, I can rapidly create an overarching understanding of the business logic and user actions through a flow chart, and ultimately map features against that flow. There are some clear benefits, and I'd like to share my current methods for building these out.

Here's an example of one user epic we defined:

First, define your key, so that you know what type of information each card stands for. FigJam's template for "Flow Charts" provides you with this key:

I adapted these, however, to this:

1. Pages, UI Components - White
2. User Actions - Purple
3. External API and Validations - Blue Diamonds
4. Error States - Red-Orange
5. Business-side Processes - Dark Yellow

That last one on "business-side processes" might not be necessary for your particular case, but was enough of an edge case that I left it as its own color—and depending on the scope of your diagram, you might need a few outlier "miscellaneous" cards that occur occasionally.

Additionally, there are a few sticky notes with lists that provide additional details in close proximity to the card affected. These are things such as:

1. List of form fields on that page.
2. Developer "gotchas" to watch out for, or other potential complexities.
3. User Experience considerations, like user safety concerns or how you might contextually provide information to the user.
4. Error handling and field validations.

These stickies can also be a nice way to keep track of notes or feedback that you collect along the way. There's also the comment tool where contributors can asynchronously provide feedback on their own.

Considerations for mapping at a less detailed level

Sometimes you don't really need to spend a ton of time diving into each and every detail because that would make the flow super large, or you simply don't have enough time.

In this case, it can be useful to batch a series of user actions that can be taken at this level—in this example, we outline the actions a user should be able to take on a dashboard.

Right now, we're exploring some new features that another client is interested in exploring around accounts. While we will conduct some discovery to identify the "why's" behind those features by conducting some interviews, we can also use this high-level flow diagram to understand where those features might actually fit, and the impacts that these changes might cause to the rest of the system.

I'm excited to keep using this tool to create better documentation, keep people on the same page when discussing features or tooling, and to continue along this journey and discover how this approach might affect developer experience as well.