The Tim Richards Experience Experience
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:
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:
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:
Any great examples out there of leaner design approaches? Anyone working in an agile environment for experience design?