Slides for

User interface design

A software engineering perspective
Soren Lauesen

5. Analysis, visions and domain description

 Highlights
How to describe the visions why the system is needed
and the large-scale solution.
How to describe data and user tasks in the domain.
Dealing with the past and the future.
Tasks versus scenarios and use cases.
Key exercise: Describe data and user tasks for the design
project.
 Analysis, visions and domain
description
Before we can design a good user interface, we have to
understand the application domain what goes on in the
real world outside the computer system.
Why is a new system needed!
What are the goals?
Who are the present users and what are they doing?
Which data is involved?
Finding out about this is called systems analysis a study
of the existing human and computer system.
 Analysis, visions and domain
description
A vision of what the new system will do is needed.
How will the goals be met?
Who will use the new system and which tasks will they carry out?
What is the large-scale solution in terms of technology?

For the purpose of designing the user interface, the two

most important documents are the data model and the task
descriptions.
Fig 5.1 Visions for the hotel system

Data model
D1. Guests
D2. Rooms
Business goals: D3. Services
- Small hotel market
- Much easier to use and install than
current systems.
- Interface to existing Web-booking Task list
systems. T1. Book room
T2. Check in
Requirements:
T3. Check out
R1: Store data according to data model.
T4. Change room
R2: Support tasks T1 to T5.
T5. Record services
...
and breakfast list
R7: Usable with 10 minutes of instruction.
 Business Goals
Business goals are the customers reasons for getting the
system. Why would he pay for it?
In the hotel case, we can define these business goals for the
hotel owner:
The hotel wants efficient support of the basic tasks in the reception
such as booking, checking in and checking out.
It is too much expensive to send staff on courses. Even temporary
staff should be able to handle the basic tasks on their own after a
few minutes of instruction.
Installation of the system should be easy.
The hotel wants to be seen on the Internet and provide on-line
booking.
 Large Scale Solution
How do we meet the business goals above? Here is the
large-scale plan:

Study existing hotel systems in detail - find out what is sufficient

for a first release.
Develop the user interface of the new system early. Run usability
tests to ensure that it is sufficiently easy to use.
Make it possible for a person with only general IT skills to
install the system.
The first release may be only for hotels that are so small that a
single-user system is sufficient (However, plan for a later multi-
user version).
 Requirements
Functional requirements
Data to be stored
Tasks to be supported
Technical interfaces
Platform
Screens
Web portals
Accounting
Quality requirements
Usability
 Data model and data description
A data model specifies the persistent data to be stored in
the system and the relationships between the data.
Figure 5.2 is a data model for the hotel system.
Each box corresponds to a collection of records of the same type.
The connectors between the boxes show one-to-many
relationships.

The one in the example is an Entity/Relationship model,

also called an E/R model or a Bachman diagram.
Fig 5.2 Data model for the hotel system
name,
address1,
address2, Guest
address3, name, price
phone
passport
Service Service
Stay
stayID, Received Type
paymethod,
state (booked | in |
out | canceled) Room date, quantity
State
date, personCount,
state (booked | occupied | repair)

roomID, Room
bedCount, type
price1, price2
 Task descriptions
A task description explains a user task in some detail.
There are many ways to describe tasks.

Why do we need task descriptions?

Because we want to ensure that the user interface can support the
tasks in both simple and complex cases.

Annotated task list : For most tasks we need a bit more

explanation than just the name of the task.
Fig 5.3A Annotated task list for the hotel system

Task list
Work area
1. Reception
T1.1 Book room. May involve many rooms. Task:
T1.2 Check in. Some guests have booked in advance, Domain-level,
some not. now and future
T1.3 Check out. Review account, then invoice.
Problem: Checkout queue in the morning. Present way
Solution? Self-service checkout.
T1.4 Change room. Possible any time during the stay. Possible future
T1.5 Record services and breakfast list. Breakfast list
daily, service notes at any time.
Clever: Special screen for breakfast list. Present way

2. Staff scheduling Work area

T2.1 Record leave
T2.2 . . .
Imperative language
Fig 5.3B Task description template

T1.2: Check in
Start: A guest arrives.
End: The guest has got room(s) and key. Accounting started.
Frequency: Total: Around 0.5 check ins per room per night. Per user: 60 ...
Difficult: A bus with 50 guests arrives
Subtasks:
Domain-level, now and future.
1. Find room. Imperative language
Problem: Guest wants neighbor
rooms; price bargain.
1a. Guest has booked in advance.
Variants Undo?
1b. No suitable room.
2. Record guest data.
2a. Guest recorded at booking.
Missing
2b. Regular guest.
subtask?
3. Record that guest is checked in.
4. Deliver key.
Full reference to a
Problem: Guest forgets to return the
subtask: T1.2-4
key; guest wants two keys. Past:
Problems
5.3 extra Typical UML use-case
For what reason?
Use case 21: Find a free room
Start: The receptionist wants to find a free room
End: The receptionist has found a free room
Subtasks:
1. Select room type.
2. Select desired period. Premature dialog
3. Click Search.
4. System shows the first free room.

