Improving efficiency in a revenue-critical workflow without breaking the trust of users.
IMPACT
Moved complexity out of the UI and into system behaviour without losing what made the system safe.
I led the redesign of a core enterprise workflow used by sales associates during client conversations, both in-person and remote, where errors carry direct operational and financial risk.
The challenge was to introduce multi-add, a meaningful efficiency gain, without increasing cognitive load in a system users already found difficult to trust.
The result was a simpler, more resilient flow. Conversion more than doubled following release, and associates regained confidence navigating a workflow that had previously felt too fragile to rely on.
CONTEXT AND STAKES
This workflow sat at the intersection of sales velocity and operational risk.
Sales associates used this tool in real time to build and manage product collections for clients during their conversations. Every decision happened under pressure, speed mattered, but so did accuracy.
As the system evolved, it demanded more from its users: more steps, more context switching, more states to track and remember.
The risk wasn't usability alone. It was whether the system could support fast, confident decisions without introducing costly errors in an environment where hesitation was already visible to clients.
PRODUCT TENSION
We needed to improve efficiency while protecting a system users were already losing trust in.
Prior research made the constraint clear: associates found the tool hard to use. Trust was fragile.
This meant any improvement had to feel like a simplification, not a change. Introducing new flows, new states, or new concepts was off the table, regardless of how well-designed they were.
At the same time, the business needed multi-add feature. Adding items one at a time was the primary source of friction, and addressing it was non-negotiable.
The tension was real:
Introducing multi-add would increase the complexity the system had to handle
But the solution could not increase the complexity the user had to manage
And the users we were designing for were already skeptical
THE PROBLEM EVOLUTION
The system worked — until the problem changed.
In the original flow, items could only be added one at a time. If a product already existed in a collection, the system blocked the action to prevent overwriting size information. It was a safe guardrail. It worked because the scope was contained.
Multi-add changed the shape of the problem entirely.
Now, associates were selecting multiple items across multiple collections simultaneously. Some collections already contained some of those items — sometimes with size information, sometimes without. The same blocking logic that had protected users in single-add became a bottleneck at this scale.
What worked as a guardrail became a barrier.
And the problem kept compounding. Multi-add surfaced a second-order issue on the product detail page: selecting a size dynamically updates inventory. But once items are in the multi-add queue, changing a size creates ambiguity: is the associate checking inventory, or updating what gets added to the collection? The obvious fixes either increased cognitive load or required associates to remember what had just changed which is precisely what the system was already failing to support.
Every straightforward solution introduced new ambiguity.
Before: Items could only be added one at a time.
If a product already existed in the collection, it could not be added again even when a different size was intended, increasing friction and cognitive load.
WHY OBVIOUS APPROACHES FAILED
Surfacing more information made things worse, not better.
The instinct was to expose all possible states in the interface: show every condition so associates could make informed decisions in real time.
This failed quickly. It required users to interpret too much information under pressure, at exactly the moment they could least afford to.
Other approaches shifted responsibility back to the user, relying on memory, confirmation steps, or sequential logic to prevent errors. But these added overhead to a flow that was already asking too much.
Neither approach solved the right problem. The issue wasn't that users lacked information. It was that they were being asked to reason through complexity the system should have been handling for them.
When the obvious fix made things worse
Selecting a size on the product detail page created an unresolvable ambiguity: was the associate updating their collection, or checking inventory? Every attempt to surface more information just made the question harder to answer.
CORE INSIGHT & GOVERNING PRINCIPLE
The problem wasn't how to communicate complexity better. It was how to eliminate the need to reason about it at all.
I reframed the solution away from UI communication and toward system behaviour.
Instead of exposing every edge case, I defined a governing rule that the system would follow consistently, so associates didn't have to hold it in memory.
Governing Rule
If no new size is selected → preserve the existing state. The system assumes the prior information is still valid.
If a new size is selected → update the collection. The system treats this as new knowledge about the client's intent.
From the associate's perspective: the interaction becomes predictable. You make a selection, the system responds correctly, you move on.
From the system's perspective: complexity is handled behind the scenes, consistently, without leaking into the UI.
After: Multiple items can now be selected and added at once.
Re-adding an existing product updates it to the most recently selected size. When no size is selected, the prior size is preserved, reducing effort without introducing new flows.
DECISION STRATEGY
Every visible element needed a reason to exist at that exact moment.
My role was to decide what the system needed to show, when it needed to show it, and what could safely remain implicit, without creating invalid states or leaving users to infer meaning under pressure.
I prioritized:
Making system state visible at the moment of decision, not before or after
Grouping actions by user intent rather than underlying data structure
Reducing the number of things associates had to hold in memory at once
Equally important was deciding what not to change. Preserving familiar patterns where the system already worked prevented unnecessary relearning and reduced rollout risk which is critical in a low-trust environment.
System state is explicit at the point of action.
Size selection and collection actions are co-located, so decisions happen in one place. When a size is updated, inline feedback confirms the change immediately, resolving the ambiguity between updating a collection and checking inventory.
DESIGN CHANGES
Changes were minimal by design. The goal was legibility, not novelty.
Rather than introducing new interactions, I focused on making system behaviour legible at the right moments:
Actions and size selection co-located to eliminate context switching at the point of decision
System state reflected immediately when an item is added, so associates don't have to remember what changed
Inline feedback confirms size updates in real time, removing ambiguity between viewing inventory and updating a selection
Clear action hierarchy reduced the number of decisions users had to consciously make
The result was a flow that felt lighter, not because it did less, but because the system took on more of the reasoning load.
THE OUTCOME
The workflow became faster, clearer, and more trustworthy.
Following the release:
Conversion more than doubled
Errors during live sales conversations decreased
Associates moved through the flow with noticeably more confidence
More importantly, associates regained confidence moving through the flow smoothly, even as system complexity remained.
Rebuilding trust in the internal tool created the conditions to redesign the customer-facing side of the workflow which is the experience clients received when associates shared a collection with them.
Taken together, both sides of the journey contributed to monthly revenue growing from $50K to $347K, an outcome directly attributed to these changes by the team lead overseeing the work.
REFLECTION
In low-trust systems, clarity comes from predictable behaviour, not from better explanation.
This project reinforced a core belief in my design practice:
When users have already lost confidence in a system, adding more information doesn't restore trust. Defining behaviour they can rely on does.
The most impactful design decisions here weren't visual. They were about where the system took responsibility away from the user and where it didn't.