The UX of User Stories, Part 1

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:

As a substitute teacher, I want to view a list of all students in my course, so that I can call on them by name.

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

Stories are a communication interface between team members

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 to 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:

Becky says:
As a substitute teacher, I want to view a list of all students in my course, so that I can call on them by name.

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:

As a [user role]…I want to [be able to do something]…so that [it will provide value in this way].

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.

As an auto mechanic, I wants to be able to search auto parts visually.

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

Team reviewing a story wall for story completeness

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

Paired Interviews – applying pair programming thinking to user research

As I’ve said before, Agile is not a specific methodology or set of practices; it is a way of thinking about creating software products.  If you are a UX designer, once you understand and are able to adopt an Agile mindset, you’ll be able to reshape your practice, such that it takes full advantage of Agile thinking. Manifestations of this include replacing slow-to-create detailed specification documents with fast and light-weight conversation-centered design documents.

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

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.


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.


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.

Agile UX For Developers (or why fluff is stuff too)

So I’m tooling around the web and come across this video of a workshop I did at Agile Roots 2010. The main audience for the workshop is Agile developers, and it seeks to convey how the UX practice is a different dimension of work, separate yet inseparable from software development, yet equally critically to the success of the overall product.

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.



Findings from the State of Agile UX Survey

Together with members of the Agile Experience Design LinkedIn group, I created a survey on the State of Agile UX. The overarching goal of this survey was to begin to understand what is and what is not working when it comes to adoption of Agile among UX designers. The survey was inspired by Version One’s annual State of Agile survey, which have been surveying Agile adoption since 2004(?). Similarly, we wanted to establish a benchmark for what is likely to be an adoption that will continue (and evolve) over the years.

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

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

Designing Ahead: The Good, The Bad, and The Ugly

In my previous post, I talked about how starting to build earlier has a cascading and transformative impact on the UX practice. One big change change driven by starting to build earlier is that of condensing up-front design work down to Just Enough. In other words, we go from doing a lot of analyzing and creating a lot of documents, sometimes for months, to committing to start delivering some kernel of the real product within weeks of project inception.

Once some kernel of the working product has been built, there is a fundamental shift in the working relationship between design and development. We move from the traditional assembly line hand-off model to something more akin to a theater production, where we are in a continual state of iterating on something real, from reading the script to acting it out in some rehearsal space, to adding set design, costume, and so forth. We are designing by doing rather than designing by describing. This is a concept Robert Austin and Lee Devin describe in wonderful detail in Artful Making, a must-read for anyone interested in elevating their Agile UX chops.

But alas, designing the product while developers are building the product is alien territory for many traditional designers. A UX designer indoctrinated into a traditional approach to UX design, with lots of pre-development design work, lots of exploration and iteration away from those who will actually be building the product, is unlikely to be prepared for the type of transformation of their practice that this change will bring about.

Without an Agile mindset, without an understanding of what it means to iterate not just design in isolation from development, but to instead iterate design with development, which is what we really are talking about here, you are almost certain to suffer some form of dysfunction, such as this horror story relayed to me a while back by a UX colleague:

This whole designing ahead thing is driving me crazy. I’m supposed to have detailed designs ready for the next sprint, which starts in a few days, but I can’t get the developers to stop coding and spend some time whiteboarding the UI, because they’re heads down finishing the current sprint and want to match or beat their velocity from the previous sprint. So now, the same thing that happened last sprint will happen this sprint: the developers build what I give them, which ends up being only half-baked in terms of UX because we didn’t really collaborate on it and because I had to rush my work to not fall behind, and yet they call it Done because they built everything I put in the wireframes. I can’t keep up. I’m just one UX Designer and they’re a whole team of developers. Man, I miss the good old waterfall days…

Does this sound familiar? The lone UX’er having to crank out wireframes to keep the dev team busy, with the resulting product perhaps being impeccable at the code level, but half-assed at the experience level? This phenomenon, sometimes referred to as “Feeding the Beast,” is what I think of as the dark side of Designing Ahead, which has become a relatively standard pattern among teams integrating Agile and UX.

The dysfunctional Feeding the Beast phenomenon occurring when waterfall thinking is applied to Designing Ahead.

