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…
…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.
- 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.
- 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.
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:
- 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.
- 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.
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.
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.
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.