The read-only state the whole team had skipped

The missing middle state: read-only inspection.

The product

Accolade is a B2B SaaS platform for multifamily property operations - leasing and maintenance across communities and units, increasingly with AI in the loop. A system that large repeats the same interaction shapes often enough that getting one pattern right pays off many times over. For more information, see www.accoladehq.com

The chair

I came into product design through writing, which means I'm often in the user's chair before anyone's in the builder's chair. This project is what happens when those two chairs collide.

Context

At Accolade I was the sole UX writer across three product lines. Because of my technical-writing background, I was pulled in to test the support docs for three features being prepped for release, features I didn't own, built by other PMs and designers. Around 60 articles over three weeks. The job was to walk each documented flow step by step and confirm the docs matched the real product.

The catch

Walking a user path for a feature I didn't own, I clicked a list item and the drawer opened straight in edit mode. From the user's chair I'd stepped into to write the docs, the gap was obvious: there was no way to just check a record, only "see it in the list" or "drop into edit." The middle state, read-only inspection, was missing.

Then the uncomfortable part: I'd been shipping the same edit-mode default in my own features without noticing. It was a convention, not a decision. The docs-lens caught what my design-lens had waved through.

The insight

Writing step-by-step paths is user simulation, it puts me in the user's chair. Designing puts me in the builder's chair, where I assume intent. Testing docs collides the two: whatever the builder-chair accepted, the user-chair exposes.

How I checked it wasn't just my preference

I pressure-tested it two ways before I trusted it.

First, against the field. I ran a competitive scan of how established enterprise tools handle the split between viewing a record and editing it: Notion, Salesforce, Airtable, HubSpot, Jira. Almost none open a record straight into edit mode; the dominant pattern is view-first, edit-on-demand. It lined up with how the major design systems frame it, too: NN/g on mode error, Carbon and Cloudscape on using read-only rather than disabled states for non-editable fields, since read-only stays readable and keyboard-accessible while disabled gets skipped by screen readers.

That scan did two things: it told me the instinct wasn't idiosyncratic, and it sharpened the spec, view mode should render read-only, not disabled. The surprise wasn't that view-first is right; it's that we'd shipped the opposite default and no one had questioned it.

Then, against pushback. I fixed it in my own features first, view-first then edit, as a working proof, not a proposal, and brought it to the design call where the feature owners could push back with a use case. They did, at first: "that was the design." My answer was the use case, people often want to inspect a record, not act on it, and edit-mode default gave them no way to just look. No one had a counter-use-case, so the pattern moved. Design consensus is the closest thing we have to peer review without a Head of Design; if the fix had only been my taste, it would have died in that call.

What I changed

• 1Redesigned my own features to view-first then edit: read-only on open, edit one deliberate step away.
• 2Built it as a local component. Other designers began pulling view-first from my component into their own features, and on that momentum the team decided to promote it into the design system as a shared pattern.
• 3Followed the consequence through. Deletion had been sitting inside edit mode; once open didn't mean edit, deletion now lived behind view → kebab → edit. I kept that added depth deliberately: a destructive action should take intent to reach.

Outcome

Other designers adopted view-first directly from my local component, and the team agreed to formalize it into the design system. Then operations paused for a funding round, before the design-system component was built. So the honest state: reused by peers from my component, decided as a system pattern, and built into three of the eight features I owned end to end. Not yet formalized, and not yet live to users. I speak to what was decided, adopted, and built, not a finished rollout I can't claim.

What I carry forward

Writing documentation puts me in the user's chair; designing puts me in the builder's chair, where I assume intent. Testing docs collides the two, and whatever the builder-chair accepted, the user-chair exposes. That's not QA; it's design intelligence under a different frame.

And the fix didn't need authority to spread. I didn't own those features. Fix your own scope, show the working version, and other designers will pull it into theirs.