Parminder Sandhu Contact
All work

Case study 03 OCC / Department of the Treasury

Examiner Portal

A journey analysis that moved the problem from screens to seams.

Client
Office of the Comptroller of the Currency
Role
Senior UI/UX Designer
Platform
Appian · Certified Lead Developer, April 2025
Team
Product, engineering, data, and supervision experts
27 journey stages mapped across five roles
7 of those stages scored breaking down
None of the seven was an interface problem

Overview

Certification-grade supervision work, and no design system behind it.

The Examiner Portal is where OCC bank examiners plan and carry out supervision work: strategy, scoping, scheduling, resource assignment, approvals, and audit-ready history. It was built on Appian, and it was consolidating behavior that had lived in separate legacy applications.

I joined in January 2025. The program had screens, a backlog, five personas, and a short framework playbook from an earlier phase. It did not have a design system, journey research, or a shared way to name what was wrong. The most useful thing I did in the first months was not a redesign. It was a two-day workshop that taught the client’s own team enough UX to dissect their application themselves, followed by five journey maps that showed where the product broke.

What that produced, a shared vocabulary and a scored set of journeys, made everything after it possible. Five role journeys were mapped end to end across 27 stages. Seven of those stages scored breaking down. When I sorted the seven by what had gone wrong, they fell into two groups with nothing left over, and neither group was about a screen. The failures lived in the seams between systems, and the project changed shape around that finding.

A note on what is shown

The production interface is internal OCC material and is not reproduced here. The journey structure, the analysis, and the design standards are redrawn. The persona names are the project’s own research personas, not employees.

How the work moved, and what each phase produced.

Each phase produced an artifact the next one depended on.

  1. Standards audit

    Read what already governed the work before proposing anything new: OCC’s Appian Center of Excellence standards, an earlier agency Appian design guide, and the patterns already in ExPo. The point was to find out which constraints were real and which were habit.

    Inherited-constraint inventory

  2. Client workshop

    A two-day UI/UX workshop with the client team in July 2025: personas and goals, Execution workflows, sitemap review, page types, wireframing, component standards, and accessibility. Sitemap and wireframe fundamentals were taught in the room first, then applied by the team to their own product.

    Validated sitemap, wireframes, standards decisions, prioritized gap list

  3. Personas and journeys

    Five roles traced end to end with supervision subject-matter experts, deliberately starting before login: how work arrives, who owns it, where the result appears. Twenty-seven stages recorded with actions, thoughts, touchpoints, pages, feelings, and the specific gap at each.

    Five journey maps and the friction analysis

  4. Architecture and IA

    The as-built navigation drawn as one sitemap for the workshop: eight destinations, Institution and Office branches mirrored across Execution, Strategy repeating Institution across two separate tracks, and two destinations labeled not yet built rather than removed from the navigation.

    Sitemap, July 2025

  5. Design system

    Identity, palette, type hierarchy, an eight-point spacing rhythm, and component behavior for buttons, alerts, forms, cards, navigation, and tables. Every rule written within Appian’s capabilities, and stated as a decision rather than an appearance.

    ExPo Design Guide v1.0

  6. Specify and verify

    User stories and acceptance criteria per feature, covering defaults, conditional fields, validation timing, destructive actions, and pending states. Design QA against responsive behavior, keyboard order, realistic zoom, and empty and error states. Then UAT.

    Implementation-ready specifications

Two things ran continuously, not in sequence

  • Client education

    The two days set the vocabulary. Shorter recurring sessions carried it forward: decisions went to the standing program meetings with product, engineering, data, and supervision experts, where the client could now evaluate them against principles rather than approve them on trust.

  • Platform fluency

    Appian Lead Developer certification, taken mid-project, because workflow questions were crossing the design-to-engineering handoff and returning days later instead of being settled in conversation.

Phases 01 to 06 are each evidenced in a project document. What happened inside the workshop sessions is the designer’s own account.

The problem

Fragmentation was the starting problem.

ExPo had a real fragmentation problem. Modules shared concepts without sharing rules. An activity could be created in one place and surfaced in another with different editing permissions. Institution search and office search behaved differently because of platform mechanics. Reference values could expire after work had already been scoped against them.

Each of those is a design decision and a data decision at the same time. Fixed screen by screen, they multiply.

But there was a problem underneath that one. The program had had design work before me: personas, landing-page concepts, a short framework playbook. It had not had a design system or journey research, and a year of recorded feedback shows requests arriving as solutions: move the KPIs to the top, remove the hover, make the headers darker. A solution was the only form a request could take.

