What are the 5 basic principles of web design?

The five principles are balance, contrast, emphasis, repetition, and unity. They were invented for compositions that stay where you put them. Websites declined to cooperate.

  • Web design
  • Design principles
  • Responsive
  • Design mode

There are two lists that regularly get called the basic principles of web design, because apparently even the basics needed competing standards. One is balance, contrast, emphasis, repetition, and unity. The other is contrast, repetition, alignment, and proximity, popularized by Robin Williams in The Non-Designer's Design Book in 1994. That second list has four principles. If you found a version with five, someone needed a better headline.

The five we're interested in are balance, contrast, emphasis, repetition, and unity. They come from art and graphic design, where the designer had one considerable advantage: the thing stayed where they put it.

Balance

Balance is the distribution of visual weight across a composition. Put a large image on one side and you probably need enough on the other side to stop the page looking like it's falling over.

This is straightforward when the composition has one size. Websites have whatever size screen someone happens to own. Your carefully balanced two-column hero becomes a vertical stack on mobile, the image moves above the copy, and the composition you spent an afternoon nudging into equilibrium no longer exists.

Responsive design doesn't make balance irrelevant. It means you have several layouts to balance. Check the page at the widths where its structure changes, especially when columns stack, images move, navigation collapses, or sidebars relocate themselves to somewhere technically valid.

Contrast

Contrast makes different things look different. Bigger against smaller, dark against light, bold against regular, crowded against spacious. Without enough of it, everything politely asks for the same amount of attention and the user gets to figure out what matters.

The web improves one part of this because text contrast is measurable. WCAG AA requires at least 4.5:1 for normal text and 3:1 for large text. You can test that instead of gathering six people around a monitor to discuss whether the gray feels gray enough.

Not all contrast comes with a number, though. A heading that barely differs from body copy can technically pass accessibility checks while still doing a terrible job of being a heading. The checker can tell you whether people can read it. It cannot tell you whether anyone knows why they should.

Emphasis

Emphasis decides what gets noticed first. Usually that means a headline, an important piece of content, or the primary action. You make one thing louder because making everything louder is how websites become airport duty-free shops.

Then the real site arrives. Marketing adds a promotional bar. Legal adds a consent banner. Support adds a chat bubble. The app adds three notifications. Everyone's addition is important in isolation, which is how the page ends up screaming about six unrelated things at once.

Check emphasis on the complete page with the actual production UI present. Look at it for a second and notice where your eye goes first. If it isn't the thing the page exists to communicate, congratulations, you've discovered the actual hierarchy.

Repetition

Repetition makes related things look related. Buttons behave like other buttons. Cards use the same spacing. Headings follow a recognizable hierarchy. Users learn the visual language once instead of solving a small puzzle every time they scroll.

CSS and component systems are extremely good at this, provided nobody gets creative in the wrong place. If every primary button needs changing, change the shared rule or component. If you fix seventeen buttons individually, you haven't created consistency. You've created seventeen future opportunities to forget one.

This is where repetition stops being purely visual and becomes an implementation decision. The design stays consistent because the underlying rule is shared, not because everyone involved has an unusually good memory.

Unity

Unity is what you get when the whole site feels like one system rather than several projects sharing a domain name.

It's also the principle most likely to decay quietly. Websites don't get finished. Someone adds a landing page in March, another person ships a new component in June, and by September there are four button styles because each one looked reasonable when viewed alone.

You can't permanently complete unity because the site keeps changing after the design review ends. The practical answer is to review the whole thing occasionally. When something looks wrong, work out whether that page is the exception or whether the shared system is. Then fix the right one instead of adding another exception and leaving a comment explaining why it's special.

Check the website, not the memory of the website

These principles are visual, which means the useful place to evaluate them is the running site. Not the Figma frame from three months ago. Not the desktop screenshot in the launch deck. The slightly more disappointing version currently being served to users.

Open the real page at several widths with real content, banners, navigation, widgets, and whatever else accumulated between design approval and production. Check whether the layout stays balanced after reflow, whether text has enough contrast, whether the important thing actually gets attention, whether repeated components are still repeated, and whether the site looks like its pages have met each other.

Pixy makes the fixing part less ceremonial. Add the tag to your site or use the Chrome extension, press ⌘⇧E, and edit the page you're actually looking at. Resize the frame and your existing CSS reflows through its breakpoints, so you can make the mobile fix while looking at the mobile problem. Changes stay attached to the width where you made them, and your coding agent can apply the batch to the source.

It doesn't make balance, contrast, emphasis, repetition, or unity automatic. That would require software capable of knowing what you meant, which remains an ambitious feature request. It just lets you find the problem on the real site and fix it there instead of writing a paragraph explaining to someone else that the hero feels weird around 768px.

The old principles still work. You just have to apply them to a thing that changes width, changes content, and continues being edited by people who weren't in the room when you designed it.

So open the page, make it narrow, and see what happens. Mobile users already did.

Enough theory. Put the principles to work.

Change the balance, contrast, or emphasis on this page with Pixy.