Agility in Experience Design Process – What’s Next? (Part 1)

16 Jan
2009

I’ve been working on how to make our services, as Experience Designers, faster, cheaper, and better. (Good Experience Design for all!) I’ve ran a few agile software development/product development projects in the past, with much help from some great “coaches.” However, there are several major pattern problems with doing what we do in an agile environment. I’m exploring some solutions.

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?

4 Responses to Agility in Experience Design Process – What’s Next? (Part 1)

Avatar

Kirk Thoughts » Daily post (weekly)

January 17th, 2009 at 5:37 pm

[...] Tim Richards’ Experience Foo » Blog Archive » Agility in Experience Design Process – What’s Ne… [...]

Avatar

Michael Betts

January 19th, 2009 at 8:08 pm

Tim, glad you’re exploring this in the context of design. Hypothetical question for you — how do you know when to launch? Most of the big brands aren’t willing (scratch that…would need to be powerfully convinced…) to launch a site that could be construed as half-baked. Have you considered setting a benchmark or guidelines around this? And what has been your experience with prioritization. Do you set a limit and say we’ll get whatever’s most important that we can launch in say, 6 weeks? Or do you push out the most important features first, even if they take longer?

Avatar

Dutch

January 21st, 2009 at 5:06 pm

@ Betts

Before you kick off, the clients needs to buy into the benefits of early launches and needs to embrace the drive for a minimal product that delivers the required experience.

It’s possible it’ll take a couple of design and dev cycles to bring you to a release where you and the client are confident the experience is complete from the user’s perspective. The drive here is to be emperical and let users tell you whether the experience is “baked”.

I would argue that if client’s brand values include minimizing waste, maximizing value or dialogue with the user base, early launches would be a great way demonstrate these values. Early launches could include launching on beta sites like google and yahoo do.

The most important features should drive the site’s experience. Hence, I would always push for including these in the earliest possible launch.

Avatar

Ray

February 9th, 2009 at 2:33 pm

Great stuff Tim. Where’s part 2?:)

Comment Form

top