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.
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.
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:
…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