Creating UIs

Planning

How to create a UI?

PlanTestDesign

How to create a UI?

Plan TestDesign

Step 1 Step 3Step 2

How to create a UI?

Plan TestDesign

Step 1 Step 3Step 2

Planning Outline

A. Analyze user and taskB. Consider functionalityC. Conform to the user’s view

Analyze User and Task

Analyze User and Task

The number one principle in design

Focus on the user and their tasks, not the technology.

Planning Outline

A. Analyze user and taskA. Understand UserB. Understand Task

B. Consider functionalityC. Conform to the user’s view

Understand the User

Decide Investigate Collaborate

Understand the User: Decide

Who are you developing the software for?• You can’t develop a solution for ‘everyone.’

• Choose a primary target as the intended user base and focus on them.

• Sometimes customers are different than users.

Understand the User: Investigate

Make an effort to learn about potential users

• Talk to them• Observe them in their natural environment• Talk to their managers• Read about their business

Not just novice vs. experienced

• Avoid classifying novice users as people who have never used a computer.

• Avoid classifying expert users as professional computer engineers.

• A better approach is using independent ‘knowledge dimensions.’

Knowledge Dimensions

• General computer savvy – how much a users knows about computers in general

• Task knowledge – how well does a user perform at the target task

• Knowledge of the system – how well does the user know the specific/similar software product.

Understanding the User: Collaborate

• Don’t treat users as objects to be studied.

• Treat users as experts in their domain.

Understanding the User: Collaborate

Take note of user’s:– experience– management structure– likes – dislikes– motivation

Bringing it all together

Decide Investigate Collaborate

The goal of these three steps is to create user profiles that describe the intended users of the software.

User Profiles

User profiles - A collection of personal data associated to a specific user.

User Profiles

Possible info found in a user profile:• Job description• Job seniority• Education• Salary• Computer skill level• Task/Product skill level

Sample User Profile

• Name : John Doe• Age : 40• Profession : Software Engineer• Job Description : Android UI Development and

meetings to plan/track/improve project.• Computer Skill Level : High. Works with computers

constantly, uses mobile phones and tablets. • Familiarity with task domain : Medium• Interaction with task domain :

User Model

User model – the user’s mental understanding of what the program will do for them.

User Model

• When someone uses a program, they don’t come with a completely blank slate.

• Understanding the user’s knowledge dimensions help designers form a picture of the user’s model.

User Profiles

• Helps designers know what they are aiming at.

• Helpful for deciding what a user would and wouldn’t do.

• Help ground judgments about design choices.

• Basis for usability testing

Analyze User and Task

In order to focus on the user and their tasks, one must understand the intended user by asking:

1. For whom is this software being designed? Who are the intended users? Who are the intended customers (not necessarily the users)?

2. What is the software for? What activity is it intended to support? What problems will it help users solve? What value will it provide?

3. What problems do the intended users have now? What do they like and dislike about the way they work now?

Analyze User and Task

Questions continued:

4. What are the skills and knowledge of the intended users? Are they motivated to learn? How? Are there different classes of users, with different skills, knowledge, and motivation?

5. How do users conceptualize the data that the software will manage?

6. What are the intended users’ preferred ways of working? How will the software fit into those ways? How will it change them?

Planning Outline

A. Analyze user and taskA. Understand UserB. Understand Task

B. Consider functionalityC. Conform to the user’s view

Understand the Task

Decide Investigate Collaborate

Understand the Task: Decide

• Applications are designed to fill a need

• Decide on an application area:– Music– Video– Social Networking

Understanding the Task: Decide

Your application area and target user help yield a specific product category such as,

1. A document editing software for technical writers2. Banking software for bank tellers.

Understand the Task: Investigate

• Learn from the user

• Perform a task analysis

Task Analysis

Learn as much as you can about exactly how the intended users do the tasks that the software is supposed to support.

How to perform a task analysis

• Observe users

• Interview users

• Understand how people perform their task

• Ask users to speculate how they would use your application

