Here’s the slide I used in explaining how they’re different (I’ve added the complete deck below):

Explaining the relationship and differences between Traditional, Agile, and Lean UX

Traditional UX – it’s not like it suddenly vanished

I think it’s easy to think that just because you are adopting an Agile and/or Lean approach to your UX practice, that all the traditional UX practices and principles suddenly somehow vanish. Nothing could be further from the truth. As experience quality becomes an evermore critical factor in product success (ie. if you have 10 apps to choose from that basically all do the same thing, which one do you think people will pick?), everything that UX designers have been hemming and hawing about for eons (ahem) about usability and good design principles are as important as ever.  Good design is good design, regardless of if we are living in an Agile or Lean or [insert new term] universe. The only real difference when adopting these methods is in the How, which is what Agile and Lean UX are all about.

Agile UX – Collaboration and Delivery

Agile was created by developers for developers to solve developer problems.  As Ward Cunningham, one of the original signatories of the Agile Manifesto, once said, “Agile is hot food served quickly.” Ultimately, Agile is about high-quality high-velocity delivery of working software.  In the Agile universe, that is the ultimate measure of success.  However, a funny thing happened on the way to that Agile Manifesto.  Making great software quickly, it turns out, requires collaborating really really effectively with those pesky non-binary entities called people.  While basically silent about UX design, Agile thinking offers a fundamental paradigm shift about how to interact and communicate with your project team and beyond.

So, while there certainly is a lot that UX designers can learn from Agile thinking on software delivery (such as to automate everything that can be automated), the real pay-off for UX practitioners is in the collaboration part.  Agile UX methods, like Design Studio and Cross-Functional Pairing, help UX practitioners replace slow and heavy documents with design through direct interaction.  An Agile UX practice, in other words, allows UX designers to replace a document-centered design practice with one that is collaboration-centered.  This is a very big deal for UX designers working on Agile teams, because it is this shift that is key in allowing them to integrate their practice with Agile Developers.

Lean (Startup) UX – Measuring and Validating Product/Market Fit

Cool, so now we’ve got this great Agile machine allowing us to be crazy-efficient in shipping software.  But, um, did anyone check to see if we are shipping the right software?  A Lean UX approach shows us that shipping, which basically is the big honkin’ Done in the Agile world, is in fact really only the beginning.  While Agile methods help UX designers turn old ways of designing and communicating on their head, Lean UX helps us overturn old approaches to research and measuring quality.

In a traditional model, research is something you do before starting to create the product, to figure out what the product is that you are going to build.  In a Lean approach, we are building and gathering metrics about what we have built continuously.  The most archetypal example of this is the metrics-gathering landing page, which is created and launched at the very outset of the project, rather than soon before the “finished” product is about to be released.  We turn what was once just seen as marketing fluff into an actual experiment of our hypothesis that others will think our idea is as great as we think it is.  Then, the metrics gathered from that landing page (or it can evolve into a full-fledged metrics-gathering website) are fed back into the product design.  But a landing page is just one of any number of ways one can apply Lean UX.  Another common pattern is to create a simple prototype and GOOB!  Yes, Getting Out of the Building, out of your cozy cubicles and offices and actually taking your idea to where your users are. We are, in this model, not doing research before or after the product is made but throughout the product design and delivery process.  While in an Agile UX model, Building is Designing is Building, in a Lean UX model, Building is Research is Building, and it is easy to see how these two are very much intertwined.  Like with Agile UX, it allows for much more easily integrating research with how Agile teams work, since it is continuous and not up-front.

One more thing about Lean UX: I think it’s kinda’ confusing.  The term “Lean” has its origins in Lean Manufacturing and refers to the practice of minimizing waste and maximizing flow, which, in turn, is a cornerstone of Agile methods.  Lean UX, on the other hand, is really a reference to Lean Startup a la Eric Ries (and Steve Blank, basically the godfather of Lean Startup, and creator of concepts like Customer Development and GOOBing), which extends Agile ideas to include methods for ensuring that there in fact is a market for the product you are doing such a good job designing and shipping early and often.

Bottom line: in everyday conversation, whether one uses the term Lean or Agile or what-not is probably not important.  What’s more important is an understanding of how Agile and Lean help make traditional UX a more whole practice.

Oh, and here is the complete deck from my 10-minute opening talk at the Lean UX Roundtable Panel:

So, with that out of the way, here are the slides from my talk:

And here’s a video of my talk, courtesy of Yasunobu Wayaguchi:

Video streaming by Ustream

Enjoy!

