The brief was a live demo: an interactive prototype of the Sportster S dashboard that the audience could watch being driven from a keyboard. We had already done the design work. A Figma page held every screen and overlay in the team’s visual style, and seven logic tables described what every handlebar key does, in every state, with rule IDs we could point at.

What we had not done was build it. Wiring a round dashboard with five pages, nested settings, media keys, calls and warnings means hundreds of frames and more than a thousand links. That is exactly the kind of work where AI can help, as long as the design decisions stay ours.

111

Frames in the final prototype

~1,300

Interactions wired

1,488

Link targets, none broken

19

Spec files the AI worked from

The team made every design decision. The AI handled the build and much of the verification.

Scope is the most important element of any prompt. Without it, AI readily expands the work: additional screens, additional features, a refined version of something outside the brief. Each expansion looks like progress but does not serve the test.

Where the AI went outside our scope

Before every prompt: what is this prototype testing, and what does it not need?

We gave the same task to four models. The prompt was written once, in two versions, and kept as the record of the test. The decisive factor was not general model capability but whether the model had access to the environment where the work lives.

The test showed which model did best on our task. This part answers the question underneath it: for the work this project actually needed, what can each one do, what can’t it do, what does it cost, and what happens to our files? The rows follow our needs, in the order they mattered.

Memory, other chats and long sessions

A build of this kind runs for several hours and often spans multiple chats. Whether a model remembers earlier work, can look into another chat, and copes with a very long one determines how much context has to be re-supplied.

Privacy: what happens to the project files

Our 19 files were an internal spec, but the same setup would carry a client’s unreleased product. Before any upload, the team needs to know what each AI can access, where the data is stored, and whether it may be used for model training.

Test results come from the versions we used during the project. Prices, memory features and privacy terms were checked on October 29, 2026. They change often, and several are already scheduled to change.

The test produced five criteria we now apply before selecting a model for design work. The first is usually decisive.

Our recommendation: build with the model that can work directly in the file, and use a second model to review the logic.

The session comprised 34 messages. Afterwards we grouped them by stage and rated each one: ✓ worked first time, △ needed follow-up or rework, ✗ produced nothing. Half the stages required a rebuild, and the cause was consistent: information the team held but had not written into the prompt.

How long each prompt took

The log has a timestamp on every message, so we can see how long each prompt took, from sending it to sending the next one. The chart covers the build session, 22 prompts in about 95 minutes. These are not model run times: each bar includes the AI working plus our own reading, testing and typing.

95 min

Build session, 22 prompts

51 min

Spent on the 7 prompts that needed follow-up

42 min

Lost to two of them: wrong format, no edit access

~1 min

Per bug fix with a screenshot or recording

Rewriting the first prompt

Stage 1 is the clearest example. Across eight messages and forty minutes, the build location was never specified, so the first output was a well-built web prototype in the wrong format. A further twenty minutes were then lost to file permissions.

Anatomy of the prompt that worked

For the four-model test we rewrote the brief twice. Version 1 was one dense paragraph. Version 2 split it into four parts (visual style, interaction logic, key panel and transitions, build and acceptance), and the final version added a role, a research step and acceptance tests. These are its parts, in order.

Prompts that worked

Two prompts we now reuse as-is

A productive session has limited value if it stays in one person’s chat history. We converted ours into a toolkit: the components below are kept in a shared folder, and every new AI task starts from them.

The prompt template

Figma limits, and what we did instead

Most of the lost time came from a small set of recurring practices. They persist because each appears efficient at the time.

Style problems: send an image. Motion problems: send a recording. Logic problems: state expected vs. actual behaviour.

V1 arrived at 09:05 with 61 frames. It appeared complete; a single click-through revealed gaps. Between 09:07 and 09:54 we reviewed it, tested it from a rider’s perspective, reported problems one at a time and checked every fix. This is the record of what was wrong, who found it, why it happened and how it was fixed.

13

Problems found and fixed after V1

5

Found by our review and testing

7

Found by the AI checking its own work

0

Broken links in V2, out of 1,488

The loop we used for every fix

Final test: with AI vs by hand

For the final test we set the AI build against the same job done by hand in Figma. The AI side is measured from the session log. The by-hand side is estimated from the work counts in the finished file, at typical speeds for an experienced Figma user.

