More Elements of UX: real-world design deliverables

more
elements of
user experience
real-world design deliverables

peter boersma
(This presentation was delivered to the attendees of UX Russia 2010, on October 7, 2010 in
Moscow, Russia.)
Hello, my name is Peter Boersma, and I want to show you what real-world, user experience
design deliverables your UX team could be making and how you can become more effective by
using the right design process.

1988-1995 Information Ergonomics, Twente University
Enschede
1995-2002 Designer & Consultant, General Design & Satama
Amsterdam/Hamburg/Helsinki
2002-2004 Information Architect, EzGov
Amsterdam/London/Jamaica
2004-2005 Partner & Consultant, User Intelligence
Amsterdam/Ireland
2005-2010 Interaction Designer, Info.nl
Amsterdam
2010-now Experience Designer, Adaptive Path
Amsterdam/Austin/San Francisco

I have a background in Computer Science and Cognitive Psychology, and worked as a UX
designer and consultant for the last 15 years, for different companies and mostly in
Amsterdam.

A the moment, I work for a company called Adaptive Path, you may have heard of us... ;-)

Adaptive Path helps teams and organizations create products and
services that deliver great experiences to improve people’s lives.
consulting

experience

research events
experience

design 4,000
participants
experience

strategy
r+d 20
countries

8
50
books

hundreds
of articles
c o n s u lta n c i e s

thousands
of readers

We design interactive systems that improve people’s lives. We have a consulting branch, and
R&D branch, and we organize training events for the UX community.

We have offices in San Francisco, Austin (Texas), and Amsterdam.

Our clients used to be in the United States, but we are going global, more and more.

more
elements of
user experience

so, back to my talk: MORE elements of User Experience.

more
elements of
user experience

If I say “more elements”, what is the original set of elements?

Yes, it is Jesse James Garrett, and he wrote this book: The Elements of User Experience.

The book is the long version of this diagram, which introduces 5 layers (or “planes”) to think
about when you design User Experiences.

2000
The book was written in 2000(!)

and I think it is time for a new edition of the book, but with MORE elements of user
experience.

Of course, this image is FAKE (although I must say Jesse is working on a second edition).

more
elements of
user experience

So, what are these “MORE” elements of User Experience?

Or: what does the diagram look like?
?

Design
Strategy Research

Well, the original diagram was mostly about Design, and a little bit about Strategy and
Research.
I believe all 3 of these elements have a place in my diagram, although Design plays a smaller
role there...

Business

Manage Strategy

Process

Evaluation Research

Design

And what is missing are important steps such as “Evaluation”, “Management”, and “Business”.
And the whole thing is being held together by Processes. THAT is my model for User
Experience design.

Business

these
influence the
Manage User Experience Strategy
too!

Process

Evaluation typical Research
User-Centered
Design

Design

Notice how the lower 3 elements together form the TYPICAL USER CENTERED DESIGN process
(Research, Design, Evaluate).
BUT, the other elements can all determine the success or failure of a User Experience, just
like the lower ones!
And...all together, they form...

more
elements of
user experience

The Elements of User Experience!
So, now that we know these...

more
elements of
user experience

...it is time to see some real-world design deliverables!

Pitch Estimate
Business
Optimize Scenarios

Beta Position
Roles

Manage Strategy
Steps Service Design
Scope Competition

Process
Test Interviews
Review Requirements

Evaluation Research
Roadmap

Personas
Prototype

Design Sketch

Detailed Design Concept

What you see appear here, is a list of 15 deliverables that I will show: 2 or 3 per element.
And for Process, there are 6 more deliverables.

Pitch Business Estimate

Scenarios

Let’s start with Business, with the “Elevator Pitch” that you present to win a project (if you are
an outside agency), or get approval for a project (if you work inside an organisation).

And the secret to winning pitches is....good pictures!

Pictures that show you have a good sense of business...

Pictures that show you can see things from above...

Pictures that show you want to ﬁnd the treasure, together with your client.

And pictures of Apple products. You just HAVE to have those :-)

Pictures that show the client needs to make choices. Tough choices!

pitching is all about
en-vision-ing

Pitching is all about showing you have a VISION for the future.

Pitch
Business Estimate
Scenarios

Next up are Estimates.

How many sunﬂowers do you see here?

“many”
and

“a lot”
are good first guesses!