Jared: …it feels to me sort of like an onion, in that you’re always seeming to peel things back, and at the core of it are these Agile values that really, I think, speaks a lot to what people are trying to do and why this really is something more than just a fad or just a re-branding of something we already were doing.

Anders: Yeah. So what’s interesting and maybe confusing for people who aren’t aware of the history is that even though the “Agile Manifesto” you know, was formulated in 2001, that was something that was many, many years in the making. And it’s really sort of turned upside-down, because the methodologies that people are familiar with, they actually existed before that term “Agile” was coined. And, in turn, those methods originated from what was generally referred to as lightweight software-development methods.

So I see myself as being more of an adoptee of these earlier, original elements that became the basis for Agile. And Agile is more just like a brand, a term. It’s something that we can all refer to. We can just talk about Agile. We’re referring to this kind of way of thinking about design in general and software specifically.

Check out the full podcast.

If you want to learn more about applying Agile values to UX practice, be sure to check out my upcoming UIE/Rosenfeld Media Next Step Series virtual seminar.

Be sure to check out my upcoming virtual seminar on this topic, which is a collaboration between UIE and Rosenfeld Media.

Also, be sure to sign up to get notified re. the launch of the pairingproject, an educational experiment I am conducting with Ideo and Pivotal Labs.

6. Iterate Story Development with UI Exploration

Within the everyday chaos of an average design project, part of what makes stories so valuable is their nimbleness and flexibility.  They can easily be ordered, re-ordered, and grouped in any number of ways depending on your current need, such as by category, priority, complexity, sprint, or whatever, and you can do this in a highly ad-hoc manner.  Team members can use the same card for everything from affinity diagrams to product road maps to scrum boards and on and on. But this level of flexibility also has drawbacks.

The node-like nature of Stories also means they often lack context.  In other words, while you can easily group a set of cards and say that they belong together, it is very difficult to see how they will fit together simply by looking at the cards alone. This is where UI exploration comes in.

Users participating in a design studio session

While Agile offers strong conversation-centered methods for capturing stories, UX adds to that by offering visually centered methods for contextualizing those stories, i.e. helping us uncover the order in which features should be completed, which feature should be accessible in association with other features, and more.

Here’s a quick example. Jim, the auto mechanic we talked about in part 1, has described each of the following features as being important to him:

(Note that we are not using the long format described earlier. Especially during early exploration, just have users jot down short phrases they can speak to in more detail later.)

Discussing these features with Jim, he explains that

Sometimes I want to search by part number, but sometimes its easier to just find it based on where in the engine the part is, especially for new models, though sometimes I might need to find the part based some other spec info, or all I have is an aftermarket part number.

Based on this conversation with Jim, while it is clear we have a good starting point, it is also clear that we have no idea if this list of features is the right list or a complete list until Jim is able to see them in context, i.e. in some rendering of an actual user experience.

For example, maybe we create a part number search feature with a smart auto-complete, which when Jim sees it, he realizes that a visual search is not as critical as he thought.  Or, conversely, maybe we make the visual search so easy that searching by part number falls to the wayside.

The bottom line is this: make sure UI exploration is part of story development.  For example, do some initial cardstorming with your users, but then quickly transition to a visual exploration, such as a design studio. (Will Evans recently did a great write-up on on that.) The visual exploration will also help you improve your story coverage.

Story coverage is the degree to which you in fact have all the stories that will be needed to deliver a complete product experience.  This can be very hard to see from just looking at a list of cards, but is much more likely to jump out at you when looking at or interacting with a user interface.

7. Make sure UI infrastructure stories get into the backlog

If you are using a story-based model for software development, that means that only features for which there are stories, and which have been added to a sprint backlog, will in fact get implemented.  Ok, that’s all good and well, but what does that have to do with UX?  Well, it means that simply having a feature appear in a wireframe or prototype, even if the team agrees that the feature is important and should be part of the product, does not mean that feature will get built.  There must be a story for the feature, and the feature must be added to the backlog. If not, you’ll be negating much of what makes a story-based model effective.

Now, in most cases, this is not a problem.  The force driving the creation of a set of wireframes is usually a set of stories.  Or, in other situations, you might start visually, and then generate story cards from those artifacts.

But in the midst of this, there are certain features which can easily slip through the cracks, which I like to think of as UI infrastructure stories.

Like signage in a building, some UI features are just seen as part of the infrastructure, and something customers will just expect to be there and not think to ask for.

These are your water-sewer-electricity-type features, like pagination for tables or navigation bread-crumbs. A product owner isn’t going to think to ask for this stuff, but will simply expect to see it in the product, like I am not going to ask for electrical outlets in my hotel room, but will just expect it.

