Built with a colleague to get UX signal before waiting on real customers — now the standard early-stage check across every DOOR product team.
DOOR OS runs real locks, on real doors, for real property managers and residents. That's exactly why user testing is hard to schedule: our test participants aren't a recruited panel, they're actual customers running actual buildings. You don't swap them for a random usability pool when the flow controls who can get into someone's home.
Which means every round of real testing costs real time — up to two weeks to organize and run, before a single finding comes back. By the time it does, the design has usually already moved.
We needed a way to catch obvious friction before asking a real customer to give us two weeks.
If we could encode what we already knew about our real personas, our real usability standards, and our real platform's quirks, we could get a same-day first-pass read on any flow — and save the two-week real-user cycle for what actually needed it: ambiguous behavior, high-stakes decisions, anything irreversible.
That's the shape it still has today: Testing for the simulation itself, Documentation to publish findings where the team already looks, Consulting to tell you when simulation isn't enough and you need the real two weeks after all.
The tool runs on real persona archetypes — not invented user types, but abstractions of people who'd actually sat in our real testing sessions: the enterprise portfolio manager managing thousands units through deep PMS integrations, the on-site manager who autosaves a destructive edit without meaning to.
Each one carries real frustration triggers, real vocabulary (some clients say "Neighbor," never "Resident"), and real edge cases — calibrated against journey maps where we already have actual human findings as ground truth.
You upload a customer journey map — or hand it a doc and let it build one — pick the personas you want in the room, and point it at a prototype or Figma file. That's the whole setup.
From there it runs the flow against everything we know: the persona .md files, the journey map, platform quirks, and the accumulated record of past findings, app-store reviews and customer-support themes — all kept as markdown.
Out comes a report. And the knowledge files get updated with what it learned, so the next run starts smarter than the last.
.md knowledge for the next runWhat shipped from the hackathon was a six-question wizard: paste or describe the flow, point it at a Figma file or live build, pick personas, confirm — out comes one standardized HTML report per persona, scored for friction severity, each finding tied to a named heuristic and a concrete fix. No vague feedback, no pass/fail verdict.
That output format is what made adoption easy: any team could read it without translation. It's now the first thing we reach for whenever a team can't wait on a real-user round, or just needs a fast early gut-check before committing design time.
Beyond running tests, the tool documents itself — every report comes out as a standalone, self-explanatory document, organized by feature and test date, so findings don't live only in one designer's head. And it knows its own limits: a built-in consulting mode tells a team when automated testing is the right call versus when they genuinely need the real two weeks with real customers.
The tool is only as honest as the restraint we built into it — it was designed to front-load testing, never replace it, and that line matters most exactly when a report comes back clean and it's tempting to skip the real round. Making sure that discipline holds as more teams adopt it — not just as a rule in the skill, but as a habit in how people use it — is the harder, ongoing part.