crafting the compelling user experience using a methodical ... › ska › hci06 › literature ›...

Creating the compelling user experience make it easy 2001

©IBM 2001 June 2001

Crafting the Compelling User Experience Using a methodical software-engineering approach to

model users and design

Didier Bardon Dick Berry

Carolyn Bjerke Dave Roberts

Ease of Use, IBM Contents Overview......................................................................................................................................................... 2 Discovery...................................................................................................................................................... 28 Design I – Abstract ....................................................................................................................................... 45 Design II – Realization ................................................................................................................................. 75 Case Study .................................................................................................................................................... 99 Conclusion .................................................................................................................................................. 106 Tutorial Exercises ....................................................................................................................................... 119

Audiences................................................................................................................................................ 119 Stories ..................................................................................................................................................... 120 Hotel Tasks by Job.................................................................................................................................. 122 Object Analysis....................................................................................................................................... 124 Exercise 1: Overview.............................................................................................................................. 125 Exercise 2: Tasks Models ....................................................................................................................... 125 Exercise 3: Views ................................................................................................................................... 126 Exercise 4: State Models......................................................................................................................... 126 Exercise 5: Sketches ............................................................................................................................... 127 Sample Answers...................................................................................................................................... 129


©IBM 2001 June 2001

Overview Dick Berry, Ease of Use, IBM, Austin.

Note: In this version, signposting slides, such as section titles and repeats of the overall process diagram, have been omitted where they did not appear to add any further value for the reader.

Slide 1

Slide omitted.

Welcome to Crafting the Compelling User Experience. Using a Methodical Software Engineering Approach to Model Users and Design

I'm Dick Berry from the IBM Ease of Use Team in Austin, Texas. I'll be with you for a while this morning and again this afternoon for the conclusion.

You'll be spending most of the day with an outstanding team of hands-on practitioners from Austin, TX and Warwick, UK - I'd like to introduce Carolyn Bjerke and Didier Bardon from Austin, and Dave Roberts, from Warwick.

Slide 2,3

Slides omitted.

I will begin with some background and key concepts, some of which are specific to the approach we will teach you today, but many of which are applicable to good interface in general. Then three pre-eminent practitioners – Carolyn, Dave, and Didier - who use this approach daily in client engagements, will teach the core sections.

To begin, Carolyn will tell you about Discovery activities, consisting of identifying and modeling targeted users, their goals, tasks, and criteria for success

Then Dave and Didier will take you through Design. Dave will cover finding and modeling user objects - building the user object model, designing user tasks, and identifying abstract views

Didier will then show you how to craft abstract views into finished presentations – Web pages, panels, screens and so on - applying visual design aspects such as visual themes, company styles, visual priority, and so forth.

Carolyn and Didier will then show you an exciting case study that demonstrates how this approach can be used in an accelerated manner, involve users, and achieve significant gains in user satisfaction.

Dave will then show you an exciting proof-of-concept demo - generating HTML pages from the UML diagrams.

I'll conclude by taking a look at some of the issues in Development and Deployment, difficulties you may encounter using this approach along with strategies for working around them, and we'll end with a glimpse of possible future directions.


©IBM 2001 June 2001

Slide 4

June 2001 4IBM Ease of Use Group Slide number

Tutorial Overview

User CenteredDesign

Total User Experience

This tutorial is about creating compelling user experiences and how the application of software engineering approaches and tools are very powerful if not necessary aids in this endeavor. More and more we realize that we need to expand the focus of design to creating a Total User Experience - an end-to-end approach to creating and delivering a compelling and productive user experience

What you will be seeing today is an introduction to an evolving approach to creating a total user experience – an approach that is evolving from traditional user interface design approaches in two major ways. Firstly, we are evolving the scope to encompass the total user experience. Secondly, we are evolving the use of software engineering approaches and tools. This is the direction of user experience design – we are not alone on this path – it has become clear to many in our field that a more rigorous, thorough, and accurate approach to UE design is not only possible – it is necessary, for many of the same reasons that software engineers long ago started down this path.

By the end of the day you may feel somewhat overwhelmed – many of the concepts involved may be new to you. So don’t despair if you feel somewhat overwhelmed – you can’t become a skilled practitioner in a day - what we intend today is that you gain an appreciation of what is possible – how we can significantly raise the level of user experience design to truly create compelling user experiences.

It’s not just the ‘design’ phase we have to be concerned with anymore. Remember that the “D” in UCD is for “Design”. But in the future we have to extend user-centered approaches along with software engineering approaches to all phases of creating a product or solution, including - Discovery, Design, Development, and Deployment.


©IBM 2001 June 2001

Slide 5


Tutorial Overview

User CenteredDiscovery

DesignDevelopmentDeployment

Total User Experience

Object View Interaction Design

So we believe it’s an appropriate evolution for UCD to become User-Centered Discovery, Design, Development, and Deployment

Some of you may be familiar with Object View Interaction Design (OVID), which introduced an engineering-like precision and rigor to design, using tools of software engineering to enable thorough analysis and create precise specifications for use from initial design through implementation and deployment. Several of us taught a tutorial at CHI ’97 and published a book about a year later.

We are now extending the OVID approach to the entire process of creating a user experience - from the initial understanding of users and their environment through deployment and assessment of user acceptance.

This tutorial is in effect “User Experience Engineering” – “engineering” is the application of principles and approaches to practical problems – UEE is analogous to CASE - computer assisted software engineering

This approach uses software engineering techniques and tools to define and document - unambiguously - all aspects of the user experience, from the factors that influence the design, through the design, its ultimate implementation and deployment

This approach provides a single-source specification from which all members of the design and implementation teams can work to achieve a single view of the desired result.


©IBM 2001 June 2001

Slide 6


End-to-End Approach

User-Goal Analysis

Scenarios & Stories

User Objects

User Tasks

Abstract Views

Presentation ViewsView Maps

Implementation FidelityReports

DeploymentFeedback

Post-DeploymentUser Satisfaction

What you’re going to hear about throughout the remainder of the day is how to apply the concepts of architecture and modeling, through the use of software engineering approaches and tools, to address the full gamut of design issues – from Discovery of users needs through Deployment and assessment of how well the design meets users’ needs.

We’re going to show you how to extend the UCD process to address Discovery, Design, Development, and Deployment with a new degree of accuracy and rigor.


©IBM 2001 June 2001

Slide 7


UCD Phases

Here is a brief overview of the issues we’ll discuss within each phase of our expand view of UCD:

Discovery identifies the targeted user audience, which may quite distinct from market segments. Users are those who actually experience the product, application, or Web site we develop. This phase develops clear distinctions between various user segments – distinctions that are likely to be reflected in design differences. Whenever we talk about users we need to make sure we also talk about their goals, tasks, and criteria for success. An understanding of these four aspects is necessary to truly know who the real users are. Carolyn will cover this topic in detail.

Design is broken into two levels: abstract and realization. Abstract design consists of identifying objects, or things, users need to perform their tasks, along with high-level interaction aspects. Realization maps the abstract user experience to specific environments, including issues such as technology, accessibility, culture and geography.

Finally, the issues we focus on during Development and Deployment are ensuring that the design is implemented as intended, and that it is actually satisfying users’ needs.


©IBM 2001 June 2001

Slide 8


Iceberg Analogy

Visuals InteractionTechniques

User’sModel

UI Toolkit andStyle Guides

Desktop and application objects

Look and feel are the tip of the user experience iceberg.

Need for a formal architectural approach.

Drivers Analysis

Many of you are likely familiar with the iceberg analogy we’ve used since 1990 to convey what we believe to be the relative contribution of various user experience aspects to the overall experience. Two key observations have driven much of our work over the last decade including our focus on modeling and software engineering approaches.

Firstly, we believe the relative contribution of the user’s model outweighs that of the look and feel combined – hence the “look and feel are the tip of the iceberg”.

Secondly, if we can analyze and impact the various drivers of user experience in a more precise, rigorous, and repeatable way we can explicitly create more compelling user experiences.

To achieve this level of analysis and rigor we look to formal architectural approaches using models and tools. We need a notation to document the user's object model, and we need to identify the activities necessary to create it – much of which evolved to become Object View Interaction Design (OVID) method - based on CASE approaches and tools, such as UML and Rational Rose.

Now after several years of experience using these approaches and tools for the core design and modeling activities, we are extending the approach to encompass the total user experience - modeling the front-end activities – thorough & rigorous analysis in order to better drive the design & to capture it for communication.

We are basically still following an “architectural approach” – the way we were in the early 80’s – providing a framework for identifying fundamental concepts and relationships, and modeling them to facilitate analysis and understanding.


©IBM 2001 June 2001

Slide 9


UI Architecture

Architecture

Orderly arrangement of parts to achieve some desired effect.

Computer Architecture

The conceptual elements of a system, their roles, and relationships.

UI Architecture

The conceptual elements of a system that are perceivable by users, their roles and relat ionships.

Architectures are often described using models.

In general, architecture has to do with arrangements and relationships of components to achieve some desired effect - whether it be related to a building, an organization, or a computer. Furthermore, it typically refers to the conceptual aspects more so than to specific implementation details - thus very meaningful discussions take place regarding the "Intel Pentium architecture" without regard to specifics such as chip size, fabrication technology, operating voltage, cache size, packaging, and so forth.

More specifically, computer architecture identifies conceptual elements of computing systems, along with their roles and relationships.

A UI Architecture consists of the components of a system, their roles and relationships - that are perceived by users of the system. This is what distinguishes UI Architecture from computer architecture in general - while we utilize many of the same techniques, approaches, notations, and tools - our focus is solely on aspects that users are intended to experience.

Of course we are now extending this architecture from simply “user interface” to the broader topic of “user experience”

It is often very useful to document an architecture - for the purposes of analysis, understanding, and comparison - using a model – so it’s important to understand what a model is and what they’re good for.


©IBM 2001 June 2001

Slide 10


ModelsModel

A schematic description of a system, theory, or phenomenon that accounts for its known or inferred properties and may be used for further study of its characteristics.

User Interface ModelConveys essential aspects of use:

Conceptual – entities & relationships

Interaction - user controls

BenefitsRigor and precision

Pattern recognition ! reuse

Communication ! visual and memorable

A model is a representation of a system that accounts for its structure, organization, properties, and behaviors - again, primarily used to facilitate study and analysis.

A model is not the system itself - it's a description of it. Therefore, models have some very interesting properties - such as, they don't have to be complete - they don't even have to be perfectly accurate. The key requirement is that any model be complete enough and accurate enough to enable a useful level of study and analysis.

For example, you may recall from high-school Chemistry that Bohr's model of the atom provides perfectly acceptable answers to many physical phenomena – up to a point - then the quantum model replaces it. Each can be useful. The Bohr model with its solar system like notion of electrons orbiting the nucleus in various shells is simple to understand, and it explains many chemical reactions quite well. But when we start to talk about phenomena involving light, or at the atomic level, the Bohr model becomes inadequate and we have to use the quantum model, which is much more difficult for most people to fully comprehend.

When we model a user experience architecture, we need to include both conceptual and interaction aspects - remembering the Iceberg.

One way I like to think about modeling is describing the essential elements of use - both conceptual and interaction. Let's look at a simple example we can probably all relate to - a radio. I’ve chosen the radio because we’re probably all users but very few of us really understand how a radio works. Through the use of a model you’ll very shortly have a useful level of understanding – and you’ll know why you can’t listen to one on an airplane.


©IBM 2001 June 2001

Slide 11


A simple model of a radio

Naive User's Model

Radio Receiver

Antenna

Tuning Control

Volume Control

Speaker

In it's most simple form, a radio consists of an antenna, a box full of electronic parts, a speaker, and a couple of controls - one for selecting the station you want to listen to and the other to adjust the volume.

Since the antenna and speaker are often contained within the box, you could argue that this isn’t necessarily the simplest model - but you might want to at least explain where the sound comes from - again, the level of detail depends on the situation in which the model is being used - what needs to be described - to whom, and for what purpose!

We sometimes talk about a continuum of users' understanding - with naive users at one end and astute users at the other - this is a naive user's model.


©IBM 2001 June 2001

Slide 12


A more complex model of a radio

Astute User's Model

RF

Amplifier

IF

Amplifier

Audio

AmplifierMixer Detector

Local Osc.

Antenna

Speaker

Tuning

Control

Volume

Control

This is a more detailed view inside the box we call a radio - and it's basically valid for everything from AM/FM radios, to TVs, to cell phones. Now we get a bit more formal - for each identified component we state its role and relationships with other components.

Antenna - captures very weak radio frequency (RF) waves being transmitted by stations all over the world

Radio Frequency (RF) Amplifier - amplifies the very weak signals from the antenna to a useful level

Local Oscillator - generates a signal of a specific frequency that is combined with all of the signals received by the antenna to control which station is selected

Tuning control - a user control that changes the frequency of the signal generated by the local oscillator so the user can select a specific station

Mixer - combines the multitude of amplified signals from the RF Amp with the signal from the local oscillator to select the user's chosen station and converts it to an intermediate frequency (IF) for further processing. The signal is still a radio frequency - far above human hearing range.

Intermediate Frequency (IF) Amplifier - amplifies the selected station's signal - still at radio frequencies - may be multiple stages of IF amplification

Detector - extracts the audio signal from the radio frequency signal and couples it to the audio frequency amplifier

Audio Frequency (AF) Amplifier - amplifies the audio of the selected station and drives the speaker

Volume Control – a user control that allows the user to adjust the audio volume

We might call a user who understands this level of detail an astute user - probably a very astute user. As a matter of fact, if you understand this level of the model you know why the use of radios and similar devices is not allowed on airplanes. The Local Oscillator is a tiny transmitter that could cause interference with the airplanes communications or navigation equipment! This is also how the authorities in the UK discover people watching TV using unlicensed television receivers – they drive around in vans listening for TV sets at unlicensed locations!


©IBM 2001 June 2001

Slide 13


Benefits

Understanding • Facilitates purchase and optimized use• Aids problem determination• Enables modifications and enhancements

Astute UserNaive User

Communication • Visualize key elements, roles, and relationships• Memorable• Ensure a common level of understanding

So what are the benefits of understanding such models? First, there are direct benefits of use, such as:

Understanding the role of the antenna leads to better reception - buy a bigger TV antenna with more elements to capture more signals

Aids purchasing decisions - one set has an RF amp another doesn't – a cost savings possibly resulting in poorer reception

Ability to use advanced features such as RF Gain control and IF pass-band tuning to reject strong unwanted signals and eliminate interference - these features and others are typically standard on commercial communication equipment

Additional advantages include problem determination and proposals for enhancements, for example, if you hear only white noise (hissing sound) coming from the speaker, (or only snow on a TV picture), it's likely that there's a problem with the antenna - at least you know it's not the AF amplifier or speaker.

Military and commercial radio operators undergo extensive training using such models not only to enhance their abilities to use the equipment to the utmost but to enable problem determination and potentially repair or modification in the field.

Additional benefits of models are derived from improved communication. They visualize key elements, roles, and relationships, making them more memorable. The overall effect is that they ensure a broader, more common degree of understanding throughout a team

Now let's turn our attention to the way we use models in user interface design, more specifically the way we can methodically create compelling user experiences. The first step is to understand the relationships between what users' think, what we design and intend for them to think, and what implementers actually build. We do this with three key models.


©IBM 2001 June 2001

Slide 14


Three Key Interface Models

Hotel Room

Guest

Designer's Model

•Things•Appearances•Interactions

Needed for users’ tasks

Note: We will use the term "application" to mean "system", "application", Web site, or whatever it is we are creating.

There are three key models we have to be aware of:

First, the designer's model represents what we're designing and what we intend that users understand

It consists of:

The things, or objects, we will give users to do their tasks, along with the properties and behaviors of those objects, and their relationships to other objects

It also includes how we intend users to perceive the things – their appearance – and the interactions that users can have

Most importantly, it consists only of those things that are perceived by users in order to do their tasks.


©IBM 2001 June 2001

Slide 15



Users’Models

•Beliefs•Goals•Emotions•Superstitions

Hotel Room

Guest

Designer's Model



Every user who observes and uses what we design begins with preconceived notions based on their beliefs, goals, and emotions. Users’ prior experiences contribute to what we call the users’ models – also called users’ conceptual models, or users’ mental models. Some of their beliefs may actually be superstitions – representing mistaken or incorrect interpretations of their experiences.

Note that “users’” is plural and possessive. Each user has their own unique conceptual model – shaped by their own life experiences.


©IBM 2001 June 2001

Slide 16



Hotel Room

Guest

Designer's Model



Users’Models

•Beliefs•Goals•Emotions•Superstitions

•Data structures•Toolkits•Algorithms•Libraries

Implementer’sModel

The implementer's model represents the implementation of the application being designed

It consists of implementation details such as data structures, toolkit components, algorithms, and libraries.

Users should never have to be aware of the implementation model. It describes the implementation details that create the designer's model for users.


©IBM 2001 June 2001

Slide 17



Observ ations

Guest name

Reservati ons

No. in party

Credit cardSmoking Non-smok ing

In Out

Naive Astute

Hotel

Gues t

Deduction

User B's Conceptual Model

Hotel Room

Gues t

Deduction

User A's Conceptual Model

Hotel Room

Guest

Designer's Model

User A User B

The Goal

The way these models interact is as follows:

Users perceive what is created by the implementation, a hotel reservation form for example.

Each user builds or reinforces their conceptual model.

If the implementation is faithful to the Designer’s Model and users’ deductions are correct, their conceptual models will match what is intended – the Designer’s Model.

