UX Intake Process

04.1 /

Different ways in

The problem wasn't that project teams weren't doing discovery or providing a UX brief. It was that there wasn't one consistent way of delivering it. Depending on the team, region or person leading the project, it could come through different brief templates, spreadsheets, conversations or additional supporting materials. Because those materials could be created by different people at different stages of the project, the problem wasn't only inconsistent detail. I could also be left trying to determine which direction was the latest.

Most of those materials covered roughly the same categories of information, but the level of detail could vary significantly. For example, a field as broad as "section & content" might tell me generally what belonged on a page, but lack important details such as the amount or type of content the section needed to accommodate, its primary goal or whether a referenced pattern was a requirement or simply an idea to consider. Those gaps usually became questions during the kickoff call or follow-up conversations once I started working through the wireframes. Until they were resolved, I was either waiting for answers or designing around assumptions instead of established requirements.

But standardizing the existing questions and templates wouldn't solve the whole problem. Before I could rethink how project teams provided information to UX, I needed to understand what information was actually needed in the first place.

04.2 /

Defining the need

I started by creating a master list of the information that consistently proved useful when designing career sites, drawing on years of designing them and the questions that repeatedly surfaced along the way. I also included more specific product- and feature-level considerations that were important to the work but weren't always well understood by the teams preparing information for UX.

At this stage, I wasn't concerned with how the questions would eventually be written or even whether they would all make it into the final intake. I just wanted to capture all the core and supplemental information that could lead to better-informed design decisions.

I then worked with leaders from the teams responsible for project requirements to map what information was already being captured, where it lived and who was responsible for it. We also looked at what was missing and whether those gaps could reasonably be filled. Part of that exercise was understanding whether some information could simply be pulled from or linked to existing documents instead of asking teams to provide it again. That helped separate the information UX found useful from what project teams could realistically provide, while also exposing places where similar information was already being collected across other documents and intake materials.

When I started building the actual intake, that research became a starting point rather than a blueprint. I consolidated overlapping questions, removed lower-value ones, updated terminology and added new questions based on newer product features. I also considered how to organize and phrase the questions in ways that would make sense to the person completing the intake while making the resulting information easier to reference when wireframing.

04.3 /

Choosing the format

With the information mapped out, I started thinking about what the intake itself should become. I explored a dynamic form that could show only the questions relevant to each project and briefly considered an AI-assisted workflow that could review existing project materials and identify what was still missing. Both could have made the process more adaptive, but they also introduced questions around development effort, ownership, security, access and long-term maintenance.

Before adding that complexity, I wanted to launch the new process using tools everyone already had and learn from how it worked in practice. I started with Excel because a grid structure worked well for capturing multiple details about individual page sections, while separate tabs could organize the information around the different page types that made up a career site.

As I built out the spreadsheet, though, I realized all of that information did not need to live together. Some of it helped establish the context and scope of the current project, while the more detailed page requirements could remain useful long after that project was complete. A new UX Brief would still be created for each future phase or project, but the existing Page Requirements Workbook could be updated rather than rebuilt from scratch. Keeping everything in one document would mean repeatedly revisiting information that was already known or decided whenever a future phase or new page came through.

I separated the intake into two connected documents. A form-based UX Brief in Word captured the customer and project context, wireframe scope, broader site decisions and reference materials UX needed to begin the work. The Page Requirements Workbook kept the detailed page and section-level requirements in Excel, where individual page tabs could be added or updated as the career site evolved.

04.4 /

Designing the intake

Years of wireframing had given me a pretty good sense of the questions that tended to surface once design started. Instead of continuing to rely on kickoff calls and follow-ups to fill those gaps, I used the new intake to move more of that knowledge upstream. Questions about content quantities, section goals, editability, visual references and whether something was a requirement or suggestion gave project teams a clearer picture of what UX needed to make informed decisions.