If I had responded by producing designs, I would have been a service the team submitted tickets to. Every proposal would have been evaluated on whether people liked how it looked, because that was the only axis available. Before designing screens, I built an axis the team could use to evaluate them.

CLIENT WORKSHOP

Two days that gave the client the vocabulary.

I ran a two-day UI/UX workshop with the client team in July 2025. Day one moved from users to structure: personas and goals, the Execution workflows, the sitemap, page types. Day two moved from structure to standards: wireframes for the key journeys, component standards, accessibility, and a prioritized list of what was wrong. Fundamentals were taught first, in plain terms, and then the team applied them to their own product with the live application on screen.

Two days that gave the client the vocabulary.

Fundamentals taught in the room, then applied to ExPo by the team that owned it.

Session format

  1. Ground

    Personas, business goals, and Appian's constraints, so every later decision had something to be evaluated against.

  2. Structure

    The as-is sitemap reviewed against alternatives; page types and layout patterns agreed.

  3. Sketch

    Wireframes for the key journeys, drawn collaboratively rather than presented.

  4. Standardize

    Component standards, accessibility requirements, and the gap list sorted into backlog items.

What the sessions surfaced

Six categories of flaw, sorted as structural.

  • Context was ambiguous

    Every tailoring action applies to whichever institution or company is selected, but the context bar was easy to miss. A new observer in the session could not tell which scope an action would land in.

    Principle taught Recognition over recall

  • Two words for two things, used as one

    An activity is agency-level supervisory work. A task is one person’s responsibility inside it. The interface used the words interchangeably, so ownership, notification, and completion were all ambiguous.

    Principle taught Consistency and standards

  • Work arrived from outside the product

    Assignments reached examiners by email or through a manager. Nothing in the portal knew that had happened, so the dashboard could not be the place work started.

    Principle taught Visibility of system status

  • Density collided with zoom

    Examiners work dense hierarchies at high display scaling on laptops. Layouts that resolved at 100% on a large monitor did not survive real use conditions.

    Principle taught Accessibility, and honest constraints

  • Reference data changed underneath work

    A policy value could expire after an activity had already been scoped against it. The system’s options were to silently rewrite the work or to say nothing, and both are wrong.

    Principle taught Error prevention

  • Personas were standing in for permissions

    Five research personas were being treated as if they were the security model. They are not: the platform enforces many granular roles, and a design built on the personas alone could not be implemented.

    Principle taught Match between model and reality

Where the six came from

Three were on the program’s record from 2024 and still open when I arrived: the activity and task words, personas standing in for permissions, and layouts failing on laptops. One came out of my own screen audit: the context bar. One came out of the journey sessions: work arriving by email and through managers, with nothing in the portal aware of it. One came out of the June 2025 design meetings: reference data expiring under work already scoped against it. The workshop did not discover them. It sorted them as structural rather than visual and put the list in the client’s hands.

Sources: the 2024 backlog refinement notes, the ExPo usability gap audit, the five persona journey maps, and the June 2025 design meeting records.

That mattered because the person who agreed each flaw was structural was the person with the authority to prioritize fixing it. It also changed how every later decision was received. Once a stakeholder knows what error cost means, a confirmation step is not friction you are adding to their form. It is a control they understand the purpose of.

Research

Twenty-seven stages, scored one at a time.

The sessions told me what was broken. They did not show how work flowed, and the flaw about work arriving from outside the product made it clear that the flow was where the answer lived.

Five personas were already established from earlier project work: an examiner, an office manager, a business administrator, an administrative support user, and a non-direct supervision expert. What did not exist was an account of how each one moved through a week. I ran journey sessions with supervision subject-matter experts and traced all five end to end, deliberately starting before login: how does work reach this person, who owns it once it exists, where does the result appear next.

Five roles, only two of them named.

Examiner and non-direct supervision expert came with a paragraph of context. The other three had a title and a task list.

Before the names became rows in a matrix, I built one empathy map per role: what each person says, thinks, does, and feels day to day, not just what they click. Eddie is worth reading in full. Manage ISU is the one stage two different people scored as breaking down independently, and he's the role that stage belongs to.

Select a role to read the full empathy-map synthesis.

Empathy map

Eddie Examiner

Frontline examiner · Institution-focused execution