~13×

Faster

~10×

Cheaper

95 min

Our whole build session with AI, people included

~21 h

Estimated by hand

How we estimated the by-hand time

The 95 minutes are measured from the session log, from the first message (08:16) to V2 (about 09:54), and cover people and AI together. The by-hand figures are an estimate, not a timed run. Designer time is costed at $40 an hour. Neither side counts the design work done before the build (the screens, the logic tables and the 19 files), which is the same either way, or the write-up afterwards.

The prototype is functional. The following additions will make the next build easier to hand over and the next test more rigorous.

Every version gets a time, a place and a number

During the session the versions only lived in the chat. This is what we had, and how each version will be saved from now on.

Two ideas for the next build

Two ways to build, side by side

This time we generated the whole prototype at once and fixed it afterwards. Next time we will build the same thing step by step, confirming each step before moving on, and compare the two.

Quality control: three checks before a version is accepted

Quality control asks one question: does the prototype do what the spec and the real bike say, on every frame? Visual impression alone is not sufficient, so we split it into three checks that each end in a pass or a fail. The AI runs the checks; we review what it flags.

The AI score uses the same five-point rubric every time, so versions can be compared:

AI scores and AI checks are flags, not verdicts. They tell us where to look; a person decides whether the version passes.

The Figma build proved the screens and the wiring. It could not prove the behaviour: no design tool we used can show two prompts competing for the screen, a value pushed past its limit, or which overlay owns the D-pad when three are showing. So we rebuilt the dashboard as a coded prototype, and this time we did what we planned above: step by step, with a checklist written before each build.

Each layer is specified, built by AI and checked before the next one is added, and every earlier check runs again on every new version. A better layout that breaks the menu counts as a step backwards.

Before any code, the team turned a one-page brief into a behaviour specification that an AI could build from without guessing. We split the work into six stages. Each stage answers one question and hands a defined output to the next. The order matters: an AI fills every gap it is given, so each gap had to be closed, or written down, before it started.

1. 00 Known unknownsWhat can we not observe?→
2. 01 ContextWho rides, and what is on the dash?→
3. 02 Data mapWhat matters most?→
4. 03 States & routingWhat happens on every input?→
5. 04 Spec → ChecklistBuild it, then prove it

Working documents for every stage (Google Drive) ↗

Skip to the live prototype ↓

The first document was a list of questions, not answers: how many overlays can show at once, what happens when a higher-priority one arrives, whether Home dismisses an active prompt, whether holding the D-pad scrolls, how long media feedback stays. We kept it open through every stage. By the end it held 16 items, each with an ID that later tables could cite, so nothing undecided was presented as fact.

16

Known unknowns, tracked by ID

5

Pages in the loop

27

Physical controls

4

Overlay classes

Who we design for

Carson, 27, commutes through New York every day and rides out of the city at weekends. He uses navigation and music on most rides and wants speed, gear, ride mode, directions and warnings at a glance. Every priority call later in the process was checked against one question: does this help Carson keep his eyes on the road?

Non-negotiables

Out of scope, on purpose

Only two vehicle states are built: engine running while stationary, and engine running while moving. Boot, engine-off, accessory mode, shutdown, service screens, Bluetooth pairing and the full Settings tree are excluded, so the build and test effort goes where riding happens.

The documents

We listed every piece of information the screen can show and gave each a relative importance, a display area and its evidence. P0 is critical riding information or an immediate warning; P1 is feedback on an active task; P2 is supporting information or configuration. The ranking decides what goes into the protected zone and which overlay wins a conflict.

80

Information items

68

Documented by the OEM

12

To confirm with OEM / firmware

21

Sections and sub-sections

Evidence is labelled on every row. 68 items are documented in Harley-Davidson’s own material (the 2022 infotainment manual and 2021 product information); 12 come from reference images and are flagged for confirmation. The Source column uses the same names as the System Event Table, so design and engineering refer to the same signal.

The document

“When the rider presses a button, or the system reports something, what happens on the screen?” We split that question into seven tables and a shared notes file. Before prompting any AI, each table got four answers written by hand: what it is, what it collects, why it is needed, and who would provide and use it in a real programme.

