Skip to content

Building interfaces that scale

How I think about CSS, accessibility, and the states between actions.

Sam Darbeh

I've spent most of my frontend career building interfaces for complex systems. Financial data, advertising workflows, and experiments come with rules the customer shouldn't need to learn. A scalable interface gives that complexity a shape people can understand.

CSS I can trust

I don't judge CSS by how little of it exists. I care whether another engineer can find a style, understand why it's there, and change it without breaking an unrelated screen.

The framework matters less than clear boundaries. I want styles close enough to the logic that another engineer can change one area without starting a specificity war somewhere else.

I don't mind some duplication. Two things looking the same today doesn't make them the same component. The wrong abstraction usually creates more work than a few repeated declarations.

The interface has to stretch

A Figma mockup usually shows clean data and copy that fits. The real interface gets one-character customer names, reports with hundreds of results, regional number formats, and translations much longer than the original label.

I try to avoid fixed heights around text, let controls grow, and only truncate when losing part of a value is acceptable. Logical properties also keep LTR assumptions out of most components.

Empty values, user-generated content, zoom, and small screens test the same assumptions.

The states between actions

Loading, empty, partial, stale, disabled, and error states are part of the product. I want to catch incompatible choices early, block only what is impossible, and preserve the user's state when something fails.

An error should say what happened, what it affected, and what the customer can do next. I try to avoid Something went wrong whenever possible.

Sections can render as data arrives. Skeletons work when the shape is predictable, or existing content can stay in place while new data loads.

Clarity lives in the implementation

Accessibility goes well beyond using semantic HTML. When dealing with asynchronous streams or heavy tables, it becomes a challenge of managing time and attention.

A status update that only appears visually often needs a live region. If a background request resolves and shifts the layout, focus has to be intentionally routed. Validation should be explicitly connected to the field it describes, and the page must remain usable regardless of viewport or input device.

When I'm building a UI, I want someone to be able to answer three questions:

  1. What just happened?
  2. What is happening now?
  3. What can I do next?

If the product can't answer those questions, the frontend isn't done yet.

Absorbing complexity

Customers don't experience our CSS architecture, component boundaries, or data-fetching strategy. They experience whether the product makes sense. Clean CSS and reusable components help a team preserve that clarity as the product grows.

A good interface absorbs those nuances and keeps the customer oriented.

Limited mode

JavaScript disabled. Some features won’t work as intended.