The idea of designing ahead one or more iterations, of working on the UX for iteration 6 while developers are working on iteration 5, has emerged as a common practice in Agile UX circles. One of the originators of this pattern are Desirée Sy and Lynn Miller and this now-somewhat-famous paper they wrote. Don’t get me wrong: the issue is not with Designing Ahead per se. Desirée and Lynn and the folks at AutoDesk have applied this approach and been very successful.

The issue is with applying the pattern with a waterfall mindset rather than with an Agile mindset, which is what leads to much of the dysfunction. Top-most among them, in my experience, is thinking that designing ahead means designing alone.

Don’t Confuse Designing Ahead with Designing Separately

This is a great example of a waterfall mindset sneaking into an Agile approach. Just because there is a need to do some UX design ahead of the iteration work doesn’t mean you should be doing that design separately and away from other team members. So, let’s be very clear:

It is not the UX designer who should be designing ahead. It is the team that should be designing ahead

“But wait a second,” I can already hear a UX designer asking, “how can the whole team be designing ahead if the developer-part of the team is busy building for the current iteration? How can they be doing two things at once?” The problem with this question is one of misunderstanding what type of work is (or should be) done during an iteration. It makes the assumption that project iterations are discrete units of work with no overlap from one to the other.

As Mike Cohn explains in Succeeding with Agile, iteration work should include not just delivering value by the end of that iteration, but should also include planning and preparing for the next iteration, to ensure that it too is able to deliver value. And that preparation should include UX Design.

Bake UX Design into the Planning and Preparation for the Next Iteration

This means that the team should be committed not just to building for the current iteration but also designing for the next one. Certainly, the UX designer may be spending more time than the developers on this, but the developers are continually and actively engaged, reviewing mockups, providing feedback, showing the UX designer what they currently are building, to allow that to inform the design work being done for the next iteration.

Remember, adopting an Agile UX approach requires transformation not just on the part of UX designers, but also on the part of developers. That means that developers who may have been of the mindset of focusing on code quality and velocity will need to broaden their thinking to include product quality, where user experience plays an evermore central role.

Another common problem is that of trying to have a “finished” UI design by the time the iteration begins.

Design at the Right Level of Detail at the Right Time

Don’t try to figure out every last detail in the preceding iteration. Get the big conceptual ideas figured out, such as the user flow or any unusual UI patterns, etc., but save atomic-level design for the actual build iteration. For example, let’s say you’re designing a domain-specific registration process. For the screens that deal with the unusual domain-specific stuff you may go into a lot of detail, while for generic registration stuff, like “address” or “payment info,” you’d only define it roughly. Then, during the iteration, you may actually sit with the front-end developer and work on the detailed stuff, such as error messages and character allowance for form fields.

In Fact, Strive to Make Designing Ahead the Exception

In my opinion, the goal should always be to complete the UX design of what you are building in the same iteration that you are building it in and then move the design work to an earlier iteration only if needed, in which you have virtually eliminated hand-offs and document waste. Yes, it will in many cases not be possible, but it is the mindset that matters here, to be thinking of that as the ideal state. There are two factors, in my opinion, which will require the team to forego that ideal: 1) Inexperience collaborating and 2) A high degree of design innovation.

Reason 1 to Design Ahead: Inexperience Collaborating

The idea of integrating design work with development work is, as I mentioned earlier, uncharted territory not just for traditional UX designers, but also for many Agile developers, who often are used to doing all the design work on their own, or just being handed some UI mockups to build from. This means that Designing Ahead requires teams that are highly adept at collaborating, teams that, for example, understand how to use light-weight rapid communication methods. If you’re new to this form of intensive collaboration, getting to that point will require a few training rounds and some good coaching.

Reason 2 to Design Ahead: A High Degree of Innovation

The more innovative the design work, the more groundbreaking or otherwise unusual it is, the more time you will likely need for upfront exploration. On the one hand, be mindful of the high level of risk attached to pursuing a highly unusual and non-standard user interface. At the same time, innovation is part of the UX game. Try to treat the innovation work like a UX spike, i.e. a short and intensive exploration. Just don’t turn it into an excuse for doing weeks or more of mockups and sketches. The goal should always be to find the shortest path to start to confront your ideas with something real.

Agile UX and The One Change That Changes Everything

