Design and build the frontend

Two products can use the same colors and the same font and still feel completely different: one looks intentional, the other looks assembled from spare parts. The difference is usually not talent. It is whether a small, consistent set of choices, type, color, spacing, and reused components, gets defined once and actually reused everywhere, instead of re-decided on every screen.

The four things to lock down early

None of this is arbitrary. It maps onto the findings in the core laws of UX and UI design: a short, chunked type scale respects the same limited working memory behind Miller's Law, a small reused color and spacing system is what lets Gestalt grouping read correctly, and following the visual conventions people already know from other products is Jakob's Law in practice. This lesson is the practical version of that guide: what to define before you lay out a single screen.

How to apply it

• Write the type scale and spacing scale down before building any layout. A short list of allowed values is easier to hold to than "whatever looks right" in the moment.
• Pick a base spacing unit and only use multiples of it. Arbitrary pixel values are how spacing quietly drifts screen by screen.
• Build shared components, a button, a card, an input, once, and change them in one place instead of copying and tweaking markup for each new screen.
• Before adding a new color, font size, or one-off spacing value, check whether an existing one already does the job.

A responsive layout is one codebase that rearranges itself to fit whatever screen it is shown on, instead of a separate design for every device. Getting that right starts with which end you design from first.

Start from the smallest screen

Mobile-first design means building the layout for the narrowest, most constrained screen first, then adding complexity as more space becomes available, rather than designing a wide desktop layout and squeezing it down afterward. Starting narrow forces real priority decisions early: what actually has to be on screen, and what can wait. Starting wide and shrinking tends to produce a desktop layout with things quietly hidden or crammed together on a phone.

Breakpoints

A breakpoint is a screen width where the layout changes to fit the available space better. You do not need one for every possible screen size, only for the handful of widths where the current layout stops working well.

Search engines see the mobile version

This is not only about how the site looks on a phone. Google, the dominant search engine, indexes and ranks pages using the mobile version of the content, not the desktop version, for the large majority of sites. A layout that hides content, breaks navigation, or drops text on small screens is not just a worse mobile experience. It is the version search engines are actually evaluating.

Accessibility is not a feature added at the end. It is whether the people who navigate by keyboard, by screen reader, or with limited vision can actually use what you built. A surprising amount of it comes from a short list of habits applied consistently, not a specialized skill learned separately.

Semantic HTML

Use the HTML element built for the job: a real <button> for something clickable, a real <nav> for navigation, an ordered sequence of heading levels, <h1> through <h6>, instead of styled <div> elements with a click handler. Screen readers and keyboard navigation are built to understand these real elements. A <div> styled to look like a button gives a mouse user something clickable and gives a keyboard or screen reader user nothing at all.

The essentials

• Keyboard operability: every interactive element must be reachable and usable with Tab, Enter, and Space alone, with a visible focus outline, not just a mouse hover state.
• Real labels: every form input needs a linked <label>, and every icon-only button needs an accessible name, such as an aria-label, when there is no visible text.
• Alt text: every meaningful image needs a written description in its alt attribute; a purely decorative image gets an empty alt so screen readers skip it instead of reading a meaningless filename.
• Color contrast: WCAG AA requires at least 4.5:1 contrast between text and its background for normal text, and at least 3:1 for large text (roughly 18pt, or 14pt bold, and up).

Contrast is easy to get wrong by eye: light gray text on a white background often looks fine to a designer with good vision and fails the 4.5:1 ratio outright. Run actual text and background colors through a contrast checker rather than judging by eye, especially for body copy, form labels, and any text placed over an image.

A slow interface is not an abstract problem. It is felt directly, as a wait before something useful appears or a tap that does not seem to register. Core Web Vitals are a small set of metrics built to measure that felt experience in concrete numbers, rather than leaving "fast enough" to guesswork.

The three Core Web Vitals

What actually moves those numbers

• Image optimization: serve images sized for where they are shown, use a modern compressed format, and compress before upload. Images are usually the single heaviest thing on a page, and often the element LCP is timing.
• Lazy loading: load offscreen images and non-critical content only as the user scrolls near them, so the initial page load is not paying for content nobody has reached yet.
• Keep the JavaScript bundle small: every kilobyte of JS has to be downloaded, parsed, and run before the page is fully interactive. Ship only what the current page needs, and load rarely used, heavy features only when they are actually used.

Reserve space for images and embedded content with explicit dimensions so the browser does not have to shift the layout once they finish loading. That single habit accounts for a large share of avoidable CLS.