Better together:How user experience design can help agile teams

Dmitry Nekrasovski | dmitryn.com | @dmitryn

Thanks for being here everyone, and thanks Glenn and Dave for having me.I’d like to talk to you today about user experience design, agile, and what it’s like to have the two working together.Before we get started, let’s do a quick poll.

Have you heard the term “user experience design” before coming to this talk?

If so, have you worked with a user experience designer?

Let’s start by clearing up a few misconceptions...

User experience design is not pixel pushing.

Don’t get me wrong, pixel-level visual design is important.But it’s only a part of the way people experience products and systems.User experience design incorporates visual, interaction, and interface design.

User experience design is not just about usability.

“The Princess Rescuing Application” by Danc

http://www.lostgarden.com/2008/10/princess-rescuing-application-

Making things easy for people to use is important, too.But again, it’s only a part of the experience.Games are a great example of an experience where making things too easy can lead to a suboptimal user experience.

User experience design is not a checkbox.

It’s not also not a rubberstamp, an exit criterion, or a chance to practice your pig lipstick application skills. It’s something that needs to permeate the entire product planning and development process.

User experience design is not just about the user.

Not all user needs can be addressed.Not all user feedback can be incorporated.Not everything that users are looking for makes sense in the overall business context.

So what is user experience design, then?

User experience design (or simply UX)

is at least three things: a process, a field, and a community.

UX the process is a holistic approach to designing

all aspects of the way people use a product or service...

“The User Experience Honeycomb” by Peter Morville

http://semanticstudios.com/publications/semantics/000029.php

... while balancing user needs with business goals and

technical, resource, and scheduling constraints.

... which often means a lot of objects in the air!

UX the field is a constantly evolving set of methods and tools

for researching, designing, and testing user experiences.

UX the community is a fast growing global network

of practitioners from many related disciplines...

“UX Disciplines” by Dan Saffer

http://www.kickerstudio.com/blog/2008/12/the-disciplines-of-user-experience/

Omitted from this diagram, but also arguably a part of the broader UX community, are user research and usability engineering.

... who are increasingly in demand as organizations realize the

business value of good user experiences.

From “The Laws of User Experience” by Kelly Goto and Anthony Franco

http://www.slideshare.net/EveFife/the-laws-of-user-experience-making-it-or-breaking-it-with-the-ux-factor

Teehan+Lax UX Fund performance

http://teehanlax.com/uxfund/

Yodlee: very successful, currently handles 85% of e-commerce transactions worldwide, but no comparison to Mint’s success.Now you might argue “sure, but this is just an atypical example”.Then take a look at the performance of the UX Fund created by the consulting firm Teehan+LaxIt outperformed all major stock indices... and that was before the iPhone, Android, etc.

“OK, that’s interesting, but why should I care?”

Now you might be thinking to yourself at this point:“OK, that’s interesting information, but I’m a developer (tester, scrum master, Agile coach).Why should I care about UX?How does it relate to agile?How could it and the people who do it possibly affect what I do?”Those are good questions. Let’s answer them.

UX and Agile are both similar and complementary.

At the recent Agile Roots conference, there was a talk titled UX and Agile: My Brother from Another Mother.I don’t think this is too much of a stretch.UX and Agile share many similarities and values, but also complement each other.

UX and Agile both represent new ways of thinking about

software product development.

UX and Agile are both focused on building products that are

useful and valuable.

UX and Agile both value iteration, collaboration, and

empirical feedback.

The focus of Agile is internal: on the dev team and its practices.

The focus of UX is external: on users and their practices.

The focus of Agile methodologies is typically internal.UX methods complement this by giving the development team a better understanding of the external context in which its software is used: the users, their activities, needs, priorities, and values.

UX methods can help Agile product owners to better

understand what is valuable to their customers and users.

Most Agile methodologies designate a Product Owner role who is responsible for helping the development team understand what is and is not of “business value”.But, they don’t define how the product owner comes up with and validates their understanding of what constitutes “business value”.UX methods can help product owners understand what is truly important to their customers and users, so that they can plan releases and sprints, and prioritize feature requests and defects, with these priorities in mind.

UX designers can help Agile teams make good “battlefield

choices”.

Alan Cooper, the father of Visual Basic and now a UX thought leader, has a great talk on the symbiosis of Agile and UX called An Insurgency of Quality. In it, he talks about the small decisions that software developers face many times every day, the tiny tradeoffs that can make or break a user experience, but whose importance is rarely understood by business stakeholders. Cooper calls this concept “battlefield choices”.These are choices that Agile teams can make in a more intelligent, data-driven, and user-conscious way with the help of UX designers.

Let’s talk about some concrete examples of UX activities and

deliverables that can support agile teams.

User research (interviews, observation, focus groups) can

provide the team with rich insights into user behaviour.

User research can feed into personas - fictional users

portraying specific user roles and their goals and needs.

Personas can then replace “the user” in Agile user stories.

As you probably know, a popular format for writing user stories in several Agile methodologies is“As a user, I want to accomplish <a task> because of <a reason>”.But, “the user” is everyone and no one in particular. This can cause difficulties for the team when it comes to making decisions about what “the user” is truly looking for.By substituting a specific persona for “the user”, an Agile product owner can give a team a better understanding of what kind of user the story is written for and what constraints will affect its implementation.

Design visions can provide a visual overview of a user’s

experience to remind the team of the project’s overarching goals.

Design vision by Amanda Holtstrom

(@HoltstromDesigns).

These can be used as “information radiators”, hung alongside Big Visible Charts, etc.

Mockups and interactive prototypes can serve to guide the

team’s implementation of stories in each sprint or iteration.

