Agile UX Health Check

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

Bike with a steering wheel

If waterfall is like driving a big clunky car, and Agile is like riding a light-weight bicycle, then applying waterfall thinking to Agile might look a bit like this. (Source: Bicyclog.)

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.

How early do developers become actively involved?

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 traditional meeting, with mostly passive participation

Here is a standard waterfall-meeting from hell, with basically zero active participation.

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.

Do UX’ers also code or design?

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.Bridging the chasm between design and engineering

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.

How does the team determine if the design is good?

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.

MRE Pork chop dinner

Ready-to-eat-meal, which technically contains all the ingredients of a pork-chop dinner.

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.

Pork chop dinner

A pork chop dinner that 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.

Does the team have a co-location mindset?

Co-Location is a state of mind

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.

Is the whole organization participating in the Agile adoption?

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.

How did you fare?  Was this a useful health check?

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!

(Originally a guest post on the Hypenotic blog, as part of the UX in To workshop series.)

The UX of Minimum Viable Products (MVPs)

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?

What’s the big deal with MVPs?

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

What is an MVP anyway?

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

Here is what an “MVP” fur trapper camp might look like. (Source.)

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:

1. A Prediction

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.

2. The simplest design that will test the prediction

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.

3. The fastest test that will reveal if the prediction was correct

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.

4. The results of the test

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.

MVP Design Strategies

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.

Just making one big pain point for users go away can be your entire MVP.

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.

Fa$t Money

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.

Turk It

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.

A slightly creepy original Mechanical Turk device for playing chess. (Source.)

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.

Go Ugly Early

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.

Fake it ‘til you make it

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.

There is no one right way

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.

Agile UX vs Lean UX – How they’re different and why it matters for UX designers

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

Explaining the relationship and differences between Traditional, Agile, and Lean UX

Traditional UX – it’s not like it suddenly vanished

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 UX – Collaboration and Delivery

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.

Lean (Startup) UX – Measuring and Validating Product/Market Fit

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:

The UX of User Stories, Part 2

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.

6. Iterate Story Development with 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.

Users participating in a design studio session

Users participating in a design studio session

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.

7. Make sure UI infrastructure stories get into the backlog

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.

Like signage in a building, some UI features are just seen as part of the infrastructure, and something customers will just expect to be there and not think to ask for.

Like signage in a building, some UI features are just seen as part of the infrastructure, and something customers will just expect to be there and not think to ask for.

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.

8. Be present during story estimation

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.

9. Make sure testers are testing for usability

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.

A snippet from a code-based unit test, which would run as part of automated testing.

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.

10. Read Mike Cohn’s book

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! 

The UX of User Stories, Part 1

If you are a UX designer who wants to quickly get up to speed with integrating Agile and UX, there are few better places to start than with User Stories.  They are both a quintessential embodiment of Agile thinking (i.e. if you understand User Stories, you understand Agile thinking) and a potential power tool for a UX designer on an Agile team.  But like any tool, they can be highly effective, or, if you have no idea how stories work, cause some serious damage, especially to the UX dimension of your product.  So, if you’re using User Stories or thinking about adopting them as a tool, here are ten tips to help UX designers understand User Stories (we’ll just call them Stories from hereon) and wield them to both yours and the team’s benefit.

1. Know What the Story Is

Ok, first things first.  Before we can offer any advice about stories we need to understand what we’re talking about. Take a look at this and tell me what it is:

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

If your practice has been raised on a steady diet of document-centered design processes, i.e. work that revolves around and culminates in the creation of documents, like specifications or use cases or whatever, you can be forgiven for looking at the above card and thinking that you are looking at a story.

The card is not the (whole) story
Yes, the above definitely is a story card, but the actual story is not on the card.  This might be confusing, but bear with me here.  The statement on the card is only what one can think of as the title portion of the story. The full story is the conversation triggered by the statement on the card.  In other words, the complete story, i.e. all the excruciating details about the given feature, live in a self-maintaining, self-updating data store, namely the team’s collective memory.  Therefore, in whatever moment when someone picks up a card and has a conversation with other team members, the statement on the card triggers the most current knowledge about the feature by those team members.

The idea of storing project information in collective team memory might sound funky, but not only does it make a lot of sense—information in a modern software project is too fast-moving and volatile for document storage to be able to keep up—but collective team memory is, by its nature, always up-to-date.  All that is needed are the correct words that will trigger the appropriate memory, and resulting conversation.  And that is what goes on a story card.