In my previous post, I talked about how shifting your UX practice to an Agile approach first and foremost requires a change in attitude.  But changing your attitude can be much easier if you have a clear and concrete goal you are working toward. And one of the most common challenges I come across when talking to UX designers transitioning to Agile is that they do not have a clear understanding of the journey. It is not clear what is different and what remains the same.  It is not clear where to begin in making a change.

So let’s simplify things.  Let’s reduce your Agile adoption down to one change, a single clear goal, the one change that—in terms of process—lies at the very center of everything else that changes when going from a traditional approach to an Agile approach…

Start Building Earlier

If you are not starting to build earlier, then you are probably not practicing Agile.  At the same time, earlier is a relative concept. So, within whatever circumstances you find yourself, look for the shortest path to start delivering real working software.  Commit to start delivering a working product at the earliest responsible moment.

In other words, go from this…

a highly simplified version of a waterfall approach, in which virtually all design work is done before building, to this…

Step-ladder model of an Agile UX Lifecycle

…what I like to call a Step-Ladder model of an Agile UX lifecycle, in which we do Just Enough design up front and then iterate on the design in parallel with development. (The parallel design portion, btw, has become a relatively established pattern; our focus is on when that pattern begins in the project lifecycle.)

Yes, adopting Agile is about much more than this one change, but particularly from a UX vantage point, this shift has a cascading and transformative impact.  I like to think of it as The One Change that Changes Everything.  Why? Because virtually all other changes that occur in the UX practice when adopting an Agile approach flow out of this one change.

The first and probably most fundamental change to flow out of starting to build earlier is that of chopping your up-front design phase down to a fraction of what it might be in a traditional model to allow for establishing a foundation of working software, and then evolving the rest of the product on top of that foundation.  In other words, we go from Big Design Up Front to Just Enough Design Up Front. So how do we do that?

There are two key changes to focus on here: Rapid and Rich Communication, and Just-In-Time Detail.

Rapid and Rich Communication

Perhaps the greatest weakness of a traditional UX model is the slow pace at which ideas and concepts are communicated.  While the What—design concepts and principles—may be as sound as ever—the problem is in the How—the methods used to evolve and communicate them.

The time it takes to create a conventional design document, be it a functional specification, or a set of use cases, or deck of wireframes or whatever, is usually measured in days or weeks, or sometimes even months. That means there is less time in the overall project lifecycle for development, which in a software context really just is a continuation of design exploration. More importantly, it means that there is less overlap and iteration between creating design artifacts and exploring them in code, which in turn degrades overall product quality.

There are two main reasons why traditional UX artifacts are soooo slow to create.

  1. They are created using a document-centered engineering-like model, in which it is assumed that the document will be the primary conveyor of information.  That works well for domains with greater design stability, such as bridge-building, but is incredibly wasteful for domains with a high level of design volatility, such as software.
  2. They are created mostly in solitude, meaning that there is a built-in time delay between the point of design creation and design vetting with other team members.  Spending so much time separated from other team members also perpetuates the Us/Them mentality, which makes being a UX designer less rewarding and makes it harder to integrate UX into what other team members do.

In an Agile model, communication is rapid and rich. This can be achieved with conversation-centered documents and collaborative design.

Conversation-Centered Documents

In contrast to Waterfall time, Agile time is mostly measured in hours and minutes. Agile documents are conversation-centered. We use artifacts such as post-its and whiteboards that are able to cope with the highly volatile nature of information in the software domain.  Documents quickly grow stale, especially in a software project; conversations are always up-to-date.  Documents therefore exist primarily to support discussions between team members, which are expected to be the primary conveyors of information.

In this context, documents serve two main functions:

  1. The Conversation Placeholder: An example of this is a story card.  It is a placeholder for a future conversation between team members. One can think of the story as the title for that conversation. It contains only a barely sufficient amount of information for that conversation to take place.  Often, the details, the actual story, may change over time, but the title does not need to change.
  2. The Conversation Supporter: An example of this is a diagram, sketch, wireframe, or prototype.  It is intended to support a conversation happening now. For example, it could be used by a User Experience designer and a front-end developer pairing on a detailed design.  It exists to convey information that would be challenging to convey with a conversation alone.  By using rapid communication artifacts, such as physical sketches, the conversation supporter can often be updated during the conversation.

Collaborative Design

