Exam	Students	Format	What they wanted most
MCAT	4	Live Online	Skill mastery map, accuracy analytics, time analysis
LSAT	6	Live Online	Explanation quality, question type mastery, elimination logic
SAT	6	In-person class	Customizable plan, test countdown, readable explanations
GMAT	1	Live Online	One dashboard instead of four places
GRE	1	Self-paced	Pacing: where did my time go
ACT	1	Live Online	Realistic practice, clear daily structure

Signal	Metric	Apr 2026	What it tells us
Happiness	Platform ease of use, 1 to 5	4.36	Held flat through a full navigation replacement. 439 respondents.
Engagement	Completed 80%+ of content	83.0%	Separates logging in from doing the work. 2,825 students.
Adoption	Free to paid conversion	1.49%	Year on year the rate went 1.22% to 1.83%, up 0.61pp.
Retention	Mid program drop-off	35.6%	New definition: 2 of 3 signals down more than 25% between halves.

Workstream	When	Where it got to
Cross-product design system, 20+ programs	2023 to 2026	Shipped, maintained
Dashboard 2.0, consolidation	2024 to 2025	Shipped
Dashboard 3.0 and SAT Self-Paced personalization	2025 to 2026	In build at handover
Score report redesign and focus areas 9 SAT students: 7 in person at the NYC center, 2 self-paced. 1:1 interviews plus prototype testing. Rebuilt around four mistake patterns: misreading, concept gaps, strategy errors, pacing.	Feb to Apr 2026	Presented at Feature Review, 13 Apr
Free trial experience, aimed at conversion	Mar to Apr 2026	Concept delivered in two weeks, presented 15 Apr
Productive struggle discovery	Mar to May 2026	Concept accepted, own case study
Flexible attendance	Feb to Apr 2026	Baseline analysis, then shipped
Post free-practice-test experience	Feb 2026	Designs per test type, partner led
Desmos calculator header	Feb 2026	Shipped
Product metrics definitions and monthly report	2026	Live, feeding the monthly business review
Light and dark mode, feature parity across course types	2025 to 2026	Shipped

Assessment objective	Items	Can a repeated-mistake pattern form?
Unit conversions	1	No. The bank is exhausted after one question.
Nouns	3	No. Not enough to form a pattern and then practice against it.
Standard English Conventions whole domain	400+	Yes. Aggregate up to domain level.
"Plugging In" strategy tag, cross-domain	99	Yes, and it targets behavior, which improves faster than knowledge.

LIFE3 for Climate Tech Academy · Client work, passcode protected · 18 min read

BMS Simulator

Designing a way to teach diagnosis when the equipment you need to learn on is expensive, occupied, and unforgiving.

My role

Designer and design engineer. Equipment graphics in SVG, interaction model, backend requirements, and the build, including the Supabase backend.

Team

Curriculum lead, a subject matter expert from the field, and me

Dates

Summer 2026

Status

v1.3, in classroom use

Contribution

Product design Interaction model Requirements specification Control logic Instructor tooling Equipment graphics (SVG) Front-end build Integration testing

Tools used

SVG Claude React HTML/CSS/JavaScript Figma

Abstract

Building operators learn their job at a workstation, watching a building misbehave and working out why. Students at Climate Tech Academy could define the vocabulary and pass the quiz, then freeze in front of a real station. I designed a training platform around two users with very different needs, a student learning to diagnose and an instructor running a room, and built much of it myself. Auditing the existing prototype first turned out to matter more than any screen I drew.

In short

Problem

Diagnosis can only be learned by doing it, and there was nowhere safe to practice.

Users

Students learning to read a building, and instructors running a class of fourteen.

Discovery

An audit of the existing build found the simulation was never actually running.

Design

One interaction model, three modes, and an authoring flow so instructors can make their own exercises.

Shipped

Seven screens, fifteen exercises, in classroom use. Runs offline.

Not yet tested

I have not watched a full class use it. What that means is at the bottom of this page.

Decision record

Rejected

Scheduled faults, because students learn the timing instead of the diagnosis, and a simplified teaching interface, because students would have to relearn real operator software.

Trade-off

Fidelity over approachability. The interface follows real workstation conventions, and the teaching layer lives in the modes, labels and legend rather than a friendlier UI.

Edge cases

An exercise that can never be passed is blocked by a validation warning at save, overridden values announce themselves, points without history get an explanatory empty state, and a guessed capstone URL returns a clear access screen.

Navigation

Station, then point detail, then alarms and reports. Instructors add authoring and the Exercise Report from the same shell.

Testing

Validated with the curriculum lead and a subject matter expert, and 251 automated tests. Not yet tested with a full class, which is stated on the page.

Status

Live and in classroom use. Credentials are on this page.

Have a look around

Open Free Explore, load an exercise, or drop a damper to zero during occupied hours and see what happens.

Open the live simulator ↗

Studentcta_student · bms2026Instructorcta_instructor · bms2026

The operator station showing an equipment schematic, controls sidebar with its color legend, outside air conditions and a carbon compliance panel

Fig. 1. The station running live against real weather. Schematic, controls with their legend, outside air conditions, and the clock-state pill at top right.

Problem

A guest on the fourth floor calls down to say the conference room is stuffy. Somewhere in the basement a workstation is showing forty values, one of which explains it. Finding that value is the job.