Complete examination work accurately while staying oriented to scope, assignments, institutions, and deadlines.

01 / 05
  • Task-first
  • Institution context
  • High accountability
Evidence-backed design synthesis
"Says" statements are not verbatim quotes.

Says

Synthesized statements—not direct quotes

  • “Show me what requires my attention now.”
  • “Keep the institution, scope, and due dates visible.”
  • “Do not make me hunt across systems for files and activity details.”

Thinks

Questions and judgments shaping decisions

  • Are the PSPs, ratings, risk information, and activity attributes still valid?
  • Did a strategy or reference-data change affect work already in progress?
  • Can I trust the status, assignment, and audit history I am seeing?

Does

Primary behaviors within the work

  • Opens assigned tasks, current activities, upcoming work, and recent files.
  • Switches institution context; scopes work and tailors PSP levels 2–5.
  • Collects data, reviews ratings and RAS, records conclusions, and flags issues.

Feels

Emotional conditions created by the workflow

  • Responsible for producing accurate, defensible examination work.
  • Pressed for time when tasks, files, and context are distributed across tools.
  • More confident when status, validations, and next steps are explicit.

Primary frictions

  • Fragmented legacy behavior
  • Context switching
  • Unclear task relationships

Design implications

  • Persistent institution context
  • Direct task-to-activity paths
  • Actionable validation guidance

Demographics, goals, and technology-fluency ratings for four of these five are the project's existing persona sheets. The empathy-map synthesis itself, the says, thinks, does, and feels breakdown, the friction list, and the design-implication tags, is built from the journey sessions, meeting notes, and those personas together. "Says" lines are synthesized, not verbatim, as each map states.

Twenty-seven stages across five roles. Seven broke.

Sentiment recorded per stage with subject-matter experts. Lower is worse.

Eddie Examiner

  1. Gather & analyze
  2. Create activity
  3. Manage ISU
  4. View schedule
  5. Execute activities
  6. View strategy

Oscar Office manager

  1. Gather & analyze
  2. Manage strategy
  3. Manage ISU
  4. Manage schedule
  5. Manage activities
  6. Performance & HR

Amanda Business admin

  1. User roles & access
  2. Audit logs
  3. Reference data
  4. Admin support
  5. Visibility & security
  6. Training

Nicki Supervision expert

  1. Reporting & analytics
  2. Supervisory guidance
  3. Create strategies
  4. Support supervision
  5. QA / QC

Adam Admin support

  1. Administrative support
  2. Managerial support
  3. System support
  4. Supervision support
  • Working · 10
  • Neutral · 10
  • Breaking down · 7

The distribution is the finding

Seven of twenty-seven stages scored breaking down, and they do not fall where the interface is weakest. Two roles hit the same stage, Manage ISU. One role, admin support, is negative for half its journey. This is what made the next analysis possible: scattered complaints became a shape.

Source: the project’s five persona journey maps. Sentiment is subject-matter-expert judgment recorded during journey sessions, not instrumented telemetry.

Eddie Examiner · Journey map

One examiner's week, traced stage by stage. (Eddie's row, expanded)

Eddie's row from the matrix above, expanded. Same six stages, same scoring, with the thought and the gap that sat behind each color before it was compressed into a cell.

  1. 01

    Gather & analyze

    Working

    “Am I missing any risks or reports we’ve seen before?”

    Gap

    Needs automated suggestions and dynamic triggers for activity creation.

  2. 02

    Create activity

    Neutral

    “Why isn’t this PSP scoping like I expected?”

    Gap

    Lacks dynamic tools for creating activities from recent trends or changes.

  3. 03

    Manage ISU

    Breaking down

    “What changed that I need to account for here?”

    Gap

    No way to aggregate conclusions across activities. ISU tailoring is labor-intensive.

  4. 04

    View schedule

    Working

    “Where am I next, and who else is on that assignment?”

    Gap

    Manual schedule management, little automation, no aggregation across feeds.

  5. 05

    Execute activities

    Working

    “Did I already upload this file, or do I need to?”

    Gap

    Significant manual effort cross-checking against system data and reporting.

  6. 06

    View strategy

    Neutral

    “How does my work fit into the bigger strategy?”

    Gap

    Strategy and execution aren’t linked. No feedback loop back into future strategy.

Recording sentiment per stage was the decision that made the analysis possible. Individually, every gap in those journeys reads as a reasonable complaint. Scored and laid out together, they stop being complaints and become a distribution.

The finding