Of course, not all users will interpret what they see and experience correctly, implementations aren’t 100% faithful to the design, and our designs sometimes don’t match users’ expectations.

Our goal is two fold:

To understand users' current conceptual models well enough to factor key aspects into the design - to aid learning and satisfy users' goals.

To instill in each and every user an accurate understanding of the design at an adequate level of detail to allow them to accomplish their goals.

In the ideal situation every user has an accurate understanding of the designer's model - at least accurate enough to support the tasks they want to do.


©IBM 2001 June 2001

Slide 18, 19


Object Model – View Separation

Guest name

Reservations

No. in party

Credit cardSmoking Non-smok ing

In Out

Hotel Room

Guest

Designer's ModelView Model

Object Model

User

Obviously, users don't actually see the designer's model directly - as UML diagrams or otherwise. Users have to develop their mental model - and ideally a correct one - by observing and interacting with the design - which they perceive through screens, panels, windows, and Web pages - or in other words, through what we call views.

A view presents a portion of the model to enable specific user tasks. Each view also provides mechanisms to support user interaction. Mechanisms might include keyboard, mouse, pen, voice, and so forth. Even though we use the term "view" with a visual connotation - we intend it in a general way and include audio and all forms of sensory perception.

Everything the user sees, touches, hears, or otherwise perceives about an application is through its views. Views also enable all user interaction. If an aspect of the model is not represented in a view - for users it doesn't exist. To users, the sum of all views is the application - dictating what they can see and do. Some of you may recall Don Norman's way of depicting this using the Gulf of Evaluation and Gulf of Execution.

Some of you may be familiar with a software design paradigm called “model-view separation” or “model-view-controller”. We parallel this separation in the Designer’s Model, which is actually composed of an object portion and a view portion.

The explicit separation of object model design from view design provides a very powerful paradigm for dealing with an ever-changing set of requirements. It allows us to isolate and encapsulate aspects that are subject to different forces for change and that require different kinds of design skills. It provides flexibility and extensibility, which are ultimately reflected in reduced cost over time.

For example, given a hotel reservation system, the user-oriented business objects, such as reservations, guest registrations, folios, and receipts, and the relationships between them are described in the user's model for the application.

How the users of the application - guests and hotel staff - actually go about creating reservations, registering guests, and so forth, at a mechanism level is defined separately in the views. There may be views for kiosks in hotel lobbies, for Web pages, and even for a voice-response telephone-based system. In each case the underlying model is identical.

Recall the iceberg; views encapsulate the look and feel aspects, separate from the user object model.


©IBM 2001 June 2001

When users easily and accurately learn the model by interacting with an application we say it's intuitive. To the degree the design falls short of this goal, it has to be augmented with Help, tutorials, and other aids to understanding.

Slide 20


Abstract and Presentation Views

Guest na me

Reservatio ns

No. in par ty

Credit car dSmoking Non-smoki ng

In Out

Reservation View

Guestname: String, 20PartySize: Number, 1, 99DateIn: DateDateOut: DateCreditCard: String, 15Smoking: T/F

Abstract View Presentation Views

Guest na me

Reservatio ns

No. in par ty

Credit car d

Smoking

Date Ar/Lv View content – elementsUser interactionsInter-view navigation

Rendering detailThemesVisual priorityDevice specifics

It's pretty much a fact of life that practical applications have to be designed to operate in a variety of environments - accommodating different types of devices and running on multiple platforms. For example, it might be necessary to access an application using a Web-based browser on a 1024 x 768 PC display, and also on a Palm Pilot, and even a cell phone.

Obviously we would like to avoid having to do three designs, and potentially more later. We'd like to isolate the basic application model and insulate it to some degree from changes in interface requirements. Object model-view separation is the first step, but we needed to find a way to stretch these benefits even further - providing more isolation from change, ability to quickly respond to changing interface requirements, and even a potential to automatically generate much of the interface.

We do it by defining two levels of views - a level that is independent of platform and device specifics – called the abstract view, and a level that is specific to a particular platform and/or device – called the presentation view.

Abstract views specify what is presented to users - without specifying how it's presented. For example, suppose we want to allow the user to chose the type of room they want to reserve: a studio with a single bed, a normal double bed room, or a room with a King-size bed. All that is really needed in the abstract view is a specification of a single-choice selection with three values.

At this level we don't care if the user will see it as a set of radio buttons, a drop-down list, a spin button, or three pictures they chose from. These are issues best dealt with at the platform and device level - or in other words, in the presentation views.

Each abstract view will have one or more associated presentation views that reflect exactly what the user will experience.

Functionally, you can evaluate an application through its abstract views.

The set of tasks enabled by the collection of all abstract views must equal what's required.


©IBM 2001 June 2001

Diagrams showing the linkages between abstract views can be created to provide an overall navigation map. A navigation map can be used to assess how well users' task strategies are accommodated - by analyzing paths through the map. For Web-based applications this map is the map of the Web site showing all possible user paths.

We have created an XML-based language to describe these abstract views - called Abstract User Interface Markup Language (AUIML).

Later today Dave Roberts will show a proof-of-concept demonstration, generating AUIML directly from Rationale Rose UML diagrams, and then rendering the AUIML as a Web page – all automatically with the click of a button.

Slide 22


Scope of the User Experience

Total User ExperienceA dvertising

Pre-Sales Inquiries

Terms & C onditions

O rdering

Distribution

Packaging

Setup & Installation

Documentation

Learning to Use

General Use

Defect Support

Non-defect Support

Upgrades/New Versions

Post-Sales F ollow -up

Disposal

Human-Computer Interaction (HCI) Focus

Widening focus of the IBMEase of Use Team

We need to think about design activities more broadly, not just in relation to designing an application or a Web site.

We view the Total User Experience as consisting of activities ranging from a user’s first exposure, typically via advertising, through the full life-cycle of use, and ultimately including disposal.

All aspects of the user experience can and should be designed - all too often they just happen. Someone is responsible, they turn the crank, and out comes an implementation - often with little if any input from users.

Designing the total user experience means starting at the beginning - with explicit thought about potential customers and users, how to approach them, how to tell them about our products, how to make finding what they want and buying it painless and easy, how they acquire it, set it up, use it, and ultimately dispose of it through upgrades or other means. All of these aspects can be explicitly designed.

The focus of traditional human-computer interaction (HCI) design has been primarily on the aspects of use. Several years ago, within IBM, we began to expand this focus and are continuing to do so.


©IBM 2001 June 2001

Slide 23


Scope of the User ExperienceTotal User Experience - Design

Ease of Use Messages

Out-of-box Experience

Web Site & Telemarketing

Assistance and Support

Learning and Usage

A dvertising

Pre-Sales Inquiries

Terms & C onditions

O rdering

Distribution

Packaging

Setup & Installation

Documentation

Learning to Use

General Use

Defect Support

Non-defect Support

Upgrades/New Versions

Post-Sales F ollow -up

Disposal

Let’s look at some examples of "designing“ for the Total User Experience. As part of our implementation of User-Centered Design, we have monthly progress management reports in which products reports their progress on many different aspects of the total user experience. One element is Ease of Use Messages. These are messages designed for use in advertising and marketing literature. They may appear in magazine and TV ads, in campaign posters, on the ShopIBM Web site, and even on product packaging. These messages are often picked up by the trade press, resulting in an amplification effect.

An extreme amount of user-centered design is obviously going into many Web sites worldwide – and it’s obviously not going into others. Making the buying task easy and straightforward is a major design theme – there are many Web design guideline books, design consultants, and design newsletters – Jacob Nielsen’s AlertBox is one and Larry Constantine’s use notes is another. The out-of-box experience (OOBE) is the first time that many components come together for the first time. The user often feels the full force of lack of coordination between product design, fulfillment, packaging, and documentation. A few years ago we conducted a “best practices” workshop on out-of-box experience design, which resulted in the OOBE Design Guidelines published on the IBM Easy Web site.

Of course, learning and day-to-day usage have been the traditional focus of design activities. Now even service and support activities are being approached with the same attention to the user experience – for example, all new Thinkpads include a Thinkpad button on the keyboard that launches AccessThinkpad, a built-in function providing assistance and access to service and support. The point is, all aspects of the user’s experience can be improved through conscious attention and rigorous methods. This is the new era – designing for the Total User Experience.


©IBM 2001 June 2001

Slide 24


Multi-Disciplinary Team

Total User ExperienceLeader

Marketing Specialist Visual Designer HCI Designer

User ResearchSpecialist

Technology Architect User Assitance ArchitectService & SupportSpecialist

Obviously, to address the variety of aspects in designing a total user experience we need to ensure a proper set of skills.

Whether the titles exactly match those you’re familiar with, I’m sure you’ll agree that we need:

Someone who has the overall vision for the application – who will take the users’ perspective and ensure the total experience meets users’ expectations.

We need a two-way channel to marketing – to understand marketplace needs and competitive pressures, and to convey ease of use advantages back into marketing strategies and ad campaigns.

We certainly need skilled visual designers, HCI designers, user researchers, advisors on implementation technologies, service and support, and user assistance.

Some members of this team will actively perform modeling tasks and create model diagrams – all of them will use the model as the definitive statement of the design, and a primary means of communicating amongst themselves.


©IBM 2001 June 2001

Slide 25, 26, 27


Key Terms

A narrative describing how users accomplish their goals.

Scenario

A related set of tasks performed by a user. Role

A person who experiences the interface being designed.

User

A specific plan for performing tasks to accomplish a goal.

Strategy

A set of activities performed to accomplish a goal.

Task

A result to be accomplished independent of how it is achieved.

Goal

Before we go further, there are a few key terms you’ll hear throughout the day that require our shared understanding. These terms represent key concepts which cannot be ambiguous.

Goal - A result to be accomplished independent of how it is achieved. A goal is expressed as a state to help ensure independence from various mechanisms that might be used to achieve it. That is, it specifies a condition, using nouns and avoiding verbs, which might specify or imply how the condition is achieved. Goals are defined in this manner so as not to bias design directions or inadvertently preclude unrealized design opportunities.

Note: Any discussion or analysis of users’ goals should always include specification of users’ success criteria as well.

Task - A set of activities performed to accomplish a goal. Tasks may be undertaken at a variety of levels from cognitive and conceptual to interaction-specific. High-level design focuses on cognitive and conceptual level tasks, or what is being accomplished. Low-level design focuses on mechanism-specific interactions, or how the tasks are accomplished. High-level design is termed conceptual design while low-level design is termed interaction design. High-level tasks are identified in User-Goal Diagrams and are modeled using Activity Diagrams. The task model for a goal includes the roles of all participants in the goal. That is, the task model is the union of tasks performed by all users participating in the goal. For example, the task model for a hotel check-in task would include the roles of both guest and hotel clerk.

Strategy - A specific plan for performing tasks to accomplish a goal. Users typically have choices in how they accomplish a goal. These choices are reflected as decisions in Activity Diagrams that models the tasks. A specific path through a task model is used to represent a user strategy. A user combines the actions constituting a strategy in a coordinated and orchestrated manner to make progress toward a desired goal. Users make progress by constantly assessing the usefulness of their strategy – “does this strategy seem to be working?” – and they shift between strategies as necessary. A strategy may involve success criteria in addition to simply accomplishing the goal, such as doing so in the most expedient manner. For example, automobile navigation systems typically offer several strategies for getting from A to B: one that minimizes the distance traveled, one that maximizes the use of freeways, or one that includes scenic routes. Strategies can be modeled as specific paths in Activity Diagrams. The goal of the design is to optimize these paths to support strategies users require or frequently employ.


©IBM 2001 June 2001

User - A person who experiences the interface being designed. Users are distinct from market segments, which represent potential purchasers, who may or may not also be users. Other people may be involved with a product but not use it directly. For example, an auditor may work with the data resulting from an expense accounting application but not experience the interface; hence they are not a user of the product.

Role - A related set of tasks performed by a user. A person may fulfill one or more roles. Many individuals having different job positions may perform the same role. The relationship that associates the related tasks is the accomplishment of a major goal, and association with a common set of objects used in achieving that goal. For example, the role of System Administrator consists of a variety of tasks designed to keep a system running and operating efficiently. This role may be an individual's sole assignment, or one or more individuals might share this role along with other roles. Similarly, a Desk Clerk in a hotel may occasionally be called upon to perform the role of Shuttle Bus Driver, which is normally a role of the Bell Staff. The definition of roles is primarily to aid task analysis in situations where individuals' responsibilities overlap significantly. Roles help clarify major groups of related tasks and separate them from job positions, which tend to vary across and within organizations.

Scenario - A narrative describing how users accomplish their goals. Scenarios also indicate how users employ specific strategies. A scenario brings users and their context into the task-goal equation. This context helps clarify primary goals and associated goals that guide users to employ specific strategies. A story is a scenario embellished with users' personality attributes, emotional states, social contexts, and other situational details to illuminate aspects that may affect their overall response and behavior in a task situation.

Slide 28


Unified Modeling LanguageEntities

User (Actor)

Objects & Views (Classes)

Properties (Attributes)And

Actions (Operations)

Unified Modeling Language is an object-oriented analysis and design language from the Object Management Group (OMG). UML standardizes several diagramming methods for describing object-oriented systems that were developed in the late 1980s, including Grady Booch's work at Rational Software, Rumbaugh's Object Modeling Technique and Ivar Jacobson's work on use cases.

The primary elements of UML used in our approach are entities and relationships:

Entities – Users are represented using the UML Actor symbol; objects and views are represented using classes.


©IBM 2001 June 2001

Users, objects, and views can be expanded to show their properties and actions (using UML attributes and operations).

Slide 29


Unified Modeling LanguageEntities Relationships

Composition (Aggregation)

Type of (Generalization)

Association & Cardinality

User (Actor)

Objects & Views (Classes)

Relationships – The key relationships are composition, type of, and association.

Composition is represented using the Aggregation relationship. A Question Group is composed of “n” Question and Answers.

Type of (or sub-class) is represented using Generalization. A Desktop Computer is a type of Category.

Association in general is represented using a labeled association, such as a PC Manufacturer operates a PC Manufacturer Call Center.

Cardinality is shown on relationships. A PC Manufacturer operates “1 to n” call centers.


©IBM 2001 June 2001

Slide 30


Rational Rose

Rational Rose is a Computer-Aided Software Engineering (CASE) tool published by Rational Software.

The key diagram types used in our approach are:

User-Goal Diagrams (Class Diagrams)

User Class Diagrams (Class Diagrams)

Users Current Task Model (Activity Diagram)

Object Model and View Model (Class Diagrams)

We are also experimenting with modeling Deployment Issues using Use Case Views.

Other diagram types that may be used will be covered in the detailed sections.


©IBM 2001 June 2001

Slide 31


End-to-End Approach

User-Goal Analysis

Scenarios & Stories

User Objects

User Tasks

Abstract Views



DeploymentFeedback


What you’re going to hear about throughout the remainder of the day is how to apply the concepts of architecture and modeling, through the use of software engineering approaches and tools, to address the full gamut of design issues – from Discovery of users needs through Deployment and assessment of how well the design meets users’ needs.

We’re going to show you how to extend the UCD process to address Discovery, Design, Development, and Deployment with a new degree of accuracy and rigor.


©IBM 2001 June 2001

Slide 32


Discovery to Realization

This concludes the Overview. After the break we will begin to drill-down into each phase beginning with Discovery, followed by Abstract Design, and Realization.

In the Conclusion I’ll talk about Development and Deployment.

Slide 33

Slide omitted.

Slide 34

See Exercise 1: Overview on page 125.

Discovery Slide 1

Slide omitted.

Slide 2

June 10, 2001 2IBM Ease of Use Group Slide number

Overview of UCD Phases


©IBM 2001 June 2001

Slide 3


Overview of the Discovery Phase

Purpose of Discovery Phase: To define and understand the essential user information in order to design an effective user experience.

Point of Evolution: We have evolved our modeling approach to now include modeling information that comes before the original starting point of OVID. We now model the users, their goals, as well as their tasks and the use cases the system will support.

Further point of evolution: We are working to also model business objectives, vision and strategy to further aid the user experience design effort.


©IBM 2001 June 2001

Slide 4


Teaching Example - Hotel Guest Services System

" Why use the Hotel task example?" Can be scoped to look at simple tasks" Familiar experience to most of us" Can easily use the web to do some research on the task set

" Not a real-world project (later in the day we’ll present a Case Study)" Inputs: We wrote stories as input to the teaching example

See examples in Tutorial Exercises on page 119.

Slide 5


Stories - For your reference

" Vacationer: Making a Hotel Reservation task" Jackie wants to take an out of town vacation in an area she doesn’t know " She wants to be pampered for her short 2 night stay" She normally stays a big hotel chains but she would consider an independent hotel with adequate references" She’s concerned with access from the airport, proximity to attractions and security " She’s found out names of the few hotels to consider and will be checking out the web sites of each

" Starting point for our example: Jackie has already decided which hotel to patronize" See speaker notes for the remainder of the story


©IBM 2001 June 2001

Slide 6


Stories - For your reference

" Business Traveler: Making a Hotel Reservation task" Robert needs to be in Boston for a 2-day business meeting " Robert travels frequently, typically several times a month" He has traveled to the same 7 cities for 4 years and has developed a routine" He has a favorite airline, hotel chains and hotel locations in each city " He usually rents a car but will take a taxi if the weather is going to be bad" He prefers to talk with a travel agent directly - he’s a stickler for having everything go exactly as planned