If you’re still skeptical about this concept, you should know that you probably use this technique yourself on a regular basis, such as when writing a todo list. When writing a todo list you don’t write down every last detail about the thing you need to do, but only just enough so that you won’t forget to do it and, when the times comes to complete the todo item, you’ll remember all the details about what needed to be done.  Stories work the same way, except that in this case its a team-wide todo item, as well as a team-wide communication device.

Stories are a whole-team communication interface

Stories are a communication interface between team members

Each team members looks upon and uses the same story from the vantage point of their particular work

When you hand the same card to a different team member, each team member will look at it from a different perspective, and use it in a different way.  In more pontificating terms, this is what is known as a boundary object.  For a user, it describes a needed or desired feature.  For a developer, it describes a feature that needs to be estimated and/or work that will need to be completed. For a UX designer, it describes a puzzle piece to be fit into a product offering (or not) to create a coherent and valuable experience.  For a tester, it describes something for which a test likely needs to be written.  And so on, for each team member.  One story; multiple perspectives.

If you understand these various perspectives and the way in which a story gets kicked around between team members, then you’ll have a good mental model of how the Agile project game is played, and where you can best position yourself on the field to move the story to the finish line.

2. Make Personas the voice of the story

In contrast to old-school requirements, which are written from the perspective of computers, i.e. “The System shall…” do this or that, Stories are written from the human perspective, e.g. I want to be able to do this or that.  This shift in perspective is a great example of how Agile is much more human-centered compared to waterfall.  But when bringing UX practice to Agile, we have an opportunity to take this even further, as part of integrating Personas, by making the Persona the voice of the story.

In other words, if we do a Persona workshop in the early stages of the project, each story that is created should correspond to one or more Personas.  Let’s say our substitute teacher persona is Becky. After putting in all that work into modeling Becky, we can now leverage that in how we create and talk about our stories.  For example, we can add a Persona prefix to our story statements:

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

With this short prefix, we’ve both made the user feel more real, and in conversations about this story, we can talk about what Becky would want or not want, rather than what some anonymous and disembodied substitute teacher would want.

3. Have users write the stories, not you

For an advanced Agile team, this is Agile 101, but if you’re new to Agile, you may be sitting there frantically trying to write story cards while users are telling you what they want.  However, a key aspect of an Agile approach to engaging users or team members is active collaboration and creation of artifacts by the team rather than by individuals.  In the case of stories, this means that you create contexts in which users write their own cards.  There are numerous ways of doing that.  One is the Paired Interviews technique I wrote about recently. That, in turn, is a type of cardstorming activity, which more commonly is done individually, with each team member creating as many cards as they can within a short (e.g. 5-minute) timebox, followed by self-organized group chunking and prioritizing.  Additionally, the overall project infrastructure should be such that cards are available at arms-length virtually wherever you are working (e.g. place cards and markers at the center of every table, and scattered strategically throughout your team room), such that you can capture cards at the speed of conversation.

So why is it so important that the users write the stories?  One main reason is that they will then phrase the card in their own domain-specific language, and in a way that is likely to most effectively trigger the appropriate memories when you ask them about the card down the road.  And on that note, if the cards are written by hand, their handwriting can be used for card traceability, i.e. you’ll be able to know who wrote the card just by looking at it.  And if you are gathering info from many users, well, then they will be able to produce far more cards as a group than you could on your own.

4. Be sure to get your “so thats”

As you may have noticed, the above cards are written in what has become a standard structure for writing stories:

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

Now, while there is nothing that says you need to phrase your stories in this way (and when you are capturing new stories, you probably want to just jot down a couple keywords, and write the story in long form later), it is important to be aware of the relationship between the “so that…” part and UX.  Looking at our earlier example with our substitute teacher Becky, the “so that” reveals the Why of the story.  It reveals both the motivation behind the story and often also can reveal something about the context. However, when trying to get a lot of stories created in a short amount of time, this part is often skipped.  And that’s understandable.  However, it is important to then be sure to go back at a later point and get your “so thats.”

To understand why, let’s look at an example where the “so that” is missing.

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

