The intake form I built three times

The company where I spend my days leading DesignOps didn't have a design team when I started. It had a design agency on retainer, taking ad hoc requests in Slack DMs from anyone in the company who could find one of the designers. As the agency offboarded and the first full-time designers came on, the question of where design requests would land had to get answered. I answered it three times. Two of those answers stopped working before the year was out.

Across the three versions, the form's job kept changing. The first was a refusal dressed as a process. The second was a funnel with one person at the narrow end. The third one is what runs intake on the team now, and it looks nothing like the first version. Each of these was correct for its moment. The form is what makes the workflow possible at all, and the workflow has to change as the company around it does.

The first version was an apology

The agency had been the design team for three years. The full-time designers replacing them came on in a rolling start, two then three then five, while the agency's seats wound down over the same quarter. For a stretch of weeks, both teams were on the books. The Slack DMs kept arriving on whichever designer had answered last. The new FTEs were trying to learn what their role was inside a company that had been treating design as an outsourced service.

The first version of intake was a message. There were no fields. The message lived in our team channel as a pinned topic: we don't take design asks this way anymore. If you have a request, please route it to design ops. I was the design ops. There was no system behind me yet.

That version held the line and bought the new team breathing room from the prior pattern, where any product manager with the Slack app could put a designer on the spot. It told everyone in the company that the relationship had changed, even though the company (and, in fact, the design team) hadn't yet figured out what the new relationship was at that stage. The first version of intake was an apology and a redirect at once. That combination is what made it work for as long as it did.

An apology doesn't scale, though. Once the agency was gone and the FTEs were the design team, requests still had to go somewhere. Telling the company not here is not the same as telling them exactly where. Buying time was the whole point of v1. The next version had to actually receive work and provide structure.

The form-to-funnel years

The second version of intake was a Microsoft Form. The URL went in the same Slack channel that had been hosting the first version's redirect message. Anyone who needed design work filled in a few fields and the response came directly to my inbox. From there, I'd open Jira, file the ticket, decide which designer it belonged to, write a short brief on top of what the requestor had submitted, and assign.

The version of me that built this form was still new to the role. I learned which fields actually mattered by what I had to ask requestors after they submitted. What's the deadline? turned out to matter less than what happens if this misses the deadline? The first answer is usually a date; the second is sometimes "the campaign launches anyway" and sometimes "we lose the launch window." Those two answers are different requests in disguise. I worked that distinction into the form over a few months of sending follow-up DMs and feeling silly about it.

The fields that survived to the next version are the ones doing decision work, not capture work. Who is the end user? is a capture field: the answer goes into the ticket and the designer reads it. What problem does this solve? is borderline; the designer needs it, but the answer rarely changes whether the request gets prioritized. What happens if this doesn't get done? is a decision field. It changes whether the request lands in next sprint or drifts into the backlog instead. Nobody has to argue about whether the urgency was real; the requestor already told you.

This version concentrated signal. Every request became visible because everything passed through one person. I could see patterns no individual designer would have seen: which PM teams sent requests with no business driver, which ones manufactured deadlines, which ones consistently submitted under-scoped asks that ballooned in the brief. By month four, I knew what the year's intake situation looked like in a way a distributed system would have hidden from me.

It could not survive its own success, though. Once the company learned the form existed, request volume climbed past what a single triager could route in a workday. I started triaging on weekends to keep up. The bottleneck that had let me see everything became the thing keeping work from moving. v2 had outlived its strategy.

What the form does now

The current intake doesn't pass through me at all. Requests start with a product manager, route through a design lead, and land in a Jira form that lives as a button in our intake Slack channel. The Slack form auto-files a ticket. The ticket lands in a weekly triage view that the design leads work through together with me as facilitator. From triage, scoped tickets enter the design backlog and get prioritized into sprints by product management alongside their own engineering work.

The structural change that mattered: requests route through product management, not around it. In v2 I was a parallel intake to product management. Engineering work was being prioritized in sprint planning; design work was being prioritized in my inbox. Two systems, two queues, two different sets of expectations. The third version puts design work into the same prioritization conversation as everything else the team is trying to ship. PMs see their requests competing with each other and with engineering's. Design leads see scope. I see the patterns I used to see in v2, except now the patterns are visible to the people who can do something about them in the moment.

The form's role in this version is what makes the rest possible. The auto-ticket-from-Slack is convenient; the form's fields are what make the weekly triage productive. The triage meeting has thirty minutes a week and a queue that varies from six tickets to twenty. The only way that meeting works is if the fields in the ticket are doing the decision work in advance. We are not learning what the request is during triage; we are deciding what to do with a request the form has already framed.

The form has stayed roughly the same throughout the last eighteen months. The fields don't change much because the questions a design team has to answer before scoping a request don't change much. What changes is the routing: who sees the answers, who scopes from them, who prioritizes against them, who runs the cycle that turns answers into design work.

Three versions across roughly three years. Each one was correct for its moment and stopped being correct when the moment moved. The first version refused; the second concentrated; the third routes. None of those words would have meant anything to me at the start, when I was writing a pinned channel topic and hoping it would hold for a week.

What nobody told me, and what I'd tell someone building their first intake form today: the form you build first will not be the form you have in three years. The fields you copy from a template will not survive contact with your company's actual urgency arguments. The version that works is the version that adapts, over time, to what your requestors actually answer when they submit. You write down those patterns; you put them in the next form; the next form does more decision work than the last one. The artifact evolves because you do.

A longer version of this arc, with the post-launch metrics and team makeup at each stage, lives in my portfolio.

The form is the artifact. The triage is the rhythm. The reality around both is what every version has to keep up with, including the one running right now.