A Quiet Brand in Ten Tokens
For the Midwest site I wanted something dark, quiet and credible. The whole visual system fits in ten colour tokens and a short list of rules. Here's why a small palette and a few hard rules beat a big design system for a brand like this.
5 min read
Midwest is an agentic software company: we build real products, and we build them with agentic practices. The public site has a narrow job. It should feel like a high-signal portfolio. Dark, a little mysterious, technical, quiet, and credible to the people who matter most: investors, operators and strong collaborators.
When I wrote the design guide for it, I kept it deliberately short. Ten colour tokens. About a dozen rules. That's the whole system.
This post is about why that's enough, and why a small system is often better than a big one for a brand like this.
The ten tokens#
Every colour on the site comes from this list:
Ink #050605 near-black background
Moss #0F2A20 deep green surface
Pine #153B2F lighter green surface
Mint #D8FF5C the one loud accent
Cream #F3F0E8 primary text on dark
Paper #FBFAF6 brightest light surface
Smoke #A8A29A secondary text, quiet UI
Clay #F49C7E warm accent
Lilac #CFC5FF cool accent
Cyan #B8F7FF cool accent
A few things are worth pointing out.
They have names, not numbers. There's no green-700 or gray-400. Names like Ink, Moss and Mint are easier to talk about in a review and harder to misuse. Nobody accidentally picks "Clay" for body text.
The base is almost black, not black. Ink has a faint green in it, and so do the two surface colours. You'd never call the site green, but it feels different from a generic dark mode. That small tint is a lot of the brand.
There's exactly one loud colour. Mint is bright and slightly acidic. It's used sparingly, for the things that should catch your eye. If everything is Mint, nothing is.
The text colours are warm. Cream and Paper instead of pure white. Smoke instead of a neutral grey. On a near-black background, pure white is harsh. Warm off-whites read as calm.
The rules matter more than the palette#
Tokens alone don't make a brand. Plenty of sites use a nice palette and still look like a template. What holds it together is a short list of rules. A few from the guide:
- Keep the entire public site dark and restrained. No light-mode sections, no bright hero banners.
- Use rounded 2rem cards with high-contrast colour blocks. Big, soft corners. Solid colour, not gradients.
- The logo is the hero. An SVG zig-zag mark runs full width at the top and draws itself on load.
- Hide the main navigation until the header is hovered or focused. The page opens quiet. Navigation is there when you reach for it.
- The sidebar is an interactive agent-console preview, not a static menu. It shows what the company does instead of describing it.
- Use shadcn-style primitives for buttons, inputs and cards. Own the components, keep them simple.
- Sign-in screens are custom built on the auth provider's APIs, rather than its hosted default screens, so they look like the rest of the site.
Each rule removes a decision. That's the point. A rule like "rounded 2rem cards" sounds tiny, but it settles a question that would otherwise come up on every single page, and it settles it the same way every time. When the next page gets built, nobody has to debate the card style or whether a section can be light. It's already decided.
Why small works here#
Big design systems exist for good reasons. Large products have many teams, many surfaces and many edge cases. They need a scale of greys, a full type ramp and documented states for every component.
A brand site is different:
- Few surfaces. A home page, project pages, contact and sign-in.
- One small team. Often one person, plus agents.
- The goal is a feeling. The site should feel consistent and deliberate. That comes from repetition, and repetition is easier with fewer choices.
A big system on a small site tends to produce variety, because every token is an invitation to use it. A small one produces consistency, almost by default.
What the guide leaves out#
It's just as telling what isn't in the guide. There's no type scale, no spacing scale, no shadow system and no list of component states. Those come from the component primitives and sensible defaults.
That's a deliberate trade. Every extra section in a guide is something to keep in sync with the code, and something people stop reading. A guide that fits on one screen gets read. The parts it leaves out are the parts where the default is already fine.
If the site grows into a product with many screens and many contributors, that changes, and the guide should grow with it. Until then, short wins.
Constraints that help accessibility, and one that needs care#
A dark, restrained palette has some built-in advantages. Cream on Ink is high contrast, so body text is easy to read. The accent colours are all light, so they work as text or highlights on the dark surfaces.
Hiding navigation until hover or focus is the rule that needs the most care. It's a strong brand move, but it can't cost anyone access. Keyboard focus has to reveal it, the header has to be reachable, and it has to work on touch screens where hover doesn't exist. Writing "hover or focus" into the rule, rather than just "hover", is there for exactly that reason.
Tokens make agent-built pages consistent#
Midwest builds with agentic practices, so coding agents write a lot of the code. That changes what a design guide is for.
An agent will happily invent a new shade of green if you let it. It has no sense of the brand. But give it ten named tokens and a short list of rules, and it has very little room to drift. "Use Moss for the surface, Cream for text and Mint for the one thing that matters" is an instruction an agent follows well.
So the guide is written to be read by both people and agents. Short sentences. Hard rules. No "consider using". A design system that agents can follow is one that stays consistent no matter who, or what, builds the next page.
I've written more about giving agents standards to work from in Skills, Standards, and Context.
How I'd start one#
If you're building a small brand site, here's the order I'd go in:
- Write the direction in one paragraph. Who's the audience, and how should it feel? Everything else checks back against this.
- Pick one base, two surfaces and two text colours. Tint them slightly so they feel like yours.
- Pick one loud accent. Only one.
- Add a few quiet accents for variety in cards and illustrations.
- Name everything. Names you can say out loud.
- Write ten or so hard rules. Each one should remove a decision.
- Put it in the repo, where people and agents will both read it.
The takeaway#
A brand doesn't need a big design system. Ten named colour tokens and a short list of hard rules gave the Midwest site a consistent, quiet identity. The rules matter more than the palette, because each one removes a decision. And when agents are building pages too, a small, strict guide is exactly the kind they can follow.
Related
- Design
Swapping a Component Library Without Stopping the Product
Moving a React app from MUI to shadcn-style primitives sounds like a rewrite. It doesn't have to be. Here's the approach I set up: codemods for the boring parts, a thin layer of your own components, and a migration that ships one screen at a time.
Design systems · React · Front-end5 min read
- Design
Designing and Building the Same Feature
For five years my job titles had both halves in them: Interaction Designer/Developer at Pandora, then Design Engineer at eBay. Here's what changes when the person who designs an interaction is also the person who builds it, and why I think the role matters more than its title suggests.
Design systems · Front-end · Careers7 min read
- Leadership
The Tech Job Exodus Isn't New: When Opening the File Stopped Being Enough
Around 2012 and 2013, knowing how to operate the tools stopped being enough to hold a job on the web. You had to be able to build. The AI shift feels like that again, only faster. What I saw then, what's different now, and what I'd do about it.
Careers · AI · Front-end · Leadership6 min read