Sure, everyone needs a bit of alone time on occasion, but in an Agile model we strive to create design artifacts as a team during team meetings, or strive to do detailed design in pairs. This eliminates the lag time that occurs when one person designs something and then has to meet with another person to review it and so forth.  This is why pairing is so powerful, because you are in a continaul state of both exchanging and vetting one another’s ideas.  And if you are doing cross-functional pairing, then you are also doing that across disciplinary dimensions.

This approach allows for creating Just Enough detailed design at the outset.  With several team members present during the actual design work, the team can then also establish when the design has reached a point where it is more cost-effective to start building (and in effect design through exploration) rather than continue designing by describing, i.e. with documents.  With a Rapid and Rich approach, your communication will be faster and higher quality.

Just-in-Time Detail

Another key reason why the up-front work takes so long in a traditional model is because there is this idea that every design detail has to be defined before any part of the application can be built.  But the reality is that you only need a Big Picture design and a Kernel design.

Big Picture Design

A big picture design is any set of artifacts that allows the team to understand what the major areas or units are of the application. From the vantage of pointing of starting to deliver a product at the earliest responsible moment, the key factors to understand are which application units are the most essential to the product and which are most complex or unusual.

A Story Wall (i.e. a collection of story cards organized to visually represent the major areas of the application and maybe also across other dimensions such as priority level or complexity) is a powerful method for representing the Big Picture, but a basic site map with some annotations may also work.

Sometimes you have to get into the details to understand the big picture, so you are likely to also need some other artifacts to understand essentialness and complexity, such as UI sketches or a prototype.  The specific artifacts you produce is up to you and your team; what matters is that you only produce the minimum artifacts needed to understand the Big Picture.  That understanding, in turn, will allow you to focus on the Kernel Design for your initial release.

Kernel Design

Let’s say you’re designing an auto parts ordering system.  Based on your big picture design work, you determine that the most essential component of the application is the ability to place an order.  That is your kernel.  Without that feature, there is no product.  Therefore, that is what you will focus on to design in detail for the first release.

Now, uncovering the product kernel is not always easy.  Often, you’ll have clients who say that everything is essential.  In those instances, it can be effective to use an Innovation Game, such as Product Box and Buy a Feature, which helps the client envision the end product and forces them to make tough choices and uncover what really is important. In other instances, the choice may be to select the most complex or unusual set of features, to allow for uncovering the unknown or unexpected as early as possible.

Regardless, the kernel must be a complete and coherent feature set that represents some essential product capability. (There are exceptions to this, such as for teams completely new to Agile, who, taking a page from the Cockburn Crystal approach, may want to start their first iteration with a simple set of functionality that allows the team to go through the motions of working this way and boost team morale and confidence.)

While there are several activities I haven’t touched on here which one would likely also need to include in a pre-building phase, such as Domain and User Research, the same principles apply.  Leverage rapid communication tools to communicate with team members and research participants (e.g. SMEs), do only a barely sufficient amount of research, and remain singularly focused on beginning the work of delivering the working product.

In a future post, I’ll talk about how the One Change That Changes Everything also cascades into the software delivery phase, in which the UX practice is transformed by entering what effectively is alien territory for a traditional UX designer: working not ahead of but in tandem with developers.

Why Agile UX is Meaningless without an Agile Attitude

Imagine yourself walking down a fictional hall in a fictional office building and passing two different offices.  In the first office sits a UX designer, busily plugging away at a deck of wireframes, preparing to review them with the rest of the team.  In the second office sits another UX designer, also busily plugging away at a deck of wireframes, preparing to review them with the rest of the team. At the surface level, these practitioners appear identical.  And yet, they are worlds apart. Me as my former traditional designer self and my present Agile designer self.
The first designer, as he is working on his wireframes, thinks of them as a clear representation of the user experiene layer of the final product.  He is expecting to present them to the development team and then for the development team to build the UX layer, mostly according to the design, perhaps with a few minor tweaks down the road.

The second designer thinks of his wireframes merely as a starting point for the design of the actual product.  He sees them more as sketches rather than specifications.  If developers were to respond simply with a “looks good” to his work, he would be worried indeed. He intentionally only a spent a minimum of time working away from the rest of the team, quickly generating a few UI concepts, and is now expecting to collaborate with the team to evolve them.