if you answered “many” or “a lot”, those are good ﬁrst guesses. 20 x 25 (that’s 500) was also
a good estimate.

input for estimates output
scope items
requirements assumptions
approach calculations
team skills explanations
experience with subject risks
experience with client
experience of client

when available when possible

A good estimate is based on these types of input, assuming they are available (list on left)
... you can turn them into this type of output, if you know enough to create them (list on
right).

output example output
assumptions assuming
we design 10 wireframes
(5 complex + 5 medium)
+ 15 components
calculations we estimate
(explanations) we need 320 hours
(5x16 + 5x12 + 15x12)
risks but
we don’t know the
developer’s
documentation needs

Here is an example: (list on right)

1. make estimates honest
2. use margins to wow client

The rules for estimates are:
1. Make your estimates honest and
2. IF you include a margin, try to use it to exceed the client’s expectations, to “wow” them.

Pitch Estimate
Business
Scenarios

Let’s move on to Business Scenarios.

portal (portal)

promo promo service
info info (login)

service
(login)

A or B
Business scenarios sketch different approaches to business problems. They may be
ILLUSTRATED in terms of possible designs, but really are about much more general decision
on how to do business. The example here shows two approaches for an international
INVESTOR COMPANY that wanted to redesign its International PORTAL, its PROMOTION-
oriented brochure site, and it’s SUBSCRIPTION-ONLY service section.
- Scenario A suggested ONE, integrated portal for all countries, with one navigation scheme
for the Global, Info and Service sections.
- Scenario B suggested SEVERAL, loosely connected sites, some of which would not be
available in some countries, and each with their own, specialized navigation and content.
At the time my UX team advised them, the client ended up choosing approach A which meant
they had to create a lot of extra content, but also that they only had to promote 1 website.
Later they changed their mind...because they wanted to do business indifferent locations in
different ways, and scenario B matched that model better.

define business scenarios
so they help you decide
how
you plan to win the war

...

Position
Strategy
Competition

Businesses cannot survive without a good Strategy. Strategies determine HOW TO WIN THE
WAR.

communities
client competitor competitor
sub-brand sub-brand
(future)
Big Big
Competitor Competitor
sales content
Competitor
Competitor

Competitor Competitor
client Competitor
(now)

core brand
Positioning is about WHERE you fight the war. Companies need to find their PLACE in the
COMPETITIVE LANDSCAPE. When they change their strategy, they will find themselves in new
terrain, with new competitors. They need to determine how they present themselves to the
outside world, and how to DIFFERENTIATE themselves from their competition.
The example shows how a Publishing client chose a new strategy that included an EXTRA
swing towards “Sales” to not find themselves in the middle of similar competitive brands.

1. find a place on a map
2. see who’s there

So, Positioning is all about ﬁnding a place on the map of the competitive landscape, and
defending your position against the competition.

Position

Strategy
Competition

Speaking of competition...

Here is a story of how the CAR INDUSTRY was looking at the competition.
What you will see is a series of advertisements that were placed in subsequent editions of this
South African car magazine.

It all started when BMW placed and ad to “congratulate” Audi for winning a “local”
competition.

Audi got its revenge the next month, when it mentioned that it had a great history in the
famous car race “The 24 hours of Le Mans”.

And then Subaru stepped up, pointing out that beauty isn’t the most important thing for a car
(look at that picture! See how much of it is ENGINE?)

...and ﬁnally, Bentley responded by showing this man on a leather couch, wearing a suit, and
telling everybody how important they were...

“know your enemy”
(Sun Tzu, The Art of War)

Competitive reviews are all about knowing who is around you, and how you can beat them.

Position

Strategy
Competition

Interviews

Research
Personas

Next up is research to see WHO is ﬁghting the war for WHICH users.

business
stakeholders

The ﬁrst group of people you want to interview are the BUSINESS STAKEHOLDERS. They
should be the inﬂuencers in the client organization, the ones who can make or break your
project.

ask
what is the idea?
will it help you reach your goals?
will customers accept it?
why now?
how fast can you move?

and find out value of answers

You ask them these questions about the problem, your idea for the solution, how it affects
their business goals and how they think customers feel about it. You also want to know why
the project needs to happen now.

ask: what is the idea?

Analyzing the answers from the stakeholders, you can see what the idea for the problem is
about.

ask: why now?

This chart shows that a project needed to happen because the competition was ahead on
some important factors of the website.

