01
Glanceable by design
The rider cannot look away for long, so the dashboard needed clear hierarchy and fast recognition.
Vibe Coding an Embedded Motorcycle Dashboard
A UX case study on AI-assisted prototyping for a 4-inch Harley-Davidson Sportster S dashboard
I approached this project as an experiment in learning how to work with AI critically. My goal was not to create a perfect prototype, but to understand how far vibe coding could go when the interface was not a simple website or mobile app.
Role
UX Designer / AI-assisted prototyper
Tools
Claude, Codex, ChatGPT
Focus
Embedded UI, state machines, interaction logic
Project Challenge
This was not a normal app screen
The prototype was a 4-inch digital motorcycle dashboard. That meant I had to think about rider attention, physical controls, safety rules, and what should happen when several system events happen at once.
02
Physical controls
The UI had to work through motorcycle controls like Page, Home, Trip, and D-pad input instead of touch.
03
Riding guard rules
Some features, especially Settings and Diagnostics, needed to lock or change behavior while riding.
04
Priority overlays
Low fuel, incoming calls, and prompts needed interruption rules so the rider always sees the highest-priority event.
05
Small screen, big system
The interface only had five main sections, but the logic underneath included states, triggers, guards, overlays, and edge cases.
My Process
Analyze → document → build → test → repeat
I treated vibe coding as a learning loop, not a shortcut. Each prompt became a design decision, and each failure told me what I had not explained clearly enough yet.
Analyze
I studied the dashboard structure, rider context, and safety constraints.
Document
I mapped sections, controls, states, overlays, and guard rules.
Build
I used AI to create working HTML, CSS, and JavaScript prototypes.
Test
I tested the output with checklist criteria instead of trusting the visual result.
Repeat
I updated prompts and prototype logic based on what failed.
back to analyze
System Logic Under The Surface
The hard part was what the screen had to remember.
Once the prototype became interactive, I had to define the invisible rules behind the interface. These were the concepts that made the project more like an embedded HMI than a normal website. Every tag below shows up in the simulator further down the page.
State
State
A state is where the system currently is, like Home, Navigation, Media, Vehicle, Settings, or Settings Locked.
Transition
Transition
A transition is the move from one state to another, such as pressing Page to move from Home to Navigation.
Trigger
Trigger
A trigger is what causes the system to change, like a button press, a low-fuel event, or an incoming call.
Guard
Guard rule
A guard rule decides whether a change is allowed, like blocking Settings while the motorcycle is moving.
Overlay
Overlay
An overlay interrupts the normal screen when something important happens, such as Low Fuel or Incoming Call.
Edge case
Edge case
An edge case is the situation that breaks the simple version of the design, like receiving a call while another prompt is active.
Iteration Process
From prompting to system thinking.
At the beginning of this project, I thought the hardest part would be building the dashboard interface. After three iterations, I realized the bigger challenge was learning how to communicate system logic clearly enough for AI to build it without guessing.
Each iteration taught me something different. The first showed me the limits of a generic prompt. The second helped me understand the cost of long chats, token limits, and visual replication problems. The final iteration with Codex gave me the strongest result, but it also proved that AI still needs detailed guidance, testing, and human decision-making.
How close each iteration got
Same frame, same scale — switch between the three attempts and the bike itself.
Iteration 1: useful for testing logic direction, but not visually close enough.
Iteration 1 / Claude Sonnet 4.6
Starting with the logic
For the first iteration, I gave Claude all of my motorcycle dashboard logic documents and asked it to create a prototype. My main mistake was making the prompt too general and expecting the AI to understand the full system at once. Claude understood some of the logic, but the visual design was weak. The result felt more like a logic test than a realistic Harley-Davidson dashboard prototype.
Iteration 1: useful for testing logic direction, but not visually close enough.
Reference: actual Harley-Davidson dashboard home-screen proportions.
What worked
- The prototype started to follow the system logic from my documents.
- Claude understood some of the dashboard structure.
- The process showed me that detailed documentation matters.
- It gave me a starting point for testing embedded UI logic.
What did not work
- The prompt was too broad and not specific enough.
- Claude made assumptions instead of asking questions.
- The visual design did not look close to the actual dashboard.
- I treated the AI like it could solve the whole project at once.
Key takeaway
Prompting is part of the design process. I should have asked Claude to plan first, break the project into smaller parts, and ask me questions before making decisions.
Iteration 2 / Claude Opus 4.7
Trying to improve the visual design
For the second iteration, I tried to make the dashboard look closer to the real Harley-Davidson Sportster S display. At first, I continued from the previous Claude chat, but the chat had become too long, so Claude started losing context and using tokens quickly. I then started a fresh chat with Opus and worked more step by step. The result improved and felt more like a circular motorcycle dashboard, but it still did not fully match the reference.
Iteration 2: closer circular structure, but the lower notch and proportions still needed work.
Cleaned reference image used later to guide the final Codex build.
What worked
- Starting a fresh chat improved the results.
- Breaking the work into smaller steps helped Claude perform better.
- The dashboard became more circular and more motorcycle-like.
- The logic still worked fairly well because the original documents were detailed.
- I learned how important model choice is for complex design tasks.
What did not work
- Continuing the old chat caused context and token problems.
- Claude struggled to replicate the dashboard accurately from reference images.
- The bottom curved notch was especially difficult to recreate.
- Some visual fixes broke other parts of the design.
- Token limits slowed the process and made experimentation harder.
Key takeaway
AI is not always good at visual precision, especially when the design depends on specific shapes, spacing, and proportions. A fresh chat, a clear plan, and smaller prompts produced better results than one long overloaded conversation.
Iteration 3 / Codex GPT-5.5
Building the strongest prototype
For the third and final iteration, I switched from Claude to Codex, which made the process smoother and gave me more room to experiment. This time, I started with a clearer process. Before adding all the logic, I focused on replicating the home screen as closely as possible.
The first result was better than earlier versions, but it still needed refinement. I realized my reference image was a low-quality YouTube screenshot, so I used Gemini to clean it up and remove the background. After giving Codex the improved reference, the design became much closer.
A method that helped a lot was drawing on screenshots to mark problem areas. When I did not know how to describe a shape, I asked AI what to call it, then used that wording to write more specific prompts.
Iteration 3: Home page
Iteration 3: Home page
What worked
- Codex handled the project more smoothly than Claude.
- It was better at recreating the dashboard from reference images.
- Token limits were less disruptive.
- Starting with the home screen helped control the design.
- Using a cleaned-up reference image improved the visual result.
- Screenshot markup helped me explain specific design problems more clearly.
What did not work
- The bottom curved notch still required many prompts to fix.
- Adding the same visual system to every page caused layout issues.
- Some shapes overlapped when new design elements were added.
- A few logic items still did not work perfectly.
- Bottom information icons like fuel, time, and other indicators needed more polish.
- When I tried to add too many visual details, parts of the design broke.
Key takeaway
Codex gave me the strongest result, but it still required constant direction. The biggest improvement came from combining clear system documents, better reference images, smaller tasks, and visual markup.
Final Prototype
Stage 29 tested the full system, not only one screen
The final prototype included multiple sections, locked states, and prompt overlays. These screenshots show the kinds of states I checked during manual testing.
Try the logic
Press Page to step through the five sections, then switch between Riding and Parked to see the guard rule lock or unlock Settings. Raise Low Fuel or Incoming Call to interrupt the screen with an overlay, or raise both to find an edge case.
Handlebar buttons
Trip and the D-pad are not simulated, because their behavior is not documented on this page.
Bike status
Alerts
Back to Home, riding, no alerts.
Riding. Press Page to move through the sections.
- State
- Home
- Bike
- Riding
- Guard rule
- none active
- Overlay
- none
- Last trigger
- —
The state machine underneath
Page steps through the sections. The diagram follows whatever you press.
Home
Navigation
Media
Vehicle
Settings
Settings Locked
Home returns to the Home state from anywhere.
This replays the prototype's documented logic using screenshots from the Stage 29 build; it is not the running prototype. The overlay stills were captured over the Home screen, so they show Home underneath whichever section you raise them from.
The states I checked
How I Measured The Prototype
AI checklist plus manual testing.
To measure the prototype, I used two types of testing: an AI-assisted checklist and my own manual review. The checklist helped me evaluate structure and logic, while manual testing helped me catch visual and interaction problems that were easier to notice by actually using the prototype.
AI checklist testing
The checklist turned the prototype into measurable criteria instead of relying only on opinion. It helped me check expected logic, states, guard rules, overlays, and page structure.
Manual testing
Manual testing helped me evaluate the prototype like a designer. I could see when shapes overlapped, when the hierarchy felt off, or when something technically worked but did not feel polished.
What I learned from both
The checklist was best for structure and logic. Manual testing was best for visual quality, interaction feel, and whether the design matched my intention.
FINAL MANUAL SCORE
88 / 90
97.78% passed on the Stage 29 manual checklist.
Appearance
20 / 21
Manual logic
68 / 69
Failed
2
Untestable
0
Why Vibe Coding Was Harder Here
Visual similarity was not enough
AI tools perform well with common requests like "build me an app" or "make a landing page." There are millions of those examples in their training data. An embedded motorcycle dashboard is not one of those things.
Claude, Codex, or Figma Make could draw a screen that looked close. What they struggled with was the logic underneath the screen: the rules that decide what should happen when the rider presses the Page button while a Low Fuel warning is active, the vehicle is moving, and the headset is disconnected.
Figma can hide that complexity, because static screens never have to answer "what happens next." HTML has to. That forced me to think like an engineer as much as a designer.
Actual Sportster S reference image used to judge shape, hierarchy, and visual accuracy.
The realization
Visual similarity was not enough. The prototype also needed correct logic, and that is where AI needed the most direction from me.
Final Reflection
This project changed how I think about UX screens
This project helped me see that UX design is not only about screens. It is also about the logic underneath the screens. Working with AI pushed me closer to how designers and engineers communicate, because I had to describe states, triggers, guard rules, overlays, and edge cases instead of only describing how the UI should look.
I also learned that creative ownership matters more when AI is involved. AI helped me build faster, but I still had to decide what counted as good, what counted as unsafe, what needed to be tested, and what failures should stay visible in the final story.