Local Traffic Policies

My Role

I conducted all facets of the redesign from start to finish, including: project scoping, requirements gathering, technology analysis, information architecture, user task flows, interaction flows, prototyping, and development. I also conducted user research using methods such as interviews, surveys, and frequent design reviews in order to address both user behavior and attitudes.

The Problem

We started with a data driven GUI, designed to allow developers to quickly add new rule conditions. This design made no attempt, by admission of the original developers, to approach the problem from a user’s point of view. As a result the feature suffered from minimal use due to its confusing UI.

The rules page represents a classic condition of forcing the user to fully understand the inner workings of the feature in order to configure a policy. In this case, the schema object used to define a rule was translated in its raw form into graphical elements.

Constraints and Limitations

We were constrained to the general look-and-feel of the existing system. While we could introduce new work flows and new patterns, they were required to look familiar and feel that they belonged as part of the larger product.

Our ability to alter the backend was also limited, though not totally restricted. For example, we were able to introduce the concept of “staged policies”; but we were unable to change the data schema, or introduce new comparison operations (‘and’, or ‘or’ concepts) where they didn’t previously exist.

Our Process

It was important to earn trust when starting the new project relationship. I ran several high level heuristic evaluations on the existing GUI and walked through issues with developers at a weekly design coordination. This allowed me to build a positive working relationship, by bringing the engineers into the conversation and treating what existed with respect.

The initial meetings allowed me to provide respectful feedback while seeking out and accepting feedback on why original design might have been done the way they were. The idea of focusing the process around the user was still foreign to many engineering teams; it was vital I communicated regularly about the status of the project.

Design action where guided by user input. Ten functional use cases were created and a baseline set of metrics were critically evaluated as a group.

The Result

The Traffic Policies feature was very underutilized, so I had to make a lot of decisions in the face of ambiguity and uncertainty. I spoke with users to provide clarity to the situation on how they think about the problems they are trying to solve, asking them to describe the rules and listening to how they constructed them verbally.

I was able to identify and deliver a simplified solution in the form of a natural language rule editor. Each rule represented itself as a sentence that could be read and understood by someone who had no previous experience with the feature.

This allowed the editor to speak to the users, as they spoke to me. The user and the system were not speaking to each other and could now more easily collaborate.

The same ten use cases were evaluated using the new collaborative interface.

The reduction in time to complete, abandonment, and error represented a significant improvement over the original design.

Next Steps

User testing was conducted again on the same ten use cases to see how the updates faired.

The results demonstrated a significant reduction in time, along with the elimination of abandonment and errors in the policy creation process.