Harness Design in practice: unblocking the screen queue when there are not enough designers
This article explains how we applied Harness Design to a very practical problem at Prolog, the company where I work: there are too many screens to build and too few designers to build them. Harness Design is the discipline of giving AI the context, the criteria, and the decisions already made by the design team, so it produces with direction instead of improvising. Here, that became a tool that generates screen prototypes with AI support, following our decisions. It is called design-draft.
I will explain the context, the problem, what we solved, and how it works. The numbers and technical detail are in the Annex at the end, for anyone who wants to go deeper. One term that comes up often: Glorp is the Prolog design system.
The problem: the screen queue
With AI, whoever programs has become much faster. But before programming, someone has to understand the problem and design the solution, and this stage, which I call upstream, has not kept up. In Article 2 I wrote that the acceleration of engineering created a bottleneck in design. At Prolog the math does not add up: there are more screens to build than designers to draw them.
When the queue does not move, developers draw the screen themselves, with help from AI. I would do the same in their place. The problem is in the result. I ran a simple test: I asked for a list with detail, edit, and delete without giving any rule, and in 13 decisions the AI chose differently from what the product adopts. It copies the code it finds, and the code of an old product mixes right and wrong. Without someone saying which is which, it guesses. (Annex B explains this test and the caveat it deserves.)
Today the prototype repository holds 71 of them, saved by 14 people, and only a small part comes from designers. The demand exists, and it will not wait.
Two fronts, one short and one long
I was already working on a long-term answer, which I described in earlier articles: tokens and components prepared for AI to read, with a command-line tool inspired by Astryx, the design system Meta opened up. It is right and it keeps moving, but it is heavy. In a legacy product, the components were spread across different repositories, and the project does not get full-time attention. It does not deliver in the short term.
So I opened a second front, to deliver something useful now: skills for Claude Code. A skill is a package of instructions that it follows for a specific task. The two fronts use Harness Design in different ways. In the components front, I build from the bottom up: each token and each component gets documentation saying when to use it and when to avoid it. In the skills front, I go from the top down: I looked at the screens that already exist in the product, separated what is right from what is wrong, and turned that into rules. One helps the other, because what we decide in the skills goes back into the work on the components.
The tool: screen prototypes guided by Harness Design
The first skill is design-draft. You describe a screen or feature, in a text or a task, and receive a clickable prototype at medium fidelity: more detailed than a sketch, less than the final screen. In the tests I timed, a new flow took between 12 and 27 minutes to become ready and checked. That time belongs to the AI, and I did not measure how long a designer would take on the same request.
The first version was created by Gustavo Navarro, our engineering manager, with Kas, at the start of June. It began as a gray sketch generator. I picked up the skill later and kept improving it, and Gabriel Tavares also contributed.
To be fast, it does not use the real React and Flutter components. I asked Claude to copy the components needed into a lightweight version in HTML and CSS. In practice, this is a second version of the design system, made for the skill. We call this set of pieces the kit. This has a cost I need to state: the copy can drift from what is in production, and someone has to keep the two up to date.
The prototype comes out with several screens linked together, the product's sidebar and top bar, and the business and interface rules written as comments on each screen. The skill also draws the situations that tend to be forgotten: a field with an error, an empty list, a failed save, leaving without saving, and missing permission. And it uses more than the design system. Usability heuristics, information architecture, interaction design, and interface copy come into play, to get close to a designer who looks at the whole.
The images below come from a real delivery, the flow for a screen to manage the banners on a product's login page. Inside a canvas, the space where the prototype appears, the AI places comments on each screen. Each comment says whether it came from the AI or from a person, and what state it is in: to review, answered, accepted, or rejected.
In the board view, the whole flow appears at once, with all the screens side by side.
And a button called Components shows, over each part of the screen, which Glorp piece was used. When the kit did not have the piece, the mark warns. This helps see where the screen rests on the design system and where it does not.
The review flow is simple. The developer generates the prototype, sends the artifact to a designer, the designer comments, and the comments come back to the developer through Claude Code itself. This speeds up review for developers, designers, product managers, and anyone else in the process.
What makes the AI get it right: human decisions before it
design-draft does not invent criteria. It follows three curations made by people, and this is where Harness Design really happens.
The first is the screen patterns. Glauber Franco and I surveyed how the product solves each type of screen and decided what is right. This produced 19 rules for the web and 15 for the app. For example, a record's detail opens in a panel that slides in from the side, and deleting does not open a window in the middle of the screen. The second was a test with a real screen, which raised six points where the rule did not exist or contradicted itself, and we decided on all of them. The third was reviewing, one by one, the components copied into the kit: 124 were approved and 10 were discarded.
The rule I consider most important fits in one sentence: when the curation does not cover a case, the AI does not choose. It returns the case as a question for a person.
After that comes a kind of gatekeeper. The assembler is a small piece of code that is part of the tool itself. It does not use AI and is not another skill: it just follows written rules, always in the same way. It assembles the prototype and refuses the screen when it breaks one of these rules, for example a button that leads nowhere, a component drawn by hand in place of the existing one, or an emoji where a Glorp icon should be. On top of that, the web screen is opened in the browser and checked.
Almost every gatekeeper rule was born from a real error. One example: the product's submenu, which opens on mouse hover, kept disappearing halfway because the prototype carried an adjustment inherited from an older version. Today the menu belongs to the kit and no screen touches it, with a test just for that. The full table of errors is in Annex D.
Where we use AI alone and where a designer comes in
Not every screen deserves the same design investment, and this is where we decide where to spend the scarce time of designers. The criterion is the risk to the customer experience.
Where the flow is critical for the product and for the people who use it, a designer works in the more traditional way: discovery, research, conversations with customers, and the Double Diamond method, which alternates between opening up the problem and closing on the solution. Where the appetite for risk is higher, which includes features and internal products, we accept the risk of not allocating that work. There, design-draft is used by non-designers, mainly developers, and a designer joins if they think it is necessary, as a consultant who reviews what someone else or the AI produced.
What changes for the designer
This arrangement shifts the designer's work toward curation. They become the person with specialist knowledge to say what good design is, and to turn that judgment into something the AI can follow.
In practice, the designer works on two layers at the same time. In one, they build the harness: the rules, the criteria, and the approved pieces that make the AI design well. In the other, they review the design that someone else or the AI produced, and each review feeds back into the harness. It is a continuous flow, in which reviewing improves the base and the base improves the next screen.
The Harness Design manifesto asks who answers for what was produced. In this arrangement the answer has a name: whoever curated the rule and whoever judges the review. The AI generates and checks, and the decision about what counts as the product's standard stays with a person.
Where this will live is GlorpLabs, the internal platform we are building to curate and maintain the design system and Harness Design. The skills deliver now what GlorpLabs will deliver later. When it is more mature, the idea is that design-draft will no longer be needed, because the knowledge and the harness will all live inside it.
What this article does not solve
Improving the prototyping operation raises the chance that the screen comes out better. It does not guarantee that we are building the right thing, nor that it will generate revenue or that customers want it. That is a product discovery subject, which is not the topic here. In this article I talk about the operational side of design: how to improve, speed up, and scale the creation of screens and flows. In other articles I tell how we are scaling discovery and user research.
The other half of this operation is measuring whether a screen is good. That becomes a score from 0 to 100, and it is the subject of Article 12.
What I do not know yet
I do not know how much of what design-draft produces the team accepts. When people's responses come back to the file, rejection is low (11 out of 612 decided annotations), but those responses only came back for 20 of the 65 saved prototypes. I also do not know how long a designer would take on the same request, how many rounds of adjustment the real average requires, or whether the screen built ends up the same as the prototype. In the only case checked so far, the code followed the contract, the document that says which component to use in each part of the screen, across the 11 components and 22 rules. And I do not know whether what people who are not designers are asking the tool for is what the product needs: they draw the cards (the tasks) the product has already prioritized, which does not prove the solution is right. The coming weeks will answer part of this.
Technical annex
This part is for those who want the detail of the detail. It is not needed to understand the article.
A. Who is creating screens
In the repository where the prototypes are stored there are 71 of them, saved by 14 people. I appear in 8. The other 13 people are not designers, and together they saved the vast majority of the prototypes. Almost all came from real tasks registered in Jira or ClickUp, the task management tools the team uses.
Two caveats about these numbers. The repository records the name of whoever saved the file, which is almost always whoever ran the tool, but not necessarily. And I did not measure whether these screens were approved, or whether they were ever built.
B. The three curations in detail
Screen patterns (05/10). We surveyed how the product solves lists, detail, forms, deletion, filters, and indicators, and decided what is right. This produced 19 rules for the web and 15 for the app. Some examples:
A record's details open in a panel that slides in from the side of the screen.
The export button sits in the table footer and must not appear in the screen header.
Deleting does not open a window in the middle of the screen.
In the app, the create button is a blue pill, an elongated button with rounded corners and text. The round button with a plus sign is not used.
What motivated this curation was a test run on the same day. For a common request of a list with detail, edit, and delete, the AI decided on its own at 6 points on the web and 7 in the app. By our rules, it got all 13 wrong. It put the export button in the screen header, opened the deletion in a window in the middle of the screen, and invented the width of the side panel, among others.
There is a limit I need to state about this number. The ones who defined what is right were me and Glauber, after looking at the code. The 13 errors measure the deviation from the rules we wrote ourselves. What the test shows is that the AI, without these rules, chooses differently from what the product wants. It chose differently because it copied what the code does, and the code of a legacy product mixes right and wrong. In Article 4 I wrote that Claude Code invents when it does not find. Here I saw the complementary case: when it finds two answers in the code, it has no way to know which one is the product's decision.
Questions from the first test (06/10). A test with a screen from the product's telemetry module raised 6 points where the rule did not exist or contradicted itself. To show that a screen is loading, the skill uses the spinning tire animation, which Glorp already has, and not a skeleton, the gray drawing with the shape of the screen. We chose this because 71 of 99 screens with a table already did it that way. When a list has no create action, it is left without a create button, instead of getting an invented one.
Pieces (15 to 19/10). I reviewed each component copied from React and Flutter into the HTML and CSS version and marked it as approved, discarded, or approved with adjustment. 124 were released and 10 discarded, including the breadcrumb (the navigation path at the top of the screen), the timeline, and the split button. The observations became rules: a piece that is not on the list is not used. This approved list is the skill's piece kit. The curation also feeds the other front: what was decided here goes back into the work on the CLI, the tool that delivers component documentation to the AI, and into the components harness.
C. Questionnaire, assembler, and tests
Before drawing, the skill answers a questionnaire of 17 questions about the screen, such as where the main action is, where editing opens, and how a deletion is confirmed. Each answer cites the curation rule that supports it. Then it assembles the screen from a ready template, already with the kit's pieces, changing only text and data.
The assembler refuses the screen in more than 20 situations, divided into four groups:
broken flow: a button that leads to a screen that does not exist, a map screen with no file, or a comment pointing to a nonexistent screen;
curation pattern: the "Export" button or the record count in the screen header, or an old component that imitates the side drawer or the step-by-step wizard, instead of the kit's component;
product bar and menu: a screen that draws its own sidebar or top bar, instead of using the product bar the kit fits in, or a screen whose style touches the kit's menu (in the submenu, in the hover area, or in the bar's scrolling);
brand: any emoji in the interface, because the Prolog brand prohibits it. The check catches figure emojis, such as faces, objects, and colored symbols. Simple symbols, such as ✓ or ⚠, pass.
The assembler also checks whether the kit itself is complete, for example whether the product bar file exists.
Each web screen must be opened in the browser at 1366 by 700 pixels, the size of a common laptop screen, and checked before going for approval. When the session has no browser available, the skill cannot check and is required to state "not visually checked", with the reason.
When the prototype creates a new module in the sidebar, an automatic test moves the mouse diagonally to the submenu, to make sure it does not close on the way. The test takes about a minute. Without the automatic browser, it is skipped, and the rule tells the person to hover over the submenu by hand before approval. The kit has 16 test files, and the standard test runs 13 of them at once. The submenu test is left out and runs separately.
On new screens, the skill still runs three reviews before asking for approval: design, copy, and accessibility, and it fixes what is cheap to fix.
D. Usage errors that became rules
What went wrong | What changed |
An agent said a product screen did not exist, and it did (23/09) | When the search says "not found", the skill searches again before believing it |
A prototype was rejected because the skill used an outdated copy of the product's code, 1,136 changes behind the version in use (05/10) | Before drawing, the skill checks whether the copy is up to date |
A 30-screen prototype drew filters, panels, and charts by hand, even though they already existed as components (06/10) | Using the kit's piece became mandatory, and anything drawn by hand to imitate a component is refused |
The list already opened with selected rows, and test buttons, such as "simulate error", appeared on the screens | The list opens with no selection, and the selection got its own screen. Only buttons the product will have appear |
The submenu closed halfway through the mouse's path because of an adjustment inherited from an old prototype (08/10) | The menu's behavior now belongs to the kit, never to the screen, with its own test |
Each error becomes a written rule, and each rule is locked by an automatic test so the error does not come back.
E. What the comparative tests showed
23/09: sketch versus prototype. I made the same request both ways, a gray sketch and a clickable prototype. The prototype took 4 minutes more (13 against 9) and delivered 9 screens instead of 4, and 73 annotated rules instead of 26. Three of the extra screens nobody had asked for: a field with an error, discarding changes, and a failed save. That decided the change to the prototype.
06/10: three versions of the skill. I compared three versions, each made by a new agent that did not see the previous ones, with the count done by a program. I repeated the measurement afterwards and the result came out the same. The program counts a screen as "made with kit pieces" when it loads the style of those pieces. The result was 0 of 30 screens in the first version, 28 of 29 in the second, and 32 of 32 in the current one. Elements drawn by hand to imitate a component: 393, 0, and 0. Assembler warnings: 8, 8, and 0.
This number needs context. The assembler refuses imitation, so the 32 of 32 is guaranteed by the rule. It shows that the rule works. Whether the screen came out good for the person using it, this number does not say. And loading the style of the pieces does not mean every component on the screen is a real piece: in the current version, 68 of the 358 areas marked were left as "no piece captured", and the screen says so.
13 and 14/10: unifying two tools. We unified two similar tools and timed 24 runs before and after. The new version generated more screens (from 8 to 13) and 8 times more review findings, with 40% more time until approval. This comes from a single request and should not be read as a general rule.
Times. A new flow from a task took between 12 and 27 minutes from the request to the checked prototype. An adjustment to an existing screen took between 6 and 21 minutes. All of these times are the AI's.
F. How much of what the skill produces the team accepts
Of the 65 prototypes with annotations stored in the repository, which add up to 3,063 annotations, 2,435 (79%) are still marked as "to review", 601 (20%) were accepted, 16 answered, and 11 rejected. This happens because people's responses only came back to the stored files for 20 of the 65 prototypes. Among the decided annotations (accepted and rejected, 612 in total), rejection is low: 11. Even so, the number does not say how much was really accepted in the other 45 prototypes.
Comments