" Starting point for our example: Robert calls his travel agent" See speaker notes for the remainder of the story

Slide 7


Who are the real users?

" Purpose of modeling users: To create precise definitions of user groups where the basis of distinction between each user group becomes a valuable distinction for DESIGN purposes (not for marketing, system or other purposes)." Definition of user: Individuals that directly interact with the system." UCD activities:

" Review business goals" Review market segmentation (customers and users are not always the same)" Perform user profiling activity with real users " Perform task analysis activity (this activity provides information that is captured in numerous ways through out the OVID approach)

What's already known at this point: Before UCD activities should begin the business goals should be understood as well as who the market is trying to reach.

Note: There is often a lot of confusion between the terms target market, target audience, target users, target customers etc. For our purposes through out the day "customers = the buyers of your offering" and "users =


©IBM 2001 June 2001

the individuals that interact with the offering". They are not always the same. Audience is a generalization of both terms (audience = customers + users).

Slide 8


How do I create a User Class Diagram?

" 1: Review the written stories to identify nouns that are people" 2: In Rose, create a new Class diagram in Discovery Phase section" 3: Add actors (the stick figure symbol) to the diagram that correspond to the people found in the stories

Presentation point: The image contained here shows the Rose interface to but as we move forward through the presentation we'll only be showing the content of the main window.

Notice that we didn't label the user "Jackie". The person Jackie is an "instance" of a class of user called "Vacationer". Think of the difference between a "dog" as a type of mammal and "Max" as a specific dog.

Note about Rose: You won't find "Discovery Phase" as a title of a major section in the left hand pane of Rose - by default Rose refers to the first section as the "Use Case" section of diagrams. We added the "Discovery Phase" to the title of the section to clarify that the diagrams result from modeling work done in the Discovery phase.


©IBM 2001 June 2001

Slide 9



" 4: Describe “type of” relationship between appropriate actors

Definition: The "type of" relationship is generalizing the items into a higher definition. Each actor would inherit attributes and operations from it's generalized actor. In this case, the two users - Vacationer and Business Traveler are types of Guests as far as the hotel guest services system is concerned.

As we progress further into the modeling activity we will be watching for opportunities to "collapse" items into a generalization in order to simplify the model. At this point we're going to just recognize the relationship between Guest, Vacationer and Business Traveler. We'll see what happens with the distinctions as we progress.


©IBM 2001 June 2001

Slide 10



" There may be other types of users that a hotel guest services system may be concerned with as shown here but for teaching purposes we will stick to the two types of guests and the reservation clerk

Note: We are focusing on who would use the Guest Services System and the main basis of distinction between the groups will be on role distinctions. Keep in mind that position and role are NOT synonymous. Also, we are not modeling individuals - we are modeling user groups. If an individual performs different roles then they are taking on the attributes of those roles and acting as that role.

Slide 11


User Class Diagram -Detailed Description of Each Class

" For each of actors included in the model that represents a user group, we want to capture information about them that will be useful to the design effort.


©IBM 2001 June 2001

Slide 12


User Class Diagram -Detailed Description of Each Class

" 1: Open specification (or right mouse-click) on any actor" 2: Add an Attribute and a value for that attribute

Note: Notice the kind of information provided about the user group. It includes not only traditional demographic information but also behavior information, attitudinal, physical and other cognitive information that will help the design effort fully understand the users.

Point of evolution: We are working to create an "individual characteristics to user experience" model that will enable us to understand which individual characteristics tend to relate to which attributes of the user experience most closely. By creating a model of relationships based on real-world users interacting with experiences, we hope to help future design efforts use the data to more effectively factor individual differences into the design of future systems.


©IBM 2001 June 2001

Slide 13


What are the Users Goals?

" Purpose of modeling users’ goals: To define who has what goals in order to validate the distinctions between user groups and to place tasks in context of goals." Definition of goal: A result to be accomplished independent of how it is achieved." Goal success criteria: It is important to not only define the goals but also the success criteria for meeting each goal." UCD activities:

" Same activities that informed User Class diagram

Understanding goals is an important step as goals form the framework in which tasks and use cases are subsequently developed.

Slide 14


How do I create a Users’ Goal diagram?

" 1: Review written stories to identify candidate goal statements" 2: Create new Use Case diagram" 3: Add the Actors that we are working with to the diagram" 4: Create a new Class for the “obvious” goal" 5: Define the goal success criteria by adding attributes

Note: When you add actors to the diagram you are not adding them into the model again, they are contained in the model once and you are merely reusing them on different diagrams. They always bring the


©IBM 2001 June 2001

information about themselves (such as their attributes and operations) to the new diagram - just turn on the "Show attributes" from the context menu associated with each UML element such as Actors or Classes.

Slide 15



" Point of analysis: It doesn’t help the design effort very much if all the actors have the same goal, so we look to see if there are sub goals that will show a basis of distinction between user groups and that would define why users would want to use the system to perform certain tasks

The Class symbol is the bottom symbol in the symbol toolbar to the left of the diagram area of the screen.

Slide 16



" 1: Review stories again and probe for possible sub-goals" 2: Add a new Class to describe candidate sub-goals and be sure to articulate the basis of distinction" 3: Add specific goal success criteria to attribute


©IBM 2001 June 2001

Note: Notice now that there are distinctions between the user groups and the sub-goals. This helps to validate that the user group distinctions are still valid up to this point. We'll see if as we progress into modeling the tasks used to perform the goals if the distinction still holds.

Point of insight: Goal modeling is describing the users goals irrespective of the system user experience. We are still in our infancy at goal modeling and are still working to develop more heuristics to help teams to figure out the most meaningful way to approach goal modeling to help the design effort. Remember that there is no right answer to any modeling effort, the point is for the design team to make decisions that is based on user input and that somehow helps the team produce a more desirable user experience.

Slide 17


Users’ CurrentTask Models

" Purpose of modeling users current tasks: To describe the way users go about doing their tasks today so that commonality across all tasks can be identified in order to define the user experience use cases. Describing tasks inherently describes users objects with lead to object modeling." Definition of task: A set of activities performed to accomplish a goal." UCD activities:

" Same activities that informed Users’ Goal diagram" Elements of a task model:

" Starting state" Activities" Decision points" Ending state (can have multiple ending states)


©IBM 2001 June 2001

Slide 18


How do I create a Users’ Current Task Models?

" 1: Review stories" 2: Create new Activity diagram associated with Vacationer’s sub goal (Am Relaxed)" 3: Show activities performed by each role (add swim lanes)" 4: Identify starting state" 5: Add activity for each task

Slide 19



" 6: Continue to add activities for the tasks found in the stories

Note: When lines cross the swim lanes it indicates that most likely there will need to a way in the user experience to enable interaction between the two roles.


©IBM 2001 June 2001

Slide 20



" 7: Add decision points for appropriate roles and indicate activities that result from each possible decision output

Slide 21



" 8: Add ending states when a task comes to a termination point


©IBM 2001 June 2001

Slide 22



" For your reference - the rest of the task model

Slide 23


User ExperienceUse Cases

" Purpose of use cases: To state explicitly the system will support based on users goals and commonality across user tasks." Definition of use case: Statement of functionality that users expect from the system" UCD activities:

" Based on all previous modeling activities - use cases are design statement

" Defining use cases:" Review all task models" Find activities that are common to all use cases" Define highest level use cases and other uses cases that are included are types of other use cases


©IBM 2001 June 2001

Slide 24


How do I create a User Experience Use Cases?

" 1: Review all task models" 2: Create a new Use Case diagram" 3: Add actors to diagram" 4: Add Use Cases to diagram and name each" 5: Identify which actors are involved in which use case

Note: There are also other relationships that can be used when describing use cases, most notably the "extends" relationship.

Slide 25


Discovery Phase Summary

" We’ve modeled what we’ve discovered about:" Users" Goals" Tasks

" We’ve explicitly stated:" Use cases

" What’s next? - Design phase part 1" Objects including attributes, operations and states" Views in which objects are used

" Followed by - Design phase part 2" Interactions including conditions of interactions" Realization through visualization


©IBM 2001 June 2001

Slide 26


Ideas in Progress

" Modeling deployment issues - we are working on the best way to describe the deployment issues as they relate to the user experience use cases" In part 2 of the design phase deployment issues are taken into consideration

Slide 27


Ideas in Progress - Continued

" Modeling business architecture" Business goals" Resources" Processes

" Modeling market segments" Would include the culture/geographies being targeted

" Creating a model of relationships between individual user characteristics and correlations to user experience attributes

Slide 28

See Exercise 2: Tasks Models on page 125.


©IBM 2001 June 2001

Slide 29

Slide omitted.

Design I – Abstract Dave Roberts, Ease of Use, IBM, Warwick

Slide 1

Title slide omitted.

We’ve seen how we use various methods in a discovery phase to understand the situation we are working in. Now we are going to stop analysis and begin design – making proposals for how things will be in the final product.

Slide 2


The Design Process

We now take the requirements and analysis information that was assembled during the discovery phase and begin to create our Designer’s Model. Remember, the designer’s model is a plan of how this product will appear to the users. What we hope they will think when they use the product.


©IBM 2001 June 2001

Slide 3


From Discovery: Use Cases

" Use case diagrams show users and their tasks

Check-In

Check-In No ReservationBusiness Traveller

Vacationer Front Desk Clerk

Night Auditor

business traveller check in

vacationer check in

First of all we will make some small modifications to the input we were given. In this slide you can see the actors representing the various users we discovered. We have to decide whom we are designing for. In this case we know that the guest don’t interact directly with the system so we will not worry about them too much. The Front Desk Clerk and Night Auditor both perform the check in task. But we know of no reason to design different interfaces for these users.


©IBM 2001 June 2001

Slide 4


Create User Groups for Design

" Combine the users found during research into roles for use in design

Registration

(from Logical View)

Guest

(from Logical View)

Check-In



Night Auditor


vacationer check in

We use the subclass notation to show that we are treating the two groups of users the same way. The Registration actor represents both the Front Desk Clerk and the Night Auditor.

Slide 5


Assign Use Cases to User Groups

" Show relationship of design user roles to the use cases

Registration

(from Logical View)

Guest

(from Logical View)

Check-In



Night Auditor


vacationer check in


©IBM 2001 June 2001

And we connect the new actor to the use cases they are going to work on. The use case diagrams now tell us about which users are expected to complete which cases. If we need to, we can trace back from the use cases to the goals we have recorded.

In this small example we have used a registration actor. In a larger example we might have consolidated the groups of users into even larger groups, for example ‘All Clerical Staff’.

Slide 6


From Discovery: Activity Diagrams

Arrived at desk

presents credit card

agrees detail

reads name from card

inputs name from card to system

confirms details

creates guest folio

selects room

describes room

gets credit card authorization

creates key

hand key to guest

searches for reservation

Showing reservation

allocates room to guest

Showing room detail

Check in complete

Left desk

: Existi ng Sys temJulia n : Front De sk ClerkJackie : Vaca tioner

" Activity diagrams show existing process

" Drive abstract design by examining all activity diagrams in turn

" Start w ith most frequent activities

" Or activities done by the most users

" Look for objects involved in activities

We will now process the information in the use cases. The activity diagrams show us how users are doing these tasks today. We will use these to extract information on which to base our design.

We extract the data from the use cases by looking through for nouns and noun-phrases on the activity diagrams. We have to look at all the use-cases. Understanding the frequency of cases or the importance of cases helps us to give more weight to some of the objects we find. If an object occurs in many cases or in important or frequent cases then it is likely to be a good place to start your object modeling. So as you collect objects note how many times they occur and particularly, when they occur in the frequently executed use cases.

Take special not of where the lines in the activity diagram cross from one swim-lane to another. These indicate interchanges between people or systems. Try to see which object is involved at that point. These objects are also likely to be important in the design.

Slide 7

Slide omitted.


©IBM 2001 June 2001

Slide 8


The Abstract Design Process

There are four types of UML diagram we use in the abstract design phase:

What is the user’s mental model? The class diagram is first used to capture the objects the user understands, the attributes and operations on those objects, and the relationship between the objects.

What do the users do? What does the system do? The activity diagram is used (again, it was used in discovery) to capture initial proposals for how task will be performed.

What do the users need to see to accomplish their tasks? The views of the objects are added to the class diagrams.

What are the exact user/system interactions? Sequence diagrams are used to capture the interactions between the users and the system in detail.

What happens to an object as the users interact with it? State models, captured as both state diagrams and state tables, are used to capture the way in which objects change during their use.

We will take the requirements and analysis information that was assembled during the discovery phase and begin to create our Designer’s Model. Remember, the designer’s model is a plan of how this product will appear to the users. What they will think when they use the product.


©IBM 2001 June 2001

Slide 9


The Abstract Design Process

Task Synthesis

Design Outline Tasks

Design Abstract Views



Find User Objects

Have Use Cases

Create Detailed Task Diagrams

Map Object and View States

This picture shows our process in more detail. Here it is shown as an activity diagram. There are four different design activities: defining objects, documenting outline tasks and views; laying out new tasks and detailing the interactions of each object and view.

The process starts with the requirements and analysis information that was assembled during the discovery phase. The process iterates until you decide that the design is complete - moderated by testing.

Slide 10

Slide omitted.


©IBM 2001 June 2001

Slide 11


Objects

" Objects are taken from activity diagrams

" Sort objects into groups" Groups do not change final design but may allow you to arrive atthe final design more quickly

" A stronger object model when based on the concrete" Start further analysis on the left: concrete objects, people, …

AbstractUsersFormsPeopleConcrete

We search the analysis information, primarily the activity diagrams, for objects. These are in the form of nouns and noun phrase.

We have found that the more concrete the objects, the easier it is for the users to form their own model. So we have developed some categories for sorting objects. Using these categories does not necessarily alter the final design. But our experience has shown that the design proceeds more smoothly if you follow this path.


©IBM 2001 June 2001

Slide 12


Object Classification

" Concrete= Real things you can touch or walk away with

" People= Those who are managed by the system or have things saved for them

" Forms= Existing paperwork or other system

" Users= Those who operate the system

" Abstract= Anything not show above

The classification scheme has the following categories:

Concrete items are the anchor for the model so we seek those out first.

People are another sort of concrete object – you could put them in there. Perhaps it’s less insulting to be called a person than an object.

It is good to leave forms for a while so that you can justify their role. Don’t just copy the old forms into the new system or you end up just copying the old way of working in a new system.

Users have been identified already in the discovery phase. However, once we have some users we might go on to create some others to simplify our design process as in the example we showed earlier.

Abstract objects are the ones you are not sure about. Many of them are really abstract, others are just hard to classify and did not fit into any of the above categories.

Object classification is not absolute so don’t get too hung up on it. Getting things into these groups and working with the concrete things first seems to help the team approach a stable solution more quickly.


©IBM 2001 June 2001

Slide 13


Objects From Model

! Concrete! Hotel, Room, Credit Card, Key, …

! People! Guest

! Forms! Reservation, Folio

! Users! Guest (via other users), Travel Agent, Front Desk Clerk, Night Auditor…

! Abstract! Authorization, Stay, …

These are some examples of objects taken from our example. Remember, these are candidate objects for the new system. You don’t have to keep them in the new system. You can invent some new ones or reclassify them and group them.

Slide 14


Object Descriptions

! guest (gµst) n.! 1. One who is a recipient of hospitality at the home or table of another. 2. One to whom

entertainment or hospitality has been extended by another in the role of host or hostess, as at a party. 3. One who pays for meals or accommodations at a restaurant, hotel, or other establishment; a patron.

! fo·li·o (f½“l¶-½”) n.! , pl. fo·li·os. Abbr. f., F., fol. 1.a. A large sheet of paper folded once in the middle,

making two leaves or four pages of a book or manuscript. b. A book or manuscript of the largest common size, usually about 38 centimeters (15 inches) in height, consisting of such folded sheets. 2.a. A leaf o f a book numbered only on the front side. b. A number on such a leaf. c. A page nu mber. 3. Accounting. A page in a ledger or two facing pages that are assigned a single number. 4. Law. A specific nu mber o f words used as a unit for measuring the length of the text of a document. --fo·li·o tr.v.fo·li·oed, fo·li·o·ing, fo·li·os. To nu mber consecutively the pages or leaves of (a book, for example).

! Folio: The printed, itemized summary o f the charges for each room, guest or master account.

NoJargon

OneClause


©IBM 2001 June 2001

Use an appropriate dictionary, glossary or reference to check the terms. In this example I use the American Heritage Dictionary. See if the definitions fit this case. If so, then use them. It’s safer. If they are not quite right (as here) then craft some of your own.

As our example is about a hotel I used a glossary from the California Lodging Industry Association. If you want to see the CLIA glossary see http://www.ccnet.com/~oso/org/glossary.html.

The definition should not be complex or use jargon from the computer business: the definition should be a one-clause sentence, not commas, ifs, ands, or buts; jargon can only be jargon from the user’s domain.

In some cases you might wish to give temporary names and/or definitions to objects. It may be that some sort of user-study is needed to finalize these. Place names in parenthesis or square brackets to show they are temporary or not disclosed to users.

You can use various card sorting techniques to check your work, for example: write words and definitions onto cards and get users to match them up; write definitions down and get users to give them names; teach users the definitions and then see how good they are at recalling them.

Slide 15


Objects in Rose

! Use Logical View

! Record objects! Name(s) from/for the users! Definition from user’s terminology

! Use packages to collect objects into groups with diagrams