Hmm, why would searching visually be so important?  In a later conversation with an auto mechanic, he explains:  “I want to be able to search visually, so that I can find and visually match the part in the search results to the physical part as well as see in the search where in the engine or vehicle the part should be located, to make sure I am ordering the right part.”  Wow, the “so that” part suddenly revealed a desire for a completely custom visual search interface and a desire to be able to search while working on the car, meaning maybe searching with greasy hands and lying on your back. Seriously valuable intel.  Make sure you get those “so that’s” people!

5. Don’t confuse Story Maps with User Interface

Team reviewing a story wall for story completeness

While a story wall provides a good overview of the product, it is much harder to evaluate for completeness compared to a user interface.

Story mapping is a powerful way for managing stories and offering a big-picture view of the product.  But it is also a far more abstract view of the product compared to the corresponding user interface.  It is virtually impossible for a Product Owner or other domain expert to look at a story map and say, yup, looks like we’ve got all the stories there.  You have to actually flow through it in a user interface to see what is missing. In other words, after you’ve developed your story map and think you’ve got good story coverage, assume you’ll be uncovering a good chunk of new stories as part of designing the user interface.

Additionally, even though you may have organized your story cards into thoughtful silos that reflect the structure of your product or domain, that can easily be confused with an actual user flow, in which the reality is that users may be jumping around back and forth between your different silos, even if your silos have been organized in an order that generally matches your domain’s workflow.

Therefore, create story maps and use them for all the reasons that they are powerful, but quickly start to generate user interface concepts based on the cards in the story map to uncover aspects of the product that stories, by themselves, often are not very good at revealing.

To be continued…

This post got to be pretty long, so I decided to break it up into two parts. Read part 2, in which I talk about other key factors UX designers should consider when working with Stories, such as story context, story coverage, and story estimation.

Findings from the State of Agile UX Survey

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

The survey was conducted between Oct. 16-24, 2010. We received 150 responses. We are still churning through the findings but I wanted to post some initial findings I thought were of interest. I am still working on a more detailed analysis of the data. If you have experience wrangling Excel (e.g. doing PivotTables) and doing survey analysis, pls do get in touch.

Survey Overview

  • Total Participants: 150.
  • 80 participants identified as being primarily UX Designers.
  • Survey Goals:
    • To understand the level of success in integrating Agile and UX disciplines, and the reasons for the success or failure.
    • To establish a benchmark for future surveys.
  • 18% described themselves as very successful
  • 45% as somewhat successful.
  • Only 5% described themselves as very unsuccessful.
  • The written responses at the end provide some insights as to the reasons behind the success or lack thereof.
  • We received a lot of suggestions for how future surveys could be improved, such as to focus less on web design, focus less on user interface design, or on UX as a role.

Findings in a Nutshell: Same as it Ever Was

The challenges with integrating Agile and UX are not too different from the obstacles one might encounter when integrating a traditional UX practice into a waterfall methodology. Any form of change will meet resistance, logic and reasoning be damned. I remember years ago having to fight tooth and nail to convince management of the value of doing user research and creating detailed wireframes and specifications. The digital world has changed significantly since then, with detailed specs being far less-cost-effective. But resistance to change is the same as it ever was. And integration of Agile and UX is no exception.

Among the reasons for failure, it was therefore not surprising to see cultural resistance at every level (organization, team, peers) as being the strongest pattern. Another major pattern appeared to be going through the motions of change (e.g. doing something for two weeks and calling it a sprint or stand up during meetings and calling it a Standup), but missing the critical underlying Agile thinking, also seemed a strong pattern among those who described themselves as not succeeding.

Not being co-located, i.e. being in the same physical space as other team members seemed to also be a major factor. At the same time, some replied that they were successful despite being physically separated, because they were in regular contact virtually. Another interesting stated reason for failure was that Agile developers seemed to not regard the UX design role or discipline as valuable or important. Remember, it is not just UX designers who are part of this change; the attitudes of developers and the team as a whole is an equally critical factor.

Among the reasons for success, they also seemed to be factors that would make any team successful, regardless of if they are adopting Agile or something else. Many respondents described team empowerment and autonomy as a major factor, i.e. teams that are able to decide how they want to work together and create their own process as they go. Another major pattern was developers seeing the value in UX, or the UX role straddling the developer-designer divide (e.g. a UX designer who also is a front-end dev) were a strong pattern among those who described themselves as successful.