You cannot teach that from a slide, and you cannot hand a class the live controls of an occupied hotel. So the course taught vocabulary instead. Students could define an economizer, an air handler and a variable air volume box, and pass. Then they would sit in front of a real station and not know which value to look at first.

A building system is invisible. There is no fault to look at. You read supply air temperature against setpoint, damper position against outside conditions, valve positions against each other, and you form a hypothesis. That loop is the job, and the course never taught it.

Users and roles

The obvious user is the student. But an instructor has to be willing to bring the product into a room before a student ever sees it, and on an earlier project I designed the learner experience first and the instructor experience second. It nearly cost us the pilot. This time I treated them as two connected experiences from the start.

Their needs pull in opposite directions. A student wants time and room to be wrong. An instructor wants to move a room of fourteen people through a specific idea in a specific twenty minutes. One screen trying to serve both would have served neither, so the platform has modes.

Student

Learning to read a building

Needs a building that behaves believably, and a safe place to be wrong in front of their classmates.

Can change setpoints, override values, acknowledge alarms, inspect any sensor and complete the assessment. Cannot edit schedules.

Instructor

Running the room

Needs to load the right situation at the right moment, with no prep time, and find out afterwards who understood it.

Everything a student can do, plus editing schedules, authoring exercises, unlocking the assessment, and the Exercise Report.

Constraints

Three things about the room decided more of this design than anything on a mood board.

The classroom is not a studio

Training centers have bad wifi and locked-down machines. So the whole thing loads from one page and runs offline afterwards, with no build step and no server the center does not control. Assessment answers save locally, because a student who loses their connection halfway through should not lose their work.

Instructors have no prep time

A tool that needs setting up before class is a tool that gets opened once. Fifteen exercises ship ready to load, and instructors can author their own without leaving the screen they teach on.

It has to transfer

Students will go on to sit at real operator software. A friendlier teaching interface would have been easier to design and worse at the job, because they would have to learn the real one afterwards anyway. So the interaction model follows the conventions of the tools they will actually use.

Domain research

I am not an HVAC engineer, so the first month was field research. I sat with the curriculum lead and a building-operations subject matter expert and had them walk me through sequences of operation: how an air handler moves from unoccupied setback to occupied mode, when the economizer opens the outside-air damper instead of calling for mechanical cooling, what an operator checks first when a tenant calls in a hot conference room.

Those sessions produced the spec. Every behavior in the simulator traces to something an instructor said a real building does, and every fault rule traces to something they said students routinely miss.

Supply air temperature

The first thing an operator reads. Discharge temperature against its setpoint tells you whether the coil valves are keeping up before any zone complains.

Economizer lockout

Free cooling only when outdoor enthalpy is below return. Outside that band the outside-air damper returns to minimum position and the chilled-water valve takes over.

Minimum outdoor air

ASHRAE 62.1 ventilation minimums. A damper below 5% while the space is occupied is a code problem, not just a comfort one, so it became a fault rule.

Simultaneous heating and cooling

Preheat and cooling valves both open past 20% means the building pays twice for the same air. Instructors called it the most common and most expensive mistake.

Acknowledged is not cleared

Operators acknowledge an alarm to say they have seen it; it clears only when the condition does. Students conflate the two, so the alarm summary says it in its subhead.

Equipment graphics

Every piece of equipment on the station is a vector I drew in SVG: the air handler with its supply and return fans, outside-air, return-air and exhaust dampers, filter bank, preheat and chilled-water coils, the VAV box with its reheat coil and primary-air damper, and the cooling tower.

They are drawn for binding, not decoration. The board is two 1613 by 878 SVG schematics written as templates, one shared by AHU-4-3, 4-6 and 4-4 and one for AHU-23-1, with every component its own group and every live value a template slot. The front end fills them from the point registry: fans spin only when their status point reads on, damper blades rotate to the commanded position, coils tint as their valve opens, and a component in alarm takes a red ring. The schematic is the data, rendered.

Values sit where an operator's eye expects them, beside the component they measure, in the same density a real workstation uses. A friendlier, sparser diagram would have been easier to read and worse at preparing students for the software they will actually sit in front of.

The AHU-4-4 equipment graphic: supply and return fans with VFDs, outside, return and exhaust dampers, preheat and cooling coils with valves, freeze pump, filter and sensors

AHU-4-4, built as an SVG schematic with every component its own group and every live value a template slot.

Five close-ups from the AHU-4-4 board: supply fan with VFD, preheat coils with freeze section, cooling coil with valve, economizer dampers, and return fan with VFD

Component close-ups. Each part binds to a point in the registry, so its state on screen is its value in the model.

Data model and backend

Before building anything I wrote the backend requirements as testable statements, then built it, front end and Supabase backend, with Claude Code against that spec. The data model is where most of the product decisions actually live.

Point registry

Every value is a point with an address, a type (analog input, analog output, binary input, binary output, analog value), engineering units, a valid range, a change-of-value increment and a writable flag. The whole UI routes on those addresses.

Simulation clock

A clock that runs paused, live, or up to 1000× speed, interpolating between hourly rows of real exported building history and TMY3 weather, so values move continuously instead of stepping once an hour.

Command priority

Writes resolve through Auto and Manual states. A point in Manual stops following interpolation and holds its value, which is the mechanic every override exercise depends on.

Fault engine

Rules evaluated against live point values on every tick, per piece of equipment, so a student can cause a fault by overriding the wrong point and the system catches it.

Change-of-value filtering

Analog points notify subscribers only when a change exceeds their increment. Without it a fast-forwarded clock repaints every value every frame.

