- Where Do We Begin?
- Deconstructing Subjects
- Getting Started
- Talking to the Users
- Overcoming Objections
- Defining Problems Before Solutions
This chapter is from the book
This chapter is from the book
This chapter is from the book
Defining Problems Before Solutions
Domain research has a different focus than the UX research you may have encountered before. A good UX researcher attempts to understand user needs and clarify business requirements. Their goal is to understand the problem before the team sets about designing a solution. UX research reveals a product’s most-used features and pain points. It shows the broader context that leads people to engage with your product in the first place.
We could have written a whole book on research alone. But it would have been nowhere near as good as Steve Portigal’s Interviewing Users (Rosenfeld Media) or Erika Hall’s Just Enough Research (A Book Apart). Instead, we’ve focused on the exercise of gathering information about your subject domain.
Domain research lays the groundwork for content structure. Your content implicitly or explicitly supports the concepts and relationships inherent in a topic. These are the foundations that drive your structural design.
Most of the time, you’re not designing for yourself. Your expertise is in making useful, usable digital products—and knowing who to lean on for insight. Domain experts help you understand the rules, exceptions, and tricky parts of your subject. Users tell you what’s most important to cover. As we’ll go on to explore, this research funnels into the construction of a domain model. In turn, this model guides how you’ll segment and structure content. Up-front research may seem time-consuming, but you need it to make sure your product serves the real-world domain. Addressing misunderstandings during research is much, much cheaper than waiting until later.
Domain research exposes the territory you intend to map. Sharing this research with stakeholders shows them where you’re headed. This may lead to discussion, negotiation, or even heated debate over the boundaries of the subject area. Better that this happens now rather than later. As you align on the subject domain, you fix on a crucial point of agreement. Even if you decide not to follow a structured content approach, do yourself a favor and get everyone on your team to agree on the shape of the domain. It’s like a save point in a videogame. No matter how much you argue later about the specifics of content or interface design, there’s always a safe place to get back to. But more on that teamwork in Chapter 5.
Overcoming your own bias, or that of your stakeholders, is always challenging. You’ll likely come to the project with an idea of how it should turn out. That’s no bad thing, but see it for what it is—an assumption about what success looks like. Research helps you challenge your assumptions and make adjustments. Research gets you answers. But it also uncovers new questions. You’re asking your experts and users to tell you how their world works. Their answers can be unexpected, and that gives more and more insight into the problem space.
In practice, your research interviews will be a little messy. Often, your experts are also stakeholders. Your users may be keener to talk feature requests than to analyze the components of a subject. Conversations will mix domain research with a broader exploration of needs and opportunities. Keeping people on-topic is difficult. Recognize that every critique or request is a way of people expressing what’s important to them. Probe deeper and find the desire hiding behind the feature suggestion.
Through domain research, you’ll listen and observe. You’ll build understanding. You’ll build relationships with people you can call on again throughout the project. You’ll gain empathy for your users, your experts, and, above all, the subject itself.
