With each phase of Blueprint Agile, we gain more and more confidence in the product we’re building. The ERB laid the foundation, defining the core entities and their relationships to create a structured data model. The IAB then translated this into a navigable structure, outlining the main screens and primary user paths. Now, with the user flowchart, we add a final layer of complexity. 

If the IAB communicates which pages should exist in your application, a flowchart communicates what is on those pages, bringing every user action, interaction, and decision point into focus. It’s the true living document that aligns your design and development teams, enables accurate scoping, serves as the planning guide for implementation, and provides a clear understanding of the project’s effort. Well, clear enough. As with previous phases of the Blueprint Agile process, we’re only shooting for an 80% confidence level before we move on to implementation. 

There are five things to accomplish when creating a flowchart:

1. Clarify the business case and use cases of each screen (what makes a screen important to the app and the user)
2. Determine the features and actions for each screen (what the user can see and do)
3. Define the states (what things will happen when certain conditions are met)
4. Establish entry and exit points (where the user journey begins and concludes)

When all is said and done, your user flowchart should contain a granular level of detail, calling out every screen, every condition of a screen, and everything the user can see or do on a screen. Your flowchart should anticipate user needs, minimize assumptions, and guide your team through a clear, structured user journey—ensuring your product’s functionality and user experience work seamlessly together.

In terms of document size, your flowchart will by far be the largest asset you create during the discovery phase in the Blueprint Agile process. In fact, I’ve had projects so large that it required several Figjam files (but don’t worry, that’s the exception and not the rule).

In this chapter, we’ll go step-by-step through the process of building a comprehensive flowchart that captures every screen, interaction, and condition within your app. With this document—along with the ERB and IAB—you’ll have everything your design and development teams will need to begin implementation for your product. 

Why a Flowchart? 

So far, I’ve only explained what a flowchart does, but what exactly is a user flowchart? You may have worked with a product manager or UX designer in the past and received a flowchart. Forget you ever saw it; it likely wasn’t similar to what I’m about to describe. The flowchart you might have seen before may have communicated paths a user could take through an application, but it probably didn’t communicate the granular details of what the user was able to experience throughout that journey.

For me, a user flowchart should communicate several important things:

1. The journey of a user from Authentication to Account Settings
2. The features on each screen in the application
3. The states and conditions a user might experience in the application

It communicates the requirements of the application as much as it communicates the paths the user can take to experience those requirements. Essentially, your user flowchart will serve as both a user journey and wireframe.

Let’s talk about wireframes for a moment. If you’re unfamiliar with wireframes, they’re usually grayscale screens that use block-like shapes to communicate ideas for how a page in an application should look. While they’re useful in the implementation phase, particularly during 60% reviews (which we’ll cover in Chapter 5), I don’t rely on them much at this point in the discovery phase. For this process, wireframes are an expensive vehicle that oversteps its boundary in an attempt to convey the requirements of a feature.

Wireframes can be inefficient in product discovery for several reasons:

• They’re too prescriptive: Wireframes have an opinion about the design. The author of the wireframe started with a blank canvas, and eventually blocked in areas for the navigation, the actions on screen, the inputs, the content, etc. However, the designer only needs to know the flow and the function of a screen; the overall design and composition should be up to them. Designers will do a much better job of researching the right design patterns and implementing the functionality in a way that will surprise and delight users.
• They’re too redundant: A wireframe has to duplicate itself for every state of a feature. For example, if you are planning an application that displays different inputs when a user experiences different statuses, you would need to create a different wireframe of a screen for each status. If a global component on the page needs to change, you find yourself needing to make this same change countless times for every page. 
• They’re too narrow in scope: A wireframe cannot communicate the birds-eye view of your application—their scope is a single screen at a time. Because of this, they do not stop us from making poor decisions about how the features interact with each other. 

Wireframes communicate the idea of a feature. Flowcharts do too, but without being prescriptive of the design. 

Wireframes communicate the states of a feature. Flowcharts do too, but without the bloat and redundancy. 

Wireframes communicate the scope of a feature. Flowcharts do too, but they also communicate how the feature fits within the wider scope of the application.

My point here is this: flowcharts are, overall, a better vehicle for capturing requirements before starting implementation in design and development.

