Changing the Game, for Game Wardens

Spire Digital
Oct 26, 2015

The Problem

This isn’t a digital process yet?

The primary role of a game warden is to monitor a geographical territory and ensure that hunters and anglers have the appropriate licensure, and depending on the time of year that procedure could occur several hundred times in a single day. For the state of South Dakota this process was entirely analog- as officers were physically verifying that licenses matched the individual’s identification.

To put it simply, this process took a long time. Wardens may be checking a group of 20 hunters at a single time, and every minute that went by was time lost for both the wardens and the hunters.

The bigger problem was that hunters and anglers were cheating the system. A fake license could be printed with some amateur photoshop skills, and the wardens would never know. There needed to be a way to instantly verify that a hunter or angler had a valid license.

 

User Interviews & Observations

The Spire team spent two days in South Dakota interviewing and observing a handful of game wardens, hoping to better understand their work environment, process, problems, and goals.

After 2 days, my sketchbook was filled with various notes and observations.

The first day was a combination of 1:1 and group interviews to ensure balanced feedback. I probably asked more questions then I needed to, but it was important that we knew as much as we could about their daily workflow, specifically their pain points.

 

“I’m always keeping an eye on my surroundings, regardless of the situation. My top priority is always safety.”

 

The second day was purely observation. It was incredibly important to observe users in their element, as there are always differences between what users say in interviews and how they act in context.
One of the beauties of contextual observation from a designer’s standpoint, is that we are given the opportunity to observe and analyze the project/interaction/workflow from a completely new and objective standpoint.
In addition to the primary process of checking licenses, we discovered officers were manually documenting and sending the state of South Dakota various information for every license check at the end of every shift. The data was critical from a resources standpoint. We saw this as an opportunity to incorporate this information into the new and improved license check process. While secondary to the primary project goal, this feature would eliminate busy work and eliminate inaccurate data caused by human error.

 

The existing license-check process: “This looks accurate. I think…” Photo: ND Game & Fish

 

A few design takeaways from the interviews and observations were:

  1. Thumb dominated tasks. Being able to use the app with one hand is a priority, as wardens are often holding other items.
  2. Big Font, easy choices. These users are not tech savvy, and many of them have difficulty seeing size 16 font on a smart phone.
  3. Hide or layer secondary information. Only show what is absolutely necessary during license checks, and make choices easy for the users.

 

Architecture

After discussing and reviewing feature requirements with the product owner, designing the navigation became the next task. We usually start with a site map or screen flow diagram for a project like this, but because this application had such a specific purpose I wanted to ensure the navigational patterns supported it.
A flat architecture meant that important content and features were never far away. I played with a handful of different models, ultimately settling on the “nested doll” approach, as the linear structure best suited a task-based application.

My users were NOT tech savvy. Navigation had to be dead simple.

My users were NOT tech savvy. Navigation had to be dead simple.

 Application site map. How could we make the license check process as efficient as possible?

 

The License Check Process

This primary workflow needed to be efficient and intuitive for game wardens. For each screen in the process we sketched multiple iterations, looking for simple solutions that were devoid of clutter and focused on the task at hand.

The Result

Game wardens carry and operate an array of tools, and we wanted this application to feel like another piece of dependable equipment in their arsenal.
Don’t think, swipe. Wardens were worried that it may be too difficult to make an emergency call in a critical situation. The design revision placed the emergency feature within a hidden drawer accessible by swiping left on any screen. This gave officers access to this highly important feature without needing to look down at their phone.

Layering information allowed officers to only see what they wanted to see at that given moment. Designating “information screens” from “action screens” allowed wardens to make faster and easier decisions.

This app needed to allow game wardens to confidently scan hunting and fishing licenses out in the field quickly.

Because the user feedback and architecture was first structured around the license checking process, we were confident the interactions and functionality solved the unique requirements for the South Dakota Game, Fish & Parks Department.

Lessons Learned

Prototypes > Wireframe PDFs.

Especially for linear task-oriented applications, linking screens together with a tool like InVision makes much more sense than static wireframes and lists of annotations. Design feedback loops are quicker (both internally and with user testing) and communication with the development team becomes much more efficient. This was one of the last projects Spire leaned heavily on documentation, as we have since fully committed to lean prototyping, and pairing designers with developers.

Focus on goals, not features.

It’s much easier to define features in a vacuum than to match the right solutions to the right problems. Users often describe the features they would like to see- but they’re only offering a solution they are familiar with, to a problem they may not fully understand. Fortunately, our initial user interviews and observations focused on user goals, and we were able to discover and solve problems along the way without blowing up the project roadmap.

Creation vs Discovery.

Initially, the project was not scoped for initial user research and observation. We were handed requirements, and expected to deliver a “well-designed” product. As a designer working in a hybrid agency/consultancy, we are tasked with creating exceptional products and expected to provide valuable insights along the way. But those insights are rarely “aha” moments of greatness from gifted designers. They are a product of designers engaging with users to discover solutions, and sharing that feedback openly and consistently with clients to create exceptional products.