User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
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.
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:
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.
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...
