how do you build the right thing? -...

How do you build the right thing?

Experience design in practice

Part 1: The Case of the Disappearing Design Phase

Exploring common approaches and their

adaptations from real-‐world projects

PERSPECTIVES

Share this ebook.

https://twitter.com/intent/tweet?text=I+just+read+:+How+do+you+build+the+right+thing?+Download+it+for+free+http://bit.ly/14JyF7k





http://www.facebook.com/sharer/sharer.php?u=http://bit.ly/12ZHmKD





http://www.linkedin.com/cws/share?url=http://bit.ly/12ZHmKD





http://bit.ly/1aZxl57































































































Share this ebook:© 2013

Contents

2

Introduction 3

The case for Design 4

Finding the time for design -- Ben Melbourne 5

Agile and UCD -- Darius Kumana and Jon Dickinson 9

Lean UX and Rapid Innovation -- Riley Graham 12

Evolution of Visual Design - A Workflow -- Matt Copeland 15

In Summary 18

About the authors 19

Be in this ebook 20
























































http://www.facebook.com/sharer/sharer.php?u=http://bit.ly/14JyF7k











Introducing our musings on Experience Design

3

Adam Monago,VP Digital Marketing, ThoughtWorks

From computers to cars, design has returned to the

forefront of building great products. Many will

argue that it never went away. But for those of us in the trenches of software design, the last decade

has been marred by too many projects doomed by

customers brainstorming themselves a feature-rich

mess.

Today, the Lean Startup is in fashion and Agile has become a comfortable pair of shoes. Successful

software design today can be characterized by

integration, iteration and interaction.

Integration as in the true sense of the phrase

'continuous integration', where developers integrate their code multiple times a day to flesh

out kinks. We must do this with our designs as well.

Iteration means we don't get it correct the first

time; we plan for a product that's minimum viable

and expand from there.

Interaction represents how we work with our

customers and in turn how we would like them to

experience our product.

ThoughtWorks embraced Agile development early-

on in its life, as it allowed us to focus on rapid delivery of value to our customers.

Over the years, we have expanded our kit-bag to

include research and contextual inquiry, facilitation

and game storming. These tools help us manage a demanding customer.

The "internet of things" has placed an additional

demand on our people; The nature of many web

and mobile products being built today includes

software but also extends beyond it. It includes handheld devices, original content and artwork.

Production involves a cast of many teams with

specialized skills. Products are intended to be used

at work and at home. Building them has become

less about developing features and more about designing experiences.

This eBook is first in a series of three and tries to

answer the question “Where did the design phase

go?” It collects a series of essays from

ThoughtWorks designers around the world who are addressing product design challenges head-on by

fusing agile development practices with the

disciplines of interaction design. Within the

following volumes, we will focus on the ‘Designer’s

Toolkit’ and ‘Embracing Constraints’.

We hope you enjoy the first installment.



































































The Case of the Disappearing Design Phase

4



































































When I first started working in an Agile

environment I was excited to have finally reached

the land of opportunity. I was well aware of the problems with Waterfall. The big-upfront design

phases, painful stakeholder reviews, having to

endlessly review and revise wireframes, countless

annotations explaining every microscopic detail,

disconnect between developers and User Experience (UX). I thought all these problems would

magically disappear with Agile - developers would

become my best friends, my wireframes wouldn’t

need to be minutely detailed, no more double digit

document version numbers, my designs might get launched in the same year I created them.

However, I soon realized that these things don’t just

happen automatically. Agile opens up an exciting

new way of working for designers, but it also

presents a new set of challenges. To experience the benefits, I had to adjust the way I worked. These

are some of the challenges I’ve faced and

adjustments I’ve learnt to make to my UX practice

along the way.

Challenge #1: No time to explore ideas and find innovative solutions With Agile, dedicated design time becomes a

precious commodity. The traditional user-centered

design approach - taking the time to conduct in-

depth user research, analyze and document them, and then design an extensive solution is an

expensive luxury that is rarely affordable.

It’s hard to take the time when a team of

developers is waiting for to you to finish so they can start.

Challenge #2: Time spent exploring ideas is a “waste” when you’re trying to be Lean.The traditional creative process involves playing

