Design philosophy

Products should absorb system complexity rather than transfer it to users.

Seven principles, summarized from eight years of designing enterprise tools inside the retail industry — merchandising, pricing, supply chain, stores.

↓Scroll — seven principles

Complexity does not disappear.

It is either absorbed by the product, handled by the team, or pushed onto the user.

Product
Team
User
Default: the burden lands on whoever is closest to the work. Designed: the product carries it on purpose.

My job is to understand the work deeply enough to make that distribution intentional — not to make a complex system merely look simple.

So I care less about whether a screen looks clean in isolation, and more about whether it helps people understand what is happening, decide well, recover when things go wrong, and keep working with confidence.

PRINCIPLE 01

Understand the work before designing the workflow.

In complex systems the visible task is rarely the real task.

WHAT THE SCREEN SHOWS
A user edits a number.
WHAT THE WORK ACTUALLY IS
Interpreting a business event that changed the plan.
Resolving uncertainty with incomplete information.
Coordinating with another team that owns part of the outcome.
Protecting against downstream risk they will be held to.

Design should start from that work, not from the surface of the feature request.

PRINCIPLE 02

Find the user behavior that drives the business outcome.

Business goals and user needs are rarely the same sentence. They are usually connected by one specific behavior.

CASE — NFPT FORECAST ADJUSTMENT

Leadership framed the problem as forecast accuracy: find unreliable forecasts, watch variance, contain planning risk. Research told a different story about the merchants doing the work.

TRIGGER THE METRIC ASSUMED
Variance is high → Merchant adjusts the forecast NOT WHAT HAPPENED
TRIGGER THE WORK ACTUALLY HAD
Vendor update, supply change, promo shift → The current forecast is now outdated → Which weeks are affected? → Adjust those weeks
Accuracy was the outcome of these decisions, not the trigger for them. A variance number could say a problem existed; it could not say why the future should change, which weeks, or by how much.
FROM How do we show merchants where forecasts are inaccurate?
TO How do we help merchants recognize a meaningful business change, understand its future impact, and update the affected forecast?

That distinction split one blurred product need into two: performance monitoring for leadership, and decision support for merchants.

Status — research and problem-framing contribution. Its value was clarifying a mismatch between an organizational metric and the behavior needed to produce it, not a claim that the shipped product improved forecast accuracy.
PRINCIPLE 03

Structure information around the decisions users need to make.

On a merchant KPI dashboard, seven headline metrics and seven basket metrics arrived as fourteen near-identical cards. Primary outcomes, performance drivers and diagnostic indicators all carried the same weight, so every user had to reconstruct the priority themselves.

CASE — KPI DASHBOARD · SCREENS FROM THE PRODUCT
Merchant KPI dashboard as built: fourteen near-identical metric cards Proposed dashboard: total sales as the primary outcome, drivers beneath, shopper behavior and assortment grouped in a side rail
Keep scrolling — the proposal replaces the original screen. The same values, re-weighted: total sales as the primary outcome, its drivers beneath, and shopper behavior and assortment grouped into a supporting rail. Open as built ↗ · Open proposed ↗
When everything is visually important, nothing is meaningfully prioritized.
Status — critique and proposed direction. Product colleagues agreed with the diagnosis; the direction was not formally reviewed by the final decision-maker, implemented, or validated.
PRINCIPLE 04

Explain the meaning of data, not just its value.

Six related basket metrics, six identical cards, two or three benchmarks inside each. Every number was on screen. The model connecting them — who is buying, how often, how deep each trip runs, and what that is worth per household — was not.

CASE — BASKET METRICS · SCREENS FROM THE PRODUCT
AS BUILT — SIX PEER CARDS, TWO TO THREE BENCHMARKS EACH
Basket metrics as built: six equal cards, each holding two or three benchmark columns
Every value and prior period is present. Nothing states how the six relate, or which one deserves attention. Open at full size ↗
PROPOSED — FUNNEL ORDER, WITH THE READING WRITTEN IN
Proposed basket metrics: cards ordered reach, frequency, depth, value, each with a plain-language reading and the worst mover flagged
Same six metrics. Four changes turn a value inventory into an argument.
ORDERCards run in funnel order — reach, then frequency, then depth, then value per household — so the sequence itself carries the business model.
INTERPRETATIONEach number is restated in practical terms: 67.0% penetration becomes “losing about 1 in 80 buying households”; 0.89 trips a week becomes “buyers return roughly every 8 days.”
EXPLICIT COMPARISONDirection against the division is written out — “falling faster than the division,” “declining slower than the division” — instead of leaving the reader to subtract two benchmarks.
EXCEPTIONOne card is flagged as the worst mover in the view, so the eye lands on the metric that needs investigating first.
Data should communicate its implication, not merely expose its value.
Status — critique and proposed direction. Agreed with by product colleagues; not formally reviewed by the final decision-maker, implemented, or validated.
PRINCIPLE 05

Preserve the useful behavior, not the pattern's visual metaphor.

The request was to make a hierarchical explorer “feel less like a desktop file browser.” Read literally that is restyling. Read as a task problem, it is a question about what the pattern is actually doing for the user.

