When expert review depended on workarounds
Designing for expert decisions under uncertainty.
NIOSH Industry and Occupation Computerized Coding System
Industry and occupation descriptions are often collected through surveys and medical records. NIOCCS helps convert those free-text responses into standardized numeric codes researchers can analyze. The workflow includes file upload, autocoding, coder review, QA review, and export of finalized coded data.
The goal was to reduce manual coding without removing human judgment. NIOCCS used machine learning to learn from existing data and expert corrections, turning human review into feedback for future coding decisions.
NIOCCS had grown through new functions and upgrades, but the interface still reflected backend logic more than user workflows.
Coders, QA reviewers, and administrators needed different workflows - and even within coding, beginners and experts needed different levels of guidance, context, and control.
NIOCCS was not simply hard to use. It exposed fragmented workflows, unclear states, and competing signals without enough decision support.
Review Ambiguity
Users lacked a clear way to know what needed attention first.
Conflicting Signals
The system showed too many cues without explaining what mattered or what to trust.
Weak Recovery
Errors, edits, and bulk actions lacked safe rollback, forcing users into workarounds.
The interface exposed too many competing signals at once, but did not explain which ones mattered, which ones conflicted, or how much trust users should place in them.
Reviewers were not just reading information. They were making judgment calls under uncertainty while the system kept adding more unprioritized cues to interpret.
The Insight
User interviews and workflow analysis showed that the problem was deeper than interface clutter. Users were compensating for missing product logic with memory, personal judgment, and workarounds.
The issue was not lack of data - it was lack of prioritization, explanation, and decision support.
The system showed users signals.
It did not help them make decisions.
My Role
I led UX and product thinking for the redesign effort, identifying workflow failures, trust issues, and usability breakdowns across the system while working within significant technical and organizational constraints.
Product Strategy Support
Helped focus the redesign on the workflow problems that mattered most.
Product Experience Architect
Defined how the system should support real user decisions.
Product Roadmap Support
Helped shape the Phase 2 roadmap around decision support, uncertainty, and workflow improvement.
Cross-Functional Facilitator
Helped align stakeholders and the team around feasible improvements.
Design Lead
Led UX/UI design across file management, review, and coding screens.
UX Researcher
Led user interviews and usability testing to shape the redesign.
Me
UX Designer
Project Manager
Strategy & Product
Developer
Engineering
Technical Constraints
The system had existing logic and workflows that could not be fully replaced immediately.
Backend-First Mindset
Decision-making often centered on implementation logic rather than user workflows.
Build-First Culture
The system evolved through implementation decisions more than user or product thinking.
The Direction
The redesign separated the work into two levels: stabilize the existing workflow first, then define a future model for decision support.
Phase 1
Make System Status Visible
Show what's in progress, returned, in QA, completed, or ready for review.
Make Work Recoverable
Turn errors, edits, and bulk actions into safe correction paths.
Reduce Repetitive Effort
Support faster review through clearer file states, resume actions, and bulk editing.
Phase 2
Surface Uncertainty Across Records
Show where records are conflicted, low-confidence, or repeatedly changed.
Separate Overview from Execution
Use View All for prioritization and CAS for focused record-level decisions.
Create a Program-Wide Learning Loop
Turn expert corrections into patterns that expose recurring engine mistakes.
A preview of key improvements
The old main page hid file status in a dated, passive table - nothing flagged what needed attention or where to resume.
The redesigned dashboard puts status front and center with one clear resume action, so coders continue right where they left off.
The original Computer Assisted Screen (a single record) showed every code, score, and candidate at once - a wall of competing signals with no hierarchy to interpret.
The redesign reorganizes around the decision itself: a clear working selection, ranked pairs with confidence, and signals you can actually read.
Prototype Preview
Before breaking down the research and design decisions, here is the redesigned workflow at a glance: a more visible, recoverable, and decision-aware system for reviewing coded records.
Placeholder
Prototype preview placeholder - interactive demo or short walkthrough video
A glanceable view of the redesigned record-review workflow.
Understanding the Users
I interviewed coders and QA reviewers to understand how they reviewed records, handled uncertainty, reported problems, and discussed recurring issues with management. Across interviews, I focused on understanding of their daily review flow:
Research Focus
Research showed NIOCCS served multiple user groups through one undifferentiated experience. Needs varied across roles - and within coding, across experience - but the system offered the same path to everyone.
A newer coder needs the system to explain what matters, what to trust, and how to move forward safely.
Needs
Challenges
An advanced coder needs speed and control, but still depends on reliable signals to maintain confidence and momentum.
Needs
Challenges
A QA or Admin needs to verify coder work efficiently, maintain consistency, and identify recurring issues before they affect more records.
Needs
Challenges
User interviews and workflow analysis showed that the problem was deeper than interface clutter. Users were compensating for missing product logic with memory, personal judgment, and workarounds. Across that research, the recurring themes kept surfacing:
Workflows Were Personal, Not Shared
Users built their own review routines because the system never provided one.
Experience Changed Behavior
Experienced users leaned on memory; newer users trusted unexplained output.
Screens Had Unclear Roles
CAS and View All served different purposes, but the product never unified them.
Trust in the System Was Inconsistent
Users worked around the system because its signals weren't clear or prioritized.
In response to the research findings, stakeholder input, and project constraints, the following principles guided the redesign.
Make system state visible
Reduce memory burden
Support safe correction
Prioritize uncertainty
Separate overview from execution
Explain signals, don’t just display them
Low Fidelity
The redesign started in low fidelity to solve the workflow structure before moving into high-fidelity design. The goal was to separate the experience into clearer layers: resuming file work, reviewing one record in CAS, and correcting records across the full file.
The old main page treated files as rows in a table, with status and actions scattered across the screen. The low-fidelity direction reframed the entry point around continuity: what file is open, how much work remains, and where the coder should go next.
The old CAS made coders interpret too much at once - codes, scores, pairs, candidates, and history all competing for attention. In low fidelity, I reorganized it around the coding decision itself.
The old View All blurred filtering, editing, selecting, and reviewing into one passive table. In low fidelity, I explored turning it into a file-level correction space - scan, select, and bulk-correct with more control.
Usability Testing
Validation in this project was driven through iterative user feedback, internal walkthroughs, and screen-level usability analysis rather than formal controlled testing.
Still open after Phase 1
High Fidelity · Phase 1
Phase 1 stabilizes the coder's daily workflow - finding files, resuming work, reviewing records, and correcting codes - making it clearer, safer, and faster without added complexity.
My Files
The My Files screen becomes the coder's operational starting point - showing active work, file status, review progress, and a clear next action, so coders can resume without reconstructing where they left off.
With a file in progress, My Files shows where the coder left off and the next action, so they resume without reorienting.
Files that need attention are surfaced up front, so nothing waiting on the coder slips out of view.
The empty state points a coder to start or open a file rather than leaving them on a blank screen.
CAS · Record Review
CAS (Computer Assisted Selection) was redesigned from a crowded review screen into a structured decision space - separating the autocoded result, suggested alternatives, and signal explanations so coders can compare options, resolve conflicts, and review records without losing context. It works for experienced and new coders alike - deeper signals on hand, without overwhelming anyone.
CAS leads with the suggested pair and marks what is currently applied, so coders compare against a clear baseline.
Alternative candidates sit beside the applied code, turning a single guess into a side-by-side comparison.
Signal explanations say why a result is suggested or conflicted - replacing unexplained cues with reasons coders can act on.
View All · File-Level Review
View All was redesigned from a passive table into a file-level review and correction space. Coders can scan every record, filter to the records that need attention, and apply safe bulk corrections when the same issue appears across multiple records.
All records sit in one scannable view, giving coders the whole file at a glance instead of a record at a time.
A Needs Review filter narrows the file to the records that still require attention, so effort goes where it matters.
When one issue repeats across records, a safe bulk correction fixes them together - with the controls to review before applying.
High Fidelity · Phase 2
Phase 2 shifts from coder execution to QA analysis. The goal is no longer helping one coder move faster - the system now helps QA reviewers see where uncertainty, inconsistency, and recurring coding problems appear across a single file and the entire program.
QA File Analysis
QA File Analysis highlights quality risks that are difficult to detect from the table alone. It shows the overall QA state of one file, then lets reviewers select findings - such as inconsistent coding or uncertainty hotspots - to filter the records behind them.
The overview states the file's overall QA health and lists the findings worth investigating, instead of leaving reviewers to read every row.
Selecting a finding surfaces similar records that were coded differently - making inconsistency visible at the file level.
Uncertainty hotspots concentrate the low-confidence records, pointing reviewers straight to where judgment is most needed.
Program Analysis
Program Analysis extends the same signal model across files, time, and teams. QA can start from a program-level view, select a signal such as Conflict Override, see where it concentrates across files, and open the scoped record grid behind that issue.
The program overview lifts the same signals above a single file, showing quality patterns across the whole program.
Choosing a signal shows where it concentrates across files, turning a vague concern into a located pattern.
Opening a pattern drops QA straight into the scoped records behind it - so a program-wide signal becomes specific, reviewable work.
Outcome
The low-fidelity was tested with the coders and reviewers who’d use it, and that feedback drove the high-fidelity shown here. My contract ended while the high-fidelity was still in progress - so the team’s takeaway was a set of validated design recommendations, and what you see stands as the direction that work was heading toward, not a shipped product.