NoTube blog – the future of television is social and semantic

In praise of swimlane diagrams

Posted in Meetings, Thinking Out Loud by vickybuser on January 20, 2010

As an Information Architect (IA) I often make diagrams of various kinds – usually user flow diagrams, sitemaps and wireframes. However, I’d never made use of swimlane diagrams until the most recent NoTube project meeting.

Commonly used for diagramming business processes (sometimes in a humourous vein!), I found this visualisation technique to be an extremely useful, simple and versatile tool for helping us to show how all the various components within Notube need to fit together and influence each other to support our scenarios.

The scenarios (descriptive stories about a user’s overall experience) supplied the context and background – the next step was to map these stories to a sequence of discrete ‘activities’ grouped by component to show what happens and when (as others have suggested, a more accurate name for this type of diagram might be a Scenario Description Swimlane). During the script writing activity described by Libby the ‘actors’ and their ‘lines’ were mapped to a swimlane diagram drawn on a flipchart by Chris van Aart from VU helping to clarify various issues along the way.

As the name suggests, the diagram looks like a swimming pool with lanes. Each NoTube component (service, tool or system) was assigned to a lane – we started with a lane for the user interactions implied by the scenario. The activities performed by each component were represented as boxes within the relevant column and connected by arrows to show the interconnections. Our lanes were arranged vertically so that time flowed forward as you moved down the page (but they could also be laid out horizontally). So – really quick and simple to do once you have the right information: the main challenge was not to make the diagram look too messy when drawing arrows across several lanes.

Swimlane diagram detail

The resulting diagrams provide a set of documents that show everything going on at once – at a glance – helping us to understand:

  • the tools and systems involved
  • how the user interacts with the various components
  • which components are responsible for which activities and the flow between them

An extra bonus for me as IA was that I could use the diagrams to quickly identify the screens that now need wireframing.

As Yvonne Shek says: “The goal or differentiating factor of this diagram is to tell a story from multiple perspective, in a comprehensive and holistic way.” I’m sure I’ll be using this handy technique again in future, in particular to promote common understanding between participants of a large and distributed project such as NoTube.

Writing scripts for teasing out requirements

Posted in Meetings, Thinking Out Loud by libbymiller on January 15, 2010

The Problem

We were looking for ways to bring out the full implications of our ideas for scenarios to check that they were implementable and work out how we would implement them.

This is a very common problem, and we have looked at it using various tools including writing scenarios, storyboarding and so on. We had a rough idea of the technical components we needed and what we wanted to demonstrate. But for me there was a lack of clarity about precisely how the scenarios would play out, and so we started to look at ‘swimlane’ diagrams like these, to illustrate where in the architecture the action moves as the scenario plays out.

“Like a rather boring play”

These diagrams are actually pretty hard to write, but useful if you can do them, as you start to understand what components needs to talk to what and what they need to say. Danbri had an idea that we thought might help for writing them – to create a script – like a script for a rather boring play – with the technical components as well as the users as characters, to see if this would engage our storytelling faculties to help bring out the nuances.

“But the set top box just woudn’t do that”

This made for an entertaining meeting where different meeting participants took the roles of different technical components, and I played script editor, making choices where there were disputes. I think there were several benefits of using this process

  • better mutual understanding of the scenario itself, including discovering more about what could and ought to happen
  • better participation as different project members became champions for different components (‘yes I’m the recommender!’)
  • you didn’t need to be technical to join in and the result was something that everyone can understand
  • quite a fun (by EU project standards) meeting

however -

  • this is a time-consuming thing to do and we didn’t really have enough time set aside
  • it needs participants to be interested and care enough to join in
  • it needs more careful planning than I did for it (such as a draft script written ahead of time), and a dedicated person to take notes, as Chris van Aart very kindly did in our session

It would be very interesting to talk to people creating real plays to see what we could learn from their processes.

You can read our ‘rather boring plays’ here, and I hope that Vicky will do a post shortly about the swimlanes she has created as a result of this process.