So, what is a flowchart? It’s a series of shapes that demonstrate the screens the user will experience, the order in which the user might experience the screens, the states of each screen, and the things the user will be able to see and do when they interact with that screen. They are granular like wireframes and high-level like user journeys.

Getting Ready

Unlike creating the ERB or IAB, creating a user flowchart isn’t something you can usually do in an afternoon. Don’t be shocked if it takes two to three sessions to get the job done. Of course, you and your team could hunker down and get it knocked out in a long marathon session—complete with pizza and beer—if you’re focused and committed.

To make this undertaking as easy as possible, get prepared:

Use Your Tools 

Before you get started, open up a new page in Figjam (or whatever whiteboard tool you’re using), and have your IAB handy for reference. Your flowchart will take inspiration directly from the IAB, so you’ll need to refer to it frequently to make sure you aren’t forgetting to sketch out any screens.

Just Be Detailed Enough

While your flowchart will go into a lot of detail regarding what can and cannot happen on each page of your app, there are a few important aspects of design we’ll leave for the implementation phase. As you work, you and your team do not need to concern yourselves with these three things: 

• Copy. This includes copy such as the header text, description text or any marketing language.
• Layout. The flowchart isn’t necessarily concerned with where a feature may be placed on a page. Features can be logically grouped together, but they do not need to be explicitly stated (i.e. “the search bar goes above the page title.”). 
• Error Messages or Validation. Unless there are specific flows that need to be called out where the user might experience some unique features, the flowchart doesn’t need to be concerned with things such as form validation.

Follow a System

When creating a user flowchart, I like to create a shape system to keep the different components organized. It’s nothing eccentric; I just use the default shapes that come with Figjam:

• Lined Rectangles: These shapes represent a screen, which might be a page, modal or email. When I use a lined rectangle, I usually label them as such (i.e. Page / Login, Email / Reset Password). These shapes connect to things that go on a page, like rounded-corner rectangles, rectangles, and diamonds.
• Rectangles: These represent the things on a screen. These things could be an input, such as a dropdown or a search field. It could also be a list of things, such as customers. I usually label these things as such (i.e. Input / Search). 
• Rounded-corner Rectangles: These shapes represent a condition, such as “status is approved”. If the condition is true, the element below it would display on screen. I usually write shorthand javascript in these shapes. For example, “status === approved” or “status !=== approved”. 
• Diamonds: These shapes represent an action the user will take, such as submitting a form. You can usually equate diamonds with buttons on a screen.
• Circles: These shapes represent endpoints in the flow or otherwise hyperlinks to different parts of the flow. A circle will usually be preceded by a diamond. 

The system you employ on your flowchart doesn’t need to be the same as mine. It should account for these five components, though, and it needs to be consistent and understood by everybody participating in flowchart creation.

Go Left to Right, Top to Bottom

When creating flowcharts, I always start at the top left and move down to the bottom right. For example, in most applications me or my team have modeled, you’ll find Authentication in the top left and Account Settings in the bottom right. Everything in between captures the interesting work that happens throughout the user journey. I typically begin with authentication requirements because these patterns are usually quite similar from project to project. Once the authentication flow is mapped out, I continue to follow the path established in the IAB, building out the rest of the user flow from there. 

The Process

I’ve distilled the user flowcharting process down into these three steps: 

Step 1: Define the Business Case and Key Use Cases

Before we can get started on our flowchart, we must determine the core purpose, or business case, of each page identified in the IAB for the application. From there, we will be able to identify and prioritize the use cases that will guide the design and functionality of each page.  

Step 2: Determine Features and Elements

With a clear understanding of the business case and use cases, we next identify the specific features needed to support them. This includes gathering design references for inspiration, detailing each feature necessary for every use case, and breaking these down into visual elements that will guide the design.

Step 3: Map the Flow and Connect Pages

The final step is to create a cohesive flow across the application. We’ll map out user journeys within individual pages, account for conditional elements, and connect pages to establish a seamless journey. We’ll finish up with a thorough review of the flow, ensuring the contents of the flowchart are laid out logically and take the user where they need to go. 

Step 1: Define the Business Case and Key Use Cases

Before you start arranging shapes and connecting lines, it’s important to step back and clarify what you’re building and why. To construct a flowchart that truly satisfies your goals, you need to ground it in your product’s business purpose and identify the primary ways users will interact with it. A well-defined business case and prioritized use cases for each screen you defined in your IAB ensures your product aligns with both your business’s goals and the needs of the end user.