We store the objects in Rational Rose. The Logical View section is the best place to keep the designer’s model. If you are using Rose for development too then you might want to create a package within the section. That will allow you to handle the two (or more) models side by side within the same environment. In Rose and other case tools there are facilities to partition and version the model to allow many people to work on it at the same time.

Regardless of how it is stored, we prefer to have a ‘gatekeeper’ to areas of the model: someone responsible for the integrity of the whole thing and/or a section.

For example, sometimes we do team designs in a room. You may not want to take the whole time to ripple changes into the whole model in front of the team. Someone makes the critical change in front of everyone and then ripples the changes to the rest of the model offline.


©IBM 2001 June 2001

Slide 16


Class Diagram Notation

Object

RelationshipRoom

Hotel

1

n

1

n

! First add the concrete objects! Give priority to most used objects

! Used in most tasks! Used my most users! Used most frequently

! Objects have the name a user would give them

! Draw the relationships the user would understand

Objects are rectangles. The lines are for attributes and operations that you will see in a moment.

Lines between the objects and/or the actors show relationships between them. The numbers at each end, the multiplicity, represent the number of objects of that class that can have that relationship. Here, Hotel has n Room(s) and a Room can be in (only) 1 Hotel.

Slide 17



Actor

Room

Hotel

1

n

1

n

Guest

Guest History

1

1

+represented by

+represents1

! Add objects to represent people who are managed by the system

! If they are also a user then show the connection to the actor


©IBM 2001 June 2001

Actors represent users – not ‘people’. Sometimes the same people fit into both the ‘users’ category and the ‘people’ category. In this case provide an actor to show them as a ‘user’ and an object to show how the system deals with them as a member of the ‘people’ category.

In our example the Guest turns out not to be a user. So we don’t really need this actor.

Slide 18



Multiplicity

Room

Hotel

1

n

1

n

Guest

Guest History0..n

0..n

0..n

0..n

Plan to Stay

1

1

+represented by

+represents1

! Continue to add relationships between the objects! Name the relationship in user terms

! ‘If I know of a hotel then why would I want to know about a guest’?

! Consider the number of objects that might have the relationship

! Record multiplicity

You can store much more detail about a relationship or object in the case tool. There is a description foiled for almost everything on a UML diagram. So if you have a hard time finding a name for a relationship then put some notes into the description, give the relationship some temporary name and then organize some user based testing to find the appropriate name.


©IBM 2001 June 2001

Slide 19



Room

Hotel

1

n

1

n

Guest

Guest History0..n

0..n

0..n

0..n

Plan to Stay

1

1

+represented by

+represents1

Reserv ation

! For many-to-many relationships add an object to represent the relationship! An existing form is often the right object for this

! Do not add forms until you show they are needed

AssociationObject

When a relationship has many objects (n, 0..n, 1..n) objects at both ends then we have a modeling rule that you must have an association object. This is where you can identify the need for tracking objects in the system. Quite frequently these are the existing forms in the system.

Slide 20



Room

Hotel

1

n

1

n

Guest

Guest History0..n

0..n

0..n

0..n

Plan to Stay

0..n

0..n

Stay

Folio

1

1

+represented by

+represents1

Reserv ation

Here is a reasonably complete model for our hotel example.


©IBM 2001 June 2001

Slide 21


Room

Smoking : boolean = False

check in()check out()

(from Logical View)


Attribute

Operation ! Consider the attributes (or properties) the object might have

! Smoking – attribute name! boolean – attribute type! False – initial or default value

! Add operations, the things you can do to the object

! Can add parameters

Attributes are the extra detail of an object. They are normally found in the activity diagrams. Sometimes you have to infer them. You don’t have to find types or values for them at this stage if they are not obvious, they will emerge in much more detail as you progress with design.

Operations are the verbs from the activity diagrams. Again, if you don’t find them now don’t worry too much. We will look for verbs again when we get to our interaction diagrams later.


©IBM 2001 June 2001

Slide 22


Room



(from Logical View)


Aggregation

Room


(f rom Logical View)

boolean

Smoking

! Another equivalent notation for an attribute

! Use when you wish to draw attention to the class of the attribute or when there are relationships w ith the attribute

The two notations for Smoking in this slide have the same meaning. Choose the one on the left if the attribute is not of major concern. The notation on the right is more useful if there are significant relationships with the attribute itself.

In a case tool it is possible to have items shown in different ways on different diagrams. This allows you to have a diagram that shows specific concerns. You can hide or show detail about an object according to the subject you are dealing with at the time. For example, if you were dealing with the same object in different contexts you might some attributes and operations in one context and different attributes and operations in another context. If you need more information about an object or relationship then you can always drill-down in the tool to get the information even when it is not shown on the current diagram.


©IBM 2001 June 2001

Slide 23


Room



(from Logical View)


! If processes depend on the state of an attribute then consider using a subclass or type-of relationship

! Users consider the subclasses to be different in character! Relationships tosubclasses differ

Subclass

Room(from Logical View)

non-Smoking Room Smoking Room

Subclasses say when something is like another, but a special version. Here, instead of showing the smoking and non-smoking rooms by a change of attribute we might show it as a pair of subclasses of the Room. This notation would be more appropriate than an attribute notation when the processes differ from one object to another. In the case of the hotel room this might well be appropriate as these days there is often a procedure to charge a guest when they smoke in a non-smoking room.


©IBM 2001 June 2001

Slide 24



Guest

Guest History

1

1

+represented by

+represents1 Role

! If a relationship is difficult to name then use roles

! + sign indicates a role, not a relationship name! A name for the way an object participates in a relationship

! Aggregation is an implied role

Here’s another use of that word role in our work – this one comes from UML. The label ‘+represented by’ is the role of the Guest with respect to this relationship to a Guest History.

Slide 25


User Objects - Summary

! Examine all use cases! Most frequent first

! Find objects in use cases

! Classify objects to speed design

! Define objects in user’s terms

! Define relationships as the users would understand them

! Add attributes and operations


©IBM 2001 June 2001

Slide 26

Slide omitted.

Slide 27

The swim lanes in the diagram indicate where responsibility lies. Make sure the decisions, processes and states go in the right column.

Whenever a line crosses between one column and another then you have communication. In this diagram either the Clerk is putting data into the system or the System is showing information to the Clerk. These are the points where views will be required.

Slide 28

Slide omitted


Propose Task Outline

! Show how tasks will be completed in the new system

! Do not have to match existing practice, but be aware of the learning required by the users

! Capture overview of task in an activity diagram! High level at first

! Treat system as a black box! Only reveal essential detail! Similar to essential use case from Constantine and others

! Show where process occurs and decisions are made ! Note when goals or sub-goals are achieved by using states

Has requ irement from guest and has se lected hotel

propos e dates

select best dates

complete guest detai ls

specify room options

specify payment method

reserve

Has reservati on ready for client

Any acceptable?

find avai lability for dates

Showing available dates

reserve dates

request details

gener ate reservation num ber and complete al l process ing

Show confirm ed reservation detai ls

no

: System: Reservation Clerk


©IBM 2001 June 2001

Slide 29


Define Starting View

View

Make A Reservati onpropos ed dates

U:Propose Dates()

<<View>>

Guest

(from Logical View)

Reservation Clerk

(from Use Case View)

User starts here

! Process most frequent or most commonly used tasks first! Start by creating a view w ith the data needed

Has requirement from guest and has selected hotel

propos e dates

select best dates

Any acceptable?

find avai lab ility for dates

Showing available dates

reserve dates

no

: System: Reservation Clerk

Views are recorded as a class with a stereotype of ‘view’; shown as <<view>> on the diagram. This allows you to distinguish views from object. Each view contains the parts of the objects (the attributes) that are required for the task.

In our example here we have made an initial view that corresponds to the first part of the interaction shown on the fragment of the interaction diagram shown bottom right. ‘Proposed dates’ occurs as an attribute of the view to indicate that the user has to interact with the proposed dates. Propose Dates() is shown as an operation on the view because the Clerk has to send that information to the system. If we were to proceed down the activity diagram we would next add an attribute of Available Dates to provide space for the dates returned by the system to be shown to the Clerk. The third arrow that crosses the swim-lane boundary would require us to put another operation on the view by which to select the date.

When another object becomes involved in the interaction you should then add a view to that object…


©IBM 2001 June 2001

Slide 30


Connect More Views

Create a Res ervation<<View>>Make A Reservati on

propos ed dates

U:Propose Dates()

<<View>>

Guest

(from Logical View)

Guest for Reservation'detai ls'

<<View>>

Reservation Clerk


ReservationSmokingdate of startdurationconfirmation numberpayment details

Guest History'detai ls'

0..n0..n

Plan to Stay

<<view>>

<<view>>Relate to object

! Proceed from initial view to the other objects required for the task! Views can only show data from ‘parent’ object

Views must be a view of some object. We show the object that owns the view by an aggregation relationship with a stereotype of view (shown as <<view>> on the diagram). Views can only show the owning object – the attributes that the object also has. If there is a need to show another object then we connect to a view of that other object.

The views can be connected together to show how the user navigates from one view to another. This forms the navigation map for the product. At first you can just put on unlabelled ‘uses’ arrows. Later you should name these arrows. They become implicit operations of the view they exit from. For example, later on in our design we labeled the arrow from ‘Make A Reservation’ to ‘Create a Reservation’ as ‘Reserve’ (See slide 19 of the Design II section of this document where the word Reserve emerges as a button next to each of the available dates). Making the decision to transfer to another view means that the third arrow on the activity diagram (see previous slide) is now catered for.


©IBM 2001 June 2001

Slide 31


Anchor To Object

Note

Room availabil ity for a given date can be found from reservations and capacity

ReservationSmokingdate of startdurationconfirmation numberpayment details

Create a Res ervation<<View>>Make A Reservati on

propos ed dates

U:Propose Dates()U:Accept()

<<View>>

Guest

(from Logical View)

Hotelcapacity

Guest History'detai ls'

0..n0..n 0..n0..n

Plan to Stay


<<View>>

Reservation Clerk


<<view>>

<<view>>

<<view>>

! Objects are not required for transient data! Add notes to describe how transient data can be derived

Transient data such as the proposed dates do not have to be part of the containing object. But when you do this remember that the next time the user comes to the system they will not be able to see that data. Data that is only in a view is transient data.

You can add notes to explain how data is to be derived from other objects.

Slide 32


Navigation or Embedding?

Navigate

Embed

Make A Reservat ionproposed dates


<<View>>

Create a Reservation<<View>>

Guest for Reservation'details'

<<View>>

Create a Reservat ion<<View>>Make A Res ervation

proposed dates


<<View>>


<<View>>select

! Examine transfer of data from one step to another

! Use ‘aggregate’ to embed when data must be seen concurrently! Use ‘depends’ to show navigation for consecutive display

! May be adjusted in later design


©IBM 2001 June 2001

Often in the early stages of design we may start these relationships as navigations and then change them to be aggregations later (of course they can change back again). This is done when you recognize that a user will need to see a collection of information in one chunk. This is all part of adjusting the design and you will see more about this in the next part of this presentation (Design II – Realization, page 75).

Slide 33


Wizard Example

! Can use a combination of embed and navigate to model a wizard

! Steps are embedded in the main view

! Navigation shown between steps

Step 1: Propose dates<<view>>

Create a Reservation(from Making a reservation)

<<View>>

Step 2: Select stay<<view>>back

next

This is an example of how patterns in the model correspond to typical styles of user interaction. A wizard is represented as an aggregated collection of views with navigation shown between the steps.


©IBM 2001 June 2001

Slide 34


Site-wide Feature Example

site wide featuresSite wide property

Site wide operation()

<<view>>

Home page<<view>>

home

news page<<view>>

buying page<<view>>

News Index<<view>>

index

view Basket<<view>>

basket

! Can use subclass notation to show how a page groups have similarfeatures

This design pattern shows how you can use subclasses to provide common features on groups of views. The elements of views that are higher up in the scheme are inherited by all the views further down the tree. In this example all pages have a connection to the home page.

Slide 35


Abstract Views - Summary

! Find the objects that are involved in the task! Select the attributes/properties of the objects

! Add views to the class diagram! Name each view for the task! Show details of which attributes are needed! Connect views to a main object

! Must have access to all information required for that view! If the information is not accessible then either you have chosen

the wrong object or you have the relationships wrong! Consolidate later

! Look at patterns in the model as an opportunity for reuse! Benefits both implementers and users

! Either before or during visual/interaction design


©IBM 2001 June 2001

Slide 36

See Exercise 3: Views on page 126.

Slide 37

Slide omitted.

Slide 38


Task Flow in Detail

: Reservation Clerk

: Make A Reservation

: Create a Reservation

: Guest for Reservation

propose dates

show availability

request specific reservation

transfer reservation dates

request smoking information

smoking information

open view

open view

supply 'details'

confirm reservation

timing depends on embed/open decision

! Use interaction diagrams to show detailed plan for a task

! Include users and views in the diagram

! Can include objects when the synchronization between the view and the object is critical

! For example, systems with time dependant information! But users must not communicate directly with objects

Here the new task flow is shown in the form of a Sequence Diagram. You may choose to use the Activity Diagram instead.

The columns in the chart represent views and users. The horizontal lines show interactions, called transitions, between these parties. The transitions initiated by the user will become commands in the interface. Some of them refer to the user making settings or entering data into fields. Others may refer to actions and others may be shorthand for a combination of these.

These diagrams normally have users and views as the main columns but the interactions with objects can be included. Remember that users may not interact with objects. The users may interact with the views and then the views may interact with other views or with the objects.

In this example the phrase ‘propose dates’ may refer to a combination of entering data and then pressing a button. As the design proceeds, the detail will increase and the diagram will show more and more of the interactions.

When you do a design you have to decide how far to take the abstract design as it transitions towards a physical design. The more physical detail you show the more difficult it will be to transfer the product to different implementations (such as between Web and WAP).

We have to look back at the use cases from the discovery phase and see if we have all the diagrams needed to accomplish the cases they need.


©IBM 2001 June 2001

Slide 39


Formalize Names

Operation name

: Reservation Clerk

: Make A Reservation

: Create a Reservation

: Guest for Reservation

timing depends on embed/open decis ion

U:Propose Dates( )

show availabili ty

Select( )

transfer reservation dates

request smoking information

smoking informat ion

Open View( )

Accept( )

open view

supply 'details'

! Formalize the names of the transitions as operation names

! Allows you to accumulate operations for a view over many diagrams

The major advantage of the interaction diagram is the opportunity to formalize transitions. When doing the early designs the transitions are informally labeled with the intention. Later they can be converted to Operations. The benefit of doing this is that it crosschecks these diagrams with those recorded in the class diagrams as operations of views and objects.

Slide 40

Slide omitted.


©IBM 2001 June 2001

Slide 41


State Diagrams

Start State

End State

TransitionConfirmed

Being CompletedCreate

Transfer Reservation Dates

Confirm

Transfer Smoking Information

Check In

! Use state diagrams (HarelDiagrams) to show normal processes for an object or a view

! View may have different states such as showing a snapshot

! Transition names should correspond to operations! Can adopt convention to distinguish user operations from system operations in views

! ‘U: Confirm’ ! Convert to state tables to examine all combinations of states and transitions

State diagrams (also known as Harel Diagrams) are used to show the state changes for both objects and views. For some cases, such as Reservation, the object has a life cycle that starts and finishes. Others, such as the room, are not created or destroyed; they exist all the time but may change state.

It is easier to document the normal case for an object on this diagram. If you try to document all of the conditions the diagram gets too crowded and is too hard to read.

The names of the states and the names of the transitions should be in terms your user understands. The state names are not always revealed to the user. For example, it is possible that a reservation might be ‘confirmed’ and ‘not confirmed’.


©IBM 2001 June 2001

Slide 42


State Table

To ConfirmedConfirm

To Being Completed

Transfer Smoking

To Being Completed

Transfer Dates

To [final]Check In

To Being Completed

Create

Being Completed

Confirmed[initial]Transition

State

Here is the same diagram laid out as a table.

The columns are states and the rows are events. Each intersection represents what happens when the event occurs in the state. In this example I have only shown the next state. You can go into lots of detail with what happens and capture that in the model.

The important thing after the transposition is to look at all the blank transitions. These represent the places where users might be trying to perform an operation that was not on the main path. Deciding how to react in each of these situations is a vital part of designing the product. Reacting in the most appropriate way for your users is the difference between an application that works and one that feels ‘just right’.


©IBM 2001 June 2001

Slide 43


State Table

To ConfirmedConfirm

To Being Completed

Transfer Smoking

To Being Completed

Transfer Dates

To [final]Not available to the user

Check In

To Being Completed

Create

Being Completed

Confirmed[initial]

Here we have started to fill on some of the blank spaces. The only transition available from the initial state is Create as the user will not have seen this object yet.

Slide 44


State Table

To ConfirmedConfirm

To Being Completed

Transfer Smoking

To Being Completed

Transfer Dates


Check In

Create is internal action so not available to the user

To Being Completed

Create

Being Completed

Confirmed[initial]

Next we blank out the other intersections for Create as this is something that is done implicitly by the system.


©IBM 2001 June 2001

Slide 45


State Table

To ConfirmedConfirm

To Being Completed

Transfer Smoking

To Being Completed

Transfer Dates

Must be confirmed


Check In


To Being Completed

Create

Being Completed

Confirmed[initial]

We show that check-in is not available from a reservation that has not been confirmed.

Slide 46


State Table

To ConfirmedNot allowedConfirm

To Being Completed

Transfer Smoking

To Being Completed

