Rebuilding a Diagram Around Real Users
Taking an inherited sign-up and registration diagram that treated every user the same, and rebuilding it into a set of focused user flows and a segmentation matrix the whole team could design from.
Role & Scope
A Verizon product team handed us a FigJam file mapping out the sign-up and registration process for the Family App. It was thorough in its own way, with every business rule and edge case documented, but it was not built to design from. The logic was written for engineers rather than user journeys, and it treated every person moving through the flow as the same type of user.
I worked on this closely with a design lead. We paired on calls to reason through the logic together, and split off to push the work forward between sessions before reconvening to work through what we had found. What follows is the shape of that shared effort, with a few moments that were mine to carry.
Together we turned that artifact into something the design team could actually work from. Over the course of the exercise we audited the diagram for assumptions, annotated it with questions and recommendations, identified the distinct types of users buried inside it, rebuilt their journeys as focused linear flows, and consolidated everything into a segmentation matrix that became the team's shared reference point. The result was not a set of screens. It was the clarity that made designing those screens possible.
Overview
- Starting With What We Had
- Auditing and Annotating
- Finding the User Types
- Rebuilding From the User's Point of View
- Mapping It All in One Place
Starting With What We Had
The team received a single diagram outlining the full login and registration process. It combined several different use cases into one sprawling flow and mixed back-end processes together with customer-facing actions and screens. Everything lived on one canvas: every decision point, every business rule, every edge case, and every system step, all sharing the same space.
The intent behind it was good, and nothing was missing. But its comprehensiveness was exactly the problem. Because it tried to show everything at once, and made no distinction between what the system does and what a person experiences, it was nearly impossible to read as a user journey. Our goal was to use this diagram as the raw material for clean, single-purpose user flows. So before anyone could put a screen together, it had to be untangled.
Auditing and Annotating
The first real work was analysis. We went through the diagram end to end, identified the technical requirements embedded in it, and annotated it directly with questions, assumptions to confirm, and recommendations. Where the logic was ambiguous, we flagged it. Where the diagram conflated a back-end process with a customer-facing step, we marked the seam. Where a decision point raised a question only the product owner could answer, we called it out in place rather than guessing at an answer.
This annotation pass is where the disambiguation actually happened. It turned a static, engineer-oriented artifact into a working conversation: a version of the diagram that made its own gaps visible and gave the cross-functional team a concrete list of things to resolve. Once those notes were reviewed and incorporated, we had a revised diagram organized around our recommendations and ready to be broken apart into individual journeys.
Finding the User Types
With the diagram clarified, the distinct users hiding inside it became visible. What had looked like one universal path was actually several different journeys layered on top of each other, each belonging to a different kind of person entering the flow with a different starting context.
The users fell into three core categories based on their relationship to the service:
Non-Verizon customers.
People with no existing relationship, entering the flow fresh and needing to be established from scratch.
Current Verizon customers without Smart Family.
People already known to Verizon but new to this particular product, carrying some account context but not all of it.
Current Verizon customers with Smart Family.
People already inside the broader product ecosystem, arriving with the most context and the fewest steps left to complete.
Within those categories, finer distinctions mattered too. Several of them turned on Individual Profiles (IP), a Verizon initiative to give customers one set of sign-in credentials across every Verizon experience, replacing the older mix of mobile number, phone number, and email logins. Whether a person already had an IP linked to their Verizon service, had no IP set up yet, or was signing in through a temporary login with no email on file each led to a different path. Account role mattered as well, since an owner or manager could set up the family where a member could not, as did age and legal consent: for a product used by families, any flow involving minors had to account for COPPA and in-app consent. Naming these types was the pivot point of the whole exercise. Once we could say precisely who was moving through the flow, and what each of them did or did not walk in with, the single tangled diagram stopped being one impossible journey and became a manageable set of specific ones.
 customer 1.png)
 customer 1.png)
Rebuilding From the User's Point of View
For each user type, we traced the path that person would actually take and rebuilt it as its own focused linear flow, moving it through a clear sequence of stages. We started from the product team's original flowchart, simplified it, removed the back-end checks so that system logic no longer sat on top of the human experience, and then layered in our design recommendations. Separating what the system does from what a person sees was the pivotal move: once the machine steps were pulled out, each flow collapsed into a clean, legible sequence of what one real person experiences, step by step. A lot of this was heads-down work: I would take a stretch of the flows on my own, then bring them back to talk through and refine together.
That staged progression became the way we presented the work back to the client, organized around the three use cases we ultimately focused on: a non-Verizon customer, a current Verizon customer without Smart Family, and a current Smart Family customer. Shown together, each one moving left to right from the raw product-team flowchart to a design-ready recommendation, the transformation was impossible to miss.
Some of these flows depended on questions the client had not yet answered. Rather than stall while we waited, we flagged each open assumption and identified the delta that its answer would create. If the Family App could not own the create-IP experience, that implied one path; if it could, another. If a given user had to provide COPPA and legal consent in-app, that added a step; if not, it did not. Working through these branches was an exercise in thoroughness rather than a second round of design: the point was to surface every way an unconfirmed assumption could resolve, so the team stayed unblocked and no eventual answer from the client would catch us unprepared.
Where there had been one diagram that tried to serve everyone and served no one clearly, there was now a set of purpose-built journeys, each one simple enough to hand to a designer and start building against. The complexity had not disappeared. It had been sorted.
Mapping It All in One Place
The final artifact tied everything together. To keep track of users with different qualifications, we built a segmentation matrix that laid out each user type against the conditions that defined it: billing and account-based role, individual profile dependencies like IP status and primary line, Family App purchase and account status, and legal requirements such as age. For each segment, the matrix also captured what was known about the person after sign-in and what information they still needed to provide.
The matrix was a living document. As the client answered our open questions, some of the scenarios we had accounted for turned out not to be needed, and the set of segments tightened to the ones that remained in scope. This is why the focused flows and the final matrix do not line up one to one: the flows covered every case we had identified, including provisional ones, while the matrix tracked what survived once the requirements settled. That narrowing was not a loose end; it was the method working as intended. The matrix became the shared reference for who we were designing for and what each of them walked in with, turning a set of individual flows into a single, queryable source of truth.
Impact & Learnings
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 finally begin without every decision turning into a debate about whose version of the user we were designing for. The ambiguity that had been blocking the work was gone, replaced by a structure everyone could point to.
This project was a reminder that not all design work produces a screen. Sometimes the most valuable thing you can deliver is clarity: a way of seeing a problem that lets everyone else move. Taking an artifact built for machines and rebuilding it around real people was, in the end, the whole job. It sharpened how I think about the space between a business requirement and a user experience, and it reinforced that untangling that space is often where a designer adds the most value, well before a single screen is drawn.
