Category Archives: Agile

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.

Disadvantages

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.

Why Agile Needs to Start in Academia

About a decade ago, I was in the midst of completing my degree in information science at the University of Michigan.  Wanting to avoid just taking a bunch of vanilla courses, such as computer programming, data modeling, and cognitive psychology, (which all are valuable and important courses to take), I sought out courses in other schools and departments to broaden my horizons.  One such course, in the School of Art & Architecture, was a physical computing course called “Interfacing.”

In the Interfacing course, an art student would pair up with a student from the School of Electrical Engineering to collaborate in building a series of electronic interactive art pieces.  Since I had registered for the course via the School of Art, I was considered the “artist” and was paired up with an engineering student.  Together, we developed our project idea, an analog radio that would tune itself based on proximity sensors, allowing people passing by to discover that their movement was affecting the radio frequency.  Then, we created a circuit board from scratch, soldered on all the necessary electronics, and programmed a 10K chip with the logic needed to have input from the proximity sensor to drive a motor attached to the tuning wheel of the radio.

While we only had mixed success with our nifty little human proximity tuner, the most important lesson was that of working across and truly integrating two disciplines, in this case art and engineering, and discovering that what the other does is not as mysterious and weird as one might think.  I didn’t know it at the time, but this was my first foray into Pairing, a concept currently receiving widespread and well-deserved attention thanks to the Agile movement. Pairing is most well-know in the form of Pair Programming, in which two developers share one keyboard, one “driving” (i.e. typing), the other “navigating” (i.e. telling the other programmer what to type.)  To an outsider, this may seem a strange ritual indeed, but it is in fact a powerful way of generating a highly focused whole-brain work session, in which one person is continually debugging the work of the other. (I.e. as the driver types, they are also thinking about and evaluating everything the navigator tells them to type, able to continually make course-corrections.)

In our case, we were pairing across disciplines, which can be just as powerful.  It becomes an act of debugging or evaluating the work of the other across dimensions.  While the engineer may be deep in their C programming mode, I am thinking about how the resulting code will impact the experience of people walking in front of the tuner.  While the engineer is gaining a deeper awareness of the impact of their coding choices on the people interacting with the machine, I as the “artist” am gaining a deeper appreciation for the complexities of software development (for example, when programming a chip, you can’t call a library function such as “abs()” to get an absolute value, you have to actually write an algorithm for that from scratch.)

Unfortunately, this type of cross-disciplinary pairing is, as far as I know, incredibly rare in academia.  Instead, artists or designers are often housed separately and away from engineers and computer scientists, rarely if ever having any contact with one another. The same seems to hold true for those in the interaction and graphic design fields. Until my first day on my first job out of school as an Information Architect at a small web agency, I had never worked with a graphic designer. I have to wonder how many of those students currently studying interaction design are spending time working side-by-side with software developers.  Based on my informal survey, the amount of time they spend together in academia is approximately zilch.

It is no wonder, then, that so many people in the interaction design community I have spoken with seem to think of developers as the Other, as people who simply are different from Us, who simply do not understand the subtleties and nuances of designing a user experience, who do not think the same way that We do. It is no wonder that so many people in the interaction design community suffer from what I call The Genius Problem, in which they see themselves as the creators of ideas, while developers are mere builders, construction workers who transform these ideas into reality.  It is no wonder that so many people in the interaction design community greet the idea of Agile software development with a high degree of suspicion.  It is no wonder because that is a mindset that academic institutions (unwittingly) have indoctrinated them into during the formative years of their practice.

As long as academic institutions in general, and interaction design programs specifically, do not begin to truly integrate their students with those in the computer science departments, this problem will persist.  Agile should not be something that is only taught in computer science departments, and only discovered by interaction designers on their first day at work.  For Agile to be effective, these students need come into these roles with an understanding of what they do as not being something separate from what software developers do.  And for that to happen, computer programming students should be spending time with graphic design students, graphic design students should be spending time with interaction design students, interaction design students should be spending time with computer science students, and so forth. Until that happens, the integration of Agile with other disciplines will continue to be a perpetual struggle.

Two Great Talks on Agile UX

These are two great recent talks about Agile UX.  The first is by Johanna Kollmann, which presents findings from a research project that she participated in on this topic.

The second is by Cennydd Bowles and is a great primer on Agile UX.

Enjoy!

Why You Should Take Jeff Patton’s Passionate Product Owner Workshop

Last week, I sat in on a dry-run of Jeff Patton’s Passionate Product Owner workshop. I was lucky to be part of this particular group, since Jeff had invited a lot of smart people to provide feedback on his updated workshop, including a Certified Scrum Trainer and other veterans of Agile.  And just as importantly, there were several who were completely new to Agile, to bring a fresh perspective and ask a lot of not-stupid questions.

