designing with ethan daya

Create restrained, intentional work that is specific to its purpose. Minimal does not mean generic. Prefer fewer, stronger objects, a clear hierarchy, and one memorable detail.

Route the task

If the request mixes modes, protect the narrowest accepted scope. Do not turn a refinement into an unsolicited redesign.

Read the product before designing

1. Identify the decision or action the surface supports.
2. Inspect current composition, tokens, primitives, interactions, and responsive behavior.
3. Inventory capabilities and accepted identity that must survive.
4. Separate the requested change from nearby opportunities.

Lock references

Inspect actual reference screens, not titles or metadata. Choose one primary reference for mood, density, and composition. Borrow at most two named details from secondary references. Translate rather than clone.

Use this artifact before implementing an open direction:

REFERENCE LOCK
Job:
Primary reference and traits to preserve:
Borrowed details and source:
Existing product traits to preserve:
Rejects:
Unverified assumptions:

Filled example:

REFERENCE LOCK
Job: help an operator spot the largest delay and open its cause.
Primary: compact editorial report; preserve one dominant chart, tight rows, broad section spacing.
Borrow: tabular metric labels; a single amber exception marker.
Preserve: existing filters, detail route, dark mode, export action.
Reject: twelve equal cards, ambient gradients, mono body copy, hidden mobile metrics.
Unverified: chart legibility below 360px until rendered.

Build hierarchy before decoration

• Expose user concepts, not implementation concepts.
• Give each page one obvious primary object or action.
• Remove duplicate titles, helper copy, badges, dividers, and actions when context already explains them.
• Move secondary detail behind a row, dialog, tab, or route without deleting capability.
• Prefer composed sections over equally weighted cards.
• Keep related controls tight and separate distinct sections with space.

Assign typography roles

• Primary sans: navigation, body, controls, and most headings.
• Serif: selective editorial or brand voice only when it adds character.
• Mono: code, identifiers, dates, ranks, times, and technical metadata, not ordinary inputs or all labels.
• Tabular numerals: changing metrics, ranks, times, and financial values.
• Verify small text and muted contrast instead of assuming they pass.

Control surfaces and color

• Prefer tonal separation, restrained shadows, and selective borders over boxes everywhere.
• Keep radius and shadow proportional to the component.
• Reuse semantic tokens and primitives before adding variants.
• Reserve accent for state, identity, or one focal detail.
• Design dark mode rather than automatically inverting it.
• Reject glass, glow, ambient blobs, decorative gradients, and borrowed luxury styling unless the lock requires them.

Preserve interaction and states

• Make object rows actionable while preventing nested controls from triggering the row.
• Keep controls stable during loading and preserve content footprints.
• Use visible text-link affordances and label icon-only controls.
• Preserve filters, sorting, and context across navigation.
• Design main, loading, empty, error, zero-data, long-content, disabled, and success states as relevant.
• Keep focus visible, DOM order logical, labels programmatic, contrast sufficient, and keyboard operation equivalent.
• Ensure targets are usable by touch and focus is restored after dialogs or transient layers close.

Motion explains state and stays out of frequent work. Prefer transform and opacity, named transition properties, reduced-motion alternatives, and brief timings. Never use transition: all. Do not add motion merely to make a static hierarchy interesting.

Preserve responsive continuity

• Treat mobile as the same product, not an emptier variant.
• Hide low-value metadata before core values and actions.
• Prevent clipping, overflow, accidental wrapping, tiny targets, and unwanted mobile autofocus.
• Test content extremes, not only ideal samples.

Verify visually

1. Render representative content in the real medium.
2. Capture or inspect comparable desktop and mobile views.
3. Inspect supported themes and relevant hover, focus, loading, empty, error, and reduced-motion states.
4. Compare against the reference lock and accepted baseline.
5. Fix visible regressions, then repeat the affected comparison.

Source inspection does not prove visual quality. Use measurements when alignment, width, typography, or layout shift is disputed.

If no browser or visual inspection capability exists, inspect source and tests, produce the reference lock and expected viewport/state matrix, run any available static checks, and label every visual claim unverified. Do not claim fidelity or polish. Stop at a review-ready proposal or source change with explicit manual checks.

Acceptance artifact

Before handoff, provide:

• the task mode, surface job, scope, and preserved capabilities;
• the reference lock for a new direction, or accepted baseline for refinement;
• compared desktop and mobile artifacts, with viewport details when available;
• relevant interaction, keyboard, focus, content, theme, and reduced-motion states checked;
• exact automated checks and outcomes;
• known regressions, unavailable capabilities, and unverified visual claims.

Reject list

• Generic SaaS grids of equal cards
• Oversized type, padding, controls, or radii without compositional purpose
• Mono as a shortcut to feeling technical
• Full-card accent when a semantic mark works
• Literal reference copying
• Decorative motion or filler copy
• A redesign that removes accepted features, routes, or personality

Stop only when the requested scope is visually compared and the acceptance artifact is honest, or when unavailable capability is clearly recorded for the next reviewer.