Five tangled boards, read as one lifecycle.
A seven-person art studio had never mapped how it works as a whole. I sat with each department, drew its flow, and found five processes that barely connected. I rebuilt them into one student lifecycle over a single shared record, an MCP server every team reads and writes, so a student is entered once instead of re-typed and handed off by hand. A self-hosted AI sits on top and drafts the busywork; a person signs anything that leaves the building.
I drew how the studio works. Almost nothing connected.
Five accurate department boards that barely touched: a student's name re-typed at every stage, handoffs left to memory.
Before I could redesign anything, I had to see how the studio runs. So I sat with the director and each department lead and drew it out. Five large boards came out of it, one for each side of the business: how leads become students, how a student is enrolled and coached, how mentors deliver their teaching, how money moves, and how the studio finds the next student. Each board was detailed and accurate on its own. Side by side, they barely touched.
A student's name was typed fresh at every stage. A handoff between two teams was a message someone remembered to send. The same approval waited on one role in five different places. None of it was wrong. But a studio is really one path a student moves along, and running it as five separate machines left gaps for a name, a payment, or a handoff to fall through.
as-is · the real board
Once I followed a single student, the boards became one path.
One student's arc became the spine, and every department was rebuilt against it in a strict order.
I stopped treating the boards as five processes and traced the one thing that runs through all of them: a single student. They arrive as a lead, sit a consultation, get assessed, decide, enroll, get onboarded, get coached for months, apply to schools, and graduate. If they do well, their story becomes the marketing that brings in the next student, and the arc loops back to where it began.
So I fixed that arc as a spine and held it still, then rebuilt each department against it, one at a time. I kept to a strict order: cut the steps that should not exist, simplify what is left, automate, and only then connect the systems onto one shared record. Automating a broken step only makes a broken step faster.
I redrew the five boards as one.
The same departments and phases as the board I found, now organised into one flow over a single shared record.
The rebuild keeps every step but untangles the connections. Blue is the automated spine that carries one record the whole way. Gold marks the two things I added: the zones I tightened, and one shared record on an MCP server beneath every lane, carrying the student from one department to the next automatically.
to-be · the redrawn board
→ scroll the board sideways
I designed each department, then tried to break it.
Every redesign went back to the people who run the work, to be pulled apart before I trusted it.
A redesign that only its author has read is a guess. So every department went through the same loop. I drafted the new flow, then took it back to the director and the lead who runs that work and asked them to find everything wrong with it. Those critiques were uncomfortable and worth it.
One pattern kept surfacing. I would call a bottleneck solved when I had only moved it. Approvals for nearly everything funneled to one role, so I routed the routine ones away, then noticed I had rebuilt the same queue on a different screen. The fix was a rule that defines which decisions need that person, and a number on their own dashboard that shows when they are the thing holding work up. I kept the critiques in the work instead of hiding them.
Six departments, rebuilt one at a time.
Each of six lanes shows what it carried and the single move that changed it, before they recombine into one blueprint.
Holding the spine still, I rebuilt the departments one at a time, in the order the reframe set. The five boards became six lanes: I pulled the director's approvals, which had slowed all of them, into a lane of their own.
The hardest problems sat in the boundaries between departments rather than inside any one of them. Two teams would each assume they owned the same proposal, invoice, or case study, and the work stalled in the overlap. I settled every case with one rule: one team owns the artifact and the call to send it; another owns the mechanism beneath it, the templates and the shared record. Once that rule was written down, no two lanes claimed the same job twice.
The whole service on one shared record.
Four phases run across the top; roles and systems run down the side. Everything works from one record, and each backstage step is tagged human, auto, or AI-drafted for a person to approve.
The redesign is one blueprint. Across the top, the four phases a student moves through. Down the side, the people and systems that serve them, all reading and writing one shared record instead of copying it between each other. Every backstage step carries a tag, so the shape reads at a glance: what stays human, what runs on its own, and what an AI drafts for a person to approve. The dashed rules are the blueprint's own borders, between what a family sees and what they never do.
→ scroll the blueprint sideways on a narrow screen
The AI reads the record and drafts the busywork.
One rule at the center: nothing irreversible happens without a person approving it. Student data stays on models the studio hosts itself.
The studio already used AI in the corners, informally. The redesign gives it one place to work, the shared record, and one rule: a person approves anything that sends, pays, or publishes. From that record the model drafts the proposal, the progress report, the invoice, the reminder. A person reads each one and commits it. Nothing irreversible fires on its own.
The work that touches a student's records runs on a model the studio hosts itself, on its own infrastructure. That keeps a young person's data where it belongs and where the law expects it to be. The teaching, the critique of a portfolio, the read on whether an idea has landed: I never put those on the table to automate. The studio sells exactly that.
One record per student on an MCP server: the source of truth every department and dashboard reads and writes. It replaces the copy-by-hand handoffs, so everyone works from the same state.
One screen per role, built on that record. The few numbers that drive an action, plus the one-click drafts the role needs.
Every send, payment, or publish waits here as a draft with a preview. A person approves it or sends it back, and a log records who did what.
Narrow, least-privilege links from the record to the systems the studio already runs. The model reads freely and writes only through them.
Self-hosted for anything that touches a student's data. A hosted model only for the rare hard problem on non-sensitive work.
Every role gets one screen that says what to do next.
Each dashboard shows only the numbers that drive an action; every figure has to answer one question, what do I do about this?
Each team gets a dashboard scoped to the decisions that role makes, all reading the same record. Every figure has to answer one question: what do I do about this? The ones that cannot, I cut. A few carry a quiet signal the studio needed without having asked for it, like whether the work is creeping toward the limit of how many students the mentors can take.
Needs you
One-click drafts
The mistake I almost shipped.
The loudest signal was a worry heard at every intake: too many leads. I nearly built a faster funnel before checking whether the mentors were full.
The loudest signal in the studio was a single worry, raised again and again at intake: too many leads. I read it as the problem and started designing a faster funnel. The reviewer stopped me. A faster funnel only helps if the studio can teach the extra students it converts. If the mentors were already full, converting harder would fill a longer line and make the experience worse, which is the opposite of what this kind of studio sells.
So I held the redesign and asked the one question only the director could answer: are the mentors full? They were not, so the intake work went ahead. But I had come close to building hard for a constraint I never confirmed, on a hunch that happened to be right. Now I test the loud signal before I act on it.
What I handed over.
An as-is map, a to-be blueprint, one shared record on an MCP server, a self-hosted AI layer with a human gate, a dashboard per role, and a phased build plan.
The engagement is live and mid-build, so I will not report outcomes I have not measured. The design work itself, though, is done. An as-is map the studio recognized as itself. A to-be blueprint that holds together across every department. One shared record on an MCP server that every department reads and writes, with a self-hosted AI on top behind a human gate on every risky action, plus a dashboard for each role. A build plan sequenced so the cheapest, safest wins come first and earn the trust for the rest.
The one-lifecycle view held up against every department I rebuilt, and rebuilding against it changed what each one was for. The blueprint and the build plan are written to be handed off and run without me.
What I would do differently.
I would build the unglamorous prerequisites first, and design the visible parts second.
I would sequence the build the other way around. I designed the visible parts first and left the unglamorous prerequisites for last, when the build itself has to run in reverse: the studio needs a clean place to keep its money before any of the finance work is worth drawing.
On my first service-design project, I learned that most of the craft is restraint. Automating the studio was the easy part. The harder call was what to leave exactly as it is.