Introduction

Estée Lauder is one of the world’s leading manufacturers, marketers, and sellers of quality skin care, makeup, fragrance, and hair care products. The company’s products are sold in approximately 150 countries and territories. They are an inclusive company with over 25 brands and a rich history as a family led business.

Background

Estée Lauder is dependent on their C2M desktop applications. There are 20 apps in use on a daily basis to create their entire line of beauty products. They provide everything from new product codes, perfume packaging outlines, product testing and safety, quality control, design specs and final regulatory sign-offs by business leaders.

My Role

As the Lead UX/UI designer working on the project, it was my role to improve User Interactions + Visual Design to create a cohesive, productive suite of web applications.

The daily team consisted of a Technical Director, Business Analysts, Business Users, Subject Matter Experts, UI & Backend Engineers, Scrum Lead and Project Manager. I met weekly with key stakeholders like the Technical Director, VP of Operations, and a variety of team leaders to keep everyone in-step with the latest progress and expectations.

Timeline: June 2019 – Present.   Project: 6 – 8 weeks

Responsibilities: Product Analysis, User Interviews, Information Architecture, Low and High Fidelity Mockups, Prototypes, Usability Testing, Style Guide, Visual Hierarchy, Iconography, WCAG 2.1, UI Component Library, Dashboards, Data Visualization, Automation, CSS

Tools: Sketch, Figma, InVision, Adobe CS, Zeplin, Jira, Confluence, MS Teams

The Challenge

Analyze and optimize the new UI to increase productivity and the user experience across Cornerstone.

We received a lot of feedback after release of Cornerstone 1.0. Some of these issues involved broken functionality, confusing user flows, in-app errors and user accessibility.

These issues were scrutinized and managed in a backlog.

Key strategies:

  • What will provide the greatest impact for our business users.
  • What was the return on investment for key stakeholders (productivity/efficiency/positive PR/user adoption).
  • What methods could we apply to ease the development burden, since the original engineer team had shrunk considerably.
Following the key strategies above, we focused first on improving user accessibility.

My goal was to help users of all abilities work with equal efficiency and remove the problematic accessibility issues.
I needed to provide a solution that had low overhead from a development perspective. There was limited access to an engineering team to make these changes.

What is Accessibility?

Accessibility is usability for people who interact with products differently. The main categories of disabilities, limitations, or constraints that affect how people use digital services are:

  • Vision disabilities – such as blindness and low vision, color blindness,
  • Hearing disabilities – such as deafness and low hearing, tinnitus
  • Motor problems – such as hand tremors, physical deformities or amputations
  • Cognitive disorders – such as dyslexia, dementia, or being sleep deprived

My Process

User Interviews

An initial meeting was created with the Technical Director and 5 business users struggling with their daily tasks. I asked users to go through an example task and explain what it was that was frustrating them. I also connected one on one with a variety of business users to get a more detailed and personal account of their issues.

We held 4 or 5 sessions where I had the opportunity to learn more about each user, what apps they used and I took note of the language each used to describe the problem. This helped me focus and uncover the root of the issues.

Words used to describe the user interface

  • Glare, lightness, whiteness, lack of contrast, white screens, fonts too light, fields hard to see, straining, lack of brightness, too much brightness, small fonts, blurry fonts, gray, nothing pops, jarring.

Other important points:

  • Users challenged with the Cornerstone screens felt pretty helpless. The main adjustment they could make at the browser level was zooming in to make fonts larger. This helped but ended up slowing their tasks down since they saw less data on the screen and enlarging things meant more scrolling in the browser window.
  • I noticed that users would say to me, “Why is you screen so dark. The fonts look great and are easy to read.” I was on a Mac laptop and all of Estee’s workgroups are supplied inexpensive Dell laptops. The screens looked faded with low contrast between white and black by comparison.
  • Users could have increased screen brightness/contrast and implemented accessibility options in Windows settings. This was an unrealistic method of fixing the problem, since the people having issues were approximately 20% of the Estée workforce. That amount of user support was just not available to us.
I empathized with users and detailed any challenges. These became impromptu personas for future design:
  • A user who had a serious visual acuity issue. He had a 3-4 inch vision area that goes dark and blurry outside of that.
  • A user who was in their 30s and struggled with glare in the new interface. They had headaches at the end of the work day.
  • A user in their 50s had a hard time locating & entering information due to small font size and lightness of the screen.

“FYI- My eye strain is off the charts bad now… any relief…even a placebo effect like…” – comment from business user with visual acuity challenges.

Example screens with accessibility issues

Cornerstone 1.0 Product Analysis

  • All CS App colors have gone through WCAG 2.1 compliance testing to make sure color & contrast is acceptable.
  • Initially fonts were WCAG 2.1 compliant. During development, table fonts were reduced from 15px to 12px in size to get more data on the screen so users could work more efficiently.
  • Each app (20 in total) was created by a different team of developers. Even though they had access to a full style guide/component library, it was not fully followed and there are variations in designs on some apps.
  • The large development teams are no longer available since Cornerstone 1.0 is officially complete.
