The UX intake process

The UX intake process

The intake process has one goal: to understand a problem from 360 degrees as a team. This process is a critical part of UX design. Without it, you cannot create a product that delivers the best experience for the user.

After you read this article, you will be able to do this systematically and consistently. 

The typical intake process

Here is the outline of a typical intake process:

Typical intake process
  1. The intake process starts with a product manager putting as much relevant information as possible in an intake form.
  2. Next, an intake meeting is planned with the goal of understanding and getting agreement on the information provided in the intake form. Typically, a project or release manager would facilitate the meeting, which would be attended by product managers, designers, user researchers, and product owners or architects.
  3. Once the meeting takes place, the intake form will be stored and shared with participants to be used for future reference.
  4. Iterate the process whenever necessary.

Knowing how this process looks like, let’s first answer a fundamental question: why are we doing it?

The need for an intake process

Have you ever been asked to deliver something without having an understanding of why it is needed? As a product manager, does the idea of not meeting business objectives, user expectations or functional requirements leave you frustrated?

Having an intake process can help you avoid these situations.

My biggest takeaway from Simon Sinek's Golden Circle theory is that “it is the why questions and a purpose that get people motivated and engaged.”

Applying the Golden Circle theory to Agile practice, let's start with asking the “why” questions first.

Once every member of your team understands the common goal that needs to be achieved, they will become more engaged, autonomous, lean, happier and more productive.

The intake questions

First, start with the “why” questions. The “five whys”, or “ask why five times” technique shows the benefit of repeatedly asking why.

Why? x 5

Asking this question repeatedly is definitely a powerful technique. However, it doesn't always help me to get great answers.

The reason for it is that people find it difficult to think of an answer if the question is too open or broad. They can struggle not because they don’t have the answer, but because they don’t know what answer you are expecting.

To address this, I apply the “five whys” theory a little bit differently, by always providing a context to make the question less open. Instead of literally asking “why?”, I try to ask questions from a specific perspective. Combined with this technique:

Six thinking hats

I ask the questions with different hats on, one at a time.

For a product manager, here is how asking why five times might look like:

Ok, this feature sounds interesting. But,
  1. in what way can this feature solve the problem the end-users are facing?
  2. what are we trying to improve? End-user satisfaction, business value, or software quality?
  3. is the business value of our product increased?
  4. will more users start using our product?
  5. how do we measure success?

As a designer, the five why questions might look like this:

Ok, I heard what you want to make. But,
  1. who are the target users?
  2. what is the problem that we are solving?
  3. how much do we know about the target users?
  4. how much do we still need to learn about the target users?
  5. how do we know that any proposed design solves the problem?

Putting different hats on allows you to ask a wide variety of questions that will lead to richer answers. Asking these questions is definitely a great start to getting to a useful outcome for the team. Next, I will show you how to ask good questions systematically and consistently.

The intake form

Eventually, all the questions that I typically ask during an intake meeting become the blueprint for the intake form. Here is how all the “why” questions are organized in the intake form: 

Structure of the intake form

You could color-code each slide to give an indication of ownership:

  • Blue: for all participants to answer.
  • Green: more for product managers to answer.
  • Yellow: more for user researchers to answer.
  • Navy: more for technical representatives (product owners or architects) to answer.

Why should you create an intake form?

There are many advantages to bringing all questions together in one intake form. To list a few:

  • The intake form is reusable. If it helps one team, it can do so for other teams as well. If something is working, there is no need to reinvent the wheel.
  • It helps you focus on getting meaningful answers to all the important questions. Using a predefined list, you take away the cognitive load of trying to remember all the questions.
  • It prompts an audience to look at the problem from many different perspectives.
  • It guarantees a top-down approach. The questions are carefully ordered from the most fundamental to practical ones, from abstract to tangible ones.
  • It standardizes the requirement statement. By using the same template, parts of the intake form can be copied and pasted when a similar feature is taken in, or when a different client requires the same feature.

Intake form format

There are two formats I work with at the moment:

  1. PowerPoint presentation.
  2. Wiki page + a dedicated template.