Two groups, and no remainder.

Then I sorted the seven by what had gone wrong rather than by who reported it. They fell into two groups with nothing left over.

All seven low points sorted. Nothing left over.

Sorting by what went wrong rather than by who reported it produced two groups and no remainder.

Repeated across systems

4

The same work done more than once because the systems holding it were separate. Every repetition is another chance for two records to disagree.

  • Access changes made by hand in several places Amanda · user roles and access
  • Document and facility tasks spanning multiple systems with no standard process Adam · administrative support
  • Support work done differently in every office Adam · managerial support
  • Performance and development data scattered across unintegrated systems Oscar · performance and HR

Could not be aggregated

3

A question that required looking across records, asked by someone the product could only answer one record at a time.

  • No way to aggregate conclusions across multiple activities Eddie · manage ISU
  • Supervision content hard to roll up across exams Oscar · manage ISU
  • Reporting siloed and duplicative, with no cross-institutional view Nicki · reporting and analytics

None of the seven was a screen.

Not one low point was a person struggling with a layout, a label, or a control. Four were the same work repeated because two systems did not talk. Three were a question the product could not answer because it could not roll data up. A better-looking dashboard would not have moved any of them.

What this changed

The project had been scoped as an interface consolidation. This analysis said the highest-value work was deciding, per connection, how two systems should meet, which is an integration question and a program-scope question.

Gap text is quoted in condensed form from the gap row of each persona journey map.

That is an uncomfortable finding to deliver on a program scoped as an interface consolidation, and it is much easier to deliver to a room that has spent months learning to think this way. The brown bags paid for themselves here. I was not telling a client their project was aimed at the wrong thing. I was showing a client the conclusion of an analysis they already understood how to read.

The design response

Match the integration pattern to the interaction.

What matters is what the user has to see, decide, or change at that moment, and what that costs to support. The framing that usually wins the argument, build or link, loses because the right answer changes per connection.

Five ways to connect a system, and a rule for choosing.

Connectivity is usually argued as build-or-link. The right choice changes per connection.

Pattern Effort What the data does Choose it when
System link Low No preview inside the portal Navigation is enough and the user can finish the job in the source system. The cheapest honest answer, and often the right one.
Inline display Low Real-time view, no writing back External content needs to be read in place. A poor default between two Appian systems, where it becomes a read-only dead end.
Data fabric High Integrated, not always real-time The portal needs governed access and a purpose-built interface over the data, and the latency is acceptable for the decision being made.
Web API High Depends on the source contract Real-time exchange is genuinely required and the source system supports it well enough to depend on.
Migrate in Long-term Native once complete The value of consolidating onto one platform exceeds migration and ongoing ownership cost. A program decision, not a design one.

Two decisions already on record show the rule

Both were taken in June 2024, before I joined. Calendar integration could not embed directly for security reasons, so a calendar-file route was kept instead of dropping the requirement. Reporting links were designed to carry office and portfolio parameters, so a user arrives in the right context instead of re-selecting it. Each is the cheapest pattern that still supports the interaction.

Integration options, effort, and data behavior as documented in the program’s 2024 UI/UX Framework Playbook, which predates my involvement. Applying them as a rule per interaction is the design contribution here.

A link adds a context switch but preserves the source system. Inline display removes the switch but can become a read-only dead end. Data fabric supports a coherent interface but adds latency and modeling cost. APIs can make a workflow seamless but require contracts you can depend on. Migration removes fragmentation and changes program scope.

Architecture

Give navigation the shape of the domain.

Examiner Portal · Sitemap, July 2025

One navigation row. Four infrastructure views.

Redrawn from the sitemap prepared for the July 2025 UI/UX workshop. The top row shows the product’s full navigation; the panels below show the records, work, strategy, and support structures inside it.

  1. Home Main navigation hub
  2. Profiles Manage institutions, offices, and users
  3. Execution Track and manage activities
  4. Scheduling Planned
  5. Strategy Review, adjust, and track strategy
  6. ISU Institution supervision universe
  7. Reports Access and manage reports
  8. Admin Planned
Inside the navigation

Site infrastructure

Eight destinations, two marked planned.

Home & records

Daily navigation, institutions, offices, and users

Home

Main navigation hub

  • My Tasks
  • Notifications
  • My Activities
  • My Calendar
  • Quick Links
  • My Institution / Office / CC
  • Recent Files
  • KPI
Profiles

Manage institutions, offices, and users