and find out the value of answers

But the survey also discovered that the people who wanted this change were product
marketeers, even though the project was commissioned in part by the Support organization.

users

We all know you should deﬁnitely talk to the USERS.

ask
who are you?
what do you use now?
how do you feel about it?
when is it a good/bad day?
what should it be like?

and find out value of answers

These questions help you understand what their current situation is and where/how a new
solution could help.

ask: who are you? etc.
Hardware Engineer
Can you please describe your role?
System Engineer

Field Application Engineer

Software Engineer

Board Engineer

Test Engineer

Quality Engineer

Component Engineer

Other Engineering role

Program/Project Manager
What information is most important to you? (1 = most important / 3 = third most important)
Purchase Manager

Purchaser

Sourcer
Rich Media (Videos, Interactives, etc.)

Price

Environmental Information

Sustainability

Block Diagrams (or other visualizations)

Application Information

Do you use social media as part of your job? General Product Information

0.00 0.50 1.00 1.50 2.00 2.50 3.00

Yes. I often use social media for
work.
I rarely use social media for work.

No. I never use social media for
work.

Ideally, all of your interviews with users are face-to-face, but occasionally it helps to do some
quantitative measurements too.

and find out the value of answers

What is the size of the organization where you work (all locations combined?)

Less than 10 employees
10 to 100 employees
100 to 500 employees
1,000 to 10,000 employees
10,000 to 100,000 employees
More than 100,000 employees

In this case the client wanted to move to server smaller companies, so ﬁnding out that more
than 50% of the answers came from companies with less than 100 employees was reassuring.

“you are not the user”

Remember to be objective and not let your opinion count too much.

Interviews

Research
Personas

Now on to a deliverable that I think most of you are familiar with....

Personas. You know what they are like: a PICTURE and some KEY FACTS. And hopefully
statements about how they feel about your system.

where do they come from?

But where do these proﬁles come from?

In our case, we listen closely to the DATA, like the recordings from face-to-face interviews.

While listening we realized they had different behaviors that we started mapping on
scales,
for example (on top) from MAKER (“I need to finish this project now”) to LEARNER (“I come
here to learn and apply the knowledge much later”).
Or (lower on) PERSONALISATION, where people ranged from totally AGAINST (I do not
want you to filter information for me, based on my profile) to YES, PLEASE (“if you can
suggest new things to me, I am happy”).
...The stories of individual interviewees can still be traced
...But you can also see groupings emerge.

And when we clustered them, 3 main, connected groups appeared. (WE CHECKED with the
original stories)

And if you separate these
out...

Of course with all the data behind them...about NEEDS and VALUES

find personas in the data

...so don’t start with personas in mind and ﬁll them with data, FIND them IN the data.

Design Sketch

Now we slowly come into the DESIGN phase. Here is where switch from deﬁning PROBLEMS to
SOLUTIONS. First, with sketches.

And at Adaptive Path, we sketch with a Sharpie...

Sketching with markers

Yellow marker
Look at me!

Sharpie markers
More attention Fat

Regular

Start here Small

Gray marker
Depth:
Pop forward
Push back

Actually, with different kinds of Sharpies, as well as Gray and Yellow markers:
* start with the small sharpie. It lets you be ﬂexible, even though you’re working in permanent ink.
• Use bold markers to emphasize important things like page borders or callouts.
• Add a yellow highlight to things that you want to yell, “look at me!” like alerts or buttons.
• Add gray shading to areas that are less important, that you want to push back.

It’s not about HOW to sketch, but WHAT to sketch

We have different kinds of sketching for different points in the process
The techniques and goals of the two kinds are very different.

we use templates like this for EXPLORATORY sketching, where you want to document as many
different ideas as possible.

...and later we switch to this template to combine the best ideas into one reﬁnement.

and so we produces sketches and we hang them on whiteboards to evaluate.

and then we produce some more, and evaluate.

...and when we run out of whiteboards, we use the WALLS.

...and when we run out of walls we CONTINUE ON THE WINDOWS.

you can never have
too many sketches

We produce a lot of sketches AND I ENCOURAGE YOU TO DO THE SAME.

Design Sketch

If you have many rough ideas, you want to consolidate them in one, central CONCEPT.

This image, plus a one-sentence description (“CLOCKY is a clock that runs away when it goes
off”), describe the concept in enough detail for a high-level understanding.

