An Emergency Redsesign
Rapid prototype and design of a complex administration system
The Situation
Broadridge’s product, DMEdge was running it’s admin system on Adobe Flex technology which was rapidly nearing it’s end of life. In fact, all modern browsers where set to drop all support for Flex and block it’s functionality. With only a few short months to go, the highly complex admin tool needed to be rewritten in an HTML format. And fast.
Gathering pain points
A good redesign project starts with an assessment. What was good about the old design? What was not so good? We polled our user contacts for input on their experience with the platform. As an aging platform, we expected a great deal of frustration with the interactions on the site. Complaints about slow speeds and system lag where also par for the course and expected. The most common feedback we heard was complexity. The admin of the system required a lot of data points and values to be mindful of and users were having a hard time understanding how different values affected different system elements.
Building a Taxonomy
The first thing we wanted to tackle at the onset of the project was the complexity. A list was created of every setting, control, and operation that was required to administer the system successful—we dropped a few settings that were more confusing than they were beneficial as well. Next, we built out a list of logical super-categories. Which settings affect visibility and location? Which values impact pricing and purchases? These groupings allowed us to organize controls by their intuitive relationships that fell in line with user expectations.
The design
It so happened that our development timeline coincided with a big corporate rebranding effort. This did present a challenge but also an opportunity to work with the corporate design teams. It was helpful to keep abreast of changes coming down the pipeline but to also be able to provide real-time feedback as to the design needs of a system as it was being developed. Screens for the new admin toolset were being updated on the regular and the brand compliance requirements were being met before they even existed.
Additional features
Working directly with development team on implementations of the new designs also allowed for making sure the new code base allowed for some future proofing for features that were outside of sprint. We knew there were a number of features that our user base were clamoring for that would not be able to make it into the current project. It was therefore important that the new code being developed for implementation had a level of modulability to allow for future updates without a whole new rewrite. With clean, adaptable code, we were set up for a few quality of life improvements as fast-followers to the redesign.
Results
The redesign was released to excitement and praise from our user contacts. They were made aware of the situation and were expecting mostly the same basic system to be delivered in a new language. The new design intuitions and organization meant that they would have to commit less time to administration tasks and less time ramping up new users on their end. And with the logical ordering of tools, there were a lot less “oops” situations.
