Inherited diagram to design-ready flows

A client product owner shared a FigJam file mapping out their sign-up and registration process. It was thorough in its own way — every business rule and edge case documented — but it wasn't designed to design from. The logic was written for engineers, not user journeys, and it treated every person moving through the flow as the same type of user.

Before anyone could put a screen together, something had to give. I took the diagram, audited it for assumptions, and rebuilt it into a set of flows the team could actually work from. The final result was a set of flows segmented by user type, stripped of business jargon, and organized around what a person actually experiences at each step.

Starting with what we had

The team received this flow outlining the login and registration process. It combined several different use cases into this singular diagram and included both back-end processes and costumer-facing actions and screens.

Our goal was to use this diagram as the basis for user flows for singular login use cases.

Our first step was to analyze the diagram, identify technical requirements, and annotate it with questions and recommendations.

After this, we made updated the diagram by incorporating our recommendations and organizing our notes:

Finding the six user types hiding in one flow

After revising the diagram provided to us by the client, we identified several key types of users and highlighted the paths they would take to sign in or register.

Rebuilding from the user’s point of view

By identifying the paths that certain users would take to login or register, we were able to create linear user flows. This allowed us to have a simplified view of the potential experience for the users we identified.

Mapping it all in one place

Part of this exercise was anticipating the most common types of users. In order to keep track of users with different qualifications, we created a user matrix. This asset contained the users we accounted for in this exercise, and will continue to grow as the project develops.

With the flows segmented and the matrix in place, the team had a shared reference point for the first time. Design work on individual screens could begin without every decision turning into a debate about whose version of the user we were designing for.