www.BigDutchBank.com
is...

a personal, retail bank
where you learn about, configure and buy
products & services
alone, based on stories, or with an advisor

but you may want to add to that one sentence, and create layers of explanation behind
different words (in this case SHOWN AS HYPERLINKS).

Life

Play Buy

Learn

or you can create a diagram that shows how certain types of content help the business reach
their goals.

Or you combine a sentence
...with a diagram, which can become complex.

flow: confirm appointment

1 2

3 6

4 5

and if you have a good enough idea of user ﬂows through your concept, you can highlight
where certain USER SCENARIOS take you in the solution.

express concepts as
sentence, model or flow
(or a mix)

There are several ways of showing your client a Concept. Make it an exciting presentation;
THIS IS WHAT SELLS THE SOLUTION, and it is also a POINT OF REFERENCE for future design
decisions.

Design Sketch


many detailed design decisions will REFER BACK to the CONCEPT. Detailed design can be
SIMPLE OR COMPLEX, depending on the need of the project.

if
the level of detail
in your design specification
goes up like this:

...

...via annotated wireframes...

and HEAVILY annotated wireframes..

...with different STATES for each component, and FLOWS to show when you reach what
state...

...and the number of STATES goes up...

...and the FLOWS become more and more complex...

then
it may be time to write more
formal design specification
documents

...

you may want to create a FUNCTIONAL DESIGN document, with entries for each page type,
each component, per user role, with ﬂows, business rules, and user permissions.

...and those documents may need good VERSION MANAGEMENT, showing what changed after
each REVIEW.

Similarly, visual designers may create STYLEGUIDES that explain the rules behind their
designs.

...but also describing interactive visual behaviors.

make design specifications
match the needs of the project

...

Test

Evaluation

Prototype

To help you determine if your design is working (to EVALUATE YOUR WORK), you could create
a prototype, if only to test if your rules work out in practice.

A prototype can be a PAPER PROTOTYPE, that can even EXPOSE FUNCTIONALITY.

...and where CONTENT CHANGES, based on actions of the user.

or you can work with visual designers to show what a design of SEPARATE COMPONENTS
would look like.

Some people even use EXCEL to prototype.

But of course there are also more suitable software tools, like that of a SPONSOR of this
conference.

use what you like:
paper, PowerPoint, Excel,
Axure, HTML or Flash,
but
prototype

so no matter what design, TRY IT OUT.

Test

Evaluation

Prototype

I don’t think I have to spend a lot of time on USability Evaluation, right?

observer

facilitator
participant

In an evaluation with REAL USERS, you have a participant, a facilitator or moderator to help
him, and an observer to..ahem..take notes.

I encourage you to READ THIS BOOK about usability evaluation.

try any of these
remote usability testing tools

then for remote testing, there are A LOT OF TOOLS that can help you test a design.

read this book

..and again, THIS BOOK explains a lot about this topic.

1. test early & often
2. have a test strategy

I encourage you to test early and often and to write up a test strategy early in the project that
states WHEN you want to test WHAT artefact with WHO (users), WHY (goals).

Optimize

Beta

Manage
Scope

We’re getting CLOSE TO THE END of the circle. Let’s look at ways to PREVENT SCOPE CREEP
and LAUNCH A SERVICE.

essential pick
just a few of
these for your
project!
quick winner!
win
easy hard

repair quality

contribute
In selecting scope items to be part of the project, you can map them on 2 axes:
1) from easy to hard to design or implement.
2) from a mere contribution to the project to being essential for the project.
Each quadrant has its own attributes (REPAIR, QUALITY, QUICK WIN and WINNER).
From the WINNER quadrant, you can only pick a few, or the project becomes too complex.

1. classify scope-items
2. select the winners

Place the scope items on a scale (or two) and select the ones that should make it into the
project.

Optimize

Beta
Manage
Scope

Sometime you want to launch systems in STAGES, starting with a BETA.

beta flow

@news @news

Beta New
Current Beta New

Here’s how that could work:
Next to your current system
...You develop a Beta
...and announce it, for example in a newsletter. Allow people to explore the Beta from the
site.
...and to return to the normal site if they want to.
...when you are SATISFIED, you announce that the Beta will become the new site
...and then you make it the new site
...and then you can do it all over AGAIN.

“(1) tell them what you’re
going to do,
(2) do it, and
(3) tell them what you’ve
done”

