The Elements of User Experience: The Scope Plane: Functional Specifications and Content Requirements
This chapter is from the book
This chapter is from the book
This chapter is from the book
Defining Requirements
Some requirements apply to the product as a whole. Branding requirements are one common example of this; certain technical requirements, such as supported browsers and operating systems, are another.
Other requirements apply only to a specific feature. Most of the time when people refer to a requirement, they are thinking of a short description of a single feature the product is required to have.
The level of detail in your requirements will often depend on the specific scope of the project. If the goal of the project is to implement one very complex subsystem, a very high level of detail might be needed, even though the scope of the project relative to the larger site might be quite small. Conversely, a very large-scale content project might involve such a homogeneous base of content (such as a large number of functionally identical PDFs of product manuals) that the content requirements can only be very general.
The most productive source for requirements will always be your users themselves. But more often, your requirements will come from stakeholders, people in your organization who have some say over what goes into your product.
In either case, the best way to find out what people want is simply to ask them. The user research techniques outlined in Chapter 3 can all be used to help you get a better understanding of the kinds of features users want to see in your product.
Whether you are defining requirements with help from stakeholders inside your organization or working directly with users, the requirements that come out of the process will fall into three general categories. First, and most obvious, are the things people say they want. Some of these are very clearly good ideas and will find their way into the final product.
Sometimes the things people say they want are not the things they actually want. It’s not uncommon for anyone, when they encounter some difficulty with a process or a product, to imagine a solution. Sometimes that solution is unworkable, or it addresses a symptom rather than the underlying cause of the problem. By exploring these suggestions, you can sometimes arrive at completely different requirements that solve the real problem.
The third type of requirement is the feature people don’t know they want. When you get people talking about strategic objectives and new requirements that might fulfill them, sometimes they’ll hit upon great ideas that simply hadn’t occurred to anyone during the ongoing maintenance of the product. These often come out of brainstorming exercises, when participants have a chance to talk through and explore the possibilities for the project.
Ironically, sometimes the people most deeply involved in creating and working with a product are the ones least able to imagine new directions for it. When you spend all your time immersed in maintaining an existing product, you can often forget which of your constraints are real, and which are simply products of historical choices. For this reason, group brainstorming sessions that bring together people from diverse parts of the organization or represent diverse user groups can be very effective tools in opening the minds of participants to possibilities they wouldn’t have considered before.
Getting an engineer, a customer service agent, and a marketing person in a room together to talk about the same Web site can be enlightening for everyone. Hearing unfamiliar perspectives—and having the opportunity to respond to them—encourages people to think in broader terms about both the problems involved in developing the product and the possible solutions.
Whatever device we are designing for—or if we are designing the device itself—our feature set will need to take into account hardware requirements, too. Does the device have a camera? GPS? Gyroscopic position sensors? These considerations will inform and constrain your functional possibilities.
Generating requirements is often a matter of finding ways to remove impediments. For example, assume that you have a user who has already decided to purchase a product—they just haven’t decided if your product is the one they will buy. What can your site do to make this process—first selecting your product, and then buying your product—easier for them?
In Chapter 3, we looked at the technique of creating fictional characters called personas to help us better understand user needs. In determining requirements, we can use those personas again by putting our fictional characters into little stories called scenarios. A scenario is a short, simple narrative describing how a persona might go about trying to fulfill one of those user needs. By imagining the process our users might go through, we can come up with potential requirements to help meet their needs.
We can also look to our competitors for inspiration. Anyone else in the same business is almost certainly trying to meet the same user needs and is probably trying to accomplish similar product objectives as well. Has a competitor found a particularly effective feature to meet one of these strategic objectives? How have they addressed the same trade-offs and compromises we face?
Even products that aren’t direct competitors can serve as fertile sources for possible requirements. Some gaming platforms, for example, offer users the ability to create social groups of fellow players. Adopting or building on their approach when scoping a similar feature for our digital video recorder may give us an advantage over our direct competition.