In this pre-flowcharting step, we’ll first define the core problems each screen needs to address. Then, we’ll outline specific user interactions that support the solutions to these problems. Finally, we’ll prioritize the use cases, helping you focus on delivering a user experience that meets your users’ expectations.

1.1. Identify the Business Case

Let’s start by taking a closer look at the purpose of each page within your application. Each page in your IAB—and ultimately, your flowchart—exists to serve a specific business case, which ties back to the core entities you identified in Chapter 2. For instance, if you have Contact List and Details pages, it’s because you have a “Contact” entity that needs to be managed in the app. 

Your business case for a page is essentially the reason it should exist. If your product includes a Contact List view, the business case associated with it might be “our customers need to manage information for all of their contacts in our software”. Each business case will outline the value and purpose of that screen within your product and ensure that the development, design, and user flows are all aligned with achieving that purpose.

Let’s try a few examples. 

Application	Entity	Screen(s)	Business Case
CRM	Lead	Lead List; Lead Details	Streamline lead management to optimize the sales pipeline.
E-Commerce	Cart	Shopping Cart	Allow users to stage, manage and review their order before checkout.
Project Management	Task	Task List; Task Details	Enable detailed tracking of task assignments and status updates.
Learning Management	Course	Course List; Course Details	Provide structured learning materials and assessments.

Once you’ve reoriented yourself around the business case for each screen, you’ll then be able to break it down further by identifying the specific use cases a page must support. 

1.2. Determine Use Cases

Once you’ve identified your core business cases for each screen, the next step is to determine the use cases. A use case is a specific action or series of actions a user wants to perform within your application to achieve a goal. Defining these use cases helps clarify how users will interact with each page in your app, outlining the paths they’ll take and the features they’ll need along the way.

If you aren’t sure which use cases you should consider for a screen in your flowchart, I’d encourage you to refer back to your business case. Ask yourself: why did the user arrive on this page, and what are they trying to accomplish? 

To help develop your use cases, a good practice you can use is “I want… so that” statements. Creating these statements is a simple way of stepping into a user persona’s shoes and asking what they want to do on-page and what they want to achieve.

Let’s try this with the business case: Users need to independently manage their subscription without support. This business case is related to a subscription entity in the ERB, which is related to a Billing page in your IAB. When the user arrives on your Billing page, what do they want to do?

• I want to see all available subscription tiers… so that I can select the plan I want to upgrade to.
• I want to see a comparison of the subscription tiers… so that I can make an informed decision when I upgrade.
• I want to see a list of my previous invoices… so that I truly understand my subscription and my billing history.
• I want to make a selection and checkout… so that I can complete my subscription upgrade.

Any given screen in your application will have many use cases. A user might have wanted to upgrade their subscription, or they might have wanted to downgrade or cancel instead. Or perhaps they need to download their previous invoices or update their payment method.

Be sure to explore a range of scenarios to capture both common and edge cases, ensuring your flowchart addresses typical user goals and any potential variations or detours. You can put yourself in the shoes of different user personas, as well, asking what actions they might want to take or what obstacles they could encounter. Consider potential errors—like what should happen if a user imports a list of contacts with errors that must be resolved—alternative paths, and unusual conditions, such as if a user has limited permissions. 

You won’t think of every possible use case when creating your flowchart, and you shouldn’t be trying to. While you want to brainstorm as many as possible to provide a solid foundation for your flowcharting process, attempting to define all use cases in advance can lead to building the wrong thing and wasting time on unnecessary details. My advice is to cover the essentials while avoiding too many assumptions, so you can ask for user feedback as early as possible, keeping your project aligned with the real needs of real users.

1.3. Prioritize Use Cases

Not every use case deserves to be given the same amount of consideration in your flowchart. Some are critical to the overall business case of a page, while others can be deferred for later software releases. So, before you start determining the features required in your flowchart, you should work with your team to prioritize the use cases you’ve brainstormed. 

Begin by asking yourself which use cases are essential for users to achieve the core goals of your application. Consider each use case in relation to its impact on user experience and its alignment with a page’s primary business case. For example, if the main purpose of a screen is to allow users to manage their subscriptions, then use cases like “view subscription options” and “upgrade plan” might take precedence over use cases like “download previous invoices.” 

