Problem

Internal users need to create, edit, and delete URL redirects to marketing landing pages. These rules could only be managed by the development team, and so were often done so with delays due to the development team's higher priority work. This led to delays with the internal users’ work.

Solution

Enable users with limited technical experience to easily add and manage URL redirection rules without a dependency on the development team

WIREFRAMES

I started the wireframes in conjunction with the corporate internal style guide as reference. This allowed me to brainstorm and block out elements while still abiding by the design guidelines that the tool would ultimately be held to. I included some design standards from the beginning that I knew were required, such as the font families.

Because the user could perform multiple actions on this single page, I went with a modular approach (which also encourages componentizing when developing) for clarity and bring the user to set "filling out a form" expectations. I communicated the source URL domain restrictions as a dropdown, and added status messages just below the buttons since the user's attention will be in that area upon clicking.

I presented v1 of the wireframes to the development team and PO, who amended some of the stories to include details such as allowing multiple rule tests and requiring all rule tests to pass before a new rule can be saved. The wireframes went through four or five more cycles of feedback-iteration before moving on to design.

PROTOTYPES

There was some time between approval of the wireframes and the start of the prototyping process, and by that time, a new user story to allow users to browse existing rules had surfaced. I created a very rough wireframe/prototype hybrid to illustrate a few options for this new story, as well as began implementing the more specific guidelines from the design system.

Throughout this process, my team had several check-ins with the PO to review progress on the codebase and the designs. Due to some evolving requirements, some changes to the prototypes were added then removed, and things previously removed were re-added at points. It was good I kept such an extensive version history!

I identified a lot of the interactions up-front, including:

• Submitting the form successfully

• Submitting the form with duplicate information

• Submitting the form with rule pattern errors

• Submitting the form with incomplete fields

• Submitting the form with errant tests

• Adding a new test

• Deleting a test

• Running the tests

Some of these interactions were merged in the end, such as automatically running all the tests upon the user attempting to submit the form. I also planned for a few of these interactions to trigger a success/error message box above the major CTA button. As the requirements shifted, I also added more interactions that had to do with browsing a list of existing rules and filtering on that list by the root domain.

ITERATIONS

My team had the benefit of getting early feedback from one of our user groups a few days after we released the initial version. There were two major iterations identified from user feedback. One was to better discern between active and inactive rules, so I added a filter dropdown for that as well as special styling for inactive rules within the list.

The other major iteration was to improve upon the success and error messaging. These status messages were initially written by the developers, so they were very short, technical, and straight to the point. They did not provide the user with any follow-up or corrective actions. I worked with the developers to understand the situations in which these messages would display, and then rewrote and expanded them in order to clearly communicate what had happened and what actions the user could take next.