No changes are allowed once a reservation is confirmed

Transfer Dates

Must be confirmed


Check In


To Being Completed

Create

Being Completed

Confirmed[initial]

And finally show the things you cannot do with a confirmed reservation.


©IBM 2001 June 2001

Slide 47


State Modelling - Summary

! Model normal path in state diagram! Models can be done at many levels, from the state model of a business object to the model of a roll-over on a web page

! Convert to state chart

! Examine all empty cells and decide what should happen! Completing the empty cells avoids late design decisions! The difference between a design that does the job and one that is compelling

Slide 48


Completing Abstract Design

Exit abstract design when you have! Processed all the use cases! Found or created no new objects in last pass! Validated the model with users

! Typically done using low fidelity prototypes

Task Synthesis





Find User Objects

Have Use Cases

Create Detailed Task Diagrams

Map Object and View States

Slide 49

See Exercise 4: State Models on page 126.

Slide 50

Slides omitted.

Design II – Realization Didier Bardon, Ease of Use, IBM, Austin

Slide 1

Slide omitted.

Slide 2

June 10, 2001 2OVID Tutorial, IBM Ease of Use Group Slide number

Introduction

" Realization phase overview

" Design activities• Object representation• Visual design and interactions realization• Verification of the user experience fidelity and clarity

" Recording and managing the results of the realization phase• The Presentation View Model

" Exercise


©IBM 2001 June 2001

Slide 3


The Realization Phase

Slide 4


The Realization Phase

" Goals• Orchestrate all concerns• Insure fidelity and clarity with respect to the abstract design• Record the results in the Presentation View Model

We use the term “Realization” to emphasize the main goal of the design phase: taking the abstract definition of the user experience provided by the previous phase and transforming it into a real, visible and palpable user experience.

Although very abstract, the abstract definition is detailed and complete. All its contents must be transferred intact into the final presentation. The main goals of the realization phase are 1) to insure that the abstract definition of the user experience is entirely and accurately reflected in the final presentation: Fidelity, and 2) that the elements supporting


©IBM 2001 June 2001

the user experience, the objects and interactions, are clearly perceivable by users and that no extraneous elements are ntroduced that would blur the perception: Clarity.

Bring the abstract user experience into the real means that environmental and technological concerns come into play. (Provide quick definition of all concerns). Environmental and technological concerns are well known by designers in the field, so they will not be the main focus of this presentation. 1) The main point is that the abstract definition provides the fundamental structure of the final experience, and is therefore the driving force in the realization phase.(develop) 2) How do the environment and technology concerns affect the realization of the abstract design. (Will there be conflicts, or trade offs to be made)

The activities of the realization phase result in one or several presentations of the user experience. In the abstract design, only one set of view definitions is needed (Abstraction -- keep possibilities open). With the introduction of environmental and technical concerns, several different presentations of the user experience may be necessary (cultural or platform necessities). Each design may includes significant extensions to the abstract definition of the user experience, as well as a large quantity of visual and interaction implementation specifications. To manage this information, insure maintainability and easy accessibility to this information by the design and implementation team we are proposing the Presentation View Model.

The design activities of the realization phase require the usual competencies of visual design, the familiarity with the current interactive computing platforms and the established conventions of user interface design. These competencies are not the focus of this tutorial. The focus of this presentation is to show how the information contained in the abstract definitions can inform the design decisions that have to be made at the realization phase. We recast visual and interaction design in the context of OVID, and show how this method facilitates the design tasks and renders them more efficient.

Slide 5


OVID Diagrams As Input To Presentation View Design

The abstract design phase provides the foundation of the user experience. It is skeletal, but complete. It makes important design decisions that are key to the usability of the final product, but it leaves open a wide field of possibilities. During the realization phase, the design team uses this leeway to flesh out the user experience. The experience can be adapted to sit well within a particular visual trend, to carry a particular brand or to address a particular age group. It can be done safely, provided that the foundation from the abstract design is carried through.

We have seen that the abstract user experience design is delivered as a set of diagrams. Each diagram describe one aspect of the user experience. I have gathered on this slide the diagrams that are the most useful as input for the activities of the realization phase, visual and interaction design (brief description of each). To safely carry the abstract


©IBM 2001 June 2001

design through to the presentation views, the design information must be extracted from these diagrams and used to inform visual and interaction design choices.

In the following, we will look closely at these diagrams, to discover what useful information each one contains, and which aspects of the design they will help drive. We will use the diagrams associated with the task of “making a reservation”. We will use the information they provide to design a set of presentation view that will indeed support the intended task.

In this process, we will naturally make decisions that will have been influenced by environment and technology. We will look at the results of these influences and show how they affected the design.

Before we proceed, I need to go back to the notion of Fidelity and Clarity I mentioned before, and explain better the meaning I give them in the context of this process.

Slide 6


Fidelity and Clarity

" Fidelity to the Abstract Design • All the elements defined, and the decisions made in the AbstractDesign must be reflected in the Presentation views• No extension to the design should be made, or element added thatdo not have roots into the Abstract Design

" Clarity of objects representation• The objects, discovered during the Abstract Design phase, shouldbe perceivable by users as they interact with the system• User objects should be recognizable along the flow of the user experience• The states changes of objects as user interact with them should be perceivable

" Fidelity to the Abstract Design and Clarity of object representation are the contribution of visual design to the usability of the product

The requirement for Fidelity to the Abstract Design seems evident. It is actually well worth mentioning. A visual designer that would misunderstand the role of visual design in this context, or get carried away in achieving a cosmetic effect could easily jeopardize the potential benefits afforded by the previous phases of the process. (Tufte’s “Above all, do no harm”).

The designers that understand the value of the abstract design (user-centered) become its custodians. They do not see in it a limitation of their creativity, but relish the challenge of bringing it to users while orchestrating the concerns of environment and technology.

It is therefore important that the visual designers that are active in this process gain intimate familiarity with the modeling process, learn enough of its language to be able to use the diagrams naturally.

All that’s there, none of what’s not there. We remember that the objects in the model have not been arbitrarily created. They have been discovered, and are reflecting the users mental model. Adding extraneous elements that do not necessarily correspond to tangibly to users mental model is taking the great risk to sever the connection to users that the entire process is seeking to establish.

For similar reasons, the clarity of the objects representation is pivotal to the success of the realization phase. Users, when accomplish their tasks interact with object through views. These views will be clear, become familiar as they use them only if they can recognize the objects with which they are dealing, their differences and their relationships. The clarity, the transparence of the user experience depends on users recognizing the objects of their mental model in the views with which they interact.


©IBM 2001 June 2001

Good usability is obtained, when all is said and done, when all phases of the process have been executed with sensitivity and talent. The realization phase contributes to usability by providing Presentation Views that are faithful to the Abstract Design, and that support a transparent user experience through clear object representations.

Slide 7


Objects and Views in the Realization Phase

" Presentation Views are compositions of Object Views

" Through each different presentation view, users gaze at the same object model

It is easy to get confused at first by the different kinds of object views that we deal with in the OVID method. In this section, I will call “Presentation Views” the views with which the user interacts and “Object Views” the views of single objects that enter in the composition of Presentation views.

We have seen that in the course of their experience with the system, users interact with objects through Presentation Views. There is a single object model that contains a limited number of objects. There is several presentation views in the system. Each one supports one or several tasks. In each presentation view, some of the objects in the model appear as object views. Each object view in the composition displays the attributes and operations of the its parent object that are needed to accomplish the task.

It can be said that with each presentation view, users can gaze as the object model from a particular angle. Or, it can be said that through every presentation views, users look at the same object model or part of the same object model.

These remarks are very important. They are the premises of the visual design effort in the realization phase. They spell out for us how the user interaction with the presentation view can be made transparent, and why the clarity of the object representation is crucial.

The visual design effort will strive to bring the experience as close as possible to transparency. As the users go from one presentation view to another while accomplishing series of task, the views will become more and more familiar as the objects that appear and reappear are recognized. With a successful visual design, the users should feel that they are always dealing with a set of familiar entities, entities that they were expecting to deal with in the first place.

Recognizing objects doesn’t necessarily means that users will explicitly recognize objects as they work with the system, or that they are expected to attend to object recognition. Again, we are looking for transparency. We want the user to benefit from the fact that objects are recognizable and differentiated from each other.


©IBM 2001 June 2001

Slide 8


Three Levels of Concern

When approaching the visual design effort in the realization phase, it is useful to consider 3 levels of concerns: The objects themselves, taken individually, and in relationship with each other, Each views in the system that support a particular set of task, and the entire experience presentation, consisting of all the task supporting views in the system, their relationships and the flow between them.

The different levels of concern shown on this slide shouldn’t be taken for steps in a linear process. They represent the “Layers of thinking” that are included in the process. When making each design decision, the designer has all these levels of concerns in mind. The thought process goes freely from one to the other, as each level is tightly related to the other.

It is useful to have these levels in mind. Each level presents different design challenges and the visual design need to achieve different kinds of goals. At each level different design decisions can be made that are informed by different diagrams from the abstract design. These different goals are complementary. It is important for the designer to understand them, and understand how they contribute to the success of the user experience realization effort

At the level of individual objects, the designer makes the choices that will ensure that users will differentiate objects from each other, learn their particular appearance and recognize them along the flow of their experience with the system. In effect, the designer is building a distinct visual identity for each object visible to the user. For this task, information will be found in the object model, and the choices will be strongly influenced by the environment.

The bulk of the design decisions are made at the presentation view level. Object views are assembled. They must be laid out in a manner that reflect the “role” of each object in the accomplishment of the task. The mechanisms that will support the interactions with the view are chosen. Decisions such as embedding object views within one another or letting the user navigate from one to the others are made. The information is found in the abstract view diagrams as well as sequence, and object states diagrams. The choices are influenced both by technology (platform) and environment.

When considering the entire user experience, most of the design decisions have been made. The effect of the decisions made for the two other levels is verified and adjustments made (Team Reviews). When presentation views are considered in the context of the user experience, new problem arise, usually with transitions between views that have to be solved. When all adjustment to the design are made for an iteration, a prototype can be created.


©IBM 2001 June 2001

Slide 9


Object Representation: Visual Identity

For an example, we will step through the design of the presentation views that will support the task of making a reservation. Before we consider the design of these presentation views we will consider the objects in the hotel model and build their distinct visual identities.

How do we make objects from the model visible? User objects are still very abstract entities. They have a name, a list of attributes and a list of operations that can be applied to them (Input form the object model). How can they be made visible without adding extraneous elements (Fidelity). Making the attributes visible will do the job. The object manifest itself through the appearance of its attributes. In effect an object view is a collection of an object’s attributes, surrounded by a boundary. (ex: Room object). The object’s attributes become visual elements that are the building blocks of the object representation.

The visual identity of an objects is built by carefully determining how each of its attribute will be represented. In the views of an object, the combination of these attributes will convey a unique appearance to that object. (ex: the five objects). Each time an object is encountered along the flow of experience, the same combination of visual elements is seen, which help recognition. Of course, the visual identity of objects is relative. The choices made must ensure that each object’s set of visual building blocks yields combinations that are truly unique within the system.

The choice that are made for the representation of object attributes are influenced by the environment that surrounds the product. The environment is actually a source of potential visual choices. It can be said that the environment provides a palette of visual elements to choose from when building the visual identity of the objects in the system. The possibilities of typography, color and imagery are virtually infinite, but the environment conveniently restricts the choices in a meaningful way, helping the object representation’s relevance to the audience. The product will speak their visual language.

Ex: the mental model of the audience may provide useful mental images; the current trends in visual design or the established conventions in the product domain will also offer a choice of possibilities. A brand system might have to be carried, which also can usefully restrict the palette.

Object can be represented without adding extraneous visual elements (not rooted in the abstract design). Metaphor can be used in representing attributes (smoking/non smoking). When beneficial to object recognition, metaphorical adornments can be used. Such elements are usually not rooted in the abstract design.


©IBM 2001 June 2001

Slide 10


Visual Identity Across the User Experience

" Each object appears in several views, in different capacities

" Each object’s visual identity must stay perceivable in all views

Ensuring that the visual identity of objects remains perceivable in all views presents a challenge to the visual design. We have seen that each object views in the systems presents only a subset of the attributes of its parent object. It presents only the attributes that are relevant to the task at hand. (Show object 2 views)

This means that different views of the same objects will have a different combination of visual building block. How, in these circumstances could the combinations of building block look similar enough, and be unique enough to carry a visual identity?

Practice shows that within the attribute list of an object, there is a few attributes that appear almost in all occurrence of the objects, no matter how minimal the view is. The remainder of the attributes appear only in the more detailed views of the object. We call the former the identifying attributes. Because of their quasi constant appearance in the views of the object, they contribute the most to the visual identity of the object. The designer should look for them (abstract view diagram), and be aware that the visual identity will depend mainly on their visual appearance.


©IBM 2001 June 2001

Slide 11


Two Occurrences of the Same Objects

Making a reservation

Checking in

We are looking at two view of the same object combination, Reservation/Guest, for supporting different situations, making a reservation and checking in.

On the left are the simplified abstract view diagrams within which the two views are defined. Further in the presentation we will focus on the layout information that is contained in these diagram. For this example it is sufficient to realize that the two diagrams describe different task situations, and there fore the object views will have a different combination of building blocks.

In the make a reservation situation, the guest is in the process of completing a reservation by providing his or her personal information. A view of the guest object is embedded in the view of the reservation object. The user is dealing with all the attribute of the Reservation and the Guest object, so the view displays all detail. All the attributes are visible, and the visual identity is easily perceived.

In the checking in situation, the clerk is looking for the guest’s reservation in a collection of reservations. The task at this point is simply to select an object out of a list, so the views of the objects display only a small selection of their attributes. The view of the Guest object is also embedded in the Reservation object.


©IBM 2001 June 2001

Slide 12


Two Occurrences of the Same Objects (cont.)

Each object is given its visual identity by applying to its attributes the visual specifications that were selected (ex)

The identifying attributes are easily seen. The reservation has few attributes that end up being all displayed in the abbreviated view. It is the combination of these attributes and the unique background color that carries the visual identity. The guest object has one strong identifying attribute, the guest’s name. It was given typographic specifications that help make it unique and conspicuous. It’s combination with the unique yellow background carries the visual identity. In this system, all Bodoni Italic text on a yellow background will be associated to an instance of a guest object.

When the clerk needs to see the details of the reservation, access will be provided through the small view in the list. The transition between small and detailed view would be made seamless by the strong visual identity. The similarity of appearance would implicitly confirm that the same objects are being dealt with. In this situation if the clerk is interested with the guest data only, the visual identity of the guest object will help him parse the new view quickly, and direct his gaze toward the yellow field with the italic type.

A guest object that represents a guest already in the hotel (checked-in), will not be presented in the context of a reservation. A list of reservation and a list of guest already in the hotel will have a different appearances, helping the clerk differentiate them.


©IBM 2001 June 2001

Slide 13


Presentation View Design Input From The Abstract View Diagrams

" View specifications indicate which objects are involved, and which subsets of object attributes will be presented

" View specification titles indicate the object’s role in accomplishing the task

" “Uses” relationships indicate dependencies w ith respect to the task

" The actor indicates which subset of the audience w ill interact with the presentation view

Abstract view diagram for the “making a reservation” task.

We are leaving the issues of object representation to focus on the layout of presentation views. We will examine each OVID diagram that is relevant to presentation view design, identify the information it contains, and show how we make use of it in the design.

This diagram defines the view that will support the “make a reservation” task, in a skeletal manner. Part of the object model, the objects that are involved in the task, is shown. To each object is attached a view specification that indicates the subset of attributes and operation that have to be presented. (the diagram above is simplified). By this, we learn which objects are involved, and how much details each object view will present. This defines the main elements of the presentation view composition.

The title of each view object indicates the role played by the object in the accomplishment of the task. The “Hotel” role is to support the entire task of “Making a reservation”, which indicate its coordinating role. The “Reservation” and the “Guest” objects have more specialized roles. By looking at the attributes and operations specified in the view definition, the designer gains an understanding of the objects role. The interaction sequence diagram will help complete that understanding.

In UML the connections between the view definitions (dotted arrow) denote the “uses” relationship. In effect, to support making a reservation, the “Hotel” object uses the “Reservation” object which in turn uses the “Guest” object. In the presentation view design, these relationship will translate in layout or navigation decisions (ex: embed, juxtapose, open, replace)

The guest actor in the diagram indicates that the hotel customer that will be the human being using the view. It indicates to the presentation view designer that the user will not be familiar with the system. It actually may be the user’s first encounter with the system. This will lead to avoid short cuts, and to support the task in a very explicit way. It also indicates that the user will be a customer of the hotel. This view could be the first contact of the customer with the hotel, which may lead, for example, to give more emphasis to the hotel corporate image.

Note that the actor wasn’t made to look directly at the reservation which could have been plausible.


©IBM 2001 June 2001

Slide 14


Presentation view DesignUsing the Input form the Abstract View Diagrams

The sketches above could have been made by a presentation view designer after examining the abstract view diagram we just studied. They represent two alternatives for the same view design.

Let’s look a the first one and identify the three objects and their attributes.

Let’s look at the layout from the stand point of the role of each object. In this layout the “Hotel” seems to take the role of containing the objects necessary to create a reservation, which is probably the understanding that the designer has so far. The “Reservation” receives the guest request, and present the “Guest” object to allow the customer to provide his or her details.

The “Uses” relationships have translated into embeds. The object view that is used by another object is embedded into it.