with designs and seeing where they lead. More often than not, the designs get discarded, but the

learnings fold back in to the overall solution.

Once you start to embrace Lean way of thinking,

taking the time to play around with different

options, only to discard them can feel like your deliberately “wasting” time.

This “test and learn” approach is actually a core

part of Agile, but we have to do it in a different way.

“Finding the time for design”

Ben, User Experience and Interaction Designer

5

Stop, I need to explore

more ideas!

Ways to fit the creative exploration process into your Agile process. And produce better results for it.

(continued...)



































































Challenge #3: Getting out of the deliverable business.Our traditional approach of producing shiny, all-encompassing deliverables doesn’t work with Agile.

Not only is time scarce, but the documents are

usually out-of-date before you finish them. On the

flip side, it’s not just a matter of producing lots of

low-fidelity prototypes to hand over to developers. There can still be communication breakdowns.

Adjusting our practiceAll of these challenges can be overcome, with some

adjustment to our practices to get the most out of

the Agile process. We need to focus on the value we

deliver, and not just the output. We’ll find that it actually improves our ability to create awesome

experiences. These are some of the ways I’ve learnt

to adjust my practice to be a better designer.

Adjustment #1: UX as a facilitator, not just a designer.Change the way you see your role in the team. Let

go of control of every little detail and empower our

team. We need to become an information radiator,

not the sole source of knowledge. Give everyone

the knowledge required to build a great product that meets the needs of your target audience.

Adjustment #2: Design as a continuous activity.Make design an ongoing activity, not just a phase. Agile UX isn’t just about breaking our activities into

small chunks, i.e. mini-waterfall. It’s about changing

our approach and how we work.

Other fields are embracing the “Continuous”

approach. Product management is adopting Lean Startup - launching a Minimum Viable Product

(MVP), testing and proving a proposition, then

continuing to evolve it. Development teams are

using Continuous Delivery to enable regular

software releases (daily, not a few big releases a year) thus reducing feedback cycles, testing and

learning rapidly.

We need to change our approach to embrace these

benefits - shorten our feedback cycles, learn quickly,

find out what experiences work and build on them.

As designers we need to embrace this approach to “continuous” improvement.

6

(continued...)

Use your UX skills to take the team on a journey of understanding and empathizing with the user

We need to use prototypes as a communication tool,

not just a deliverable. We need to get out of the deliverables business.

“Finding the time for design”Ways to fit the creative exploration process into your Agile process. And produce better results for it.

(...continued)


































































http://theleanstartup.com/




http://continuousdelivery.com/

http://continuousdelivery.com/

http://uxdesign.smashingmagazine.com/2011/03/07/lean-ux-getting-out-of-the-deliverables-business/





Adjustment #3: Do just-enough, just-in-time.Just-in-time design does what it says on the tin.

Don’t try to do everything upfront, as change is relentless. If you do too much upfront, the

requirements will probably change by the time you

get your designs out there. Make decisions at the

last responsible moment.

Tools and TechniquesThese are some tools and techniques I’ve been

using to make these adjustments to my practice.

Collaborative design workshopsCollaborative design workshops involve getting

both the stakeholders and the team in a room and

sketching out their ideas about what the product

should/could be. You then put it all up on a wall where everyone can contribute to it. This

“sketchboard”, is great to kickstart projects and

inform the story writing process. The sketches can

also quickly be turned in to prototypes to test and

validate the team’s ideas.

Use Iterations to shorten your feedback loopsEach iteration allows us to design and build

something new. Quickly turning design ideas into

working code, and thus shortening the feedback

loop. The functioning ideas can then be tested and

improved. No more waits for months/years to see if our design works. We can do it immediately.

Co-LocationProblems throwing things over the wall? There

shouldn’t be one in the first place. Co-locate

yourself with and become part of the development team. Multidisciplinary teams working in the same

place sharing ideas is a key principle of Agile. Don’t

waste time typing emails when you can have a quick

conversation. Developers and designers want to

work together and learn from each other. Co-location naturally allows for this to happen.

Sketchboard -‐ a lightweight shared vision of the product

7

Start by sketching a vision, then figure out the details as you go.

“Finding the time for design”Ways to fit the creative exploration process into your Agile process. And produce better results for it.

