A frontend engineer who thinks in interfaces.
SOHEIL YOUSEFI
I started in design and moved into engineering because the interesting decisions kept happening after handoff. What a loading state does, how a table behaves at 10,000 rows, whether a keyboard user can finish the task — none of that survives a static file. So I learned to build it.
Today I work on the dense end of product: support consoles, commerce back offices, dispatch tools. Interfaces where several people's work depends on the screen being fast and unambiguous. The projects here are self-directed — I build them to test specific ideas about state, density and accessibility rather than to fill a grid.
I care about the parts that don't demo well: focus order, error copy, what happens on a slow connection. That's usually where a product either feels considered or doesn't.
How I work
States before screens
Empty, loading, partial, error and over-full get designed alongside the happy path, not after it.
Build to decide
When a question is about feel or performance, a rough working build answers it faster than another round of mockups.
Leave a system behind
Tokens, component APIs and written rules, so the next person extends the work instead of guessing at it.
Want the long version? Ask me directly.
The parts that do not fit on a page — what broke, what I would do differently, and who I did it with.