These responses re. the reasons for success seemed to capture the essence of what many were saying:

“For our teams, the UX designer is a dedicated team member – reporting to their product teams. Complete integration with a development team creates a much more successful team dynamic, shared ownership, opportunities for learning and growth, etc, in comparison to having UX as an external team/department.

We have also abandoned the idea that you always should design a sprint ahead, always use certain design methods, etc… Over the years, we’ve learned that there’s not “one right way” to do design & development. Some problems need the extra time to experiment and iterate and others don’t. Some designs need prototypes first, some can be iterated on in tandem with development. We’ve become far more flexible in our approach and techniques, over the years. We learn as we go.” — Alan Dennis

“Everyone talks about how important it is to keep the UX design ahead of the development sprints. I’ve found that this often means that the UX designer is the first to encounter tricky architectural issues. So one thing I’ve learned is that the entire team needs participate in the evolution of the UX design for a given feature or new area. This means that the development team must devote some % of their hours in a given sprint toward reviewing UX design for a future sprint and you have to factor this into the schedules. But if done right, both the UE and any important architectural coding issues are well understood before the story is picked up for implementation. Doing so can help avoid unexpected surprises that cause churn in the UI, features or schedule.” — Robin Silberling

“The UX designer and the Web Develper are part of the sprint planning and we sit next to the back-end Developers. The back-end Developers are very interested in watching the videos of the usability tests. Also they find the wireframes and Agile Acceptance Tests usuful when coding up the windows. We have had quick meetings with the UX designer, Web Developer and the back-end Developer to clarify what needs to be completed before coding starts. All developers are encourage to ask questions and give feedback on the wireframes or any part of the design/coding process. Before introducing the Agile Accpetance Tests the Developers were asked what they thought and if they had any feedback.” — Anonymous

Looking at the Numbers

A key focus here is on activities and process. We–rightly so, in hindsight–got a lot of feedback that we were too process-focused with this survey and were looking at UX as a separate person rather than a literacy. We’ll be working to correct that in future surveys. With that in mind, these were some findings relating to how UX is integrated into Agile teams.

UX-Designer Co-Located with Developers
Nearly 50% of respondents said that the UX designer is co-located with developers all the time. Once we start filtering findings, we’ll check this against those which identified as finding their agile adoption a success.

UX-Designer Doing Front-End Development
50% of respondents identified the UX designer as either regularly (20%) or occasionally (30%) also doing front-end development. Cross-disciplinary roles, i.e. team members wearing many hats is a strong indicator of successful/healthy team (see written responses below.)

Designing Using the Production Technology
45% said they regularly design directly in the browser and only 14% said they had no idea what that meant. If a team is designing in the browser, this is a strong indication that they have a tight integration between UX and dev practices.

The Last Artifact Created Before Development Begins
Detailed wireframes and functional specs continue to hold the lead, with 43% using this as what is the basis for initial development work, with hi-fi prototypes a close second at 33% percent. Only 15% go directly from sketches and whiteboarding to development. This is an area where there still is a lot of room for improvement. In my experience, UX designers continue to struggle with letting go of the deliverables mentality, the idea of UX being one of creating pretty-looking design artifacts before starting to create software.

When Does Detailed Design Work Occur Relative to Development?
Only 8% complete all detailed design work before any development work begins. 50% complete a majority before development. 35% are doing detailed design work in tandem with development. Here again, there is plenty of room for improvement. The idea of not designing everything in atomic detail before starting to build can seem scary to a traditional UX designer. There are probably also a lot of business/org culture/peer pressure factors here that will drive UX practitioners to feel compelled to create all this detailed design up-front.

More Written Responses

Reasons for Success

“UX designer is respected, full member of the team”

“We’re somewhat successful because I think previously we were working with high-fidelity mockups that made it hard to iterate in tandem with developers and design and implement an UX in an iteration or two. We’re now more focused on paper prototyping to give developers the guidance they need around implementing functionality, and designing more directly within the browser within the current iteration. This has been working better, but I think it’s taken a long time to get the hang of UX tools and methods that match the speed of development and iterative methods.”

“We explored the potential of every person & helped other person learn something new. In short we recognized the capability of the team. Made sure who the actual owner of the Story is & made others contribute in the mix. In short, we empowered the team to make decision & requested management solve the impediments & stay out of teams face.”