Exercise schema

A starting timestamp, the set of changed points, a success criterion derived from a point and its setpoint with a tolerance, the ASHRAE standard behind it, and an assignment list.

Roles and access

Six privilege levels from view-only to manager. Students write setpoints and acknowledge alarms; instructors author exercises, edit schedules and unlock the capstone.

Supabase backend

I built the backend on Supabase: Postgres tables for profiles, exercises, assignments and attempts, email accounts with password reset, and row-level security so a student can only read exercises assigned to them (an is_assigned_to_me() policy). The schema lives in a re-runnable SQL file.

Sync and offline

A write-through cache: every screen keeps reading synchronously from local storage, and changes push to Supabase in the background. If the network drops mid-class the app keeps working, and an instructor can upload local exercises to the server later.

Assignment and progress

Exercises assign to the whole class, a group or individual students, all flattened to one seat list so nothing downstream changed. Student progress saves continuously and restores on resume, so a multi-hour exercise survives signing out.

Verification

251 automated tests, including an integration suite that loads every real exercise against the real registry and asserts each one changes the building. Deployed on Railway, with Supabase for auth and data.

The point detail modal for AHU-4-4 spill air damper, showing the value rail with gauge and status dots, and the General, Command Priorities, Alarms, History and Recent Events tabs

The point detail modal, captured from the running app.

Spec-driven build

I drew the equipment graphics in SVG, every air handler, damper, valve, coil and sensor as its own labelled vector, then designed and built the product with Claude. The workflow is worth describing, because it is the reason a single designer could ship a product this large without the result being a set of screens that only look complete.

The input was not a prompt. It was a set of real source material and three documents I wrote before any code existed: a requirements spec, a design doc, and a task plan. Claude worked against those rather than against a conversation.

Start from real source material

Training slides from the subject matter expert, a fourteen-chapter reference guide, twenty-seven spreadsheet exports of real system history, an EPW weather file, and the building’s filed energy data. The simulator had to be accurate before it could be good, so the data layer came first and everything else was built on top of it.

Write requirements as testable statements

A numbered spec of roughly 366 lines, written in the form WHEN this happens, THE system SHALL do that, with a glossary fixing every term so point, override, security level and scenario each mean exactly one thing. That reads like engineering hygiene and it is mostly interaction design: deciding that six privilege levels stack in ascending order, or that an overridden value stops following the data, is a product decision written in a format somebody can check.

Sequence the build by dependency

A task plan of about 404 items in strict order: data conversion, then the simulation engine, then interface chrome, then point detail, then alarms and schedules, then the teaching modes, then integration. Every task carries the requirement numbers it satisfies, so nothing gets built that no requirement asked for and nothing in the spec quietly goes missing.

Keep the reference in context

A steering document holds the domain reference so it is present in every session rather than re-explained each time. The design equivalent is that decisions live in a file, not in my memory of a conversation three weeks ago.

Then read all of it

This is the step most teams skip. A spec makes the result checkable, and checking it is what surfaced the defects in the next section. Generated code that passes its own tests can still be wrong about the system it lives in.

What the tool changed is throughput, not judgment. It did not decide that an alarm should distinguish seen from fixed, that a magenta value means someone has taken manual control, or that authoring belongs on the same screen students use. It made implementing those decisions possible at a scale one designer could not otherwise reach, and it made being wrong cheap enough that rewriting a fault rule was easier than defending it.

Technical audit

A version had already been generated with an AI development tool, and it looked finished. Every screen was there and it passed its own tests. I read it properly before trusting it with a classroom.

The simulation clock was never connected to the data. The timestamp advanced in the status bar, which is where your eye goes, but no value ever moved. The building looked live and was static.

Underneath that, all fifteen exercises silently did nothing. Each referenced points by an address format that did not exist, and writing to an unknown address fails quietly. Loading an exercise jumped the clock and staged none of the conditions. Three of the six fault rules pointed at sensors that were not in the data model at all, so they could never fire.

The tests passed because each piece was tested against its own assumptions rather than against the system. Everything was correct in isolation and wrong together.

Had this reached a classroom, students would have been asked to diagnose a building that never changed. I fixed the data layer, corrected every address, rewrote the three impossible rules, and added a test that loads the real exercises and checks each one actually changes something. Then I reintroduced the original bug to confirm the test caught it.

Design principles

Three established principles governed the work, and every screen decision traces back to one of them.

Visibility of system status

Nielsen’s first heuristic, and the one this product lives or dies on. A teaching tool that looks correct while being wrong is worse than one that is obviously broken. The clock names its own state, overridden points are color-coded, and any value that has stopped reflecting the building says so. The audit finding below is exactly this heuristic being violated: a running timestamp over a frozen dataset.

Learning by doing, with productive failure

Kolb’s experiential learning cycle, and Kapur’s work on productive failure: learners retain more when they struggle against a real problem before being told the answer. So the platform never says incorrect. The building behaves badly and the student discovers their hypothesis does not explain the readings. Feedback is whether conditions have improved, which is the only feedback the job itself gives.

Design for the adopter, not only the end user

In enterprise and edtech the person who adopts a product is rarely the person who uses it most. Instructors are the adoption gate here, so authoring, loading and reviewing were treated as primary workflows rather than admin screens. Getting this backwards on an earlier project nearly cost us a pilot.

Student experience

The core interaction is reading a screen full of values and deciding which one matters. Most of the design work went into making that decision possible for someone doing it for the first time.

