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.
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.
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.
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.
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.
aspects of the way people use a product or service... “The User Experience Honeycomb” by Peter Morville http://semanticstudios.com/publications/semantics/000029.php
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.
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+Lax It outperformed all major stock indices... and that was before the iPhone, Android, etc.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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. :)
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
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).
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.
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
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
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! 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.
dmitryn
tooomo
muture
hrtnde
goodpatch
xxxkinu
ajstarks
chatwork_hr
kasumidyaya
ncdc
hopin
aguringo
jacobian
3n
kevinliebholz
maggiecrowley
addyosmani
cromwellryan
philnash
pauljervisheath
csswizardry
rasmusluckow
ufuk
paigeccino