(continued...)

(...continued)


































































http://jasonfurnell.wordpress.com/2010/12/01/facilitating-collaborative-design-workshops-a-step-by-step-guide-for-rapidly-creating-a-shared-vision-for-execution/

http://jasonfurnell.wordpress.com/2010/12/01/facilitating-collaborative-design-workshops-a-step-by-step-guide-for-rapidly-creating-a-shared-vision-for-execution/


Design WallsAs details start to emerge, turn your Sketchboard

into a Design Wall. Fill in the details of your vision as you go. Claim space alongside the Project team’s

card wall. Put out wireframes and visual designs on

the wall and radiate details of the UX design.

Lightweight production Do just enough, just in time. Do not aim to capture every detail upfront. Capture just enough, and then

have a conversation. Sometimes a paper sketch is

enough, sometimes a hi-fi mock is required. It is the

conversation that is important. The closer you can

get to designing in code the better.

Conducting lightweight research Bring user feedback into the team as often as you

can. Go guerrilla - run three sessions every Friday,

or every iteration. Make it easy for the team to

watch. Capture your findings on Post-it notes, not in

PowerPoint. Often you can put the findings into action right away. Especially if the team is still

working on the feature.

Add usability fixes to the backlog If you can’t act on usability fixes straight away,

become part of the Agile process and prioritize usability fixes like everything else. Write up stories

for them and add them to the backlog. The product

owner can make an informed decision about

whether to prioritize them, or build something new.

This helps avoid the tension of designers trying to squeeze small fixes into the workload in an

unstructured way.

Creating great experiencesSome of these Agile ideas are not too dissimilar to

existing UX techniques. Often they just have a different name to what we usually call them. Some

principles can be easily applied to the design

process, with just a bit of willingness to learn and

adapt.

As designers, Agile provides us some great lessons and opportunities to work in better ways. At the

same time we can add value to the process as well.

Our ability to visually communicate ideas and share

a vision helps drive the process and provide a

customer focus which can often be lost in the mix of delivery activities.

They key goal is have an entire team collaborating

together, finding ways to combine their skills and

talents together to create great experiences.

8

“Finding the time for design”Ways to fit the creative exploration process into your Agile process. And produce better results for it

(...continued)


































































http://jasonfurnell.wordpress.com/2011/05/02/from-sketchboards-to-blueprints-facilitating-detailed-conversa

http://jasonfurnell.wordpress.com/2011/05/02/from-sketchboards-to-blueprints-facilitating-detailed-conversa

http://www.sensible.com/rsme.html

http://www.sensible.com/rsme.html


The agile software development movement has

made huge improvements in reliability when

delivering software, increasing return on investment, and reducing the risk of building

software. However, in a world of iPhones and

Google apps, this may no longer be enough.

People are beginning to expect more from

software. They expect it to work, intuitively and hassle free, as if it were built just for them. As users

become more computer savvy, they have a better

understanding of how they expect programs to

behave. More often than not, users know what they

want to achieve. Any software that hinders them from efficiently achieving their goals will quickly be

replaced. This is particularly true with Internet-

based applications where a viable alternative is only

a web search away.

There is no doubt that to continue to provide value

for our customers, we must continue to apply the

principles of the agile development philosophy. But, in order for our software to be truly successful in

the eyes of its biggest critics, we must endeavor to

adopt a more user-centered approach.

What is User-Centered Design (UCD)?UCD can be applied to the design of anything that has a user—from mobile phones to kitchens. When

integrating UCD with agile practices, we apply it to

software development. With agile development, the

primary measure of progress is related to working

software. Once you adopt a user-centered philosophy, this is no longer the whole story.

Unlike agile, UCD is not focused on the customer—

it is centered on the end-user. Furthermore, from a

UCD standpoint, software is incidental; what is

important is that end-users can easily and efficiently achieve their goals—with or without

software.

Why do we need User-Centered Design?There are a number of benefits that arise when

advocating a user-centered philosophy. User-based research provides a mechanism against which

design decisions can be validated and tested.

Evidence-based decisions mean that guesswork is

minimized. What to build becomes much less of a

matter for debate. More importantly, by keeping a product’s end-users at the heart of its design and