State is visible at a glance

Five states, printed at the top of the sidebar rather than left for students to work out. A white box is an editable setpoint, gray is calculated, a dark pill is a measured value, a red ring means in alarm, and magenta means someone has overridden it. A beginner can see the condition of the plant before reading a single number.

Overridden values announce themselves

When a value is overridden it stops following the building and holds where it was left. That is the most dangerous state to misread, so it gets the loudest treatment, and a report screen exists purely to find every value somebody left in manual.

The clock always names its state

A pill in the header reads LIVE when the building is following real weather, FROZEN when it is paused, and AUTHORING while an exercise is being built. A student should never have to guess whether they are watching the building behave or looking at someone’s setup.

Alarms distinguish seen from fixed

Acknowledging an alarm and clearing it are different acts, and the summary screen says so directly in its subhead. Unacknowledged alarms blink, acknowledged ones go solid, and the acknowledgement survives the condition going away. Students consistently conflate the two, and the interface is doing the teaching here rather than the instructor.

Everything is inspectable

Any value on the schematic opens its detail view. Present value, mode, and four health flags sit in a fixed rail so they stay visible while you move between tabs, with identity, command priorities, history and a change log behind them. The order reflects what an operator checks first: is this healthy, then what has it been doing. A Flag for Review tab lets a student mark a point they cannot explain, so an instructor can see what confused the room without the student having to raise a hand in front of it.

Two details in the detail view I would defend in a review. Where the underlying export had lost its timestamps, entries are labeled by how long before the session they occurred rather than given an invented clock time. And where a value has no recorded history, the empty state explains that trending is a paid subscription on real systems, because a blank chart is a real thing operators run into.

The five-state value key, printed in the sidebar rather than learned

72.4

Editable

A setpoint you can write to. White means the system will accept a value here.

68.1

Calculated

Derived by the controller. Read-only, and greyed so nobody wastes a click on it.

71.8

Measured

A live sensor reading. The dark pill separates fact from instruction at a glance.

84.0

In alarm

Outside its limit. A red ring rather than a red fill, so the number itself stays legible.

55.0

Overridden

Someone has taken manual control. The loudest state, because an overridden value has stopped describing the building.

Fig. 2. The point detail modal. The rail answers is this healthy before any tab is opened, and the technical path in the header is the same address an operator would use on a real system.

Instructor experience

Four jobs, in the order an instructor does them. This is the half of the product that does not photograph well and it took the most design thinking.

Author an exercise on the teaching screen

An instructor breaks the building on the same screen students use to fix it. Change values on the schematic, then save that state as an exercise. No separate authoring tool to learn, and no gap between what you set up and what the class will see. The save step does the technical work for them, which is what makes this usable by an instructor who is an HVAC expert rather than a software one.

Run it without prep

Fifteen exercises ship ready to load. Companion mode pairs the building with a lesson panel and pauses the clock, so advancing a step moves the building to the moment being discussed rather than leaving the instructor to stage it live.

Open the assessment when the class is ready

The capstone stays locked until an instructor opens it from the dashboard. Access is checked by privilege level rather than by hiding the link, so a student who guesses the URL sees a clear message about their access level instead of a broken page.

See how the room is doing

The Exercise Report lists every published exercise with its goal, its standard and a pass count. Expand one and it becomes a roster: every student by name, whether they have started, and whether anything has changed on their copy of the building. An instructor can see who is stuck while the class is still in the room. Afterwards it is too late to help.

Authoring mode: a banner reading AUTHORING AHU-4-4, with instructions to change values on the diagram, and Save as Exercise and Discard controls

Fig. 3. Authoring. The instructor breaks the building on the same screen students will use to fix it, then saves that state as an exercise.

Exercise authoring

Authoring only works if an instructor can create a rigorous exercise without writing a specification. An HVAC expert knows exactly which fault they want to teach. Asking them to enumerate which data points changed, define a machine-checkable pass condition, and cite the governing standard would end the workflow immediately.

So the save dialog derives all three. The instructor writes a title and a brief in plain language. Everything technical underneath it is inferred from what they just did to the building.

It captures the starting state itself

The dialog diffs the live building against its baseline and lists every point the instructor changed, tagged as an override. One point here, found automatically. No one types a list, and nothing gets forgotten, which is the failure that would otherwise ship a broken exercise into a classroom.

It separates an override from a lying sensor

A device fault is a different teaching problem and the product treats it as one. The plant still behaves correctly and only the reported reading is wrong, so a faulted sensor is deliberately excluded from the override list. The student cannot find it by checking what has been overridden. They have to distrust the number in front of them, which is a much harder and more realistic skill.

It reads the target from the equipment, not from a guess

Choosing a success criterion attaches the standard behind it, and the threshold is pulled from that unit’s own configured setpoint rather than a value typed in by hand. The same criterion applied to a different air handler produces a different number, because the two units are configured differently.

It shows the standard while you author

When a standard backs the goal, the requirement appears inline with its clause, and a custom target is offered for the cases where none applies and a plain reading of what it means. The instructor sees the pedagogical justification at the moment of authoring, and the student later sees the same badge, so the exercise and the curriculum cite the same source.

It validates the condition against the live building

The completion rule is a real comparison with a live readout beside it, so an instructor can see the current value while setting the target and immediately tell whether the exercise is achievable. A condition must hold for three seconds to count, so a value swinging briefly through the target does not pass someone who has not actually fixed anything.

