Human-Computer-Interaction Summary 1

In the Human-Centered design process

After understanding and specify context of use, the specify user requirements:

A statement about an intended product that specifies what it is expected to do or how it will perform it.
Examples: For a map application, the requirement could be that the time to load the map must be less than half a second, or for a smartwatch, the requirement could be that the interface should be made attractive for teenagers.

Helps us tell the developers what to build.
Allows users to verify and contribute towards the development.
Overall advancing our goal to build usable system and one that meets the needs of people.

Happens iteratively and could be gathered from different stages of HCD process.
Over a period of time, requirements could change completely. For example, our requirements from our smartphone today are very different from early phones such as landline phone and early cell phones.

Functional (what people need)
1. Describe what the product will do.
2. E.g., new video game
3. Client wants a beginner level squash video game that supports signle or two-players.
4. Has to capture player data continuously.
Non-functional (what people expect)
1. Describe the constraints (physical, logical, semantic, culture, technical) and aesthetics style.
2. E.g., new video game
3. End-users would expect the game works on Xbox if found on Xbox store.
4. Client expects that the gameplay and aesthetics of the game should be modern.

Secondary research: Read patents and research articles that explain in detail how systems have been developed and also do a good job outlining the rationale.
Study existing products and systems.
Interact with potential end-users: Engage in UX research using methods such as interviews, surveys, diary studies, ethnography and other methods.

A method to identify meaningful tasks that people want to or have to accomplish using a system, and
Using those tasks to propose new ideas or improvements for UI design.

Say what the user wants to do but does not say how they would do it.
a. No assumptions made about the interface.
b. No mention of the interface in the task helps designer brainstorm all potential options for UI.
Are very specific.
a. Say exactly what the user wants to do.
b. Specify actual information the user would somehow want to input.
c. Helps designers think through the types of inputs the system will need to process and perhaps store.
Describe a complete job.
a. Tell designers about how information flows through the system.
i. Where does information come from?
ii. Where does it go?
iii. What has to happen next?
b. Ask designers to consider how many system features are required and how they will work with each other.
Say who the users are.
a. Helps the designer understand who will be using the system, how and their context of use.
As a set, cover a range of possibilities.
a. The potential users of the systems-primary occasional and least likely to use the system.
b. Types of tasks – routine important but infrequent, unexpected, or rarely performed.

Designs can rarely handle everyone; we typically need feature-level customization to reach a broad audience.