A lot of this is about communication around the Beta, about keeping PEOPLE INVOLVED and
giving the a chance to TEST, give FEEDBACK. You MANAGE EXPECTATIONS.

Optimize
Beta

Manage
Scope

and FINALLY, when a design is launched, it needs MORE MANAGEMENT. You need to listen,
measure and OPTIMIZE.

You may want to experiment with alternative designs. Like this...

28% better
versus this. WHICH ONE WORKS BETTER?
The one with the picture of the man behind this site worked 28% BETTER.
You can try alternative designs using A/B Test tools like Google Website Optimizer.

In The Netherlands, our former state-owned Telecommunications company KPN
experimented with these 3 designs for their splash-page (TAGS, DROPDOWNS, LISTS).
It looks like the 3rd one worked best, because their current website looks like that one the
most.

experiment
to learn what works
for your design

...

Pitch Estimate
Business
Optimize Scenarios

Beta Position

Manage Strategy
Scope Competition

Process
Test Interviews

Evaluation Research
Personas
Prototype

Design Sketch


and with that, we’re at the end of the circle.
...but to make all of this happen, there are some more, longer term processes at play...

Roles


Process
Review Requirements

Roadmap

...and we will explore those too. I have identiﬁed 6 process-related deliverables.

more
elements of
user experience

Oh, at this point, I end up talking less about CONCRETE DELIVERABLES...

more
elements of
user experience
real-world design processes

...and more about ABSTRACT PROCESSES.

Roles


Process
Review Requirements

Roadmap

Let’s start with the roles that UX team members play.

UX roles in projects
account management
sales
research
build

prototype
design
concept
st rategy
optimize
scope evaluate

project management

User-Centered design dictates that we play the ROLE of Researcher, Designer, and Evaluator...

UX roles in projects
account management
sales
research
build

prototype
design
concept
st rategy
optimize
scope evaluate

project management

...but, as I have shown today, many other ROLES WITH ASSOCIATED SKILLSETS can (or should)
be played by UX team members.

UX skills: T-model

wide experience

knowledge
deep

Let me quickly introduce the T-MODEL:
On the HORIZONTAL, you place your general (but shallow), WIDE KNOWLEDGE.
On the VERTICAL bar, you place your specialty, your expertise, your DEEP KNOWLEDGE.

T-model

user experience

architecture
information

For example: your horizontal bar could be User Experience, and your vertical bar Information
Architecture.

T-model

user experience

interaction
design

Or, User Experience and Interaction Design.

Or both!
interaction
design
T-model

information
architecture
user experience

T-model

user experience

information architecture
interaction design

usability testing
user research

visual design

prototyping
In fact, for User Experience, a lot of ﬁelds could be in your vertical bar.
And you could have different levels of expertise in all of them.
But all together, they make you an experience designer.
And the same is true for fellow members of your UX team.

a good team is made of
overlapping T-shapes

You create a good UX Team by putting people together with different expertises in their
vertical bars.

Roles


Process
Review Requirements

Roadmap

Now on to Service Design. Service Design is a BUZZ WORD at the moment, but for me it is
about two things:

First about determining where you can make an impact:
This type of Activity Diagram can help you determine WHERE in the organisation or process
your chances lie in improving the experience.
You create such a diagram, by LISTING the activities that are unique to a service, then
INDIFYING connections between activities, identify the ones you can have an IMAPACT on,
and DESCRIBE the impact you can have on THE WAY THE SERVICE IS DELIVERED.

And secondly, Service Design is about mapping different layers of a service:
Service Designers create, after extensive research and a lot of design exercises, Service
Blueprints like this one with (from top to bottom) Physical Evidence, User Actions, visible
Service Personnel Actions, and invisible Service Personnel Actions which are supported by
internal Processes.

service designers
look for
the next bigger context

When designing a system, always try to look to what’s at the next higher level.
For interactive systems, that is the service that makes the system work.

Roles


Process
Review Requirements

Roadmap

Then a look at requirements, and how those are linked to the design process.

<stakeholder>
wants
<something>

It is helpful to think of requirements in terms of this FORMAT: a STAKEHOLDER wants
SOMETHING.
During and after your analysis of the business environment and user needs, list as many of
these as you can