It allows an exercise with no number at all

Some faults are diagnostic rather than corrective. A checkbox switches completion to a written diagnosis, so an exercise can ask what is wrong and why without demanding the student drive a value anywhere.

It scopes who gets the exercise

Whole class, groups, or named individuals, with a line under the control that states the consequence rather than the mechanism: every student seat gets this exercise, nothing to keep in sync as the roster changes. Differentiation is a normal part of teaching, and an instructor who wants to give three struggling students an easier version of the same fault should not have to author it twice.

The save exercise dialog with title and brief still empty, showing a captured starting state of one point, a success criterion reading Active Minimum Setpoint is within 55 plus or minus 1, a live value of 60 degrees, an amber validation warning, and an assign to control

Fig. 4. The save dialog before the instructor has typed a word. The title and brief are still empty, and the technical half of the exercise is already built: the changed point captured, the criterion written against the unit’s own setpoint, and the live value checked against it. The amber warning is the dialog refusing to let an impossible exercise ship.

The Exercise Report: published exercises with goals, standards and pass counts, one expanded into a per-student roster

Fig. 5. The Exercise Report. Every published exercise carries its equipment, its success criterion, the standard behind it and a pass count across the class.

Modes and states

Rather than build three products for three teaching situations, I made the layout and the clock the variables.

Companion

Leading a room

Building at 70%, lesson panel beside it, clock paused so nothing moves while the instructor is talking. A visible indicator says the clock is stopped, because a frozen building otherwise looks like a broken app.

Free Explore

Practicing alone

Full width, clock running fast so an hour of building behavior passes in a minute. Speed is adjustable, because watching an economizer swing over an afternoon needs a different pace than reading one alarm.

Capstone

Being assessed

A worksheet beside the live building, so students answer with the evidence still on screen rather than from memory. Autosaves locally, checks all sections have content before submitting, and confirms before it sends.

The alarm summary with a location filter tree, a sortable table, and a subhead reading acknowledged does not equal fixed

Fig. 6. The alarm summary. The subhead is doing real teaching: acknowledged is not fixed.

Design engineering

I designed this product and built a large part of it: the front end, the control logic, the fault behavior and the instructor tooling. That is unusual for a designer and it is worth being specific about, because several design decisions only survived because I could implement them.

Three examples where the design and the engineering were the same decision.

Faults are rules, not a script

The easy build plays a fault at a fixed time, and students learn the timing rather than the diagnosis. Instead the rules evaluate against live values continuously, which means a student can cause a fault themselves by overriding the wrong thing and the system will catch them doing it. Simultaneous heating and cooling, a supply air loop that is not holding, a fan running in an empty building, a shut outside air damper, a sleeping economizer, high carbon dioxide, and a zone reheating air the plant just cooled.

The building runs on real data

A thousand hours of real system history, interpolated so values move continuously instead of stepping once an hour, with real weather driving the outside air conditions and the building’s filed energy figures behind the carbon panel. Believability was a design requirement, and it needed a data layer to deliver it.

Screen updates are filtered

Values only refresh when a change is large enough to matter. Without that, a fast-forwarded clock repaints everything constantly and a beginner cannot tell signal from noise. It reads as a technical detail and it is really a legibility decision.

Outcomes

In classroom use for the building systems session and the capstone project.

screens: station, point detail, alarms, schedules, reports, capstone, instructor dashboard.

teaching exercises, plus authoring so instructors can add their own.

251

tests passing, up from 222, including the suite that would have caught the original bug.

network requests after load. It runs with the wifi switched off.

Validation

Worth being precise about, because the two are easy to blur.

Verified

That the simulation behaves correctly. Every exercise stages its conditions, every fault rule can fire, and the test suite proves it. That was the point of the audit.

Reviewed

Domain accuracy and teaching sequence, with the curriculum lead and a subject matter expert from the field. Both know this work far better than I do, and both are experts rather than beginners.

Not yet tested

Whether beginners can actually learn diagnosis with it. I have not watched a full class use the finished product, so claims about how students behave in it are design intent, not findings.

Next steps

Watch a class. Everything I know about how this teaches comes from two experts. The people it is for are the people I have not sat with, and that is the first gap I would close.

Log the path, not just the outcome. The Exercise Report says who passed, not how. Two students can reach the same answer by very different routes, and the one who guessed learned nothing. Recording which screen they opened first and what they changed would turn the report from a scoreboard into something an instructor can teach from.

Read generated code earlier. The audit found real defects, but late enough that they could have reached a classroom. I now read the data layer before I look at a single screen.

Next case studyLIFE3 Website Redesign →

← All work

Resu-ME.ai · Cofounder and Head of Design · 14 min read

Resu-ME AI

Three products and a marketing site that share one context: the job you find becomes the resume you tailor, and that becomes the interview you rehearse. Built on the bet that hiring is a coordination problem, not a writing problem.

My role

Cofounder and Head of Design. Product strategy, all four surfaces, design system, research, copy.

Surfaces

Marketing site, Resume Studio (web), Interview Studio (iOS), Job Studio (web)

Dates

2025 to present

Live

resu-me.ai ↗ · App Store ↗

Contribution

Product strategy Design system UX/UI across web and iOS Content design Marketing site Analytics taxonomy

Tools used

Figma Claude Mixpanel Google Analytics Adobe Illustrator Lottie

Abstract

