Design needs a harness too — Denis Kharchenko

Denis Kharchenko — Lead Product DesignerDesign needs a harness tooWhat a design harness is, and how to write skills an assistant can followMore and more of how a team works is written down for an AI assistant to follow. A harness is that written-down way of working: a set of skills, each one a procedure for a single job, and the files they keep. The assistant follows the skills; the files remember what happened.Product and engineering often get harnesses first: one to turn an idea into a spec, one to turn a spec into shipped code. Design tends to sit between them in practice, but not in the tooling.Where design goes missingWhen that happens, design becomes an input rather than a participant. A product workflow might read design files as background, but nothing in it produces a design. An engineering workflow plans how the code is put together, not what the thing looks like or how it behaves.So design decisions have nowhere to live. They end up in a comment, a chat thread, or someone's head. When a screen is built, there's no record of which design it was built against, or why that design won over the alternatives."The screen itself, with the flow, the states and the edge cases a user sees, belongs to neither document."A peer, not a layerThe tempting shape is a layer in the middle: PRD, then design, then code. I think that shape is wrong.A layer in the middle means engineering waits for design. It adds the first hard dependency to a system that was working without one, at exactly the point where product and engineering already connect least well. It is also wrong in practice. Plenty of engineering work has no interface and needs no design. Plenty of design work, like cleaning up the design system or exploring a concept, is not downstream of anything.So the design harness is a peer. It attaches sideways to both. To the product side, it offers evidence and settled decisions the PRD can lean on. To the engineering side, it offers a specific, pinned reference: this screen, this version. And it owns the work that belongs to neither, like the design system, which outlives any single feature.The rule that holds it together is short:"Nothing waits on anything."Reviews, findings and designs are records, never gates. A review is something you prepare for and write down, not permission to move on.What it keepsEach piece of work gets a few plain files: how the product works today, what competitors do, the states every screen has to handle, and the decisions. Every file opens with a picture (the current flow, a state map, the concepts next to what exists) and a five-line summary. The text underneath keeps the why.The decision log was the single biggest gap. It records what was chosen, why, and the options that were rejected, so the reasoning survives the comment thread and someone can answer "why is it like this?" months later.And before anything is shared, every screen has to handle every state:

empty

error

no permission

realistic volume

A piece of work, start to finishEverything starts from one command. It asks once how big the work is, then walks it one step at a time:

Quick A label, one screen, a small fix. Edge cases, a mockup, a design check and a recorded decision. No reviews.

Standard A feature or a flow. Discovery through to the design review.

Full A new area. Every step, through the build and past the release.

Each turn shows a short map of where the work stands and suggests one next step. The step runs only when the designer says yes. You can skip, repeat or jump; a skipped step simply shows as skipped.How it works today → questions and states → how others solve it → concepts → check → decision → full design → handoff → design QA → after releaseAlong the way, everything recorded becomes a design document that sits next to the PM's PRD: first the concept, then the design, then what was built.When the design is ready, the handoff packages it for engineering with the exact version pinned, so the build has one clear reference. Once it is built, the screens are checked against the states and decisions that were recorded. A person judges the match; the harness prepares the evidence. After release, one question closes the loop: did behaviour change the way we intended? The answer feeds the next discovery.Writing skills that hold upMost of the work in a harness is writing: instructions an assistant can follow well, day after day, for people who didn't write them. A few rules make the difference:

Give each skill one job, but keep the list short. My first version had seventeen skills. The ones that always ran together became one, and it settled at twelve. Fewer names means fewer to remember.

Keep descriptions short. A skill's description stays in the assistant's memory all the time and decides when the skill runs. Every extra sentence there is paid for in every session.

Give people one way in. A single start-here command that knows where the work stands is easier to trust than a menu of skills. It suggests the next step and never chains skills unasked.

Check before you rely. Before using a tool, a skill makes one small, read- only call. If the tool is missing, it says in one line what that affects and carries on with what works. It never quietly switches tools or guesses at what it can't see.

Read by default. Nothing is published, sent or changed as a side effect. Edits happen only where the designer asked for them.

Never invent. How the product behaves comes from evidence, and the evidence is cited. A gap is recorded as a gap.

Use the names people already use. I renamed every skill once I noticed the prefix read as "design system" to most designers. A name that needs explaining gets misused.

One rule matters more than the others: let the team teach the harness. There is a list of what counts as slop: anything generic enough to have been made without thinking about this user and this product, from hype words to fake- looking data to decoration standing in for an idea. Every check runs against it. And when a designer calls something slop, it is added to the list, so the next check catches it too."The quality bar belongs to the team, not to the prompt."Where to startIf you're building a harness for your own team, I'd go in this order:

Find where decisions get lost. Comment threads, chat, someone's memory. That is the gap the harness exists to close.

Write the rules before the skills. What the assistant must never do, where the record lives, and that nothing waits on anything.

Build the record, then the connections. Give design its own files first. Then connect them to product and to engineering.

Hand the quality bar to the team. A list people can add to beats a prompt nobody can see.