The problem here is that, in a story-based model (and in some ways in the Agile model in general), if you don’t ask for it, you won’t get it. But UX design, in contrast, is very much about giving the customer what they did not think to ask for.  Therefore, as part of UI exploration, it is essential to look at the UI and compare it to the backlog and make sure that there are cards for these types of features.

Find these features in your design artifact, write a story for each of them and work with your team to get them estimated and added to the backlog.  If not, you are going to have some unpleasant surprises at the end of your sprint, and be carrying UX debt, i.e. half-baked experiences that, like credit card debt, get costlier and costlier to fix with time.

8. Be present during story estimation

A key function of user stories are to serve as an estimating and planning tool.  After stories are written, hopefully by customer and users, developers use a variety of methods (such as planning poker) to assign a cost to a story, such as in the form of story points, such that the Product Owner can decide if they want to “buy” it and place it into the backlog.

Conventionally, only developers, or those who will be doing the actual software construction, participate in estimating.  That is all good and well. (After all, something that may seem as simple as justs adding a button to the screen from a UI perspective could equal a world of work that we are not aware of under the hood.)  At the same time, it is critically important that you are present during estimation.

And I don’t just mean physically sitting there watching developers estimate (though that can be an experience in itself, if you’ve never seen an Agile estimation workshop), I mean really being present.  In other words, come prepared to an estimation session with an idea of which cards you think might involve some complex UI, and watch out for a low-ball estimation.  Make sure you educate yourself on how Agile estimation works, so that you can raise a concern if you think developers are under-estimating a feature.

A common pattern, particularly on a pragmatic Agile team, is that the estimation will be based on the simplest possible way to implement the feature.  For example, if you are implementing a form, that may mean just putting all the fields on one page as one long form.  However, that may not be the best solution from a UX perspective.  You should be present to lobby for a more costly but also more user-friendly UI, in cases where it makes sense, such as to make the product competitive. This is also why its so important to have done some UI exploration before you estimate, to have a concrete basis for your discussion. Too often I see it happen afterwards, which makes for all kinds of churn and other problems.

9. Make sure testers are testing for usability

From a tester’s vantage point, a story is something for which you create a test.  If the test passes, the story is done.  Ok, I’m oversimplifying things quite a bit here, but one thing to be aware of is that testers in many cases are not looking at or primarily focused on the user interface. Instead, they are writing code-based tests that check to see if the code written to execute the given feature passes the test or not.

A snippet from a code-based unit test, which would run as part of automated testing.

If your head is spinning from reading that, then you would be well advised to educate yourself on test-driven development.  It turns traditional QA on its head and is a powerful manifestation of Agile thinking.

Perhaps more importantly from a UX perspective, because it allows for a large percentage of testing to be automated, it can free up testers to spend time reviewing the user interface and the quality of the user experience.  This can, to a large degree, be a question of working with them to point out examples of the types of issues they should be looking for in the UI, things that might jump out at you, but may not jump out at them, such as pagination links being super-tiny or in a color that is hard to see or whatever, but also to make sure that they are looking at and comparing UI screen mockups with the real thing.

It also means looking carefully at any acceptance criteria that have been created going into the sprint, because testers will use those as a basis for determining done-ness. Another very powerful tool here is a UI style guide.  This is where you can include general display rules for the user interface, so that you don’t have to keep repeating the same issue over and over.

This will allow you to spend more time working on the design for an upcoming sprint and spend less time having to check every screen of the app at the end of every sprint and nag deveplopers (or fill out time-consuming bug reports) about a slew of small tweaks that need to be made.

10. Read Mike Cohn’s book

User Stories are a huge topic and I’ve only looked at them here from the relatively thin perspective of UX.  If you haven’t done so already, you should pick up a copy of Mike Cohn’s book, User Stories Applied.  Even though it’s been out for quite a few years now, it remains as relevant as ever.

Any tips and tricks for integrating UX and User Stories you’d like to add? Please share them in the comments! 

Users reviewing stories on a card wall

If you are a UX designer who wants to quickly get up to speed with integrating Agile and UX, there are few better places to start than with User Stories.  They are both a quintessential embodiment of Agile thinking (i.e. if you understand User Stories, you understand Agile thinking) and a potential power tool for a UX designer on an Agile team.  But like any tool, they can be highly effective, or, if you have no idea how stories work, cause some serious damage, especially to the UX dimension of your product.  So, if you’re using User Stories or thinking about adopting them as a tool, here are ten tips to help UX designers understand User Stories (we’ll just call them Stories from hereon) and wield them to both yours and the team’s benefit.

