For those of you who have sat down to write requirements, you’ll know that it is no fun. As much as I don’t like writing requirements for a project, I have to grudgingly accept how important it is. Content requirements are nothing but planning. It’s a part of the planning phase, that we can’t do without.
Content requirements can include task flows,user behavior that leads to different task flows, features based on priority, etc. All these are formulated from user needs and business goals. To make the document, one could perform research activities such as interviewing users, conducting focus groups, customer journey mapping and so on. During my internship, where the UX team’s primary focus was redesigning the current software, in order to write requirements, the team tested the current product with actual users to identify pain points and opportunity spaces. We also did competitive and comparative analysis, by testing other products to understand what works and what doesn’t. Richard Caddick and Steve Cable’s Communicating The User Experience talks about the many ways to create ‘content requirements’ for a project.
The why? It’s understood that the reason for the amount of research undertaken to produce the document is to create a user-centered design; it involves the user in the creation process. But it also serves to have a common ground between different teams within an organization, between stakeholders and clients and even between members of the same time. When the actions and tasks are clearly spelled out, it is an attempt to eliminate confusions and discrepancies that could possibly arise during the designing and development phases.