RWC 3. (~3–4 min)

Finding the right abstraction

This case shows how I identify and resolve hidden complexity early, reframing seemingly simple requests into durable system decisions that scale without adding cognitive or technical debt. To respect NDA constraints, high-fidelity visuals have been replaced with simplified, low-fidelity representations.

Mission

“Enable multi-location fulfillment in sales orders while preserving clarity and usability in an already complex workflow.”

Context

The sales order experience was in an early, MVP-like state, built incrementally on top of a young and still evolving design system. The existing model assumed a single fulfillment location, which simplified both the interface and the underlying mental model.

As the product matured, we needed to support multiple fulfillment locations—a necessary step toward a complete fulfillment system—but one that risked significantly increasing complexity in a workflow that was already difficult for users to reason about.

Problem

Introducing multiple fulfillment locations required rethinking how location assignment fit into the sales order model. What initially appeared to be a simple extension revealed deeper implications for user mental models, workflow clarity, and long-term system coherence.

Constraints

  • Evolving design foundations: The work had to be delivered on top of a young and still-maturing design system, with limited reusable patterns for complex, data-driven workflows.
  • Incremental platform evolution: The broader fulfillment system was being built rapidly and iteratively, requiring design decisions that could accommodate ongoing change without locking the product into brittle or short-lived structures.
  • Underestimated problem framing: The problem space was initially treated as a straightforward extension of the existing model, masking its impact on user mental models and requiring deliberate reframing to surface hidden complexity and systemic risk.

My role

  • Design ownership & direction: Led design for the initiative, owning problem framing and overall solution direction.
  • Cross-functional alignment: Facilitated discussions across product, design, and engineering to establish a shared understanding of the problem and align on priorities.
  • Design system stewardship: Partnered closely with the design system team to identify and reuse existing patterns, avoiding unnecessary divergence while supporting product needs.
  • Pragmatic delivery: Balanced speed and quality to enable fast delivery without introducing long-term complexity or technical debt.

Exploration

  • Early risk analysis: Evaluated the initially proposed approach and mapped its implications across the sales order and fulfillment workflow, surfacing usability and feasibility risks early.
  • Problem reframing: Reoriented the problem around the core need—assigning fulfillment locations at the appropriate level of abstraction—rather than extending the existing order-level model.
  • Structural exploration: Investigated alternative structures that reduced cognitive load while remaining flexible enough to support future fulfillment scenarios.
  • Domain validation: Validated emerging approaches through ongoing discussions with fulfillment subject-matter experts, ensuring alignment with real operational workflows and constraints.

Decision points

  • Correcting the abstraction level: Moved location assignment from the order level to the fulfillment level to reflect how the system actually operates internally.
  • Deferring premature decisions: Delayed location selection to later in the workflow, recognizing that it was not meaningful or actionable for users at order creation time.
  • Constraining for clarity: Enforced a single location per fulfillment, based on user research and SME validation, simplifying system logic and reducing error-prone scenarios.
  • Intentional scope limitation: Explicitly avoided supporting multiple locations per line item in the initial implementation to prevent combinatorial complexity and protect future evolvability.
  • Leveraging familiar patterns: Reused an existing, well-understood design system pattern, minimizing learning cost for users and reducing implementation effort.
Order-level location inherited by all items and fulfillment records.
Before — Location was defined at the order level and inherited by all items and their fulfillment records.
Item-specific fulfillments, each associated with one location.
After — Fulfillment is item-specific, with each fulfillment associated with a single location.

Outcome

  • Low-risk enablement: Delivered a focused, low-risk change that enabled multi-location fulfillment while preserving system stability.
  • Fast, lightweight delivery: The solution was implemented quickly with minimal engineering overhead and no need for additional user education.
  • Complexity avoidance: By resolving the core structural decision early, the team avoided downstream complexity that commonly escalates in fulfillment-related features.
  • Operational validation: The approach was validated by fulfillment subject-matter experts and proved effective in a fast-moving, iterative product environment.

What I learned

  • Upfront framing pays off: Investing in early problem reframing helped prevent later complexity and rework in a rapidly evolving system.
  • Abstraction decisions compound over time. Small structural choices early in a system’s life can either unlock scalability or create long-term friction.
  • Constraint can be a design tool. Limiting scope intentionally often creates clearer, more usable systems than attempting to support every theoretical scenario.

Working on something complex?

I’m always interested in products where systems, workflows and AI create interesting design problems

Contact

LinkedInGithub