These two designers represent the essence of what sets a traditional waterfall approach apart from an Agile approach.  If you think being Agile is about doing daily Scrums and Standups and doing Story Mapping and Retrospectives, think again. They are nothing more than tools. Going through the motions of these activities without understanding the thinking behind them is like speaking a language without knowing what the words mean.

No, the true power of Agile is not knowing Agile activities inside and out or being able to recite the Agile Manifesto by heart. The true power is in understanding the underlying thinking, the attitude toward software that fueled their creation. And at the end of the day, as Jim Highsmith and others have said, Agile is no more than an attitude, a mindset. In fact, you are likely to find greater success when starting out with Agile by ignoring the well-known Agile activities and principles and to continue working the way you currently work, and focusing instead on only one change: your attitude.  That shift, in turn, will drive change from within your current practice, rather than attempt to impose it from the outside with some activities you read about in a book.

So how can one develop an Agile attitude?

First, let’s be very clear, changing your attitude when it comes to adopting Agile is about changing your habits, changing your mindset, changing what you see as a Normal way of working.  And that is unlikely to happen overnight. In fact, that first designer at the beginning of this post is me about ten years ago and the second designer is me today.  Now, that’s not to say it will take a decade to change your attitude. In fact, among the many changes, here is one central change that I made and which worked for me.  More importantly, it is something you can start to put into place now

Stop Designing Alone

For a number of reasons, many UX designers are strongly conditioned to design alone.  This unfortunate yet common pattern is perhaps the single greatest obstacle in allowing for developing an Agile attitude.  Among its many detriments is that it perpetuates an Us/Them mindset and that it makes ritual-free rapid communication, a cornerstone of Agile, nearly impossible.

A common working-alone pattern is to first gather information from team members and stakeholders, and maybe do a bit of whiteboarding with the team, and then go off and create the “real” design in your cubicle with your headphones on.

Designing is a process of making innumerable micro-choices, and as software systems become more complex, each choice needs to be looked at from multiple dimensions.  When you are working alone with your headphones on, you are making one-dimensional decisions: yours. Perhaps you spent hours and hours designing a custom UI solution, only to learn that an off-the-shelf solution already exists. Perhaps you made some technological assumptions about what is and is not technially possible, only to learn that something you assumed not possible in fact is possible or vice versa.

Yes, focusing on a problem alone can have value, but usually only in brief spurts.  Hours and hours of alone time is almost guaranteed to equal an increasing percentage of waste. So how do we stop designing alone and start designing together?  Two inter-related patterns for addressing this are Cross-Functional Pairing, which I’ve talked about before (and others have as well), and Active Collaboration.

Collaborate Actively, Not Passively

How many times have you presented a UI concept to team members, in which they are all sitting around a conference table, leaning back in their chairs, occasionally nodding in acknowledgment of your ideas? How many times have you then had them much later raise an issue about the UI that you in fact had discussed during that meeting? Why does that happen?  A huge reason is because they are only passively engaged, which in turn is largely caused by how teams traditionally collaborate, through stale old (and as 37 Signals would put it “toxic) meetings. The attitude is that you were off alone designing this thing, so its your design, not theirs, and now they are taking a passive audience stance, only half-listening, only half-participating.  If you want true participation, you need active collaboration.  And that can be powerfully enabled by implementing a few ground rules:

  • Stop talking about meetings and start talking about workshops.
  • Commit to delivering the real high-level design concept during the meeting. This means actually creating the real design documents as a team, not having you create it afterwards.
  • Commit to creating living documents, i.e. those that everyone can see and participate in creating.
  • Commit to doing detailed design in pairs, not individually.

This will be hard at first for traditional teams, but stick with it.  A fundamental shift will be in the types of artifacts you produce.  You will go from creating document-centered artifacts (i.e. those in which the document is expected to contain the primary information) which are time-consuming and anti-agile, to conversation-centered artifacts (i.e. those in which documents are designed only to support conversations, which are the primary conveyors of information), which can be created and updated in the moment. Over time, you’ll start to see a change in how your team works together, and a change in attitude, toward one another and toward the design of the software as a whole.

Agile and UX Coaching

It seems to be increasingly commonplace for there to be a shortage of senior level UX designers, so the ability to extend fewer of them across more teams is likely of great interest and potential value to many organizations. This is an emergent pattern in Agile UX circles for achieving this.

UX Coaching visual

More UX in early iterations, more Dev in later iterations

