Web Design as a Series of Tradeoffs

The Illusion of Best Practices

Web design isn't a solved problem. It's a negotiation between competing constraints, and those constraints shift depending on your users, your content, and your business model. What works for a documentation site fails spectacularly for a portfolio. What makes sense on a dashboard becomes hostile on a blog.

The challenge isn't finding "best practices"—it's understanding which tradeoffs you're making and why.

Performance vs. Visual Richness

This is the oldest tension in web design. Large images, custom fonts, animations, and video all create friction. They increase page weight, slow initial render, and punish users on metered connections.

But visual design communicates meaning that text alone cannot. A well-chosen hero image establishes mood faster than three paragraphs. A smooth transition signals that an action succeeded. Typography creates hierarchy that guides the eye.

The tradeoff isn't binary. You can:

• Use responsive images with srcset to serve appropriately-sized assets
• Subset fonts to include only the glyphs you actually use
• Lazy-load images below the fold
• Use CSS animations instead of JavaScript where possible
• Compress assets aggressively

<picture>
  <source 
    media="(min-width: 800px)" 
    srcset="hero-large.webp 1600w, hero-medium.webp 800w"
  >
  <img 
    src="hero-small.webp" 
    alt="Warehouse interior with organized shelving"
    loading="lazy"
    width="800" 
    height="450"
  >
</picture>

The key is being deliberate. Every asset should justify its cost. If you're adding a 2MB background video, you should be able to articulate what it accomplishes that a static image cannot.

Flexibility vs. Consistency

Design systems promise consistency across products. Use these components, follow these patterns, and everything will feel cohesive. This works well until you need to build something that doesn't fit the system.

Rigid systems create visual consistency but constrain problem-solving. Completely ad-hoc design gives maximum flexibility but produces incoherent experiences.

The middle path is a system with clear principles but limited components. Define your spacing scale, your color palette, your typography. Then let individual pages compose those primitives in ways that serve their specific needs.

:root {
  --space-xs: 0.25rem;
  --space-sm: 0.5rem;
  --space-md: 1rem;
  --space-lg: 2rem;
  --space-xl: 4rem;
}

.card {
  padding: var(--space-md);
  margin-bottom: var(--space-lg);
}

This gives you consistency where it matters—visual rhythm, color harmony—while leaving room to solve new problems without fighting your tools.

Accessibility vs. Aesthetic Preferences

Accessibility isn't optional, but it does constrain certain design choices. Sufficient color contrast limits your palette. Keyboard navigation requires visible focus states. Screen reader support sometimes means additional markup.

These aren't obstacles—they're design requirements, like supporting mobile viewports. But they do require thinking differently about visual hierarchy.

Low-contrast text looks elegant until someone with aging eyesight tries to read it. Invisible focus states create a clean aesthetic until someone navigates with a keyboard. Hidden labels work fine until a screen reader user encounters an icon-only button.

The solution is to design with these constraints from the start:

button:focus-visible {
  outline: 2px solid var(--color-primary);
  outline-offset: 2px;
}

.visually-hidden {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  border: 0;
}

<button aria-label="Close dialog">
  <svg aria-hidden="true"><!-- X icon --></svg>
</button>

Good accessible design doesn't look like accessible design—it just looks like good design.

Simplicity vs. Functionality

Minimalism is seductive. Remove everything that isn't essential, and what remains is clear and focused. But minimalism taken too far removes functionality users need.

A navigation menu with three items is simpler than one with ten. But if your site has ten sections, hiding them behind a hamburger menu or multi-level dropdown just moves complexity around—it doesn't eliminate it.

The question isn't "how much can we remove?" but "what does this user need to accomplish, and what's the clearest path there?"

Sometimes the answer is radical simplification. Sometimes it's a dense interface with lots of visible controls. The error is applying the same answer to every problem.

Mobile-First vs. Desktop-First

Mobile-first design forces you to prioritize ruthlessly. You can't fit everything on a 375px viewport, so you have to decide what matters most.

But desktop-first design lets you take advantage of larger screens—multiple columns, persistent navigation, richer interactions that don't work on touch devices.

The actual tradeoff is where you start your thinking. Mobile-first encourages progressive enhancement: build the core experience for constraints, then add capabilities. Desktop-first risks creating designs that work beautifully on large screens and break awkwardly on small ones.

Most projects benefit from starting mobile and enhancing up:

/* Base: mobile */
.grid {
  display: block;
}

/* Enhance: tablet and up */
@media (min-width: 768px) {
  .grid {
    display: grid;
    grid-template-columns: repeat(2, 1fr);
    gap: var(--space-lg);
  }
}

/* Enhance: desktop */
@media (min-width: 1200px) {
  .grid {
    grid-template-columns: repeat(3, 1fr);
  }
}

The Meta-Tradeoff

The hardest part of web design isn't choosing between these tradeoffs—it's knowing when to stop deliberating and ship something.

Every design can be improved. Every interface has rough edges. But shipping an imperfect design that solves a real problem beats endlessly refining a design that never launches.

The skill is recognizing when "good enough" is actually good enough, and when the remaining problems are worth the additional time to solve.

That judgment only comes from shipping things, seeing how they perform, and learning from what breaks.