Observing vs. Interviewing

• Observation requires interpretation. Sometimes your interpretation can be wrong.

• Interviews provide direct explanations, goals, etc. However, sometimes interviews provide misinformation.

Task Analysis

The goal of task analysis is to develop a thorough understanding of the activities the software will support.

Example Task Analysis Questions

• What is your role in (insert task here)?

• What software do you use to (insert task here)?

• What is involved in (insert task here)?

A good task analysis can answer the following

1. What goals do users want to achieve by using the application?

2. What set of human tasks is the application intended to support?

3. Which tasks are common, and which ones are rare?4. Which tasks are most important, and which ones are

least important?5. What are the steps of each task?6. What are the result and output of each task?7. Where does the information for each task come from?

A good task analysis can answer the following

8. How is the information that results from each task used?9. Which people do which tasks?10. What tools are used to do each task?11. What problems do people have performing each task? 12. What sorts of mistakes are common? What causes

them? How damaging are mistakes?13. What terminology do people who do these tasks use?14. What communication with other people is required to

do the tasks?15. How are different tasks related?

Taken from Designing with Mind in Mind, Chapter 11 Many Factors Affect Learning, Section Task Analysis

A good task analysis can answer the following

• The previous 15 questions are great generic questions to help steer task analysis in the right direction.

• However, they aren’t enough by themselves. You need to dig in and find tasks that are specific to the application domain.

Example Task Analysis for how people prepare a slide show

1. What is your role in producing slide presentations?– Do you produce slides yourself or do you supervise

others who do it?– How much of your total job involves producing slide

presentations?– For whom do you produce these slide presentations?– What quality level is required for the slides?– Do you (your department) follow slide formatting

standards?

Example Task Analysis for how people prepare a slide show

2. What software do you use to create slide presentations?– Who decides what software you use for this?– Do you use one program or a collection of them?– Do you use general-purpose drawing software or slide-

making software?– What do you like and dislike about each of the programs

you use?– What other software have you used, tried, or

considered for making slides, either here or in previous jobs?

Example Task Analysis for how people prepare a slide show

3. What is involved in making slides?– Describe the complete process of producing a

presentation.– Do you reuse old slides in new presentations?– How do you (your department) organize and keep

track of slides and presentations?

Understanding the Task: Investigate

• Think about the application context– Where will it be used?– Where does input come from?– Where does output come from?

• Don’t get tunnel vision and think only of the user’s computer screen

Understand the Task: Collaborate

• Generate two-way feedback with users

• Present preliminary analysis and conclusions to your users and solicit reactions.

• Encourages better working relations with users and might help gain more reliable data

Bringing it all together

• Understanding the tasks requires the same activities as understanding the user.

• Both investigations can be conducted at the same time

Consider Functionality

Planning Outline

A. Analyze user and taskB. Consider functionality

A. Find functionalityB. Develop a conceptual modelC. Perform an Objects and Actions AnalysisD. Define Lexicon

C. Conform to the user’s view

User Interface No No

• GUI developers often put presentation before functionality. DON’T DO IT!

• With that said, don’t put off the UI until the very end.

Find Functionality

• Designers should fully define the concepts and their relationships before they design how to present concepts to the user.

Finding Functionality

• Focus on task-related questions– Questions asked during Task Investigation

Finding Functionality: Concept Visibility

1. What concepts are visible to the user?

2. Are the concepts recognized from the user’s task domain?

3. Can new concepts be presented as familiar concepts?

Finding Functionality: Data

1. What data will the user create, view, or manipulate?

2. What information will users extract from the data?

3. Where will the data come from?

4. Where will the generated data be used?

Finding Functionality: Options

• What choices, settings, and controls will be provided?

• This isn’t about how to PRESENT options, but what their role in the application is. Exp: Day of week, dollar amount, email address, volume level

Putting it all together

• Taking all the data we have collected about the user, user task, and application functionality, we need to capture and organize all available data.

• A recommended approach is to design a conceptual model for the app.

