The Scope of User Experience

“In my practice, I have a laundry list of deliverables or services I can offer to a prospect. I use this list in several ways:

• as a checklist to remind me of the various services I could offer—Of course, I need to consider whether a given service might be appropriate to the project.
• to consider the cost associated with each service—My firm might not be competitive in all areas, so if the prospect’s needs bias toward services I’m not tuned to deliver, I can quickly refer them to others who might be more suitable.
• as a way of engaging the prospect in a conversation about their needs—Do they really need ‘wireframes and redlines,’ or do they, for example, actually have a more fundamental need to improve developer understanding of the desired experience?
• as the scaffolding for scope management—If I win the prospect’s business, we need to agree on the services up front, but each of us reserves the right to review those services as we move into the project. By keeping the full list of services in plain view from start to finish, we—the client and my consultancy Phase II—can manage the project’s scope transparently.”

Defining Project Scope

“There are essentially two ways of defining scope,” answers Jordan. “You can define project scope based on:

1. Best practices—In the project-management world, people generally refer to taking this approach as a time-and-materials project. Such projects have a specific goal such as: create a Web site. User Experience is an important component of building a Web site, but the term User Experience can cover a multitude of different processes and deliverables. Most project managers don’t have the expertise to propose a detailed list of UX tasks that you should include on a given project. The best project managers request a proposal from the UX professional who is assigned to the project. In such cases, you can propose whatever you think is the best approach. You’ll likely have to refine and adjust your proposal until the team and clients are all aligned.
2. An allocated budget—This is what we call a fixed-budget project. In such cases, you’ll likely receive a budget that stakeholders have allocated to the UX-design portion of the project. Again, User Experience could mean almost anything to them, so defining what’s in scope is important. Having a budgetary constraint—or even a timeline constraint—can help you determine what UX activities could be in scope and what couldn’t possibly be in scope. For instance, if a software project allocated $10,000 to the UX portion of a project, that budget is unlikely to support usability testing. The great thing about fixed-budget projects is that they’re often based on an annual or quarterly client budget—meaning, there are often additional funds available for a good reason. With projects like these, it’s tempting to offer only services and deliverables that fall within the allocated budget—as opposed to what’s right or desirable for a project. I’ll often propose what fits within the budget, then also provide the business case for doing anything that isn’t within the budget. For instance, if usability testing would be desirable, I’ll write a business case outlining the value it could bring to the table along with its associated costs. Most of the time, clients won’t find the extra money or time, but sometimes they do, and they always appreciate the advice.”

Do You Really Need to Answer This Question?

“Short answer: you don’t need to,” says Cory. “There are two factors at play here:

1. What work needs to get done—This includes both activities that fall under the umbrella of User Experience and, more generally, anything else that is necessary to complete the project.
2. What skills you or your team must possess to get the work done—If you have the time and inclination to do certain work—whether it’s a core UX activity, a more tangential UX activity, or a task that’s completely unrelated to User Experience—do it to get the project completed. If neither you nor your team has the right skills to do any work that needs doing, either start building up those skills internally, bring on someone who has the right skills, or contract out that specific aspect of your project.”

What’s Under the UX Umbrella?

“There are lots of ways to read this question,” concludes Adrian. “Because the answer is easy, I’m going with this interpretation: which of these practices should User Experience own? The answer: I don’t care.

“The list of things that sit under the UX umbrella has always been too large for any individual to be equally good at all of them. The job titles and roles of the people who perform UX activities has changed over the last 25 and will likely change again over the next 25 years.

“I do not care whether Customer Experience, User Experience, or Product Management owns customer interviewing. I don’t care whether somebody whose job title is User Researcher, UX Designer, Product Manager, or Startup Founder conducts the interviews.

“I care that people understand when and where customer interviewing is necessary. I care that it is done well. I care that the team acts on the learnings from customer interviews.”

“The discipline of User Experience is expansive,” agrees Pabini. “When I redesigned the UXmatters Web site in 2016, I created an infographic representing what were then the professions that fell under this discipline. That infographic provides the backdrop for our site’s home page. Since then, the discipline of User Experience has continued to grow, adding new specialties such as design ops and research ops. We’ve also seen the emergence of more fine-grained specialties such as motion design, which some might simply consider a subset of graphic design. As the software industry continues to evolve, I’m sure User Experience will adapt to meet its needs—and that likely means we’ll see more new UX specialties in the future.”