Institution
  • Data Collections
  • Licensing Filings
  • Supervision Filings
  • Complaints
  • MRA
  • Violations
  • Enforcement Actions
    • Individual
    • Bank
Office
  • DMRM
  • Conclusions
Consolidated Company
User
OSU

Planning & strategy

Coordinate examinations and review change

Scheduling

Plan and coordinate examinations

Planned

This section is planned for a future release.

Strategy

Review, adjust, and track strategy

Institution
  • All Activities
  • Review / Feedback
  • Strategy Change
  • Audit History
Institution
  • All Activities
  • Review / Feedback
  • Strategy Change
  • Audit History

Execution & supervision

Activities and the institution supervision universe

Execution

Track and manage activities

Institution
  • Activities
    • Conclusions
    • Ratings and RAS
    • Data Collection
    • DMRM
    • MRA
    • Violations
    • Enforcement Actions
      • Individual
      • Bank
Office
  • Activities
    • DMRM
    • Conclusions
ISU

Institution supervision universe

ISU View
Flags
Search
Audit History

Reporting & administration

Reports, system administration, and access

Reports

Access and manage reports

All Reports
Admin

System administration

Planned

This section is planned for a future release.

Acronyms
ISU
Institution Supervision Universe
OSU
OCC-wide Supervision Universe
DMRM
Documents Management / Requirements Management
MRA
Matters Requiring Attention
RAS
Risk Assessment System
CC
Consolidated Company
Execution mirrors Institution and Office underneath. Strategy repeats Institution across two separate tracks, drawn identically in the source sitemap. Role and record security determine what each user sees inside either one.

  • Why the open branches stay visible

    A clean diagram that quietly invents structure for an unsettled area is worse than one that shows the gap, because the invented version gets built and then defended. Scheduling and Admin were in the navigation before the modules existed and were labeled that way.

  • Execution's shape repeats

    Institution and Office branch identically inside Execution, same four children under each. A user who learns one half has learned the other.

Design system

Written as decisions, not appearances.

A design guide that says what a button looks like is a style sheet. One that says which action gets primary emphasis, where destructive actions sit relative to safe ones, and what confirmation language they take is a decision record other people can apply without me in the room.

The ExPo Design Guide covers identity and clear-space rules, the palette with contrast behavior called out per color, a type hierarchy, an eight-point spacing rhythm, and component standards for buttons, alerts, forms, selection controls, cards, navigation, tables, and editable grids. Every rule stays within what Appian can render.

ExPo Design Guide · Typography and spacing

Nine text styles, measured.

Roboto, as Appian renders it. Each bracket spans the documented line height and the sample sits on its true baseline inside it, so the leading is drawn at actual size rather than described.

  1. H1 large plus 52 px, bold
    78

    Supervision strategy

  2. H1 large 30 px, bold
    60

    Institution in context

  3. H medium plus 26 px, bold
    39

    Activities and resources

  4. H medium 22 px, bold
    33

    Manage user roles and access

  5. H small 17 px, bold
    26

    Audit history

  6. H extra small 14 px, bold
    21

    Reference data

  7. P 14 px, regular
    21

    Body text sets at fourteen over twenty-one, the same size as a small heading.

  8. P bold 14 px, bold
    21

    Bold body carries labels and field names inside a form.

  9. Link 14 px, bold
    21

    Open the institution record

Spacing, at actual size

Every margin and padding value in the guide is a multiple of eight. The squares below are drawn at the pixel size they name.

  1. 8
  2. 16
  3. 24
  4. 32
  5. 40
  6. 48
  7. 56
  8. 64
  9. 72
  10. 80
  11. 88
  12. 96
ExPo Design Guide v1.0, April 2025: Typography, page 12, and Grid System, page 16. Sample wording is drawn from the portal’s own screens. Sizes, line heights and weights are the documented values.
  • One visually dominant primary action per page, for the decision that advances the workflow
  • Alerts carrying color, icon, and text together, so urgency never depends on color perception alone
  • Icon-only utility controls only where space requires them, always with an accessible name

Two conventions came from OCC's Center of Excellence standards rather than the guide, and were applied throughout: progressive actions on the right, and destructive actions paired with action-specific confirmation language instead of a generic "Are you sure?"

The palette was audited against both white and black before it went into the guide. Which colors are safe where is exactly the sort of thing that has to be written down rather than left to per-screen judgment.

ExPo Design Guide · Contrast