Planning Outline

A. Analyze user and taskB. Consider functionality

A. Find functionalityB. Develop a conceptual modelC. Perform an Objects and Actions AnalysisD. Define Lexicon

C. Conform to the user’s view

Conceptual Model

A model of an application that designers want users to understand.

a Conceptual Model expresses

• The data users can manipulate

• How data is organized

• What users can do with the data

Conceptual Models explain

• The function of the application

• The concepts users need to be aware of in order to use it effectively

A Conceptual Model’s purpose is

• To serve as a plan for designing the details of the system

• To explain to the user how the system works

Mental Model

The user’s understanding of how the system works.

Mental Model

• Not a tangible/visible object that designers can directly interact with

• User’s might not be able to fully describe it

• We must observe the user and try to infer what their mental model is

Subtle Distinction

• Don’t confuse conceptual model with mental model

Mental Model

• Designers aspire for the conceptual model to match the user’s mental model.

• Users with a correct mental model are able to predict what the system will do.

Benefit of a good conceptual model

• Users will be able to use your application efficiently and be able to complete tasks without much effort or thought.

Creating a good Conceptual Model

• Concepts for your model should be ideally taken from your task analysis

• Use familiar concepts that have direct mappings to supported tasks

• Don’t include implementation details or software architecture

• Be wary of new/foreign concepts

Creating a good Conceptual Model

Imagine that you are designing software for creating and managing organization charts. Is an organization chart:

A. a structure of boxes, box labels, box layout, and connector lines or

B. a structure of organizations, sub-organizations, and employees?

New/Foreign Concepts

• New concepts often occur for tasks which previously were not computerized

• New concepts come at a high cost– Adds a concept that task experts aren’t familiar with and must

learn.– As concepts are added, the complexity of the system rises.

• Don’t use foreign concepts that might mislead users

New Concepts

• Use new concepts only when they provide high benefit.

• Less is sometimes more!

Planning Outline

A. Analyze user and taskB. Consider functionality

A. Find functionalityB. Develop a conceptual modelC. Perform an Objects and Actions AnalysisD. Define Lexicon

C. Conform to the user’s view

Objects and Actions Analysis

A declaration of concepts that an application exposes to the user.

Objects and Actions Analysis

• Shows what conceptual objects are exposed to the user

• The actions that can be performed on each object.

• The attributes of each object

• Relationship between objects

Objects and Actions Analysis Example

Designing an application for a simple office calendar application.

Objects1. Calendar2. Event3. To-do-item4. Person

O/A Analysis Calendar App Example

Actions1. Print2. Create3. Change4. View5. Add Event6. Delete Event

O/A Analysis: Attributes

• Metadata for the conceptual object

• Additional details/characteristics

• Etc.

O/A Analysis Calendar App Example

Attributes1. Calendars have an owner and default focus.2. Events have a name, description, date, time,

duration, and a location.3. To-do items have a name, description, deadline,

and priority.4. A person has a job-description, office location,

phone number.

O/A Analysis: Attributes

• Attributes can be used to specify sub-types of a generic object to simplify analysis.

For example, a drawing program would have circles, squares, and triangles as objects that are exposed to users. These could simply be identified as a shape object and the attribute type could specify the specific shape.

O/A Analysis Calendar AppObjects Attributes Actions

Calendar Owner, default focus Examine, print, create, add event, delete event

Event Name, description, date, time, duration, location, repeat, type (e.g., meeting)

Examine, print, edit (attributes)

To-do item Name, description, deadline, priority, status

View, print, edit (attributes)

Person Name, job-description, office location, phone number

Send email, view details

Objects and Actions Matrix

• A matrix which maps objects and actions and the relationships they share.

O/A Matrix

Objects go on the left

Obj

ects

View Print Edit Add Event Delete Event

Calendar X X X X

(A) Owner

(A) Focus

Event X X X

(A) Date

(A) Name

To-do item X X X

(A) Deadline

Person X

(A) Name

