Ruby Wu
LooperRoom Enterprise
Client
LooperRoom
Year
2025
Team
Ruby Wu / Sole Product Designer
Akash Patel / Developer
Stella Sakhon / Project Manager
OVERVIEW
An enterprise system that turned "manage our keys and codes" into an organization's operating logic.
LooperRoom needed a B2B platform for healthcare organizations to manage access keys and patient codes, and that one sentence was the entire brief. No defined roles, no permission rules, no shared understanding of how resources flow through an organization. I judged this as a structural problem before it was ever a screen problem, so I built a permission matrix first instead of sketching dashboards from a vague spec. Engineering built directly from it, and the role logic still powers operations across programs today.
PROBLEM
In mental healthcare, a misplaced code isn't an inventory error, but a privacy risk.
01
Undefined roles
Executives, Directors, and Supervisors had no distinct permissions
02
Untracked authorization
Codes floated with no owner, a compliance risk in this sensitive domain
03
Misaligned logic
Every team held a different mental model of how the system worked for them
RESEARCH: MAPPING THE CHAIN OF TRUST
Before designing screens, I interviewed every layer of the org chart.
To design a system nobody could describe, I went to the people who would live inside it, then watched them work through an early prototype. Where they hesitated and what questions the interface failed to answer became the raw material for the authorization chain: five tiers, two resource types (clinician access key & patient code), one chain of trust where every key always knows whose hands it is in.
01
Role-based interviews
2 to 5 people per level, executives to clinicians
02
Task-based walkthroughs
Real assignments, participants thinking aloud
SYSTEM MAPPING: THE MATRIX WAS THE SPEC
I didn't start with screens, but with a table engineering could build from.
Every role, crossed with every resource, crossed with every action: allocate, distribute, assign, track, reassign, return, revoke. Each cell answered one question with no room for interpretation, so engineering built role logic directly from the table. Contradictions were caught as cell edits instead of backend rewrites, which is exactly where the weeks of saved rework came from.
PRIORITIZATION: THREE LAYERS, IN ORDER
Build the logic the system can't run without. First remove the daily pain, then get smart.
With limited engineering capacity, sequence was strategy. A smart layer built on wrong permission logic is a demo, not a product. Therefore I worked with PM to define the priorities of our feature design in 3 layers:
01
Foundation
Roles, permissions, resource chain
02
Daily operations
Bulk onboarding, status visibility
03
Intelligence
Usage trends, anomaly alerts
DECISION 1: ROLE-SHAPED DASHBOARDS
Your first screen is your job description.
The matrix didn't just tell engineering what to build. It told me what each role should see first. Same product, same data, different shape per role, because a universal dashboard with filters serves no one's actual job.
Executive dashboard
allocation and oversight - sees resource health, no operational detail
Supervisor dashboard
frontline inventory - sees status distribution and today's attention items
DECISION 2: ONBOARDING AN ORGANIZATION, NOT A USER
B2C onboards a person. B2B onboards an org chart.
I designed both sides of LooperRoom, and this is where the difference became concrete. The consumer app onboards one vulnerable person, so the design work is trust and warmth. However, the enterprise platform onboards an entire hierarchy, so the design work is scale and accuracy. CSV bulk invitation replaced one-at-a-time entry: setup in minutes instead of days.
Before
After
DECISION 3: STATUS OVER TOTALS
The brief asked for a total, but the users needed to know what to do next.
The requirement from the PM and CEO said: display the total number of codes in a key. But in walkthroughs, participants at every level looked at the total, paused, and asked some version of "okay, but how many are actually available?" A total answers no one's Monday morning question. I brought the walkthrough notes back, and we changed the requirement. A total tells you the size of things, and a status distribution tells you what to do next.
Before
After
DECISION 4: RECOVERY AS A FIRST-CLASS FEATURE
Org charts have bad days, and the system should absorb them.
Interviews kept surfacing scenarios no happy path covers: a director leaves and every key they distributed is orphaned, or a code reaches the wrong clinician, which here is an authorization error touching patient privacy. So recovery became a designed feature, not an afterthought. The maturity of a B2B system is not in its happy path, but in how gracefully it absorbs the ways organizations actually behave.
Return
Sends a code back up the chain
Reassign
Moves it to the right clinician
Unassign
Releases it cleanly
DECISION 5 (BETA): THE AGENT INHERITS THE MATRIX
Could the same permission matrix that shaped every screen also shape what an AI is allowed to know?
Could the same permission matrix that shaped every screen also shape what an AI is allowed to know? I designed an Ask Agent panel across all five roles to find out, and gave each agent the same boundaries as the interface it sits inside, not as an afterthought but as the actual spec.
I could have let the agent take action directly, reassign a code, flag a record. I chose not to. The agent notices and navigates, the human decides and acts, the same rule Melo follows in LooperRoom AI, now applied across five roles instead of two.
Supervisor
Surfaces workload gaps and idle codes. Suggestion routes back to the reassign flow.
Director
Answers render as comparisons, not totals, spotting the outlier is the job at this tier.
IMPACT
It paid off when we do structure first, and screens second.
The permission matrix was finished before development began, so authorization errors were caught as table edits, not backend rewrites. Reviewing it against the original requirements surfaced 12 logical contradictions before a single screen was built.
A post-launch pilot across all five roles confirmed something we'd designed for: almost every user stayed within their own role's core tasks, with very few edge cases reaching into the tier above or below. That matched what we'd predicted when scoping the boundaries. The MVP shipped on schedule, and the same structure has since absorbed new programs without redesign.
One honest note is, long-horizon B2B metrics need operational data that accumulates over time. What we established first was structural correctness, where every resource has an owner and every mistake has a recovery path.
REFLECTION
A system's success is that nobody has to think about it.
Next step if resources allowed, I want to add the intelligence layer, where the system notices a program running low on codes or an unusual reassignment pattern before anyone asks. But the deeper lesson from this project is that the role structure never needed to be the interesting part. It just needed to hold, so a new program could plug in without anyone touching the logic again. That's the real test of a B2B platform: not how it looks on day one, but how quietly it keeps working as the business grows around it.