Task4 - dfdds PDF

Preview

Summary

dfdds...

Description

Faculty of Science, Engineering and Technology

User-Centred Design Task 4.1P User model ILO

Demonstrate an explicit understanding of software context of use (i.e., users, tasks and system environment) using a variety of models.

Purpose:

Users are a key component of context of use, the characteristics of a user (such as their previous experience with an app or particular hardware, job role, and motivation to use an app etc) can have a big impact on how they interact with an interface. Having a good understanding of our users is therefore important. While our interview data can reveal a lot about the user, it is not practical to be continually consulting the interview data. A persona is a way of capturing user data in a way that is explicit and easily accessible for the entire team.

Group Task:

Summarise the main features of the major user groups and their role in the system. Use a persona to represent a major user group.

Resources:

Lecture Notes: Topic 05: Requirements, Topic 06: Modelling Textbook: Harstson & Pyla Section 7.5, Stone et al Chapter 3 and 4 UCD Project Interview Data, your own data from background research

To be marked as Complete your submission must have:

A Persona that represents one of the Project user groups (see UCD User Interface Design Project and UCD Project Description task, UCD Project Interview Data) and includes: ■ name of persona and headshot of a person that is representative of user group ■ description of key user characteristics (e.g., previous experience and skills, technology use, motivation to use etc) and concerns (describes broad goals of the user in relation to the system, but no detail about tasks) ■ quote from interview data that captures key user concern/s ■ gives the reader a good feel for the user group (generates empathy and understanding of the user group) One or more requirements: ■ identify at least one requirement (must be based on information in the persona) ■ requirement/s are ■ requirement has a name and a reference number ■ expressed clearly and unambiguously ■ single issue per requirement ■ requirement statement does not specify implementation ■ requirements are written with ‘shall’ or ‘must’ ■ a rationale is provided ■ note is optional

Warning:

Task must be based on information in UCD Interview Data or other data sourced from published research (provide full reference for all sources). Do NOT make up or use ‘fake’ data for any UCD submission.

User-Centred Design

Overview In this task you will need to show that you have a good understanding of who the users are and their major concerns in relation to the Project. A good persona captures the typical characteristics of the user group. A persona does not represent one particular user, rather it should represent the entire user group. 1. Document the typical characteristics of one of the Project user groups using a persona. The persona should: ■

Include a name; ■

Do not use the name of a person known to anyone on team, or one of the interview participants, or of a famous person (because this could cause bias)

■

Make the name culturally appropriate, but do not use a very generic name (e.g., John Smith, Jane Doe)

Page 2 of 4

User-Centred Design

■

Include a head shot of the user (can be a sketch)

■

Demonstrate the user’s characteristics, and concerns including motivations and attitude towards the system.

Note: Your personas will be used again in the following Tasks: ■

Conceptual Design Task (where they will play a staring role in your design scenarios)

■

Rapid Expert Evaluation Task (where they will help someone reviewing your prototype understand who the users are), and

■

Demographic Questionnaire (to help you write a questionnaire to for identifying representative users for your usability evaluation).

3. Identify one or more requirements based on the user’s characteristics or concerns. Make sure that the rationale for the requirement is based on user related data. Suggested user requirement format: Name of major feature or category Number of requirement and Name of second level feature or category Requirement statement: [with source if possible] Rationale (if useful): Rationale statement Note (optional): Commentary about requirement Requirement examples: 1 Hardware requirements 1.1 Location of Kiosk Requirement: The kiosk will be located in small shopping centres in suburbs with poor internet services. [1-13]* Rationale: Service is most useful to those who do not have a good internet connection. User is a frequent visitor to shopping centres. Note: May be worth checking the number of visitors to centre when choosing a site. 2 Usability requirements 2.1 Efficiency Requirement: The user shall be able to hire a movie in under 1 minute. [1-23, 2-4, 3-05]* Rationale: The user is busy and has small children, they need to complete the hire quickly to minimise waiting time for child. Note: User may be distracted by small children * Reference numbers for interview data (transcript not provided in this example). Page 3 of 4

User-Centred Design

Note: The requirement statement must NOT specify how the feature is implemented. You can make a suggestion for how it might be implemented in the note, but not the requirement itself.

Page 4 of 4...