Advisor workflows at a national brokerage

Finding where financial advisors would get stuck in the prototypes, before the software was built

My role

Lead product designer

Employer: World Wide Technology
Client: A national brokerage
Year: 2019
Team: Three reviewers

Ran an expert review of the prototypes a national brokerage planned to give its financial advisors, before any software was built.
Checked two advisor workflows against ten usability heuristics, as one of three reviewers working separately, and rated every step for how hard it was.
Audited the firm's design system in seven areas, and aimed our fixes at it wherever we could.

44 places where advisors would get stuck, each rated for how bad it was
3 reviewers checking every screen on their own against the same ten rules
0 of 5 accessibility rules the design system had written down
7 areas of the design system checked against both prototypes

Summary

A national brokerage's design team had built clickable prototypes for two tasks its financial advisors would do every day: opening a client's account and reading financial statements. Before paying developers to build them, the firm wanted to know where advisors would get stuck, and how badly. Opinions wouldn't do. They wanted problems they could rank.

Three of us checked each screen on our own against the same ten rules of thumb, then combined our ratings. We found 44 places where advisors would get stuck, and a design system with most of its accessibility rules never written down. The software wasn't built yet, so there are no numbers from afterward.

Who was involved

Financial advisors The people the screens were for. None of them tried the prototypes in this review.
The firm's design team Built the prototypes in InVision after a series of brainstorming workshops.
Three reviewers UX consultants from World Wide Technology, with over 25 years of design work between us.

Executive Summary page in three columns. Overview: UX consultants from World Wide Technology independently evaluated the Account Opening and Financial Statements prototypes against Nielsen’s ten principles, added severity ratings, and documented 44 points of friction of varying severity, noting the evaluators are experts in UX and heuristics but not the intended users of the software. Findings: most issues fell in design consistency, error prevention and efficiency of use; both prototypes depend on disparate systems, present read-only information inside interactive components, and place alert dialogs away from what they refer to. Summary: a separate document details every issue, and all evaluations ran on a laptop against InVision prototypes built by the firm’s UX team. The report's executive summary, which I kept. Every limit listed here is in the report's own words, not a caveat I added later. — **The whole project on one page.** The report's one-page summary: 44 problems, and the limits it states in its own words.

Context

The prototypes were part of a larger program at the firm for onboarding and serving clients. They were clickable mock-ups made in InVision, so nobody had written code yet. The design team had worked out the two advisor workflows in brainstorming workshops.

The firm wanted more than a list of opinions. It wanted numbers it could rank the fixes by, and a starting score it could check again after making changes.

Research

The method is called a heuristic evaluation. It works like a home inspector walking through a house with a checklist. Ours was Jakob Nielsen's ten usability heuristics, well-known rules of thumb for easy-to-use software.

Each of us went through the prototypes alone. We rated every step on a three-point scale for how much thinking it asked of the advisor, and wrote down every rule it broke and how bad that was.

Assumption map

Research first

Each dot is one belief, placed by how much it mattered and how much we actually knew. The top right corner is where being wrong would hurt most and we knew least, so that is where the research went first.

Held up
Partly held
Didn't hold
Never tested

ID	Assumption	Certainty	Importance	Status
A1	Advisors would get stuck in the two prototypes in places the workshops had not caught.	Medium	Critical	ValidatedThe three reviewers found 44 places where advisors would get stuck, some small and some serious.
A2	Three reviewers checking each screen separately against the same ten usability heuristics would give ratings the firm could rank fixes by, not one person's taste.	High	High	Partially validatedEvery problem got a how-bad rating and the rule it broke, but the pages kept do not show the math that combined the three sets of scores.
A3	The firm's design system already had written rules for the areas the prototypes depended on.	Medium	High	Didn't holdOf six accessibility rules, only one was written down, so each product team was working out accessibility on its own.
A4	The prototypes showed enough of each advisor workflow to judge it.	Medium	Medium	Partially validatedThe report itself says the review could only check the tasks each prototype happened to show.
A5	UX experts who were not financial advisors could still judge where advisors would get stuck.	Medium	High	Not testedThe report notes the reviewers were not the intended users and no advisors tried the prototypes.
A6	Fixing a tricky interaction once in the design system would fix it in every product that uses it.	High	High	Not testedThe fixes were handed over before the software was built and there are no follow-up numbers.
A7	The audit's scores would give a baseline the firm could check again after making changes.	Medium	Medium	Not testedThere are no numbers from after the fixes were handed over, so the baseline was never rechecked.

