Designing The AudioEye Toolbar

UI design solutions for the AudioEye Toolbar, a web personalization tool to meet user needs.

Project Overview

My Role: Lead UI Designer

What I did:

1. Designed the UI: A mini design system and custom icons to release a refined and modern toolbar.

2. New features: Admin controls were being introduced for this toolbar release, which meant defined UI states.

3. Adapt for mobile web: Functional and viewport differences were designed for desktop and mobile.

Duration: December 2020 - March 202; Released April 2021

Tools: Figma, Color Contrast Analyser, iOS VoiceOver

Summary: After 3 months with AudioEye, I was given the role of Lead UI Designer for one of their main products, The AudioEye Toolbar. In addition to giving an overall visual refresh, I was tasked with incorporating flows to support new administrative features. With the support of 1 Designer, 1 Product Manager, and a team of Engineers, the final product was released to production in April 2021. Designing with accessibility guidelines at the forefront, while testing for quality assurance was prioritized from start to finish.

What is AudioEye and its Toolbar?

AudioEye is a SASS company that provides its customers with automated fixes for digital accessibility issues once installed on a website. After installation, the AudioEye Toolbar integrates and a toolbar icon (an accessibility icon) will appear on the customer site.

The AudioEye Toolbar provides web personalization tools that allow end-users to customize their user experience to meet their individual needs.

Kickoff

It is a well-known fact that the more practical and applicable a product, the more clear and easy-to-use it should be. The AudioEye Toolbar is aimed to be used by a wide target audience for all demographics and abilities in technology. Therefore, this factor had to be considered to create an efficient and bright interface design that would have a simple aesthetic representation to not confuse any users.

The assignment didn’t come out of thin air. I was given an existing design to be based on further changes. The version existing at the moment already had an effective user experience that needed refinement and testing.

The goals of the new UI design would be user-friendly, harmonic, and accessible. These were all considerable factors from the start of the design process.

A Mini Design System

The main approach for the UI design was already started by another designer before I joined AudioEye. The designer used a light color palette to keep the toolbar neutral, as this was becoming a white-label product down the pipeline. There was a design system in use but it was limited. After I was handed off the toolbar I began making contributions to the design system as it was imperative for my team of engineers to continue to build consistent, UI-friendly designs quickly. My contributions to the system were: typography, color palette, keyboard focus, icon badge, and elements.

Custom Icons and Buttons

Another task to take on was to create minimalistic icons that related to the visual toolkit functionalities. To keep it minimal the icons were made using only strokes with no fill. These small details made a big impact as the home screen (The Visual Toolkit) comprised only UI components including icons and buttons.

New Features — The Admin Panel

During the redesign, three new features were being added with the release of a fresh-looking toolbar: the admin panel. This gave owners customizable features to brand the toolbar for their business’ website.

The admin features:

1. Select the placement of the toolbar’s icon for your website.

2. Choose an accent color for the toolbar’s icon (CTA).

3. Switch between light theme and dark theme.

😫 Constraint 1 — color and contrast for accent color

One of the major challenges, when faced with the UI, was navigating color and contrast. With every visual design element, came the priority of WCAG compliance — which is AudioEye’s bread and butter.

What’s WCAG? In short, Web Content Accessibility Guidelines (WCAG) cover a wide range of recommendations for making web content more accessible and more usable to all users.

I faced restraints with contrast every step of the way when it came to the release of the Admin panel; specifically for 2 out of 3 features: accent color and themes.

Accent Color: this allows owners to choose any color from the color wheel.

My challenge was to reinforce WCAG through the UI. The tool I used to determine the contrast ratio of two colors was Color Contrast Analyser by TPGi.

Version 1 allowed owners to apply their color selection to the top and bottom bars of the toolbar. Ultimately I found this iteration would not be an effective branding solution for owners, as the set color would be end-user facing.

This brought me back to the drawing board.

Version 2 would allow owners to choose the color of the toolbar’s icon. This would be most beneficial for owners because the toolbar’s icon is consistently present, regardless of end-user engagement.

