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
Content Requirements
Much of the time, when we talk about content, we’re referring to text. But images, audio, and video can be more important than the accompanying text. These different content types can also work together to fulfill a single requirement. For example, a content feature covering a sporting event might have an article accompanied by photographs and video clips. Identifying all the content types associated with a feature can help you determine what resources will be needed to produce the content (or whether it can be produced at all).
Don’t get confused between the format of a piece of content and its purpose. When discussing content requirements with stakeholders, one of the first things I usually hear is, “We should have FAQs.” But the term FAQ really only refers to a content format: a simple series of questions and answers. The real value of an FAQ to users is that it provides ready access to commonly needed information. Other content requirements can fulfill that same purpose; but when the focus is on the format, the purpose itself can be forgotten. More often than not, FAQs neglect the “frequently” part of the equation, offering instead answers to whatever questions the content provider could think of to satisfy the FAQ requirement.
The expected size of each of your content features has a huge influence on the user experience decisions you will have to make. Your content requirements should provide rough estimates of the size of each feature: word count for text features, pixel dimensions for images or video, and file sizes for downloadable, stand-alone content elements like audio files or PDF documents. These size estimates don’t have to be precise—approximations are fine. We only have to collect the essential information needed to design an appropriate vehicle for that content. Designing a site to provide access to small thumbnail images is different from designing a site to provide access to full-screen photographs; knowing in advance the size of the content elements we have to accommodate enables us to make smart, informed decisions along the way.
It’s important to identify who will be responsible for each content element as early as possible. Once it has been validated against our strategic objectives, any content feature inevitably sounds like a really good idea—as long as someone else is responsible for creating and maintaining it. If we get too deep into the development process without identifying who will be responsible for every required content feature, we’re likely to end up with gaping holes in our site because those features everybody loved when they were hypothetical turned out to be too much work for anyone to actually take on.
And that’s what people often forget when developing requirements: Content is hard work. You might be able to hire on contract resources (or, more likely, stick someone down in marketing with the job) to create the content in time for the initial launch, but who will keep it up to date? Content—well, effective content, anyway—requires constant maintenance. Approaching content as if you can post it and forget it leads to a site that, over time, does an increasingly poor job of meeting user needs.
This is why, for every content feature, you should identify how frequently it will be updated. The frequency of updates should be derived from your strategic goals for the site: Based on your product objectives, how often do you want users to come back? Based on the needs of your users, how often do they expect updated information? However, keep in mind that the ideal frequency of updates for your users (“I want to know everything instantly, 24 hours a day!”) may not be practical for your organization. You’ll have to arrive at a frequency that represents a reasonable compromise between the expectations of your users and your available resources.
If your site has to serve multiple audiences with divergent needs, knowing which audience a piece of content is intended for can help you make better decisions about how to present that content. Information intended for children requires a different approach from information intended for their parents; information for both of them needs yet a third approach.
For projects that involve working with a lot of existing content, much of the information that will feed your requirements is recorded in a content inventory. Taking an inventory of all the content on your existing site may seem like a tedious process—and it usually is. But having the inventory (which usually takes the form of a simple, albeit very large, spreadsheet) is important for the same reason that having concrete requirements is important: so everyone on the team knows exactly what they have to work with in creating the user experience.