“The Tech lead is a huge supporter of UX and understands the value. And, if he ‘forgets’ about me at times, he does what needs to be done to get me integrated back in the dev cycle.”

“…the UX desinger has always been considered part of the team. I used to be a FE dev so understand the complexities. Am also a ScrumMaster and attended the training with the developers. Started from the same point. This means I’ve always had very good relationships & high levels of trust with the devs. Always get dev feedback on feasibility and we can all be part of the process.”

“Even though we’re geographically dispersed, we are constantly in touch via an ever-present group skype chat.”

Reasons for Lack of Success

“We have off-shore team, hence bringing them up-to-speed & style is getting challenging. Team here in US still has the mentality that US team is the best.”

“Too many executive stakeholders who don’t understand the value of agile methods. UX team (our client) still focused on producing deliverables rather than working code (site maps, content inventories, requirements, specs)”

“The organization started pure agile and is struggling to integrate ux”

“My organization still views agile and ux as diametrically opposed interests. They still view ux as an upfront activity. My local project teams have a changing view because of their experience working with me, and I hope that view spreads throughout the organization.”

“Front end developers requiring more design detail thus pushing more work onto design.”

“We don’t involve users. We create interfaces that are very flashy, but not terribly useful to the user.”

“The lack of co-location and general “design” think is the biggest barrier.”

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

Designing beyond the surface layer

Designing a user experience is usually considered synonymous with the work of designing the part of a system users will directly interact with.  While that is all good and well, a general problem I see in the UX practice is that this then becomes the place where the UX work not only begins, but also where it ends.  In other words, the underlying functionality, the components that actually allow for the interaction being designed to function is either completely ignored or only given cursory consideration from a UX perspective.

This lack of attention to the impact of the non-visible aspects of a system on the user experience is, in my opinion, a major reason for a lot of bad user experiences.  If you think about it, if your page is slow to load, if you try typing into a text field but nothing happens, if some seemingly simple action in the UI in fact initiates connections to a bunch of data sources and causes whole interface to become sluggish, who cares how perfect your UI design is?

I think a lot of UX designers shrug their shoulders at issues like this.  Hey, that’s the developer’s problem not mine, right?  Yup, definitely the developer’s problem, just like the proverbial leak on his side of the boat is his problem and not yours.

The issue here is not one of who is responsible, rather one of an awareness that it may critically impact the user experience, and therefore the User Experience design process should be one that allows for surfacing the issue and addressing it.  Current conventional methods of UX design, i.e. focusing solely on the user interface first, then waiting to deal with pesky issues such as load time later is only likely to ensure that those issues get relegated to the revolving “Phase 2” version of the application.  A better way to address this is to rethink the relationship between UX design and development, and a great example of that is to evolve the GUI in tandem with the software build.

An Agile UX Method: Functionality First, GUI Second

The idea of designing the user interface in tandem with the build is a good example of applying Agile thinking to UX.  Here, instead of first creating some fully formed interface concept before starting to actually implement it, we take a step back and look at what underlying functionality needs to be developed.  In cases where it makes sense, such as a piece of  functionality that may be simple at the user interface level  but where there may be some heavy lifting on the back end, rather than spend a lot of time at the outset trying to come up with the perfectly user-friendly UI, we instead abstract out what inputs the user will provide and what outputs the system must return and then create a minimal user interface, of which the most standard is the command line interface.

Example of a minimal user interface, showing only user inputs and outputs

Example of a minimal user interface, showing only inputs and outputs

Here is an example of an auto parts search, in which we know that actually connecting to the various parts warehouses and then executing the search is going to be highly complex.  Therefore, before spending a bunch of time designing a GUI, which will need to make assumptions, for example, about the amount of time that will be required to complete a search, we instead start by building a first iteration of the search functionality and use a skeleton user interface.  With the knowledge of the actual average time of completing a search, as well as issues related to connecting to the warehouses, we are in a much better position to build a graphical user interface around this, in which we can clearly set user expectations, as well as determine much more effectively what forms of dynamic features in the UI we can support, such as how much flexibility we can allow for in terms of user inputs. (I.e. maybe we discover that Name needs to be a separate field from ID or whatever.)

This can be an incredibly powerful way of working, since it actively and organically involves developers into the design process, allowing you to collaborate much more closely in evolving the user interface.