Projects/Okular/User Research Profile: Difference between revisions

From KDE TechBase
No edit summary
(Replaced content with "{{ Moved To Community | Okular }}")
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Okular User Research Profile =
{{ Moved To Community | Okular }}
 
: Short summary description of the purpose of the application, who it is for, and what those people can do with it.
 
Okular is a document viewer. It allows people to read documents ...
 
== 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

Latest revision as of 18:21, 11 March 2016

This page is now on the community wiki.