1. Know What the Story Is

Ok, first things first.  Before we can offer any advice about stories we need to understand what we’re talking about. Take a look at this and tell me what it is:

If your practice has been raised on a steady diet of document-centered design processes, i.e. work that revolves around and culminates in the creation of documents, like specifications or use cases or whatever, you can be forgiven for looking at the above card and thinking that you are looking at a story.

The card is not the (whole) story
Yes, the above definitely is a story card, but the actual story is not on the card.  This might be confusing, but bear with me here.  The statement on the card is only what one can think of as the title portion of the story. The full story is the conversation triggered by the statement on the card.  In other words, the complete story, i.e. all the excruciating details about the given feature, live in a self-maintaining, self-updating data store, namely the team’s collective memory.  Therefore, in whatever moment when someone picks up a card and has a conversation with other team members, the statement on the card triggers the most current knowledge about the feature by those team members.

The idea of storing project information in collective team memory might sound funky, but not only does it make a lot of sense—information in a modern software project is too fast-moving and volatile for document storage to be able to keep up—but collective team memory is, by its nature, always up-to-date.  All that is needed are the correct words that will trigger the appropriate memory, and resulting conversation.  And that is what goes on a story card.

If you’re still skeptical about this concept, you should know that you probably use this technique yourself on a regular basis, such as when writing a todo list. When writing a todo list you don’t write down every last detail about the thing you need to do, but only just enough so that you won’t forget to do it and, when the times comes to complete the todo item, you’ll remember all the details about what needed to be done.  Stories work the same way, except that in this case its a team-wide todo item, as well as a team-wide communication device.

Stories are a whole-team communication interface

Each team members looks upon and uses the same story from the vantage point of their particular work

When you hand the same card to a different team member, each team member will look at it from a different perspective, and use it in a different way.  In more pontificating terms, this is what is known as a boundary object.  For a user, it describes a needed or desired feature.  For a developer, it describes a feature that needs to be estimated and/or work that will need to be completed. For a UX designer, it describes a puzzle piece to be fit into a product offering (or not) to create a coherent and valuable experience.  For a tester, it describes something for which a test likely needs to be written.  And so on, for each team member.  One story; multiple perspectives.

If you understand these various perspectives and the way in which a story gets kicked around between team members, then you’ll have a good mental model of how the Agile project game is played, and where you can best position yourself on the field to move the story to the finish line.

2. Make Personas the voice of the story

In contrast to old-school requirements, which are written from the perspective of computers, i.e. “The System shall…” do this or that, Stories are written from the human perspective, e.g. I want to be able to do this or that.  This shift in perspective is a great example of how Agile is much more human-centered compared to waterfall.  But when bringing UX practice to Agile, we have an opportunity take this even further, as part of integrating Personas, by making the Persona the voice of the story.

In other words, if we do a Persona workshop in the early stages of the project, each story that is created should correspond to one or more Personas.  Let’s say our substitute teacher persona is Becky. After putting in all that work into modeling Becky, we can now leverage that in how we create and talk about our stories.  For example, we can add a Persona prefix to our story statements:

With this short prefix, we’ve both made the user feel more real, and in conversations about this story, we can talk about what Becky would want or not want, rather than what some anonymous and disembodied substitute teacher would want.

3. Have users write the stories, not you

For an advanced Agile team, this is Agile 101, but if you’re new to Agile, you may be sitting there frantically trying to write story cards while users are telling you what they want.  However, a key aspect of an Agile approach to engaging users or team members is active collaboration and creation of artifacts by the team rather than by individuals.  In the case of stories, this means that you create contexts in which users write their own cards.  There are numerous ways of doing that.  One is the Paired Interviews technique I wrote about recently. That, in turn, is a type of cardstorming activity, which more commonly is done individually, with each team member creating as many cards as they can within a short (e.g. 5-minute) timebox, followed by self-organized group chunking and prioritizing.  Additionally, the overall project infrastructure should be such that cards are available at arms-length virtually wherever you are working (e.g. place cards and markers at the center of every table, and scattered strategically throughout your team room), such that you can capture cards at the speed of conversation.

So why is it so important that the users write the stories?  One main reason is that they will then phrase the card in their own domain-specific language, and in a way that is likely to most effectively trigger the appropriate memories when you ask them about the card down the road.  And on that note, if the cards are written by hand, their handwriting can be used for card traceability, i.e. you’ll be able to know who wrote the card just by looking at it.  And if you are gathering info from many users, well, then they will be able to produce far more cards as a group than you could on your own.