KEEP — BEHAVIOR THAT SERVES THE TASK
  • The user's path through the hierarchy stays visible
  • Context is maintained across adjacent levels
  • Moving back never costs orientation
  • The active level and its next step stay in reach
DROP — CONVENTIONS THAT DON'T
  • A permanent equal-width column per level
  • Inactive ancestors competing with the task for space
  • The look of a file browser
CASE — PRODUCT PERFORMANCE EXPLORER · SCREENS FROM THE PRODUCT
AS BUILT — FOUR EQUAL COLUMNS, HELD OPEN AT EVERY DEPTH
Explorer as built: group, category, vendor and item columns at equal width, each holding a full scrolling list, with the KPI detail panel on the right
The path is legible, but every ancestor keeps a full-width column of rows the user has already left behind — and the two levels that carry the current task get a quarter of the width each. Open at full size ↗
PROPOSED — ANCESTORS COMPRESS, THE ACTIVE LEVELS KEEP THE SPACE
Proposed explorer: earlier levels collapse into narrow overlapping cards on the left while the vendor and item levels expand to full cards, KPI detail unchanged on the right
Same hierarchy, same drill path, same data. The behavior is kept; the file-browser geometry is not.
SPACE FOLLOWS THE TASKThe two levels the user is working in — vendors in the category, items for the selected vendor — take full cards. Everything behind them narrows to a sliver.
PATH STAYS PRESENTAncestor levels stack as overlapping cards rather than disappearing, so the route in is still visible and still clickable — the drill-down behavior the user relied on is untouched.
DEPTH BECOMES LEGIBLEThe stack reads as position in the hierarchy — how deep the user has gone, and how far back recovery is — which four equal columns never expressed.
FIXED REFERENCE HELDThe KPI detail panel and the breadcrumb stay exactly where they were. The change is scoped to the columns; nothing the user had learned to find moves.
Reuse a pattern for the behavior that supports the task — not because its familiar appearance is easy to copy.
Status — critique and proposed direction. Agreed with by product colleagues; not formally reviewed by the final decision-maker, implemented, or validated.
PRINCIPLE 06

Make system status, consequences, and recovery visible.

Enterprise work runs on partial data, delayed integrations, permissions, approvals, and decisions that are expensive to undo.

WHAT IS HAPPENING NOW
Loading, syncing, or waiting on an upstream system — and how long it should take.
IS THIS DATA TRUSTWORTHY
Complete, partial, stale, or unavailable — said plainly, before a decision is made on it.
WHAT THIS ACTION WILL DO
Scope, who is affected, whether it can be reversed, and who has to approve it.
HOW TO GET BACK ON TRACK
Whether it succeeded, what failed, what survived, and the next move from here.

Empty, unavailable, error, loading and unsaved-change states are not polish. They are the product's ability to support real work.

PRINCIPLE 07

Design for exceptions, not only the happy path.

The happy path proves the concept can work. The exceptions decide whether it survives real use.

HAPPY PATH Open→ Review→ Adjust→ Submit→ Approved
THE NORMAL TEXTURE OF THE WORK
missing data mismatched records conflicting rules unusual permissions incomplete history delayed integration approval bounced back interrupted mid-edit two owners, one record legacy system disagrees
In enterprise environments these are not rare. Designing for them is not extra scope.
HOW THAT BECOMES WORK

Methods

01Understand the real workflow before committing to an interface direction
02Separate organizational goals from the frontline behaviors that produce them
03Map user classes, decision points, handoffs, and sources of authority
04Identify what information users need before, during, and after a decision
05Use hierarchy, grouping, explanation, and interaction structure to reduce interpretation work
06Make recommendations concrete through rationale, tradeoffs, prototypes, and available evidence
07Clarify decision ownership, review points, and success criteria as early as possible
08Stay involved through implementation where it protects design intent

Where this comes from: retail operations

Everything above was learned in retail. It is a domain where the product sits inside a large organization, and the people who buy, approve, manage and use it are rarely the same person. These are the constraints I have worked inside:

multiple user classes, unequal authority fragmented sources of truth legacy systems that can't all be replaced high-volume workflows, many exceptions management goals needing frontline translation frontline friction needing business framing rollout, training and adoption constraints

I can't claim these principles generalize to every industry — I have only practiced them here. But the conditions that produced them are structural rather than retail-specific, so I expect the approach to travel to other operational domains with the same shape.

Much of the work is translation. Ambiguous feedback becomes a specific task, information or decision problem: “this feels too even” is usually an information-priority problem; “make it less like Finder” is usually a request to keep hierarchy behavior while changing the metaphor.

Strong reasoning improves the quality of decisions, but it does not by itself grant a seat in them. So I stay precise about the status of my work — whether I am offering critique, proposing a direction, building the implementation, or owning the decision.

This is the work I care about: connecting business goals to actionable user behavior, making complexity understandable, and helping people act with confidence.

LET'S TALK ABOUT A HARD PROBLEM → yangyanglong233@gmail.com