Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

Do you include user requirements in the same document as in individual personas or do you keep them in separate files?

In a typical persona document you explain the motivations behind the visit, usually i a broad sense and connect a scenario to those motivations while a user requirement document is usually more detailed such as a list of tasks. The persona document could therefore be several pages long.

share|improve this question
1  
Are these requirements stated by the users? Or are they a list of 'requirements' that map to functions and features based on an interpretation of user needs? –  Jay Sep 10 '12 at 10:44
    
To avoid any misunderstanding, can you clarify what you mean by 'user requirements' in your context, perhaps with examples. –  Roger Attrill Sep 10 '12 at 15:34
add comment

2 Answers 2

Including the user's goals is absolutely important in creating a persona document, however I would be wary of including lower level, software requirements style information in documents.

Real users are rarely looking for enumerated lists of features like:

  • 32 bit OS support
  • Windows or Mac
  • 500 ms response time

etc. Instead, personas are made to help you step back and consider the users and what they're doing, not just how the big wigs/requirements document/etc have laid out what the product needs.

Now, Personas, user goals and scenarios aren't a substitute for technical requirements either. Sometimes just because users don't care about (or often more accurately, don't know that they care about) certain things doesn't mean they're not important. An example from Personas: Moving Beyond Role-Based Requirements Engineering:

Scenarios are good at describing and analyzing functional behavior of the system. However, there are better ways to describe the nonfunctional or quality of service (QoS) requirements.

One form of these QoS requirements center on security. Other QoS requirements focus as constraints on scenarios such as performance, load, and stress requirements.

Application security has been a recent focus.
Seventy-five percent of system security breaches have occurred at the application level...

Some stuff like security you need separate requirements from your personas; the fact that you need AES 256 security doesn't fit with a persona, even if it's important to protecting all personas. I strongly suggest you give Personas: Moving Beyond Role-Based Requirements Engineering a read. It's got lots more good information on using Personas to help build requirements.

share|improve this answer
add comment

In theory, personas help determine requirements, so they should live in their own document long before a requirements document exists. Even if you already know some requirements going into a project (for instance, senior management has already decided to make a Windows-only product), personas aren't the place for those; personas define the users, not the solutions.

That said, if you're just asking whether it's okay to merge your persona and requirements documents once you have them both, I'd say it depends on whether people reading those documents would find it helpful. It's certainly easier to pass around one link rather than two and you're not going to violate any sacred UX practices by merging them... that I know of...

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.