An operational encyclopedia for how a company runs
- Role
- Product Designer
- Tools
- Figma, Claude Code, Next.js
- Timeline
- 4 weeks
- Read
- 6 min
- Skip to
The knowledge existed. It just lived everywhere and nowhere.
I work at Parkmerced, a residential community serving over 9,000 residents. After we moved to a new property management company, our workflows for parking, key handoffs, and maintenance stopped being consistent. The new team knew single-family homes across the Bay Area, and those systems did not translate to a community this size.
No SOPs were written to bridge the gap. Leadership was remote, turnover on the ground was high, and the knowledge lived wherever it happened to land.
Teams
hey do you know where the parking form link is?
RE: RE: FW: key handoff — updated process
Sticky note
ask Marco, he did it last time
Group chat
does anyone still have the old checklist
Someone's Drive
probably. we think.
What I kept wanting was one place — an encyclopedia for how the company actually operates. Every tool I looked at gave me a piece of that and never the whole picture. So I started building it.
The issue was not effort. It was that the knowledge had no home.
Execution depended on who happened to know
After the transition, the core processes lost consistency. Parking, key handoffs, and maintenance had no structured SOPs, and the knowledge behind them was scattered across tools and people. When execution depends on individual memory instead of a shared system, the same task gets done five different ways.
The real gap was a centralized system anyone could reference and execute against.
Who this impacts
Onsite staff
need clear guidance on resident-facing workflows like parking, key handoffs, and maintenance.
Remote support teams
manage tickets and escalations without full context on the ground.
Managers and leadership
need visibility into how processes actually run across teams.
New hires
join a high-turnover environment where training material is fragmented or out of date.
Static documents cannot keep up with a moving operation
A document you write once and forget goes stale the moment the process changes. If SOPs live as structured, searchable systems instead, teams execute more consistently, spend less time asking each other how things work, and onboard faster. That was the bet.
As operational complexity grows, the knowledge has to scale with it.
01
Static documents
Written once. Stale by the next process change.
02 · Today
Execution layer
Where Playbook sits today. SOPs you follow, not read.
03
Operational layer
One place holding how the whole company works.
What I built
01
Structured SOP execution
What it does
Contextual instructions per step · Scripts and documents attached inline · Photos embedded in the workflow · Edge-case logic surfaced when relevant
02
Search the way people actually think
What it does
Global search across every SOP · Category filters · Pinned and recent SOPs · Structured naming for scannability
03
Structured workflow creation
What it does
Title, category, and tagging · Overview and per-step detail · Photo and script attachments · Edge cases and escalation ownership
04
A legible system
What it does
Persistent sidebar navigation · Clear content hierarchy · Consistent spacing and states · Modular component structure
My first build alongside AI
I designed Playbook. Claude wrote most of the code. A lot of the actual work was learning what to ask for, then reading what came back closely enough to know whether it was right. I was not trying to prove I could code. I was trying to move fast on a real problem and stay in control of what got built.
Prompt · 001
Scaffold a Next.js component for an SOP step: title, body, and an optional escalation note. Keep the state local for now.
What came back
A working component in about two minutes — enough structure to click through and test whether the step-based layout held up at all.
What I changed
It put the escalation note inside the step. Escalation is a different job with a different reader, so I pulled it out into its own block before building any more on top of it.
Prompt · 002
This file is doing too much. Split the SOP editor into separate components and show me where the props and state should live.
What came back
A modular split with the prop and state flow written out — which is how I learned how the system actually fit together, rather than being told.
What I changed
I moved the boundary. It split by screen region; I split by what owns the data, so adding a field later touches one component instead of three.
Prompt · 003
What states does this need to handle? Empty, loading, error, and anything I have not thought of.
What came back
A list longer than mine, including the edge cases I would have found later in the build and paid more to fix.
What I changed
Nothing, and that is the point — it changed the order I work in. I now write the states down before the visuals, because that list is cheap now and expensive later.
Iteration log
Structure before appearance
The first version laid an SOP out like a document. It became a step-based flow instead — Overview, Steps, Edge Cases, Escalation — because that is the order someone actually runs one in.
What I got wrong
I built the interface before defining a design system. Every later change to the visual direction had to be made in as many places as I had written it.
From experimental to intentional
Cut redundancy across the inputs, restructured the Add SOP flow around the same step model, and separated content from logic so a new SOP type does not need new screens.
The expensive one
No colour tokens, no type scale, values living wherever I happened to write them. When I changed direction on the visual system late in the build, that change did not live in one place — I spent real time updating values across components instead of updating them once. Now I define tokens before I build anything, because I have paid for skipping it.
Reflection
Playbook started as an experiment in structure. It turned into a lesson about how design decisions compound, and about how I work when a real problem is in front of me.
- Why not just build another document repository?
- Most tools in this space are exactly that: you search, read, interpret. I built Playbook around the moment someone is doing the task, and put the cost on whoever writes the SOP once rather than whoever runs it fifty times.
- Why search instead of folders?
- Folder trees assume knowledge new hires do not have. Designing around how people already look for things — by keyword and intent — followed from who the tool is for.
- What did building with AI actually teach you?
- It removes the friction that used to force me to slow down and think. When scaffolding a component takes two minutes, there is no pause to ask whether the structure is right. The decisions worth slowing down for are the ones that are cheap now and expensive later.
Playbook was not about shipping another tool. It was about seeing a real problem, moving on it fast, and learning where to slow down. That is how I work.
What I would build next
I built the execution layer. Next is the rest: persistent data, role-based permissions, real-time collaboration, escalation routing — and documenting decisions as I make them, which is the exact problem Playbook exists to solve.
Closing Thoughts
Thanks for reading this far. If you want to dig into the design decisions behind any of this, or you have run into the same problem somewhere else, I would genuinely like to hear about it.