OK. Not what I was shooting for – and it really needed another rev. After printing and sending it out, I now have a ton of stuff that I’d like to do to it…but, this season’s been so busy – this is what everyone got. Click it to view full-size.
First – an observation about client/product management feelings about agile, at first blush:
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:
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.
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?
Recent Comments