Systems & Workflow design

My background is in Product Design, but much of my work has never been about interfaces alone. I work where people, software, and business rules have become difficult to reconcile, helping teams understand how the system actually works and determine what needs to change.

I have spent my career working across enterprise software, fintech, B2B products, legacy systems, and AI-enabled workflows. Over time, the work has moved further upstream: understanding the logic behind a product, the decisions embedded in a workflow, and the conditions that determine how people actually use the system.

Today, I focus on complex workflows where the work has become difficult to understand, operate, or change. That can mean working inside a product, across several systems, or at the boundary between product and operations.

View Full resume
DISCUSS A PROJECT

// SCALE CHANGES THE WORK

Some of my most important design lessons came from working on U.S. Online Banking at TD Bank, where the system served more than 10 million active users.

At that scale, the difficult questions were rarely about individual screens. The system had to behave correctly when permissions changed, information was incomplete, an integration failed, or a user moved into a state the original flow had not anticipated.

The interface made those problems visible, but it did not create them. The harder work was understanding the rules underneath the experience and getting multiple teams to agree on how the system should behave.

That experience changed how I think about design. The interface is one expression of a larger system, and many of the most consequential design decisions happen before anyone opens Figma.

// FROM PRODUCT DESIGN TO SYSTEMS WORK

The same problem kept appearing in different forms. Sometimes it was an ambiguous product requirement. Sometimes it was a legacy workflow that no longer matched the business. Sometimes it was a process spread across several teams and systems, with each group holding only part of the picture.

The surface changed, but the underlying problem was often the same: people were working inside a system whose logic had become difficult to see.

That pattern has shaped how I work. Product Design taught me to look closely at how people interact with systems. Business analysis and transformation work taught me to look at the operation around those systems. My MBA gave me another way to understand what changes to those systems mean for the business.

// HOW I APPROACH COMPLEXITY

I start with the work itself. Before trying to improve a workflow, I want to understand how it actually operates, where the logic has become implicit, and what people are doing to compensate for it.

[01]
Understand the System
Start with how the work actually happens, not how the process is supposed to work on paper.
[02]
Make the Logic Visible
Surface the rules, decisions, dependencies, and assumptions that people have been carrying implicitly.
[03]
Find Where Work Breaks
Identify where the workflow stalls, repeats itself, depends on workarounds, or asks people to compensate for the system.
[04]
Define the Change
Determine what needs to change for the work to function better, and make that change concrete enough for the team to use.

Complex workflows rarely become difficult because people do not know how to do the work. They become difficult when the system people are actually operating is different from the one the organization thinks it has.

[01] Workarounds become part of the process without anyone formally deciding that they should.
[02] Exceptions are handled through memory and judgment instead of an explicit rule.
[03] Important decisions happen outside the workflow that is supposed to govern them.
[04] Responsibility sits with one team while the authority to change the outcome sits somewhere else.
// The System People Actually Use
Declared
What the organization says should happen.
Learned
What people have learned to do when the formal process does not fit the work.
Designed
What the workflow should make easier to happen.
The gap is where the useful design work begins.

// MAKING COMPLEX WORK LEGIBLE

// When AI Enters the Workflow
01
Implicit Rules
People rely on judgment to fill in what the formal process does not define.
02
Automated Execution
Software or AI begins executing decisions that were previously absorbed by people.
03
Amplified Consequence
Ambiguity that was once handled case by case can now reproduce at scale.

AI lowers the cost of executing a workflow without necessarily improving the workflow itself.

On a recent enterprise voice-agent project, the technology was functioning, but the team could not reliably determine whether the agent was behaving correctly without resolving business decisions embedded in the underlying intake process. People had been making many of those decisions informally for years. The AI simply made the ambiguity executable.

That experience reinforced something I have seen across complex systems: automation can expose weaknesses that people have learned to compensate for. Before deciding what to automate, it is often more important to understand what the workflow is actually asking people to do.

Read the full field note → AI Scales the Organization You Actually Have

// AI CHANGES THE COST OF BAD WORKFLOWS

//  The Right Fit

I’m most useful when a workflow has become difficult to understand because it crosses teams, systems, or business rules.

The problem may appear in a product, an implementation process, an internal tool, or an operational workflow. The common condition is that the people involved can see the friction, but no one has a complete view of the system producing it.

That is where I can help: making the workflow legible, finding where the system has accumulated unnecessary complexity, and helping the team determine what should change.

//  START A CONVERSATION

Working through a complex workflow?

Tell me what has become difficult to manage, and we can determine whether a focused engagement makes sense.

Discuss a project →