That doesn’t mean you shouldn’t consider lower-priority use cases like “view and download past invoices,” it just isn’t as essential to the Billing page as say, managing an active subscription. After discussing with your team, you may decide that giving users the ability to view and download past invoices can be shelved until after you’ve released your minimal viable product, or MVP. 

An MVP is the very first iteration of your product idea that will make it into the wild. For now, it just needs to have the minimum features required to validate the product idea, gather user feedback, and most importantly, start making money.

If you’re unsure which use cases should be addressed, assign each one a priority level: 1 (low priority), 2 (medium priority), or 3 (high priority). 

3. High Priority: These are the use cases that need to be addressed in order to generate new business or reduce churn in your current target market.
4. Medium Priority:  These are use cases that enhance the quality of life for your users. Addressing medium-priority use cases will prevent some cohort of your users from churning.
5. Low Priority: Developing features for these use cases may add depth or flexibility to the product and enable you to expand into different or larger markets. 

If your product isn’t an MVP, you might very well order those priorities differently. Regardless, the goal in prioritizing use cases is to spotlight the most important features and interactions so you can create a focused, effective user journey. It clarifies which features to focus on when flowcharting each screen, maintains alignment with your core objectives, and keeps your product vision organized and intentional. 

Step 2: Determine Features and Elements

By first identifying and prioritizing the use cases for a page, it will be much easier to determine the features and elements needed to support those use cases. Elements are simply components or sections on a page—such as tables, charts, forms, buttons, or tabs—that guide and facilitate user interaction. Determining the right features and elements involves transforming user needs into concrete components, shaping each page to fulfill its intended purpose. 

Converting your use cases into definitive features and page elements bridges the gap between broad user journeys and specific design and development requirements, ensuring that every feature has a clear reason for being there. You’ll be breaking down each use case further, listing the features needed to fulfill each use case and translating these features into actions and elements for your flowchart. By defining the functionality of each page, you set the stage for a smooth, intuitive user experience, grounded in both user needs and business goals.

2.1. Research Design References

Like everything in engineering, if you’re being creative, you’re probably doing it wrong. The odds are good that you haven’t thought of any use cases that other teams haven’t attempted to address in the past. There are likely many other software companies out there that have tried to solve the same problems you and your team is currently grappling with. This is great news for you, because you can learn a lot from researching these other products. 

Examining similar applications or design patterns can provide insight into effective layouts, user interactions, and visual elements that align with your own goals. How have others already thought through your problem and what can you learn from them? 

Design references also serve as inspiration, helping you identify established solutions to common use cases and visual cues for communicating functionality. Remember the goal when building software isn’t to design a user experience that feels foreign to the user—you want them to feel like they’ve used it before. That means utilizing the most common design patterns from other applications, and in some cases, ideating on how to improve upon them. 

To make the most of your research, focus on design references that reflect the key use cases you’ve already prioritized. For example, if one of your main goals is a smooth subscription management experience, look at SaaS applications with effective billing and subscription pages. Take note of how they display key actions, organize billing information, and handle complex tasks like subscription changes or cancellations. 

The common pattern is usually the best pattern. The more examples you evaluate, the more you’ll notice similarities, such as how they display subscription tiers or manage payment method information. You’ll likely want to incorporate these common patterns into your own product. Not only are they what the user will be most accustomed to, they are typically what has been found to work the best. Why waste time testing out different UX approaches when you can make use of what countless other applications have already revealed for you? 

Your software will likely also have less common use cases in which there isn’t a consensus on the best path forward. Even in these instances, you can still learn a lot from researching design references, even if the lesson is what not to do. As you research, look at these design elements with a critical eye: 

• Navigation Patterns: Is it easy to navigate to the information a user wants most, or is it buried several pages deep in the software? 
• Interactive elements: Are on-page user interfaces, such as toggles, dropdown menus, and sliders intuitive and useful for users? Is this method the best way to complete a given action? 
• Responsiveness: How well does the design adapt across different devices and screen sizes?
• Information Organization: Can you find information where you expect it to be, or is it in seemingly random places?
• Feature Usefulness: Are there features that don’t seem to have a clear purpose, such as the ability to upload a profile picture nobody will ever see? 
• Feedback for User Actions: When users interact with the interface, do they receive immediate, clear feedback (such as animations, loading indicators, or confirmation messages) that confirms their action?
• Error Prevention and Recovery: Are potential user errors anticipated and prevented through clear instructions, constraints, or validations?
• Ease of Completing Key Actions: For core tasks like saving progress, checking out, or submitting forms, is the process streamlined?
• Overall User Journey: Does the user journey make sense? Is it easy to keep yourself oriented throughout? 