development process, the end result is far more

9

(continued...)

“Agile and UCD”Core values of embracing change and responding to customer feedback make Agile and User Centered Design (UCD) a natural fit.

Darius, Head of Experience Design

Jon, ThoughtWorks Alumni, now Director of Innovation at Equal Experts



































































likely to be useful, usable, and meaningful.

The era of feature-centric development is coming to

an end. Consumers are beginning to realize that more features do not always mean a better product.

In the current maturing marketplace, quality of

experience is far more likely to be a product

differentiator than number of features--think

iPhone vs. Nokia or Wii vs. PS3.

UCD provides a way to engineer these quality

experiences. As such, it empowers development

teams to create products and solutions that are

competitive in today's discerning market. By

embracing a UCD philosophy, one could argue (as Peter Merholz does in "Experience Is the

Product" [1]) that we should not just create

products and services—we should aspire to build

better overall experiences where the value (both

quantitative and qualitative) to all concerned is obvious.

Commonalities Between UCD and Agile A striking but sometimes overlooked similarity

between agile and UCD is that both are often

fundamentally misunderstood to be methodologies—magical, step-by-step recipes that you can follow

to guarantee project success. In fact, agile and UCD

are both philosophies.

There are different methodologies that implement

the agile philosophy: XP, Scrum, the Crystal family,

etc. There are also several interpretations of UCD.

User experience (UX) aficionados can learn from the

way products and experiences are created by the likes of Adaptive Path, Cooper, Apple, Shedroff,

Morville, Spool, Nielsen, and Norman. While the

specific methods are very different, the underlying

philosophies are undeniably similar.

Both agile and the UCD philosophies are iterative; they progress in small steps providing opportunities

for verification and refinement along the way.

The Conflict Between UCD and Agile There is a history of conflict between agile

developers and UX designers. Agile software development is predominantly a developer-led

philosophy, while UCD is, in many organizations,

championed by creatives. There will always be a

healthy, natural tension between these left-brained

and right-brained individuals.

If we examine the principles behind the agile and

UCD philosophies, then we are much more likely to

find tangible issues that can be addressed to

facilitate agile developers and UCD practitioners

working together to create quality software and robust user experiences, rather than falling back on

the age-old argument that developers are from

Mars; designers are from Venus.

To better understand the disconnect, let's compare

some of the principles of the Agile Manifesto that cause conflict with the UCD philosophy:

10

(continued...)

(...continued)




































































The Agile Manifesto focuses directly on providing value for the customer, whereas UCD champions the end-user—the idea being to create software that users "cannot live without." By delivering such intuitive software we cannot fail to deliver knock-on value to our stakeholders.

The concern here is the definition of working. The aim of this Agile principle was to get development teams out of the mindset that creating a lot of design documentation before writing code was helping to meet the project deadline. The goal of a software development project is to produce functioning software, not UML diagrams. With UCD, software that simply works is a secondary measure of progress. Much more important is whether the software helps users achieve their goals.

Agile development calls for early delivery of the software to the customer. This is not synonymous

with releasing to end-users. The customer's public

release strategy can be entirely separate from this

process. Early delivery to customers allows beta tests

or usability trials to be performed and the customer to realign his priorities based on the findings. If we

release too early to the market, the end-user

experience could be poor or worse.

For example, in 2005, the early release of handsets

touted as "feature complete" and "bug free" cost the mobile phone industry $4.5 billion: "One in seven

mobile phones are returned within the first year of

purchase ... 63% of the devices being returned are

done so without fault." "Most of these issues may be

addressed through stringent device testing and usability modeling prior to the launch of the mobile

device." [2]

Common Issues When Integrating UCD and Agile

Design without constraints When the design of a system is created with users and customers but without regular feedback from a development team, there is significant risk of a design being proposed and approved when no onehas any idea of how long it will take or how much it will cost to implement. When the estimate does come in, and it’s far above the amount expected,

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

. —Agile Manifesto

11


(...continued)

(continued...)

The equivalent UCD principle might read:Our highest priority is to help create an experience for end-users where they can achieve their goals easily and efficiently with minimal disruption to their mental model of the problem space.

Working software is the primary measure of progress.. —Agile Manifesto

The equivalent UCD principle might read:The satisfaction of end-user needs (user goals) balanced with the achievement of business goals is the primary measure of success.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

. —Agile Manifesto
































































it is understandable that the customer will feel let

down by the development team. To compound the

problem, the design team will often be frustrated that the only way to deliver the software within the

real budget will be to "water down" its design. As

stated in the Agile Manifesto: Business people and

developers must work together daily throughout the

project. In this context, it is often considered that the UCD practitioners would operate as part of the

customer team [3] to help drive the direction of the

product.

Validate with real-world usage UCD is an iterative process that calls for designers to validate and refine their design regularly. While the

design is being created, many techniques are used

to perform this validation that provide value through

quick and short feedback loops. Despite this, we

maintain that the design of a successful user experience cannot be completed without feedback

from people using the real system. This is where we

get benefit from the Agile principle: Our highest

priority is to satisfy the customer through early and

continuous delivery of valuable software.

To be able to perform and respond to this level of

validation, it is necessary to have the design team

integrated with the development team to run the

tests and modify its design based on the findings.

Handover is the enemy of understanding Whenever one team is responsible for creating

something it will hand over to another team, there is

a risk that the receiving team won’t understand the

theory or mental model behind the item. This is a

common problem even when the two teams have

similar backgrounds, but it is compounded when the teams have very different skill sets and

backgrounds, as is the case with development and

design teams. When designers want developers to

implement their ideas, it is not enough to pass on

screen shots or scribbles. There must be a shared understanding of the problem domain and the

theory describing the reasons why certain decisions

have been made. Like the Agile Manifesto says: The

most efficient and effective method of conveying

information to and within a development team is face-to-face conversation.

No time to iterate A common flaw, articulated by both Alistair

Cockburn [4] and Jeff Patton [5], is that on an agile

development team people forget to iterate, or at least forget to plan to iterate. It is quite common for

an agile software development team to forget that

the point of all the feedback is to allow customers to

inspect and verify the features that they have

requested. The result is that it comes as a shock to the customer that valuable features must be

postponed when a recently implemented feature

needs to be iterated over again.

When taking a user-centered approach to agile

development, it is critical that we make time to iterate so we can respond to user feedback without

pushing out features that we have told the

customers they will receive.

12

(...continued)

(continued...)

































































There are a couple of strategies to manage this: Take

a percentage of your initial estimate and add it to

the schedule, or consider Alistair Cockburn's approach of creating three cards for user rights [6]

by planning the implementation and two additional

iterations of each story.

However you solve this problem, the first step is

recognizing that while providing shorter feedback loops to the customer and users is valuable, it

doesn't count for much if we don't plan to get the

benefit from the feedback we receive. Keep in mind

the importance of the agile principle that says we

should: Welcome changing requirements, even late in development. Agile processes harness change for the

customer's competitive advantage.

Divided responsibilities; divided teamsAgile developers often focus more on the delivery of

software than on valuable software. Following the "you aren't gonna need it" [7] mindset, agile

developers run the risk of just developing the

minimum of what they are asked without actively

taking the responsibility to volunteer information

regarding alternative approaches to the product owner or UCD practitioner. We must actively

challenge the mindset of divided responsibility --

"You spec and design it; we'll build what you spec."

Everyone should work toward the shared vision of a

successful experience.

The flip side of this is the UCD practitioner or

product owner is not actively seeking collaboration

from the development team and, therefore, not

being aware of the technical constraints upon the

proposed design. This is addressed by the agile

principle: Business people and developers must work together daily throughout the project.

Conclusion

In today's marketplace, experience is king. In the

eyes of end-users, what makes software great is

their perceived experience. So how do we build great software? As one would expect, there is no magic

formula.

Not only does agile provide us with tangible software

sooner, but it also provides the transparency and

constant feedback against which we can validate and steer decisions. UCD can help us remain focused on

the goals, frustrations, and desires of our end-users

A successful combination of these two philosophies,

while sometimes painful for the practitioners

involved, will result in the creation of product experiences that provide the "wow" factor to

captivate the discerning users of today’s market.

{end}

References: [1] Experience IS the Product...and the only thing users care about

[2] 'No Fault Found' returns cost the mobile industry $4.5 billion per year

[3] Twelve emerging best practices for adding UX work to Agile development [4] Incremental versus iterative development

[5] The Neglected Practice of Iteration

[6] Three cards for user rights [7] You Arent Gonna Need It

13


(...continued)































































http://www.core77.com/reactor/06.07_merholz.asp




http://www.wdsglobal.com/news/whitepapers/20060717/20060717.asp




http://www.agileproductdesign.com/blog/emerging_best_agile_ux_practice.html




http://alistair.cockburn.us/Incremental+versus+iterative+development

http://alistair.cockburn.us/Incremental+versus+iterative+development

http://www.stickyminds.com/s.asp?F=S13178_COL_2

http://www.stickyminds.com/s.asp?F=S13178_COL_2

http://alistair.cockburn.us/Three+cards+for+user+rights

http://alistair.cockburn.us/Three+cards+for+user+rights

http://c2.com/xp/YouArentGonnaNeedIt.html

http://c2.com/xp/YouArentGonnaNeedIt.html


“Lean UX and Rapid Innovation”

14

A fatty analogy to explain the benefits of lean User Experience (UX)

Riley, User Experience consultant

Earlier this year, I worked for a client, in a start-up

environment, who needed extensive user research

to validate their product concept and bring it to market. We conducted lean User Experience (UX)

research continuously throughout the development

process and quickly took the product to market.

The results of our research were incredibly

significant. A lean UX process helped us validate business goals, identify market needs and afford

opportunities for innovative change.

As an exampleLet me explain how the process might have worked

for a media group publishing digital content.Enchanting Tales, a start-up media group within a

larger enterprise, was looking to build a new

product. They owned their own content, which was

incredibly competitive in the market and quite

valuable to the company. Through market research and business initiatives, they had identified an

opportunity for the creation of a product that

would present their content and act as its

distribution vehicle to customers. This opportunity

opened doors for user experience research and lean UX methods that would let them quickly

deliver product innovation.

What is lean UX?The goal of UX design is to create a seamless

experience for users. Many different methods and processes support this goal. They are highly

dependent on the development environment, but

the ultimate objective for a UX designer is to

understand and support users’ needs. This end

certainly justifies the means. For a UX designer,

there are two approaches to UX research and design: lean and fat.

I’ll use the concept of body mass to help explain

this. There are two aspects of a healthy body mass:

• Fat mass: A healthy human body requires

6%-25% of body fat for men; 12%-30% of body fat for women. The human body uses good fats

for energy, to protect organs from injury,

cushion the skin, and build myelin, which makes

it possible for nerve cells to fire electrical

messages to think, see, speak, and move.

• Lean mass: This comprises everything else

except fat—bones, organs, and muscle.

In summary, a human being has a healthy body

mass when fat mass is low and lean mass is high.

Why does any of this matter and how does it relate to lean UX? As body mass comprises both fat and lean mass,

UX comprises fat and lean UX approaches.

• Fat UX ApproachesYou can think of fat UX approaches in the same way that you think of fat mass in the human

body. Fat approaches are healthy for user

experience and integral to the viability of the

overall product. As fat body mass builds myelin

to help the body to function, fat UX approaches build deliverables to support a product’s

longevity. Their output is high-fidelity prototypes,

(continued...)


































































Share this ebook:© 2013 15

wireframes, pixel-perfect comps, large

requirements documents, and other design

deliverables. While these support the product-development process and are often necessary,

they are only a part of the creation of a user

experience.

• Lean UX ApproachesSimilar to lean body mass, lean UX approaches are less about creating deliverables and more

about delivering a user experience. Lean UX

approaches involve the creation of low-fidelity

prototypes, concepts, maps, internal validation,

usability tests, and plenty of design and development iterations. These are necessary,

even essential, but discrete from the user

experience itself.

So, while UX designers use both fat and lean UX

approaches, since the end goal is ultimately the rapid innovation of great, healthy user experiences,

that end justifies only a minimal amount of fat in a

superlatively lean process.

The Story of lean UX at Enchanting TalesFor Enchanting Tales, lean UX was essential to get their product to market quickly. They wanted the

new service to house their published magazine

content and upset the market in a way that kept

them competitive within their product’s market

space. The product team had plenty of ideas aboutwho its users might be and what they might want,

providing a starting point for the project.

They needed to generate cheap, but valuable ideas

quickly, so the team had to conceptualize,

communicate, develop, and test quickly.

Once we had conducted a contextual inquiry and

aggregated the available marketing research, we

developed personas. We then focused our research

on the first area of knowledge that Enchanted Tales

defined as a business goal. Our goal was to provide data to users in multiple facets.

After conceptualizing solutions with the business,

we wanted to learn about the market response, so

we sketched a low-fidelity prototype. We used this prototype to test the concept with users in the

marketplace and learned that data organization

was very important to them.

“Lean UX and Rapid Innovation”A fatty analogy to explain the benefits of lean User Experience (UX)

(continued...)

(...continued)



































































During our interviews, (part of a contextual inquiry

where anthropologists and researchers visited

users in their natural environment), we experienced users categorizing different types of

information from the magazine to facilitate better

understanding.

Using our lean UX process to iterate on our

prototype, we then validated the business goal of providing data to users in multiple facets. Our low-

fidelity prototype categorized the following

overarching data types: articles, videos, and photos,

displaying them on multiple device types through

responsive web design. Once usability testing had validated this business goal, we developed our UX

design solution. It met the needs of users by

organizing data effectively and fulfilled the business

goal by segmenting data, then providing it to users

in multiple facets.

Once the development team had developed the

actual code, using an Agile process, we went back

out to test the build with users. On our second go-

round, we learned that users tended to access the

website from multiple devices. Therefore, while they were pleased with segmented content, the

site’s information architecture did not sync with

their mental model of the magazine. Users were

looking for content, not by type, but by date of

publication.

Luckily, our lean UX process afforded us the ability

to sketch a revised low-fidelity prototype and

validate it in the marketplace with real users, then provide the results to the team.

We were able to redesign the information

architecture, while also remedying problems in the

responsive design that may have caused some

usability issues during our first round of testing.

Using lean agile practices, the development team

was able to code our latest designs quickly for a

new round of testing and validation.

ConclusionTo get an innovative product to market quickly and efficiently, it is best to employ a lean UX approach

during each iterative development cycle because it

lets you validate business goals and identify market

needs and provides opportunities for innovative

change.

For Enchanted Tales, a lean UX approach validated

the business goal of providing data to users in

multiple facets, identified the fact that the

organization of magazine content is incredibly

important to users, and through iterative UX design and development, enabled this startup to stay

ahead of the curve, while discovering what might

come next.

Originally published on UXMatters, [January 07, 2013]

“Lean UX and Rapid Innovation”A fatty analogy to explain the benefits of lean User Experience (UX)

(...continued)









































http://uxmatters.com/

http://uxmatters.com/


Matt, User Experience Designer

“Simplistic” Waterfall

“Realistic” Waterfall

A seemingly simple process? If you’ve designed in a waterfall workflow, you know that it actually looks more like:

• Designers and business communicate via documents - a very slow way to work.

• Designers spends hours building their visual language in a Photoshop document (PSD).

• A series of stakeholders spend lots of time on email to create a thick-document of feedback on the designs.

• Repeat (for weeks/months) until the stakeholders are happy with a picture of their website-to-be.

• Business finally delivers documents and requirements to development.

As designers never speak to developers prior to User Acceptance Testing (UAT), they have one shot at

communicating via documents. This means time lost writing, refining and digesting books of documentation.

Post that, as developers moves PSDs into visual assets, more translation time-consumers emerge - typefaces not suitable for web, non-normal blending in gradients, specific image treatments, inconsistent colors due to color-

pickers. As do “short-cuts”, like image-sprites cut from PSDs to save developers the hassle of fully translating PSD

into a Cascaded Style Sheet (CSS), which leads to technical debt and future problems (think retina screens.. and

beyond retina). (continued...)

Visual design workflow deltas from waterfall→landslide→agile→lean

“Evolution of Visual Design- A Workflow”




































































Landslide (version 1)

Progression of “landslide” (fake-agile). This is better than waterfall, but it still lacks pairing of the designer and

developer. It is common for teams to practice landslide without even knowing it. At least they are trying.

Agile (101)

Finally pairing!

• The designer creates the PSD. The key being that the PSD is piecemeal, not a comp.

• Brings the PSD to pair with the developer.

• Developer and designer pair on translating the PSD.

• Future proofing is discussed.

• Knowledge share / culture share can finally happen. Developers learn more about design principals used and

designers learn more about how to execute their designs in the final medium.


(continued...)

(...continued)

Landslide (version 2)


































































http://twitter.com/colemanicewater

http://twitter.com/colemanicewater


Lean (version 1)

(...continued)

This is fast

• Live changes to production code are the first and final medium.

• The designer and developer work in the final medium.

• The designer can tweak and polish on a consistent basis as their efforts are the final product.

• Icons, illustrations, and graphics are made as needed.

• Surprises are non-existent. You see how it looks in the browser now.

• Translation issues like non-normal blending methods for colors are non-existent.

• Feedback rounds result in modified stylesheets. No need for more documentation. Time and money is saved.

This is faster.

• Both are skilled as designers and developers.

• One of the pair may have stronger developer skills, the other may have stronger visual skills.

• Why two of them? Always pair. Never design in a silo.

• The team executes their ideas directly in code.

• No wasted time/money/documentation.



Lean (version 2)



































































Stay tuned for Part 2: The Designer’s Toolkit

20



































































Ben Melbourne

User Experience and Interaction Designer. Researcher. Design Thinker. Ideator. Collaborator. Visual Thinker. Sketcher. Agile Believer. ThoughtWorker. Sharpie sniffer. Killer of trees, one post-‐it note at a time.

I am a ThoughtWorks UXDesigner who specializes in creative direction, mobile and visual design.I like to muck around in stylesheets, write sass pattern libraries, and develop apps in rails and iOS.

I lead the Experience Design practice for ThoughtWorks Europe. I’m a massive advocate of Lean UX and disruptive innovation. I love engaging at a senior level and changing the way companies both work and think. I am interested in people: both their over-‐arching experiences as they interact with digital media products; and the nuances of culture, interaction, and behavior cultivated within the teams of people charged with the creation and delivery of those experiences.

I am an author, speaker… essentially a loud-‐mouthed pundit on the topic of software development. I’ve been working in the software industry since the mid-‐80’s. My main interest is to understand how to design software systems, so as to maximize the productivity of development teams.

I am an author, speaker… essentially a loud-‐mouthed pundit on the topic of software development. I’ve been working in the software industry since the mid-‐80’s. My main interest is to understand how to design software systems, so as to maximize the productivity of development teams.

Darius Kumana

Matt CopelandRiley Graham

I am an Experience Design (XD) software consultant with ThoughtWorks. I believe XD needs to be involved throughout the Agile process, and I’m passionate about using methods like contextual inquiry, user research, experience maps and sketch to code to keep the UX love going strong. A personal goal of mine is to keep up with the constant XD evolution, help to enact changes I am passionate about, and spread the word in the XD community.

I previously worked at ThoughtWorks, and am now director of innovation at Equal Experts. I organize the CodeKen conference which gives curious developers opportunities to find out more about interesting technologies. I also organize the DeNormalised conference that is focused on helping technologists make sense of the explosive growth in NOSQL and Big Data technologies.

Jon Dickinson


































































http://asinthecity.com

http://asinthecity.com

http://www.kumana.co.uk


http://matthewcopeland.me

http://matthewcopeland.me

http://www.rileyisme.com




http://blog.jonmdickinson.com/






Be in this ebook.

Tell us your story.We’d love to hear it. Email us your take on Experience Design and if it is interesting we’ll include it in this ebook

Email Us

22

Share this ebook.

Agile Project Management

Get the team togetherAgile workers talk often andwelcome change. Mingle creates ashared space to make quickdecisions and track details, evenwhen the team can’t be together.

mailto:[email protected]?subject=My%20Perspective%20on%20Experience%20Design













http://www.linkedin.com/cws/share?url=http://bit.ly/14JyF7k





http://bit.ly/12rc7UF




























































































































































how do you build the right thing? -...

Documents