Examiner Portal

Certification-grade supervision work, and no design practice 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 a program that had screens, a backlog, and no design practice. The most useful thing I did in the first months was not a redesign. It was a series of brown-bag sessions that taught the client’s own team enough UX to dissect their application themselves.

What that produced, a shared vocabulary and a shared list of flaws, made everything after it possible. Five role journeys were mapped end to end across 27 stages. Seven of those stages scored negative. When I sorted the seven by what had actually gone wrong, they fell into two groups with nothing left over, and neither group was about a screen.

That reframed the project. The interface was not the problem. The seams between systems were.

How the work moved, and what each phase produced.

Each phase produced an artifact the next one depended on.

What happened Output

1. 01

   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. 02

   Brown-bag sessions

   Ran recurring working sessions for a client team that had never had a designer on the program. Taught the fundamentals: heuristics, cognitive load, error cost, accessibility. Then used their own application as the worked example and dissected it together, in the room, with them.

   Shared flaw taxonomy and a shared vocabulary

3. 03

   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. 04

   Architecture and IA

   Eight top-level destinations mapped onto the underlying record model, so navigation described the domain rather than the filing system. Branches the team had not settled were left marked unresolved instead of being given labels that implied a decision.

   Sitemap and record model

5. 05

   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 against what Appian can actually render, and stated as a decision rather than an appearance.

   ExPo Design Guide v1.0

6. 06

   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 sessions did not stop after phase two. Every significant decision went back through the same forum, so the client could evaluate it against principles they now knew rather than approve it 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.

The starting problem was not the interface.

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 never had a designer. The team was capable and knew the supervision domain far better than I ever would, and they had no vocabulary for what was wrong with the product. Requests arrived as solutions, make this page customizable, add a widget here, because 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.

So I built the axis first.

A flaw a stakeholder finds is a flaw they will fund.

I ran recurring working sessions with the client team. One principle per session, twenty minutes, explained plainly with examples from products everyone already used. Then their live product on screen, and the principle just taught held up against it. I asked questions and they did the finding.

Teaching the principle, then finding it broken in their own product.

Each session paired a UX fundamental with a live example from ExPo. The client did the finding.

Session format

1. 01

   Teach the principle

   Twenty minutes on one idea: error cost, cognitive load, recognition over recall, context persistence, accessible contrast.

2. 02

   Open their application

   No prepared critique deck. The live product on screen, and the principle just taught held up against it.

3. 03

   Let them find it

   The client spotted the violations. A flaw a stakeholder discovers is a flaw they will fund; a flaw a designer reports is an opinion.

4. 04

   Write it down

   Every finding named, categorized, and added to a shared list that fed the backlog.

What the sessions surfaced

Six categories of flaw, all of them 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 the way the product was actually used.

  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

Why this mattered more than the findings themselves

None of these six is a visual problem, and none would have surfaced from a screen review. They came out of a room where the client had just been handed the vocabulary to name what was wrong with their own product.

None of those six would have come out of me reviewing screens alone. They came out of a room where the client had just been handed the vocabulary to name what was wrong with their own product, and where the person who found each flaw 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.

Twenty-seven stages, scored one at a time.

The sessions told me what was broken. They did not tell me how the work actually 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 actually moves 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.

Twenty-seven stages across five roles. Seven broke.

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

Eddie Examiner

1. Gather & analyze , Working
2. Create activity , Working
3. Manage ISU , Breaking down
4. View schedule , Working
5. Execute activities , Neutral
6. View strategy , Neutral

Oscar Office manager

1. Gather & analyze , Working
2. Manage strategy , Working
3. Manage ISU , Breaking down
4. Manage schedule , Neutral
5. Manage activities , Working
6. Performance & HR , Breaking down

Amanda Business admin

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

Nicki Supervision expert

1. Reporting & analytics , Breaking down
2. Supervisory guidance , Neutral
3. Create strategies , Working
4. Support supervision , Neutral
5. QA / QC , Neutral

Adam Admin support

1. Administrative support , Breaking down
2. Managerial support , Breaking down
3. System support , Neutral
4. Supervision support , Working

• Working · 10
• Neutral · 10
• Breaking down · 7

The distribution is the finding

Seven of twenty-seven stages scored negative, 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.

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.

Two groups, and no remainder.

Then I sorted the seven by what had gone wrong rather than by who reported it. Four were the same work done more than once because the systems holding it were separate. Three were a question that required looking across records, asked by someone the product could only answer one record at a time.

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 of seven low points

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 of seven low points

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.

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.

Match the integration pattern to the interaction.

Connectivity usually gets argued as build-or-link, and that framing loses because the right answer changes per connection. What matters is what the user has to see, decide, or change at that moment, and what that costs to support.

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.

Five integration patterns compared by effort, data behavior, and when to choose them

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 this settled

Calendar integration could not embed directly for security reasons, so a calendar-file route was considered instead rather than the requirement being dropped. And reporting links were designed to carry office and portfolio parameters, so a user arrives already in the right context instead of re-selecting it on the other side.

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.

Give navigation the shape of the domain.

Eight destinations, and one branch left visibly open.

Navigation describes the domain rather than the filing system. Role and record security then determine what each user sees inside it.

Global definitions

• OSU

  Agency-wide ratings, risk categories, and the supervision hierarchy

Context

• ISU

  Institution and consolidated-company context

• Profiles

  Institution, company, office, and user records

Lifecycle work

• Strategy

  Planning by institution and by company

• Resourcing

  Object and action model not resolved.

  Left open

• Execution

  Violations, matters requiring attention, enforcement actions

Entry and output

• Home

  Role-aware entry point

• Reports

  Reporting destination

• Why the open branch stays 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.

• Institution types are filters, not destinations

  Otherwise the module list grows to mirror the entire domain taxonomy, and the navigation becomes a second filing system users have to learn.

• The product name was shortened to ExPo

  Appian moves top navigation to the side once tabs exceed the available width. A shorter product name bought back capacity: a naming decision forced by a platform constraint.

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 is written against what Appian can actually render.

• One visually dominant primary action per page, for the decision that advances the workflow
• Cancel, Back, and Previous on the left; Save, Continue, and Submit on the right
• Destructive styling reserved for genuine data-loss actions, paired with action-specific confirmation language rather than a generic “Are you sure?”
• 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

The palette was audited against both white and black. Several documented colors pass for normal text against one and fail against the other, which is exactly the sort of thing that has to be written down rather than left to per-screen judgment.

Learn the platform.

Workflow questions were crossing the design-to-engineering handoff and coming back days later, because I could not read what the platform actually did. 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.

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.

Three things.

• 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.