Each of these has its pros and cons. This is why I am testing both at the moment, with the aim to eventually choose one winner. Product managers can choose to either create a PowerPoint presentation or create a wiki page with a dedicated template. 

Let’s look at PowerPoint as an example.

Example slides in the intake form

Here are some examples of slides you could use. A typical page in the form looks like this:

Example slide: Questions regarding user value

Sometimes, predefined content can be helpful.

Example slide with pre-filled content

Not all slides are full of questions. The following slide shows the elements needed to create a simple diagram that shows all the teams involved and their relationship. This can prove useful especially when working for a large organization, where not all designers might know each project stakeholder and their teams.

Example slide: Teams to collaborate with and their relations

Now, imagine you have filled in an intake form and answered most of the questions. The next step is to get everyone to agree.

The intake meeting

The purpose of the intake meeting is to make sure that everyone in the team has the same understanding of what needs to happen and what goal needs to be achieved – based on the intake form.

During my conversations with product managers, they will often say “Xinrong, it’s very clear to me what needs to happen.” That’s fantastic, and the intake meeting is to make sure everyone in the team shares this vision.

A meeting is the only format I find effective for this purpose. Face-to-face meetings are, of course, better. However, remote meetings are still more effective than any other tools such as email, wiki documentation or instant messaging.

The intake form is there to make the meeting more productive. It is perfectly fine that not all questions are answered with 100% confidence. Given the complexity of the problems we are solving, it is difficult to always find the absolute truth. The key is to get the best answer together as a team based on the information available at that point in time. As long as we all agree, we are going in the same direction.

Tips and best practices

After repeating this intake process a few times, I have noticed that some approaches work better than others. Here are some tips and tricks for you, based on my experience.

While no two teams are exactly the same and what works for one won’t necessarily work for another, I hope these learnings can inspire you.

When do you initiate the intake process?

As described in this article, the intake process requires some preparation and demands time from the team. However, the more complex the problem and the more intricate the team structure, the more the intake process can help.

For me, whenever I’m in doubt, the decision comes from asking the designer these questions:

  • Do you understand why we must work on the topic?
  • Do you have enough information to start conceptualization?
  • Do you know which teams need to be involved, other than the UI development team(s)?

If one of these answers is “no”, the intake process can help get the answers.

Fill in the intake form before the meeting

Given the number of questions and their complexity, it is a good idea to start your intake meeting with an already filled-in intake form. During this meeting, stakeholders go through the document together. We don’t turn to the next slide unless we reach an agreement on the current one.

There may be situations when not even product managers have sufficient information to give a definite answer to certain questions. In this case, more work needs to be done.

Start by asking product managers

The intake process starts with product managers filling in the intake form with as much information as they can.

Let’s take a look at the typical questions product managers are expected to answer:

  • Reasons to intake the feature. Why should we work on this feature at all?
  • What have we agreed to deliver to which clients? What did we specifically commit to? Is there a specific client requirement to keep in mind?
  • Contact person for more information. If we want to know more about a certain commitment made to a client, who can we contact?
  • Business values

These questions share two traits:

  1. They are typically more intricate to answer. Therefore, it can take a long time for product managers to come up with meaningful answers. Some of these answers require gathering information from many different sources.
  2. These questions are also more deterministic. Some answers, such as, “Why should we work on this feature at all?” have more impact than others. Having good answers will determine, in part, the success of the entire project.

Conclusion

The goal of the intake process is not to add an extra step to creating a great product. Instead, it is about making sure everyone involved is working towards a common goal and has access to the same information.

Remember, the intake process is a structured way to achieve the following:

  • Bring all stakeholders together.
  • Facilitate the journey to reach agreements.
  • Promote multidisciplinary collaboration at an early stage.
  • Enable iterative learning.
  • Sustain and replicate success.
  • Provide consistent materials to communicate further.

Now that you know how the intake process works for me, how will you start using it in your work? I’d love to see how you are making it part of your team’s process.

Great article Xinrong, Thnx for sharing!

回复

要查看或添加评论,请登录

Xinrong Ding的更多文章

社区洞察

其他会员也浏览了