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 real-world design deliverables so, back to my talk: MORE elements of User Experience.

more elements of user experience real-world design deliverables 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.

2000 The book was written in 2000(!)

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

more elements of user experience real-world design deliverables 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 real-world design deliverables The Elements of User Experience! So, now that we know these...

more elements of user experience real-world design deliverables ...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 real-world design deliverables 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 real-world design deliverables 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 real-world design deliverables ...

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

You get the personas.

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

and BEHAVIORS and ATTITUDES.

find personas in the data real-world design deliverables ...so don’t start with personas in mind and ﬁll them with data, FIND them IN the data.

Design Sketch Detailed Design Concept 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 real-world design deliverables We produce a lot of sketches AND I ENCOURAGE YOU TO DO THE SAME.

Design Sketch Detailed Design Concept 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) 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.

Design Sketch Detailed Design Concept 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: ...

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

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.

...to the level of PIXELS.

...but also describing interactive visual behaviors.

make design specifications match the needs of the project real-world design deliverables ...

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

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

Pitch Estimate Business Optimize Scenarios Beta Position Manage Strategy Scope Competition Process Test Interviews Evaluation Research Personas Prototype Design Sketch Detailed Design Concept 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 Steps Service Design Process Review Requirements Roadmap ...and we will explore those too. I have identiﬁed 6 process-related deliverables.

more elements of user experience real-world design deliverables 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 Steps Service Design 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 real-world design processes You create a good UX Team by putting people together with different expertises in their vertical bars.

Roles Steps Service Design 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 real-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.

Roles Steps Service Design 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 consistency user wants fun user wants personalization user wants anonymity content wants freedom manager admin wants consistency 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 consistency user wants fun user wants personalization user wants anonymity content wants freedom manager admin wants consistency 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 consistency user wants fun user wants personalization user wants anonymity content wants freedom manager admin wants consistency CEO wants insight And, being all about the USER EXPERIENCE, if the users also want consistency...

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 ...Consistency will likely “win”.

1. make requirements comparable 2. link requirements to design decisions real-world design processes 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 Steps Service Design 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 real-world design processes ...

Roles Steps Service Design 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! 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.

Roles Steps Service Design 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 real-world design processes After seeing these, I want to stress that I encourage all UX Teams to CREATE THEIR OWN DIAGRAMS.

Roles Steps Service Design Process Review Requirements Roadmap ...and that concludes our look at process related 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 ..which means we have seen ALL of the real-world design deliverables ...as well as the design process deliverables...

more elements of user experience real-world design deliverables 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 real-world design deliverables peter boersma Thank you! (Yes, you too, even if you weren’t actually at UX Russia ;-))

More Elements of UX: real-world design deliverables

by Peter Boersma on Oct 11, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 5

Statistics

More Elements of UX: real-world design deliverables — Document Transcript