First – an observation about client/product management feelings about agile, at first blush:

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