Warning: Declaration of description_walker::start_el(&$output, $item, $depth, $args) should be compatible with Walker_Nav_Menu::start_el(&$output, $item, $depth = 0, $args = Array, $id = 0) in /home1/mapbutch/public_html/blog/wp-content/themes/SCRN/functions.php on line 268

mapbutcher

Mapping…….user scenarios

Posted on 02 Apr 2013 in loin | 2 comments

Too many web mapping applications are built on the back of requirements documents which are entirely misguided and miles away from any real user need. In the case of web mapping applications developed in traditional GIS organisations (utilities, government, engineering etc) this  ‘classic’ approach to servicing user needs is often lead by the GIS ‘Professionals’ who in my experience are unfortunately the most ill equipped set of individuals to do such a job. Where user requirements are specified in this manner and GIS ‘Professionals’ act as the user proxy disaster inevitably awaits. If you have to ‘specify requirements’ for tendering I’d encourage you to attempt to focus on expressing the intended value your users will gain from a particular feature of the mapping system. For example instead of specifying a requirement like:

The user should be able to select features on the map and query other layers based upon their selection.

………………you could try and suggest the value of such a feature to a user:

 A user needs to be able to know what overlays exist against a planning application so they can quickly and easily inform the interested party of their obligations.

By expressing the requirement (or user story…if you like) in terms of how a real user will value the feature, it provides us with a much richer insight into the system’s purpose. This brings me around to the subject of this post. How do we work with requirements once they are expressed in this way? This week I worked with a team who used a technique called User Scenario Mapping. The team took a series of user stories and began to work with them to help us understand how a user could work with a system to achieve their goal. It’s a very effective technique and I encourage you to give it a shot. Let’s use the example above and see how it works.

Give the story context

I like attaching real people to user stories. I find it helps me attach a piece of value I’m working on with a person who will use it. It moves a feature from being abstract to concrete. As well as the who, there are the other obvious aspects like the what, where, why and how often which can be useful – our user story above is pretty close, but we’ll make a couple of changes:

Jim from the planning section at Bawbag Council needs to be able to know what overlays exist against a planning application so he can quickly and easily inform Barry the builder of their obligations.

What steps will Jim take?

We have our overall story, but now we must walk through what we think Jim should do to achieve his goal. The most effective way to do this is to place a post it note on a wall for each step Jim will take. Under each post it note you will record any comments, questions, assumptions or ideas that you have regarding each step. It’s a good idea to record these things on different coloured post it notes. Lets take the first few steps as an example:

  • Step 1 – Jim searches for Barry’s planning application on the map page
    • Question: What information does Jim have to help him find Barry’s planning application?
    • Question: Does Jim need to search on the map page?
    • Notes: Jim does this every couple of days for different planning applications
  • Step 2. Jim can view the extent of the planning application on the map
    • Questions: How should the planning application boundary appear – should it be labelled?
  • Step 3. Jim can see the summary of the overlay information effecting the planning application
    • Note: Summary information should contain overlay description, type and effected area in meters
    • Note: Jim should be able to see further details for the overlay if required

…you get the picture. We don’t assume any solution at this point, but we’re trying to establish the logical steps a user like Jim would go through to meet their goal. When you’ve completed these steps you end up with something like this:

You then repeat the process for each user scenario you want to map. Don’t be confronted if you have a lot of user stories. This process can be done incrementally and it’s time well spent if the outcome is a system which is effective.

By working through a user scenario in this way I found that it helps identify the typical assumptions that we make when designing systems. Another useful outcome is that it helps you attach value to each step a user will undertake. Taking our mock example above, Jim simply wants to find out as quickly as possible the answer Barry needs i.e. what overlays are effecting his application. If we take the requirement as its first stated and don’t do any user scenario mapping we are likely to arrive at some god awful spatial selection tool solution, however by spending a small amount of time using this technique we focus in on what’s important to our user and can dispense of any GIS baggage we may have. In the wise words of Plex ‘Try It You Might Like It’. For more info this is also a useful post

2 comments

  1. Paul Ramsey / April 3rd, 2013 3:22

    Super useful. One thing often missing even from generic user process stories is frequency and prevalence. Applications have an 80/20 pattern, and knowing which use is the 80 portion is a huge win out of the gate.

  2. mapbutcher / April 3rd, 2013 6:14

    Paul. Agreed, understanding frequency of use is critical – I’ve previously used a technique called Story Mapping which maps user stories at a higher level. You can read about it here. When doing story mapping you can explicitly mark each story card with an indicator to show its criticality i.e. seldom used, always used, then you arrange cards in the order of use (similar to scenario mapping) – what Story Mapping is very useful for is allowing a team to visualise a set of critical features which spans the overal use of a system.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>