I’ve both written about and given a few talks on the UX of Minimum Viable Products. This is one I gave at UX Singapore earlier this summer. It’s a pretty good primer on MVPs and how I see them relating to UX design.
I’ve both written about and given a few talks on the UX of Minimum Viable Products. This is one I gave at UX Singapore earlier this summer. It’s a pretty good primer on MVPs and how I see them relating to UX design.
When adopting a new way of working, it’s natural to use what you currently know as a starting point, and to frame questions about the new thing you are learning using the terminology and perspective of the old way of working. So, if you are a UX designer coming from a traditional UX background, which tends to have a strong process focus, it’s no surprise that you may be asking questions like “What is the Agile process? And are we following it?”
These questions may seem innocent enough. But it’s actually not too different from asking “Where on the bicycle does the steering wheel go?”
Now, in the case of the bike, it’s pretty obvious the question doesn’t make any sense. But it can be far less obvious to someone new to Agile that there is no such thing as a specific Agile process. The “process” in an Agile world, is a continually emergent path forged by a self-organizing team, not too different from E.L. Doctorow’s famous description of novel-writing, that it’s “like driving at night in the fog. You can only see as far as your headlights, but you can make the whole trip that way.”
What matters is if the team is equipped to forge this path and make good progress toward their destination. What matters is if they are able to collaborate and communicate in an effective and healthy fashion.
As an Agile UX coach, when evaluating a new team or organization, I usually conduct a kind of informal Agile UX health check, in the form of a set of core questions. In some cases, I ask them outright to members of the team, in others it’s just something I’m asking myself. Among the innumerable possible questions one can ask in assessing a team’s health, I have found the questions below to be an effective barometer of how well they work together and their ability to deliver a high quality product.
By developers, I am referring to anyone participating in making the actual product. By active involvement, I mean direct participation in product research, design, and implementation. Sitting in a meeting watching a presentation of work someone else did is passive participation and does not count.
A developer who is actively participating in early design work can often do something most designers can not: they can tell you when starting to build the product will be more valuable than continuing to imagine and describe it. They will help you fail faster and keep your ideas closer to the proverbial rubber hitting the road. They are also often able to offer ideas for solutions that a non-developer may not have considered. Just as importantly, early active involvement helps reduce the destructive Us/Them relationship that so easily emerges between designers and developers when they work separately.
But like many things worth doing, this can be damn hard to pull off. Active involvement by developers early in a project, ideally starting on day one, requires an organizational culture that sees just as much value in developers participating in sketching and exploring the product experience as in having them code that experience.
It also requires that developers themselves believe in this way of working, which will usually also mean that they’re going to be more attentive to experience quality in general while building on the product. And that is basically priceless when it comes to delivering a well-designed product. Because no matter how good a UX designer may be in defining a great experience, the buck will ultimately stop with the coder. They make the final atomic-level choices about how the product will work. They fiil in blanks where design documents fall short, or, for better or worse, choose to ignore them, in trying get a feature out the door.
Successful Agile UX adoption, in other words, is not just about transforming how UX designers work, but how the whole team works, particularly developers. If they are actively involved early on, that is a clear indicator of healthy collaboration.
While having developers participate in design work is great, collaboration in an Agile UX model is not a one-way street. It is just as important for UX designers to be crossing the design-engineering chasm in the opposite direction. The degree to which they do this is another key indicator of Agile UX team health.
The most common and least healthy pattern I see in this area is the UX designer who strictly does UX design and nothing else. This is like only writing recipes but never actually baking any cakes. Being a coder or a visual designer in addition to doing UX means you have a much more multi-dimensional perspective on the product. It also increases your empathy for the effort of other team members, and reduces communication churn.
And I’m talking about production-grade coding or designing production-grade visual assets. That is not to say that there is no value in having UX designers code and design throw-away prototypes. It’s much better than nothing at all. But getting back to our cake analogy, that is like creating a plastic model of your cake. We can look at it and it may have some benefits over just reading a recipe. But we can’t eat it. We can’t truly experience it.
The point of doing production-grade coding isn’t just about the coding part, it’s also a social and cultural thing. When you are checking in code, when you get to see automated tests puke out all kinds of errors, when you at some point break the build (and you will break the build at some point), and pair with another developer to figure out the problem, you are collaborating on a completely different level than if you’re building throw-away models.
The method by which a team decides if a design is of sufficient quality can be very revealing of their general health and effectiveness. Traditional teams tend to use approval from a client or a business sponsor to determine if the design is good. Quite honestly, this is an area where many Agile teams fare only somewhat better, with the concept of Done. Done is basically a judgment call made by the team, and ultimately by the Product Owner, as to whether the team should stop or continue work on a feature. It’s great for helping teams make decisions and move forward, but it can also lead to shipping half-baked crap.
Yes, the feature you shipped may technically support what the customer asked for, but oh boy is it ugly and a pain in the ass to use. Some developers like to talk about how what really matters is that the features do what the customer requested and that everything else is icing on the cake.
To all those developers, I would like to thank them by serving them the following fully functional meal.
Technically speaking, it contains all the ingredients of a pork-chop dinner, but oh-my-gawd does it look awful. And eating it ? Gaaaaaaahhhhh. (Yeah, yeah, yeah, I know this is for wartime consumption on the battlefield, but you get my point.) Compare this to a pork-chop dinner you might be served in a good restaurant, one in which presentation and all kinds of intangibles have been tended to. It looks good and is a pleasure to consume.
So, getting back to our original question, how do we determine if the design is good. Well, the only real way to know if a design is good is if actual users are f*ing using it.
This is one of several areas where Lean Startup can come to the rescue. We use metrics and other forms of validation from real or prospective customers to measure whether or not a feature is good, or just as importantly, if it sucks. Too many times UX designers and clients get so wrapped up in their own “succes theater” (my favorite Eric Ries phrase), that they convince themselves of the brilliance of their own ideas, when in fact it may or may not have any basis in reality.
There’s a lot of talk in Agile circles about how everyone should be working in the same room. Well, guess what, you can put a bunch of people in the same room, but if they aren’t used to working that way, if they’ve been sitting in cubicles their entire working career, you may end up with a bunch of agitated wrecks who want nothing more than for everyone else to get out of their hair.
What’s more important than being physically co-located is to have what I call a co-location mindset, which effectively is the ability to communicate as if you were face-to-face even when you’re not. A great indicator of a co-location mindset is when the team can maintain a low bullshit-to-content ratio in their virtual communication. For example, rather than needing to formulate long-winded emails intended to really only ask another team member a single question, you can just pop up a chat window and (gasp!) just ask the question.
In other words, a team scattered across the planet that communicates openly and frankly and without a lot of ceremony is more healthy in my book than a co-located team where everyone is walking on eggshells. Now, don’t get me wrong, achieving fast high quality communication is often much easier when you’re co-located. Just don’t assume it will happen automatically because everyone is in the same room.
A team within a larger organization is not an island. They are part of an inter-connected eco-system, and you can’t try to have just, say, the design department of a company “go Agile.” So a key question is the degree to which other parts of the organization also are adopting Agile methods.
Many of them are parts of a company you’d likely never associate with Agile and, as such, are hidden barriers if they are not part of the overall Agile adoption. Here are some of the more common Agile bogey men that might be lurking in the dark corners of your company.
Let’s start with Business Development, basically the progenitors of new project work. During this initial phase, there often is high-level phase-based planning that occurs, with research folks only participating early on, and developers not scheduled to be brought in much later in the project. In other words, you’ve basically been locked into a waterfall project before you’ve even started.
Another great example is the facilities group. Agile is very much about allowing teams to shape their own physical workspace around their own needs. However, for that to be possible, whoever is in charge of room setup, desks, meeting rooms etc. needs to understand the value of empowering teams in this way. What often is the case is that the individuals in charge of facilities and building logistics are far removed from the Agile adoption, and trying to get them involved can be a major bureaucratic headache.
Last but not least is the IT Dept. You’d think that they’d be your closest ally when it comes to adopting Agile, and that may often be the case, but don’t assume it. Don’t even assume that they have adopted Agile in the first place. And if they have, don’t assume that the flavor of Agile is one which will welcome UX designers into their midst. In many cases, what they are really practicing is Agile-fall, where they certainly do practice Agile methods when it comes to the coding part, but when it comes to the experience part, they still expect others to tell them and preferably specify in detail what they should build.
There are several other parts of an org that can be a hidden barrier to an Agile adoption, such as HR or the marketing dept. The fewer of these that are involved, the less healthy your adoption is likely to be.
With this health check, few teams, especially those in a large organization, will get a perfect bill of health, but it is a great goal to strive for and a helpful measuring stick in determining how well your team is doing.
How would your team fare in answering these questions? What other question do you think should be part of an Agile UX health check? Let me know in the comments, or via the Twitters!
Among Agile teams, especially those with a strong UX focus, “MVP” has become part of the everyday din of project discussion. A typical conversation might go something like this:
Yeah, we’re working on our MVP right now.
Sorry, what are you working on?
Our Minimum Viable, er, Valuable?… Product. Not sure. Anyway, that’s what we’re working on.
Ok, cool. How are you going about it?
Well, uh, we’re just kinda’ trying to figure out the smallest possible feature set…
The moral of this little exchange is two-fold: First, a lot of UX designers I talk to, especially those coming from a traditional UX background, are finding it quite challenging to wrap their head around the idea of an MVP. I mean what is an MVP anyway? And how the flip do I go about designing this…thing?
Before we dive into answering these questions, let’s first answer another question you may be asking yourself: Who cares?
In my opinion, the art and science of designing MVPs is possibly one of the best measures of how skilled you are as an Agile/Lean UX designer. It is truly a craft in itself, and requires applying all the practices we have come to associate with Agile UX, such as fast, light-weight communication and small intensive cross-disciplinary cycles of work.
With that out of the way, let’s see if we can untangle what we mean by “MVP.”
In a traditional UX design model, one will commonly try to design the entire product all at once. The thinking goes that, unless we design the whole thing in one fell swoop, the product will not be a coherent and complete experience. In an Agile model, there is an understanding that this is not too different from trying to plan every last detail of a long journey before it has started. Yes, having a big picture understanding of your journey and destination is important, but no matter how thoughtful your plan, it is all but certain to begin going to sheit the moment the journey gets underway. We therefore keep the big picture in mind, but as far as the details go, we take small continuous steps toward our destination, measure the progress we’ve made, make any necessary adjustments, and then take another measured step.
This measured step is what, for better or worse, has become known as an “MVP,” which depending on who you ask refers to a Minimum Viable or a Minimum Valuable Product. Either way, it’s confusing, and many traditional UX designers I talk to seem to think it just refers to a minimum feature set. That, in my opinion, is a waterfall way of thinking about an MVP. It might technically be correct, but it is not a useful way of thinking about MVPs. Instead, to understand what this term actually means, let me borrow a story Mike Cohn tells in the introduction of Succeeding with Agile.
The Hudson Bay Company, which sold provisions and gear to fur-trappers in northern Canada, encouraged their weather-beaten customers to conduct a “Hudson Bay Start.” This meant that, after they’d finished picking up their gear and provisions from the northern Canada store, they’d make a couple hours trek into the woods, set up camp, and then just stay there for a few days. Now, why would they do that? Hey, they ain’t gonna be doin’ no fur-trappin’ that close to town. No, what they were doing was conducting an MVP.
The gear and provisions they had brought with them represented their best prediction of what they’d need over a period of several weeks in the Northern Territories. Simply camping out in the woods for a few days quickly revealed any major flaws in this prediction. The cost of making this discovery at that point was low, just a couple hours trek into town. Making the same discovery out in the middle of nowhere might be costly indeed.
So which part of this is the MVP? The process of selecting gear at the supply shop? The camping out in the woods to see if they had the right gear? The discoveries they made by doing this?
The answer is…all of the above. Let’s break it down into the main parts:
Design, by its nature, makes a prediction about the future, such as “our yet-to-be built product will address a need or desire that people have and they’ll be willing to pay x amount of $$$ for it.” Among followers of Lean Startup methods, this is what we’d call the hypothesis part of an MVP, which certainly is accurate, though I find the term a bit wonky in a design context.
Now that we’ve made our prediction/hypothesis, we need to design something we can use to test it. This, on the one hand, is the actual product design, but it is an approach to designing the product that isn’t necessarily focused on the product feature set, which gets to the core of why designing MVPs can be hard for traditional UX designers. The MVP may be just a single button for users to click on. It may be just a command line interface with no GUI at all. Or it may be the now-archetypal Lean Startup landing page. We’ll discuss in more detail below.
As we saw with our Hudson Bay fur trappers, it was the fact that they set up camp very soon after acquiring their supplies that was essential in making the MVP valuable. While there isn’t a specific amount of time within which you should complete an MVP, the more time it takes to complete, the less valuable it becomes. This is where all the light-weight Agile UX practices become so important. They are the tools that help you complete your MVP in days or hours rather than weeks or months.
In Lean Startup speak, this is the third part of a Build-Measure-Learn cycle. The test you design must be such that it can allow for gathering actual metrics which inform the degree to which your prediction was accurate, ie allows you to learn from what you built through measurement. It is therefore not sufficient to, for example, create a paper prototype and then ask people if they think the design is user-friendly, or if they like it, or whatever. Who cares if people think a product is user-friendly if it’s the wrong product?
No, what your test must allow for measuring is if the product you’ve created will solve the problem you thought existed. What percentage of users said they would pay for it? How much did they say they’d pay? Would they be willing to use the product if it were free? etc.
Now, in an early MVP cycle, you can certainly get value out of a paper prototype of your idea, and measure how many people said they would use or buy what you present. It’s a good start, but not a strong metric in the long term. You’ll quickly need to move to actually building something which they can actually use, or actually sign up for, etc, which is a far more solid measurement of the quality of your idea.
We then feed what we learned into the next measured step along our product road map toward our ever-evolving grand vision. Every step along the project journey can be approached as if it were an MVP.
As discussed before, the designing part of the MVP tends to be the core focus from a UX perspective. It also is only implicit in a Build-Measure-Learn cycle, which glosses over the question of what we should build. Answering that question, of course, goes to the core of what UX design is all about. Here, however, we also have to answer what may be an even more difficult question: “What should we build first?” Traditional UX designers often just try to approach this by looking for some minimal feature set. That simply is not effective and misses the point of what an MVP is all about. Here are five strategies, or ways of approaching the design of an MVP, which I’ve found effective in helping teams answer this often challenging question.
If you’re working on a product where a key goal is to make some current annoyance or pain go away on the part of your users, this can be a great approach. Reducing pain tends to often be a main driver behind replacing legacy enterprise systems.
A Painkiller MVP may be a single feature which addresses a high priority pain point at a relatively low cost. For example, a lot of old systems often require users to suffer through time-consuming busy work, such as having to manually rename or move files around or copy files from one directory to another. Your MVP may simply be one or more buttons users can click which automate these common tasks. Yes, your entire MVP may actually be a single button. Seriously.
In addition to gaining a quick win with end users, even building this one feature will allow developers to start digging into the production technology and start uncovering issues at that level as well. It’s a great example of how an MVP may look nothing like the envisioned whole product, and yet is a concrete and measurable step toward it.
This can be a great for products or services that you will want users to pay for in some way. First, look at the core revenue model and ask what exactly it is users are paying for. If you are providing some type of expert advice, do you really need to build a full-on site with a content management system and what-not to test if people will pay for the expertise? Maybe the MVP simply is an email newsletter. Or, if you are selling a product, can you maybe do without the online shopping cart and just take orders over the phone? There are a lot of features that often are thought of as “must-haves” for the product, but which aren’t actually necessary to get the product out of the gate. Scrutinize every feature, asking if it really is what users are paying for, or if they would still pay for the product or service if it was removed.
In many cases, you may be able to manually simulate features that eventually will be accomplished by the system. This is what is known as a mechanical turk, in which you input some request, which then gets sent to an actual person who performs the task and provides what appears to be system output.
Say you’re doing a dating site, in which the assumption is that what people are paying for is to get a small number of high quality matches. Instead of trying to perfect some probably very complex algorithm for matching users, in your MVP you instead manually match users based on the parameters of the “algorithm,” which also allows you to tweak the matching algorithm as you go. This is great for letting go of the idea that every feature has to be programmed into the system. Consider just simulating it manually at first.
This is a great strategy for a product where a core part is some engineering special sauce, or in which a key product risk is technological. Maybe you are designing a parts ordering system where a major challenge will be to connect with parts warehouses all over the globe. While UX designers may run aghast in horror at the thought of this approach, we here might totally forego UX design in the MVP, and just focus on the technology. Maybe the first version of this product is just some bare-bones GUI or even just a command line interface. This approach can be great for avoiding getting bogged down in UX issues before you’ve even figured out if the technology actually will deliver.
Last but not least, this is the approach that has become popular thanks to the Lean Startup movement. Here, rather than try to build the actual product, we instead imagine that the product already has been built and create the marketing page for selling it. Think of it as creating a physical storefront without an actual store, intended to see how many passersby are enticed to come inside. We then can use a number of metrics, such how many people sign up to purchase the product, to determine what type of market there in fact is for the product. If you don’t get a lot of signups, you can modify your message on the marketing page and see if that has an impact, which effectively means you are redesigning the product by way of your marketing page.
These strategies of course are just a starting point, and you will likely use some combination rather than one or the other. What’s most important is to remember that there is no one right way to design an MVP. It is a craft and an art like any other. And in my view, it is one of the most essential skills for an aspiring Agile or Lean UX designer to strive to perfect.
I’ve seen a lot of discussion recently on what the difference is between Agile UX and Lean UX. I am happy to plead guilty to having used these terms interchangeably, as it would seem they are both talking about a more light-weight and iterative UX practice. But when I was recently asked to participate in a Lean UX Roundtable panel, I thought it would be a good opportunity to show that they, in my opinion, really are not the same.
Here’s the slide I used in explaining how they’re different (I’ve added the complete deck below):
I think it’s easy to think that just because you are adopting an Agile and/or Lean approach to your UX practice, that all the traditional UX practices and principles suddenly somehow vanish. Nothing could be further from the truth. As experience quality becomes an evermore critical factor in product success (ie. if you have 10 apps to choose from that basically all have the same features, which one do you think people will pick?), everything that UX designers have been hemming and hawing about for eons (ahem) about usability and good design principles is as important as ever. Good design is good design, regardless of if we are living in an Agile or Lean or [insert new term] universe. The only real difference when adopting these methods is in the How, which is what Agile and Lean UX are all about.
Agile was created by enterprise developers and looks at the software product from a developer perspective, similarly to how someone working in a restaurant kitchen looks at the restaurant at large. It’s not that the stuff going on in the front of the house, the experience part of the restaurant, isn’t seen as important, it just isn’t the primary focus. Furthermore, in the enterprise world of old, which was a primary focus of Agile, software products were more akin to an institutional cafeteria anyway, ie highly utilitarian systems where the focus is on delivering the required features rather than a great user experience. As Ward Cunningham, one of the original signatories of the Agile Manifesto, once said at an Agile UX retreat at Cooper, “Agile is hot food served quickly.”
Ultimately, Agile is about high-quality high-velocity delivery of working software. In the Agile universe, that is the ultimate measure of progress. However, a funny thing happened on the way to that Agile Manifesto. Making great software quickly, it turns out, requires collaborating really effectively with pesky non-binary entities called people. While basically silent about UX design, Agile thinking offers a fundamental paradigm shift about how to interact and communicate with the people on your team and beyond.
So, while there certainly is a lot that UX designers can learn from Agile thinking on software delivery (such as to automate everything that can be automated), the real pay-off for UX practitioners is in the collaboration part. Agile UX methods, like Design Studio and Cross-Functional Pairing, help UX practitioners replace slow documents with fast and effective direct interaction. An Agile UX practice, in other words, replaces document-centered practice with one that is collaboration-centered. This is a very big deal for UX designers working on Agile teams, because it is this shift that is key in allowing them to integrate their practice with Agile Developers.
Cool, so now we’ve got this great Agile machine allowing us to be crazy-efficient in shipping software. But, um, did anyone check to see if we are shipping the right software? A Lean UX approach shows us that shipping, which basically is the big honkin’ Done in the Agile world, is in fact really only the beginning. While Agile methods help UX designers turn old ways of designing and communicating on their head, Lean UX helps us overturn old approaches to research and measuring quality.
In a traditional model, research is something you do before starting to create the product, to figure out what the product is that you are going to build. In a Lean approach, we are continuously building and gathering metrics about what we have built. The most archetypal example of this is the metrics-gathering landing page, which is created and launched at the very outset of the project, rather than soon before the “finished” product is about to be released. We turn what was once just seen as marketing fluff into an actual experiment of our hypothesis that others will think our idea is as great as we think it is. Then, the metrics gathered from that landing page (or it can evolve into a full-fledged metrics-gathering website) are fed back into the product design.
But a landing page is just one of any number of ways one can apply Lean UX. Another common pattern is to create a simple prototype and GOOB! or ”Get Out of the Building!” Many UX designers give lip-service to the idea of User-Centered Design, but don’t actually spend a lot of face-time with real users. Regardless if they do, GOOBing both rebrands and reshapes the idea of UCD and also gives UX designers a nice kick in the butt to get out of their cozy cubicles and offices and actually take their ideas to where the users are.
We are, in this model, not doing research before or after the product is made but throughout the product design and delivery process. While in an Agile UX model, Building is Designing is Building, in a Lean UX model, Building is Research is Building, and it is easy to see how these two are very much intertwined. Like with Agile UX, it allows for much more easily integrating research with how Agile teams work, since it is continuous and not up-front.
One more thing about Lean UX: I think it’s kinda’ confusing. The term “Lean” has its origins in Lean Manufacturing and refers to the practice of minimizing waste and maximizing flow, which, in turn, is a cornerstone of Agile methods. Lean UX, on the other hand, is really a reference to Lean Startup a la Eric Ries (and Steve Blank, basically the godfather of Lean Startup, and creator of concepts like Customer Development and Getting Out of the Building), which extends Agile ideas to include methods for ensuring that there in fact is a market for the product you are doing such a good job designing and shipping early and often.
Bottom line: in everyday conversation, whether one uses the term Lean or Agile or what-not is probably not important. What’s more important is an understanding of how Agile and Lean help make traditional UX a more whole practice.
Oh, and here is the complete deck from my 10-minute opening talk at the Lean UX Roundtable Panel:
These are my slides from this last weekend’s excellent Agile UX NYC conference. One clarification I need to make. Early in the talk, I describe “designing ahead” as an anti-pattern. From conversations that followed, I think a lot of people took that to mean that designing ahead is bad outright and something you should not do. There is nothing inherently wrong with designing ahead; the problem lies in how you think of designing ahead, ie is it something you do as a matter of course, or is it something you try to do as little of as possible, and who is it that is designing ahead? The UX designer alone or the whole team? More about that in my blog post on this topic.
So, with that out of the way, here are the slides from my talk:
UIE just published this podcast, where I have a great discussion with Jared Spool about how I’ve applied Agile thinking and values to UX practice. Here’s a sample from the beginning of the podcast, where I talk about how this thing we call Agile is really historically upside down…
Jared: …it feels to me sort of like an onion, in that you’re always seeming to peel things back, and at the core of it are these Agile values that really, I think, speaks a lot to what people are trying to do and why this really is something more than just a fad or just a re-branding of something we already were doing.
Anders: Yeah. So what’s interesting and maybe confusing for people who aren’t aware of the history is that even though the “Agile Manifesto” you know, was formulated in 2001, that was something that was many, many years in the making. And it’s really sort of turned upside-down, because the methodologies that people are familiar with, they actually existed before that term “Agile” was coined. And, in turn, those methods originated from what was generally referred to as lightweight software-development methods.
So I see myself as being more of an adoptee of these earlier, original elements that became the basis for Agile. And Agile is more just like a brand, a term. It’s something that we can all refer to. We can just talk about Agile. We’re referring to this kind of way of thinking about design in general and software specifically.
If you want to learn more about applying Agile values to UX practice, be sure to check out my upcoming UIE/Rosenfeld Media Next Step Series virtual seminar.
Be sure to check out my upcoming virtual seminar on this topic, which is a collaboration between UIE and Rosenfeld Media.
Just gave this talk on cross-functional pairing at the 2011 Balanced Team Conference. Really good reception, and lots of great discussion afterwards. Check it out!
In the first part of this two-part series, we talked about what Stories are, their relationship to Personas and Story Maps, and factors to consider when writing stories. Let’s continue by looking at the relationship between stories and UI exploration.
Within the everyday chaos of an average design project, part of what makes stories so valuable is their nimbleness and flexibility. They can easily be ordered, re-ordered, and grouped in any number of ways depending on your current need, such as by category, priority, complexity, sprint, or whatever, and you can do this in a highly ad-hoc manner. Team members can use the same card for everything from affinity diagrams to product road maps to scrum boards and on and on. But this level of flexibility also has drawbacks.
The node-like nature of Stories also means they often lack context. In other words, while you can easily group a set of cards and say that they belong together, it is very difficult to see how they will fit together simply by looking at the cards alone. This is where UI exploration comes in.
While Agile offers strong conversation-centered methods for capturing stories, UX adds to that by offering visually centered methods for contextualizing those stories, i.e. helping us uncover the order in which features should be completed, which feature should be accessible in association with other features, and more.
Here’s a quick example. Jim, the auto mechanic we talked about in part 1, has described each of the following features as being important to him:
Find part by part number
Find part based on location in vehicle
View part specs
Show me if aftermarket parts are available
Keep a running tally of parts I plan to order
(Note that we are not using the long format described earlier. Especially during early exploration, just have users jot down short phrases they can speak to in more detail later.)
Discussing these features with Jim, he explains that
Sometimes I want to search by part number, but sometimes its easier to just find it based on where in the engine the part is, especially for new models, though sometimes I might need to find the part based some other spec info, or all I have is an aftermarket part number.
Based on this conversation with Jim, while it is clear we have a good starting point, it is also clear that we have no idea if this list of features is the right list or a complete list until Jim is able to see them in context, i.e. in some rendering of an actual user experience.
For example, maybe we create a part number search feature with a smart auto-complete, which when Jim sees it, he realizes that a visual search is not as critical as he thought. Or, conversely, maybe we make the visual search so easy that searching by part number falls to the wayside.
The bottom line is this: make sure UI exploration is part of story development. For example, do some initial cardstorming with your users, but then quickly transition to a visual exploration, such as a design studio. (Will Evans recently did a great write-up on on that.) The visual exploration will also help you improve your story coverage.
Story coverage is the degree to which you in fact have all the stories that will be needed to deliver a complete product experience. This can be very hard to see from just looking at a list of cards, but is much more likely to jump out at you when looking at or interacting with a user interface.
If you are using a story-based model for software development, that means that only features for which there are stories, and which have been added to a sprint backlog, will in fact get implemented. Ok, that’s all good and well, but what does that have to do with UX? Well, it means that simply having a feature appear in a wireframe or prototype, even if the team agrees that the feature is important and should be part of the product, does not mean that feature will get built. There must be a story for the feature, and the feature must be added to the backlog. If not, you’ll be negating much of what makes a story-based model effective.
Now, in most cases, this is not a problem. The force driving the creation of a set of wireframes is usually a set of stories. Or, in other situations, you might start visually, and then generate story cards from those artifacts.
But in the midst of this, there are certain features which can easily slip through the cracks, which I like to think of as UI infrastructure stories.
These are your water-sewer-electricity-type features, like pagination for tables or navigation bread-crumbs. A product owner isn’t going to think to ask for this stuff, but will simply expect to see it in the product, like I am not going to ask for electrical outlets in my hotel room, but will just expect it.
The problem here is that, in a story-based model (and in some ways in the Agile model in general), if you don’t ask for it, you won’t get it. But UX design, in contrast, is very much about giving the customer what they did not think to ask for. Therefore, as part of UI exploration, it is essential to look at the UI and compare it to the backlog and make sure that there are cards for these types of features.
Find these features in your design artifact, write a story for each of them and work with your team to get them estimated and added to the backlog. If not, you are going to have some unpleasant surprises at the end of your sprint, and be carrying UX debt, i.e. half-baked experiences that, like credit card debt, get costlier and costlier to fix with time.
A key function of user stories are to serve as an estimating and planning tool. After stories are written, hopefully by customer and users, developers use a variety of methods (such as planning poker) to assign a cost to a story, such as in the form of story points, such that the Product Owner can decide if they want to “buy” it and place it into the backlog.
Conventionally, only developers, or those who will be doing the actual software construction, participate in estimating. That is all good and well. (After all, something that may seem as simple as justs adding a button to the screen from a UI perspective could equal a world of work that we are not aware of under the hood.) At the same time, it is critically important that you are present during estimation.
And I don’t just mean physically sitting there watching developers estimate (though that can be an experience in itself, if you’ve never seen an Agile estimation workshop), I mean really being present. In other words, come prepared to an estimation session with an idea of which cards you think might involve some complex UI, and watch out for a low-ball estimation. Make sure you educate yourself on how Agile estimation works, so that you can raise a concern if you think developers are under-estimating a feature.
A common pattern, particularly on a pragmatic Agile team, is that the estimation will be based on the simplest possible way to implement the feature. For example, if you are implementing a form, that may mean just putting all the fields on one page as one long form. However, that may not be the best solution from a UX perspective. You should be present to lobby for a more costly but also more user-friendly UI, in cases where it makes sense, such as to make the product competitive. This is also why its so important to have done some UI exploration before you estimate, to have a concrete basis for your discussion. Too often I see it happen afterwards, which makes for all kinds of churn and other problems.
From a tester’s vantage point, a story is something for which you create a test. If the test passes, the story is done. Ok, I’m oversimplifying things quite a bit here, but one thing to be aware of is that testers in many cases are not looking at or primarily focused on the user interface. Instead, they are writing code-based tests that check to see if the code written to execute the given feature passes the test or not.
If your head is spinning from reading that, then you would be well advised to educate yourself on test-driven development. It turns traditional QA on its head and is a powerful manifestation of Agile thinking.
Perhaps more importantly from a UX perspective, because it allows for a large percentage of testing to be automated, it can free up testers to spend time reviewing the user interface and the quality of the user experience. This can, to a large degree, be a question of working with them to point out examples of the types of issues they should be looking for in the UI, things that might jump out at you, but may not jump out at them, such as pagination links being super-tiny or in a color that is hard to see or whatever, but also to make sure that they are looking at and comparing UI screen mockups with the real thing.
It also means looking carefully at any acceptance criteria that have been created going into the sprint, because testers will use those as a basis for determining done-ness. Another very powerful tool here is a UI style guide. This is where you can include general display rules for the user interface, so that you don’t have to keep repeating the same issue over and over.
This will allow you to spend more time working on the design for an upcoming sprint and spend less time having to check every screen of the app at the end of every sprint and nag deveplopers (or fill out time-consuming bug reports) about a slew of small tweaks that need to be made.
User Stories are a huge topic and I’ve only looked at them here from the relatively thin perspective of UX. If you haven’t done so already, you should pick up a copy of Mike Cohn’s book, User Stories Applied. Even though it’s been out for quite a few years now, it remains as relevant as ever.
Any tips and tricks for integrating UX and User Stories you’d like to add? Please share them in the comments!
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.
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
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.
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:
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.
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.
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!
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.