A beautiful design file is not a theme. It is one state, of one page, at one width, filled with content the designer chose.
A theme is every state, at every width, filled with content written by a stranger who has never heard of you — and it has to hold up in all of those cases, for years, while someone else edits it.
The distance between those two things is where most designer-built themes fall apart. Here is how to close it, whether you are handing the file to a developer, building it yourself, or preparing to sell it.
Part 1: Design systems, not screens
If your file is a sequence of artboards, each pixel-pushed until it looked right, you have designed pictures of a website. Themes need underlying rules.
Before drawing anything, define:
- A type scale. A fixed set of steps, each used deliberately — not 34px on one page because it fit, and 32px on another because it also fit.
- A spacing scale. Consistent increments. Every gap in the design should be a value from the scale, with no exceptions.
- Colour as roles, not values. Not “blue #2B6CB0” but
surface,text,text-muted,border,accent. This is what allows a buyer to change one setting and rebrand the site coherently — and it is the single biggest determinant of how customisable your theme feels. - One shape language. One radius, one border weight, a small set of elevation levels.
Then build real components with variants, and use them everywhere. If a card exists in six places with three slightly different paddings, you have created six components for a developer to reconcile and a buyer to be subtly bothered by.
The test: could someone else add a new page to your design using only your styles and components, without inventing a value? If not, the system is incomplete.
Part 2: Design the states, not just the happy path
This is the most common gap, and it produces the largest volume of developer questions.
For every interactive element, specify: default, hover, focus (visible, and distinct from hover — keyboard users depend on it), active, disabled, and loading.
For every page or module that displays data, specify what happens when the data is absent or unusual:
- Empty states — no results, empty cart, no posts yet, no reviews
- Error states — failed form submission, per-field validation messages
- Loading states — what fills the space while a filtered collection is fetching
- Commerce states — out of stock, on sale with the old price shown, low stock, pre-order
If you do not design these, someone else will. It will be a developer at 11pm, guessing, and it will not match your intent.
Part 3: Design the widths you actually ship
Most files contain a desktop artboard at a generous width and a phone artboard at 375px. Real browsers occupy every width in between, and the awkward middle is where template layouts collapse — a three-column grid at 900px, a navigation bar with too many items at 820px, a data table on a tablet.
Design the intermediate width for anything with a grid or a table. And specify reflow rules explicitly: at what width does this three-column grid become two, then one? Where does the navigation become a menu button? Does this sidebar move above or below the content?
“The developer will figure it out” means the developer will make design decisions on your behalf.
Part 4: Stress-test with hostile content
Before handoff, take one pass through the file replacing every piece of content with its worst realistic version:
- A page title that runs to three lines
- A product name that is 90 characters long
- A navigation with nine items instead of five
- A price with a large number and a currency symbol that sits after the digits
- A user with no avatar
- A testimonial of one sentence beside one of six
- An image that is portrait when the design assumed landscape
Whatever breaks here would have broken in production. Fixing it in the file costs minutes; fixing it after launch costs a support ticket and a patch release.
While you are there, define your image rules: what aspect ratios does the theme enforce, what happens to an image that does not match, and where is it cropped from. Buyers will upload whatever they have.
Part 5: The things that do not exist in Figma
A static file cannot express several properties that determine whether the built site feels good. Write these down in a specification, because otherwise they get invented.
Scroll behaviour. Does the header shrink, stick, or hide on scroll down? What happens to the mobile “add to cart” button — does it dock to the bottom?
Motion. Duration, easing, and what triggers it. Also: what happens for users who have asked their system to reduce motion. That is a real preference and honouring it is not optional.
Focus order. The sequence a keyboard user moves through, especially where visual order and source order differ.
Font loading. Which weights are genuinely required, and what the fallback looks like while the webfont loads. Every extra weight is a network request, and a careless fallback causes visible reflow.
Performance intent. If the design has a full-bleed hero video, a parallax section, and an animated stat counter, be explicit that these are wanted and understand the cost. It is far better to decide this at design time than to have a developer silently cut it or, worse, silently ship it.
Part 6: The handoff document
A file plus a conversation is not a handoff. A short written document alongside the file will save more time than any amount of tidy layer naming.
Include: the token names and their values; the responsive rules for each component; interaction and animation specs; asset export rules and required formats; accessibility notes including contrast ratios on the actual palette; and — most valuable of all — a short list of what is deliberate versus what is arbitrary.
That last item matters more than people expect. Developers spend real time preserving details a designer would happily have changed, because they cannot tell which is which. Tell them: this asymmetry is intentional, that 26px gap was a rounding accident, snap it to the scale.
Part 7: What changes if you want to sell it
Selling a theme adds requirements that have nothing to do with design quality.
Licensing is the trap. Everything you bundle gets redistributed to every buyer, which is a completely different licence class from using it on one project. Check your typefaces for a licence permitting redistribution inside a product — many do not. Check your icon set’s terms. Check every photograph in your demo content, since standard stock licences generally do not permit redistribution in a template. This catches out more first-time theme authors than any technical issue, and it is the one that carries legal consequences.
Documentation is part of the product. Installation, setup, every setting explained, and a section on how to customise without breaking updates.
Demo content has to be shippable. Realistic and varied rather than idealised — and importable, so a buyer can start from something rather than an empty site.
Customisation has to survive updates. Design tokens exposed as settings, a documented override path, and no expectation that buyers edit core files.
Support is an ongoing commitment. A theme is not a one-time sale. It is a maintenance relationship, with a changelog, compatibility updates, and questions to answer for as long as it is listed.
The shift in mindset
Designing a website means designing an outcome. Designing a theme means designing a range of outcomes — most of which you will never see, made by people whose content, brand, and taste differ from yours.
The best theme designers stop asking “does this look right?” and start asking “how far can someone take this before it stops looking right?” That distance is the product.
At eThemeStudio, this is roughly the pipeline our own themes go through, and we are always interested in talking to designers who work this way — whether you are building your own product or looking for a development partner to take a file to launch. Send us your work.
Comments (0)