Reference page setting out Jakob Nielsen’s ten usability heuristics in three columns; visibility of system status, match between system and the real world, user control and freedom, consistency and standards, error prevention, recognition rather than recall, flexibility and efficiency of use, aesthetic and minimalist design, help users recognize diagnose and recover from errors, and help and documentation, each with its full definition. From the evaluation report I kept. It's a published checklist, not a measurement; what it gave us is that three reviewers were looking for the same ten things. — **The checklist we all worked from.** Nielsen's ten usability heuristics, printed in the report in full, so every problem had to name the rule it broke.

Findings

We found 44 places where advisors would get stuck, some small and some serious. The same problems kept showing up: information you couldn't change sitting in boxes that looked like you could type in them, the main button looking no more important than the others, and warnings appearing far from what they warned about. The biggest single cause was that the workflows jumped between several separate systems behind the scenes.

Every problem came with how bad it was, the rule it broke, a marked-up picture of the screen, and a specific recommendation.

Findings page titled “Issues in Multiple Areas” for the Account Opening prototype: the screen at left, then three findings, each labeled NOTABLE with the heuristic it violates; “Select all” links not grouped with the checkboxes they control, secondary actions styled inconsistently as links or buttons, and “Apply” buttons that duplicate the “Save and Continue” primary action, beside annotated crops and a recommendation in italics. From the findings pages I kept. How bad each problem was is the judgment of three experts using a fixed scale, not a usability test with anybody using the prototype. — **Account Opening.** Three of the problems, each with how bad it is, the rule it breaks, and a specific recommendation.

Findings page titled “Issues in Multiple Areas” for the Financial Statements prototype: the screen at left, then four findings (two NOTABLE, two EASY), covering users likely to type into inputs before clicking “Edit Item”, an overflow menu placed against Material Design convention, Save and Cancel carrying equal visual weight, and Cancel styled inconsistently across modals, each beside an annotated crop and a recommendation. From the findings pages I kept. This page shows the second prototype's findings; the per-feature chart described above didn't survive. — **Financial Statements.** The same checklist on the second prototype, where Save looked no more important than Cancel.

Design system audit

Separately, we checked both prototypes against the firm's design system in seven areas: accessibility, color, grid, icons, typography, components and patterns. For each rule we asked one plain question: has anyone written it down?

Of five accessibility rules, none was. The only thing it had written down was a list of reference links. Page structure, keyboard use, text for screen readers, images and video, and color all came back no. So every product team was working out accessibility for itself. Where we could, we aimed our fixes at the design system: solve a tricky interaction once, and it's fixed everywhere.

UI Design System page in three columns. Overview: design systems bring order to chaos and the firm's designers and developers want stronger collaboration. Findings: several areas of the existing design system would benefit from clearly defined standards, listing accessibility, color, grid standards, iconography, typography and patterns. Summary: the evaluation compares the firm's design system standards against the two prototypes and records whether a specification exists, with a recommendation to specify anything missing. From the audit summary I kept. This page lists six of the areas; we checked components as well, which makes seven. — **Fix it once, fix it everywhere.** The audit summary, comparing the design system's written standards against the two prototypes.

Accessibility audit page: a table of guidelines against a SPECIFIED column (structure and hierarchy NO, keyboard navigation NO, screenreader text NO, images and video NO, colors NO, references YES), beside recommendations naming what each missing guideline should illustrate, from managing keyboard focus to complying with AA contrast ratios. The accessibility audit I kept. Whether a rule is written down or not is something anyone with the same design system can check; none of it rests on our judgment. — **Five of six never written down.** Only references was specified; the other five accessibility rules came back no.

Outcomes

The firm got its 44 problems, each rated for how bad it was, before any developer time was spent. That's where my part ended. The software hadn't been built, so I have no numbers from afterward, and the starting scores were never checked again.

The report is honest about its own limits too. We knew usability but weren't financial advisors, and we could only check the tasks each prototype happened to show.

A design system audit across seven areas, from accessibility to typography.
The same review on Financial Statements, where Save looked no more important than Cancel.