One of the more common challenges in integrating UX work into an Agile team is the push-and-pull between the good Agile practice of having knowledge and expertise distributed across team members and the desire to have a genius designer just come up with a strong design concept and hand it off to the team, so that the team can quickly get started building.

The latter model seems nice in the short term, but leads to all kinds of problems in the longer term.  When developers simply are handed something to build, something they were not part of designing, they are likely to care less about the quality of the experience, since they have a decreased sense of ownership of the work.

And, because they are less likely to understand the thinking behind the overall concept, i.e. why a certain design choice was made, they will be less able to extrapolate it into the atomic-level details they are working on, many of which the overall concept inevitably did not account for.  In short, not having the team actively participate in developing the overall user experience vision will lead to a lower quality product.

Group of people sketching (and I think the person in the foreground is Johanna Kollmann)

@johannakoll sketching, photo by Paul Kelly

Teams I have met and worked with are usually eager to participate and own the UX design, but often just need a bit of high-level guidance.  What should be the overall user flow? In what way should pages for anonymous users be different from those for users who are signed in? What are some key considerations in designing the navigation? In designing forms? Etc.

The UX Coaching model has emerged as a strong pattern which provides a best-of-both-worlds solution to this challenge.  Here, the UX expert acts as a kind of consultant to the team, providing guidance while ensuring that the team is actively participating in the development of the overall vision. Team members are not just reviewing and providing feedback on the design, but are in fact the designers of the user experience.

In this model, the UX Coach plays two main roles:

  • Visioning: At the outset of the project, the UX Coach helps the team develop a user experience strategy and vision that best supports the overall business need.
  • Office Hours: During development iterations, the UX Coach is available during regular “UX Office Hours,” which become part of the project rhythm, to provide the team with feedback on their design concepts, to ensure that it remains consistent with the overall vision and in line with the latest UX best practices.

UX Visioning

The specific activities that would be part of developing the experience vision will be unique to each project.  Some examples include a Product Box activity and a Design Studio activity.  Additionally, it will involve some user research, such as a contextual inquiry, user interviews or whatever makes sense for the current situation.  As with the design work itself, the UX Coach would lead the team in how to do this work, but the team is responsible for doing it; they will be the ones observing and interacting with users.  Here, the UX Coach does not present design concepts to stakeholders; team members do.  The UX Coach does not produce sketches or wireframes or prototypes; the team does. (Yes, they may provide training and guidance regarding the mechanics of creating these forms of artifacts, but they are not producing the actual project artifacts.)

At the conclusion of the visioning phase, which ideally should last no more than three weeks, every team member should have a clear vision of what the product is, why the product is being created, and what the current vision is for what the user experience of the released product will be.

UX Office Hours

With the team now having a clear sense of direction of the user experience, they can begin to simultaneously design and develop the detailed solution. During early iterations, teams are likely to spend a greater part of their time doing design work compared to actual development work.  Some developers are likely to feel that they are wasting time on doing user interface design and that it will look bad on their burnup chart. It will be the job of the UX Coach, in collaboration with a ScrumMaster or equivalent team role, to manage this.

Teams need to take a step back and realize that, while short-term velocity may be lower, the overall project velocity is likely to be higher, since iterating between sketching/wireframing and building can happen more fluidly with the same group participating in both of these activities.

As the product begins to take shape, the product itself can more and more become a reference point in the design, with an increasingly smaller part of iterations needing to be devoted to design, allowing for velocity to increase. (E.g.  a developer can build a new page template using an existing template but only add one or two new blocks of functionality)  This approach can powerfully mitigate the whole “feeding the beast” phenomenon that emerges when UX designers are expected to be creating entire solutions an iteration or so ahead of designers, which really is nothing more than doing waterfall inside of Agile.

These are some key advantages of this model:

Allows a small number of UX specialists to guide a large number of teams

As I mentioned above, perhaps the greatest strength of this model is that it allows for a smaller number of senior level UX designers to lead a larger number of teams.

At the same time, the idea of having one individual work on many simultaneous projects is generally considered an anti-pattern in Agile circles.  In a traditional model, because project pace tends to be far slower than in Agile model, working on many projects at the same time may appear to be effective, but the reality is that it creates continual disruption of work and incurs a cost each time the individual switches between projects, since they need to be brought up to speed on whatever developments have happened since they last were working on the project.  And with an Agile project, a lot more is likely to have happened in a shorter period of time.

