More Elements of UX: real-world design deliverables

transcript

moreelements of

user experiencereal-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 Enschede1995-2002 Designer & Consultant, General Design & Satama Amsterdam/Hamburg/Helsinki2002-2004 Information Architect, EzGov Amsterdam/London/Jamaica2004-2005 Partner & Consultant, User Intelligence Amsterdam/Ireland2005-2010 Interaction Designer, Info.nl Amsterdam2010-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... ;-)

events

4,000 p a r t i c i p a n t s

20 c o u n t r i e s

50 c o n s u l t a n c i e s

consulting

e x p e r i e n c e

researche x p e r i e n c e

designe x p e r i e n c e

strategy

hundredso f a r t i c l e s

8b o o k s

thousandso f r e a d e r s

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

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.

three locations

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

clients world-wide

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

moreelements of

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

moreelements of

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

Do you know who this is?

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.

2000The book was written in 2000(!)

2010And now it is 2010...

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).

moreelements of

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

?Or: what does the diagram look like?

Design

ResearchStrategy

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...

Process

Evaluation

Manage

Business

Design

Strategy

Research

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.

Process

Manage

Business

Strategy

Evaluation

Design

Research

theseinfluence the

User Experience too!

typicalUser-Centered

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...

moreelements of

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

moreelements of

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

Business

Design

ResearchEvaluation

StrategyManage

Scenarios

Position

Service Design

Roadmap

Prototype

RequirementsReviewTest

Optimize

Estimate

ConceptDetailed Design

Sketch

Personas

Competition

Process

Interviews

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.

BusinessPitchScenarios

Estimate

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 find 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 abouten-vision-ing

real-world design deliverables

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

BusinessPitch

Scenarios

Estimate

Next up are Estimates.

How many sunflowers do you see here?

“many”and

“a lot”are good first guesses!

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

output

assumptionscalculationsexplanations

when possible

input for estimates

scope itemsrequirements

approachteam skills

experience with subjectexperience with client

experience of client

when available

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).

example output

assumingwe design 10 wireframes(5 complex + 5 medium)

+ 15 componentswe estimate

we need 320 hours(5x16 + 5x12 + 15x12)

butwe don’t know the

developer’s documentation needs

output

assumptions

calculations(explanations)

Here is an example: (list on right)

1. make estimates honest2. use margins to wow client

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

BusinessPitch

Scenarios

Estimate

Let’s move on to Business Scenarios.

portal

promo info

service (login)

(portal)

promo info

service (login)

A BorBusiness 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 scenariosso they help you decide

howyou plan to win the war

Strategy

Position

Competition

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

Competitor

competitor sub-brand

sales content

core brand

communities

client (future)

Competitor

CompetitorCompetitor

competitor sub-brand

Competitorclient (now)

Big Competitor

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 map2. see who’s there

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

Strategy

Position

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 finally, 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.

Strategy

Position

Competition

Research

Personas

Interviews

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

business stakeholders

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

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.

We all know you should definitely talk to the USERS.

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.

Can you please describe your role? Hardware Engineer

System Engineer

Field Application Engineer

Software Engineer

Board Engineer

Test Engineer

Quality Engineer

Component Engineer

Other Engineering role

Program/Project Manager

Purchase Manager

Purchaser

Sourcer

Do you use social media as part of your job?

Yes. I often use social media for work.

I rarely use social media for work.

No. I never use social media for work.

0.00 0.50 1.00 1.50 2.00 2.50 3.00

General Product Information

Application Information

Block Diagrams (or other visualizations)

Sustainability

Environmental Information

Rich Media (Videos, Interactives, etc.)

What information is most important to you? (1 = most important / 3 = third most important)

ask: who are you? etc.

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

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

and find out the value of answers

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

“you are not the user”real-world design deliverables

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

Research

Personas

Interviews

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 profiles 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...

You get the personas.

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

and BEHAVIORS and ATTITUDES.

find personas in the datareal-world design deliverables

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

SketchDesignConceptDetailed Design

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

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

Sketching with markers

Yellow marker

Regular

Gray marker

Sharpie markers

Start here

More attention

Depth:Pop forward

Push back

Look at me!

Actually, with different kinds of Sharpies, as well as Gray and Yellow markers:* start with the small sharpie. It lets you be flexible, 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 processThe 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 refinement.

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 havetoo many sketches

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

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.

a personal, retail bankwhere you learn about, configure and buy

products & servicesalone, based on stories, or with an advisor

www.BigDutchBank.comis...

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

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

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

express concepts assentence, model or flow

(or a mix)real-world design deliverables

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.

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

