Playbook

Operations · Parkmerced · Prototype

Nine thousand residents, and the key handoff lived in a group chat

I work at Parkmerced. When the property management company changed, the operating knowledge did not transfer with it — the new team ran single-family homes around the Bay, and almost nothing about a property this size worked the way their playbook assumed. Nobody wrote the gap down. For a while, I was where you went instead.

Scope

Four weeks, in Figma and then in Next.js. It runs and you can click through it. It has never been deployed to the team: no accounts, no database, nothing that survives a refresh. What I was testing is whether the shape of a procedure is right, not whether the software is.

Owner
Nate Bautistas
Role
Product designer — the research, the interface, and the build
Built with
Figma, Claude Code, Next.js
Timeline
Four weeks, 2026

Overview

Parkmerced houses about nine thousand people. The company that took over managing it knew single-family homes, and the systems that work for a house on a street do not survive contact with a community this size. Leadership was remote. Turnover on the ground was high enough that the person who did a thing last month had often already left.

So people asked. Onsite staff asked me, or asked whoever had done it most recently, and the answer came back in a Teams thread nobody could find again the following week. The answers were usually right. They just cost somebody twenty minutes each time and never accumulated into anything.

I started by listing what we actually do — every recurring task I could name, and where its instructions physically lived, if they lived anywhere at all.

A mind map of every recurring procedure, branching out to where each one's instructions were stored.
Every recurring procedure I could name, and where its instructions actually lived.

None of it was lost. It just had nowhere to be.

Every answer existed and somebody had it. It was spread across tools that do not index, held by people who leave, and needed by whoever was standing in front of a resident with their hands full.

Teams

hey do you know where the parking form link is?

Email

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.

I looked for something to buy first. Everything I found was a better place to put documents, and the problem was not where the documents were.

The bet, and what I traded for it

The bet is that a procedure written as something you run, rather than something you read, gets followed in the moment instead of asked about. That is testable, and I have not tested it. What four weeks bought was building it precisely enough to be worth someone's time to test.

  • Search, not folders

    A folder tree assumes you already know how the company is organised. New hires are exactly the people who do not, and they are the people who need this most. So the front door is a search field and structured names.

    What I gave up. Browsing. If you do know the tree, you now have to think of a word instead of following a path, and there is no view that shows you everything at once.

  • A procedure is steps, not a document

    The first version laid an SOP out as a page you read top to bottom. I rebuilt it as an overview, then steps, then the exceptions, then who to escalate to — because that is the order somebody actually runs one in.

    What I gave up. Authoring speed. Writing one is real work now, and all of that work lands on the person who writes it once rather than on the fifty people who run it.

  • Exceptions live inside the step that raises them

    “What if the lease still says Pending” belongs at the moment you check the lease. Filed in a section at the bottom, it is a section nobody scrolls to.

    What I gave up. Seeing the whole procedure at once. Collapsed, a twelve-step SOP is twelve lines, and you cannot scan it for the parts that are going to bite you.

Steps

A worked example of a move-in key handoff. The systems and the names are changed.

This is the object the whole thing is built around. Open a step to see what it asks you to do, and open the question inside a step to see where the group chat used to come in.

  1. Open the resident record. The status has to read Executed. Screenshot it into the ticket before you touch a key.

Escalation owner · Leasing ManagerLast revised · 12 Feb 2026

Everything else in the product exists to get somebody to a record like that one, or to get a record like that one written down in the first place.

Typing a query and landing on the matching procedure. Category filters and structured names do the rest of the work.
Writing one. The step model is the form: a title, an overview, steps with their attachments, then the exceptions and who owns them.

My first build alongside AI

I designed Playbook and Claude wrote most of the code. The hard part was not asking. It was reading what came back closely enough to know whether it was right, which is a different skill from writing it, and one I did not have at the start.

Scaffolding a component takes about two minutes now. That removed the pause where I used to work out whether the structure was right, and I shipped a fair amount of structure I had never actually thought about. So the habit I came out with is a boring one: before I ask for anything, I write down what the thing has to survive.

Script · before I ask
What it has to handle
  - the empty state, and who hits it first
  - the longest realistic content, not the demo content
  - what happens when the thing it depends on is missing
  - keyboard: where focus goes when it opens, and where it goes back to

What it must not do
  - own data that something above it already owns
  - invent a size, a colour or a duration

Done means
  - I can name every state out loud before I read the diff
Scaffolding a component, then reading back what it produced.

Edge cases

What this got wrong, in the order I hit it.

  • I built the interface before I defined a system

    No colour tokens, no type scale, values living wherever I happened to type them. Then in week three I changed direction on the visual language.

    What it cost. Two days I did not have, spent changing the same value in about thirty places instead of one. I now write the tokens before I draw anything, and this is the only reason I do.

  • I laid an SOP out as a document

    The first version was a page you read top to bottom, with the exceptions collected at the bottom. Then I watched myself use it: I went straight to the middle every time, and I never once read the bottom.

    What it cost. The rebuild — but early enough that it was cheap. The step model came out of that, and so did putting exceptions inside the step instead of under the fold.

  • I designed for four audiences and talked to none of them

    Onsite staff, remote support, managers, new hires. I wrote all four into the brief from my own read of the building, which is a real source but it is one person's.

    What it cost. I still cannot tell you which of the four this is actually for, and that is the largest hole in the project. It is the first thing I would fix, and it does not need a single line of code.

What would have to be true

Nobody but me has used this. Before I would put a team on it, three things would have to be true, and not one of them is a design problem:

  • Somebody who is not me runs a real handoff out of it, cold, while I stand there and say nothing.

  • The person who has to write the SOPs writes one without asking me how. Tools like this die at the source, not at the reader.

  • It survives a process change. Every document I am replacing was correct on the day somebody wrote it.

What I would defend is the step model. Most of the rest I would rebuild, and I can tell you which parts, because I already had to once.

Escalation owner

Nate Bautistas

Talk to me about this one

If you have run operations somewhere this problem exists, I would like to hear how you solved it, because I do not think I have yet. And if you are hiring product designers, let's talk.