Five tangled boards, read as one lifecycle.
A seven-person art studio had never mapped how it works as a whole. I drew each department, found five processes that barely connected, and rebuilt them into one student lifecycle over a single shared record.
I drew how the studio works. Almost nothing connected.
Five accurate department boards that barely touched, with a student's name re-typed at every stage.
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 boards came out of it, each accurate on its own and barely touching the others.
A handoff between two teams was a message someone remembered to send, and the same approval waited on one role in five places. A studio is 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 one order.
I traced the one thing running through all five boards: a single student, from first inquiry to graduation. If they do well, their story becomes the marketing that brings in the next one, which is why the spine closes on itself.
months
a graduate’s outcome becomes a consented case study, then content, then the next family’s reason to inquire
I held that arc still and rebuilt each department against it, always in the same order.
The four-step order 1 diagram
Cut the steps that should not exist. Most boards had a few, and they were the cheapest thing on them to fix.
Reduce what is left to the smallest version that still does the job.
Only now. Automating a broken step only makes a broken step faster, which is the whole reason this order is fixed and not a preference.
Last, join the systems onto one shared record. Connecting first is how five boards became five sources of truth.
I redrew the five boards as one.
The same departments and phases as the board I found, organized into one flow over a single shared record.
The rebuild keeps every step and untangles the connections.
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, took it back to the lead who runs that work, and asked them to find everything wrong with it. One pattern kept surfacing. I would call a bottleneck solved when I had only moved it.
what I thought I had fixed
routed the routine approvals awayApprovals for nearly everything funnelled to one role, so I moved the routine ones off that desk and called the bottleneck solved.
what the critique found
the same queue, on a different screenI had moved the bottleneck, not removed it. The fix was a rule defining which decisions genuinely need that person, plus a number on their own dashboard showing when they are the thing holding work up.
Six departments, rebuilt one at a time.
Each lane shows what it carried and the single move that changed it, before they recombine into one blueprint.
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.
Everything works from one record, and each backstage step is tagged human, auto, or AI-drafted for a person to approve.
Four phases across the top, the people and systems that serve them down the side, all reading and writing one shared record instead of copying it between each other. The dashed rules are the blueprint's own borders, between what a family sees and what they never do.
→ scroll the blueprint sideways
The AI reads the record and drafts the busywork.
One rule at the centre: nothing irreversible happens without a person approving it, and student data stays on models the studio hosts.
The studio already used AI in the corners, informally. The redesign gives it one place to work and one rule: a person approves anything that sends, pays, or publishes. The model drafts; a person commits. Nothing irreversible fires on its own.
Anything touching a student's records runs on a model the studio hosts itself, which keeps a young person's data where the law expects it. The teaching, the critique of a portfolio, the read on whether an idea landed: I never put those on the table. The studio sells exactly that.
The studio's own automation key 1 photo
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.
Every figure on a dashboard has to answer one question: what do I do about this?
Each team gets a dashboard scoped to the decisions that role makes, reading the same record. Figures that could not answer that question, I cut. A few carry a signal the studio needed without asking for it, like whether the work is creeping toward the limit of how many students the mentors can take.
Needs you
One-click drafts
Every intake said “too many leads”. I nearly designed for it without checking.
A faster funnel only helps if the mentors can teach the students it converts. Nobody had asked.
I read it as the problem and started designing a faster funnel. The reviewer stopped me. If the mentors were full, converting harder would fill a longer line and make the experience worse.
So I 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. Now I test the loud signal before I act on it.
Six artifacts, and the studio can run them without me.
An as-is map, a to-be blueprint, one shared record on an MCP server, a self-hosted AI layer behind a human gate, a dashboard per role, a phased build plan.
The engagement is live and mid-build, so I will not report outcomes I have not measured. What I will defend is the sequencing: the cheapest, safest wins come first, so they earn the trust the rest of it needs. The one-lifecycle view held up against every department I rebuilt.
What I would do differently: I would build the shared record first.
Everything else waited on the record underneath, and the dashboards were the easy part.
I designed the visible parts first and left the unglamorous prerequisites for last, when the build 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 a first service-design project, most of the craft turned out to be restraint. Automating the studio was easy. The harder call was what to leave exactly as it is.