ifthe level of detail

in your design specification goes up like this:

...from sketchy wireframes...

...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...

thenit 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 flows, 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.

...to the level of PIXELS.

...but also describing interactive visual behaviors.

make design specificationsmatch the needs of the project

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

prototypereal-world design deliverables

so no matter what design, TRY IT OUT.

Evaluation

Prototype

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

observer

facilitatorparticipant

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 theseremote 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 & often2. 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).

Manage

Optimize

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

easy hard

contribute

essential

quickwin

repair quality

winner!

pickjust a few of these for your

project!

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-items2. select the winners

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

Manage

Optimize

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

Current Beta New

beta flow

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”real-world design deliverables

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.

Manage

Optimize

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% betterversus 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.

experimentto learn what works

for your designreal-world design deliverables

Manage

Optimize

Process

BusinessPitch

Scenarios

Estimate

Design

ResearchEvaluation

Strategy

Position

Prototype

Sketch

Personas

Competition

Interviews

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...

Process

Service Design

Roadmap

RequirementsReview

...and we will explore those too. I have identified 6 process-related deliverables.

moreelements of

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

moreelements of

user experiencereal-world design processes

...and more about ABSTRACT PROCESSES.

Process

Service Design

Roadmap

RequirementsReview

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

strategy concept design

research

evaluate

account management

project management

prototypebuild

optimizescope

UX roles in projects

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

strategy concept design

research

evaluate

account management

project management

prototypebuild

optimizescope

UX roles in projects

...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

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

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

T-model

user experience

Or, User Experience and Interaction Design.

T-model

user experiencein

Or both!

T-model

user experiencevi

In fact, for User Experience, a lot of fields 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

real-world design processes

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

Process

Service Design

Roadmap

RequirementsReview

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 designerslook for

the next bigger contextreal-world design processes

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.

Process

Service Design

Roadmap

RequirementsReview

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

<stakeholder>wants

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

useruseruser useruserusercontentmanageradminCEO

wantswantswants wants wantswantswants

wantswants

overviewspeedconsistencyfunpersonalizationanonymityfreedom

consistencyinsight

But remember:requirements from different types of stakeholders may SUPPORT and CONTRADICT each other.

wantswants

consistencyinsight

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).

wantswants

consistencyinsight

Sometimes different roles have contradicting requirements, such as the Freedom versus Consistency requirements highlighted here.

wantswants

consistencyinsight

And, being all about the USER EXPERIENCE, if the users also want consistency...

wantswants

consistencyinsight

...Consistency will likely “win”.

1. make requirements comparable

2. link requirementsto 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 find a way to trace design decisions back to requirements, you are ready to defend your design by referring to (agreed upon) requirements.

Process

Service Design

Roadmap

RequirementsReview

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

Area Area

progress

progress progress

progress

progress progress

moment momentmoment moment

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 first, realistic improvements....And then the improvements that are further away....And finally, 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 futureof the system

2. define incremental steps towards that future

Process

Service Design

Roadmap

RequirementsReview

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

design reviewdesign

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

design reviewdesign

design review

prepare review

project review

team review

client review

design 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 finally a CLIENT review can happen (with someone responsible for sign-off) to make sure the deliverable gets approved.

design reviewdesign

approach reviewapproach deliver

delivery 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!real-world design processes

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.

Process

Service Design

Roadmap

RequirementsReview

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

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 B21 3 4

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?

SITEMAP

wireframesrequire-

mentsusability test

Screen

FLOWproto-type

designprinciples

Persona

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.

1 2 3 4

Persona

SITEMAP

wireframesrequire-

usability testScreen

proto-type

designprinciples

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.

userresearch

conceptdesign

detaileddesign

prototype & evaluate

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

C Dconceptdesign

detaileddesign

userresearch

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

Persona

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 definitions for deliverables, and has good examples or even instructions to work from, should all help you define 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 B21 3 4

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)!

userreseach

concept design

detaileddesign

Persona

SITEMAP

wireframesrequire-

usability testScreen

proto-type

designprinciples

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

don’t copya design process diagram;

create your ownreal-world design processes

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

Process

Service Design

Roadmap

RequirementsReview

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

Business

Design

ResearchEvaluation

StrategyManage

Scenarios

Position

Service Design

Roadmap

Prototype

RequirementsReviewTest

Optimize

Estimate

Sketch

Personas

Competition

Process

Interviews

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

...as well as the design process deliverables...

moreelements of

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...

Process

Manage

Business

Strategy

Evaluation

Design

Research

theseinfluence the

User Experience too!

typicalUser-Centered

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?

moreelements of

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