User:Andrew/HIG/ConceptualModel: Difference between revisions

From KDE UserBase Wiki
No edit summary
 
(6 intermediate revisions by the same user not shown)
Line 1: Line 1:
__NOTOC__
__NOTOC__
= Conceptual Model =
= Concept =
The conceptual model is the most fundamental aspect of the interface, describing the relationship between the interface and the outside world. The purpose of the conceptual model is to draw on the user’s past experiences so they can readily understand basic operations and accurately predict functionality.
The conceptual model is the most fundamental aspect of the interface, describing the relationship between the interface and the outside world. The purpose of the conceptual model is to draw on the user’s past experiences so they can readily understand basic operations and accurately predict functionality.


== Project vision ==
== Project vision ==
A vision describes the goal of the project. It can be emotive and a source of inspiration, for instance by outlining how the final product makes the world a better place.
A vision describes the goal of the project. It can be emotive and a source of inspiration, for instance by outlining how the final product makes the world a better place. Describe the project's final goals. Explain who will use the product, and how he or she will take advantage of it. Make sure the vision is shared between all project stakeholders. Leave room in the vision for creativity. Keep it short.  
 
Describe the project's final goals. Explain who will use the product, and how he or she will make advantage of it. Make sure the vision is shared between all project stakeholders. Leave room in the vision for creativity. Keep it short.  


A good starting-point is the ''elevator pitch'':
A good starting-point is the ''elevator pitch'':
Line 17: Line 15:
* OUR PRODUCT <further differentiation>
* OUR PRODUCT <further differentiation>


== The User ==
== Personas ==
Personas can help identify the target users of your application and provide a common understanding among the design and development team. A persona is the representation of a user, based on empirical data. Personas describe the target users, giving a clear picture of how they're likely to use the system, and what they’ll expect from it. The description includes a concise summary of characteristics of the user, their experience, goals and tasks, pain points, and environmental conditions.  
Personas can help identify the target users of your application and provide a common understanding among the design and development team. A persona is the representation of a user, based on empirical data. Personas describe the target users, giving a clear picture of how they're likely to use the system, and what they’ll expect from it. The description includes a concise summary of characteristics of the user, their experience, goals and tasks, pain points, and environmental conditions.  


Line 23: Line 21:


If you do elect to create your own personas, consider the following:
If you do elect to create your own personas, consider the following:
* Always try to define personas based empirical data. Feel free to ask the KDE user experience team (kde-usability at kde.org) for assistance with the collection of empirical data.
* Always try to define personas based on empirical data. Feel free to ask the KDE user experience team (kde-usability at kde.org) for assistance with the collection of empirical data.
* Add enough information to establish a good impression of the target user, but do not write a novel and stay concise.
* Add enough information to establish a good impression of the target user, but do not write a novel and stay concise.
* Common elements are: name, job titles and major responsibilities, demographics such as age, education, ethnicity, and family status, goals and tasks they are trying to complete using the application, physical, social, and technological environment.
* Common elements are: name, job titles and major responsibilities, demographics such as age, education, ethnicity, and family status, goals and tasks they are trying to complete using the application, physical, social, and technological environment.
* Add a quote that sums up what matters most to the persona and a casual picture representing that user group.
* Add a quote that sums up what matters most to the persona and a casual picture representing that user group.
* Discriminate between primary (the basic user) and secondary (additional users) persona. If it makes sense, describe the group of users that is explicitly not supported by a anti-persona. Respect the law of parsimony and have as few personas as possible.
* Discriminate between primary (the basic user) and secondary (additional users) persona. If it makes sense, describe the group of users that is explicitly not supported by a anti-persona. Respect the law of parsimony and have as few personas as possible.
* Make sure your persona can act in different [[Projects/Usability/HIG/Scenario|scenarios]].
* Make sure your persona can act in different scenarios.


== Scenarios ==
== Scenarios ==
Scenarios illustrate how the users achieve their goals by means of a task-orientated example. It is supplementary to a persona, providing together an efficient method applicable in a wide range of applications.
Scenarios illustrate how the users achieve their goals by means of task-orientated examples. It is supplementary to a persona, providing together an efficient method applicable in a wide range of applications.


Use the following guide to help create scenarios:
Use the following guide to help create scenarios:
Line 38: Line 36:
* If available, use real world images to support imagination.
* If available, use real world images to support imagination.
* Try to include problem situations that will test the system concept, not just straightforward scenarios.
* Try to include problem situations that will test the system concept, not just straightforward scenarios.
{{Prevnext2|prevpage=User:Andrew/HIG#Getting_Started|nextpage=User:Andrew/HIG/OrganizationalModel|prevtext=Getting Started|nexttext=Organization|index=User:Andrew/HIG|indextext=Back to HIG}}

Latest revision as of 15:48, 28 September 2014

Concept

The conceptual model is the most fundamental aspect of the interface, describing the relationship between the interface and the outside world. The purpose of the conceptual model is to draw on the user’s past experiences so they can readily understand basic operations and accurately predict functionality.

Project vision

A vision describes the goal of the project. It can be emotive and a source of inspiration, for instance by outlining how the final product makes the world a better place. Describe the project's final goals. Explain who will use the product, and how he or she will take advantage of it. Make sure the vision is shared between all project stakeholders. Leave room in the vision for creativity. Keep it short.

A good starting-point is the elevator pitch:

  • FOR <target customer>
  • WHO <statement of the need>
  • THE <product name>
  • IS A <product category>
  • THAT <key benefit>
  • UNLIKE <primary competitor>
  • OUR PRODUCT <further differentiation>

Personas

Personas can help identify the target users of your application and provide a common understanding among the design and development team. A persona is the representation of a user, based on empirical data. Personas describe the target users, giving a clear picture of how they're likely to use the system, and what they’ll expect from it. The description includes a concise summary of characteristics of the user, their experience, goals and tasks, pain points, and environmental conditions.

The KDE usability team has created predefined personas which we highly recommended using for your project.

If you do elect to create your own personas, consider the following:

  • Always try to define personas based on empirical data. Feel free to ask the KDE user experience team (kde-usability at kde.org) for assistance with the collection of empirical data.
  • Add enough information to establish a good impression of the target user, but do not write a novel and stay concise.
  • Common elements are: name, job titles and major responsibilities, demographics such as age, education, ethnicity, and family status, goals and tasks they are trying to complete using the application, physical, social, and technological environment.
  • Add a quote that sums up what matters most to the persona and a casual picture representing that user group.
  • Discriminate between primary (the basic user) and secondary (additional users) persona. If it makes sense, describe the group of users that is explicitly not supported by a anti-persona. Respect the law of parsimony and have as few personas as possible.
  • Make sure your persona can act in different scenarios.

Scenarios

Scenarios illustrate how the users achieve their goals by means of task-orientated examples. It is supplementary to a persona, providing together an efficient method applicable in a wide range of applications.

Use the following guide to help create scenarios:

  • Always try to create scenarios based on empirical data. Feel free to ask the KDE user experience team (kde-usability at kde.org) for assistance with the collection of empirical data.
  • Take technical configuration, environmental condition, organizational and social aspects into consideration.
  • If available, use real world images to support imagination.
  • Try to include problem situations that will test the system concept, not just straightforward scenarios.