O/A Matrix

Actions go on the top

actions

View Print Edit Add Event Delete Event

Calendar X X X X

(A) Owner

(A) Focus

Event X X X

(A) Date

(A) Name

To-do item X X X

(A) Deadline

Person X

(A) Name

O/A MatrixView Print Edit Add Event Delete

Event

Calendar X X X X

(A) Owner

(A) Focus

Event X X X

(A) Date

(A) Name

To-do item X X X

(A) Deadline

Person X

(A) Name

Attributes (A) of objects are listed beneath the object and are indented.

O/A Matrix

Relationships show which actions are applicable to objects. They are shown as checkmarks/X’s

View Print Edit Add Event Delete Event

Calendar X X X X

(A) Owner

(A) Focus

Event X X X

(A) Date

(A) Name

To-do item X X X

(A) Deadline

Person X

(A) Name

What can O/A Matrices tell you?

• Tall Matrix means many objects to master• A wide matrix means many actions to learn• A small and dense matrix indicates good

design and is easy to learn• A large and spare matrix reflects inconsistent

design and is hard to learn.

**Don’t take into account attributes when determining the complexity/simplicity of your matrix**

The Goal of O/A Analysis

• Validate the conceptual model• Weed out inconsistency• Identify relationships between objects• Identify more/less important tasks• Identify the simplicity or complexity of your

application.

Other O/A Analysis Examples

See Designing with the Mind in Mind, Chapter 11, Section Objects/actions Analysis for online store customer comments application

Online article by blink @ http://www.blinkux.com/insights/newsletter/objects-and-actions-analysis/

Planning Outline

A. Analyze user and taskB. Consider functionality

A. Find functionalityB. Develop a conceptual modelC. Perform an Objects and Actions AnalysisD. Define Lexicon

C. Conform to the user’s view

Define a Lexicon

Define the terminology to be used throughout the software and documentation.

Define a Lexicon

• The lexicon provides names and definitions for each object, action, and attribute.

• Use vocabulary that is familiar to the user and their tasks.

• Don’t use vocabulary that is implementation specific.

Benefits of a Lexicon

• Prevents designers/developers from using multiple terms for the same concept

• Helps designers/developers from using the same term for different concepts

• Promotes clear communication between designers and developers.

Bringing it all together

• Keep conceptual models simple• Find common tasks shared by objects. – Helps developers reuse code. Designers can then design

the same interface for operations across the objects.

• Identify Importance:– Which tasks are absolutely needed and which ones can be

removed.

Bringing it all together

A good conceptual model will help

Kick start Development: O/A analysis identifies an initial object model for user visible concepts.

Scenarios: A dev team can create scenarios which are helpful in validating design.

Conforming to the user’s view

Planning Outline

A. Analyze user and taskB. Consider functionalityC. Conform to the user’s view

Conform to the user

User interfaces should be designed from the user’s point of view.

Strive for naturalness

• Using the task analysis, we can see which acts are ‘natural’ to the task domain and which ones are ‘unnatural’.

• Unnatural acts are steps that have no obvious connection to a goal.

• Don’t impose arbitrary restrictions on users.

Strive for naturalness

• Writing software for a chess game, moving a piece in chess should only require knowing:– the piece you’re moving and – the position you’re moving to. Don’t complicate

the task by asking to name the move, making the player switch to move mode, etc.

• Don’t limit people’s names to 16 characters, • Don’t provide undo for only the last 3 actions

Use the user’s vocabulary

• Avoid geek speak, computer jargon, or technobabble for text used in software.

• Use the lexicon you defined. It should match terminology used in the task domain.

• The words from your lexicon should be found in the conceptual model, software, and help docs.

Keep program internals hidden

• The UI should represent only concepts that are required to support the task.

• Design for the convenience of the user, not the developer.

Power/Complexity Trade-off

• People tend to believe the more options, the more controls, the more power, the better.

• Realistically, people only learn a few features and ignore the rest.

• Decide which features are important by talking to the user.