Most AI resume tools do the same thing: paste your resume into a prompt, get a rewritten resume back. The output reads well and says nothing new, because the input was already the problem. The company’s bet is larger than resumes, that matching people to work along the dimensions which actually determine fit is a solvable coordination problem, and that where a competency gap blocks the match you build the competency rather than filter the person out. As cofounder and head of design I argued for the product shape that follows from it, a structured interview that asks about your work before it writes anything, and designed the system around it: Resume Studio on web, Interview Studio on iOS, Job Studio for sourcing, and the marketing site that explains all three without selling three things. I also own the funnel: acquisition, the pricing architecture, onboarding, and the instrumentation that reads them, plus the investor deck that has to make the same argument to a harder audience. The decisions I would defend hardest are the ones about what we did not build.

In short

Stage

0 to 1, three times. Resume Studio, then Interview Studio on iOS, then Job Studio, plus the marketing site and the design system under all of them.

Problem

A rewrite cannot add what the resume never contained.

Thesis

Interview the candidate first. One context, reused across every surface.

Scope

Four surfaces, two platforms, one design system and one analytics vocabulary.

Hard calls

Cut the match score from Job Studio. Refused a fourth pricing plan.

Shipped

Web and iOS live; Job Studio Phase 1 behind a flag.

Decision record

Iterations

Resume Studio shipped first, then Interview Studio on iOS, then Job Studio, each reusing the context the previous one produced.

Rejected

A match score in Job Studio, because it would anchor people on a number close to noise, and a fourth pricing plan, because it contradicted the shared-context thesis.

Edge cases

A skipped question, an answer that is too short, lost connection mid-conversation handled by autosave, and a job posting the user cannot apply to inside the product.

Platform

Web for resume work at a desk, native iOS for rehearsal, with light and dark themes on both.

Status

Live at resu-me.ai and on the App Store.

The studios section of the marketing site: Resume Studio with the AI enhancement conversation, Interview Studio on iPhone, and Job Studio with a filtered feed, above an Application Kit bundle banner

Fig. 1. The system, as the marketing site explains it. Three studios, one shared context, and a bundle that prices the whole journey rather than each piece.

Problem

Someone sits down to apply for a job they would be good at. Their resume says they led design initiatives and improved metrics. It is true, it is useless, and no amount of rewriting fixes it, because the interesting part was never on the page.

Every AI resume product on the market takes that page as input. Paste it in, get a polished version out. The polish is real and the content is identical, because a model cannot infer the 35% engagement lift from a sentence that does not mention it.

The category had converged on a rewriting tool. I argued the actual product was an interviewing tool that happens to produce a resume.

Research and product thesis

Two things in the research decided the product shape, and both cut against what the category builds.

The first came out of my cofounder’s own hiring process. Running product designer interviews, he switched from real-time conversations to async commenting in a shared doc: highlight a phrase, ask a targeted question, let the candidate answer when they were ready. The responses were consistently richer than anything a live interview produced. One candidate said so directly, that she could think and respond thoughtfully because it was not real time.

That reframed the problem. Candidates do not fail for lack of qualifications. They fail because a one-page resume is a forced amnesia event: years of work compressed to four hundred words, skimmed in thirty seconds, then defended live while cognitive load peaks. The competency that is missing is recall and articulation under pressure, and that is learnable rather than fixed. So the product teaches it the way test prep does: low-pressure repetition against a scoring framework. It is also why Interview Studio measures delivery instead of describing it.

The asymmetry is structural

The employer side runs parsing systems, AI screening, calibrated rubrics and recruiting teams paying $750 to $900 per seat per month for sourcing tools alone. The candidate side hand-customizes every resume: two to four hours each, fifty to two hundred applications per search. One hundred to eight hundred hours of unpaid labor before anyone calls back.

And the labor does work

A senior data scientist who reviewed our proof of concept put numbers on both ends: roughly 1% response rate on cold applications, and a 75% lift for candidates spending 45 to 60 minutes tailoring. So tailoring is worth doing and nobody can sustain it. That gap is the product.

Which is why tailoring is one tap

Job Studio already holds the job description, so the expensive step collapses. That is the only feature in Phase 1 that no competitor can copy without building the same shared context first.

Pitch deck

I designed the investor deck as well as the product, and I would argue that is the right split rather than a startup compromise. The deck has to make the same argument the marketing site makes, to a more skeptical reader, in ten slides. If the person who designed the funnel is not the person framing the market, the two drift.

The problem slide is the one that had to work hardest. 92,272 tech layoffs year to date, a 40% year-over-year increase, 22 weeks on average to find a role, and 88% of executives admitting their ATS filters out qualified candidates. Four numbers that establish the market is large, worsening, and structurally broken rather than merely annoying. Everything after it is a response to those four.

Deck slide: The Sophistication Gap, with 92,272 tech layoffs year to date, a 40% year-over-year increase, 22 weeks average to find a role, and 88% of executives admitting ATS filters out qualified candidates, beside a vision panel on the compounding career corpus

Fig. 2. The problem slide. The job search stack failed from both sides of the table.

Jobs to be done

Framing the problem as a journey rather than a feature set is what produced three products instead of one. A job search has three distinct jobs to be done, and each one currently sends people to a different tool that knows nothing about the others.

Find the role. Tailor for it. Be ready for the conversation. The insight worth building on is that each stage produces the context the next stage needs, and nobody was carrying it forward.

Job Studio

Find the role. Produces the job description, which is the input the tailoring step would otherwise ask you to copy and paste.

