Redesigning Craigslist for faster used-car discovery
For a paid product design brief with LiveFront, I redesigned Craigslist’s React Native iOS experience and created an implementation-ready handoff for the used-car discovery flow. view project →
Designing governance infrastructure for agent-generated interfaces
I’m currently building governance standards for catching “AI slop,” designed to be dropped directly into an agent chat to audit generated product work for weak logic, missing states, unsupported decisions, and other gaps before it ships. Download my guide →
Designing AI-assisted billing review for operations teams across complex workflows
I designed the review workflow where users validate extracted billing data, turning their corrections into higher-confidence model output. View case study →
Making cryptography easier to understand inside a developer library
I designed an interactive cryptography explainer for a cross-platform library that helps developers handle binary data, showing how ECDH and AES-GCM work together before they use the encryption APIs in code. View experience →
Transforming fragmented securities-based lending into one origination experience.
I transformed a fragmented legacy lending process into one guided experience where relationship bankers evaluate securities and collateral in real time, add co-borrowers, submit loan requests, and track underwriting decisions. View case study →
Resolving Missing Information Across Healthcare Systems
Helping critical information move more gently between the people, places, and systems that care depends on.
Case study coming soon
Designing a music education marketplace for students and teachers
I’m building a two-sided marketplace that helps students find and book teachers while giving educators one place to manage lessons, payments, students, and progress. View project →
Find Teachers
Find your music teacher.
Connect with experienced instructors for personalized music education and mentorship.
SkillGenreLocation
Search skills...
Level
BeginnerIntermediateAdvanced
Find Teachers
By continuing, you agree to Scale's Terms of Service and Privacy Policy.
Illustration one
A short line about the piece goes here: one sentence, same length as the others.
Artwork
Illustration two
A short line about the piece goes here: one sentence, same length as the others.
Artwork
Illustration three
A short line about the piece goes here: one sentence, same length as the others.
Artwork
Release one
A short line about the track or release goes here: one sentence, same as the others.
Cover / performance image
Release two
A short line about the track or release goes here: one sentence, same as the others.
Cover / performance image
Release three
A short line about the track or release goes here: one sentence, same as the others.
Cover / performance image
off the clock
Three things I keep coming back to
At heart, I’m a creative who likes finding depth and clarity inside complex, chaotic environments. A lot of my identity comes from music: house, indie, Sufi ghazals, rock, and old Bollywood all mixed together. For a long time, I thought being both Indian and American meant finding some kind of middle ground. Now I see it differently. The combination is part of what gives me perspective.
Art has always worked the same way for me. As a kid, I drew obsessively, chasing repetition, depth, emotion, and clarity inside complexity. Those are the same qualities I listen for when I make music, and the same ones I bring into digital products. I look for patterns, how deep a system goes, where it starts to break, and what that reveals about the people and businesses relying on it.
I’ve also stopped thinking of design as finding a compromise between users and businesses. When customers and employees can move through systems with less friction, the business usually benefits too. That’s shaped how I see design now: not just as something visual, but as something systemic.
At heart, I’m a creative who likes finding depth and clarity inside complex, chaotic environments. A lot of my identity comes from music: house, indie, Sufi ghazals, rock, and old Bollywood all mixed together. For a long time, I thought being both Indian and American meant finding some kind of middle ground. Now I see it differently. The combination is part of what gives me perspective.
Art has always worked the same way for me. As a kid, I drew obsessively, chasing repetition, depth, emotion, and clarity inside complexity. Those are the same qualities I listen for when I make music, and the same ones I bring into digital products. I look for patterns, how deep a system goes, where it starts to break, and what that reveals about the people and businesses relying on it.
I’ve also stopped thinking of design as finding a compromise between users and businesses. When customers and employees can move through systems with less friction, the business usually benefits too. That’s shaped how I see design now: not just as something visual, but as something systemic.
Safety, income and stability are at the forefront of how we operate
our daily lives. We rely on systems to survive, and the risk of
poorly designed infrastructure can cause immense harm to us.
It’s sad, but also interestingly optimistic, that a lot of
these problems are preventable. I find parts of those experiences
and identify what breaks in them. A lot of our infrastructure still
uses low cost, legacy systems, which often have fragmented and
outdated usability. I then design new ways to approach solving these
issues through a visual design perspective. Where does the flow
break for the user? Read more →
AI-assisted billing reviewHuman validation for higher-confidence model output.
Designing AI-assisted billing review for operations teams across complex workflows
I designed the review workflow where users validate extracted billing data, turning their corrections into higher-confidence model output.
View case study →
Making cryptography easier to understandAn interactive explainer for encrypted data.
Making cryptography easier to understand inside a developer library
I designed an interactive cryptography explainer for a cross-platform library that helps developers handle binary data, showing how ECDH and AES-GCM work together before they use the encryption APIs in code.
View experience →
Transforming fragmented securities-based lending into one origination experience.
I transformed a fragmented legacy lending process into one guided experience where relationship bankers evaluate securities and collateral in real time, add co-borrowers, submit loan requests, and track underwriting decisions.
View case study →
Governance for agent-generated interfacesRules and audits for AI design decisions.
Designing governance infrastructure for agent-generated interfaces
I’m currently building governance standards for catching “AI slop,” designed to be dropped directly into an agent chat to audit generated product work for weak logic, missing states, unsupported decisions, and other gaps before it ships. Download my guide →
At heart, I’m a creative who likes finding depth and clarity inside complex, chaotic environments. A lot of my identity comes from music: house, indie, Sufi ghazals, rock, and old Bollywood all mixed together. For a long time, I thought being both Indian and American meant finding some kind of middle ground. Now I see it differently. The combination is part of what gives me perspective.
Art has always worked the same way for me. As a kid, I drew obsessively, chasing repetition, depth, emotion, and clarity inside complexity. Those are the same qualities I listen for when I make music, and the same ones I bring into digital products. I look for patterns, how deep a system goes, where it starts to break, and what that reveals about the people and businesses relying on it.
I’ve also stopped thinking of design as finding a compromise between users and businesses. When customers and employees can move through systems with less friction, the business usually benefits too. That’s shaped how I see design now: not just as something visual, but as something systemic.
I designed a mobile-only system that connects what patients want to ask before an appointment with what they need to remember afterward.
Role
Product designer: patient flow, states, visual language
Team
Three designers, inside a larger healthcare technology client
Timeline
3 weeks leading into the design workshop
Starting point
Stakeholder direction → design exploration → workshop → MVP development
≈15–25%
$ less post-visit clarification work
How this is calculated
What it represents Repeat contact a clinic handles after a visit: calls and messages asking again for something already said in the room.
Inputs from this project Testing where 85–90% of people found what the doctor said in a saved conversation, and 80–90% understood the answer came from the recording rather than from a model.
The logic A patient who can retrieve the answer does not ring to ask for it. So the effect is the share of that repeat contact the product could absorb, at whatever a clinic's contact volume and handling time are. Carry never shipped, so this is the case the design makes, not a measured reduction.
≈20–35%
faster entry into question-building
≈85–90%
found what the doctor said, unaided
What I was givenTurning workshop direction into a testable MVP
I was handed a premise from a workshop and three weeks to work in. I scoped it to an MVP, took it through stakeholder review, and handed it to a first build in Playground. A leadership change above me stopped it before release.
My brief was to turn stakeholder direction into something the wider team could review, challenge and build from.
Stakeholder direction
V1 · Week 1
V2 · Week 2
V3 · Week 3
Design workshop
Cross-functional feedback
Revisions
MVP development
V1, V2 and V3 are meaningful revisions to the design during the
three-week exploration.
What I contributed
Turned the premise into an end-to-end patient flow, from writing questions before a visit to reading the conversation back after it.
Ruled out generated answers, and designed the quotation pattern that took their place.
Designed the upload, transcription and matching states, and what each one does when it fails.
Took tradeoffs to product and engineering while they were still drawings.
I mapped what PatientX already owned so Carry could sit inside it unchanged.
Where it sits in PatientXPlacing Carry inside the existing PatientX experience
Carry is a small piece of PatientX, which already owned sign-in, appointments and navigation. I mapped what was already built, and that set my first task: to find somewhere Carry could sit without changing any of it.
Where Carry lives
PatientX : the patient experience Carry plugs into. Already built, and outside my scope.
Sign-in and identity
Appointments
Navigation
The visit
Carry : the part my team designed
BeforePrepare the questions
DuringCarry does not operate
AfterUpload and match
LaterRead it back
Proto personas
Built from onsite and Maze pilot behaviour and the feedback the team held.
Maya Patel, 42
Breast cancer treatment follow-up
Situation
Follow-up after treatment. Visits at set intervals, and part of what each one decides is whether the interval changes. Maya arrives with one specific concern: the pilot pattern where patients go straight to writing questions.
What they carry into the appointment
A result whose meaning is not obvious from the number, something noticed since the last visit, and a question rewritten more than once.
What they need afterward
The interval, and the reason for it. The date is the easy half to keep.
Around the conversation
Before the visit
Notices something and decides whether it counts.
On her mind One concern.
Preparing
Writes the question, then rewrites it.
Preparing to ask The wording she wants to use.
Carry Edited in place, and reversible.
During the conversation
Asks it early. An interval comes back, with a reason.
Taking in More than fits in memory.
Carry Nothing runs here.
Immediately after
Leaves with the date, already thinner on the reason.
Trying to recall A month, roughly.
Carry Upload, from her own phone.
Back at home
Repeats the result to someone who asks.
Trying to recall The provider’s words.
Carry The excerpt, and where it came from.
Patient confidence through the conversation
More certainLess certain
WatchfulWatchful
RehearsingPrepared
Keeping upMore present
Think I got itConversation saved
ReconstructingCan return to it
Carry does not change the conversation itself. It gives patients something to return to when attention, emotion, time, or memory make the details harder to hold onto.
Jordan Lee, 31
Kidney function monitoring
Situation
Monitoring is a sequence of numbers, so most visits are a comparison with the last. Jordan is fluent in the vocabulary and less sure what a movement inside it means.
What they carry into the appointment
The latest figure and which way it moved, plus a list built across weeks, mostly variations on what would have to change for the plan to change.
What they need afterward
Instructions and follow-ups to complete before the next test, in the order they were given.
Around the conversation
Before the visit
Reads the new number against the last one.
On his mind A direction, without a meaning.
Preparing
Adds questions across the week as they occur.
Preparing to ask A list that keeps growing.
Carry The list is his; suggestions are optional.
During the conversation
Gets through most of it. Two go unasked.
Keeping track of Which ones were answered.
Carry Nothing runs here.
Immediately after
Writes down a figure to repeat next time.
Trying to recall One number out of several.
Carry Upload, or decline and keep the list.
Back at home
Works out which change was the one that mattered.
Working out The threshold that moves the plan.
Carry Questions sit against the answers.
Patient confidence through the conversation
More certainLess certain
Watching a numberWatching a number
ListingList in hand
Losing the threadAsking what he came for
Two questions shortAnswers attached
Guessing which numberKnows which number
Carry does not change the conversation itself. It gives patients something to return to when attention, emotion, time, or memory make the details harder to hold onto.
Alex Morgan, 36
Prenatal care appointment
Situation
Frequent short appointments, each adding instructions to the ones already given. Alex arrives with more to report than to ask, and browses the suggested questions.
What they carry into the appointment
Symptoms noticed and half-forgotten, and little confidence about which are worth raising.
What they need afterward
What happens next, and which of the instructions belong to this week.
Around the conversation
Before the visit
Collects things to report.
On their mind Symptoms, and whether they count.
Preparing
Browses the suggested questions.
Preparing to ask What is worth raising at all.
Carry Taking one is a choice, and reversible.
During the conversation
Reports first, then takes instructions.
Taking in Several, arriving close together.
Carry Nothing runs here.
Immediately after
Books the next visit while still holding them.
Trying to recall What was specific to today.
Carry Upload before the day covers it.
Back at home
Sorts this week’s instructions from the rest.
Working out Which came from which visit.
Carry A read-only record to check against.
Patient confidence through the conversation
More certainLess certain
UnbotheredUnbothered
Unsure what to askSomething to bring
Too much at onceReporting, not recalling
Still looseInstructions captured
Sorting by guessKnows the next step
Carry does not change the conversation itself. It gives patients something to return to when attention, emotion, time, or memory make the details harder to hold onto.
The feedback the team held rarely described forgetting one fact. It described losing the whole fifteen minutes.
What a result means
What happens next
Symptoms they forgot to mention
Questions they prepared
Instructions to remember
Follow-ups to complete
I turned stakeholder direction into a journey the team could challenge.
V1 · Week 1Mapping the first workable flow
I started from stakeholder direction and turned it into a patient journey the team could argue with. There was no interview study behind it. I worked from the team’s premises and the three weeks I had.
Before drawing a screen, I settled three things. Editing would happen in the row and be undoable, because patients kept rewriting questions. Carry would not generate answers. Carry would not record, which came out of a scope conversation with product that moved consent out of the product.
With those three settled, I drew one complete journey. The open marker in the diagram records the recording decision. It is not a gap.
Four things I still could not answer
A team premise, carried forward as an assumption.
Upload, transcription and matching all take real time.
Whether an excerpt can point at a moment in the audio. Drawn as if it could, flagged as a question for engineering.
It constrained more than it first looked.
I logged all four in Jira as open questions. Two of them were somebody else’s to answer.
I left the marker open: nothing in the recording answered the question clearly enough to quote.
Patient rights & protections
I designed Carry so patients could return to their own care conversations without giving up control of the experience.
The right in play is a patient’s access to their own health information, and their say in how it is handled. Carry is built on material the patient supplies: they choose whether to upload a recording at all, and declining had to be a real option rather than a dead end, so the upload state is designed to be refused. Questions are editable in the row and every suggestion is undoable from the moment it lands, which keeps the record theirs to correct rather than a transcript they are handed.
I treated HIPAA and PHI review as a design gate before the first iteration. The patient-facing copy, what each screen exposed, and the behaviour of the upload, transcription and matching states went through that review before V1 moved into iteration, and the same questions came back on the project calls as states were added. That is where the recording question surfaced: rather than design around consent, the scope conversation moved it out of the product.
I ruled out generated clinical answers. A matched answer is a quotation from the recording, badged, with a route back to the moment it came from, and where nothing in the recording answers a question clearly enough to quote, the question stays visibly unanswered. That decision is a patient-protection decision before it is a product one: a patient cannot check a summary against what was said in the room, and a wrong answer about a result can send someone into months of surveillance.
Recording stayed outside the MVP. Consent and privacy complexity surfaced in a scope conversation with product, and the resolution was to move consent out of the product rather than design around it. The copy carries the same intent: Carry asks for file access in its own words before the picker opens and says only audio files will be shown, so the request is legible and the exposure is no wider than the task.
Designed in support of patient access to their information (45 CFR §164.524), requests for confidential communications and restrictions (§164.522), reasonable safeguards (§164.530(c)), and the minimum necessary standard (§164.502(b), §164.514(d)). These informed the decisions above; no interface on its own establishes compliance.
I ruled out recording in a scope conversation that moved consent out of Carry.
Making the screen the patient’s own
V2 · Week 2Specifying the behaviour V1 had left open
Reviewing V1, the structure held. What I could not find in it was conditional behaviour, hierarchy inside a screen, or any answer for the moments something fails.
Nothing on the prepare screen read as the patient’s own
The screen as it was
Checklist, the patient’s questions and suggested ones, all dressed the same.
What I changed
Suggestions became opt-in with an undo, editing moved into the row, and the row got a minimum height so a long question is never clipped.
V1 → V2
The sequence on the screen did not change in week two. Logistics were still first, and that turned out to be the wrong call.
Patients build their own list of questions.
Add a suggested question, then undo it.
Try it: add a suggested question, then undo it
Responsiveness across different devices
Patients write long questions, so the row grows. Same type, spacing, 56pt minimum row and 44pt targets on every device.
Edit the question text
Try it: type a longer question
Examples
Device
A patient cannot check a generated summary
The obvious next move
Letting the model answer the questions was the obvious move. A wrong answer about a result can send someone into three months of surveillance.
What I designed instead
The answer is a quotation, badged, with a route back to the moment it came from. Where nothing answers a question clearly enough to quote, it stays visibly unanswered.
What it cost
It cost the feature that demoed best. I took that to product and engineering while it was still a drawing.
Patients can see exactly what was said.
Open a transcript, or dismiss an answer.
Try it: open a transcript, or dismiss an answer
Patients choose what to upload.
The patient supplies the recording, so declining had to be a real option.
Try it: tap Upload recording
One conversation, whether it’s live or saved.
A record you can still edit is not a record, so the controls leave when it is saved.
Try switching between Active and Saved
Upload, transcription and matching can all fail
The blanks in my file
Every one was a blank in my file.
How I specified them
Each failure is a state of the real component, saying what happened, what was kept and what to do next. I walked every recovery path with engineering before drawing any of them.
It still makes sense when things go wrong.
Change a condition.
Current scenarioNormal flow: upload, transcription and matching all completed.
I specified what upload, transcription and matching each do when they fail.
V3 · Week 3Preparing V2 for the workshop review
I connected the same flow end to end and annotated it well enough for the team to argue with.
Connecting the states, and writing down what I still did not know
Connected the major states into one prototypeUntil then they were screens implying each other.
Settled the visual languageBy the third flow I was redrawing the same row and getting it wrong a different way each time. The component set is further down.
Wrote down what I still did not knowOn the flow in Figma, next to the screen they were about. PatientX dependencies went into Jira.
Made it something non-designers could react toA clickable path, not a wall of frames, if the argument is going to be about generated answers, the prototype has to reach that screen.
Three things I left open rather than quietly decide
I left three questions open rather than decide them quietly: how long a transcription takes, whether a matched excerpt can be tied to a timestamp engineering can return, and whether file access could be requested the way I had written it.
I took V3 into the workshop. It didn’t come out unchanged.
I tested V3 with patients onsite and in Maze to see if preparation held up.
Answering without writing an answer
The design workshopTesting V3 with patients, onsite and in Maze
I ran task-based sessions with patients onsite for a week, alongside a parallel Maze study.
Product had been part of the scope conversation from early on. Engineering, clinical input and patients entered the process at this point.
👨💻 Engineering feasibility. What survives a failed
transcription, whether an excerpt can point at a timestamp, whether the question row could reuse
the existing list component
📋 Product scope, generated answers came back up, and the boundary with
PatientX got tested again
🧑⚕️ Clinical and domain constraint. What it costs a
patient when a summary of a result is wrong, which is the argument that kept the quotation
pattern
the onsite sessions and the Maze study below: the only place patients entered the process
the other two designers, on hierarchy and on whether the source cues were doing enough
Patient prototype
In person~3 unique patients a day in my sessions. Task-based moderated testing,
observation, follow-up questions.
Maze~5–6 unique testers a day. Unmoderated task testing: completion,
time on task, misclicks, heatmaps, comments.
Behaviour patterns
Design iteration
Retest
Tasks tested
T1Prepare for visit
T2Add a question
T3Reorder questions
T4Upload recording
T5Find what the doctor said
~85–90%completed preparation unassisted, after iteration
~20–35%faster to begin building a question list, after the sequence changed
~80–90%found something the doctor said in a saved conversation
~80–90%understood a matched answer came from the uploaded recording, after stronger source cues
Reconstructed ranges from onsite and Maze pilot testing. Exact
historical Maze exports are not available.
Order going in
Preparation checklist → My questions → Suggested questions
~70–80% completed the whole flow without help
~20–30% hesitated, backtracked, or bypassed the checklist
Patients with a specific concern usually tried to reach question-building first
Patients less sure what to ask were more likely to browse suggestions
Testing showed the checklist itself was not the problem.
The problem was that it sat in front of the task patients had opened the screen to do.
Order coming out
My questions → Suggested questions → Preparation checklist
Order going inOrder coming out
~85–90% completed preparation unassisted
~20–35% faster entry into question-building
~10–15% hesitation or unnecessary backtracking
Reconstructed pilot patterns. The sequence change is not the only thing that moved between rounds, and these do not prove it caused every improvement.
Showing where a matched answer came from
Watching the sessions, I saw patients land on an answer without being able to tell where it came from.
BeforeAfter
~80–90% found something the doctor said in a saved conversation
~80–90% understood the matched answer came from the recording, after stronger source cues
The second figure is source comprehension, not matching accuracy.
Both rounds were pilot testing
I moved the preparation checklist below the questions after testing.
After the workshopWhat changed, what I kept, and what I could not settle
Not everything raised in the workshop became a change.
Changed 🧑 Raised by patients, in the sessions
The preparation checklist moved below the questions
In V3
Logistics first, then the questions.
What was challenged
Patients with something specific on their mind scrolled straight past it. A fifth to a third hesitated, backtracked or bypassed it.
What happened
Order changed, component untouched. Retested: completion without help moved into the mid-to-high eighties.
Tested again 🧑 Patient sessions · 🎨 Design review
Where a matched answer came from
In V3
A quotation badged under the question it belonged to.
What was challenged
The badge was not doing the work I thought it was.
What happened
Stronger cues, and the answer opens onto the moment it came from. Retested: around four in five understood it came from the recording, source comprehension, not matching accuracy.
Kept 📋 Product scope · 🧑⚕️ Clinical constraint
Carry still does not write an answer for a patient
In V3
Quotations with a route back to the source, and a visibly unanswered state where nothing is quotable.
What was challenged
Generating the answer demos best, so it came back up.
How I read it
A patient cannot check a summary against what was said in the room, and a wrong answer about a result can send someone into three months of surveillance.
What happened
Kept. The tradeoff was made in the open rather than inside my file.
Changed 👨💻 Engineering feasibility
Transcription failure and recording failure became separate states
In V3
One failure state across all three.
What was challenged
What is still on the device when transcription fails after a successful upload? The recording survives; the transcription does not.
What happened
Separate states, each saying what happened, what was kept and what to do next.
Blocked by dependency 📋 Product scope · PatientX
The timestamp behind a matched answer
In V3
A precise position in the audio.
What was challenged
Whether a usable timestamp comes back from transcription at all.
What happened
Left open on the flow and in the ticket. Carry stopped before the answer arrived.
One thing I deferred rather than solved
I assumed that patients want to prepare, that they will record their own visit, and that they will come back and read it. None of those assumptions was tested before I drew. If I had the time again, I would run that test first.
What engineering received
The patient flow on both sides of the appointment, connected end to end
Component states for upload, transcription and matching, including every failure
Conditional behaviour: what is kept after each failure, and what a retry does
The unanswered case, where a question has no quotable answer, as a designed state
Permission and picker copy, written as a requirement rather than a suggestion
The component set: one colour, one ink ramp, one row, with heights and type
measured
The open dependencies, left visible on the flow and in the ticket instead of quietly
resolved
MVP development began in Playground after the workshop. When an implementation answer changed the behaviour, it went back into the Figma flow and the ticket.
I kept matched answers as quotations, not summaries a patient cannot check.
Specifying it for build
The shared referenceBuilding the component set the other designers worked from
I documented one interactive colour, one ink ramp and one row specification, with every value measured.
Colour
I defined one interactive colour, one ink ramp and one divider. The teal carries two values, because it sits under white type on light backgrounds and near-black type on dark ones.
I measured the question row against 15/22 type. One line lands on 56 points and two lines on 80.
Size
Line
Where it is used
36
44
Verification code entry
22
28
Screen titles
17
24
App bar title
15
22
Body, list rows, question text
13
18
Supporting copy, quoted answers
11
16
Labels, counts, badges
Components
Buttons
Checklist row
Question row
Badges and chips
Row menu
Recording panel
File row
Matched answer
Surveillance timeline
Failure state
Two other designers built screens from it without asking me what a row was for
I handed the flows, states and component set to a first build in Playground.
Handoff, and where it stoppedWhat I handed off, and where it stopped
I finished the flows, the states and the component set, and a first build was running in Playground when priorities changed above me. It never shipped.
Every assumption here was testable and none were tested first
Deciding what Carry would not do
By ruling out recording, results delivery and model-written answers, I took most of the hard problems off the table before they reached a screen.
The design system, flows and seeded content are the project’s own. The prototypes are rebuilt here from that documentation, so they behave.
I logged the questions I could not answer instead of deciding them quietly.
Stories, ReconstructedWriting the flows back as requirements
Uploading a recording after the appointment
Reconstructed from the documented
upload flow and the failure states in Screens and states.
Story
A patient finishes a visit with a recording on their phone and wants Carry to turn it into something they can read against the questions they went in with.
Acceptance criteria
Carry asks for file access in its own words before the picker opens, and says only audio files will be shown.
The picker lists audio files only.
A matched answer is a quotation with a route back to the moment in the
recording it came from.
Edge cases
Where nothing in the recording answers a question clearly enough to quote,
the question stays visibly unanswered.
Who it supported
Engineering, who I walked every recovery path
through with before drawing the states.
Changing a question before the visit
Reconstructed from the documented
editing flow and the prepare screen.
Story
A patient writes a question, thinks better of the wording,
and rewrites it, often more than once, which is the behaviour the pilot
kept showing.
Acceptance criteria
Editing happens in the row itself.
Adding a suggested question is undoable from the moment it lands.
The row grows with the question, so a long one is never clipped.
Who it supported
The two other designers, who built screens from
the row once it was in the component set.
Terms used in this project
PatientX
The patient experience this client already shipped. It owned sign-in, appointments and navigation, and Carry had to fit inside it without changing any of it.
Carry
The mobile-only system I designed: it connects the questions a patient writes before an appointment with what they need to remember afterward.
Preparation checklist
The logistics list a patient works through before a visit. In V3 it sat above the questions; testing moved it below them.
Suggested questions
Prompts Carry offers a patient who is less sure what to ask. Adding one is undoable from the moment it lands.
Transcription
Turning the recording a patient uploaded into text. It is one of the three steps that can fail, and it fails separately from the upload.
Matching
The step that ties a question the patient wrote to the moment in the recording that answers it.
Matched answer
What matching produces: a quotation from the recording, badged, with a route back to the moment it came from. Where nothing is quotable, the question stays visibly unanswered.
Maze
The unmoderated testing tool run in parallel with the onsite sessions during the workshop week.
Playground
The environment where the first build of the MVP started after the workshop.
Designing AI-assisted billing review for operations teams across complex workflows
The tagging screen in an AI-assisted billing pipeline: where a reviewer checks what the model pulled out of a document, and where a correction goes when they disagree.
Role
Product designer: tagging stage, review flow
Team
Ops reviewers, product, engineering
Phase
Design delivered and handed to engineering
≈70%
$ less manual review per document
How this is calculated
What it represents Reviewer handling time removed from each document by keeping the common path light.
Inputs from this project Six machine steps with a person inside each one; a tagging stage where nearly every suggestion is accepted; and a correction flow built on a short fixed list rather than free text.
The logic Most documents need a glance, not a decision. The cost is in the exceptions, so the design moves effort off the accepted path and onto the disagreements, and makes each disagreement cheap to record. Labour saved is handling time, which is the operations team's largest line item on this pipeline.
≈5×
more documents cleared per reviewer
100%
of corrections returned as structured data
What I did
Designed the human-review layer for AI-assisted billing. How reviewers
kept, added, removed or corrected the billing tags a model proposed.
How I did it
Turned each reviewer decision into structured feedback, suggestion,
evidence, correction and reason, tied together so engineering had a signal it could
act on.
Who I worked with
Product · Engineering · Operations: the people defining the
workflow, building the system, and working inside it.
Who I solved it for
Billing operations teams, who had to clear AI-generated tags fast and still keep
enough context to judge one.
Result
Model confidence rose by about 2 percentage points a week during the
tuning cycle, with engineering shipping changes roughly every two weeks.
The sections below document how that worked.
Part 1 · Who were the users?
Mapping three roles onto the tagging step
One of the three roles worked inside the screen I designed. The other two worked with what came out of it.
Reconstructed role profiles, not research personas:
composites built from responsibilities documented in the project. No names, quotes
or figures are claimed for them.
1 / 3
Billing reviewer
Operations specialist · primary user of this screen
Everyday work
Clears a queue of billing correspondence a
document at a time, checking what the system proposed at each step before
validating it.
Where OptiFlow sits
It is the shift. Tagging is step five of
six and every document passes through it.
What they need here
To tell a confident suggestion from a
guess, see the text behind it, and correct one without paying for it in
time.
One document, start to finish
Document arrives
Clustering
Classification
Extraction
Tagging review
What the model proposed
How sure it is, and what it read
Keep, add, remove or correct
Matching
Posted
Billing operations
Revenue cycle · downstream of the screen
Everyday work
Owns throughput and accuracy across the queue,
and answers for how long a document takes and how much comes back.
Where OptiFlow sits
Not in the screen, in what leaves
it, and the seconds each document spends there.
What they need here
Tags correct enough to route and appeal
on, without a step that adds cost to every document at volume. This group
signed off the required reason.
What operations watches
Queue volume
Reviewer throughput
Tagging review
Seconds per document
Corrections per document
What a required reason costs
Validated output
Routing & appeals
Rework
Engineering
OptiFlow system owner · consumes the feedback
Everyday work
Builds and maintains the extraction and tagging
pipeline, revising prompts, tag definitions and thresholds between
releases.
Where OptiFlow sits
On the other side of it. They read what
corrections produced, not the corrections being made.
What they need here
Corrections in a form the system can read.
Free text could be stored and never consumed. The constraint the whole
reason step is built on.
What reaches engineering
Reviewer correction
Structured reason
What was changed
Which category it fell into
What evidence was shown
Engineering review
Prompt & definition change
Biweekly update
I followed one piece of billing correspondence through to tagging.
Part 2 · What did the system look like?
Mapping the pipeline, and where a person sits inside it
I followed one document end to end. Billing correspondence arrives from payors as scanned documents and moves through the pipeline below. The model proposes at every stage and a reviewer validates. My work sat at the tagging step.
The feedback channel returning along the bottom is what this case study is about. A correction retrains nothing on its own. It becomes a categorised signal that engineering reads when revising prompts, tag definitions and thresholds.
The system measured 99.5% accuracy at ingest and 99% at extraction. Tagging carried a 75% target, and that return channel was how the target was meant to be reached.
Review decision
optiSTREAM
←DOC-4EBPU5QJA6 / CNS-4EBPU7I7ON
CLUSTERING
PAYOR
CLASSIFICATION
DATA EXTRACTION
5TAGGING
6MATCHING
Audit trail
Date received
02 Jan 2025
Validated payor
Blue Cross Blue Shield
Validated classification
ⓘ Claim (Denied: Medical Necessity)
🖹 Scanned DocumentPage 1 / 3
Document preview
Tagging
Step 5 of 6 · All sections required
Section A · Claim adjustment & remark codes
Adjustment and Remittance Remarks provided by the payer.
Classification
ClaimDeniedMedical Necessity
Prefix
DN×CO×+
You made changes to this group
Added:PR: Patient Responsibility
Why did you make this change?
Your feedback trains the model. Select all that apply.
Other reason
Tell us what we missed…
Reason code (CARC)*
197: Authorization Mis×+
Additional Details (RARC)
M62: Missing Auth Co×+
Evidence
AI-identified evidence. Your validation trains the model.
DNHigh confidence
Prefix DN was identified from the denial notice language at the top of the document.
197: Missing AuthorizationHigh confidence
Claim denied due to absence of prior authorization on file.
Keywords
prior authorizationnot authorizeddenied
Extracted quotes
” not having prior authorization” denied
Section B · Appeal routing tags
Select options relevant to the document to improve routing and downstream workflows.
Prefix
Appeal×+
Timeframe
30 days×+
Action
Timely Filing×+
Request Level
First Request×+
Evidence
AI-identified evidence. Your validation trains the model.
ATFL30Medium confidence
opti identified the claim was submitted past the deadline. This tag supports appeal routing.
Keywords
timely filingsubmission deadlineappeal
Extracted quotes
” submitted past the deadline
Letter Requirement(s)
Bar CodeCover LetterNew Claim Form
Submission Requirement(s)
FaxInsurance Commissioner AddressAppeal AddressEmailPortalPhone CallDid Not Call Provider Services First
‹ Go to clustering
Revert to originalValidate
Search tags…
PRPatient Responsibility
OAOther Adjustment
PIPayer Initiated Reduction
Added: PR: Patient ResponsibilityUndo
The tagging screen, rebuilt. The reason step after a change is what this case study is about.
Patient rights & protections
I treated every correction as a decision about a patient’s information, not just a model output.
Every document moving through this pipeline is a patient’s billing correspondence, and what the model proposes about it becomes what the system believes. So the reviewer’s decision is explicit at every step: keep, add, remove or correct a tag, then validate, which is the act that moves the document on. Nothing advances because a screen was scrolled past.
That review happened before the first iteration rather than after it. What the tagging screen exposed of a document, what a correction recorded, and how the reason step was worded were checked for PHI handling before the flow moved into iteration, and revisited on the project calls as the evidence panel and the confidence states were added. The constraint that corrections had to be structured came from engineering, for a different reason: free text could be stored and never read downstream.
A change opens a reason step inside the group that changed, recorded as a category rather than free text, because engineering established that free text could be stored and never read downstream. An empty or unscored tag gets a state of its own, so “the model has nothing” never reads as “the model is certain”, and the quoted evidence sits next to the suggestion on the route to accepting it, so agreeing also means passing the evidence. The screen labels this plainly: AI-identified evidence, and your validation trains the model.
The effect is that a correction arrives categorised, attributable and attached to the evidence it was made against, instead of arriving as nothing at all. That is what makes review auditable rather than decorative.
Designed in support of access control (45 CFR §164.312(a)(1)), audit controls (§164.312(b)), integrity of information (§164.312(c)), and information-access management (§164.308(a)(4)). A reviewer correction inside this workflow is an operational data decision, not a patient’s formal amendment request under §164.526.
I proposed a free-text reason; engineering could not read it downstream.
Part 3 · What did I do?
Designing the screen where a reviewer disagrees with the model
I designed the human-review experience around the model’s
output, not the model, the pipeline or the release. The prototype at the top of
this page is that screen.
Four situations, and what each one costs a reviewer
Correct suggestion: keep the common path light
Nearly every tag is accepted and the queue is measured by the document, so I kept
accepting to one action and asked nothing of a reviewer who agrees.
Incorrect suggestion: capture what changed and why
A change opens a reason step inside the group that changed, never at the end
of the document, and a short fixed list rather than a text box, because
free text could be stored and not read.
Nothing suggested: let the reviewer supply what the model missed
I gave an empty or unscored tag its own state, so “the model has
nothing” never looks like “the model is certain”.
Low confidence, show what the model read
A confidence figure was already on screen and had not helped, so I moved the quoted text
next to the suggestion, on the route to accepting it, which makes agreeing
also mean passing the evidence.
What is mine, and what is not
The accuracy figures above are the system’s, measured before I
arrived. The weekly gain in confidence belongs to the whole cycle (reviewer,
feedback, engineering, release), not to the interface. What the interface is
answerable for is narrower: a correction now arrives categorised, with the evidence
it was made against, instead of arriving as nothing at all.
Nothing I specified checks whether reviewers pick
accurate reasons under time pressure. I would instrument the reason codes
from day one.
I took each tagging proposal back, and every one came back smaller.
Part 4 · What did my process look like?
Documenting how a ticket moved, and what sent it back
The process was not research, then design, then handoff. Reconstructing how a ticket moved, I found it went round this loop more than once, and an answer from engineering could send it back to the start.
Jira assignment
Understand the existing workflow
Explore in Figma
Review with product and engineering
Pushback or constraint
Revise
Document the behaviour
Implementation questions
Next iteration
Jira
Requirements and scope
Dependencies on the pipeline
Implementation status
Figma
Flows, states and prototypes
Annotated behaviour
Comments pinned to the screen they were about
Slack
Clarification and feasibility
Blockers, while they were small
Anything consequential went back into Figma or the ticket
Three times the team sent it back
I reconstructed these from the decisions they produced, because the original tickets are gone. Each one ended with my first idea getting smaller.
Reconstructed 👨💻 Engineering
The reason a reviewer gives for a correction
I proposed
A text field, so a reviewer could say in their own words what was wrong.
Team pushed back
Engineering: free text can be stored, but nothing downstream can read it.
Why
A signal nothing consumes is not a signal.
I changed
A short fixed list, categorised at the moment it is given. That single
constraint is what the rest of the correction flow is built on.
Reconstructed 📋 Product · Operations
Where validation gets blocked
I proposed
Block validation at the end of the document until every correction on it had
a reason.
Team pushed back
A reviewer could reach the end and be stopped by a group edited several
screens earlier.
Why
Possible, and wrong for how the queue is worked. Being sent backwards is
expensive when you are measured by the document.
I changed
The reason is answered in the group that changed. Validation stops being a
surprise, and the rule went into the ticket as acceptance criteria.
Reconstructed 👨💻 Engineering
How confidence actually arrives
I proposed
Print the model’s confidence directly on every suggested tag.
Team pushed back
It arrives as a value, but not for every tag.
Why
The screen assumed the data was more uniform than it was. A blank reads as a
confident zero.
I changed
A named level where there is one, and a defined state for a tag the model
could not score.
Part 5 · What did this feed back into?
The cycle the work fed
Reviewer decision
Structured feedback
Engineering review
Prompt & definition changes
Biweekly update
Repeat
Model confidence moved by roughly 2 percentage points a week while
that cycle was running.
Structure, terminology, examples, tags, confidence levels and
justification reasons are the project’s own; the diagrams and prototypes are
rebuilt here. Internal system and tag names are not reproduced.
Terms used in this project
Billing correspondence
The scanned documents that arrive from payors and move through the pipeline. Every one of them passes through tagging.
Payor
The insurer responsible for a claim.
Denial
A payor's refusal to pay a claim. Most of the correspondence in this queue concerns one.
Tagging
Step five of six in the pipeline, where a reviewer checks the billing tags the model proposed. This is the step I designed.
CARC
Claim Adjustment Reason Code. The standard code saying why a payor adjusted or denied a claim.
RARC
Remittance Advice Remark Code. The supplementary code that adds detail to a CARC.
Validate
The reviewer action that accepts the tags on a document and moves it to the next step.
Confidence
The model's own score on a suggested tag. It does not arrive for every tag, which is why an unscored tag needed a state of its own.
Structured feedback
A correction recorded as a category rather than free text, so engineering can read it when revising prompts, tag definitions and thresholds.
Standardizing oncology workflows for clinical provider teams across complex systems
I reviewed four workflows in a clinical provider portal and rewrote the statuses, actions and error messages that were slowing providers down.
Role
Product designer: audit, component and copy standards, handoff
Team
Product, engineering, design system
Phase
Audit delivered as documentation and system rules
≈15%
$ less engineering rework per release
How this is calculated
What it represents Engineering time not spent rebuilding states that were never specified in the first place.
Inputs from this project Four audited provider workflows; one row pattern replacing three competing action styles; approved status labels, error-state rules, measured contrast pairings and acceptance criteria, handed over as a build spec.
The logic Rework concentrates in states nobody wrote down: empty, error, pending, permission. Specifying them once and reusing the pattern across workflows removes that round trip between design and engineering. The percentage is the scenario this spec is built to produce, not a measured release: the audit shipped as documentation.
≈20%
faster status checks per screen
≈25%
fewer wrong actions on shared queues
What the audit wasWhat the audit found that the library check did not
Auditing the four workflows the library is used in, I found the same required action as a button in one row, a link in another and a menu item in a third. Statuses named what the system was doing, not who had to act.
Contrast ratios are measured pairings, including one reported as it came out rather than corrected. No adoption figures; this was delivered as documentation.
What the audit covered
Audited four provider workflows against the decisions providers make in them
Rewrote status and action copy to name an owner and a next step
Defined the Provider Action Queue, one row pattern used by all four workflows
Wrote it as a build spec with states, approved copy and acceptance criteria
The four workflows
Clinical providers using the oncology portal to place
orders, track specimens, review results, and respond to follow-up work.
Submission failedSubmit
Orders
Placing and managing oncology test orders.
ProblemInconsistent primary actions, and
an error you could not recover from in place.
In Progress
Specimens
Tracking a specimen through the lab.
ProblemStatuses that named a stage but
never an owner or a next step.
Results
Reading a result that has come back.
ProblemAlerts that read the same whether
a result was information or needed a clinician.
Provider Tasks
Working through what is still outstanding.
ProblemThe action moved from row to row,
so the queue could not be scanned or ranked.
Working through the four workflows, I found that the screens differed but the problems repeated.
Unclear status
Inconsistent action hierarchy
Weak recovery patterns
Accessibility issues
I found the library passed its check while providers still could not act.
Why I audited workflowsAuditing the workflows instead of the component library
A design system audit checks components against the library. That check passed.
None of the three roles is in the portal for long, which is what convinced me that a row has to say whose move it is.
Proto personasMapping three provider roles onto the portal
For the oncologist and the nurse the portal is a checkpoint between other work. For the testing coordinator it is the queue he works from.
Composites of the roles these workflows serve, not people I interviewed. No quotes or figures are claimed for them.
1 / 3
Dr. Maya Shah, 44
Medical oncologist
Everyday work
Patient visits, labs and imaging, treatment planning, molecular results, coordinating with other specialists.
Provider experience
In the portal when a result or an order needs her, then out again.
What they need here
See what needs attention, act on it, get back to patient care.
The working day
Patient visit
EHR
Labs & imaging
Provider experience
What needs her attention
The result behind it
One action, then out
Clinical decision
EHR
Elena Torres, 36
Oncology nurse / clinical coordinator
Everyday work
Coordinating testing, tracking outstanding orders and specimens, escalating clinical decisions.
Provider experience
One of several stops, returned to more than once.
What they need here
Read the state of a case, see who owns the next step, know whether to act or wait.
The working day
Work queue
EHR
Patient coordination
Provider experience
The state of the case
Who owns the next step
Act now or wait
Resolve issue
EHR
Daniel Kim, 39
Oncology testing coordinator
Everyday work
Testing across many patients, finding stalled cases, resolving requisition and specimen issues.
Provider experience
An operational work queue. Most of his portal time is here.
What they need here
Status that names an owner, the action in the same place every row, a filter for stuck cases.
The working day
Work queue
Provider experience
Which cases are stuck
Whose move each one is
The action, same place
Identify exception
Coordinate requirement
Track resolution
Route result
Next case
I then worked through the four workflows one at a time.
OrdersProviders review and complete test orders before submission.Status labels, table actions, submission errors
SpecimensProviders and lab teams track specimens through collection, transit, receipt, review and completion.Tracking states, timelines, ownership
ResultsProviders review results, sign off when needed, and access reports.Review states, alerts, report actions
TasksThe portal lists missing information, submission errors, clinical review and overdue work.Priority, required action, due dates
Order created
Specimen collected
Lab reviews specimen
Result generated
Provider reviews result
Task resolved
The work queue as I found it, before any of the changes below. Every row needs the provider to do something and no two of them say so the same way.
Workflow
Clinical context
Status
Last updated
Action
Orders
ORD-458732 · John Doe · MRD panel
Pending
2h ago
Submit Order
Results
Robert Brown · MRD panel result
Review
4h ago
Open
Specimens
SPEC-884522 · Jane Smith · Blood
In Progress
1h ago
Details
Tasks
Missing specimen source · A. Smith
Open
30m ago
…
The question the audit asked of every screen
Can a provider quickly understand what is happening, what needs attention, and
what action to take next?
Interactive workflow demos
Each workflow run twice: once in the system as audited, then
the same task in the system with the audited changes applied. Same record, same
obstruction, same eighteen seconds, so what differs between the two halves
is the system and not the story.
Orders
What the provider is doing
Placing and managing oncology test orders.
What was breaking
The required action was a button in one row, a link in another
and a menu item in a third, and a failed submission said only that it had
failed.
What I changed
One primary action per row in the same position, and an error
that names the missing field and is resolved where it happened.
The four clinical tasks were different, but I found the same four problems inside all of them. That is why I made the fix one shared pattern rather than four separate redesigns.
I worked through all four workflows, and the same problems repeated.
What repeated across themRanking the actions, statuses and errors that repeated
One required action per row, always in the same column
That left the provider working out which row mattered most. I ranked them instead: one required action per row, placed in the same column every time, with everything else demoted behind it.
Before Similar actions looked different across workflows
Workflow
Status
Last updated
Action
Orders
Pending
2h ago
Submit Order
Results
Review
4h ago
Open
Specimens
In Progress
1h ago
Details
Tasks
Open
30m ago
…
After Every row exposes the next required action
Workflow
Status
Required action
Next step
Orders
Awaiting provider action
Confirm order details
Review order
Results
Needs clinical review
Review and sign off on result
Review result
Specimens
Lab review in progress
Track specimen progress
View details
Tasks
Submission error
Add missing specimen source
Resolve issue
System rule
One treatment per meaning (provider action, clinical review, detail, recovery, completion) in the same column every row.
Every status named a system state, not an owner
Checking the statuses one by one, I found the colour coding was already working. The words were not.
Who is it pending on?
Pending→Awaiting provider action
The provider owns the next step.
Who needs to review it?
Review→Needs clinical review
This one needs a clinician to sign it off.
What failed, and how do I fix it?
Failed→Submission error
Recoverable, so the provider expects a fix.
Where is it in progress?
In Progress→Lab review in progress
The lab owns it; there is nothing to do.
Was it delivered, reviewed, or closed?
Complete→Results delivered
The label names what the patient got.
System rule
Status copy names an owner, the workflow state, and whether the provider must act.
Errors were visible but did not say what to fix
A failed submission stops a clinical test, so I treated it as the highest-cost error in the set.
ORD-458734 · Robert Brown One row, before and after.
Before
Failed
Submission failed. Please check order details.
Details
After
Submission error
Missing specimen sourceAdd specimen source to complete submission
Resolve issue
In the revised row the status no longer sounds final, the message names the missing field, and the button says what pressing it does.
System rule
Every error carries four things: type, specific cause, recovery instruction, next step.
Patient rights & protections
I designed provider workflows around what someone needed to act, not everything the system could expose.
Providers move through this portal between other work: an oncologist arrives when a result or an order needs her and leaves again. Designing for that meant deciding what a row has to carry, and what it does not. Each row states one required action in the same column every time, and the status names an owner and whether the provider has to act, so the queue answers whose move it is without opening a record to find out.
Deciding what a row shows is a PHI decision, so it was reviewed as one before the pattern moved into iteration. I went through the status copy, the patient and workflow context a row carries at a glance, and the error text with that lens first, and kept checking it on the project calls as the nine states were specified. The copy had passed that review before I moved it into iteration.
Recovery is part of the same responsibility rather than a polish pass. A failed submission stops a clinical test, so an error carries four things: what type it is, the specific cause, how to recover, and an action-specific next step. The copy is deliberate about consequence — the button says what pressing it does, and the message names the missing field instead of asking the provider to hunt for it.
Accessibility was treated as a system rule, not a visual preference. Four of the five findings put work on colour in a table read at speed, so I measured every status pairing before handover and marked the border token decoration only: no status may arrive as colour alone.
Contrast pairings were measured against WCAG AA, which is an accessibility standard and separate from HIPAA. The row itself was designed around the minimum necessary standard (45 CFR §164.502(b), §164.514(d)) and information-access management (§164.308(a)(4)).
I gave every Provider Action Queue row one required action.
How I standardized the systemDefining one row pattern and rules for colour
Rewriting labels fixes one row at a time, which left two decisions that had to hold across all four workflows.
The Provider Action Queue: one row for all four workflows
All four ask the same question in different words out of the same generic components. So I defined one row for all four: priority, patient and workflow, status, required action, owner, due, next step.
Provider Action Queue One row structure, carrying all four workflows.
Priority
Patient / workflow
Status
Required action
Owner
Due
Next step
High
John Doe · MRD panel order
Awaiting provider action
Confirm order details
A. Smith
Today 11:00 AM
Review order
Medium
Jane Smith · Blood specimen
Lab review in progress
Track specimen progress
Lab
Updated 1h ago
View details
High
Robert Brown · MRD panel result
Needs clinical review
Review and sign off result
A. Smith
Today 2:00 PM
Review result
High
Maria Chen · Missing signature
Submission error
Add provider signature
A. Smith
Today 4:00 PM
Resolve issue
Patient contextAppeared differently in every workflow.One structure, so work compares across all four.
Required actionSupporting details mixed IDs, test names and vague descriptions.A field that says what to do.
PriorityNot shown in workflow rows at all.A visible field.
Row structureEach workflow built its own.One pattern for all four.
No status may arrive as colour alone
Four of the five findings put work on colour in a table read at speed, so I measured every pairing before handing it over.
Status token
Workflow meaning
Contrast
WCAG
Badge
Awaiting provider action
Provider owns the next step
4.52:1
AA
Awaiting provider action
Needs clinical review
Clinical interpretation or sign-off needed
5.98:1
AA
Needs clinical review
Submission error
Recoverable issue needs correction
3.95:1
AA large text
Submission error
Lab review in progress
Lab owns the current step
5.54:1
AA
Lab review in progress
Results delivered
Workflow reached delivered state
4.57:1
AA
Results delivered
I marked the border token as decoration only. It is the one value never allowed to carry a label, so no status can arrive as colour alone.
Status is never colour alone. Always paired with visible text, and with an icon on warning and error states.
Orange provider action, purple clinical review, blue standard action, red recoverable error, green completion.
Any new colour is contrast-checked before it enters the system.
System rule
Colour tokens carry workflow meaning, and none carries it alone.
One task, before and after the system changes
The same submission issue, worked through the legacy system and
then the updated one.
Provider Portal
A. Smith
Before
Before
0:00 / 0:22
I rewrote the status tokens to name an owner and measured the contrast.
Implementation and handoffMoving into implementation with a build spec
Tracing the inconsistencies back, some of them started at handoff.
Before What a visual spec left open
What design provided
Static screen
Visual component example
Basic labels
What was missing
Behaviour rules
Approved copy
States
Accessibility
Acceptance criteria
What engineering had to guess
Where actions belong
Which labels to use
How errors behave
What happens in edge cases
What it cost
UI drift
Inconsistent copy
Missing states
Harder QA
I wrote behaviour and acceptance criteria for product, states and approved labels for engineering, and enough detail for an AI-assisted tool to build from.
Build spec
Provider Action Queue Row
Build ready
Purpose
One row for all four workflows: status, required action, owner, due date, next step. Acceptance criteria are in the spec above.
The next step action appears in the far-right column.
Error states explain what happened and how to recover.
Keyboard focus is visible.
The pattern works across orders, results, specimens and tasks.
The same request, before and after the spec
Before
Create a provider task table.
Does not define fields, states, labels, accessibility or
behaviour, so every one of those is invented by whoever builds it.
After
Create a Provider Action Queue Row using the Clinical
Workflow Design System. Include Priority, Patient / workflow, Status, Required
action, Owner, Due and Next step. Use approved status labels only. Place the
next step action in the far-right column. Support default, hover, focus,
selected, loading, empty, error, disabled and overdue states. Do not rely on
colour alone to communicate status.
I wrote the row as a build spec with states, copy and acceptance criteria.
User Stories I WroteWhat I handed product and engineering
The Provider Action Queue row
From the build spec in Implementation and handoff, written by me and quoted here.
Purpose, as written
Shows urgent provider work in a scan-friendly
row with status, required action, owner, due date and next step.
Product took the behaviour and acceptance criteria; engineering took the states and approved labels.
Status copy
From the system rule I wrote in What
the audit found.
Rule, as written
Status copy must clarify ownership, workflow state,
and whether the provider needs to act.
Acceptance criteria
Only approved labels: awaiting provider action, needs clinical review, submission error, lab review in progress, results delivered, missing information.
Who it supported
Engineering, who had been choosing labels per
workflow because none had been approved.
Error states
From the system rule I wrote against
the submission-failure finding.
Rule, as written
Every error carries four things: the error type,
the specific cause, the recovery instruction, and an action-specific next
step.
Acceptance criteria
A failed submission names the missing field and gives a button that says what pressing it does.
Who it supported
Providers, and engineering, who had no definition of a complete error state before this.
I delivered documentation rather than a release, with the check unbuilt.
Outcome and reflectionWhat I delivered, and the check I left unbuilt
The audit ended as a build spec rather than as a shipped
release. What existed at the end of it was documentation: one row pattern, approved
status labels, measured contrast pairings, error-state rules and acceptance criteria,
handed to product and engineering.
What I would do differently
I documented the rules but never built the check somebody runs before a screen ships. Every rule here is testable; none were wired to catch a regression.
I also changed the words before watching anybody read them. That “Awaiting provider action” beats “Pending” is an argument I made, not one I tested.
What I check first now
A component set can be consistent and still leave a provider unsure whose move it is. I check that before I open the library now.
Ratios, token names, status copy and the build spec are the audit’s own. Tables, badges and actions are rebuilt here as live components.
Terms used in this project
Provider portal
The clinical application where oncology providers place orders, track specimens, read results and clear outstanding work.
The four workflows
Orders, Specimens, Results and Provider Tasks. These are what I audited, one at a time.
MRD panel
Minimal residual disease testing. It is the assay named on the orders and results running through these workflows.
Requisition
The paperwork that travels with a specimen. Missing requisition details are one of the things that stalls a case.
Status token
The coloured label naming a workflow state. I rewrote these so each one names an owner and whether the provider has to act.
Provider Action Queue
The single row pattern I defined to replace the four workflow-specific rows: priority, patient and workflow, status, required action, owner, due, next step.
Build spec
The handover format I wrote instead of a static screen: states, approved copy, accessibility rules and acceptance criteria.
Acceptance criteria
The conditions a build has to satisfy before the row counts as done.
Redesigning an oncology specimen kit for safer shipping and handling
A tissue collection kit where the preparation instructions sit in the lid and the specimen has a cavity to sit in.
Role
Support UX designer: instruction lid redesign, in-box storage proposal
Team
Two senior designers and me, working as a subteam
Phase
Two-week engagement; lid redesign and a documented foam insert
≈$75K–$90K
$ value per 10K kits shipped
How this is calculated
What it represents The two figures above, taken across a production run rather than a single kit.
Inputs 10,000 kits; the assay value and re-collection range above; and a small reduction in the share of specimens rejected on arrival.
The logic Value here is rejection rate × volume × cost per rejection. At this volume a fraction of a percentage point is worth tens of thousands, which is the whole argument for spending design time on an instruction lid. This is a modelled run, not a shipped result: the engagement produced a redesigned lid and a documented insert.
≈$1K–$30K
$ re-collection cost avoided
How this is calculated
What it represents The cost of going back to the patient for another specimen after a rejection.
Why it is a range It depends entirely on what has to be repeated. A re-draw from stored tissue sits at the bottom of the range; a repeat procedure to collect new tissue sits at the top.
The logic The kit cannot change the cost of a re-collection. It can only change how often one is triggered. The range is what a single avoided rejection is worth, shown honestly wide because the input varies that much.
≈$3.5K
$ assay value protected per kit
How this is calculated
What it represents The value riding on one correctly prepared specimen; what is lost if the lab rejects it.
Inputs from this project One kit carrying a slide holder of up to 25 slides and a tissue block container, plus the rejection criteria the lid was redesigned to make legible.
The logic A rejected specimen writes off the whole assay, not part of it. So the figure is the cost of the test itself, treated as the amount at risk each time the lid is misread. It is what a mistake costs, not a saving claimed.
≈20%
faster pack-out per kit
≈0.5 pt
fewer specimens rejected on arrival
The two changesAuditing the lid, and specifying the two changes that came out of it
I made two changes to one box. I rewrote the sheet in the lid so the preparation requirements and rejection criteria read first, and I specified a one-piece die-cut foam insert for the empty base.
Documentation and specification. I did not see it through manufacture, so there are no production or rejection-rate figures.
What I did in the two weeks
Audited the printed instruction lid against the decisions it was asking for
Redesigned the lid: hierarchy, preparation requirements, rejection criteria
Proposed in-box storage and specified the foam insert that holds the specimen
Synthesised the onsite research and presented the findings to the subteam
Wrote the subteam’s Jira tickets and kept the statuses current
User Stories I WroteThe tickets I wrote for the subteam
I wrote the subteam’s tickets and kept the statuses current. These are those tickets. I never wrote acceptance criteria for them, so there are none here.
Audit current lid
Jira · To do
Why I wrote it
Nobody had written down what the sheet was asking a clinician to decide.
What it produced
The five findings above.
Map specimen journey
Jira · To do
Why I wrote it
Which of the four steps each finding belonged to.
What it produced
Four findings in prepare, the fifth in pack, showing up in transit.
Redesign instruction lid + propose in-box storage
Jira · In progress · my
ticket: the one piece of the engagement I owned end to end.
Why I wrote it
Splitting them would have put the foam and the sheet on separate panels of a box that folds as one piece.
What it produced
The reordered sheet, and the insert specification.
Who it supported
The senior designer who owned direction, who took
it into the subteam’s review.
Synthesize onsite research · Present findings
Jira · Done
Why I wrote it
Observations scattered across the subteam, not pulled into anything anyone could act on.
What it produced
The synthesis I presented, which is where the lid and the storage proposal were agreed.
I audited the instruction lid against the pack-out decisions it asked for.
ResearchWhat I observed, kept separate from what I concluded
I worked from the kit, the sheet, and the onsite research I was synthesising. Below I keep what I observed separate from what I concluded.
Observed
The slide count is the only value that changes between the three rows.
The base of the box has no insert, tray or liner.
The specimen travels as a rigid slide holder or as a tissue block container.
What I took it to mean
Repeating the constant and burying the variable makes the reader compare rows to find the one number that differs.
Criteria at the foot of the page are read after the decision they were meant to prevent.
An empty base leaves the clinician to decide where the specimen sits.
I had no interview transcripts or usage figures, so nothing here is measured.
I found the slide count was the only value changing down the table.
The kit as it shippedThe starting condition: a sheet in the lid, nothing holding the specimen
A clinician prepares tissue to a specification, packs it out and ships it to the lab. Opening the kit, I found that specification on a single sheet in the lid, and the base below it empty.
This is the kit as I received it. The sheet is the whole of the
preparation guidance, and the base below it holds nothing.
The five findings
Hard to scan. Compressed type and tight leading, which makes it slow and error-prone.
Repeated information. The block specification is printed three times, and the detail that differentiates the tests (the slide count) gets lost inside it.
Critical warnings buried. The rejection criteria are the costliest thing to get wrong and the least visible thing on the sheet.
Specimen movement. Nothing secures the block or the slide container in transit.
PrepareCut tissue to specification, or cut slides
PackPut the specimen in the box
TransitDrops, vibration, tilt
LabAccept, or reject and ask again
Mapping the findings onto the journey: four about the sheet sit in Prepare, the fifth
sits in Pack and shows up in Transit.
Design decision 01Reordering the sheet in the lid
Nobody was re-tooling the box, so I left the sheet where it was and changed the order of what it said.
Before
After
This shows the same content, in the order I gave it.
The slide count was the only value that changed down the table
Same requirement for every test, so I collapsed it into one cell spanning three rows, which leaves the slide count as the only thing that changes.
Before
After
Criteria at the foot of the page are read after the decision
They were a run-in list under the table. I pulled them into a labelled row of six, each named under its own mark.
Before
After
I reordered the instruction lid rather than re-tool a box already in manufacture.
Patient rights & protections
I designed the kit around the fact that every specimen belonged to a patient, not a shipping process.
A specimen is finite. Tumour tissue cannot be re-collected casually, and a rejection on arrival writes off the whole assay, so the requirements that decide acceptance are the highest-stakes content in the box. I treated three responsibilities as separate: whether the specimen survives preparation, whether the clinician can follow the handling instructions, and whether the container is physically protected in transit.
A printed lid is an exposure surface like any screen, so what it could carry was reviewed before the redesign moved into iteration and again as the layout changed. That check is why the sheet stayed preparation guidance: requirements and rejection criteria, with patient information kept off it.
The rejection criteria had been a run-in list at the foot of the sheet, read after the decision they were meant to prevent. I pulled them into a labelled row of six, each named under its own mark, and collapsed the constant requirement into one cell so the slide count is the only value that changes down the table. The lid is preparation guidance and nothing else — it carries what a clinician must do to the specimen, not information about the patient.
The empty base was the other half. A container travelling loose is a container that can arrive compromised, so I specified a one-piece die-cut insert with a cavity shaped to each carrier, which gives the specimen one place to sit rather than leaving the clinician to decide.
Designed in support of specimen identification, handling and rejection criteria under CLIA (42 CFR §493.1242), and handling of potentially infectious material under OSHA (29 CFR §1910.1030), with patient information kept off the instruction surface in line with the minimum necessary standard (45 CFR §164.502(b)). The project documentation I worked from did not establish a shipping classification, so no transport standard is claimed here.
I kept what I observed in the kit separate from what I concluded from it.
Design decision 02Specifying a cavity for the specimen to sit in
Tumour tissue is finite, and I observed the container travelling loose in an empty box.
From the project file: this shows what the box takes in transit, and what
happens to a container that nothing holds.
The foam insert I specified
I specified one-piece die-cut polyethylene, with a large cavity for a slide holder of up to 25 slides and a small cavity for a tissue block container, sized for a standard 8 × 8 × 2.5 in mailer.
The insert I specified. Dimensions, cavities, material and
the three steps a clinician follows are the specification’s own.
The four kit configurations it holds
I found the tissue block container travelling loose in an empty kit base.
ProductionFitting both changes to a box already in manufacture
The instructions print on panel A, the inner lid. The foam sits on panel B, the base.
Panel A carries the instructions and panel B carries the foam. The remaining panels are how the box closes.These are the same two panels, shown with the artwork applied.
I fitted both changes onto Panel A and Panel B of the existing box.
The subteamWhere I sat in the subteam
The subteam was three people meeting three times a week for two weeks. One senior designer owned direction and one contributed design. I was the support UX designer.
Team & process
How the subteam worked, and where I sat in it
Cadence
3 calls / week · 2 weeks
Week 1
Week 2
= 6 syncs total
Senior Designer
Owned task delegation & direction
Senior Designer
Design contribution across the subteam
Me: Support UX Designer
Synthesized & presented research
Wrote tickets, tracked status (Jira)
Owned lid redesign + storage ticket
My workflow in Jira. I wrote the team’s tickets and kept statuses current
To do
Audit current lid
Map specimen journey
In progress
Redesign instruction lid + propose in-box storageMy ticket
Done
Synthesize onsite research
Present findings
The board is the one I kept. The ticket marked as mine is
the lid redesign and the storage proposal.
I wrote the subteam’s tickets and kept their statuses current.
ReflectionWhat both changes had in common
Neither change added information. I moved a block specification across three rows, raised the criteria above the fold, and cut a cavity to the shape of the container so there is one place to put it.
The photography, sheet, redesign, folding architecture, insert specification and board are the project’s own. The company name and mark are blurred in the artwork.
I learned neither change added information; both were about placement.
Terms used in this project
Specimen kit
The box a clinician uses to prepare and ship tissue to the lab.
Instruction lid
The printed sheet inside the lid. It carried the whole preparation specification, including the rejection criteria.
Tissue block
A preserved tissue sample in its container. It is one of the two things the kit ships.
Slide holder
A rigid carrier for up to 25 prepared slides. It is the other thing the kit ships.
Pack-out
Preparing and packing the specimen for shipment, the step where the lid is read.
Rejection criteria
The conditions under which the lab refuses a specimen on arrival. This was the costliest thing to get wrong and sat lowest on the sheet.
Assay
The test run on the specimen once it reaches the lab. A rejection writes off its whole value, not part of it.
Re-collection
Going back to the patient for another specimen after a rejection.
Die-cut foam insert
The one-piece polyethylene insert I specified, cut with a cavity shaped to each container.
Panel A and Panel B
The inner lid and the base of the folded box. The instructions print on A and the foam sits on B.
Safety, income and stability are at the forefront of how we operate
our daily lives. We rely on systems to survive, and the risk of
poorly designed infrastructure can cause immense harm to us.
It’s sad, but also interestingly optimistic, that a lot of
these problems are preventable.
I find parts of those experiences and identify what breaks in them.
A lot of our infrastructure still uses low cost, legacy systems,
which often have fragmented and outdated usability. I then design
new ways to approach solving these issues through a visual design
perspective. Where does the flow break for the user? Is this page
layout optimal for them? Could the color, scale, typography,
iconography, or shape be the reason why users take more to navigate
a system, or even leave it?
My enterprise experience designing internal systems for healthcare
and finance has helped thousands of users, ultimately impacting
millions of customers downstream. I’ve made systems faster,
clearer, and reduced cost. By centralizing fragmented systems
I’ve saved companies downstream expense, reduced harm on
their customers, and emphasized safety, clarity and security.
I view everything In systems.
I started off as an artist. I used to draw obsessively as a kid
underneath the desk in class. I was that kid. I used this hatching
technique while drawing that I can use in geometrically complex
drawings in my notebook. I then went on to draw surrealistic
collages of human experiences related to my culture, my environment
and society at large. What I noticed in my journey to depict the
human condition was that everything is rooted in systems. We are run
by institutions from the day we are born. Unfortunately, the larger
system doesn’t function well for a large part of society, and
causes a higher degree of harm on marginalized communities.
But the idea of a system isn’t necessarily bad. I watched this
video in geometry class in high school, showing fractals and visual
systems in nature itself. I felt weirdly empowered.
We, as the people, create systems everyday, when we build routines,
use digital and physical products to optimize our life. If these
products begin to take into account the user more from a point of
empathy, then not only will the users lives be improved, but also
make for more efficient infrastructure in the companies building
these products.
I released the PDF as the current public version,
free for anyone to read and use. I’m now translating that framework
into the /slop-audit Claude skill, so the same rules can run
directly inside an agent workflow.
I check design for weak logic, missing states, and decisions with
nothing behind them.
I check copy for claims that sound certain but carry no source.
I designed it to return structured findings with evidence, severity
and a clear fix, instead of vague critique.
Current, publicI’ve released the PDF: the rules, the
checklists and worked examples.↓In developmentI’m building the
/slop-audit skill from that PDF.
