Starting A Design Project
Needs Assessment
The beginning phase of any system design activity should take the form of some type of Needs Assessment (also frequently referred to as "Requirements Analysis"). This is the stage of design work where you take stock of what already exists, what your users need, and in what context your system will operate. It is really important to spend some time up front identifying what constraints should shape your system design - missing a key task or output requirement in this phase could be quite costly later on after development begins. In fact, there are whole companies and comprehensive methodologies that specialize in identifying system requirements.
There is a wide range of methods for conducting needs assessment studies (focus groups, surveys, literature research, etc...), but, in this lesson, I want to focus on two methods in particular that I think anyone can do, no matter how limited time and resources may be for this critical stage of design. Scenarios outline a story in which your system plays a key role, and Personas describe the types of users you expect will use the system.
Scenarios
Scenarios are a very popular entry point for the design of virtually every type of system. The idea behind scenario-based design is that you (the designer) concoct a story that describes the use and context of a new system. Most of the time, we already have a scenario in mind as we begin working on a design project, but true scenario-based design requires the structured development of one or more narratives that describe in detail how a system will be used. One of the academic pioneers of scenario-based design is Jack Carroll, a Penn State professor of information science and technology.
The most common method of scenario-based design (there are many flavors, and here I'm just going to cover one of them) features two key stages that I want you to understand - 1) development of a narrative and 2) claims analysis.
A typical workflow for writing a scenario starts by describing the current state of the art in narrative form. So, let's say you're in charge of designing a new web mapping tool for sharing zoning information with local government officials and members of the general public. We'll assume, in this case, that currently your organization keeps this information in a desktop environment and disseminates this information by responding to requests for specific maps. So, you would create a narrative that describes how a typical user would get the map they need using the existing system.
Then, once you have outlined the current state of the art, you write a separate narrative describing your vision for a future system that improves on the current system. In your scenario, you might have a map request handled by a web service that pulls data from a server and compiles an easy-to-read and printable map in real-time, delivering it within seconds to the end-user. A scenario works best when it has detail and context that connects it to reality - here's my take on a short scenario for the zoning web map example:
Alexandra is looking for a map of her neighborhood so she can better understand the proposed changes to the use of several large pieces of land near her house. She clicks the link to the county zoning map website, which launches a web mapping tool that connects in real-time to key base layers housed on a server. Using only her web browser, Alexandra is able to quickly browse through a set of commonly downloaded map types (zoning maps, reference maps, topographic maps, etc...) and selects a zoning map as her desired output. Then, the web mapping tool asks Alexandra to select the area she'd like the map to center around. She can choose this area by typing in her address or by using the mouse to draw an area of interest bounding box. Once she has selected an area of interest, the web mapping tool asks Alexandra which output format she would prefer (PDF or Image) and the delivery mechanism (web link to the file or email attachment). She selects a PDF to be emailed directly to her account.
This is a fairly short and less-detailed scenario, but hopefully, you get the idea. In many cases, it will be a good idea to write up multiple possible scenarios for the new system. Most GIS tools these days are not one-trick ponies, so there will be a variety of possible uses, and you'll want to plan for each of them in advance.
With narratives in hand, the second key part of scenario-based design is to conduct claims analysis. Claims analysis involves going through your written scenarios to identify which things you have claimed the user will do, and which things the system will support. Basically, you are formalizing what you have written in the narrative - condensing everything into short statements that can be considered "claims."
For example, in the scenario I created above, one claim would be that the web mapping tool has a "wizard" feature that asks users questions to help them make choices among map types, extents, and output formats.
The claims analysis then involves taking each claim and identifying positive and negative reasons for supporting that claim. A positive reason for supporting the wizard approach might be that scientific evidence shows that users perform better when using wizards for complex tasks. A negative against using the wizard approach is that it would take a lot of time to develop a custom interface that would suit all task types. Conducting claims analysis can help your project team decide what to tackle and what to leave behind after you've developed scenarios.
Personas
Personas go hand-in-hand with the development of scenarios. Simply put, a persona describes a typical user profile for your system. In the GIS context, there might be multiple relevant personas -- for example; a spatial analysis expert, a decision-maker, and a public user. Developing personas is somewhat like developing a scenario since you need to construct a narrative that describes a typical user, their needs, the experiences they bring to bear, and the context of their work.
Here's a brief persona for Alexandra, the subject of my short scenario above:
Alexandra is a 34-year-old accountant for a mid-sized company. She has a bachelor's degree in accounting and uses technology on a regular basis at work. She is an engaged community member, always attending local planning board and city council meetings to share her opinion on the direction of development projects in her community. Alexandra is a frequent user of local government websites to obtain information on upcoming meetings and proposed plans.
Developing personas can help you crystallize the types of users you need to support with your system. No doubt, you can imagine many other possible personas I could have described given the type of scenario I generated earlier. A web mapping tool that would be used by the public would have a lot of different audiences, each of which should be considered during the system design phase.