Even if you aren’t an expert in UX design, you’ll usually be able to tell rather quickly if you’re enjoying using an app or not. It’s like a gut feeling. After you learn to listen to your first impression of a platform, you just need to dig into this feeling and identify the reason behind it. Taking the time to research design references can also help you spot potential challenges early and guide your team’s approach to specific UI patterns. Once you’ve gathered your design references, you can proceed to list out the specific features that will fulfill each of your use cases. 

2.2. List Features Needed to Fulfill Each Use Case

After you do some research into the different approaches other products take to solve similar use cases, you should have a pretty good idea of what features you’ll need to fulfill the use cases you’re focusing on. Features are the specific functionalities that allow users to interact with the software and achieve their goals. At this stage, your goal is to bridge the gap between high-level use cases and the tangible elements that will bring those use cases to life.

Tie Features to Use Cases

Every feature you identify should map directly to one or more use cases. That way, you make sure all features have a clear purpose and directly contribute to the user’s journey or the product’s business goals.

For instance, if the use case is “I want to upgrade my subscription… so that I can access additional features,” the required features might include:

• A pricing comparison table to display subscription tiers
• An upgrade action that initiates the checkout process
• A checkout page or modal where the user can input payment details and submit the upgrade action. 

Consider User Actions and Page Elements

When listing features, think about both actions (what the user does) and elements (what the user interacts with). For example, on a Billing page, actions could include: upgrade your subscription, downgrade your subscription (if you’re on a paid plan), cancel your subscription (if you’re on a paid plan), download invoice, or update payment information. Elements, on the other hand, could be things like: a subscription tier table, the individual subscription tier items included in the table, a management payment information modal, and the input fields in the modal. 

A Few Pointers

1. As you’re getting the hang of all the actions and elements that need to be included on a screen in your flowchart, start by listing the features that should be included on a screen, and then list all of the actions and elements you think you’ll need alongside each feature. 
2. A single feature may be important for many use cases, and a use case will require one or many features to be addressed.
3. Feature identification isn’t a solo effort, especially if you aren’t the SME. If all of your team members have done their own research into design references, everyone should have unique insights to offer. 

2.3. Translate Features into Granular Shapes

With your features identified—along with the actions and elements those features require—the next step is to translate them into the building blocks of your flowchart. At this stage, you’re shifting from high-level ideas to specific, actionable components that represent the features on each page. 

Remember the shapes I mentioned earlier?

Using these five shapes, you’ll be able to communicate the features you need on each screen you laid out in your IAB. To be clear, you don’t need to use these five specific shapes. You just need to use five distinct shapes, and you need to use them consistently. 

Breaking Features into Their Granular Components

First, ensure that all elements and actions associated with your Billing page are organized beneath a lined rectangle labeled “Page / Billing.” This visually ties all components to their parent screen, making it easy for your team to understand how everything fits together. Also, be sure to place all elements for the screen below and to the right of the corresponding page rectangle.

Let’s start by breaking down a pricing comparison table into granular shapes. You should think of tables as lists composed of individual list items. When flowcharting, represent the pricing comparison table as a list element—represented with a rectangle—and then break it into list item elements—which will also be represented with a rectangle. Each list item should include the following components: the subscription tier’s name, the price, and a description of benefits. You can condense this content into a single rectangle. Each pricing tier should also have a call-to-action (CTA). What the CTA should be is dependent on a few conditions, so for now, I’ll just use a rectangle to represent this element, and we will break down the actions later in step 3.2. 

So far, your flowchart for this feature should look like this: 

Let’s try another potential feature you may decide to include on your Billing page: a Billing History Table. Again, think of the table itself as a list element and then each list item as a separate element. For each row, what information should be included? It probably needs a transaction name or ID for the invoice, the amount, the date the invoice was issued, and a status (such as Pending, Failed, or Completed). 