user wants overview
user wants speed
user wants consistency
user wants fun
user wants personalization
user wants anonymity
content wants freedom
manager
admin wants consistency
CEO wants insight
But remember:
requirements from different types of stakeholders may SUPPORT and CONTRADICT each
other.

user wants overview
user wants speed
user wants fun
manager
CEO wants insight
In this example, the User requirements list both Personalization and Anonymity, which may
be hard to combine (because of storing of personalized settings, versus not storing anything
at all).

user wants overview
user wants speed
user wants fun
manager
CEO wants insight
Sometimes different roles have contradicting requirements, such as the Freedom versus
Consistency requirements highlighted here.

user wants overview
user wants speed
user wants fun
manager
CEO wants insight
And, being all about the USER EXPERIENCE, if the users also want consistency...

user wants overview
user wants speed
user wants fun
manager
CEO wants insight
...Consistency will likely “win”.

1. make requirements
comparable
2. link requirements
to design decisions

Make sure you are ready to make trade-offs by making requirements COMPARABLE; that is: in
the same format and/or at the same level of granularity.
And if you can ﬁnd a way to trace design decisions back to requirements, you are ready to
defend your design by referring to (agreed upon) requirements.

Roles


Process
Review Requirements

Roadmap

Next up are Roadmaps, which come in handy when there is too much scope to design in one
go.

moment moment moment moment
progress progress
progress progress
Area progress progress Area
progress

progress progress
progress
Area Area

Area

Roadmaps look at the HORIZON, at what the FUTURE brings.
...You create them by thinking about the AREAS you want to specify PROGRESS in.
...Then you map the ﬁrst, realistic improvements.
...And then the improvements that are further away.
...And ﬁnally, you try to map them to milestones,
...to moments in the future.

...And this is what a realistic, real-world roadmap might look like.

1. define the future
of the system
2. define incremental steps
towards that future

...

Roles


Process
Review Requirements

Roadmap

A good designer is not afraid to show his work to others, to have it reviewed.

⤿
design
design
review

To make a design better, you review it. But how does a Design Review work?

design review

project

⤿
review

prepare design design
team client
design
review review review
review review

tools
review

...A good review is PREPARED by determining what needs to be reviewed by who, and by
making sure everyone sees the design.
...Then there may be up to 3 reviews before the TEAM review:
- a PROJECT review (with the project manager) to make sure the deliverable matches the
project schedule and scope
- the “real” DESIGN review (with the design lead) to make sure the deliverable matches the
design concept
- a TOOLS review (with the designer’s senior or competence lead) to make sure the right
tools and templates are used (this is especially important in environments with lost of
regulations and standards)
...Then a review with the TEAM can happen (or with designated reviewers in big teams) to
make sure all of the team’s deliverables match and complement each other. And ﬁnally a
CLIENT review can happen (with someone responsible for sign-off) to make sure the
deliverable gets approved.

⤿

⤿

⤿
approach design delivery
approach design deliver
review review review

So, to make a design better, you REVIEW it. When you are happy with the results, you DELIVER
it, and REVIEW THE DELIVERY; that’s when you look at how the process went (according to
plan or not?) and what you learned from designing the system (did you apply new tools or
techniques? did you create new designs that may be candidates for reusable patterns?)

But to make sure you design & deliver the right thing in the right way, you create an
APPROACH and your REVIEW THE APPROACH before you start; that’s when you look at
whether your estimates match historic benchmarks and whether the team agrees with the
proposed deliverables and team roles.

reviews are work too!

Reviews are an important part of creating solutions.
Make sure there is plenty of time in the project’s schedule for reviews.
A good rule of thumb is to devote 10% of your time to reviews.

Roles


Process
Review Requirements

Roadmap

and, ﬁnally, let’s have a look at what Design Processes look like, how they convey the steps
that a UX team takes.

?
A B

How do you usually get from the START of a project to the END of a project? How do you get
from A to B?

A 1 2 3 4 B

4a
2a
C 1 3 4b 5 6 D
2b
4c
And, are the steps you take to get from A to B the same as the steps you take to get from C
to D?

na A P
rs o M
Pe T E
S I

ir e- wire
fram
re qu es usabi
ts lit y
m en test

re en design proto-
Sc principles
W
F LO type
I encourage UX teams to organize a session where each team member lists ALL of the team’s
deliverables and writes them on Post-It notes.
Then the team can compare them and agree on the NAMES of deliverables.