Jeff Patton leading a workshop

If you want to kick-start your Agile practice or just enrich your current practice, you should definitely consider taking one of his upcoming workshops.  Here are a few reasons why:

The Workshop Itself is Agile

I’ve been to all too many workshops where someone basically drones their way through a big Powerpoint deck for several hours, all while attendees do their best to not fall asleep.  In contrast, Jeff’s workshops are not only highly participatory, but also apply numerous Agile methods, such as discussion timeboxing, using the Pomodoro technique with little Pomodoro timers used both by Jeff while discussing concepts (in 25-minute Pomodoros) and by groups when completing activities (e.g. we’d get 5-minutes to do some Storystorming and then be asked to start our little timers)…

Pomodoro Timers used for personal timeboxing in Agile

…as well as lots of lots of low-cost/high-visibility artifacts that we, the attendees, participate in creating, such as these Agile Personas…

Agile Persona created as part of Jeff's workshop

Another Agile Persona created as part of Jeff's workshop

There are few better ways of learning and understanding new concepts than actually engaging in them, and I think this is particularly true for Traditionalists journeying to an Agile practice, since many Agile methods can appear completely alien to a traditionalist, so the best way understand their power is to actually experience them.

Perhaps the most interesting or unexpected application of Agile thinking is how attendees are introduced. Instead of the vanilla round robin of introductions, which at best tends to be a ho-hum when-will-the-actual-workshop-start activity, Jeff instead had us briefly interview the person sitting next to us, and then share with the rest of the group what we learned about the attendee we interviewed.

This was a perfect segway into a discussion about how Conversation lies at the core of an Agile practice.  Instead of passively listening to others talk about themselves, we have been engaged, and have now already connected with at least one other person in the group, the first step in the mini-teams that emerge as the workshop progresses.  Maybe more importantly, we are required to listen, to be attentive to the person we are speaking with, since we know that we will soon need to deliver a working version, as it were, of what we’ve heard, to the team.  To paraphrase Ward Cunningham, one of the fundamental goals of Agile was to get developers to talk to (and by implication also listen to) their customers.  This interview activity, I think is a great way of manifesting that thinking.

Jeff can probably explain Stories better than anyone else on the planet

Yes, Mike Cohn may have written the book on stories, but at least for me, even after having read that book many years back, I credit Jeff with really helping me see the light in understanding what is an essential aspect of Agile. And by that I mean not only the physical manifestation of stories, such as 3×5 cards, but the thinking that underlies their use.

For someone coming from a traditional requirements management practice, with rigorous requirements and change management systems, the idea of jotting down what you need the application to be able to do on small pieces of paper will likely seem awfully  strange.  Jeff does a fantastic job of conveying how stories in fact are incredibly powerful little pieces in that cooperative game we call software development. In the workshop, he used several techniques, from silent and conversational story-storming (like brainstorming, but you write down every feature you can think of onto a story card), to how those stories are transformed into a model of the application with story mapping, and how we can use the story maps to create holistic groups of stories that span a user flow, rather than being divided into entities, as is more common in traditional unit-based software development.

These are some pictures of workshop participants in the midst of a story mapping activity, which organically integrates stories into the design process, and serves as a powerful technique for inter-relating, prioritizing, and dividing stories into sprints.

Workshop participants in the middle of a story mapping activity

The floor can be the perfect location for story mapping

Maybe the strongest testament to the power of this workshop was a shift in mindset by one of the members in my group.  She said she came to the workshop highly skeptical about Agile, but left feeling that she actually understood it and was looking forward to start applying Agile techniques with her team.

Bonus Reason: If you’re lucky, you’ll get to go out for drinks with Alistair Cockburn afterwards

Since the workshop is held in Salt Lake City, which sort of is ground zero for Agile, you might also get a chance to hang out with some of the originators of a lot of the ideas that Jeff presents.  After the workshop, some of us went out for drinks, and we met up with Alistair Cockburn, who also lives in the area, and aside from being a leading Agile thinker, Alistair is also a beer connoisseur, and provided extensive advice on which beer to select from the The Bayou’s ginormous beer selection.

AXD 032

Hey, every great workshop deserves a great beer!

Agile for UX Practitioners

This is a talk I recently gave at the Delve NYC Conference. The goal is to provide traditional UX practitioners with an understanding of what it means to be part of an Agile team, as well as provide some suggestions for how to make the journey from Traditional to Agile.  (For a visual summary of the talk, check out @rayraydel‘s visual notes, or this one from Matthew Oliphant.)