Inside the IA mindset

This morning I braved the gale force winds and driving rain (seriously) and headed in to Bristol city centre to attend the World IA Day event that Nomensa were putting on.

I was lucky enough to win a freebie ticket on Twitter yesterday and if I’m honest until then it hadn’t been an event I was intending to attend. I went to an earlier edition of this event a couple of years ago and found it too theoretical for me (apart from a session by Leisa Reichelt, who is now Head of User Research at GDS, which I found useful and insightful in its outlining of the role of user research in a multi-disciplinary delivery team. Essentially introducing me to the GDS model before there was a GDS.)

This morning followed pretty much the same pattern as last time. In fact it even had the same opening keynote speaker. I only stayed for the morning session and of the four talks contained in that period three of them did not really click with me at all. However the third made the early morning soaking worthwhile (though maybe not the second one on the way home!)

Dan Ramsden, a UX Architect from the BBC, gave a great talk about the #iamindset and how that fits in to the use of ‘design sprints’ and ‘service design’ techniques to identify, prototype and test new products (or new versions of existing products.) It was one of those talks that immediately started to make sense in the context of the work you are doing and I was immediately making connections in my head and working out how to juggle things to make room for this approach.

The idea of ‘design sprints’ seems to have been popularised by Google Ventures and it really is an interesting approach.

It basically breaks down as an intense 5 day workshop with a multi-disciplinary team – heavy on the UX continuum of skills and subject matter experts – where you work through user-led design challenges in a (very) rapid manner.

Day 1: Understand
Dig into the design problem through research, competitive review, and strategy exercises.

Day 2: Diverge
Rapidly develop as many solutions as possible.

Day 3: Decide
Choose the best ideas and hammer out a user story.

Day 4: Prototype
Build something quick and dirty that can be shown to users.

Day 5: Validate/Test
Show the prototype to real humans (in other words, people outside your company) and learn what works and what doesn’t work.

The BBC approach focuses heavily on creating stories. Real stories beyond just the standard agile ‘user stories’. More like scenarios for their personas. Personas being something else they lean on heavily, borrowing from the ‘service design’ model. They tie these stories in to the needs and motivations of those personas (something I was talking about just last week after the great persona work we just had done by PureUsability.)

They break the stories in to ‘pages’, ‘chapters’, ‘books’ depending on the scale/complexity (kind of like stories, epics and themes in agile I guess?) and then work up quick sketches, peer review them and eventually end up with a couple of ideas to prototype and then eventually user test (with real users from outside.) Throughout the sketching and prototyping work the team is also working up test scripts etc in the background – test driven design!

Using service design methods like ‘life cycles’ and the ‘blueprint’ they are able to map these prototypes etc in a wider context (i.e. the wider website) and this not only helps generate ideas by identifying gaps but also helps act as a record of the work.

It is a technique that obviously lends itself best to discreet problems/needs rather than larger issues but I can already see how many of the things we are facing can be chunked up in to appropriate sized elements to attack in this way and that actually this might be the missing piece to the approach we have been building around user research/experience. We have been generating more and more research but have been struggling a little in turning that in to actionable ideas and this seems to give us an opportunity to do that.

Now I just need to carve out five days time for the team and find a space to work in!

So thanks Dan and enjoy your biscuit on the way back to Salford!

**UPDATE 16/2/14** Dan has posted the (very comprehensive) notes from his talk. Well worth a read.

2 thoughts on “Inside the IA mindset

  1. Thanks so much for writing this summary – it’s reassuring that it matches what I wanted to get across. One thing I probably didn’t stress is that this is a five stage process – and doesn’t necessarily require a full five days.

    Although at the BBC we often do this over five days, as in the example I talked about, the model can be applied to a shorter process. It’s sometimes difficult to get the right people for the full five days, and we’ve found that dipping in and out of the process doesn’t really work (without a really good a handover). But we have experimented with shorter sprints – covering all the stages but playing around with the format. Things to consider is how guerrilla testing techniques might enable you to save time or combining days [possibly the diverge and converge days(?)].You could even have a mini-sprint to refine your approach to the process. You need to find a way where the process works for you and your team. The structure helps, and it’s a pretty intense process, but if you’re struggling to get ‘buy-in’ or find the time, don’t be afraid of playing with the length of sessions.

Comments are closed.