How we worked with AI

1. 1 · ThinkWhat, why, who uses it→
2. 2 · StructureColumns, IDs, naming→
3. 3 · PromptOne shared context, one prompt per table→
4. 4 · CheckFour layers of review→
5. 5 · FinaliseOne file per table

Three rules kept the output honest. The AI could use only three sources: the professor’s templates, the Figma file “HMI Analysis V2026.1” and the brief. Every row carries a Basis: Template, a Figma frame, Assignment, or Proposed. And an unknown value is written as TBD and added to the known unknowns instead of being guessed.

Four layers of checking

11

Problems found in the first AI version

11

Fixed

21 / 21

Automated checks pass

178

Rows across seven tables

Carried forward as known unknowns: the main menu covers the speed band in Figma, which conflicts with a non-negotiable (KU02); there is no Figma screen for an active call (KU04); timeouts other than the menu’s 2 s are not specified (KU07).

The hardest part was judging AI output in an unfamiliar technical domain. What worked was starting from purpose rather than content: what is this table for, who hands us the information, and who relies on the result?

How the tables connect

The documents

Before any AI was involved, we hand-built a grey-box clickable flow to record our own understanding. Then we wrote the logic down, so that nothing about the behaviour was left for the AI to invent.

Every empty cell in a spec is a decision AI makes for you, and it won’t tell you.

AI extracted the position, size and content of every element from the vector reference. What no tool can read off a file is what each element shows and when it changes, so that part was ours: for every row, the value it is linked to and the events that change it.

Overlays are where the logic gets hard. A prompt, a media confirmation and the main menu can all be on screen at once, and only one of them can take the buttons. This behaviour exists only in the coded prototype.

Each overlay has an entry in a registry (layer, priority, whether it takes the D-pad, whether it dismisses itself, its timeout), backed by explicit conflict rules.

Every AI-built version is a single file with a built-in test interface: a state readout, an event log and a state inspector. Each logged event carries a rule ID that points back to the spec, so a failure can be traced to the rule it breaks.

109

Checks

107

Passed

0

Failed

2

Open, cause recorded

The team ran the same checklist themselves, on the same version. Wherever both ran a check, they reached the same result: 107 of 107. The team closed one of the AI’s open checks (G-108) by comparing the build against the design file, which the AI did not have.

The checklist is the team’s half of the verification. We wrote it so that anyone in the group could open it, run it against the prototype and reach the same result as the next person, without reading the spec first. Building version 3 took 15 minutes; running the full checklist on it took 5.

15 min

To build version 3

5 min

To run the checklist

109

Tests, 108 passed, 0 failed

0

Requirements without a test

In the latest team run, on version 3 after audit fix PR-24, 108 of 109 tests passed and none failed. One was left unmarked: G-48b, which checks that switching away while holding a key does not leave it stuck, a case that only applies to the browser simulator.

How it is connected

1. SpecEvery rule has an ID→
2. AI audit111 requirements checked by the AI (AUDIT.md)→
3. CoverageEach requirement lists the tests that prove it→
4. Group checklist109 tests run by people→
5. SummaryCounts update as boxes are ticked

Design choices, and why they work

109 tests across eight areas

The 111 requirements come from four sources, and the Coverage sheet labels each one: 36 instructor requirements, 18 from second-hand instructor sources, 19 decisions the team agreed on, and 31 design assumptions. Seven more are marked out of scope on purpose. Labelling the source shows which results answer the brief and which ones test our own assumptions.

The workbook

Open the full checklist in Google Sheets ↗

The open checks are as useful as the passed ones: they show exactly where an AI tester needs another tool, a real machine or a person.

Next for part two

Finish visual fidelity within a stated tolerance and re-run every check, since real typefaces change how wide strings are; check each version both by AI and by a person and count where they agree, by type of check; and close the two open checks.

Version 3 of the coded prototype, embedded and fully working. Click inside the frame first. Use the on-screen buttons or the keyboard: arrow keys for the D-pad, Enter for OK, P for Page, H for Home, T for Trip, Space for Play/Pause, [ and ] to skip, − and = for volume. The System events panel sends calls, warnings and “start moving”; Reset prototype starts again.