Your users will also need the ability to download their invoices for their own records. You may want to give them the ability to download all invoices to date at once and the ability to download individual invoices. The ability to download all invoices should happen at the list level, while the ability to download a single invoice should occur at the list item level. Remember, downloading an invoice is an action, and it should be represented with a diamond. 

Start mapping out the elements and actions you think each feature will need. Don’t worry about getting everything perfect, yet; this is just about figuring out the building blocks each feature will need. 

Step 3: Map the Flow and Connect Pages

Finally, after all the work you’ve done defining use cases, conducting research, and determining the features and elements users will interact with on each screen, it’s time to bring everything together. This step transforms your flowchart into a fully connected, cohesive map of your application’s user experience.

By the end of this step, you’ll have clearly mapped out the flow on each individual page, accounted for conditional circumstances and endpoints in the user journey, and established logical, well-organized connections between all your pages. This comprehensive flowchart will ensure your application’s navigation is seamless, intuitive, and aligned with user needs and business goals.

3.1. Map the Flow on an Individual Page

Mapping the flow on an individual page means detailing how users interact with the features and elements you’ve defined. Your goal here is to document these interactions clearly, including any conditional behaviors or alternative pathways users might encounter.

At the end of step 2, you began breaking features down into elements and actions. Now it’s time to incorporate these into their respective pages. Continuing to use the Billing page as an example, your flowchart should look like this right now: 

Incorporate Conditional Elements

To finish mapping the flow, it’s critical to account for conditional elements—those that appear or behave differently based on specific criteria. For example, the Pricing Plan Table contains CTAs (calls-to-action) that change depending on the user’s subscription status. The CTA that displays is dependent on two conditions: 

• Is the user looking at their current plan?
• Is the plan free or paid?

When dealing with complex conditional scenarios, it can be useful to write out all of the outcomes before you map them on your flowchart. 

Given the two conditions we have for the CTA, here are four possible scenarios: 

• The user is looking at their current plan and it is the free plan.
• The user is looking at their current plan and it is a paid plan. 
• The user is not looking at their current plan and it is the free plan.
• The user is not looking at their current plan and it is a paid plan. 

Now, you just need to determine the outcome for each scenario:

