Establishing patterns for Visa Design System

Visually, the old wizard didn’t match Nova’s new direction, and functionally, it only covered a narrow set of use cases. This led teams to build custom, off-system solutions which resulted in inconsistent user experiences, duplicated engineering effort, and accessibility gaps. Underneath that sat a bigger gap. Nova had strong components, but no definition of a pattern, so there was no agreed way to document something larger than a single component.

• Audit of ~8 product implementations. I catalogued what use cases each wizard served and what functionality teams needed, then mapped the findings in FigJam to spot where teams had diverged.
• Designer interviews. I followed up with calls where designers walked me through why they chose a pattern and what felt missing.
• Kickoff with senior stakeholders. Lead engineers, senior designers, and content designers who had worked on the previous wizard shared what worked, what didn’t, and what they wished they’d done differently. I sorted their questions into definition, functionality, and visual design.

Teams diverged on wizard behavior. One size wouldn’t fit. Teams needed wizards for long complex forms and constrained mobile screens. The open question was structural. The biggest question from kickoff was whether the wizard was a component or a pattern.

My first draft gave each layout a numbered walkthrough: fill in the fields, select Next, repeat, submit. The steps were nearly identical across layouts, and the criteria for choosing between them were buried in the text. Reviews with senior designers and engineers revealed that users already know how to move through a wizard. What they lacked was a way to choose the right one, so each team drew its own line between layouts. I rebuilt the guidance around a usage table that compares the three layouts side by side, with clear criteria for when to use each and when not to. A page of repeated instructions became a decision users could make in seconds.

The audit showed teams diverged most on logic: what happens when a step depends on an earlier answer, or when a user goes back and edits a response. To address this, I separated wizards into two types: fixed, where every user follows the same steps, and branching, where steps change based on user input. My first approach was to explain the difference in writing. But branching logic is about cause and effect over time, and written rules alone was hard to convey implementation. So I introduced task flows: interactive prototypes that walk through real scenarios for each type, showing exactly what happens when a user moves forward, goes back, or changes an answer that adds or removes a step. Each layout in the guidelines links to its task flow, and engineering and accessibility reviewed every flow before build. Instead of interpreting rules, teams could see the logic working and match it.

The biggest open question from kickoff was whether the wizard was a component or a pattern. Nova had no definition of a pattern, and the wizard was one of the first complex interactions in the system, so my answer would set the precedent for every pattern after it. I defined a pattern as a reusable flow built from components. Since it was made of components, I wrote separate guidelines for its component parts and for how the pattern fits into a larger flow. That produced three long guidelines and a lot of unnecessary complexity.

In a review session, I realized that users don’t care what a pattern is made of; they want to know how to use it. With three documents, they first had to work out which one to open. I redefined a pattern as components, layout guidance, and behavior rules that work together to solve a task, and condensed the documentation into two guidelines: the wizard pattern and its task flows, ordered by what a user needs first. That structure became the template for later patterns, starting with file upload.