In this sketch, the “Hotel” view asserts the identity of the hotel, while the reservation object, which is related to the main purpose of the task occupies the most space.

With the second sketch, the designer seem to have decided to let the view of the “Hotel” do more than assert the hotel identity, but provide more visual information about the hotel. The ‘Hotel” view becomes a stand alone from which a view of the “Reservation” can be open with a view of the “Guest” embedded in it.

It is important to note the flexibility afforded by the abstract definition of the view. The abstract definition prescribes only the basic structure of the experience. The visual and interactive implementation of it is left quite open. In this example, the abstract design of the view can be implemented in many different fashions. The design can therefore be applied to many different hotel situations.

Where does hotel landscape image come from? Is there an attribute for it in the “Hotel” object? It is plausible that during the abstract design phase, the designers have foreseen the need for promotion or the display of touring information in some of the “Hotel”is view. Attributes such as Hotel corporate ID assets or Hotel location imagery, would exist.


©IBM 2001 June 2001

Slide 15


Presentation View DesignInput From Interaction Sequences Diagrams

" The state diagrams clarify the interaction information that was left to interpretation in the Abstract Views

" Knowing all the steps involved in the task helps decide to embed object views or to use navigation

" Knowing which steps are supported by an object completes the information needed to plan its view in the composition

Interaction Sequence Diagrams unfolds a task step by step along a time line, and indicates precisely which actor or which object is involved in executing each step. The information is very useful to the presentation design effort. It disambiguates the information that was left to interpretation in the abstract view diagrams. Decisions about the implementation of interactions can be made or finalized.

By looking at the time line, the presentation view designer can discover all the steps involved in accomplishing the task, and in which order they need to occur. In our example, the guest provides a set of dates, the hotel returns for which dates there is rooms available, the guest requests to reserve, the hotel records the dates, the guest is asked if a smoking room is desired, the guest answers the question, the guest provide details and confirm the reservation. Steps that had to be interpreted from the abstract view definition (which is not time based) are now clearly indicated. (ex: the exchange of dates and availability, confirmation).

With this information, the presentation designer can make educated decisions about embedding views or using navigation between views. By knowing precisely the sequence of steps in a task, the designer can judge whether the sequence is short enough with a light enough cognitive load to make the embedding all all object views into a single presentation view practical.

By considering the columns of the diagram, the presentation designer sees which object supports which steps. In our example, the “Hotel” object supports the exchange of dates and availability as well as letting the customer request a particular available dates. The “Reservation” object receives the dates selected by the user, supports the exchange about a smoking/non-smoking room and receives the customers confirmation of the entire operation. The “Guest” object merely receives the detail information from the customer.

Knowing which steps is supported by a particular object completes the information that is needed by the presentation view designer to create the layout of the object view. It is now possible to decide which set of mechanisms will support the interaction that is necessary to perform the steps.


©IBM 2001 June 2001

Slide 16


Presentation View DesignUsing Input From Interaction Sequences Diagrams

The presentation designer could have drawn the two sketches above, taking advantage of the information obtained from the interaction sequence diagram for the task at hand. This time, the sketches represent one alternative of the presentation view. We can recognize the “Hotel” object which provides an access to a view of the “Reservation” object. Like before the “Guest” object is embedded in the “Reservation” object.

The sketches are further in the design process. They now show interactive controls, and the designer is satisfied that the presentation view will support all the steps of the task. The “Hotel” view now seems to contain a new thing, a “Vacancy Finder”. Is this a new object? We’ve seen that the requirement for fidelity to the abstract design forbids the introductions of extraneous elements.

In effect, the designer realized that the “Hotel” object had the important role to support the exchange where the customer supplies dates and is proposed vacancies. A interactive mechanism had to be designed to support the exchange. The designer knew from the object model that the “Hotel” object has a method that accepts dates as input and goes to query the schedule of every rooms and return true if some rooms are vacant for these dates. The “Vacancy Finder” was designed to allow the method to obtain its input from the user and to display its results. So the ‘Vacancy finder” is not a object, it is an interactive mechanism that exist only at the presentation view level. It could have been named differently or not named at all.. It could have been designed differently. (describe functioning of Vacancy Finder)

The “Reservation” is created from the “Hotel” view with the button that appear in the Vacancy Finder when a set of dates corresponds to vacant rooms.

The “Reservation” view now supports the step of confirming. Note that the view of the “Reservation” is contained by the “Hotel” in both views. It is conform to the abstract view definition. It comforts the customer that at each step of the task, he or she is always dealing with the “Hotel”.


©IBM 2001 June 2001

Slide 17


Presentation View DesignInput From States Diagrams and Tables

" The states that are meaningful to users are identified and must be made perceivable by users

" Some states are transparent to users, or receive implicit visual feedback

We have seen that as the user experience takes place, the states of object may change. The abstract design phase strive to record all the state changes along the life cycle of an object by creating the diagram shown above. The state diagrams record the states changes through all the steps of a task. The state tables looks at all the combination action/object, to ensure that no state change as been ignored.

The presentation view designer knows that most state changes are meaningful to users. Some state changes are initiated by the system. The users need to be able to notice when the change occur and to understand its implications. Some state changes are initiated by user actions, and users need to be given explicit feedback as well.

The designer must examine the states that each object assumes along the steps of the a task, and determine when a state transition must be signaled, and how to signal it. An object may have states that are perceivable by users implicitly, without out any special feedback provided. (Ex: the state of being completed for the “Reservation”). Some object states are important with respect to the task at hand, but cannot be perceived by the user without explicit visual feedback (Ex: the confirmed state for the “Reservation”)

In our example, the “Reservation” object has two states along its life cycle. “being completed” and “confirmed”. The state diagram shows the circumstances that surround the a state. The “being completed” state occurs when the the “Reservation” is created, and is unchanged as long as the user keep adding information to the object. The user probably doesn’t acknowledge that the “Reservation is in a particular state. He or she implicitly recognize that the object is ready to accept input (Input fields) The “confirmed” state is of course very meaningful to the user, but is not implicitly perceived, and the design will have to address it.

By examining the state diagrams for a task, the designer sees which actions are causing state transitions and plan where in the sequence of views the visual feed back will have to be applied.


©IBM 2001 June 2001

Slide 18


Presentation View DesignUsing Input From States Diagrams

These sketches show the “Reservation” object in the two states that occur during the task of “making a reservation”.

On the left, (and in the back…) is the view of the “Reservation” object while in the state of “being completed”. The presentation view designer has not taken any special disposition to make the state of “being completed” more visually explicit that it is already. The visual feedback comes with the usage of standard input field that indicate that they are ready to receive information (well, flashing cursor). In this case, the designer can safely assume that the customer will not wonder whether the “Reservation” is in any particular state. The state of “being completed” is meaningful for the system, it is transparent to the user. The user sees a form to be completed.

The “confirmed” state is very meaningful to the customer. It is associated with the commitment that the customer makes to come and stay at the hotel. The presentation designer will provide a feedback mechanism that is appropriate for the situation at hand. There is many ways to provide feedback to an action such as confirming a choice, the simplest one being a dialog popping up with one line of text.

In our example, we found that the hotel might want to make a special impression on up-coming customers by using the feedback to demonstrate the care with which their information is handled . Instead of popping up a simple dialog, a full view is displayed of the hotel object displaying a message in the Queen’s English, thanking the customer and acknowledging the confirmation. Embedded in the “Hotel” view is a view of the “Reservation” and “Guest”. The information in these view is displayed without input fields, emphasizing that the data has reached the hotel.

The opportunity to make a new reservation and change the confirmed reservation is offered. Note that the “make a new reservation” action is placed on the “Hotel” object and the “change this reservation” action is placed on the “Reservation” object.

Such a design might require to add to the abstract design methods to enable the “Hotel” object to compose an English message using the name of the customer found in the “Guest”. The “make new reservation” method of the “Hotel” may exist already as well as the “change reservation” method of the “Reservation” object.


©IBM 2001 June 2001

Slide 19


Examining The Entire User Experience

Design decisions have been made at the level of individual object representations, and at the level of presentation views. Their effects must be evaluated at the level of the entire user experience.

The presentation views are arranged in the order they would appear to a hotel customer. The first one doesn’t belong to the “make a reservation” task, it is the “top” view of the “Hotel” which presents all the tasks supported by the “Hotel”. Then come the view of the “Hotel” for “making a reservation”, which provides access to the view of the the “Reservation” to “create a reservation” in which is embedded a view of the “Guest” for making a reservation. The view of the “Hotel” for “acknowledging a confirmation” comes last.

How is the visual identity holding up? Are the views of different objects sufficiently visually differentiated? Are the views of the same object visually similar even when seen on different context? This design, for the sake of driving the point home, uses color background to differentiate objects. This is a tad heavy handed. Also, it could be argued that the task is so simple that such strong visual identities for objects are superfluous. Indeed, the intensity of the visual identity of objects in a system depends on how complex the system is. If a system includes a lot of objects and support a large number of task, object visual identity becomes crucial and must be very explicit.

How is the fidelity of the presentation view with respect to the abstract view definition? The abstract design intention was to let the “Hotel” object support the task of “making a reservation”, using the “Reservation” and “Guest” object. The presentation views in this design do support the task in that spirit. In effect, each presentation view in the sequence is a view of the “Hotel”. The experience starts and finishes by a view where the “Hotel” object view is the most prominent element. The feedback view which could be seen as an addition, therefore as a breach of fidelity to the abstract design, is actually reinforcing its intention. (flexibility, discretion of the presentation view designers).

How seamless are the transitions between presentation views? At the exchange dates/availability the sudden appearance of the blue “Reservation” mini view help the customer noticing the event. When the customer navigates from the “Hotel” view to the “Reservation” view, the large visual event denotes a switch in the task from seeking availability to completing a reservation.


©IBM 2001 June 2001

Slide 20


Realization & Environmental Concerns

" Environmental concerns• Audience characteristics • Visual trends • Task domain • Brand

" How are the environmental concerns addressed in the model driven presentation view design

• Audience characteristics influence decisions about cognitive load and interaction mechanisms• All the environmental influences define the “palette” that will be used by the presentation designers

We have looked at how the abstract design provides input to the presentation view design. This input is the main driving force of the design. It provides the structure of the user experience. But we have ignored so far the influence of the environment and of the technology platform, partly because these notions are well understood by designers in the software domain. However, let’s quickly summarize how these issues are addressed in the context of this process.

Audience characteristic – Some information is available in the User Class Diagram and preliminary user studies from the Discovery Phase. Cultural background, age group, level of familiarity with technology.

Visual trends: Visual designers keep themselves aware of visual trends as part of the on-going activities of their professions. color schemes, typography usage, imagery.

Task domain: the Discovery phase activities should provide information. Presentation designers might have to complete the research. Typical language or images used in the domain

Brand: a comprehensive description of the brand system should be available to the presentation view designers. Typography scheme, color scheme, logotype, imagery style

The audience characteristics influence the design decisions that concern aspects such as the amount of cognitive load that the user can be expected to carry, the type of interaction mechanisms that will be used. Without changing the fundamental structure defined by the abstract design, it will have a great effect on the final presentation views.Note that the audience characteristics may have already come into play at the level of the abstract design.

Audience characteristics, visual trends, task domain and brand define the “Palette” the the presentation designers will use to make the user experience visible. Color, typography, graphics and imagery offer almost infinite possibilities. Without looking at the environment that surrounds the user experience, the presentation designers have an infinite palette at their disposal. The environment allows designers to select a small set of visual elements (color scheme, typography scheme…) that will be relevant to the audience, and give coherence to the entire user experience presentation.


©IBM 2001 June 2001

Slide 21


Realization & Technology Concerns

" Hardware concerns• Typical information capacity of the display device• Input devices• Processing speed

" Software concerns• Flexibility of the underlying operating software• Typical information capacity of client areas

" Influence of technology platform on presentation view design• Low information capacity may force extraneous navigation, a challenge to the user experience’s clarity• Input devices may dictate particular interaction mechanisms• The level of flexibility of the software platform defines how far visual design can go to boost the clarity of the user experience

Hardware concerns: display capabilities, input devices, processing speed

Software concerns: Flexibility of underlying operating environment (desktop, web browsers, java, flash), typical information capacity of client area.

The display capabilities of the hardware platform define an image pixel and color resolution, a maximum display size, and therefore a maximum quantity of information that can fit in one display. The image resolution will influence choices about the type of rendering that will be applied to the visual element selected on the “project’s palette”. The maximum quantity of information displayable at one time will influence decision about presentation view layout and partition. It may force into the presentation view design a navigation system that wasn’t defined in the abstract design phase, pausing a challenge to the clarity of the user experience.

Variations in input device and processing speed influence choices about interaction mechanisms and effects that may require extra processing.

The flexibility of the underlying platform has a major influence on the presentation view design. A product that would be living on the desktop, and be develop using the GUI toolkit and established UI convention could very will demonstrate good usability, but the presentation views designers would have less leeway to use visual design to boost the clarity of the experience and reduce the user’s cognitive load.

The typical information capacity of the client area, will also influence the presentation view layout and partition, and similarly to the display device capabilities may force navigation and view sequence that weren’t defined in the abstract views.


©IBM 2001 June 2001

Slide 22


Summary of Realization Phase

" Three categories of influence on the design that have to be addressed and orchestrated

• OVID’s Abstract Definition of the user experience: it drives the realization design activities• Environmental concerns: they help define the graphic palette that will be used and the tone of the final presentation• Technical concerns: they help define the graphic palette further, and may cause the partition of views that were defined as singleentities in the abstract view model

" Three important points• The object, abstract view, interaction, and state diagrams contain the information that drive layout and interaction design• The quality of objects visual identities design is key the clarity of the user experience• The user experience structure defined by the abstract design canalways be brought to the user intact

Slide 23


Recording the Decisions of the Realization Phase

The presentation view model concludes the user experience design activities before the development and deployment of the product


©IBM 2001 June 2001

Slide 24


Why a Presentation View Model

" Even a simple project generates a multitude of design specifications that need to be managed

• The presentation design specifications become integrated into the greater OVID model. Developers have access to all the designin a single location• The presentation view design specifications are organized around the structure of the design itself • The specifications can be organized for automated rendering• The Presentation View model facilitates the maintenance of the delivered product

" Several sets of presentations may have to be created• Market segmentation, (e.g. cultural differences, levels of familiarity with technology)• Multiple delivery platforms

At this point of the process, when a final design is reached after successive iterations of design, prototyping, and testing, it should be possible to pass along the torch to the developers. The design is done. However, in model driven design, models are used as tools to think with, as well as tools to record the design decisions and to communicate them to other team members. The abstract design is communicated to the designers of the realization phase through the diagrams of models. The same need for recording and communicating design specification exist between the realization phase and the development phase.


©IBM 2001 June 2001

Slide 25


Presentation View Model

Replace Replace

The presentation view model is a recent addition to our method. What is presented here doesn’t reflect the final modeling syntax. What is shown is how the presentation view model reflects the structure of the final design, and how each object view in the presentation carries its own specifications.

Notice how the presentation view model for the task of “making a reservation” differ from the corresponding abstract view model. The abstract view model is indicating only which object views are necessary to accomplish the task and how they are related. The presentation view model describes 3 consecutives composed view. The three composed views respect the view relationships defined at the abstract level.

Each object view in the presentation view model carries the justification for the particular presentation, here <<Web presentation>>, the name of the object, the task that the presentation is supporting, and the task supported by the object at this particular point. “Make a reservation -- Find vacancies”, specifications for the interaction mechanisms in the view, visual specifications and comments from the presentation view designers.

The embedding of object views is denoted by the UML aggregation relationship. The navigation is indicated by the dotted arrow, and qualified by a text label.


©IBM 2001 June 2001

Slide 26



The image on this slide shows the object views superimposed on their respective model elements

Slide 27



The presentation view model is also used to organized the implementation files. In the case of a web application, the html, the cascading style sheet and imagery files can be organized in the most appropriate way. The implementation platform also influence how the presentation view model is organized. For example, for a web application, style sheets


©IBM 2001 June 2001

would be developed that would affect the rendering of all views. The structure of the presentation view model would help the author of the style sheets to organize classes in a meaningful, convenient way. The visual specifications in the model would be written in term of style sheet classes.

Slide 28-31

See Exercise 5: Sketches on page 127.

Case Study Your Advisor 2 Didier Bardon and Carolyn Bjerke, Ease of Use, IBM, Austin

Slide 1

Slide omitted.

Slide 2


What is Your Advisor?

! Description: Your Advisor is a feature of ShopIBM which enables the target user group, “Wants Help”, to specify their needs in non-technical terms in order to receive a recommendation of what to buy! Your Advisor basically consists of:

! Answering questions to specify usage, budget and other needs! Receive recommendations of what to buy! Review other suggested items to buy

! Major goal we had: To demonstrate that modeling can be performed at an accelerated rate in order to more effectively reach or exceed user experience objectives! Case Study will:

! Show results! Review starting conditions and other salient project facts! Review process! Show some of the modeling diagrams! Discuss lessons learned


©IBM 2001 June 2001

Slide 3


Customer Satisfaction Rating Results (goal was 6 pt increase about current)

Your Advisor 1.0 Exists on web site today

Your Advisor 2.0 Not yet in development cycle

Slide 4


Facts

! Client: ShopIBM Worldwide Business Strategy Team! Multidisciplinary UCD Team:

! User Research Specialist, HCI Designer, Visual Designer (from EOU team)! Marketing specialist, Internationalization, Technology Specialist (from client team)