Scenario	CTA
The user is looking at their current plan and it is the free plan.	(Read Only) Current Plan
The user is looking at their current plan and it is a paid plan.	Cancel Subscription
The user is not looking at their current plan and it is the free plan.	Subscribe
The user is not looking at their current plan and it is a paid plan.	Downgrade (if it is lower tier than their current tier Upgrade (if it is a higher tier than their current tier)

How do you go about representing all possible outcomes in your flowchart for the design and development team? I use the rounded rectangle shape to denote a specific condition, and I use the spanglish equivalent to javascript to notate the condition itself. For instance, to indicate the condition, “plan is current plan”, I write “Sku === Current Sku” in the condition shape. To indicate that “plan is not current plan”, I write “Sku !=== Current Sku”. 

In order to include all the scenarios laid out above, we need another level of conditions, though. Here, I am trying to convey that either the “current plan is free” or the “current plan is not free”. I notate these conditions by saying either “Current Sku === Free” or “Current !=== Free”. 

Once I’ve called out the conditions for which each CTA should display, then I can finally include my actions. In my flowchart it looks like this:

There is also another feature on my Billing page that is only accessible if a user is on a paid plan, and that is payment method management. Just like on the pricing plan table, we need to preempt this feature on the flowchart with the conditional statement, “Current Sku !=== Free”. 

Pay Off the Actions

What happens when a user decides to take an action? Rarely will an action diamond be the end of a path. Your flowchart needs to spell out what happens next and where the user goes from there. 

Let’s look at the CTAs on the pricing plan table. Three of the four outcomes mapped out previously led to an action a user can take. Now you need to figure out where that action takes them. 

When “Cancel Subscription” is the CTA, selecting it should show a cancellation modal. This modal is a lot like the deletion modal you’ll encounter in your application anytime a user needs to delete an instance of an entity. It only needs to include a message asking the user if they’re sure they want to cancel their subscription—which you do not need to include copy for at this time—along with the option to Confirm or Cancel. Regardless of the button they select, the flow should take the user back to the Billing page, which I note with an endpoint circle. 

If the user decides to “Subscribe”, “Upgrade”, or “Downgrade”, they should be taken through the checkout flow. This can be done in either a page or a modal, though the shape used, the lined rectangle, will be the same regardless of what you choose. 

On the Checkout page, you need to lay out the information that should be found there. This could include inputs for the user’s organizational information (name, company, address, etc.), inputs for payment details, and a summary of the transaction for the user to review prioring to submission. You may also decide to give users the option to be billed annually or monthly. Your Checkout page may contain slightly different information, but this example should give you an idea of how detailed you need to be. 

Finally, you need to include a “Subscribe” action. It’s also wise to include a confirmation modal for users when they’re making important decisions. This ensures they do only what they mean to do. When you put it all together, your Checkout flow will look something like this:

The other action left to pay off is “Update Payment Method”. After completing the checkout flow, this modal is pretty easy to complete. Just like on the Checkout Page, I’ll include a list of payment methods, though I don’t need to detail the options a second time. The modal will look like this.

Put It All Together And What Do You Get?

Alright, we’ve gone through each part of the Billing page, breaking features down into their granular components. After all of that work, our Billing page has been fully fleshed out. 

Now, you just need to do the same thing we just did together for all of your other pages. Easy, right? Okay, yes, while it does feel like a lot of work, I promise you that it gets easier as you go. You also have the benefit of reusing common patterns after you map it out the first time.

3.2. Connect Your Pages

Once you’ve mapped out the flow for all individual pages, it’s time to connect those pages together and make sure your flowchart is organized. This is where your application’s overall user journey takes shape, showing how users move from one screen to another as they interact with your product from start to finish. 

Remember to begin with the authentication screens (if you have them), as this is the most common entry point into an application for users. Typically, most of the screens should connect to the dashboard (or whatever you consider to be your “home” screen in the app). There may be some screens you wouldn’t be able to navigate to from your dashboard screen, though. If your software sends out emails, and you’ve flowcharted the elements of these emails, they would be an example of screens that exist outside of the typical user flow. 

3.3. Test for Logical Flow and Refine

Now that you have your flowchart all sketched out, it may be smart to take a short break from it. When you return with fresh eyes, review each page’s connections and ensure the logic aligns with user expectations.

As you go, ask questions like: 

• Is the user able to complete their goals on this page? 
• Does each action have a clear next step or end point?
• Does the sequence of actions follow a natural progression?
• Do I know what happens when a user reaches an endpoint? 

Moving through the flow as if you were a user is the best way to catch silly mistakes and make adjustments.

You’ll be completing steps one and two for each page in your IAB, until you have a fully fleshed-out user flowchart. By the time you’re finished, this flowchart will serve as a comprehensive guide for your designers and developers, ensuring everyone is aligned on how the user will navigate your application.

With the flowchart in place, you’ve completed the heavy lifting of the discovery phase. As you move into the next phase of Blueprint Agile—Synchronized Delivery—your team will have a clear understanding of what users will see and do on each screen, how they will move through the app, and what conditions trigger different behaviors. This document will be your foundation for the implementation stage, keeping your team aligned and minimizing surprises along the way. 

Remember that flowcharts are a living document, not a fixed blueprint. It’s inevitable that you’ll need to make adjustments during implementation. After seeing the prototype, you may discover missing features or realize the user journey needs to be adjusted. As with every phase in Blueprint Agile, the goal is simply to reach 80% confidence in your project plan across your team. The flowchart serves as the aligning document before you move into implementation. Once the development phase begins, the source of truth shifts to the UX prototype (if you’re following a design-driven development approach).

It’s natural for your app to drift from the flowchart during implementation. Most of the time I update the flowchart post-implementation when a major change, like a technical limitation, forces us to reassess our plan. Otherwise, I let the drift happen, confident that the flowchart has served its purpose by preparing us to begin implementation. 

When the flowchart is complete, you’ll have all the information necessary to estimate the effort required for implementation. At Brandcave, we split discovery and implementation into two scopes of work, with discovery concluding when we have an implementation estimate. Once we hand off the ERB, IAB, and flowchart to our design team, they can produce high-fidelity prototypes that are on-budget and accurate, with minimal need for clarification. They are the best designers in the world, but they don’t have to be. The flowchart tells them everything they need to know.