Resume Studio

Tailor for it. Produces a structured account of your experience, which is the input the rehearsal step would otherwise ask you to invent.

Interview Studio

Be ready for it. Pulls role-specific questions from the posting and the resume you just built, rather than from a generic question bank.

That chain is the product strategy, and it is also the only honest reason to build three things instead of one. If the studios did not share context, they would be three unrelated tools sharing a brand.

We did not build them in that order. The journey runs Job Studio to Resume Studio to Interview Studio, but Resume Studio shipped first because it generates the context the other two consume. Interview Studio came second and was cheap once that existed, since it reuses both the resume and the job description. Job Studio came last and deliberately scoped to Phase 1: it benefits most from shared context and contributes least of it.

Resume Studio: guided conversation

The bet only pays off if people answer the questions. An open-ended chat with an AI is a commitment nobody can size, and abandonment mid-conversation costs more than never starting, because now we have half a context and no resume.

Five decisions, each aimed at the drop-off point it addresses.

Goal-gradient effect

A bounded counter and a segmented progress bar, so you can always see how many questions are left and how far in you are. People work harder as a goal gets visibly closer, and an unbounded conversation removes that entirely. Bounding it turns an open chat into a task with an end.

Recognition over recall

Questions quote your own material back: "you mentioned conducting user research with 200+ participants, what methods did you use and what changed as a result?" Recognizing a detail you already wrote is far easier than recalling your career unprompted.

Progressive disclosure

A hint is available on every question but never shown by default. Offering the hint up front replaces the person’s own answer with ours, which defeats the entire mechanism. Offering it on request rescues the people who would otherwise abandon.

Multimodal input

Voice or type, chosen per answer. People describe their work far better out loud than in a text field, and this is also where the iOS product’s voice pipeline earns its second use.

Autosave with visible state

"Auto-saved 2 min ago" sits in the header, and an explicit rule tells you each question takes one response. The first removes the fear of losing work; the second sets the expectation before you hit send rather than after.

Resume Studio: the AI enhancement conversation with progress bar, hint and voice controls; the scored version comparison with a competency matrix and three options at 7.4, 8.1 and 9.2; and the layout, color and font design step

Fig. 3. Resume Studio, all three steps. Context, then scored options, then export.

Scoring and feedback

"Better" is not a claim a resume tool can make credibly, so the product shows its reasoning instead of asserting a result.

A bullet comes back as three scored options, not one rewrite: concise at 7.4, balanced at 8.1, quantified at 9.2, with the original struck through above them. The person chooses. That is a deliberate reversal of the category default, which hands you one answer and asks you to trust it.

Above the options sits a competency matrix, six dimensions scored against the job description, updating live as bullets change. It does the thing a score has to do to be worth showing: it says which dimension moved and by how much, so the number is diagnostic rather than decorative.

Interview Studio (iOS)

Rehearsal is a phone problem. People practice in the car, on the walk in, the night before, which is why this one is a native iOS app rather than a page in the web product.

It scores against the STAR method, the format interviewers are actually trained on, rather than a rubric we invented. Around that sit the two measures that make delivery coachable instead of vague.

Measure the behavior, not the vibe

Words per minute against a 120 to 150 target, and filler-word ratio as a percentage. "You sounded nervous" is not actionable. "138 words per minute, 2.4% filler" is something a person can practice against tomorrow.

Score the structure separately

An average STAR score sits beside the delivery metrics, so a well-structured answer delivered badly and a fluent answer with no substance do not collapse into the same number.

A readiness score, not a streak

The home screen leads with readiness and recent sessions. Practice products default to streaks, which punish the person who takes three days off before an interview, exactly when they need the tool most.

Light and dark, both first-class

Practice happens at night and in a parked car. Dark mode is not a preference toggle here, it is the condition half the sessions run under.

Interview Studio on iPhone: a feedback screen scoring an answer 87 out of 100 with average STAR score, words per minute and filler word ratio; a practice screen with behavioral, technical and case tabs; and a home screen with a readiness score and session history

Fig. 4. Interview Studio, iOS. Scored against STAR, with delivery measured rather than described.

Job Studio: scoping Phase 1

Job Studio crawls live openings from company career pages, classifies every posting by role family, and shows you only yours. Filter by work mode, location, salary floor and recency. Save what fits, dismiss what does not, and dismissing takes a reason so the feed learns.

The obvious feature for a product like this is a match score. Every competitor has one. I cut it from Phase 1 and it was the most contested decision on the project.

A percentage next to a job is a claim about someone’s chances, and ours would have been computed from a role-family label and a keyword overlap. It would have looked authoritative and been close to noise. Worse, it is the number people would have anchored on: a 42% next to a role you are qualified for talks you out of applying, and we would have no way to know we had caused it.

So Phase 1 ships without a score, without relevance sort, and without application tracking. What it ships with is the thing only we can do: we already hold the job description, so tailoring a resume for a posting takes one tap and no copy-paste. That is the feature worth having, and the score would have distracted from it.

Apply deliberately links out to the company’s own posting rather than capturing the application. Pretending to own a step we do not own is how job boards lose trust.

Job Studio: a filter panel showing role family, work mode, location, salary floor and sort with 412 matching openings; a saved jobs list with dismiss reasons; and a posting detail with tailor and apply actions

Fig. 5. Job Studio, Phase 1. No match score anywhere on the screen, by decision rather than by omission.

