Crafting the Compelling User Experience Using a methodical ... › ska › hci06 › literature ›...
Transcript of Crafting the Compelling User Experience Using a methodical ... › ska › hci06 › literature ›...
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 1 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
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 2 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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 3 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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 4 June 2001
Slide 5
June 2001 5IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 5 June 2001
Slide 6
June 2001 6IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 6 June 2001
Slide 7
June 2001 7IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 7 June 2001
Slide 8
June 2001 8IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 8 June 2001
Slide 9
June 2001 9IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 9 June 2001
Slide 10
June 2001 10IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 10 June 2001
Slide 11
June 2001 11IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 11 June 2001
Slide 12
June 2001 12IBM Ease of Use Group Slide number
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!
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 12 June 2001
Slide 13
June 2001 13IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 13 June 2001
Slide 14
June 2001 14IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 14 June 2001
Slide 15
June 2001 15IBM Ease of Use Group Slide number
Three Key Interface Models
Users’Models
•Beliefs•Goals•Emotions•Superstitions
Hotel Room
Guest
Designer's Model
•Things•Appearances•Interactions
Needed for users’ tasks
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 15 June 2001
Slide 16
June 2001 16IBM Ease of Use Group Slide number
Three Key Interface Models
Hotel Room
Guest
Designer's Model
•Things•Appearances•Interactions
Needed for users’ tasks
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 16 June 2001
Slide 17
June 2001 17IBM Ease of Use Group Slide number
Three Key Interface Models
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 17 June 2001
Slide 18, 19
June 2001 18IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 18 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
June 2001 20IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 19 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
June 2001 22IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 20 June 2001
Slide 23
June 2001 23IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 21 June 2001
Slide 24
June 2001 24IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 22 June 2001
Slide 25, 26, 27
June 2001 25IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 23 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
June 2001 28IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 24 June 2001
Users, objects, and views can be expanded to show their properties and actions (using UML attributes and operations).
Slide 29
June 2001 29IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 25 June 2001
Slide 30
June 2001 30IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 26 June 2001
Slide 31
June 2001 31IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 27 June 2001
Slide 32
June 2001 32IBM Ease of Use Group Slide number
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
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 29 June 2001
Slide 3
June 10, 2001 3IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 30 June 2001
Slide 4
June 10, 2001 4IBM Ease of Use Group Slide number
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
June 10, 2001 5IBM Ease of Use Group Slide number
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
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 31 June 2001
Slide 6
June 10, 2001 6IBM Ease of Use Group Slide number
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
June 10, 2001 7IBM Ease of Use Group Slide number
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 =
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 32 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
June 10, 2001 8IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 33 June 2001
Slide 9
June 10, 2001 9IBM Ease of Use Group Slide number
How do I create a User Class Diagram?
" 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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 34 June 2001
Slide 10
June 10, 2001 10IBM Ease of Use Group Slide number
How do I create a User Class Diagram?
" 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
June 10, 2001 11IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 35 June 2001
Slide 12
June 10, 2001 12IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 36 June 2001
Slide 13
June 10, 2001 13IBM Ease of Use Group Slide number
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
June 10, 2001 14IBM Ease of Use Group Slide number
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
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 37 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
June 10, 2001 15IBM Ease of Use Group Slide number
How do I create a Users’ Goal diagram?
" 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
June 10, 2001 16IBM Ease of Use Group Slide number
How do I create a Users’ Goal diagram?
" 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
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 38 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
June 10, 2001 17IBM Ease of Use Group Slide number
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)
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 39 June 2001
Slide 18
June 10, 2001 18IBM Ease of Use Group Slide number
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
June 10, 2001 19IBM Ease of Use Group Slide number
How do I create a Users’ Current Task Models?
" 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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 40 June 2001
Slide 20
June 10, 2001 20IBM Ease of Use Group Slide number
How do I create a Users’ Current Task Models?
" 7: Add decision points for appropriate roles and indicate activities that result from each possible decision output
Slide 21
June 10, 2001 21IBM Ease of Use Group Slide number
How do I create a Users’ Current Task Models?
" 8: Add ending states when a task comes to a termination point
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 41 June 2001
Slide 22
June 10, 2001 22IBM Ease of Use Group Slide number
How do I create a Users’ Current Task Models?
" For your reference - the rest of the task model
Slide 23
June 10, 2001 23IBM Ease of Use Group Slide number
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
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 42 June 2001
Slide 24
June 10, 2001 24IBM Ease of Use Group Slide number
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
June 10, 2001 25IBM Ease of Use Group Slide number
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
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 43 June 2001
Slide 26
June 10, 2001 26IBM Ease of Use Group Slide number
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
June 10, 2001 27IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 44 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
June 2001 2IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 46 June 2001
Slide 3
June 2001 3IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 47 June 2001
Slide 4
June 2001 4IBM Ease of Use Group Slide number
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
Check-In No ReservationBusiness Traveller
Vacationer Front Desk Clerk
Night Auditor
business traveller check in
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
June 2001 5IBM Ease of Use Group Slide number
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
Check-In No ReservationBusiness Traveller
Vacationer Front Desk Clerk
Night Auditor
business traveller check in
vacationer check in
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 48 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
June 2001 6IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 49 June 2001
Slide 8
June 2001 8IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 50 June 2001
Slide 9
June 2001 9IBM Ease of Use Group Slide number
The Abstract Design Process
Task Synthesis
Design Outline Tasks
Design Abstract Views
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 51 June 2001
Slide 11
June 2001 11IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 52 June 2001
Slide 12
June 2001 12IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 53 June 2001
Slide 13
June 2001 13IBM Ease of Use Group Slide number
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
June 2001 14IBM Ease of Use Group Slide number
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
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 54 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
June 2001 15IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 55 June 2001
Slide 16
June 2001 16IBM Ease of Use Group Slide number
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
June 2001 17IBM Ease of Use Group Slide number
Class Diagram Notation
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
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 56 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
June 2001 18IBM Ease of Use Group Slide number
Class Diagram Notation
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 57 June 2001
Slide 19
June 2001 19IBM Ease of Use Group Slide number
Class Diagram Notation
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
June 2001 20IBM Ease of Use Group Slide number
Class Diagram Notation
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 58 June 2001
Slide 21
June 2001 21IBM Ease of Use Group Slide number
Room
Smoking : boolean = False
check in()check out()
(from Logical View)
Class Diagram Notation
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 59 June 2001
Slide 22
June 2001 22IBM Ease of Use Group Slide number
Room
Smoking : boolean = False
check in()check out()
(from Logical View)
Class Diagram Notation
Aggregation
Room
check in()check out()
(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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 60 June 2001
Slide 23
June 2001 23IBM Ease of Use Group Slide number
Room
Smoking : boolean = False
check in()check out()
(from Logical View)
Class Diagram Notation
! 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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 61 June 2001
Slide 24
June 2001 24IBM Ease of Use Group Slide number
Class Diagram Notation
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
June 2001 25IBM Ease of Use Group Slide number
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
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 62 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
June 2001 27IBM Ease of Use Group Slide number
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
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 63 June 2001
Slide 29
June 2001 29IBM Ease of Use Group Slide number
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…
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 64 June 2001
Slide 30
June 2001 30IBM Ease of Use Group Slide number
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
(from Use Case View)
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 65 June 2001
Slide 31
June 2001 31IBM Ease of Use Group Slide number
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
Guest for Reservation'detai ls'
<<View>>
Reservation Clerk
(from Use Case View)
<<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
June 2001 32IBM Ease of Use Group Slide number
Navigation or Embedding?
Navigate
Embed
Make A Reservat ionproposed dates
U:Propose Dates()U:Accept()
<<View>>
Create a Reservation<<View>>
Guest for Reservation'details'
<<View>>
Create a Reservat ion<<View>>Make A Res ervation
proposed dates
U:Propose Dates()U:Accept()
<<View>>
Guest for Reservation'detai ls'
<<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
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 66 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
June 2001 33IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 67 June 2001
Slide 34
June 2001 34IBM Ease of Use Group Slide number
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
June 2001 35IBM Ease of Use Group Slide number
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
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 68 June 2001
Slide 36
See Exercise 3: Views on page 126.
Slide 37
Slide omitted.
Slide 38
June 2001 38IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 69 June 2001
Slide 39
June 2001 39IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 70 June 2001
Slide 41
June 2001 41IBM Ease of Use Group Slide number
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’.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 71 June 2001
Slide 42
June 2001 42IBM Ease of Use Group Slide number
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’.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 72 June 2001
Slide 43
June 2001 43IBM Ease of Use Group Slide number
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
June 2001 44IBM Ease of Use Group Slide number
State Table
To ConfirmedConfirm
To Being Completed
Transfer Smoking
To Being Completed
Transfer Dates
To [final]Not available to the user
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 73 June 2001
Slide 45
June 2001 45IBM Ease of Use Group Slide number
State Table
To ConfirmedConfirm
To Being Completed
Transfer Smoking
To Being Completed
Transfer Dates
Must be confirmed
To [final]Not available to the user
Check In
Create is internal action so not available to the user
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
June 2001 46IBM Ease of Use Group Slide number
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
To [final]Not available to the user
Check In
Create is internal action so not available to the user
To Being Completed
Create
Being Completed
Confirmed[initial]
And finally show the things you cannot do with a confirmed reservation.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 74 June 2001
Slide 47
June 2001 47IBM Ease of Use Group Slide number
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
June 2001 48IBM Ease of Use Group Slide number
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
Design Outline Tasks
Design Abstract Views
Design Outline Tasks
Design Abstract Views
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
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 76 June 2001
Slide 3
June 10, 2001 3OVID Tutorial, IBM Ease of Use Group Slide number
The Realization Phase
Slide 4
June 10, 2001 4OVID Tutorial, IBM Ease of Use Group Slide number
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
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 77 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
June 10, 2001 5OVID Tutorial, IBM Ease of Use Group Slide number
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
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 78 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
June 10, 2001 6OVID Tutorial, IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 79 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
June 10, 2001 7OVID Tutorial, IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 80 June 2001
Slide 8
June 10, 2001 8OVID Tutorial, IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 81 June 2001
Slide 9
June 10, 2001 9OVID Tutorial, IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 82 June 2001
Slide 10
June 10, 2001 10OVID Tutorial, IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 83 June 2001
Slide 11
June 10, 2001 11OVID Tutorial, IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 84 June 2001
Slide 12
June 10, 2001 12OVID Tutorial, IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 85 June 2001
Slide 13
June 10, 2001 13OVID Tutorial, IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 86 June 2001
Slide 14
June 10, 2001 14OVID Tutorial, IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 87 June 2001
Slide 15
June 10, 2001 15OVID Tutorial, IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 88 June 2001
Slide 16
June 10, 2001 16OVID Tutorial, IBM Ease of Use Group Slide number
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”.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 89 June 2001
Slide 17
June 10, 2001 17OVID Tutorial, IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 90 June 2001
Slide 18
June 10, 2001 18OVID Tutorial, IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 91 June 2001
Slide 19
June 10, 2001 19OVID Tutorial, IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 92 June 2001
Slide 20
June 10, 2001 20OVID Tutorial, IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 93 June 2001
Slide 21
June 10, 2001 21OVID Tutorial, IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 94 June 2001
Slide 22
June 10, 2001 22OVID Tutorial, IBM Ease of Use Group Slide number
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
June 10, 2001 23OVID Tutorial, IBM Ease of Use Group Slide number
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
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 95 June 2001
Slide 24
June 10, 2001 24OVID Tutorial, IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 96 June 2001
Slide 25
June 10, 2001 25OVID Tutorial, IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 97 June 2001
Slide 26
June 10, 2001 26OVID Tutorial, IBM Ease of Use Group Slide number
Presentation View Model
The image on this slide shows the object views superimposed on their respective model elements
Slide 27
June 10, 2001 27OVID Tutorial, IBM Ease of Use Group Slide number
Presentation View Model
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
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 98 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
June 10, 2001 2IBM Ease of Use Group Slide number
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
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 100 June 2001
Slide 3
June 13, 2001 3IBM Ease of Use Group Slide number
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
June 10, 2001 4IBM Ease of Use Group Slide number
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
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 101 June 2001
Slide 5
June 10, 2001 5IBM Ease of Use Group Slide number
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
June 10, 2001 6IBM Ease of Use Group Slide number
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
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 102 June 2001
Slide 7
June 13, 2001 7IBM Ease of Use Group Slide number
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
June 13, 2001 8IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 103 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
June 10, 2001 9IBM Ease of Use Group Slide number
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
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 104 June 2001
Slide 10
June 10, 2001 10IBM Ease of Use Group Slide number
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
June 10, 2001 11IBM Ease of Use Group Slide number
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
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 105 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
June 10, 2001 12IBM Ease of Use Group Slide number
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
June 2001 3IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 107 June 2001
Slide 4
June 2001 4IBM Ease of Use Group Slide number
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
June 2001 5IBM Ease of Use Group Slide number
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
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 108 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
June 2001 6IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 109 June 2001
Slide 7
June 2001 7IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 110 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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 111 June 2001
Slide 10
June 2001 10IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 112 June 2001
Slide 11
June 2001 11IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 113 June 2001
Slide 12
June 2001 12IBM Ease of Use Group Slide number
SatSurvey Example
Here is a sample of the SatSurvey – which is a CUPRIMDSO survey instrument.
Slide 13
June 2001 13IBM Ease of Use Group Slide number
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 $
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 114 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
June 2001 14IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 115 June 2001
Slide 15
June 2001 15IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 116 June 2001
Slide 16
June 2001 16IBM Ease of Use Group Slide number
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
June 2001 17IBM Ease of Use Group Slide number
References and Resources from Rational
To round things out – here are some references from the Rational Web site – www.rational.com
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 117 June 2001
Slide 18
June 2001 18IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 118 June 2001
Slide 19
June 2001 19IBM Ease of Use Group Slide number
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’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
June 2001 20IBM Ease of Use Group Slide number
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 120 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)
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 121 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
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 122 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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 123 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
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 124 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)
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 125 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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 126 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
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 127 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, …
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 128 June 2001
..and this interaction diagram.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 129 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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 130 June 2001
Exercise 2
Arriv ed at desk
presents credit card
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
gets credit card authorization
creates key
hand key to guest
searches f or reserv ation
Showing reserv ation
allocates room to guest
Showing room detail
Check in complete
Lef t desk
: Existing Syst emJulian : Front Desk ClerkJackie : VacationerArriv ed at
desk
presents credit card
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
gets credit card authorization
creates key
hand key to guest
searches f or reserv ation
Showing reserv ation
allocates room to guest
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 131 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
Room(from Logical View)
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
Room(from Logical View)
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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 132 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.
Can't happen, there's no guest.
Can't happen, there's no 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.
Creating the compelling user experience make it easy 2001
©IBM 2001 Page 133 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.