4. Be sure to get your “so thats”

As you may have noticed, the above cards are written in what has become a standard structure for writing stories:

Now, while there is nothing that says you need to phrase your stories in this way (and when you are capturing new stories, you probably want to just jot down a couple keywords, and write the story in long form later), it is important to be aware of the relationship between the “so that…” part and UX.  Looking at our earlier example with our substitute teacher Becky, the “so that” reveals the Why of the story.  It reveals both the motivation behind the story and often also can reveal something about the context. However, when trying to get a lot of stories created in a short amount of time, this part is often skipped.  And that’s understandable.  However, it is important to then be sure to go back at a later point and get your “so thats.”

To understand why, let’s look at an example where the “so that” is missing.

Hmm, why would searching visually be so important?  In a later conversation with an auto mechanic, he explains:  ”I want to be able to search visually, so that I can find and visually match the part in the search results to the physical part as well as see in the search where in the engine or vehicle the part should be located, to make sure I am ordering the right part.”  Wow, the “so that” part suddenly revealed a desire for a completely custom visual search interface and a desire to be able to search while working on the car, meaning maybe searching with greasy hands and lying on your back. Seriously valuable intel.  Make sure you get those “so that’s” people!

5. Don’t confuse Story Maps with User Interface

While a story wall provides a good overview of the product, it is much harder to evaluate for completeness compared to a user interface.

Story mapping is a powerful way for managing stories and offering a big-picture view of the product.  But it is also a far more abstract view of the product compared to the corresponding user interface.  It is virtually impossible for a Product Owner or other domain expert to look at a story map and say, yup, looks like we’ve got all the stories there.  You have to actually flow through it in a user interface to see what is missing. In other words, after you’ve developed your story map and think you’ve got good story coverage, assume you’ll be uncovering a good chunk of new stories as part of designing the user interface.

Additionally, even though you may have organized your story cards into thoughtful silos that reflect the structure of your product or domain, that can easily be confused with an actual user flow, in which the reality is that users may be jumping around back and forth between your different silos, even if your silos have been organized in an order that generally matches your domain’s workflow.

Therefore, create stories maps and use them for all the reasons that they are powerful, but quickly start to generate user interface concepts based on the cards in the story map to uncover aspects of the product that stories, by themselves, often are not very good at revealing.

To be continued…

This post got to be pretty long, so I decided to break it up into two parts. Read part 2, in which I talk about other key factors UX designers should consider when working with Stories, such as story context, story coverage, and story estimation.

Here is another such manifestation, in this case applied to user research, something I call Paired Interviews.

A paired interview session, in which users interview one another

The paired interview method applies the thinking behind pair programming toward user research.  Instead of doing the more traditional one-on-one interviews with end users and domain experts, the researcher instead asks end users to interview one another, while moderating their discussion. The end result is a research findings artifact, commonly in the form of a prioritized list of story cards or a story map, created by the session participants during the session, rather than by the researcher after the session.

Why are paired interviews effective?

Paired interviews can often be a significant time-saver.  They effectively allow a single researcher to interview many users at the same time, by having users double as interviewers. Additionally,  these users will be able to ask questions using appropriate domain-specific terminology, reducing interview churn and the need for clarification.  They are also likely to be able to detect domain-specific subtleties in the interviewees responses and be able to then ask the ever-important follow-up questions.

Another possibly less obvious advantage of this model is its social impact: seeing and hearing others, who are members of the same demographic or the same organization, speak openly about the topic at hand, can encourage them to also want to add their share of insights and ideas for improvement.  Somewhat ironically, the din of noise from these multiple conversations also creates a kind of privacy bubble for each pair, helping them feel more comfortable opening up about possible frustrations with the current product.

What are some drawbacks of this technique?

The most obvious disadvantage is that you are not able to have an in-depth discussion with each user and therefore possibly missing some critical details. However, paired interviews of course do not exclude the ability to do one-on-one interviews.  Close observation of participants during a paired interview session often can be useful in helping to determine who might be worth following up with for a one-on-one interview.

Paired interviews tend to also require more preparation than a one-on-one interview, which can often happen ad-hoc, i.e. with little or no preparation.  As we will see, however, the time invested in preparing and running a paired interview session is likely to be well worth it.

Running a Paired Interview Session

Here is a super-brief overview of running a paired interview session.  Prior to running a session, you should (obviously perhaps) have familiarized yourself with the product domain and the context in which the product being designed is expected to be used.

Selecting Participants

