The Elements of User Experience: The Scope Plane: Functional Specifications and Content Requirements
- Defining the Scope
- Functionality and Content
- Defining Requirements
- Functional Specifications
- Content Requirements
- Prioritizing Requirements
This chapter is from the book
This chapter is from the book
This chapter is from the book
Functionality and Content
On the scope plane, we start from the abstract question of “Why are we making this product?” that we dealt with in the strategy plane and build upon it with a new question: “What are we going to make?”
)
The split between the Web as a vehicle for functionality and the Web as an information medium starts coming into play on the scope plane. On the functionality side, we’re concerned with what would be considered the feature set of the software product. On the information side, we’re dealing with content, the traditional domain of editorial and marketing communications groups.
Content and functionality seem just about as different as two things could be, but when it comes to defining scope, they can be addressed in very similar ways. Throughout this chapter, I’ll use the term feature to refer to both software functions and content offerings.
In software development, the scope is defined through functional requirements or functional specifications. Some organizations use these terms to mean two different documents: requirements at the beginning of the project to describe what the system should do, and specifications at the end to describe what it actually does. In other cases, the specifications are developed soon after the requirements, filling in details of implementation. But most of the time, these terms are interchangeable—in fact, some people use the term functional requirements specification just to make sure they’ve covered all the bases. I’ll use functional specifications to refer to the document itself, and requirements to refer to its contents.
The language of this chapter is mostly the language of software development. But the concepts here apply equally to content. Content development often involves a less formal requirements-definition process than software does, but the underlying principles are the same. A content developer will sit down and talk with people or pore over source material, whether that be a database or a drawer full of news clippings, in order to determine what information needs to be included in the content she’s developing. This process for defining content requirements is actually not all that different from the technologist brainstorming features with stakeholders and reviewing existing documentation. The purposes and approaches are the same.
Content requirements often have functional implications. These days, pure content sites are usually handled through a content management system (CMS). These systems come in all shapes and sizes, from very large and complex systems that dynamically generate pages from a dozen different data sources to lightweight tools optimized for managing one specific type of content feature in the most efficient way. You might decide to purchase a proprietary content management system, use one of the many open-source alternatives, or even build one from scratch. In any case, it will take some tinkering to tailor the system to your organization and your content.
)
The functionality you need in your content management system will depend on the nature of the content you’ll be managing. Will you be maintaining content in multiple languages or data formats? The CMS will need to be able to handle all those kinds of content elements. Does every press release need to be approved by six executive vice presidents and a lawyer? The CMS will need to support that kind of approval process in its workflow. Will content elements be dynamically recombined according to the preferences of each user, or the device they are using? The CMS will need to be able to accomplish that level of complex delivery.
Similarly, the functional requirements of any technology product have content implications. Will there be instructions on the preferences configuration screen? How about error messages? Somebody has to write those. Every time I see an error message on a Web site like “Null input field exception,” I know some engineer’s placeholder message made it into the final product because nobody made that error message a content requirement. Countless allegedly technical projects could have been improved immeasurably if the developers had simply taken the time to have someone look at the application with an eye toward content.