Users do not separate design from engineering. They experience one thing: whether the product felt effortless. A beautiful interface that takes four seconds to load is a bad experience, and a fast interface that leaves people guessing what to do next is also a bad experience. The interesting work happens where the two disciplines overlap.
Performance is a design feature
Speed changes behaviour more reliably than almost any visual decision. Research across e-commerce and content sites consistently finds that abandonment climbs sharply as load time rises past a couple of seconds. The engineering choices behind that number are unglamorous but well understood: serve appropriately sized and modern-format images, defer scripts that are not needed for the first paint, avoid layout shifting as content arrives, and cache aggressively at the edge.
Design for the states nobody mocks up
Most design files show the happy path with realistic data. Real products spend a lot of their time in other states, and how those are handled is what separates a polished product from a frustrating one.
- Empty states that explain what goes here and how to add the first item.
- Loading states that reserve the space content will occupy, so nothing jumps.
- Error states that say what went wrong and what to do about it, in plain language.
- Long-content states where a name runs to sixty characters or a list to a thousand rows.
Accessibility improves the product for everyone
Semantic markup, sufficient colour contrast, visible focus indicators, labelled form fields, and full keyboard operation are not a compliance tax. They make the product work better on a bright afternoon, on a trackpad-free laptop, on a slow connection and for the significant share of users with a permanent or temporary impairment. They also happen to be what assistive technology and search engines both rely on.
Every interaction should answer three questions immediately: what happened, what is happening now, and what can I do next.
Feedback within 100 milliseconds
When someone taps a button, something should change immediately — a pressed state, a spinner, a disabled control. Without it, people tap again, submit twice, and lose confidence in the product. Optimistic updates, where the interface reflects the intended result while the request completes in the background, make an application feel dramatically faster without any change to the actual response time.
Build once, use everywhere
A shared component library — buttons, inputs, modals, tables, each with its states defined once — keeps the interface consistent as the product grows and makes new screens quick to assemble. Consistency is not an aesthetic preference. It is what lets users transfer what they learned on one screen to the next.
Let behaviour settle the arguments
Analytics on real usage, session recordings, and a handful of usability sessions with actual users will resolve more design debates than any meeting. Ship, watch, adjust. The products that feel effortless got there through iteration, not through getting it perfect the first time.