Giving enterprise teams one place to manage roles, permissions, and shared templates.
LettrLabs' biggest customers had outgrown group management. This is the organization layer above the groups—shared roles, permissions, and centrally-governed templates—built to meet the named requirements of a high-value enterprise prospect, with CEO and CTO sponsorship.
See the org model
Visit LettrLabs
Led the template system end-to-end; org-level actions built closely with engineering, alongside a PM and a Staff Designer.
Executive summary
We shipped organization management—members, roles, a nested permission model, governed templates, and partner—so the product can support structural actions in-product rather than routing every one through ops. Built to meet a high-revenue account's named requirements to sign.
My roleLed the Template system end-to-end; contributed to Members, Groups & Billing; reused the system for Partner. With a PM, a Staff Designer, and engineering.
Scope (this study)Members · Roles · Permission model · Templates · Partner
The hard partEvery structural change can affect a live automation, so the flow has to surface its impact before commit
AI in the workDesign system, validations, UX stories, first-draft prototype, and UX copy
StatusEvaluated and shipped
At a glance
One permission system, five surfaces, designed for self-service.
1high-value enterprise account named org management a requirement to sign—one of several must-haves it was built to meet
5 surfacesdesigned on one backbone: members, roles, the permission model, templates, and partner (billing is a companion study)
3 → self-servestructural changes used to need Customer Success, the CTO, and the Director of Engineering; the shipped system was designed to move those actions in-product
5 levelsgroups nest up to five deep, with permission that follows the hierarchy
~75%of revenue sits with the 3 largest clients this org layer had to serve
1 systemone permission model reused across members, templates, and partner—not four separate builds
Account and revenue figures come from internal reporting, rounded.
The problem
LettrLabs' biggest customers had outgrown group management: many teams and budgets, but no organization layer above the groups—no shared roles, pooled billing, or centrally-governed templates. Every structural change had to route through Customer Success, the CTO, and the Director of Engineering, and a paused automation is lost revenue.
What I did
Led the Template system end-to-end, then contributed its shared permission model and patterns across members, roles, billing, and partner with a PM, a Staff Designer, and engineering.
The outcome
The shipped pattern moves structural actions into the product; adoption and completion time are launch measures. Org management also sits on the must-have list of a major enterprise prospect whose named requirements it was built to meet.
Main UX
The real design problem was permission that follows the hierarchy.
Before any screen, I had to get the model right: how organizations, groups, users, and partners relate—and exactly who can see and do what.
Manage Members — org tree, roles, and the nested scope selector
TopOrganizationOwns billing, templates, and analytics for everything beneath it.
ExternalPartnerAn outside party the org pays for—limited template use, isolated analytics, walled off.
NestableGroups / teamsIndependent teams—each with its own budget, campaigns, and people.Nests up to 5 levels deep
User · modifyAdminChanges within their branch of the tree.
User · viewMemberSees their org and groups—no changes.
| Capability | Owner | Admin | Member |
|---|---|---|---|
| See their org & the groups they belong to | |||
| Invite people, set roles & scopes | – | ||
| Manage billing | – | ||
| Create & govern templates | – | ||
| Transfer ownership or delete the org | – | – |
Can do View only – No access
Groups are independent: a member of Group A can't see Group B—only someone in the umbrella group above both can. Permission inherits down the tree, never sideways, and an admin's reach stays bounded to the highest group they administer.
Before nesting — models I ruled out
Three simpler permission models, and why each broke at enterprise scale.
Nested inheritance wasn't the obvious first choice—it was what survived after the simpler options failed against real, multi-level org charts.
Permission model
Why it broke — or survived
Ruled outFlat org-wide roles ✕
Easiest to build, but it can't bound reach—a regional lead could edit another region's billing and templates. No way to say "admin here, not there."
Ruled outAccess-list per resource ✕
Maximally flexible, but it doesn't scale: every new hire or template means re-granting across the tree, and "who can see what" drifts out of anyone's head within a quarter.
Ruled outTwo levels only (org → team) ✕
Enough for a small company, but enterprises run region → county → office—deeper than two. A hard cap forced customers to flatten their real structure.
ShippedNested inheritance ✓
Reach is automatically bounded to a branch, it scales as the tree grows, and it matches how the enterprise is organized. Its one cost—resolving which live automations a change touches—became the "show the blast radius before you commit" flow.
The problem behind every screen
Almost every structural change can pause a live automation.
Moving a team, deleting a payment method, removing a template scope, editing a locked design—each can silently break a running campaign, and a paused automation is lost revenue. The through-line of the whole project: never let an admin make a structural change without first showing exactly what it breaks.
Before you commit — who loses access
Move a team to a new parent and some admins lose their reach. The move dialog names each person and why—"admin of previous parent group"—before anything changes.
Before you commit — who gains access
The same dialog shows who gains access under the new parent, so the person making the move sees the full blast radius, both directions.
Move a team — members who lose vs gain access
Delete a region — who loses access, and where the sub-groups go
Templates · my end-to-end area
Govern centrally, use locally—without touching live campaigns.
A top-level admin creates a template once; any group can use it, as long as a scope (the shared group) is set. It's how an org sends one campaign across many teams—while keeping control of the design.
Every template control, one surface—filter by the job.
Pick a job to filter the controls, then click any row to open that screen.
How I worked
Templates were my end-to-end area. Working with a PM, a Staff Designer, and engineering, I owned the template system in full—its scopes, locked layers, and affected-automations flow became the patterns reused across Groups, Billing, and Partner. How I drove AI through the work →
AI in the process
AI-READY SYSTEM
AI prototyped org states from the shared Figma system—keeping drafts aligned with the product.
The org surface has a lot of states—empty groups, deeply nested scopes, locked templates, affected-automation warnings. The key move: AI drafted those states from the design system's own components and our shared Markdown (.md) specs—the same components and voice-and-tone docs behind the Figma system. So drafts stayed aligned with that system instead of becoming one-off mocks. (These ran as HTML prototypes; the coded React version came later, on my own, after I was let go—that's the design-system case study.)
That freed the team for the flows that carried real risk—the structural, automation-touching ones. I'm usually the one bringing AI into the workflow—testing Figma Make, Codex, Claude's design tooling, and MCP, pushing them past production output into usability, research, and discovery, then documenting what works. I taught the approach to our Staff Designer and we learned it together; our Senior PM built three of his own prototypes from the same specs. Still a workflow we're refining.
Read the design system case study →component-specs.md
One source of truth
Components, tokens, and rules authored once in the Figma system—so every AI-drafted org state used the real components, not a one-off mock that would drift from that source of truth.
validations-branches.md
States & logic
Relevancy checks, validations, and conditional branches—empty, nested-scope, locked-template, affected-automation—drafted with AI from the same specs behind the design system.
ux-copy.md
First-draft copy
A machine-readable voice-and-tone reference produced first-draft UX copy for each org state that already sounded like the product—so the AI passes stayed aligned with the Figma system.
The same system made accessibility a spec, not a cleanup.
Permission and structure screens are exactly where accessibility gets skipped—but because the rules live in that system, it was a constraint from the start; the org UI met WCAG 2.1 AA. Here's what it held to on the shipped UI. (Ratios sampled from the shipped LettrLabs UI.)
Contrast
13.1:1 primary text AAA
15.6:1 nav on dark AAA
6.8:1 muted text AA
4.9:1 button label AA
Built in
Keyboard-operable
Visible focus
Never color alone
Errors tied to the field
Screen-reader checked
Outcome
One shared org model, ready for customer self-management.
Org management and billing shipped as one system on a shared permission backbone, so the two studies report the same outcome—told here from the org side, and from the money side in the companion study.
01 / SELF-SERVE · PROJECTED
Designed for self-management
The shipped pattern moves structural actions—access, roles, billing edits, and template sharing—into the product. All four enterprise accounts are expected to self-manage at launch; adoption and completion time remain pre-launch measures to validate with live accounts.
02 / REVENUE · PROJECTED
Built for the base—and on the next deal's must-have list
These surfaces serve the three accounts behind ~75% of revenue—and the prospect we're pursuing, ~$2M in potential revenue if it signs, named org management and org billing as requirements to join. A named requirement, not a nice-to-have.
03 / SAFETY
A pattern that protects revenue
The shipped pattern shows the blast radius before a structural change, so admins can assess risk to the 95 live automations each account runs. The same protection is reused across billing edits, roles, scopes, and templates.
04 / GOVERNANCE · SHIPPED MODEL
One model for enterprise governance
Teams, budgets, and centrally governed templates share one organization model, with permission following the hierarchy up to five levels deep. Live self-management is the launch behavior to validate.
05 / DESIGN SYSTEM
0 → 45 components, 3 md specs
The org surface drew from a Figma design system taken from 0 to 45 components with 3 Markdown spec files—the same components and specs AI prototyped from—cutting roughly ~30% off design time (internal estimate) and keeping drafts aligned with the Figma system.
06 / REUSE
One backbone, five surfaces
The scope model and the show-the-impact-before-you-commit flow are reused across members, roles, templates, billing, and partner—systems thinking applied structurally, rather than solving one surface at a time.
Reflection
The automation-protection flow is crucial—and still my biggest open question.
The hardest, most important part was making structural changes safer by surfacing their impact before commit. We shipped that safeguard, but there's a cleaner flow than checking affected automations one modal at a time; it's the first thing I'd revisit.
"The screens were the easy part. The real work was a permission model that keeps central control and local use legible—and surfaces campaign impact before a structural change is committed."