Document the Organizational Assumptions About Your Users

How often have you found yourself working on the requirements for a new feature and got into a heated debate about what your users actually want or need?

If only we could conduct some user research. But we don’t have the [time, budget, resources] to conduct research, so we’ll just skip it.

But these debates are understandable (especially if you skipped the user research). Departments within an organization have relationships with different types of customers -- and, even if they do have a relationship with the same customer, their interactions with them are different.

Customer Service sees everything through the lense of support requests. The people they talk to are having problems, so they only hear complaints.

Your sales team is out hyping the best features and are interacting with decision-makers who typically don’t understand (or care to understand) the nuts-and-bolts of the software.

So when it comes time to discuss a new feature or enhancement, everyone has different perspectives and priorities. Unfortunately, it’s usually the biggest title that wins the debate in these circumstances.

Ideally, you should invest in a full user research process. The best way to understand your users and their needs is by direct observation: observe them solving the problems the planned feature-set is attempting to solve. You’ll gain a stronger understanding of the problem and an even broader understanding what your solution must do in order to be successful.

Barring that, though, there is a shortcut that can help reduce conflict from the many different stakeholders. This method isn’t intended to replace actual user research from an impartial third-party. Rather, it will help reduce internal conflict and create a better sense of empathy for all the possible customers, users, and visitors.

Step 1: Define a Product Brief

The product manager or owner should create a one-page product brief for the project. Share the Product Brief with the relevant stakeholders and subject matter experts.

Step 2: Conduct 1:1 Interviews

The product manager conducts 1:1 interviews with the stakeholders and subject matter experts. Review the product brief with them and then ask them about examples of real world examples of customers, users, or visitors that will be interested in the planned feature.

Your goal is to understand the stakeholders perceptions about the user. This point cannot be emphasized enough. Through this process you will gain insight into the mental model that your stakeholders are making decisions about the features they need in order to call the project a success.

At the end of each interview, you should understand your stakeholders perceptions about

1. Why they think the example users would be interested in the feature

2. How they think the feature will make the example customers lives easier

3. Their understanding of the example customers technographic profile (if they have one)

Step 3: Create and Organize User Profiles

Based on your interviews, create a series of user profiles that document the assumptions that your stakeholders and subject-matter experts hold about the users, customers, and visitors. These are not full personas and, as such, should avoid any semblance of color or extraneous detail that is not grounded in some form of direct user observation.

Profiles are very similar to Personas. They just lack a lot of the detail found in most research-based personas. As such, you can use any of the Persona templates found online at sites like usability.gov.

Once you have created the user profiles, group similar ones together and see if you can reduce the number of profiles.  

(One important note about the Profiles. If you are concerned about people relying too heavily on them as prototypical users (personas), refer to them as “Assumptive Profiles”.)

Step 4: Review

Invite all the SMEs and stakeholders to discuss the user needs based on the groupings that the you have created.

The product manager should review each set separately, identifying the source of the different profiles. An example:

In my interviews with Joe and Sally, you both mentioned how different clients were frustrated because they couldn’t sort the report in the way they wanted. Apparently, they spend hours every week downloading the Excel format of the data just so they can sort it the way they need to. I’ve captured that as part of Alex’s profile. Let me show you...

By the end of this meeting, you should drive for a general consensus and approval of the profiles.

Step 5: Profit!

Ideally, at this point, you have a well-defined list of customers -- potentially whose needs and goals have been prioritized. Proceed to define requirements or write your RFP as normal, referencing these profiles when needed to resolve disputes or help clarify design and implementation direction.

While you can’t track every requirement back to a specific user need (your understanding of user needs isn’t nearly this exact), you can at least identify which user needs you think a requirement or specification will be important. And, ideally, all stakeholders will be on the same page about the assumption; and, if not, you can always refer back to their approval of the profiles.

In other words, you’re still guessing, but this process should help clarify some of the unspoken assumptions about our users that can trip us up throughout the planning and development processes.