Story dependency diagrams can help the team visualize

relationships between stories and across iterations or sprints.

Usability tests can provide product owners and teams with

empirical data for making business and technical decisions.

In summary, UX methods and deliverables can support an agile

team in a variety of ways.

So, by now you may be wondering:

How can my team/organization add UX to our Agile process?

Here are 10 best practices for doing this:(inspired by Jeff Patton’s list and my own UX work with Agile teams over the last 3+ years)

Jeff is one of the thought leaders of the emerging Agile UX community. Others in this community whose work I’d recommend checking out: Austin Govella, Anders Ramsay, Desiree Sy.I’ve borrowed Jeff’s list, which is targeted towards a UX audience, and infused it with my own experience working as a UX designer with Agile teams.

1. UX is part of the Customer/Product Owner team.Business PO, tech lead, and UX lead collaboratively establish and execute on product direction.

In canonical Agile, the Customer role is filled by a single person.But in my experience, it’s best filled by a team of 3 people: the product manager, the UX designer, and the technical lead.This is consistent with the so-called “3 in a box” model, used in companies like Oracle and Cisco, where the 3 roles all have to sign off on major product decisions. Assuming these people can trust each other and work together to guide the team, this model can lead to the Holy Grail: a successful balance between the needs of the business, the needs of the users, and technical and architectural concerns.Admittedly, this sounds a bit idealistic, but it’s a good goal to aim for.

2. Sprint/iteration 0 is your friend. Do “just enough” upfront research/design to define and communicate a solid design vision.

Sprint 0 is the time to do upfront user research, create high level scenarios, and create artifacts that communicate high level screen flow, look and feel, and user interaction patterns.Sprint 0 may be longer than a “real” sprint, but should be measured in weeks rather than months (an exception being a completely greenfield product or system).

3. Design and build in incremental layers. Break down the design vision into small pieces that can map to user stories.

When your Customer/Product Owner team is writing user stories and creating design artifacts for these stories, have them structure these in layers.This way, the development team can deliver the base layer first, and then build on that base.Have the Customer/PO team create dependency diagrams, like the example I showed earlier, when the relationships between the chunks/layers get too complex for the team to fully grasp.This will give the team a context for the current batch of user stories, and an idea for what might lie ahead.

4. The Customer/PO/UX team works 1-2 sprints ahead. This allows for advance story and design artifact creation/review without Big Design Up Front.

Jeff and a number of other Agile UX practitioners also advocate for UX designers to be simultaneously designing for sprint N+1, researching for sprint N+2, being available for the team as they work on stories in sprint N, and user testing the stories delivered in sprint N-1.

However, in my experience, this is more or less impossible for a single person to accomplish without being cloned. :)

5. Schedule complex engineering tasks first. This helps mitigate both technical and user experience risks.

- Mitigate design risks by allowing UX more time for research and validation- Allow Development to uncover potential technical risks early on

6. Build a user pipeline for continuous UX validation. Draw upon lead customers and motivated users to ensure UX always has someone to test with.

This pool of users needs to be large enough that the designer doesn't call on the same user repeatedly every week - but rather talks with them every month or two.Ideally, this pool is built up and groomed by a dedicate user researcher (who can then do this for multiple products/projects).

7. Involve the whole team in brainstorming and reviews. Solicit input from everyone, then let the Customer/PO team make the final call.

Involving the whole team keeps progress transparent and gives everyone in the team an understanding of the design, as well as an appreciation for the process and tradeoffs necessary to make the design a good one.

But, that doesn’t mean that everyone gets to make decisions. Design by committee is rarely good design.

At the end of the day, the PO is responsible for making the final call on the product, and the UX designer on the experience.

8. Use lightweight tools to document design decisions. “Just enough” is the right amount of design detail and fidelity.

Find tools that will let you capture design decisions and rationale in a lightweight way.- easy to create and maintain (for the Customer/PO team)- easy to access and understand (for the implementer team)

If your team uses an issue tracking system like JIRA, leverage it- it will fit into your team’s existing workflow, and keep them up to speed with the evolution of the design

9. Communicate early and often. When in doubt, talk to your UX designer, and make sure they do the same.

Invite your designer to all your sprint planning sessions, retrospectives, and daily stand-ups. If your designer is not co-located with your team, make sure that they have the opportunity to work on site at regular intervals, and to call into your daily stand-ups and other meetings.In other words, treat them as a full member of the team.

“Agile is built around teams. Your UX person isn’t struggling, your team is struggling. If one person fails, the entire team has failed. Your burn downs, WIP charts, bug triaging, and velocity mean f*** all if any member of your team from any discipline is struggling”. - Austin Govella

10. Expect, and encourage, commitment. Designers working with Agile teams are much more effective as “pigs” than as “chickens”.

In my work with Agile teams over the last 3.5 years, I’ve seen a lot of skepticism about commitment. Many developers perceive designers as the proverbial “chickens”, content to dispense their advice, and then, for lack of a better term, flee the coop.I’ve tried to prove this skepticism wrong and work with them, day in and day out, to make their products better.As I did, I found that developers became more willing to trust my design decisions, and my ability to make a difference in their projects increased dramatically.So, if you’re working with a designer, expect, and encourage, them to be a full member of the team - to be a “pig”.And if they are not willing to do this, find one who is!

Thank you!dmitryn.com | @dmitryn

Bibliography of Agile+UX resources: http://delicious.com/prettyusable/agile-ux

Thank you!If you’re interested in a bibliography of resources on Agile and UX, check out the link at the bottom of the slide.All photos (except those credited and my own deliverables) used courtesy of Flickr’s Creative Commons search and their respective creators.