Designing workflows that Engineering and QA can actually execute

What was breaking down

This work started with a recurring friction point: workflows were difficult to design, difficult to build, and difficult to validate.

On the surface, it appeared to be a coordination issue—designs required frequent clarification, Engineering had to interpret intent, and QA didn’t always have clear criteria for validation.

But as we looked more closely, it became clear that the issue wasn’t just in execution. The workflows didn’t have a consistent structure.

That lack of structure showed up most clearly in how completion was defined—or not defined—across workflows.

Each step in the experience—patient details, ordering provider, treatment selection—was defined slightly differently. Inputs, validation, and behavior varied from one step to another, even when the underlying patterns were similar.

Without a shared model, each new workflow had to be understood and implemented on its own terms. The result wasn’t just inefficiency—it was inconsistency.

What made this complex

The complexity wasn’t just in the interface—it was in how the workflows were structured and delivered.

Each workflow involved multiple steps, conditional logic, and dependencies across inputs. Decisions made in one step often affected what was required in later steps, with entire sections becoming relevant or irrelevant depending on earlier selections.

These patterns repeated across specialties, but without a shared structure to support them.

At the same time, the workflows had to function across multiple layers:

• Product needed clarity on requirements and behavior
• Engineering needed enough structure to build without interpretation
• QA needed clear criteria to validate against

Without alignment across those layers, small inconsistencies in how steps were defined created larger issues downstream.

Each individual step could work in isolation, but taken together, the experience lacked cohesion. That made it difficult to scale or extend workflows without reintroducing the same problems.

My role in this

I led the effort to define a structured model for how workflows should operate—aligning Product, Engineering, and QA around a consistent approach to step definition, validation, and completion.

I worked with Product and Engineering to understand how each step functioned, where decisions were made, and how those decisions affected the rest of the workflow. From there, I led the effort to introduce a consistent model for defining steps—reducing ambiguity in UX, Engineering, and QA.

The goal wasn’t just to refine individual screens, but to establish a system for consistent design, implementation, and validation across workflows.

How we approached it

Bringing structure to workflows that didn’t scale

Instead of designing individual workflows, I defined a consistent structure for how each step operates. This made it easier to define what each step was responsible for, how it connected to the broader flow, and what needed to happen before moving forward. Looking across steps side by side, common patterns began to emerge:

• Collecting structured inputs
• Validating required information
• Responding to conditional selections
• Determining when a step could be considered complete

These patterns existed across workflows but hadn’t been defined consistently.

One of the key shifts was defining what it meant for a step to be complete. Instead of relying on implicit understanding, each step was defined in terms of:

• Required inputs
• Validation rules
• System responses
• Explicit completion criteria

Instead of designing flows, I defined a consistent structure for how each step operates.

This created a clear boundary between steps and reduced ambiguity during implementation.

As the structure became clearer, it created alignment across teams. Instead of interpreting designs, Engineering could rely on defined behavior. Instead of guessing what to validate, QA had clear criteria to test against. The workflow became something the team could reason about collectively, rather than individually.

What changed

From fragmented steps to a repeatable system

The result was a shift from inconsistent, interpreted steps to a predictable, repeatable system. Before this work, each step behaved slightly differently—even when solving similar problems. With a shared structure in place, steps began to follow a consistent model:

• Inputs were grouped and structured predictably
• Validation behaved consistently
• Step completion followed clear rules

What previously required interpretation became predictable and consistent across steps.

By defining workflows at the level of behavior—not just interface—the gap between design and implementation narrowed. Engineering no longer needed to infer how a step should work, and QA could validate against clearly defined expectations.

Because the structure was consistent, patterns could be reused across specialties rather than redefined each time. This created a foundation for scalability—where new workflows could be built using established patterns instead of starting from scratch.

What this reinforced

Structure enables scale

This work reinforced that scalability doesn’t come from adding more workflows—it comes from structuring them in a way that can be reused. Without that structure, complexity increases with every new addition.

Explicit behavior leaves less room for interpretation

Many of the challenges weren’t caused by missing functionality, but by missing clarity. By defining behavior explicitly, the need for interpretation was reduced—improving both speed and reliability of delivery.

The step became the reusable unit

The most impactful change wasn’t a specific screen or flow—it was how the team approached the problem. By treating workflows as part of a larger system, rather than isolated features, it became possible to create consistency across areas that had previously been disconnected.

Consistency matters most when it repeats

Small decisions—how inputs are grouped, how validation is handled, how completion is defined—have an outsized impact when repeated across a system. By aligning on these details early, the experience becomes easier to extend, maintain, and trust. The result wasn’t just a cleaner workflow—it was a system that teams could build, validate, and extend with confidence.