in Agile, Process

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.


  1. Hey Anders, I got to this post a bit late, but really like your thoughts on collaborative design. My question is what measures do you take if (in a larger organisation) the nature of the team (designers and developers) is not collaborative?

    I’ve seen many arguments and much tension between designers and developers in different companies. Throw in PMs and “UX pros” and it can get even worse. Would be interested to hear your take on implementing agile UX when the team struggles to work together, as collaborative UX sounds not different than a web team working effectively together.

  2. Hmm, yes – maybe the common workspace is the answer to this. That way the decision to work individually/together is natural, unforced… Keep up the good writing :)

  3. Hi Rian,

    So glad you raised this point. I am definitely not proposing replacing individual design work with design-by-committee, which tends to be unstructured and not very productive. I am talking about stuctured collaboration, such as pairing and all the various forms of workshops that are part of the Agile canon.

    Additionally, to your point that designers need some space to be innovative on their own, yes that certainly is the case, but often they need a lot less space than they think or a different type of space. Remember, these are designers conditioned by having done homework alone in grade school, worked separately from developers in their design institutions, and sat alone in a cubicle at some office.

    More importantly, there is no need for everyone to suddenly be collaborating all the time. The simplest step is to merely having everyone sitting in one shared space (and not wearing headphones) and continuing to work individually as desired, which allows for ritual-free ad-hoc collaboration and pairing.

    Btw, somewhat ironically, the examples that Lanier provides in the (great) article you recommended, are not examples of individual work. Larry Page and Sergei Brin paired on the Google algorithm. Jonathan Ives did not go off into some corner and return with a finalized design of the iPod or iPhone.

  4. Hi Nicolas,

    Good question. Yes, stakeholders will need to know what the product will be at the end of the dev cycle, but…

    There is nothing preventing a team from creating a couple high-def artifacts (which I assume is the same as detailed mockups?) as part of the model I am proposing. The difference is only in that they may produce fewer of them and that there will be a likely less glossy working version of the real product to calibrate their imaginary understanding of what the product will be. Of the many powerful attributes of real working software is that it brings pie-in-the-sky thinking down to earth, which is especially helpful in managing the expectations of non-technical stakeholders who too often are fooled into imagining perfection from seeing high-def mockups.

  5. Hi Anders – great post and great blog. I like your descriptions of conversation placeholders and conversation supporters – it’s a very helpful way to describe wireframes (and why they are important) to a non-designer audience.

    The part I’m still wrestling with is at what stage design should become collaborative, and how you harness the value and innovation that comes from some level of design in isolation. It’s this WSJ journal article that really got me thinking about it.

    I think there has to be some space where designers can be innovative on their own, before the rest of us get involved. As a PM, I try to give my team that space and not get involved too early, but it can become a tricky line to walk effectively.

  6. Hi Anders,
    While I agree with all your ideas, there is one dilemna with project stakeholders / management teams : as some points, and rather sooner than later, they need to know what/how the product will be at the end of the dev cycle ; which requires high-def artifacts at some points.
    What is your view on this ?

Comments are closed.


  • Värdet av tidig feedback « Helt Sonika July 8, 2010

    […] Agile UX and the One Change That Changes Everything – om att börja jobba agilt genom korta feedbackloopar […]

  • Vattenfallsträsket del 3 – Nya arbetssätt för agil UX « Helt Sonika July 8, 2010

    […] Ramsay skriver här kommer man tvingas anpassa sig om man börjar ha som ambition att leverera en fungerande produkt […]

  • Lärdomar från ett agilt UX-projekt « Helt sonika July 8, 2010

    […] Anders Ramsay har skrivit om kommunikation i agila projekt här […]

  • Designing Ahead: The Good, The Bad, and The Ugly - Anders July 8, 2010

    […] my previous post, I talked about how starting to build earlier has a cascading and transformative impact on the UX […]

  • User Experience, Usability and Design links for July 12th | July 8, 2010

    […] Agile UX and The One Change That Changes Everything – Anders Ramsay.comIn 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. […]

  • Favorite UX / Product Management posts of the week (2010-07-10) July 8, 2010

    […] Agile UX and The One Change That Changes Everything, Anders Ramsy writes about how user experience design can be adopted to fit the agile mold a little […]