• When you tell a stakeholder that “so-and-so” feature won’t be making a release, they become very sad…if not angry. 
• However, if you show a stakeholder that the feature is on the roadmap, just below the other, more important stories/features, they feel a certain comfort (compared to the sadness or anger if the feature is removed from a release. 
• Last, when a build is released to customers without low-priority features, I think stakeholders feel Relief…relief that additional resources weren’t spent on releasing such a low priority feature. Eventually, the stakeholders who used to start projects with long lists of “must-have” features should feel happiness that the backlog is serving as idea management…making sure that the worst ideas aren’t getting built – only the best ones.

So – I think a major help in getting to a more agile design process is to start thinking in Experiences – not pages. So, here’s a Scenario Map – where we can aggregate the needed functions, stories, content, and structure of steps in a process – across many user types. Hopefully, through some sharp scenario design, we can represent many users’ needs across a set of interfaces, and then design those interfaces – with the new vision in mind…not just a content audit in place.

Next, here’s a format example for Scenarios – what I think will be a major help in quickly defining ideas and experiences – instead of working from a list of “pages” that need to be designed. I’ve spoken of scenarios before – here’s a concept of one – where we define Who…a bit about the user and their situation, What…what content and services are needed to fulfill their perceived need, How…how the brand fulfills the need, and the…well, Do…what the brand does…or what experience is offered to the user.

Next, I wanted to share the takeaways of what I think make up the ideal stakeholder mindset for doing Agile Design:

• At the beginning of a project/cycle, don’t start with a list of features that all need to be built; be open to the idea that better ideas will be conceived during design/development/prototyping, etc.
• Put into perspective what features (or tasks or needs) are most important to the user/customer – understand that meeting/exceeding those for the customer will create a love affair between the customer and the brand that provides the experience;
• This one is a tough one – we may not know the price related to a release, yet. Moving parts of the project, like team size, accompanying burn rate, build velocity/capacity all need to be discussed without discussing (yet) the features to be built. The idea is, traditionally, that a stakeholder provides a budget for a product release…and that will fuel a certain number of cycles of a specific team/cost structure, including build/release/etc.In order to solve this, a design backlog probably needs to be built – allowing development/release to draw from a story list that is well-defined, more easily estimated against. So – stakeholders prioritize once to design/conceptualize – and prioritize again once the stories have scope related to them – and capacity/velocity is known. This starts to feel less agile, but more manageable from a stakeholder standpoint.Who’s got great stories of on-time, on-budget releases of agile projects? What are the deltas between the initial feature list and the “built” list? Anyone using design backlogs?

Last, I’ve seen some great results in design sessions when we get much more aggressive about designing experiences around what a brand should do, riffing off recent thoughts on “Brands Do” by Garrick Schmitt and his merry troupe of Experience Planners. In addition to building great IA in content portals, we need to help brands “do stuff…” What’s the embodiment of the brand online? What starts to emerge are conversations, transactions, and elegant interactions…much more participative experiences. Now, with participative interfaces, brands are faced clearly with the challenge to “do…” not just publish, watch, release, etc.

In any case – continuing the conversation on Agile design, there have been quite a few comments related to whether clients would be on board with Agile, etc. The comments and experiences shared with me have fueled more thought. These were just a few quickies on the subject.

So, since posting some thoughts on UX Agility, a good friend of mine (Mr. Hungry) pointed me to a report over at the Norman/Nielsen Group that looks really good. I don’t have it yet, but trust me when I say I will be digging in. I wonder how far off their conclusions I’ll find myself. I have a feeling I won’t be surprised, either way.

So – what happens when we try to do Experience Design in an agile manner? Well, again, I’m not anywhere near complete, yet. But, here are a few sketches and ideas. More to come.

First, what is an agency’s role in Agile Experience Design? Well, an intent and goal should be identified. Plenty of companies already know how to do this – and do it well. Once we know intent and goals, we can go after describing our target audience, demographic attributes, targeting strategy…we write a brief…or several of them, we document our impressions and ideas – and there’s usually a fair amount learned from analytics.

So – with intent and goals clarified, we should be able to provide audience information and start forming ideas around what kinds of content and/or services will be provided to the audience. Now – when we’ve got an ongoing relationship with the client, we can do this continually. If we’re just doing a project, maybe we do this once. Maybe we get real lean about doing this, if we’re constantly doing projects.

So, in a waterfall situation, we might take that first step, and make it a big Discovery period…hoping to set a scope for the rest of the project. What if we did it constantly – or iteratively? Well, for one, all those briefs and ideas and targeting and such…well, they take time. I haven’t tackled it here, yet…but, I’ll be digging into what this service model might look like, if we were more agile.

So – what do we do with our audience + content/service set? Well, what I’ve been having my teams do lately involves creating scenarios…lots of them. We write a scenario title, and track them in some sort of spreadsheet. Every scenario is made up of the following:

• Persona (referenced here…not created or viewed in full here)
• Persona Backstory (realistic situation to set up a user need/desire/disposition)
• Narrative Story (realistic, but new way of the user fulfilling their need, using new experiences, content, or services)
• Low Fidelity Schematics (for each step in the story, provide an interface SKETCH)
• User Needs/Desires (track what the user wants or needs…there can be many of these…they play off each other)
• Need Fulfillment Tracking (show gradual, partial, and complete fulfillment of need/desire, per step in the story)
• Content/Services Inventory (per story step, list what content/services are shown in your schematics…what is needed for that step to occur)

I’ve been trying to keep these to 6 steps or less…instituting a rule that anything bigger must be a series of needs. I also have high fidelity versions of these…but, I’ll share those some other time.

So, we take our scenarios – and we do a bunch of them. We have the stakeholders, product managers, and other personalities help prioritize these. These are great, because multiple scenarios can use the same UI, page, or feature…but, each stakeholder group can describe their audience, content, or service differently, from story to story. Scenarios are a way to “show our work” in experience design…and they’re pretty lightweight.

Once we’ve got enough scenarios to describe the features that would make up an Agile Story, we can group them as packages – and we’ve got the beginnings of something we could give to a presentation layer developer/designer.

So – quick pause here. Why Agile? Well…I think that there are a few reasons:

• Faster. We can get a product to market faster if we build only what’s needed, launch, observe, and iterate;
• Cheaper. Well, this uses the previous principle, and assumes that we’ll only design and build what’s needed (first), and get to market. Since many features of any experience are often unused (more on this later), we can avoid waste, and spend money building the most important features, services, and content for the user;
• Better. Getting to market earlier, observing, and tweaking means learning more about what people love and hate about the experience you’re delivering. Also, Agile (not sure why I’m capitalizing) means making decisions, allowing for change (requiring it between cycles, in fact), and probably NOT building (ever) the lowest priority feature that would otherwise be in scope…you see, if it’s low priority, it won’t make it into an iteration…everyone has ideas constantly – and chances are, better ideas will come along, and cause those lower priority features and ideas to remain out of the product. Software Darwinism?

Enough on that. I’ve amended the title of this post to carry the “Part 1″ moniker. I’ll follow this up a bit later with a second installment, including links to references to Agile (again with the capitalization). Next time, I’ll cover:

• How do we estimate for it?
• Is it right for every project?
• What does the perfect dev handoff look like?
• What do customers actually want?
• And, other exciting topics…

Any great examples out there of leaner design approaches? Anyone working in an agile environment for experience design?