The same color, set on white and on black.

Every color in the ExPo palette, set as type at body size against both backgrounds. Ten of the thirteen are legible on one and fail WCAG AA on the other.

Holds on either background 3

4.5:1
4.6:1
Primary grey

#767676

4.7:1
4.5:1
Red

#D13F45

4.6:1
4.6:1
Green

#04865F

Light backgrounds only 5

6.3:1
3.3:1 fails
Primary blue 01

#005ACA

14.6:1
1.4:1 fails
Primary blue 02

#002855

5.0:1
4.2:1 fails
Secondary blue

#0072C6

21.0:1
1.0:1 fails
Black

#000000

9.4:1
2.2:1 fails
Dark grey

#464646

Dark backgrounds only 5

2.4:1 fails
8.8:1
Primary orange

#F68E32

1.6:1 fails
13.3:1
Secondary grey

#ECECEC

1.0:1 fails
21.0:1
White

#FFFFFF

1.5:1 fails
14.0:1
Yellow

#FFCD00

1.1:1 fails
19.9:1
Tertiary grey

#F9F9F9

ExPo Design Guide v1.0, April 2025, page 10. Ratios computed from documented hex values against the WCAG 2.1 threshold for normal text.

Learn the platform.

Workflow questions were crossing the design-to-engineering handoff and coming back days later, because I could not read the platform’s behavior. So I took the Appian Lead Developer certification mid-project. It changed the design work itself, not just the speed of it. Knowing that top navigation collapses at a certain width makes module count a design constraint rather than a surprise. Knowing custom CSS was not part of the delivery model means a pattern gets composed from native components from the start.

What came of it

A long-running program, reported precisely.

This is a long-running enterprise program, not a project with a launch date. Being precise about which parts were settled is more useful than a summary implying all of it was.

Settled

  • A client team fluent enough in UX to evaluate design decisions rather than approve them on trust, and a shared flaw taxonomy that fed the backlog
  • Five role journeys mapped end to end, with the friction analysis that reframed the problem from screens to seams
  • A governed design guide covering identity, palette, typography, spacing, and component behavior, written against Appian’s real capabilities
  • An integration decision framework tying each connection to the interaction it has to support
  • A sitemap with eight destinations, two of them labeled not yet built rather than hidden
  • Appian Lead Developer certification, which closed the design-to-engineering loop
  • User stories and acceptance criteria detailed enough to build from

Still moving

  • The single-institution activity creation path was implemented; consolidated-company creation remained in development
  • Scheduling and Admin appeared in the navigation before the modules behind them were built
  • Task assignment and handoff, the largest gap the journeys exposed, needed workflow changes beyond the interface
  • No usability testing or production analytics were instrumented, so no measured improvement can be claimed

On attribution

ExPo was delivered by a large team over several years. I joined in January 2025. Before that, the program had produced the five personas, landing-page concepts, a 2024 framework playbook including the integration matrix above, and the 2024 sitemap decision that fixed the site name as ExPo. Those are team assets I inherited. What is mine: the standards audit, the July 2025 workshop, the five journey maps and the friction analysis they produced, the two-group finding, the July 2025 sitemap with its open branches, the ExPo Design Guide v1.0 and its performance supplement, the usability gap audit, and the specifications and design QA that followed. Program outcomes belong to the program.

What I would do differently

Measure sooner, escalate the seams, name an owner.

  • I would have instrumented before the redesign, not after

    The journey analysis is good research and it is still self-reported. Seven specific stages were named as breaking down, which is exactly the list you would instrument: time from login to the correct task, wrong-context actions, how many systems a single task touches. Baselining those while the journeys were fresh would have cost very little. I wrote the measurement plan and did not push to run it.

  • I would have taken the seams argument further up

    The finding was that the worst problems were not solvable inside the product. Four of the seven needed systems to talk to each other; three needed data to roll up. I made that case to the product team, where it landed as design input. It was really an argument about program scope, and it needed to reach the people who set scope.

  • I would have named an owner for the design system sooner

    The guide went through more than one version, and for a period two different typefaces were specified across documents that were both in circulation. Nothing broke, but the ambiguity was real and avoidable. A design system needs a named owner, a version history, and one authoritative source from the first release.

Next case study

04 Health Resources and Services Administration (HRSA) HRSA Grant Application Redesign Fifteen forms due on the same day, with one Clinical Performance Measures flow redesigned from 90 screens to 18 pages. Read the case study