Marketing site and pricing

The site has a harder job than most: explain three products without making the company look like it sells three products. The structure follows the journey, so the studios section reads as one system with three entry points rather than a feature comparison.

Adding Job Studio was the test of that. The default move is a new SKU.

Job Studio is included, not sold

Two studios at $30 a month each, both together at $50 as the Application Kit. Job Studio joins every plan as a feature line rather than becoming a fourth price. A separate SKU would have contradicted the shared-context thesis on the same page that argues for it.

The free tier is the sourcing tier

Browse, filter, save, dismiss and apply are all free. Tailoring meters against the existing monthly analysis. The paywall sits where the expensive work happens, not in front of the part that builds the habit.

Analytics vocabulary is part of the design

Every CTA carries a location and plan attribute, and both new values had to be registered in the event router before launch or the allowlist would silently drop them. Shipping a section whose clicks do not appear in any funnel is shipping a section you cannot learn from.

Gate the nav on the flag

I held the navigation link until the feed was enabled in production. A nav item pointing at a surface users cannot reach is worse than no nav item, and the launch checklist says so explicitly.

The Resu-ME AI marketing homepage with its navigation bar, the headline Land the interview. Then ace it., a subhead reading your experience holds more than 1-2 pages can capture, and a Start For Free call to action noting one free resume enhancement and no credit card required

Fig. 6. The homepage. One sentence for the whole journey, then the three studios underneath it.

Funnel results

Resume Studio went live on 1 May with Interview Studio on the App Store the same day. These are the numbers sixteen days later, and I am reporting them at that scale deliberately: this is a launch, not a track record. What matters at this stage is whether each stage of the funnel is instrumented and moving, not whether the absolute figures are impressive.

Before launch the work was validation rather than acquisition: over fifty customer interviews, ten recruiters and hiring managers interviewed on the other side of the filter, and three SAFEs closed with three investors at $30K.

Acquisition

149 unique visitors, 602 page views and 256 sessions on the marketing site, against 9,499 views and 1,848 interactions on Meta across five activated social channels plus email outreach to roughly fifty people on the waitlist. The ratio is the useful part: paid and social reach is an order of magnitude above site traffic, which tells me the click-through, not the awareness, is the constraint.

Conversion

Six users converted across Resume Studio and Interview Studio, and six are still active. From 149 unique visitors that is a visitor-to-signup rate around 4%, which for a paid product at $30 a month in its third week is a signal rather than a result. The design decision it validates is the free first enhancement: no credit card in front of the conversation.

Onboarding

The guided conversation is the onboarding, so activation and first-value are the same event. That is why the flow is bounded, autosaves visibly, and offers voice as well as typing: every one of those exists to get a first resume out of the door rather than to look thorough.

Retention

Six active of six converted at day sixteen, which is a number I will not read too much into. Retention is the metric the pilot with The Knowledge House was designed to measure properly, across eight cohorts of five participants, with activation, completion and repeat-use defined with engineering before it ran.

Pricing as a growth lever

Competitor analysis showed premium AI tools converged on a $0 / $20 / $60-100 / $200 ladder. Resume Studio and Interview Studio sit at $30 each with both bundled at $50, which places us in the validated mid-band rather than inventing a price point, and makes the bundle the obvious choice rather than a discount. The $199 Workspaces tier exists to define the ceiling, not to be the volume seller.

And the instrumentation to read it

Every CTA carries a location and plan attribute in Mixpanel and Google Analytics, registered in the event router before launch. Without that the sixteen-day numbers would be a page-view count instead of a funnel.

Deck traction slide: pre-launch validation of 50 customer interviews and 3 SAFEs, launch day shipping Resume Studio and iOS Interview Studio, then day one to sixteen showing 149 unique visitors, 602 page views, 256 sessions, 9,499 Meta views, 1,848 interactions and 6 converted users

Fig. 7. The funnel as reported to investors at day sixteen. Each column is a stage, not a highlight reel.

Deck business model slide: Resume Studio and Interview Studio at $30 a month each, a $199 Workspaces hero tier, and a note that premium AI converged on a $0 to $200 ladder where $30/$30/$50 sits in the validated mid-band

Fig. 8. Pricing architecture. The mid-band position is the research result, not a guess.

Ownership

Four surfaces across two platforms, held together by one system rather than four sets of decisions.

Product strategy

The interview-first thesis, the three-studio structure, the scope line on Job Studio Phase 1, and the pricing architecture that keeps it one product.

Design system

One design token set, component library and motion vocabulary spanning a marketing site, a web app and a native iOS app, with light and dark as parallel themes rather than an inverted afterthought.

Content design

Every question the AI asks, every empty state, every paywall line, and the site copy. On a product whose core interaction is a conversation, the copy is the interface.

Measurement

The analytics vocabulary, the CTA taxonomy, and the discipline of registering new values before launch rather than discovering the gap in the first funnel review.

Next steps

Instrument the conversation. I know how many people finish and how many skip, but not which question loses them. Per-question drop-off would tell me whether the sixth question is one too many or whether one specific prompt is badly written, and those need opposite fixes.

Earn the match score. Cutting it was right for Phase 1. It becomes defensible once the analysis engine, not a keyword overlap, computes it, and once we can show what drove the number rather than just the number.

Close the loop. Phase 2 tracks applications through to outcome. That is the first point at which we can say whether any of this works, rather than whether people enjoy using it.

Next case studyThe Custom Wizard →