Try to include a broad range of users. This may mean including both advanced users and those new to a possible legacy product. At the same time, you want to be sure that the pairs interviewing one another are able to relate to what the other person is saying.

Number of Participants

This session can be completed with anything from a single pair to a large group of pairs.  Many pairs is better, since participants are likely to feel less self-conscious in interviewing one another. For larger groups, consider having additional team members assist you with moderating the interviews.

Session Intro

Setting discussion boundaries is key.  If you are doing the interviewing, you are in control of that, but here you will be relying on the users themselves for this.  The project goals, which are a good idea to present, set natural outer discussion boundaries, but you can feel free to narrow it even more. For example, a project goal may be to replace an old desktop publishing system with one that is cloud-based.  Ask participants to try to keep their discussion focused on the old system and their ideas for a new one.

And don’t forget to explain the concept of paired interviews, since this is likely to be new to many of those attending.  Explain that the interviews effectively are conversations, in which both parties are interviewing one another at the same time.

Conversation starters

While many users often are eager to discuss things that frustrate them, such as their current crappy enterprise software, others may need some assistance with getting their discussions underway.  Therefore, present a set of conversation starters.  Here are some examples.

• “Describe a really bad workday you had recently.”
• “What is your least favorite feature or work activity?”
• “What is your favorite feature?  What makes it great?”
• “What would be an ideal workflow?”
• “What is the most time-consuming part of your day?”

Try to tailor these to be more specific to the project domain or context.

Pairing up

Ask participants to pair up. Allow participants to self-organize, i.e. to determine who they would like to interview and be interviewed by.  Forcing someone to pair up with someone else may backfire, since you may put two people together who do not get along.  If you are left with an odd number of participants, such as due to a no-show, ask that one person to join one of the pairs, and have a three-way conversation.

Capture conversation with cards

Provide participants with markers and sticky notes.  Ask each participant to jot down a few word capturing each key point made by the person they are interviewing.  Some participants may be new to this way of taking notes, so consider providing some examples.

For example, if the person you are interviewing says: “Sometimes I am in the middle of filling out a form and have to go ask someone a question, and then when I come back, there is a message that my session has ended, and all my form data is lost.  Super frustrating!”

…jot down something like: “Session time-out, form data lost!”

The key here is to jot down just enough that it will be possible to trigger a more detailed conversation about the topic at a later point.  Explain that this approach both allows for taking notes in real-time, and allows both the interviewer and interviewee to see what notes are being taken.  That way, if the person being interviewed says something they feel is a key point, but the interviewer does not make a note of it, they can see this, and ask them to add a new sticky note.

The Interview Timebox

Start a 5-minute timebox.  This will usually trigger an immediate flow of conversation and sticky notes.  Try providing pairs that seem to be struggling with some personal attention. Keep a close eye on the cards being produced by each pair.  If there are pairs with few or no cards in front of one person, check with them to see that both parties have had a chance to interview the other.

At the conclusion of the interview timebox, ask for a show of hands of those who feel they were not able to share everything they would like to.  For those pairs who raise their hands, give them another few minutes to finish their discussion, while others get started with developing and organizing research findings.

Interview Summary

Go around the room and ask the interviewer in each group to use the sticky notes to summarize the conversation.  The reason for asking the interviewer and not the interviewee to do the talking is to allow for capturing both the original discussion and the interviewer’s opinion and possible disagreement. Be sure to note anything they are saying that is pertinent but not on the card.

Iterating

At the end of the summary, ask participants if they would like to complete another round.  You are likely to find that there is value in completing 2-3 rounds.  It is better to err on the side of doing too few rounds here, as you will have plenty of raw material to work with even from a single round.  You also want to make sure you leave at least 20 minutes to half an hour for mapping and normalization.

Mapping and Normalization

Ask each pair to group their cards by category and relative importance. Ask pairs who are reasonably far along in organizing their stickies to move them to a whiteboard or wall. (You can use painter’s tape to create silos for each major area.) Observe this activity very closely.  As you see pairs starting to create categories, look for common categories or workflow steps across pairs.

You will most likely see self-organizing behavior here, such as those with stickies containing the same information placed next to or on top of one another.  If there is disagreement regarding the organization, ask those in disagreement to see if they can resolve their differences or, if not, create their own proposed versions.  Because the discussion is revolving around a constrained topic area or domain, you are virtually guaranteed to see similar headings.  If you don’t, this may mean that there is a larger issue, such as an organization where there is a complete lack of structure and everyone is working in an ad-hoc fashion.

You have here created the beginnings of a story map.

Cross-Pollination

