Introduction & Background

Frequence bills itself as a one-stop solution to providing local advertising for SMBs and enterprise businesses. The app allows users to run adverts across multiple channels such a TV, radio, social media, SEM, email, print and even custom ones like billboards. The platform is built to be malleable enough to adapt as a white label solution for its parters of which there are thousands, as it has grown over a decade. However, much like the LaCalle Group’s Continued brand for its EdTech verticals was in need of a revamped design system, so did Frequence with its barebones, stock Material UI components. Luckily, the app ran on Angular like Webconnex and, therefore, didn’t need much of a rebuild on the backend.

The Challenge

After having accrued a sizable amount of engineering and design debt, Frequence’s board members focused on providing more resources to refining the user experience, in addition to simplifying and augmenting other parts of the app. By growing the product team, scoping the app’s holes and sizing possible solutions to revamping the app, it became clear early on that we’d be working at multiple phases and speeds.

Unifying Fragmented Experiences

One of the key design patterns that needed overhauling was the incessant use of accordions, which went as far as three levels deep. To replace them, we used nested side drawers because they had following benefits over the existing design:

• Improved contextual design, when drilling down into sections (ie. the previous section becomes the background for the current section) and shortening the overall page length.
• More intuitive navigation assisted with the breadcrumb top navigation (ie. meta data in breadcrumb header allows the user to get better understanding of where he/she is working within the app).
• Increased scalability and flexibility as overlapping paneling will not affect the content’s width as nesting increases, in contrast to nested accordions.
• Consolidation and consistency with respect to modals and drawers will further usher in a modernized approach to SaaS app design.

In the above screenshot example, we can see two overlapping panels, which are accompanied by a breadcrumb navigation in the dark blue header bar. As the user drills down into each section, the breadcrumb will accommodate the section name and/or meta data.

A Minor Setback

Overall, while the product and engineering team loved this concept, it would later unfold that we had a hard limit on overlapping nested panels, which broke some of the earlier redesigns. We eventually settled on a combination of nested panels, single accordions and rail navigation tabs to clean up all the pages.

Providing Consistent Navigation

Much like the inconsistencies seen across pagination styles and date picker types, the main focus of the universal shell navigation was to introduce a sense of hierarchy by designating a place and type of navigation when talking about traversing across different pages and sections.

Primary and secondary navigation would always be horizontal within the header to stay in line with legacy layouts. However, we introduced the idea of tertiary cross-navigation using panels to further things along even more. Once within a section, a user would be able to cross-navigate using vertical navigation bars. These will replace nested accordions and slide-outs. Below is a diagram of the basic schematics:

Building Processes with Offshore Engineers

With the bulk of Frequence’s head count belonging to the engineering team in India, we had to have a way to stay in sync with the iterative workflow of shipping new features and redesigns. As luck would have it, I had come across a great tool at the time called ZipMessage, which allowed me to provide edits for engineers in a quick and easy way. With this screen recording tool, I’d record several video messages, broken into small enhancement ticket-sized chunks, as I’d explain how to either resolve visual inconsistencies or functions.

Furthermore, I’d collate all these edits into a Google Document with some brief explanations on how to resolve the issues I found. My product managers would then create individual tickets, so as not to let things fall through the cracks and achieve the best possible parity between our high-fidelity designs and its coded counterparts.

The Process

Before any team could ship anything new, we needed buy-in from the board, which is where I outlined exactly what we were doing and why we were going about it. Specifically, we focused on using an off-the-shelf design kit called Tailwind UI to ramp up speed for mocking up prototypes. We also touched on the process we used to align the UX with the engineering team. Additionally, I wrote almost two dozen pages on the specifics for using the Tailwind framework along with instructions on how to approach it code-wise.

Since we had several different version all progressing in parallel to each other, I outlined an approach on how to slowly convert Material UI to Tailwind UI. First, we’d work on the aforementioned panel, which housed a Material UI component. This was was, then, converted to Tailwind UI. Next, we’d work on its associate parent component before moving on to “Tailwinding,” as it become known, the content wrapper. The chrome, that is the final page wrapper containing the main navigation, would come last.

Data-Informed Decision-Making

Throughout the entire process of revamping the platform, I led the UX efforts in validating our design decisions through multiple user interviews, which covered a vast array of usage and experience. Some users had used the platform for more than four years, while others had barely used it for a year. In all interviews, the overwhelming majority of feedback received suggested that we’re on the right track. Currently, we’ve rolled out the new designs in phases, as we’re awaiting more feedback from the larger crowd.

We had several wins coming out of this proof-of-concept for ushering in the new version of this platform. Foremost, the app was easier to navigate and just looked more polished and refined. The user messaging was more useful, the design patterns were consistent and the process by which a user would get from doing one part of the app to the next was extremely simplified, in some cases.

For example, when a user wanted to edit the budget for a video campaign, as we demonstrated above, the user had to endlessly scroll through one page that displayed all sections, then click into the relevant section section, then click into the campaign and then click into the actual budget. In the new version, we cut that process down to 2 clicks — Click #1 got the user to the budget section and Click #2 allowed the user to input all the relevant budget details, which then were spread across the video campaign’s runtime in the background.

The next major win came from iterating screens to replace the user’s “welcome” page. From the screenshot below, it was a very sparse page, which looked dated to say the least. Because Frequence has been around for over a decade, we knew we could tap into the loads of data points and, thus, came up with a new version which placed “Insight Cards” front and center. These were actionable cards that alerted the user for the current ongoings for campaigns, adverts and the like. Instead of them having to hunt and peck data across the various app sections, we focused on spoon-feeding this information on first glance. If we wanted to ensure that they love our platform, it’d behoove us to teach them a thing or two about their own data and leverage that to improve the way they spend their advertising dollars.

The last big-ticket item came in the shape of providing more structure to loosely defined spaces for components. Although a user could make sense of a campaign’s meta data, the way it was designed wasn’t really conducive to the average platform user. To put simply, some navigation had to be revamped and in certain parts had to be supplemented to provide a future-friendly way to support more elements onto a page section down the road.