! Goal: Increase customer satisfaction by 6 pts above current (conservative goal because we didn’t know current sat when we wrote the contract)! Project Duration: 8 weeks! Starting State:

! Two team members supported/worked with colleagues from lead Research team on the original project which identified the need for an “assisted” shopping experience for “Wants Help” segment ! Your Advisor project inherited the user object model from original project and utilized accumulated knowledge of team members


©IBM 2001 June 2001

Slide 5


Facts

! UCD Process:! Week 1: User Study #1: Benchmark of Your Advisor 1.0! Week 2: Design using OVID to produce lo-fidelity prototype #1! Week 3: User Study #2: Walkthrough of prototype #1! Week 4: Revisions using OVID to produce hi-fidelity prototype #2! Week 5 - 6: User Study #3: Usability evaluation of prototype #2! Week 7: Design details and minor revisions to prototype #2! Week 8: User Study #4: Quick assessment of minor revisions

Slide 6


Where we started - Your Advisor 1.0

! Customer sat =70 was mainly due to:

! Single recommendation! Unclear user model -recommendation looked like it contained only one product and was expensive! Redundancy and ambiguity of questions! “Because” statements not helpful as written


©IBM 2001 June 2001

Slide 7


Where we are now - Your Advisor 2.0

! Customer sat =88 was mainly due to:

! Multiple recommendations! Clear user model for contents of recommendation! Clear questions! Ability to review exactly “why” recommendations made ! Can email/print/save recommendations

Slide 8


How’d we do it? - Some of the diagrams of interest1) YA2.0 User Class Diagram

! We hadn’t yet developed the more detailed approach to user attributes so for this project the user attributes came from the marketing segmentation study which included some behavioral as well as demographic information! Our project targeted the two types of “Wants Help”

We started with the target marketing segmentation studies which in this case the target market segments and the target users are the same because we were designing a web experience to enable the purchase of PCs.


©IBM 2001 June 2001

We found this diagram to be quite helpful in communicating with our client and our project team members because it clarified the relationships between various other audience groups. For instance, the experience was intended to be replicated to enable IBM Employees to use a version of the site to purchase products. So in effect the IBM Employees are acting as a "type of" consumer because they are buying products for themselves and their families (not their business).

Slide 9


How’d we do it? - Some of the diagrams of interest2) YA2.0 User Goal Diagram

! We also hadn’t utilized the UofM concept for goals yet so this goal diagram doesn’t show the success criteria for each goal! The basis of distinction in the sub-goals was whether or not technical learning occurred during the purchase process


©IBM 2001 June 2001

Slide 10


How’d we do it? - Some of the diagrams of interest3) YA2.0 User Task Diagram

! Task model using a different tactic to differentiate roles (takes performed by IBM are in green)! Need to qualify the different options that come out of a single decision point! Task model was created real-time while watching users use the current version - suggestions by users incorporated

Slide 11


How’d we do it? - Some of the diagrams of interest4) YA2.0 User Object Model

Notice the users object model doesn't contain an object called "Your Advisor". After working with users we felt that they understood there was a tool behind the recommender that IBM was providing and the persona represented through the image of the person wasn't a real person (they understood he was there for


©IBM 2001 June 2001

marketing reasons). Therefore we pushed the Your Advisor metaphor into the Presentation view since it is a culturally dependent thought anyway.

Slide 12


Lessons Learned

! Modeling was the reason for our success in such a short time (itenabled accelerated design):

! a) modeling by nature forced us to be precise in our thinking which resulted in design decisions that were easier to make ! b) enabled us to get to the details quicker even to the point of writing the user alerts that resulted from various conditional behaviors! c) enabled real-time capturing of our user learning as well as real-time capturing of design decisions

! Metaphors: Metaphors are culturally based and careful consideration should be given as to whether it appears in the object model, the abstract views or the presentation view! Setting clear goals: We were able to proceed smoothly because we knew from the beginning precisely what our success criteria was and we wrote it into our contract with our client

Slide 13

Slide omitted.

Conclusion Dick Berry, Ease of Use, IBM, Austin

Slide 1,2

Slides omitted.

Slide 3


Development

! Creating the experience from the models! Goal - Ensure fidelity of the implementation to the design! Method

• Inspection• Automatic code generation (CASE tools)

! Work product• Implementation Fidelity Report

! Model components flow into implementation• Views " implementation as panels, screens, pages, dialogs

• Objects " server/database design, business rules

• Tasks " navigation, Help, training

• Model differences " training and deployment plans

Development is creating the desired user experience from the model - so the goal is ensuring fidelity of the implementation to the intended design. There are at least two ways to accomplish this. While potentially tedious, a manual inspection of the resulting implementation is one possibility. To be most effective it should be as early as possible, allowing time for corrections.

A much better opportunity to take full advantage of CASE tools by using them for both User Experience design and implementation. In this case the components of the implementation reside in the same model as those of the UE design, which should make validation easier.

With either approach the flow from the UE designer’s model into implementation is fairly direct. Views are rendered as panels, screens, dialogs, and Web pages. Objects appear in database designs and their logic reflects business rules.

Tasks are manifest through navigation mechanisms and are a focus of user assistance.

To the degree that differences exist between the designer’s model and the implementation, additional training and/or deployment strategies may be required.


©IBM 2001 June 2001

Slide 4


Changes to the Designer’s Model

! Sometimes software design has implications for conceptual design

! Example:• Cannot lock data long term in database• Solution is to change to a transaction model where user is

aware of sending requests and getting a response

Sometimes software design necessitates iterating on the user experience conceptual design. For example, if implementation constraints prohibited long-term locking of data in a database, the user experience design might need to change from a session orientation to a transaction model.

Slide 5


Starting a Development Model

! Start a Package for the implementation model in“Logical View”• Probably owned by implementers

! Show implementation objects and relationships to user objects and views

! More detailed modelling of views may be worthwhile• State modelling is very useful when designing controls or

equivalent e.g., the states of push button


©IBM 2001 June 2001

Using a CASE tool such as Rational Rose it is possible to contain both the design and the implementation in the same model. In order to facilitate a proper separation between the user’s domain and the implementer’s domain, we recommend creating a Package for the implementation model in the Logical View section. This content of this package would be owned and updated by the implementers.

In addition to defining the implementation objects, this is an ideal place to show the relationships between user objects and views and their implementation counterparts. For instance, show which implementation objects are components of user objects.

Slide 6


Deployment

! Deployment has a user experience• How is it being rolled out, phased in, what disruptions,

workarounds, …! Assessing and responding to initial user acceptance

• Monitoring and feedback; quick response team! Effective incorporation of user feedback into on-going

design• Regular feedback of user issues and suggestions to

development decision makers

• Clear and easy to understand messages to developers! User feedback and suggestion mechanisms

• On-going user satisfaction assessment

Deployment activities create a user experience that is often overlooked or taken for granted during design and development. For example, in a corporate environment issues such initial rollout, how users are informed, how a new application is phased-in to replace a current solution, what disruptions it causes, and what workarounds are viable to minimize the disruptions – are all issues that should be thought about and addressed in advance. In other words, these user experiences should be designed.

Assessing user performance and satisfaction is a key activity when creating a user experience. As with the design itself, which should be subject to constant user assessment, the deployment phases should have built-in monitoring and feedback mechanisms to assess how well users are adjusting to a solution. You may need to plan actions such as having a quick response team on call.

Constant and on-going feedback about and from users is crucial. This information must be clearly communicated to developers in order to effect appropriate changes.

We advocate the provision of built-in or easily accessible feedback and suggestion mechanisms for on-going assessment of users’ acceptance.


©IBM 2001 June 2001

Slide 7


User Feedback and Suggestion Mechanisms

! At Delivery - Web ! Installation! Usage – Help and Provide Feedback! Situational – Errors! Periodic – first use, timed, new function use, …! Instrumentation

Utilize every opportunity to listen to users

We advocate providing mechanisms for gathering user feedback and allowing users to offer suggestions at every possible opportunity. For instance, aspects of delivery, especially when using the Web, are ideal opportunities to get user feedback.

During both installation and normal usage ample opportunities should be provided to allow users to express their satisfaction and offer ideas for improvement.

Specific situations, such as error messages, also provide opportunities.

Periodic opportunities also exist, such as upon first use, at time-based intervals during usage, and when upgrades or new functions are installed.

Ideally, instrumentation should be built into products so we can discover how they are actually being used, and correlate this data with user feedback. Instrumentation can be problematic for privacy and monitoring reasons, but through approaches involving consent or trial periods, much valuable data might be obtained.


©IBM 2001 June 2001

Slide 8-9

Original slides replaced by the image shown on the two slides.

Here is an example of a user feedback and suggestion system that I ran across on the Web. It’s from weather.com. It’s a page that allows users to provide feedback about specific pages on the weather.com site, and allows them to make suggestions.

This page is available from every page of the site, and it includes the URL of the page on which feedback is being provided.

I found this form to be very quick and easy to use. It is unobtrusive and allows you to say as much or as little as you would like.


©IBM 2001 June 2001

Slide 10


Measures of User Satisfaction

! CUPRIMDSO! Capability! Usability! Performance! Reliability! Installability! Maintainability! Documentation! Supportability! Overall

! Exemplary approach - IBM internal UCD site - Web survey tools

User satisfaction might be measured in a variety of ways. In IBM we have standardized a measure we call CUPRIMDSO, which is an acronym for the measures of capability, usability, performance, reliability, installability, maintainability, documentation, supportability, and an overall satisfaction rating.

These measures are typically assessed through a user satisfaction questionnaire using a five-point scale. The resulting data is reported as satisfaction indices ranging from zero to one-hundred. These values are compiled for our own products and for competitive products. Goals are established both for direct score and for position with respect to best-of-competition.

Within IBM we are placing great emphasis on the collection of user satisfaction data, and we are providing a significant amount of tooling to help all product areas collect this data both during product development and after deployment.


©IBM 2001 June 2001

Slide 11


Web-Based Surveys

For example, our internal UCD Web site offers several tools for conducting Web-based user satisfaction surveys - with a predefined survey for measuring CUPRIMDSO, and a tool for creating other types of surveys as well.


©IBM 2001 June 2001

Slide 12


SatSurvey Example

Here is a sample of the SatSurvey – which is a CUPRIMDSO survey instrument.

Slide 13


CASE tools and alternatives

! Rationale Rose http://www.rational .com

• Full-featured suite of products• Various licensing methods • Code generation• Implementation ready

! Visio http://www.visio.com

• General purpose diagramming• Four editions ranging in price• Professional & Enterprise• UML diagram type/modeling

! Together/J http://www.togethersoft.com

• Model, build, deploy! Constantine & Lockwood, Ltd.

http://www.foruse.com

• PowerPoint palette

You have seen that we use Rational Rose. Rose is a full-featured CASE tool and is a member of a full-featured suite of products from Rational. While Rose can be somewhat expenseive, a couple of thousand $


©IBM 2001 June 2001

per seat, various licensing arrangements are available to help alleviate the cost. Rational offers a node-locked option in which the product is licensed to a specific computer. Also available is a floating license that is administered from a license server. You can buy a few licenses and share them among many users – up to the number of licenses purchased running concurrently. The other big advantages that Rose offers are code generation for Java and C++, and it’s designed to handle implementations – so the implementation model can exist in the same Rose files as the user experience designer’s model.

Several alternatives to Rose also exist, at varying price points, with varying levels of function. Visio is a general purpose diagramming application sold in four editions. When I last used Visio about a year ago, the Professional edition supported UML diagrams, but not full modeling - with attributes, operations, relationships, etc. The Enterprise edition did support full UML models.

TogetherJ is one of a set of tools from TogetherSoft, which advertises a complete model, build, and deploy capability. I have no personal experience with these tools.

Apparently on the no-to-low cost side, Constantine and Lockwood offer a PowerPoint-based approach using a PowerPoint drawing palette. I also have no experience using this approach, but it is downloadable from their Web site.

Slide 14


References and Resources

I’ve included a few references to help get you started – or delve deeper – beginning with a new publication by Vanessa Donnelly – titled “Designing Easy to use Web sites”, and of course I have to reference our original book on OVID.


©IBM 2001 June 2001

Slide 15


www.uidesign.net

Dave RobertsInterview

UI Design fromUML Models

www.uidesign.net

There is also a Web site devoted to UI design that commands a fairly broad following of folks involved in the use of UML to model user interfaces.

Here is the homepage – you might just note the recent interview with Dave Roberts, and the special section on UML models.


©IBM 2001 June 2001

Slide 16


www.uidesign.net/2000/conference/TUPISreport.html

Towards a UML Profile for Interaction Systems

There is even a conference titled “Towards a UML Profile for Interaction Systems”.

Papers from the 2000 TUPIS conference are available on the uidesign.net Web site.

Slide 17


References and Resources from Rational

To round things out – here are some references from the Rational Web site – www.rational.com


©IBM 2001 June 2001

Slide 18


Future Directions

! Modelling of:• Relevant business goals• Deployment issues

! Generation of prototype views directly from the model! Automatic code generation through tool extensions

UML AUIML Render

Web

PDA

Phone

Recall that Carolyn mentioned 1) modeling business goals, resources, processes (most of which are captured in e.g., Word docs today – we would capture the aspects relevant to design, 2) modeling the market segments into addition user segments to help understand any differences, and 3) model relationships between user segments and correlations to user experiences attributes.

One of the most exciting potentials is for more automatic generation of prototype views directly from the model, as demonstrated by Dave Roberts.

Even more exciting is the potential for extensions to UML and tools such as Rose to specifically accommodate User Experience design activities and provide self-checking like it does for software engineering, along with automatic code generation. For example, Rose might provide stereotypes for Views, and relationships for showing the connections between view data and objects.


©IBM 2001 June 2001

Slide 19


End-to-End Approach

User-Goal Analysis

Scenarios & Stories

User Objects

User Tasks

Abstract Views



DeploymentFeedback


What you’ve heard about today is how to apply the concepts of architecture and modeling, through the use of software engineering approaches and tools, to address the full gamut of issues involved in creating a Total User Experience – from Discovery of users needs through High-Level and Low-Level Design, ensuring fidelity during Development, and Deployment with a full assessment of how well the design meets users’ needs.

Slide 20


The End

User Experience Engineering focuses on product creation – from concept

through deployment – it’s not just about “design” anymore.

http://www.ibm.com/easyStay up to date – visit us at:

Tutorial Exercises

Audiences Audience members are considered to be only those who directly interact with the system being designed (independent of which views, e.g., Web, phone, …). For example, the travel agent in the Business Traveler story is considered to be a mechanism as much so as a voice-reco system would be. We presume the travel agent utilizes a third-party system, such as Sabre, to interface to the hotel’s database, not the hotel’s Guest Services System (GSS) that we’re designing.

Vacationer • May be more flexible with schedule and facilities. • May tend to be more congenial. • May be less familiar with the venue and therefore need more assistance/service.

Business Traveler

Attributes (that could have an impact on the design and resulting user satisfaction): • Required to use a corporate approved travel agent, airlines, hotels, and car rental

agencies. • May travel frequently, leads to familiarity … • Familiarity: with venues, situations, … • Frequently relies on delegation and therefore is subject to situations caused by others. • Likely Amenities such as frequent flyer, … • Expects more personal treatment from frequently used suppliers … • Number in party is typically the same (one). • Frequently repeats the same itineraries and follows patterns, leading to an expert level

and high expectations. • Impacts of glitches can be significant. • Seeks efficiency, reliability, and consistency. From the hotelier’s viewpoint, distinctions amongst audience members are served primarily by distinctions in the following:

• Rate • Corporate rate • Senior rate • Promotional rate • Group rates for tours, etc. • Seasonal, length of stay, and weekend stay

• Kinds of service • Hotel club levels (special rooms/floors, free breakfast, newspaper, …) • VIP (honeymoon suite, presidential suite, penthouse occupants, …) • Gym/Spa • Concierge

Which audience attributes would hotel marketing use as the basis for an audience segmentation? They would likely use spending rates and the types of services that would be purchased as the basis. They would likely try to capture and create repeat customers.


©IBM 2001 June 2001

The audience attributes that would cause hotel personnel to segment the audience would involve: VIP status, how demanding, special needs,

The audience segmentation that is relevant to the design is the one that is manifested to the users of the system, or that can have an impact on uses of the system. In the hotel case the marketing segmentation may impact the reservations task but is likely less relevant in check-in and check-out tasks, with the possibility for customer survey information to be used as feedback to the marketing process.

Stories Making a Hotel Reservation - Vacationer

Jackie has decided to take an out of town vacation to see the countryside and she needs a place to stay. She doesn’t know the area she intends to visit at all. She will need a place to stay for two nights. Not having had a decent vacation in years she wants to be pampered.

She prefers a hotel – one with a nice view, a hot tub, and great service. She will be by herself but still prefers a king-size bed. Since she hasn’t been to this part of the country before she is concerned about access from the airport, proximity to churches, scenic and historic attractions, as well as the neighborhood, crime, and security. She traditionally stays at big hotel chains, such as Hilton and Marriott, because she has found them to be consistently reliable, but she would consider an independent hotel with adequate references. She has already found the names of a few hotels to consider and will be checking out the Web site for each.