Once all stickies have been added, ask participants to switch pairing partners and walk the map in pairs.  Since they are now seeing not only their own sticky notes, but also those created by other pairs, as well as being in a conversation with a different participant, this may elicit additional sticky notes.

The Resulting Research Findings

The resulting artifact will be a normalized, prioritized, and categorized collection of feature cards created by your users.  It usually is a strong indication of the needs, desires, and preference of the larger user community. The findings have many possible uses, such as to serve as the basis for a design studio, for developing a product road map, for validating or adjusting a product vision.

The sound quality is a bit iffy in the beginning (due to me waving my hands around and forgetting that one of them is holding the microphone), but get past that and there are a few good nuggets for anyone who wants to better understand how UX and coding are two dimensions of the same thing.

(http://confreaks.net/videos/46-agileroots2010-agile-ux-for-developers-or-why-fluff-is-stuff-too)

Enjoy!

The survey was conducted between Oct. 16-24, 2010. We received 150 responses. We are still churning through the findings but I wanted to post some initial findings I thought were of interest. I am still working on a more detailed analysis of the data. If you have experience wrangling Excel (e.g. doing PivotTables) and doing survey analysis, pls do get in touch.

Survey Overview

• Total Participants: 150.
• 80 participants identified as being primarily UX Designers.
• Survey Goals:
  • To understand the level of success in integrating Agile and UX disciplines, and the reasons for the success or failure.
  • To establish a benchmark for future surveys.
• 18% described themselves as very successful
• 45% as somewhat successful.
• Only 5% described themselves as very unsuccessful.
• The written responses at the end provide some insights as to the reasons behind the success or lack thereof.
• We received a lot of suggestions for how future surveys could be improved, such as to focus less on web design, focus less on user interface design, or on UX as a role.

Findings in a Nutshell: Same as it Ever Was

The challenges with integrating Agile and UX are not too different from the obstacles one might encounter when integrating a traditional UX practice into a waterfall methodology. Any form of change will meet resistance, logic and reasoning be damned. I remember years ago having to fight tooth and nail to convince management of the value of doing user research and creating detailed wireframes and specifications. The digital world has changed significantly since then, with detailed specs being far less-cost-effective. But resistance to change is the same as it ever was. And integration of Agile and UX is no exception.

Among the reasons for failure, it was therefore not surprising to see cultural resistance at every level (organization, team, peers) as being the strongest pattern. Another major pattern appeared to be going through the motions of change (e.g. doing something for two weeks and calling it a sprint or stand up during meetings and calling it a Standup), but missing the critical underlying Agile thinking, also seemed a strong pattern among those who described themselves as not succeeding.

Not being co-located, i.e. being in the same physical space as other team members seemed to also be a major factor. At the same time, some replied that they were successful despite being physically separated, because they were in regular contact virtually. Another interesting stated reason for failure was that Agile developers seemed to not regard the UX design role or discipline as valuable or important. Remember, it is not just UX designers who are part of this change; the attitudes of developers and the team as a whole is an equally critical factor.

Among the reasons for success, they also seemed to be factors that would make any team successful, regardless of if they are adopting Agile or something else. Many respondents described team empowerment and autonomy as a major factor, i.e. teams that are able to decide how they want to work together and create their own process as they go. Another major pattern was developers seeing the value in UX, or the UX role straddling the developer-designer divide (e.g. a UX designer who also is a front-end dev) were a strong pattern among those who described themselves as successful.

These responses re. the reasons for success seemed to capture the essence of what many were saying:

“For our teams, the UX designer is a dedicated team member – reporting to their product teams. Complete integration with a development team creates a much more successful team dynamic, shared ownership, opportunities for learning and growth, etc, in comparison to having UX as an external team/department.

We have also abandoned the idea that you always should design a sprint ahead, always use certain design methods, etc… Over the years, we’ve learned that there’s not “one right way” to do design & development. Some problems need the extra time to experiment and iterate and others don’t. Some designs need prototypes first, some can be iterated on in tandem with development. We’ve become far more flexible in our approach and techniques, over the years. We learn as we go.” — Alan Dennis

“Everyone talks about how important it is to keep the UX design ahead of the development sprints. I’ve found that this often means that the UX designer is the first to encounter tricky architectural issues. So one thing I’ve learned is that the entire team needs participate in the evolution of the UX design for a given feature or new area. This means that the development team must devote some % of their hours in a given sprint toward reviewing UX design for a future sprint and you have to factor this into the schedules. But if done right, both the UE and any important architectural coding issues are well understood before the story is picked up for implementation. Doing so can help avoid unexpected surprises that cause churn in the UI, features or schedule.” — Robin Silberling

“The UX designer and the Web Develper are part of the sprint planning and we sit next to the back-end Developers. The back-end Developers are very interested in watching the videos of the usability tests. Also they find the wireframes and Agile Acceptance Tests usuful when coding up the windows. We have had quick meetings with the UX designer, Web Developer and the back-end Developer to clarify what needs to be completed before coding starts. All developers are encourage to ask questions and give feedback on the wireframes or any part of the design/coding process. Before introducing the Agile Accpetance Tests the Developers were asked what they thought and if they had any feedback.” — Anonymous

Looking at the Numbers

A key focus here is on activities and process. We–rightly so, in hindsight–got a lot of feedback that we were too process-focused with this survey and were looking at UX as a separate person rather than a literacy. We’ll be working to correct that in future surveys. With that in mind, these were some findings relating to how UX is integrated into Agile teams.

UX-Designer Co-Located with Developers
Nearly 50% of respondents said that the UX designer is co-located with developers all the time. Once we start filtering findings, we’ll check this against those which identified as finding their agile adoption a success.

UX-Designer Doing Front-End Development
50% of respondents identified the UX designer as either regularly (20%) or occasionally (30%) also doing front-end development. Cross-disciplinary roles, i.e. team members wearing many hats is a strong indicator of successful/healthy team (see written responses below.)

Designing Using the Production Technology
45% said they regularly design directly in the browser and only 14% said they had no idea what that meant. If a team is designing in the browser, this is a strong indication that they have a tight integration between UX and dev practices.

The Last Artifact Created Before Development Begins
Detailed wireframes and functional specs continue to hold the lead, with 43% using this as what is the basis for initial development work, with hi-fi prototypes a close second at 33% percent. Only 15% go directly from sketches and whiteboarding to development. This is an area where there still is a lot of room for improvement. In my experience, UX designers continue to struggle with letting go of the deliverables mentality, the idea of UX being one of creating pretty-looking design artifacts before starting to create software.

When Does Detailed Design Work Occur Relative to Development?
Only 8% complete all detailed design work before any development work begins. 50% complete a majority before development. 35% are doing detailed design work in tandem with development. Here again, there is plenty of room for improvement. The idea of not designing everything in atomic detail before starting to build can seem scary to a traditional UX designer. There are probably also a lot of business/org culture/peer pressure factors here that will drive UX practitioners to feel compelled to create all this detailed design up-front.

More Written Responses

Reasons for Success

“UX designer is respected, full member of the team”

“We’re somewhat successful because I think previously we were working with high-fidelity mockups that made it hard to iterate in tandem with developers and design and implement an UX in an iteration or two. We’re now more focused on paper prototyping to give developers the guidance they need around implementing functionality, and designing more directly within the browser within the current iteration. This has been working better, but I think it’s taken a long time to get the hang of UX tools and methods that match the speed of development and iterative methods.”

“We explored the potential of every person & helped other person learn something new. In short we recognized the capability of the team. Made sure who the actual owner of the Story is & made others contribute in the mix. In short, we empowered the team to make decision & requested management solve the impediments & stay out of teams face.”

“The Tech lead is a huge supporter of UX and understands the value. And, if he ‘forgets’ about me at times, he does what needs to be done to get me integrated back in the dev cycle.”

“…the UX desinger has always been considered part of the team. I used to be a FE dev so understand the complexities. Am also a ScrumMaster and attended the training with the developers. Started from the same point. This means I’ve always had very good relationships & high levels of trust with the devs. Always get dev feedback on feasibility and we can all be part of the process.”

“Even though we’re geographically dispersed, we are constantly in touch via an ever-present group skype chat.”

Reasons for Lack of Success

“We have off-shore team, hence bringing them up-to-speed & style is getting challenging. Team here in US still has the mentality that US team is the best.”

“Too many executive stakeholders who don’t understand the value of agile methods. UX team (our client) still focused on producing deliverables rather than working code (site maps, content inventories, requirements, specs)”

“The organization started pure agile and is struggling to integrate ux”

“My organization still views agile and ux as diametrically opposed interests. They still view ux as an upfront activity. My local project teams have a changing view because of their experience working with me, and I hope that view spreads throughout the organization.”

“Front end developers requiring more design detail thus pushing more work onto design.”

http://webtorque.org/?p=1060

“We don’t involve users. We create interfaces that are very flashy, but not terribly useful to the user.”

“The lack of co-location and general “design” think is the biggest barrier.”