Priori Scout: Fixing the edit flow that fed search and matching, without leaving the modal
The legacy two-panel modal (left) and the tag-based edit flow that replaced it (right).
Context
The modal was the moment firms decided whether to trust the import
Priori Scout gives companies one place to manage their outside counsel. Law firms arrive through a data import: their lawyer roster lands as JSON, gets loaded into Scout, and then the firm takes a pass to make sure every profile is current. Practice areas and the proficiencies inside them are the most important fields on that profile, because they're what clients search and match on. A missing proficiency means a lawyer doesn't surface for a matter they're qualified for.
So this wasn't a settings screen. It was the step where firms either trusted the import or gave up on it. The taxonomy was wide and uneven: dozens of practice areas, each with its own proficiency list, and lawyers often needed to add a proficiency the list didn't have.
A lawyer's profile carries practice areas, each holding proficiencies. Client search and matter matching run on those chips, which is why a missing one costs the lawyer a matter.
The Problem
Two panels, two clicks, and a dozen tickets a month
The legacy modal split the job across two disconnected panels, categories on the left and proficiencies on the right, with nothing connecting them. Every proficiency wanted a Yes or No. Adding one took two steps ("Add," then "Yes") with no feedback in between. If the proficiency you needed wasn't listed, the only option was a free-text request at the bottom that filed a ticket instead of adding it.
Firms couldn't complete a basic edit without help. Support averaged about twelve tickets a month on this one modal and ended up making edits by hand. Sales reps left the feature out of demos.
The Constraint
Modal-first wasn't the obstacle. It was the brief
Scout was modal-first, and the design system backed that up: a modal shell, a dropdown, and a list component. Airbnb and DoorDash both handle this kind of editing on dedicated full-page screens. That was the easy answer, and it would have broken the product's consistency for one feature.
I kept the modal and treated it as the brief. The fix had to work inside the dialog the product already had, using components the team already shipped.
Airbnb and DoorDash move profile editing to full pages. Scout's system didn't have that pattern, and adding one for a single flow wasn't worth the inconsistency.
Iterations
Two layouts fixed the wrong thing before I questioned the checklist
Moved proficiencies beneath their category so the relationship was visible. Hierarchy solved, scrolling broken. A lawyer with several practice areas got a list that ran off the screen.
Borrowed Airbnb's view/edit switch, showed only selected items by default, and muted Save until something changed. We walked 12 lawyers through it on demo calls. The verdict was still "busy and overwhelming." The layout wasn't the problem. The checklist was.
Replaced checklists with a tag field per practice area. Selected proficiencies show as removable chips. Adding one is typeahead against the full list, with a browse option, and an "add your own" path for proficiencies the taxonomy didn't cover. The modal got shorter, the next step became obvious, and undoing a mistake became one click.
The Decision
Tags trade discoverability for clarity, and that's the right trade for a lawyer
A checklist shows every option; a tag field hides them until you type. For a lawyer reviewing their own profile that's the right trade: they know what they practice and don't need to scan forty checkboxes to find it. Typeahead plus browse covers the rare case where they want to look, and "add your own" covers the case where the list is wrong.
It also cost less to build. The typeahead and list components already existed, so tags composed parts the team had shipped instead of a new synced two-panel component. And each chip maps to a single add or remove against the record, so deleting one proficiency no longer meant resubmitting all of them.
| Checklist | Tags | |
|---|---|---|
| Discoverability | Every option visible | Visible on type or browse |
| Scan speed | Slow past ~15 options | Fast, only selections shown |
| Modal height | Grows with the taxonomy | Grows with selections |
| Build cost | New synced two-panel component | Existing typeahead and list |
| Remove action | Find and uncheck | One click on the chip |
| Missing option | Dead end | Add your own |
Typeahead plus browse covers the rare case where a lawyer wants to look; "add your own" covers the case where the list is wrong.
The Concession
A minimize button I didn't want, and why I let it go
The team wanted a prominent "minimize" button on the modal, on the grounds that lawyers needed a strong, obvious way out. I'd have kept it quieter; the modal already had a close, and the chips made the state self-explanatory. I took the loss. It was a small cost against a flow that was finally working, and not the hill.
What Shipped
One modal, one action per edit, a path for everything the taxonomy missed
Typeahead filters the list, a pick becomes a chip, one click removes it, and anything the taxonomy lacks goes in as your own. Recreated from the shipped build.
Outcome
Tickets to zero, and a pattern the rest of the product adopted
- The tag field became the standard pattern for every place lawyers edit list-type profile data in Scout.
- Support tickets on this modal: ~12/month to 0, two months after launch. Six months after launch, only two tickets related to editing profile data.
- Sales reps put the edit flow back in demos.
- Over six months, lawyers added over 100 custom proficiencies.
What I Learned
Ask about the component before the layout.
Question the component before the layout. I spent two iterations rearranging checklists before asking whether a checklist was the right control at all. The layouts weren't failing; the pattern was. Sometimes it is important to zoom out to figure out next steps.
A constraint can be the brief. Staying inside the modal looked like a limitation. It's what forced a solution that fit the rest of the product, which is why the pattern spread instead of staying a one-off.
Listen carefully and know when to concede. Sometimes the hardest part of the job is to know what to fight for. The way I navigate that is to really listen to the feedback. What is underneath it? Is it about the actual component itself? Or is it the actual flow? Understanding what questions to ask allows us to get closer to the best user experience.