Variant: No free rooms Used for what? Will user

have to write it down?
Fig 5.3C Optional subtasks
T1.6: Change booking
Start: Guest calls
End: ...
...
Subtasks: Separate
1. Find booking tasks?
2. Modify guest data, e.g. address (optional)
3. Modify room data, e.g. two rooms (optional)
4. Cancel booking (optional)
Fig 5.3D Task & support approach

T1.2: Check in
Start: A guest arrives.
End: The guest has got room(s) and key. Accounting started.
Frequency: Total: Around 0.5 check ins per room per night. Per user: 60 ...
Difficult: A bus with 50 guests arrives
Subtasks: Example solution:
1. Find room. System shows free rooms on floor
Problem: Guest wants neighbor maps.
rooms; price bargain. System shows bargain prices, time
1a. Guest has booked in advance. and capacity dependent.
1b. No suitable room.
2. Record guest data. (Simple data entry, see data model)
2a. Guest recorded at booking. (Search with many criteria, e.g.
2b. Regular guest. name, booking number, phone)
3. Record that guest is checked in.
4. Deliver key. System prints electronic keys. New
Problem: Guest forgets to return the key for each customer.
key; guest wants two keys. Past: Explicit Future:
Problems actor Computer part
Fig 5.4 Work area and user profile
Work area: 1. Reception
Service guests - small and large issues.
Normally standing, for instance facing the guest. Frequent interrupts.
Often alone, e.g. during night.

User profile: Novice. Often a temporary job.

IT knowledge: Simple text processing. Younger persons have surfed a
bit on the Web.
IT attitude: Part of the job, but not fascinating in itself.
Domain knowledge: Knows only the very basics, for instance what
check in is in the simplest case.
Domain attitude: OK but not the career of life. It is just a temporary job.
Discretionary use: Mandatory.
Physical abilities: Normal sight, hearing, size, etc.

User profile: Experienced. Often a life-time job.

IT knowledge: Simple text processing. Some know more, of course.
IT attitude: Curious about how it works in the job.
Domain knowledge: Knows all the procedures and the special cases.
Domain attitude: Likes the job. Likes to be an expert.
Fig 5.5A Good and bad tasks

Good tasks:
Closed: From trigger to closure - coffe break deserved
Session rule: Small, related "tasks" without breaks as one task
Domain level: Hide who does what with imperative language
Dont program - if the customer has booked then ...

Examples: More examples:

1 Manage rooms? 9 Arrange a meeting?
2 Enter guest name and address? 10 Monitor a power plant?
3 Book a guest? 11 Wonderland Web site?
4 Check in a bus of tourists? 12 Computer game?
5 Change the guests address etc?
6 Change booking?
7 Cancel entire booking?
8 Stay at the hotel?
Fig 5.5B High-level tasks and business cases

Arrange Write marketing

meeting report Business cases
Actor: meeting?
marketing report?

Participant 2:
Able? unable?
Participant 1:
other time? High-level tasks
Able? unable? Coordinator: Actor: person
other time? Who? when? where?

Phone call Email session Ordinary tasks

Email session Actor: person

Subtasks
Reply File Retrieve
Actor: person
Fig 5.6A Vivid scenario

Scenario: The evening duty

Doug Larsson had studied all afternoon and was a bit exhausted when
arriving 6 pm to start his turn in the reception. The first task was to prepare
the arrival of the bus of tourists expected 7 pm. He printed out all the
checkin sheets and put them on the desk with the appropriate room key on
each sheet.

In the middle of that a family arrived asking for rooms. They tried to bargain
and Doug always felt uneasy about that. Should he give them a discount?
Fortunately Jane came out from the back office and told them with her
persuading smile that she could offer 10% discount on the kids room. They
accepted, and Doug was left to assign them their rooms. They wanted a
neighbor room for the kids, and as usual he couldnt remember which rooms
were neighbors.

Around 10 pm, everything was quiet, and he tried to do some of his

homework, but immediately became sleepy. Too bad - he wasnt allowed to
sleep at work until 1 AM. Fortunately the office computer allowed him to surf
the net. That kept him awake and even helped him with some of his
homework.
Fig 5.6B Use cases versus tasks
UML use case
Hotel system
diagram:
Booking
actor
Checkin
Receptionist
Checkout
Account
Transfer system
actor

Human and computer separated: Task descriptions. Split postponed:

Hotel system Hotel system

Booking Booking Account

Transfer
... ... system
Fig 5.6C Human and computer separated

Use case: Check in a booked guest

User action System action
Enter booking number
Show guest and booking details
Edit details (optional)
Store modifications
Click checkin
Allocate free room(s)
Display room number(s)
Give guest key(s)