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 heuristic evaluation of the original GUI is shown below. The most common use case, creating or editing a policy rule, is highlighted.

Traffic Policy List Page - Original

The policy’s details page was the first example of off-loading all configuration requirements onto the user. No effort was made to automate any configuration that could be easily determined by the system.

Traffic Policy Details Page - Original

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

Traffic Policy Rule Page - Original

The Process

Our primary means of design iteration was a twice monthly meeting with a small focus group of 5 customers, 3 who used the current policy GUI design and 2 who avoided the GUI but used different methods to achieve the same results. Project management, back-end and front-end developers, and the feature architect where also a part of this meeting. A total of 8 meetings were held over the course of release window. During each meeting we reviewed design considerations and walked through various use cases to refine the interaction.

This process was rather foreign to the development team.

The first 5 meetings were presented primarily through wireframes and workflows, generated in OmniGraffle. The final 3 meetings focused around like prototype demonstrations and updates to the interactions.

When reasonably satisfied, we switched our focus to user testing. A total of 7 user tests were conducted with customers who did not currently use the traffic policy feature but had expressed interest in doing so. All participants had used different configuration methods to achieve similar results.

Results led to minimal, but important, updates to the work flows. The positive feedback, success rate, and lack of major updates demonstrated to the development team the importance of this process.

The Result

The end result produced a natural language rule editor. Each rule represented itself a sentence that could be read out and understood by someone who had no previous experience with the feature.

We were constrained by the existing GUI’s look-and-feel. The following is the final form of the Confluence page used to communicate the design with developers. The page went through many iterations as the development process progressed.

This section will be updated to highlight a few of the key results in more detail.