Jump to content

Plasma/PURP

From KDE Community Wiki
Revision as of 21:14, 31 July 2010 by Aseigo (talk | contribs) (Created page with '= Plasma User Research Profile = Short summary description of the purpose of the application, who it is for, and what those people can do with it. == Who is the application for...')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Plasma User Research Profile

Short summary description of the purpose of the application, who it is for, and what those people can do with it.

Who is the application for?

  • List of types (groups) of users
  • User groups can be organized based on any type of dimension
  • Some groups may be broken down in to sub groups

(Who is the application not for)

  • Sometimes it is easy to identify who the application is not for
  • This can help keep the scope of the project under control

Sample User Profiles

User Profile 1: For each group of users identified (or primary groups, or particularly special groups if many groups are defined), write a description of that user's characteristics based on a real user you know.

What kinds of tasks will they complete

  • List of common tasks users will complete
  • This does not have to be a complete functional specification, but major tasks and specialty tasks should be listed
  • Include functionality that is planned but not yet implemented to help keep the future in focus

(What kinds of functionality will the application not support)

  • List tasks or functionality the application will not address
  • Sometimes it is useful to list this unintended functionality to help keep the scope of the application
  • For example, a certain functionality may not be implemented because it is out of scope with the primary goals of the project, another application with a different focus does it better, or it is an extreme edge case for a user type which is not primary

Sample Use Scenarios and Cases

Use Scenario 1: For each task identified (or major tasks, or particularly special tasks if many tasks are defined), write a description of how that user would accomplish the task independent of how they would complete it within the application.

Use Case 1: If a use scenario has been implemented, include a matching use case which describes how the task use scenario can be completed in the application. There may be branching or multiple ways to complete the task, and this is a good way to document it.

Environment Conditions & Requirements

  • List of environmental conditions for the user or the application to consider
  • For example, an Internet-capable application would require an Internet connection