Two versions of a permissions screen, two stakeholders who wanted different things, and a third version that surfaced in 2 minutes because someone was listening for the need.
Two versions of the same screen went up in crit on Tuesday, and for a few minutes it looked like a vote.
The screen was a reporting permissions flow. Version A grouped reports into a handful of categories, clean and easy to take in at a glance. Version B listed every individual report, 16 or 17 of them, with a Select All at the top. The designer presenting had done the right thing and brought both, along with the context that customer success preferred B. Their reasoning was fair: the people who field the support tickets want granularity, because granularity is what the tickets are about. Most of the room leaned toward A, because nobody wants to scan 17 toggles to give a colleague access to one thing.
This is the moment crits tend to go sideways. Two stakeholders, two defensible positions, and the cheapest way out is to pick one and move on.
Our mobile design lead found the third version instead. What if the bigger groups show first, they asked, each one something you can toggle on or off, and turning a group on opens it up so you can see and adjust the individual reports inside? I heard myself say “so, more like progressive disclosure,” and that was the direction.
The answer to ‘A or B’ in a crit is often the version hiding between them.
What I like about the move is that it didn’t ask either side to lose. Customer success keeps the granularity they asked for. The account owner setting up a new team member gets the calm screen. The synthesis took maybe 2 minutes, and it only happened because someone in the room was listening for what each side needed instead of counting which version they’d voted for.
Three smaller things from the same session are worth passing along, especially for y’all earlier in your careers who are starting to present in crit.
Bring the default state in as a design decision. At rollout, every report in this flow is toggled off, and the presenting designer explained why: if someone had report access before the feature existed and the system extended it automatically, they’d keep permissions nobody ever granted on purpose. Account owners have to turn reports on per person. That’s friction, and it’s intentional. A default is a judgment call that will run thousands of times with no designer in the room to explain it, so it belongs in the crit as much as the layout does.
Make the controls speak one language. Checkboxes in one part of the flow, toggles in another. It’s a small catch and an easy fix, and it’s the kind of thing that tells you whether a design system is being followed or just referenced.
Leave the unresolved thing unresolved. Another designer on the team pushed back on building a bespoke flow for one permission type at all. Not a reusable pattern, they said, and what happens when the next permission type shows up? Maybe this wants to be a notification or a banner rather than its own UI. The presenter had heard the concern before and had a real answer: report access is critical for roles like practice managers, and losing it mid-rollout would break their ability to do the job. We also floated editing permissions from a team member’s flyout, which might handle bulk updates without a dedicated flow. None of that got settled on Tuesday, and the session ended with the presenter owning the exploration. That’s a fine outcome. A crit that closes every loop on the spot is usually a crit where somebody stopped pushing.
The teachable part
When a crit splits between A and B, listen for what each side needs and look for the version between them. And bring the default state to crit: it’s a design decision that runs without you.