u ire- design wire proto-
req ts principles fram
es
men type

1 2 3 4

AP
s ona M n usabi
Per TE Sc ree lity te
st
SI
FL OW

The next step is to place them in the order that they will most likely occur, from the start of
the project to the end.
Try to identify milestones, or go/no-go moments. These will be the lines between the
different phases of your process.

user concept detailed prototype &
research design design evaluate

and tehn try to ﬁnd names for process phases that make sense to your team, your
colleagues, and your clients.

user
research

detailed
design
concept
C design D

prototype & prototype &
evaluate evaluate

And sometimes, for certain projects, you may ﬁnd yourself doing things DIFFERENTLY, but
you will at least use the same BUILDING BLOCKS.

rs ona
Pe

Then, for each deliverable, you create a so-called “1-PAGER”: a description of the
deliverable’s Goal, Shape, Contents, Reviewers, Relation to other deliverables, whether the
client needs to Sign it off, and (optionally) where the Intructions or Template can be found. It
also helps to have a good EXAMPLE available.

And then you MEASURE to see if your EFFICIENCY improves. The fact that your team now
agrees on the steps of your process, uses common names and deﬁnitions for deliverables,
and has good examples or even instructions to work from, should all help you deﬁne your
approach quicker, estimate required time and efforts better, reuse deliverable formats, and
communicate to your client more clearly. All of this allows you to spend your remaining time
on a BETTER DESIGN.

?
A 1 2 3 4 B

Let’s have a look at what other UX teams have come up with, in terms of name of phases and
diagrams of how they work.

Here is a very SIMPLE AND BASIC diagram, only listing the names of phases and indicating
there is some ITERATION happening.

This one is slightly more complex, as it also lists the activities carried out, and the
deliverables that are created. Can you spot them?

This one is beautiful. Very simple, because of the 3 steps (Discover, Design, Deliver) but with
the right amount of detail in terms of deliverables. And I love the suggestion that there is
focus and progress, with the lines and arrow!

Here is one I created in 2003 for EzGov. We mapped UX deliverables to RUP-phases (RUP =
RATIONAL UNIFIED PROCESS, a standard for software development processes, supported by
IBM). We mapped them horizontally to roles...and the arrows show when deliverables from
one role are used by another role.

You can make these design process diagrams as complex as you like. You can add sub-
phases and descriptions of phases, as shown in this example.
What is also remarkable is that USUALLY, in these diagrams, the thing the team is best at, or
wants to sell, is in the center of the diagram.

...and sometimes it’s just a bit to the right :-) I kept this diagram because it is so beautiful
(and because it has “Win” in big letters)!

wire
u ire- design fram
es proto-
req ts principles
men type

user concept detailed prototype &
reseach design design evaluate

AP
s ona M usabi
Per TE n lity te
st
SI Sc ree
FL OW

but really, it is okay if your ﬁrst version of your design process diagram looks like this for a
while!

don’t copy
a design process diagram;
create your own

After seeing these, I want to stress that I encourage all UX Teams to CREATE THEIR OWN
DIAGRAMS.

Roles


Process
Review Requirements

Roadmap

...and that concludes our look at process related deliverables.

Pitch Estimate
Business
Optimize Scenarios

Beta Position
Roles

Manage Strategy
Scope Competition

Process
Test Interviews
Review Requirements

Evaluation Research
Roadmap

Personas
Prototype

Design Sketch


..which means we have seen ALL of the real-world design deliverables
...as well as the design process deliverables...

more
elements of
user experience

peter boersma

..so you have seen ALL of my Elements of User Experience with associated real-world design
deliverables.

And since this book is not available... (yet ;-))

you will have to do with this version...

Business

these
influence the
Manage User Experience Strategy
too!

Process

Evaluation typical Research
User-Centered
Design

Design

...and remember there is MORE. More than the typical User-Centered Design phases, and the
work you do in other phases have an impact on the User Experience too!

вопросы?

peter boersma

Are there any questions?

more
elements of
user experience

peter boersma
Thank you!
(Yes, you too, even if you weren’t actually at UX Russia ;-))

More Elements of UX: real-world design deliverables

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie More Elements of UX: real-world design deliverables

Ähnlich wie More Elements of UX: real-world design deliverables (20)

Mehr von Peter Boersma

Mehr von Peter Boersma (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

More Elements of UX: real-world design deliverables