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 the Scope
We do some things because there’s value in the process, like jogging or practicing scales on the piano. We do other things because there’s value in the product, like making a cheesecake or fixing a car. Defining the scope of your project is both: a valuable process that results in a valuable product.
The process is valuable because it forces you to address potential conflicts and rough spots in the product while the whole thing is still hypothetical. We can identify what we can tackle now and what will have to wait until later.
The product is valuable because it gives the entire team a reference point for all the work to be done throughout the project and a common language for talking about that work. Defining your requirements drives ambiguity out of the design process.
I once worked on a Web application that seemed to be in a state of perpetual beta: almost, but not quite, ready to roll out to actual users. A lot of things were wrong with our approach—the technology was shaky, we didn’t seem to know anything about our users, and I was the only person in the whole company who had any experience at all with developing for the Web.
But none of this explains why we couldn’t get the product to launch. The big stumbling block was an unwillingness to define requirements. After all, it was a lot of hassle to write everything down when we all worked in the same office anyway, and besides, the product manager needed to focus his energy on coming up with new features.
The result was a product that was an ever-changing mishmash of features in various stages of completeness. Every new article somebody read or every new thought that came along while somebody was playing with the product inspired another feature for consideration. There was a constant flow of work going on, but there was no schedule, there were no milestones, and there was no end in sight. Because no one knew the scope of the project, how could anyone know when we were finished?
There are two main reasons to bother to define requirements.
Reason #1: So You Know What You’re Building
This seems kind of obvious, but it came as a surprise to the team building that Web application. If you clearly articulate exactly what you’re setting out to build, everyone will know what the project’s goals are and when they’ve been reached. The final product stops being an amorphous picture in the product manager’s head, and it becomes something concrete that everyone at every level of the organization, from top executives to entry-level engineers, can work with.
In the absence of clear requirements, your project will probably turn out like a schoolyard game of “Telephone”—each person on the team gets an impression of the product via word of mouth, and everyone’s description ends up slightly different. Or even worse, everyone assumes someone else is managing the design and development of some crucial aspect of the product, when in fact no one is.
Having a defined set of requirements allows you to parcel out responsibility for the work more efficiently. Seeing the entire scope mapped out enables you to see connections between individual requirements that might not otherwise be apparent. For example, in early discussions, the support documentation and the product spec sheets may have seemed like separate content features, but defining them as requirements might make it apparent that there’s a lot of overlap and that the same group should be responsible for both.
Reason #2: So You Know What You’re Not Building
Lots of features sound like good ideas, but they don’t necessarily align with the strategic objectives of the project. Additionally, all sorts of possibilities for features emerge after the project is well underway. Having clearly identified requirements provides you with a framework for evaluating those ideas as they come along, helping you understand how (or if) they fit into what you’ve already committed to build.
Knowing what you’re not building also means knowing what you’re not building right now. The real value in collecting all those great ideas comes from finding appropriate ways to fit them into your long-term plans. By establishing concrete sets of requirements, and stockpiling requests that don’t fit as possibilities for future releases, you can manage the entire process in a more deliberate way.
)
If you don’t consciously manage your requirements, you’ll get caught in the dreaded “scope creep.” The image this always brings to mind for me is the snowball that rolls forward an inch—and then another—picking up a little extra snow with each turn until it is barreling down the hill, getting bigger and harder to stop all the way down. Likewise, each additional requirement may not seem like that much extra work. But put them all together, and you’ve got a project rolling away out of control, crushing deadlines and budget estimates on its way toward an inevitable final crash.