But asking for more information could easily make the intake harder and more time-consuming to complete, so I looked for places where the interface could do some of the work. When there was a known set of possible answers, I used dropdowns, checkboxes or simple selections to make responses faster and more consistent, reserving open fields for information that genuinely needed explanation. Additional guidance and examples were tucked into comments where possible, keeping them available when someone needed more context without adding the same visual clutter for someone already familiar with the process.

That guidance also gave me a way to move some recurring UX and product conversations earlier in the process. I added context around decisions that had repeatedly caused confusion, including things like sticky elements, editability and other product-specific considerations, so the person completing the intake could understand the implications before recommending a direction to the client. The goal wasn't to have them make the UX decision for me. It was to give them enough context to gather better information, avoid locking the project into a questionable solution too early and understand which decisions were better left open for UX to work through.

I used the same idea in the Page Requirements Workbook. Common page elements were built in as starting recommendations, with baseline selections already checked rather than asking teams to describe every page from scratch. They could confirm or challenge those defaults as needed, which made the document quicker to complete while reinforcing the terminology and product knowledge used across our career sites. Together, those choices helped turn the intake into more than a way of collecting requirements. It became another way to share the UX and product knowledge that had previously lived across conversations, documentation and experience.

04.5 /

A better handoff

Once the new intake documents started coming back on real projects, I could feel the difference in how I approached the work. Instead of piecing together requirements from briefs, supplemental files and notes created at different stages, I had a more consistent handoff with a clear view of the wireframing scope and page-level context. The same types of information appeared in predictable places on each page tab, so I knew both what to expect and where to find it. That reduced the time I spent hunting for answers or working out which direction was current, and made it easier to move from kickoff into wireframing.

The added context mattered just as much. Something as simple as knowing whether a referenced pattern was a requirement or a suggestion meant I could understand the intent behind it and move directly into deciding what worked best for the content.

Kickoff calls were still necessary, but the new documents changed what we could use them for. I could review the project context and page requirements beforehand and spend the meeting on the client, timeline and more complex parts of the project instead of walking through every requirement line by line. On some projects, we barely needed to review the workbook at all. That meant fewer clarification questions, fewer reasons to regroup before the first internal review and less time waiting on answers before I could keep moving.

More importantly, I could start the wireframing process with a clearer understanding of the problem I was being asked to solve. Instead of spending the first part of the work establishing basic requirements, I could put more of that time into working through the solution and feel more confident in the reasoning behind it.

04.6 /

Closing thoughts

Once the new intake documents launched, they became a required part of the pre-UX kickoff process. Because my role was eliminated not long after the rollout, I only had the chance to use them across a handful of projects, but the early signs were encouraging. The information coming back was more complete, kickoff calls were easier and I was asking fewer follow-up questions than before. Feedback from the teams using the documents also consistently centered on how helpful they found the additional guidance and how easy the new process was to follow.

As expected, it wasn't perfect. I knew people would occasionally overlook instructions, skip details or do more work than they needed to, regardless of how carefully the documents were designed. In early use, for example, some people marked every section as equally important even though the workbook explained that the field only worked if priorities were meaningfully differentiated. Others added information to sections of the workbook where no additional context was needed, even though the guidance explained when those fields could be left alone. As a result, they ended up doing some of the work I had specifically designed the intake to help them avoid.

In most cases, those were small issues that could be corrected with a quick reminder or a little guidance, and I expected the process to get smoother as people became more familiar with it. That was part of the reality I was designing for, not something I expected the documents to eliminate completely.

My next step would have been to gather feedback more systematically, continue iterating on the experience and keep the intake current as our products evolved. I still wanted to revisit the more dynamic approaches I had considered earlier, but the project had already clarified something I would carry forward. Standardizing a process works best when it reduces ambiguity without removing judgment. The goal wasn't to make every project or every handoff identical. It was to give people enough structure to provide useful context while leaving the decisions that still needed UX thinking open for UX to solve.