Build · Design

WordPress website design your editors can actually use.

Most agency design ends at a beautiful mockup and falls apart the moment real content and real editors arrive. We design systems, not pictures — so what launches matches what was approved, and still looks right two years later.

  • Designed with your real content, never lorem ipsum
  • A component system, not a folder of page mockups
  • Accessibility and responsive behaviour built in, not bolted on

The problem

What usually brings people here.

The design died in handoff

What was approved in Figma is not what shipped. Spacing drifted, states were invented on the fly, and the developer filled the gaps with guesses because the design never covered them.

Every page looks slightly different

Fourteen button styles, six card variants and three different heading scales. Nobody decided this — it accumulated, one rushed page at a time, until the brand stopped feeling like one brand.

It looked good empty

Designed with three-word headlines and perfect placeholder images. Then real content arrived: long product names, missing photos, six navigation items instead of four, and the layout gave up.

Editors break it within weeks

Nothing stops someone dropping a full-width image into a narrow section or picking a colour that is not in the palette. Without constraints, the design decays as soon as the team starts publishing.

What we design

The work, specifically.

Discuss your project ↗︎

Content-first discovery

We start with what you actually publish and who publishes it. The content model shapes the design, rather than the design dictating what content is allowed to exist.

Design systems & tokens

Colour, type, spacing and radius defined once as tokens, so the site stays consistent and a global change is one edit rather than forty.

Block & pattern library

Every section your team will ever need, designed as reusable blocks with defined states — so editors assemble pages instead of designing them from scratch.

Responsive by design

Layouts designed at every breakpoint, not scaled down and hoped for. Long words, missing images and eight-item menus are considered before build, not after launch.

Accessible by default

Contrast, focus states, target sizes and keyboard order are decided in design, where they are cheap. WCAG 2.1 AA is a starting condition, not a remediation project.

Build-ready handoff

Specs, tokens, states and edge cases documented so the built site matches the design. We hand off to your developers or build it ourselves — either works.

How it works

Design the system, not just the pages.

  1. Research

    Your audience, your competitors and what your current site is doing to both.

  2. Content model

    What you publish and how it is structured, agreed before any visual work.

  3. Direction

    Two or three distinct directions on real content, not mood boards.

  4. System

    Tokens, components and states built out from the chosen direction.

  5. Prototype

    A clickable prototype your team can use before anything is coded.

  6. Handoff

    Documented specs and a walkthrough with whoever is building it.

Results

What the work produced.

SaaS marketing site

A site the marketing team could finally run

A design system with 24 components replaced a folder of one-off page designs. The team now ships campaign pages in a day without a designer or developer involved.

24 reusable components
1 day to launch a campaign page

Multi-brand system

Three brands, one design system

A group with three consumer brands was maintaining three unrelated sites. We built one token-driven system with per-brand themes, so components are shared and only the surface changes.

3 → 1 systems to maintain
−58% design time per page

Capabilities

The design stack we work in.

Design & prototyping

  • Figma
  • Auto Layout
  • Variables & tokens
  • Component libraries
  • Interactive prototypes
  • Version history

Systems

  • Design tokens
  • Type scales
  • Spacing systems
  • Colour systems
  • Iconography
  • Motion guidelines

Accessibility

  • WCAG 2.1 AA
  • Contrast ratios
  • Focus states
  • Target sizes
  • Keyboard order
  • Screen reader flow

Handoff to build

  • theme.json mapping
  • Block patterns
  • Component specs
  • State documentation
  • Edge-case notes

Engagement

Three ways this usually runs.

Design sprint

Fixed fee

A focused week or two producing direction, key templates and a component starter set — enough to decide whether the direction is right before committing to a full build.

  • 1–2 weeks
  • No obligation to continue
  • Yours to take elsewhere

Design retainer

Monthly

Ongoing design support for teams shipping continuously — new patterns, campaign pages and keeping the system coherent as it grows.

  • Rolling monthly
  • System stays maintained
  • Cancel any time

Questions

Design questions, answered plainly.

If your situation isn't covered here, send us the details and we'll reply with a straight answer.

Do you design in Figma or straight in WordPress?

Figma for the system and the thinking, WordPress for the truth. We design tokens, components and templates in Figma, then map them to theme.json and block patterns so the built site inherits the system rather than approximating it. Designing directly in WordPress works for small sites but makes it very hard to explore alternatives cheaply.

Will the built site actually look like the design?

Yes, because we design what can be built and document the parts that usually get lost — hover and focus states, empty states, long-content behaviour and every breakpoint. Most design-to-build drift comes from decisions the design never made, so the developer had to invent them. We make those decisions upfront.

Can you work with our existing brand guidelines?

Yes, and often that is the whole job. Brand guidelines cover print and logo usage far more often than they cover interface: focus states, form errors, data tables, empty states. We extend your brand into a digital system without contradicting what already exists.

Do you do design only, or do you build it too?

Either. Some clients take our handoff to their own developers, which is exactly why the documentation is thorough. Others have us design and build in one engagement, which is usually faster because nothing gets lost between two companies.

How do you stop the design degrading after launch?

Constraints in the editor. Blocks ship with locked patterns, a fixed palette and defined spacing, so an editor cannot accidentally break the layout or invent a new colour. Freedom where content needs it, guardrails everywhere else — that is what keeps a site looking designed two years later.

What if we don't have the content yet?

That is common, and it is why the content model comes before visual design. We work from a realistic outline — actual headline lengths, actual product counts, actual image availability — rather than placeholder text. Designing against lorem ipsum is how sites end up breaking on launch day.

Start here

Tell us what you're dealing with.

The more you can tell us, the more useful our first reply will be. No sales sequence — one of the people who would actually do the work reads this.

  • We read it and look at your site
  • You get a written reply with our honest read
  • If it fits, we scope it properly

Prefer email? hello@dotance.com

We reply within one business day.