The default color would be the standard accessibility blue (#1275B3) until owners choose to change it. To account for user mistakes I provided a reset button, just in case owners wanted to quickly resort to its default color.

But that still left me with a hindrance of contrast. How can I give owners infinite color choices while remaining accessible? For instance — an owner’s brand color is yellow, how can AudioEye regulate contrast?

😊 The Solution

When the owner chooses a color, the icon’s outline and figure automatically adjust to either black or white to maintain an accessible level of contrast. So I held a meeting with a developer to see if they can input code to automatically meet the minimum requirements of a 3:1 contrast ratio. It was a success.

😫 Constraint 2 — color and contrast for light theme

Themes: this allows owners to select between a light theme or dark theme interface.

When designing the toolbar’s dark theme, choosing contrast colors was very straightforward. Selecting a light foreground color for a dark background passes WCAG color contrast criteria very easily. (Think white text on a black background.)

However, when designing the toolbar’s light theme, contrast is much more challenging. One constraint was the avoidance of using a digital black typeface or pure black on top of a solid white background. Although this passes WCAG criteria the stark contrast may cause eye strain.

😊 The Solution

Instead, I considered designing a more muted version by working with greys. Grey also posed a challenge as it’s a difficult color to pass WCAG. So to solve for this I chose greys that had very subtle tints of blue, which was more favorable among stakeholders, as it offered a modern, cool edge, especially compared to competitors.

In addition, drop shadows were used on the outermost stroke of the toolbar for additional contrast on a website.

After several iterations, these were the final screens released for the admin panel.

Defining UI states

Since a new user flow was being added to the toolbar, designing UI states was necessary before passing it on to the dev team for implementation. This was mandatory for the product so that the users were catered for at every interaction point.

Here’s one sample of UI states accounting for the admin login flow:

A White-label Product

Since this release prioritized owner customization of the toolbar, a white label product became a priority. The goal was to have the toolbar be less obtrusive and more harmonious; so I went with transparency.

The back panel of the Visual Toolkit (the home screen) would be set at 90% opacity, allowing the client’s site to peer through, just a bit. For WCAG compliance I left all buttons at 100% opacity. This small detail made a large impact on stakeholders as it gave a more modern edge.

Mobile Adaptation

The toolbar was ready to build for desktop but now adaptation for mobile web needed design. The differences between desktop and mobile were two things: proportion and functionality.

The functional difference between the mobile toolbar and desktop toolbar was the Visual Toolkit. The buttons an end-user would interact with via desktop simply do not apply to mobile — I.e a cursor button does not apply to mobile because a mouse is not used through a phone. That meant removing all desktop-specific functionalities: focus, cursor, highlight, guide, window, and images.

Mobile proportions:

1. When opened the mobile toolbar will take up to 100% of the screen display.

2. The mobile breakpoints were 345x720.

3. The target areas for mobile icons needed to be increased from 24x24 to 44x44, buttons sizes needed to increase, and hover states had to be removed.

Within the admin panel, icon placement was now available for owners to place the toolbar’s icon (CTA) for their webpage via desktop. Mobile icon placement now needed to be designed for. Admin can choose where the CTA lives on the webpage, whether the end-user is on a desktop or mobile.

Results and Next Steps

Once the deliverables were finalized it was built, QA tested, and released in April 2021.

The next step was to prepare for usability testing, down the pipeline, with users from a company called Fable. Fable provides people with disabilities to test products for accessibility. This was a huge leap forward for AudioEye.

Reflections and Learnings

This project was a major victory for me as a Jr. Product Designer. To have the opportunity of being the design lead for one of AudioEye’s main products, then see it released in production was a pivotal moment in that stage of my career. I was so appreciative that my team trusted me with the endeavor. Here are a few takeaways I got from working on this project:

Involve engineers early on.
This one has been said time and time again but it’s perpetually crucial. At that time, AudioEye was a startup environment, which unfortunately meant a high turnaround. Engineers came and went, so 1:1 meetings were important for me to keep everyone on the same page. I found this very valuable as it helped scope out my designs early on with their feedback. Which lead me to my next takeaway…

Utilize a design system.
Big or small I found this critical for work productivity. The benefit of designing with components from a design library is that it’s built within the software — in this case, Figma. This effort lead to efficient results in producing a consistent, user-friendly product.

Following WCAG guidelines.
With every design decision, I was testing for quality assurance. At that time it was challenging because I had no prior experience in testing for accessibility. But being hired as a designer for a software company that’s mission is digital accessibility meant rolling up my sleeves and training myself in WCAG. The benefits were unmeasurable as I’ve widened my perspective to produce products for all people in mind first.

🚀 Want to see it live?