Checking contrast & WCAG 2.1 compliance

My Initial Idea

I am a big fan of Lean design in UX:

  • Start with a hypothesis – “The accessibility options feature will help users of all abilities work with equal efficiency in Cornerstone.”
  • Collaborate early in a build cycle – The entire team is working together, staying aligned and informed.
  • Build (efficiently) – Use low fidelity mockups, or develop a portion of a feature that helps prove or disprove the hypothesis.
  • Evaluate – Direct observation, A/B Testing are some methods that can be used to validate success.

With the lean philosophy as my guide, I chose an extension called “Dark Reader”.

Dark Reader Accessibility Extension

A free extension available in all major browsers called Dark Reader.

  • I chose Dark Reader because every user had a slightly different challenge and it was easy to personalize.
  • It was an out of the box solution that didn’t depend on development at all.
Dark reader provides controls for contrast, font weight, color, and dark mode to name a few examples.
Dark Reader Testing

I met with business users, set them up with Dark Reader and let them use it for a week in CS. We met for feedback.

  • The user’s loved Dark Reader’s flexibility.
  • Being able to bold fonts was a must for a user with visual acuity issues.
  • Several users liked the creation of background colors that helped them focus on the editable fields. It provided a less stark view vs the existing Cornerstone.
  • Users liked the fact that it was pretty easy to use and save their settings. They could come back the next day and not have to set up Dark Reader again.
  • There was no mention made of dark mode. I thought this would be a bigger help. People seemed to gravitate around the bolded font and background color ability of Dark Reader

The bold fonts really helps my eyes and I don’t get a headache after being in the app.

Estée Lauder Security Team – Dark Reader Review

I spoke to Jamshid, ED, Global Head of Security Engineering & Operations and he feels that Dark Reader could become a security issue.

He went through several examples like Grammarly being a keystroke recorder. Or plugins that started with good meaning but changed over time. I asked if we could do some kind of interim/short term use of the extension and he said those things tend to go to production and become part of the system.

Potentially a keystroke recorder and used as a comparative example to Dark Reader as a potential security threat for Estée Lauder.

Revised Idea – Keep it in House

The security review had me shift gears.

I had to meet the needs of our users via an internal solution that didn’t rely too heavily on development to deploy across Cornerstone.

I looked closer at Dark Reader and how it did its CSS magic. Dark Reader pretty much worked with every website it was activated in.

Could we take this methodology and bring it into the CS landscape? Yes.

I decided to focus on two solutions that would provide the greatest impact to our users and get them back to work at speed.

1. Bold fonts for readability

Adding a text stroke around the fonts in CS. This was a really easy implementation for develoment across Cornerstone.

2. Shade card components to highlight input fields.

Relatively easy implementation across applications. Note: Developer designs varied between some apps and this created snafus.
Input fields and tables were mostly contained within these cards. Shading them put natural focus on our input fields.

CornerStone 1.0 screens with shaded cards & bolded fonts
Shaded Card and Bold Font Testing

I tested the options with users displaying a live prototype. I shared my screen and control to let users drive a bit.

  • Users have bold font and shaded card control via an accessibility modal (below). They liked the simplicity of on and off. They also liked that a change in settings would be remembered.
  • Some preferred the card shading only, while others liked both options on.
  • The results were positive overall. I had to adjust the font bolding a bit in our live session. I used a combination of Dark Reader and the source CSS to achieve this.
A modal provides users control over their accessibility options.

Moment of Insight

I knew I had the right solution when I received this comment from a visually impaired user.

I can see where I am now. This is cool.

I think this comment hit the nail on the head. By shading the cards, the ability to navigate the complex surroundings came more naturally.

Like, when you enter your own bed room, you know where the dressers, nightstand and bed are located. This helps you navigate the room. By extension, seeing these defined shaded areas made it easier for our users to go to the part they needed to do their work.

Results

  • Our users who were plagued by the CS contrast issues are completing their work.
  • They are working at a level that is on par with users of regular ability.
  • Location. Location. Location. Users can navigate the shaded blocks of data and input fields are much easier to spot vs the original experience.
  • Development only grumbled slightly and the level of work was manageable.
  • Even though my initial idea would have been the most flexible… I did take from the way they implemented the CSS and we applied it to Cornerstone.
What I learned?

Three years ago we were knee-deep in the white screen/clean design trend. This weighed somewhat on the decisions I made when creating the CS Style Guide and component library. During development we reduced many of the fonts from 15px to 12px in size to get more data on the screen.

Roll with the punches.
  • Have empathy for business users who need more data and business users having accessibility issues.
  • Be flexible. Keep what works and provide impactful options for users that are struggling.
  • Iterate and look forward. A challenge like this is a opportunity to learn. Be open and take it.