It is a bit like one ball player trying to play on two fields at the same time.  It just doesn’t work. But a sports coach certainly can coach more than one team, and so too can a UX Coach lead the UX design for several teams.  After the initial project visioning, at which point the coach’s involvement is more intensive, the relationship can then become a recurring part-time relationship.

Facilitates increased UX literacy across the organization

As team members are forced to think about the software experience, in addition to the implementation of the software, they will develop an increased understanding of the relationship between these two dimensions of work. Over time, they will require less and less guidance from a UX specialist, making for an approach to designing user experiences that is more holistic, cost-effective,  and leads to a higher quality experience.


This approach will really only work with very senior-level User Experience designers, who have experience in developing overall experience strategies, are fluent in current best practices, and have experience facilitating group sessions. However, that is no different from the requirements for being a successful Agile coach, which requires years and years of experience in the project trenches, in a variety of roles.  The approach is not recommended for junior-level designers, who are likely to be more effective if instead allowed to focus on a single project. There are probably other disadvantages, but I can’t think of any at the moment.

Update: Once again, Joe Sokohl comes through with key insights, pointing out something that was obvious in my mind but I did not state explicitly in the post – the idea of a UX Coach is analogous to an Agile Coach. Just like the Agile Coach is not part of a team but helps the team undergo the transformation from a traditional to an Agile approach, so too does a UX Coach help Agile teams undergo a similar transformation, from UX being a vaguely mysterious notion to something that is just another normal part of an Agile project lifecycle. Thanks Joe!

Agile Personas

One of the most consistent patterns I see among those integrating UX and Agile is a business-as-usual approach to Personas, i.e. continuing to create them largely in the same way as in a traditional waterfall practice.  Doing so, in my opinion, is a mistake, and reflects a lack of understanding both of the purpose behind Personas and the thinking underlying an Agile practice.

Personas are research artifacts based on real people and real research data that humanize and capture key attributes about archetypal users.  What are their goals?  Preferences?  How do they work? And so on.  They serve both to inform design decisions and, maybe even more importantly, increase designer empathy.  In other words, they are a reminder that these are real people.

So what’s wrong with that?  From a user experience design perspective, what could be more important than to understand your users?  Yes, that is all good and well. The problem with Personas is that they can become an excuse to not work face-to-face with real users.  In a traditional waterfall model, Personas effectively function as a surrogate for being able to interact with flesh-and-blood humans while designing the product. The expectation is that you will spend the majority of your time away from the real users and therefore need something to evoke who they are, so that you don’t fall into the trap designing who you imagine the user to be and not who the user is, or worse, end up designing for yourself. (And don’t get me started on designers who create “Personas” out of thin air based on imaginary users rather from actual research data. At that point, you may be creating a nice reminder that you’re designing for real people, but the persona itself is basically useless or even misleading.)

But in an Agile model, you should be in regular contact with the actual people for which Personas are intended to serve as surrogates.  That means that your approach to creating Personas should shift significantly from how they might be approached in a traditional model.  Depending on how frequently you are in direct contact with actual users, the persona can be correspondingly light-weight.  In other words, if you meet with users every day or every few days, a light-weight persona can contain as little as the person’s first name, a picture of the person in the actual environment in which they will be using the product, and a few bullets re. goals, motivations, and perhaps a “money quote.”  But that’s it.  Anything longer or more detailed, such as this very polished Persona and you’re back in waterfall world, spending more time on designing documents than designing software.

Btw, the name of the persona should be a real name and just a first name, for two reasons.  Referring to someone only by their first name is both more intimate, and also provides that person with a bit of privacy to those outside the project who may see a persona posted on an information wall. Additionally, by having a real name, the name itself becomes a shorthand for the persona, since all you need to do is say their name during team meetings and team members, who in an Agile model all will have met this person, will have a clear image of the persona you are referring to.  In other words, in an Agile model, Personas are…real people!

Being able to glance up at a persona on your information wall to remind you of that real person can be valuable.  A possible downside is that you may end up designing for only the people you are working with and not the archetypal user, but that can be mitigated in a number of ways, such as ensuring that you have a regular cadence of a wide range of users interacting with the working software.