Note: We presume that the ‘identifying a hotel task’ has previously been done. It is likely a responsibility of a hotel’s’ marketing department which may or may not rely on the Web site to make the hotel known to potential customers. We therefore start modeling this task at the point Jackie has decided to make a reservation – skipping the hotel decision tasks. Also, a story will inherently contain artifacts of existing mechanisms, such as the telephone, that will have to be factored out during subsequent analysis. Jackie always makes reservations by phoning a hotel’s 800 reservations number. She recently heard about a particularly good independent hotel in this area and decides to give them a call. The reservation clerk greets her, introduces himself as David, and asks how he may be of assistance. The friendly greeting gives Jackie an initial positive feeling.

Jackie indicates that she needs a room for two nights and specifies the dates. David then verifies the arrival and departure dates, asks how many in the party, and asks what kind of accommodations she would like. Jackie knows it’s a beachfront hotel so she requests an ocean-view, king-size bed, non-smoking room, near the pool. David checks availability and indicates three different levels of accommodation telling Jackie the price for each.

David has been given incentives for selling higher priced rooms so he extols the virtues of the best room, which include a mini-bar and a monogrammed bathrobe. Jackie relishes the opportunity to be bathed in luxury and accepts David’s recommendation. He then asks Jackie for her address and phone number, and requests that she guarantee the reservation using a credit card. Jackie agrees and provides her American Express card number.

Because of the large expense involved, hotel procedures require that David verify the credit card information. He does so very quickly while continuing to chat with Jackie so that she doesn’t even realize he has verified her account. He then gives her a confirmation number, indicates that he is looking forward to meeting her, and offers to be of any further assistance. Jackie thanks him, says goodbye, and they both hang-up.

Making a Hotel Reservation – Business Traveler

(we added this audience segment to show differences on the Audience-Goal Diagram)


©IBM 2001 June 2001

Robert needs to be in Boston on Tuesday for a 2-day business meeting. As a Regional Manager for a restaurant supply company his job requires that he travel frequently, typically several times a month. He has been traveling to the same seven cities for the past four years and has developed a routine. He has a favorite airline, three favorite hotel chains and a preferred hotel location in each city, and he usually rents a car, although he will sometimes take a taxi or book a limo if the weather is going to be bad. He also utilizes a travel agent to make all the arrangements. He prefers to talk with the travel agent directly instead of having his secretary make the arrangements in order to minimize the potential for mistakes. Robert is a stickler for having everything go exactly as planned.

Robert phones his travel agent and Pam answers. He requests the 3:15 pm American Airlines flight to Boston on Monday, returning on the 5:30pm flight Wednesday. He specifies the Hilton hotel on 7th Street South as his first preference and the Marriott hotel on St. Albans Blvd as his second preference. He foregoes the normal rental car because the weather forecast indicated a possibility of snow.

Pam will use Robert’s profile to book a non-smoking room with a King size bed and business desk. His profile also specifies aisle seating on the flights, meal preferences, and includes frequent flyer and hotel traveler’s club membership numbers. This travel agency always guarantees reservations for arrival after 6:00pm for their business travelers. Pam will use Robert’s American Express credit card number from his profile.

After a brief pause she reads Robert his flight itinerary, tells him she got the Hilton hotel and reads him the confirmation number, which he notes in his Palm Pilot. She will also fax him a complete itinerary after they hang up.

Being pleased that all the arrangements went smoothly, says Thanks and Goodbye, then begins to prepare his notes for trip.

Checking In – Vacationer

When Jackie arrives at the hotel a Bellman named Ken greets her as she exits the taxi. He takes her bags, gives her a claim check, and assures her the bags will be delivered to her room within ten minutes after she checks in. There is no line at Reception and two clerks are chatting behind the desk. As she approaches one of the clerks named Julian steps forward and greets her. Julian has been a Front Desk Clerk for about nine months and knows his job pretty well.

Jackie presents her American Express card and mentions her reservation. Using her last name from the card, Julian brings up her reservation on his computer. He verifies that she plans to stay two nights and begins creating a folio for her stay. Upon finding an available room in the hotel inventory he affirms that she will have an ocean-view and king size bed. He also affirms that her room has a mini-bar and bathrobe. David had placed a note in Jackie’s reservation when she asked about these amenities and Julian knows it’s good practice to give each guest a personalized experience. Jackie is impressed that the hotel staff noted this bit of pampering she intended to give herself. She is already thinking how enjoyable her stay here is going to be.

While Julian is waiting for the standard authorization process on Jackie’s credit card he creates her key card and places it, along with the key to the mini-bar, in a Welcome jacket. In the meantime the authorization completes. Julian writes the room number on the brochure and directs Jackie to the elevators. He tells her that breakfast is served from 6:00am until 10:00am in the Sonnets Restaurant and bids her have a very enjoyable stay. He also volunteers that if she has any questions or needs anything to please phone *55, which is the front desk.

Jackie thanks Julian and heads for the elevator.

Checking In – Business Traveler

Robert gets out of the taxi in a foul mood. The weather report was correct, it’s snowing, his flight was delayed by two hours, the taxi driver drove like a maniac all the way from the airport to the hotel, and now he doesn’t even want to get out to open the trunk for Robert’s roll-aboard travel case. He pops the trunk and waits for Robert to get the case himself. Robert pays the meter - no tip for this guy – grabs his case from the trunk and heads for the revolving doors of the hotel. He doesn’t even close the trunk, but that


©IBM 2001 June 2001

doesn’t bother the taxi driver who skillfully closes it himself by speeding away so fast the trunk has no choice but to slam shut on its own.

Robert brushes by Michael, the bellman on duty, whom having detected his mood doesn’t offer to assist with the bags but simply steps aside. Robert hustles up to the front desk anxious only to get into his room and have a warm cup of hot chocolate, which he always carries this time of year. He calls out “reservation for Robert Townsend” loudly as he approaches the front desk. The gruff look on Robert’s face and the tone of his voice tell Rajiv, the clerk on duty, to be very professional – and quick – he is already searching for Robert’s reservation. Unfortunately he can’t find it.

Anticipating some difficulty, Rajiv attempts to diffuse the situation with a gracious but business-like greeting. He knows that Robert frequently stays in this hotel, and he knows that Robert is normally very congenial. But having no reservation is not what Robert is going to want to hear tonight.

Rajiv is already searching the room inventory when Robert reaches the desk and flips his credit card onto to polished surface. He has also opened Robert’s hotel profile, a record this hotel keeps on each guest. It’s in a separate set of records that the hotel keeps locally and uses for specific personal guest preferences. The staff uses these records to provide each guest a more personal experience than could be afforded using only the hotel chain’s centralized guest profiles. Rajiv notes that Robert prefers a room facing the atrium, and that he is participating in the trial of the new wireless high-speed data connection that the hotel is test marketing. Using this information along with the hotel chain’s profile, Rajiv takes a gamble and finds a room that fits Robert’s normal requests, including the business desk. At the same time, using a second check-in computer, Rajiv completes the normal check-in tasks of creating a folio and validating Robert’s credit card.

Somewhat apprehensively and hoping that Robert had not made any out of the ordinary requests this trip, he goes over the room rate, location, and room number as he hands Robert the key and says “I know you’ve had a very trying time today Mr. Townsend. Please don’t worry about a thing. We’ll take good care of you here and I’m sure things will go much better tomorrow. Goodnight now”. Robert reflects momentarily on this small gesture and senses the effort Rajiv is making so that he will feel less stressful. With a very small and somewhat forced smile as he turns and heads for the elevators, Robert says “Thank you Rajiv. I’m looking forward to a warm room and a soft bed. Good night.”

As Robert walks away Rajiv calls after him “Enjoy your hot chocolate Mr. Townsend”. “Hmm”, thought Robert, “how did he remember I liked hot chocolate”? Robert never knew he had no reservation – somewhere between Pam’s computer, the Sabre system, and the hotel chain’s system, the reservation was lost.

Quick thinking on Rajiv’s part and having all the information he needed about Robert’s normal preferences allowed him to create a perception of normalcy. Despite everything else going wrong this night, something had gone right – the hotel was perfectly reliable – just like always. Or so Robert thought.

Hotel Tasks by Job (Assumed based on Job Descriptions)

Based on Internet research on Job Descriptions from various hotel’s job listings

General Manager (combined with Hotel Director)

Recruit, evaluate, train, and supervise staff (some assumed)

Ensure resolution of guests’ problems

Develop, approve, implement and manage to the hotel’s budget.

Front Office Manager

Participate in selecting front office staff.

Train, schedule, supervise, and evaluate front office staff.

Communicate with other departments.


©IBM 2001 June 2001

Controls the master key.

Ensures proper room status.

Ensure resolution of guests’ problems.

Complete credit limit report. (?)

Manages front office budget.

Check cashiers in and out and verify their banks.

Enforces front office polices (cash handling, credit, check cashing, …)

Enforces proper uniforms.

Desk Clerks

Registers guests and assigns rooms - accommodates special requests whenever possible.

Assists in pre-registration and blocking of rooms for reservations.

Coordinates room status updates with the housekeeping department by notifying housekeeping of all check-outs, late check-outs, early check-ins, special requests, and part-day rooms.

Takes, files and cancels reservations.

Files room keys.

Processes guest check-outs.

Reports any needed repairs to maintenance.

Head Housekeeper

Participate in selecting housekeeping staff

Train, schedule, supervise, and evaluate housekeeping staff

Ensure accurate room status is communicated

Supervise inventory control

Enforce proper uniforms

Reports needed repairs to maintenance

Housekeepers

Ensure rooms are cleaned

Deliver stock and items to rooms

Maintenance Technician

Perform maintenance and repairs

Guest Services (Concierge?)

Assist guests with questions.

Arrange transportation?

Bell Staff

Assist guests with luggage

Valet park cars

Drive airport shuttle bus

Assist guests with questions


©IBM 2001 June 2001

Night Auditor

Post billings to each department

Run reports

Check-in late arrivals

Check-out early departures

Object Analysis Hotel, independent, beachfront

Bed, king size

Chain, hotel

Reservation, (guaranteed)

Phone number, reservation, (guest’s)

Clerk, reservation, front desk

Room, non-smoking, availability, higher priced, virtues of

Date, arrival, departure

Party, number in

Accommodations, levels of

View, ocean

Price, (room), aka room rate

Address, (guest’s)

Confirmation number

Location, hotel

Travel agent

Preference, first, second, …

Profile, (traveler’s), hotel’s (on guest), chain’s (on guest)

Desk, business

Membership number, hotel club

Credit card (traveler’s)

Itinerary

Confirmation number

Bellman

Bags

Claim check

Reception desk

Last name

Folio

Hotel inventory (of rooms)


©IBM 2001 June 2001

Mini-bar

Bathrobe

Note

Amenities

Key card

Room number

Greeting

Guest preferences

Exercise 1: Overview 1.The concept of a “reservation” in a hotel Guest Services Application is an aspect of:

a.The look and feel

b.The user’s model

2.The user’s model is conveyed to users:

a.Through views

b.Using UML diagrams in Help text

3.Computer-aided software engineering approaches are only useful in the Design Phase. (True/False)

4.List three benefits users might derive from an astute understanding of the user’s model.

5.Draw a naïve user’s model of the automobile including the key user controls.

Exercise 2: Tasks Models Based on the source information (Checking In – Vacationer on page 121) create an Activity Diagram which captures the check-in process for the vacationer.


©IBM 2001 June 2001

Exercise 3: Views Using the model you have designed in Exercise 2, create the views that would be needed to check-in a guest who has a reservation. The views can be attached to the following class diagram:

Reservation

Folio

Room

Guest History

0..n

0..n

0..n

0..n

Stay

Hotel

1

n

1

n

0..n

0..n

0..n

0..n

Plan to Stay

Exercise 4: State Models Assuming that the following state chart is a correct model for the states of a room, complete the state table for a room and make the design decisions for all the state/transition pairs.

OccupiedFreeCheck In

Needs cleaning for next guest

Check OutCleaned


©IBM 2001 June 2001

Fill in your answer here.

Free Occupied Needs Cleaning

Check In

Check Out

Cleaned

Exercise 5: Sketches Draw a sketch of the views for check in based on this class diagram, …


©IBM 2001 June 2001

Sample Answers Exercise 1

1.The concept of a “reservation” in a hotel Guest Services Application is an aspect of:

b.The user’s model

2.The user’s model is conveyed to users:

a.Through views

3.Computer-aided software engineering approaches are only useful in the Design Phase. (False)

4.List three benefits users might derive from an astute understanding of the user’s model.

More efficient use, aids problem determination, facilitates communication with others

5.Draw a naïve user’s model of the automobile including the key user controls.

A User’s Model of the Automobile

User Control Elements

Controlled Elements

Automobile - Essential Elements of Use - naiveAutomobile - Essential Elements of Use - naive

Wheels(moves car)

Engine(generates speed)

Transmission(transforms speed

and direction)

Controls Speed of

Transfers speed to Transfers speed toControls Speed of

(slows)

Controls Directionleft/right

AcceleratorPedal

BrakePedal

SteeringWheel

This is just one potential model of the automobile. It captures the three essential controls. Other controls such as gearshift or parking brake could be added.


©IBM 2001 June 2001

Exercise 2

Arriv ed at desk


agrees detail

reads name f rom card

inputs name f rom card to system

conf irms details

creates guest f olio

selects room

describes room


creates key

hand key to guest

searches f or reserv ation

Showing reserv ation


Showing room detail

Check in complete

Lef t desk

: Existing Syst emJulian : Front Desk ClerkJackie : VacationerArriv ed at

desk


agrees detail

reads name f rom card

inputs name f rom card to system

conf irms details

creates guest f olio

selects room

describes room


creates key

hand key to guest

searches f or reserv ation

Showing reserv ation


Showing room detail

Check in complete

Lef t desk

: Existing Syst emJulian : Front Desk ClerkJackie : Vacationer

This diagram is a transcription of the scenario into an activity diagram. Note how states (the squarer boxes) are used from time to time to provide descriptions of where we have got to.

The horizontal bars show where the task divides into parallel activities.


©IBM 2001 June 2001

Exercise 3

Registration

(from Logical View)

Reservation(from Logical View)

Reservation for Check In

<<View>>Guest for Check In

<<View>>

Guest History(from Logical View)

Hotel(from Logical View)

0..n0..n 0..n0..n Plan to Stay


1

n

1

n

0..n

0..n

0..n

0..n Stay

Room for Check Insmokingview of seabed_type

<<View>>

<<view>>

Check In<<View>>

<<view>>

Folio(from Logical View)

creates

Registration

(from Logical View)

Reservation(from Logical View)

Reservation for Check In

<<View>>Guest for Check In

<<View>>

Guest History(from Logical View)

Hotel(from Logical View)

0..n0..n 0..n0..n Plan to Stay


1

n

1

n

0..n

0..n

0..n

0..n Stay

Room for Check Insmokingview of seabed_type

<<View>>

<<view>>

Check In<<View>>

<<view>>

Folio(from Logical View)

creates

For more details on how these views might be used see the explanation for exercise 5.


©IBM 2001 June 2001

Exercise 4

Free Free OccupiedOccupiedNeeds Cleaning Needs Cleaning for New Guestfor New GuestNeeds Cleaning Needs Cleaning for New Guestfor New Guest

check incheck in Start stay record, change to occupied.

Start stay record, change to occupied.

Not allowed.

check outcheck out Can't happen, there's no guest.

Can't happen, there's no guest.

Complete stay record. Change to Needs Cleaning for New Guest.

Complete stay record. Change to Needs Cleaning for New Guest.



cleanedcleaned Should not happen.Should not happen.

To occupied Change to free.

The empty cell at the top right (check in for a room that needs cleaning) provides an interesting discussion point. This situation could be where a guest wants a particular room (Honeymoon Suite) but that room is not ready yet. Do you check them in as normal and send them to a dirty room? Do you have a special procedure to take the bags and deliver them when the room is clean? Whichever decision you take you will probably have to define some new tasks to cater for the situation.

Exercise 5

The clerk enters the guest’s name or reservation confirmation number in the “Reservation Finder”. It is of course more efficient than asking the clerk to locate the guest’s reservation in a list of reservations mini-views.


©IBM 2001 June 2001

The system returns a familiar view of the guest’s reservation. As before, a view of the guest record object is embedded in the reservation view. In this situation we can safely assume that the clerk will find it efficient to deal with one customer at a time, so a fully detailed view of the reservation/guest record object is called for. Note that in this design, the system returns also a selection of available rooms to choose from. The system knew some of the attributes of the room requested by the guest fro the reservation object.

The clerk at this point can enter the information still missing in the guest record. If the guest refuse the rooms returned by the system, the clerk can perform another search using the “Room Finder”, setting the room attributes (the icons with radio buttons) in the proper way.

On the right hand side column, a list of room mini-views is displayed. Each view shows the value of the 4 room attributes (single/double bed, smoking/non-smoking, handicap accessible/non-accessible, sunset view or not). On the left is an action button used to select and assign a room to the current guest. On the right is a view access button that is used to open a detailed view of the room (see next slide)

When a room as been assigned to the guest, and all the information obtained from the guest, the clerk clicks on the “Complete reservation” action button, which stores the information in the guest record, marks the room as occupied by the duration. A dialog box is displayed to inform the guest that the reservation is completed.

Note: The domain specific action button (Find, complete….) have a visual treatment that is different from the view access button (Details…). This is done to differentiate these two very different classes of action. With a domain specific action, the system perform a specific task that may change the state of objects. The view access button merely opens a new view and never change the state of object.

Here the clerk has clicked on the “Details” view access button. A detailed view of the corresponding view object is displayed. The clerk finds more information about the room to communicate to the customer.

crafting the compelling user experience using a methodical ... › ska › hci06 › literature ›...

Documents