Furthermore, traditional Personas are also based on a sampling of the overall demographic.  And since they often only are created once, as part of a discovery phase, they are effectively a freeze-frame of a real person. But real people are quirky and weird and often inconsistent in their behavior and maybe you caught them on bad day or whatever during the discovery phase.  By working the actual people over time, you get a more normalized version of a traditional persona, one that reflects all of people’s normal fluctuations in character and temperament over time.  An Agile Persona, in other words, can be easily updated throughout the project as you continue to discover new things about your users.

Yes, sometimes you will not have the ability to work face-to-face with actual users, but in those cases I have found lots and lot of pictures of a wide range of users in their normal environment to be far more valuable than text-heavy Personae.  (And I just had to throw that ultra-nerdy plural usage in there at the end…)

Notes from the Agile UX Retreat at Cooper

This last weekend, a group of about 30 UX designers, developers, and leading thinkers in the Agile UX space (Jeff Patton, Ward Cunningham, Alan Cooper, Lane Halley, Desiree Sy, and William Pietri among others) met at Cooper in San Francisco to talk about the power and the challenges of integrating the Agile and UX disciplines.

Photos by Chris Nodder.

Not surprisingly, there were a wide range of opinions.  More surprisingly, for such a large group, we were able to keep our discussion focused and productive.  These are some of the big take-aways that stood out in my mind.

The Us/Them Challenge

We intentionally had attendees with a mix of backgrounds, including UX designers, developers, testers, and managers.  A consistent theme throughout the event was that of the Us/Them challenge, of how the separation of work among team members is a fundamentally negative force working against the project’s chances of success, and goes to the core of why traditional waterfall methods so commonly fail.  That separation, be it via role-based silos, throwing work over fences created by phases of work, or the underlying mentality that What I Do Is Different From What You Do, is the source of the Us/Them camps within teams and the havoc they create.  Agile, in contrast, seeks to minimize the Them and maximize the Us, not just through focusing on distributed knowledge, but also on distributed understanding and empathy for other team members.

We tussled over the issue of how much work UX designers should be doing on their own, how much work they should be doing up front before involving developers, and ended up rallying around the cause of the barely sufficient Iteration Zero, of doing the absolute minimum separately from other team members throughout the project.  And when Us/Them thinking would creep into our discussion, such as when a UX designer started talking about the importance of alone time, someone else would call out “Us/Them, Us/Them!” as a kind of mantra of the event.

What is the relationship between UX and the Agile team?

We had a lot of interesting discussion re. where UX fits into, or what its relationship is, to the Agile team.  The idea that UX should be more a competency and less a role resonated strongly. Alan likened the software team to a sports team on a field, in which everyone has set roles but their actual work can be fluid across the field/project. We also discussed the role of the UX Developer, a prototyping competency dedicated specifically to simulating User Experience, as a powerful pattern in Agile UX – at least two of those attending were from organizations that had independently adopted this practice.

Toward a Post-Agile Paradigm

But perhaps the most interesting take-away from this event was that there was a strong feeling among us that we are moving toward (or have already entered) a Post-Agile Paradigm, meaning that what we really are talking about here is not the Agile your grandparents knew and loved, er, I mean the Agile which the original signatories (of which one of them, Ward, was attending) articulated in 2001.  Remember, Agile in its original form is largely silent about UX.  Our conversation was about a paradigm in which the voice of UX plays an equal role in the project chorus.

Here are a some nugget quotes from the event:

Proccesses that are able to embrace the unexpected will look sloppy to the outsider. -Ward Cunningham

The only products that are really done are the ones that die. – Jeff Patton

If you work really hard to please your customer you will most likely fail. If you work really hard to please your user you will most likely succeed. -Alan Cooper

Iteration Zero is about paying down strategic debt. -Desiree Sy

Product ownership is a team effort. -[Don’t recall who said that]

At the end of the event, Lane was leading us through a root-cause analysis, to help us drill down into specific causes and corresponding actions we might take.  We actually were not able to quite finish this exercise before we ran out of time, which sort of left us with a kind of cliff-hanger motivating us to organize a follow-on event, which I very much hope we can do in the near future.

Also, other attendees have posted links to their blog posts about the event at the Agile Experience Design social network.

Thanks to the following companies who made this event possible!

Atomic Object, Cooper, HP, Pivotal Labs, and TechSmith.