CHEGG ONEAUTH
RESPONSIBILITIES
Design System
UX/ UI / Interaction Design
a11y compliance (WCAG)
CHEGG ONEAUTH
RESPONSIBILITIES
Design System
UX/ UI / Interaction Design
a11y compliance (WCAG)
OneAuth initiative was part of an entire platform migration stemming from problems of accumulated tech debt. The migration moved away from our outdated platform and more towards a modern end game solution (our old solutions had multiple SDKs and APIs, the modern solution simplified and optimized the paths). From a design and front-end perspective, this meant we could replace legacy components with modern React components. This not only modernized the entire front-end and back-end platform, but was now relieving major constraints and existing blockers for product teams which was a proactive initiative for the platform I had pushed for years (with many ups and downs as well as set-backs).
OneAuth initiative was part of an entire platform migration stemming from problems of accumulated tech debt. The migration moved away from our outdated platform and more towards a modern end game solution (our old solutions had multiple SDKs and APIs, the modern solution simplified and optimized the paths). From a design and front-end perspective, this meant we could replace legacy components with modern React components. This not only modernized the entire front-end and back-end platform, but was now relieving major constraints and existing blockers for product teams which was a proactive initiative for the platform I had pushed for years (with many ups and downs as well as set-backs).
WHAT IS THE PROBLEM?
WHAT IS THE PROBLEM?
WHAT IS THE PROBLEM?
When solving the Service Abuse problem, we went through 4 phases of solutions. However, all these solutions were,
Used throwaway code to solve for a specific niche problem on a product (e.g, MFA on a Chegg content pages)
Using throwaway code meant these were not scalable solutions to the problem
Imposed massive security and trust & safety issues as it touched so many end-points
This was a classic platform problems of solving things “quicker” to meet a business need at the cost of accumulating more tech debt. There eventually comes a point where short term solutions no longer work as,
The tech debt gets too large
The platform services are so outdated, they cannot support modern 3rd party services (e.g, want your Auth to support biometrics etc)
Ultimately, platform upgrades are always difficult because they,
Are very time consuming and resource heavy (very expensive for the business)
Don’t provide a clear immediate ROI (as in doing X will increase conversions by Y%)
Platform services are a long tail which pay down tech debt (can never get rid of all tech debt and it will be “outdated” by the time it’s implemented) and set up teams to move faster in order to achieve those more immediate metrics.
When solving the Service Abuse problem, we went through 4 phases of solutions. However, all these solutions were,
Used throwaway code to solve for a specific niche problem on a product (e.g, MFA on a Chegg content pages)
Using throwaway code meant these were not scalable solutions to the problem
Imposed massive security and trust & safety issues as it touched so many end-points
This was a classic platform problems of solving things “quicker” to meet a business need at the cost of accumulating more tech debt. There eventually comes a point where short term solutions no longer work as,
The tech debt gets too large
The platform services are so outdated, they cannot support modern 3rd party services (e.g, want your Auth to support biometrics etc)
Ultimately, platform upgrades are always difficult because they,
Are very time consuming and resource heavy (very expensive for the business)
Don’t provide a clear immediate ROI (as in doing X will increase conversions by Y%)
Platform services are a long tail which pay down tech debt (can never get rid of all tech debt and it will be “outdated” by the time it’s implemented) and set up teams to move faster in order to achieve those more immediate metrics.
WHAT IS THE CHALLENGE?
WHAT IS THE CHALLENGE?
WHAT IS THE CHALLENGE?
As touched upon a little bit in the problem section, it’s very “costly” and time consuming. Platform tends to be more of a reactive team than a proactive team. What this means is that updating a platform is a very proactive initiative. The business tends to push back on proactive projects and use the resources (product, dev and design) for more reactive projects as they provide more immediate monetary returns (e.g, developing and designing a new SDK or API for a feature).
Another challenge I had personally is that I am the only designer on the platform team. During my tenure as the Identity & Access Management designer, I’ve watch 3 lead PMs enter and leave. With platform being fairly technical, it takes a PM a bit of time to ramp up and truly understand the product/platform. But often as we begin to work on an execution plan, that former PM leaves and this rebuying-in process must start all over again with the new PM (this includes ramp up, building trust, and re-clarifying the goal).
As touched upon a little bit in the problem section, it’s very “costly” and time consuming. Platform tends to be more of a reactive team than a proactive team. What this means is that updating a platform is a very proactive initiative. The business tends to push back on proactive projects and use the resources (product, dev and design) for more reactive projects as they provide more immediate monetary returns (e.g, developing and designing a new SDK or API for a feature).
Another challenge I had personally is that I am the only designer on the platform team. During my tenure as the Identity & Access Management designer, I’ve watch 3 lead PMs enter and leave. With platform being fairly technical, it takes a PM a bit of time to ramp up and truly understand the product/platform. But often as we begin to work on an execution plan, that former PM leaves and this rebuying-in process must start all over again with the new PM (this includes ramp up, building trust, and re-clarifying the goal).
WHAT IS THE GOAL?
WHAT IS THE GOAL?
WHAT IS THE GOAL?
There were 3 high level goals for this project,
Improve conversion, clarity, and accessibility
Have a single auth profile for all products
Reduce design & development redundancy
There were 3 high level goals for this project,
Improve conversion, clarity, and accessibility
Have a single auth profile for all products
Reduce design & development redundancy
WHAT ARE THE METRICS FOR SUCCESS?
WHAT ARE THE METRICS FOR SUCCESS?
WHAT ARE THE METRICS FOR SUCCESS?
The user need is to provide a more seamless and optimized experience (modernizing of services will improve performance time and completion rates down the funnel).
The business goal is to update the outdated tech stack to allow future products and features to scale on the platform while reducing security risks (this also includes migration of all other Chegg sign in/sign up/ password/ etc services not on the new OneAuth tech stack that is being developed by the Identity team).
The user need is to provide a more seamless and optimized experience (modernizing of services will improve performance time and completion rates down the funnel).
The business goal is to update the outdated tech stack to allow future products and features to scale on the platform while reducing security risks (this also includes migration of all other Chegg sign in/sign up/ password/ etc services not on the new OneAuth tech stack that is being developed by the Identity team).
WHAT IS THE PROCESS?
WHAT IS THE PROCESS?
WHAT IS THE PROCESS?
This project is very intertwined with my stakeholders but primarily engineers, architects and back-end services. From the front-end and design perspective, it was about redesigning every existing outdated component and working with the design system team (working with accessibility, engineers and design) to create React variants of the components to be adopted into the new design system (internally named Horizon). I worked closely with a FE engineer and go through the code base together to identity all the use cases and edge cases (odd errors, niche flows, etc). The initial sizing estimate was small to medium as based on these conversations it was just a matter of,
Designing responsive sizes
Taking molecules, atoms and foundation components
Working with accessibility to add in all the correct tagging and meeting the minimum AA compliance
Syncing with key stakeholders
But quick came to realize during my discovery that this was a largeto extra large effort as there were dozens of unidentified must-haves for this MVP. We were missing many use cases not yet identified as well many stakeholders from misc products still not identified. This is where my PM and I divided and conquered,
He would tackle all the product and engineering meetings
I would tackle all the design, accessibility and research meetings
We would then have 1:1 meetings twice a week (more if needed) and then do a stand-up style session where we filled each other in on all the detailed updates. This “non-scalable” way of working was only possible because we had built such a trusting working relationship. These 1:1 sessions were on top of our overlapping team meetings or required stakeholder meetings.
This project is very intertwined with my stakeholders but primarily engineers, architects and back-end services. From the front-end and design perspective, it was about redesigning every existing outdated component and working with the design system team (working with accessibility, engineers and design) to create React variants of the components to be adopted into the new design system (internally named Horizon). I worked closely with a FE engineer and go through the code base together to identity all the use cases and edge cases (odd errors, niche flows, etc). The initial sizing estimate was small to medium as based on these conversations it was just a matter of,
Designing responsive sizes
Taking molecules, atoms and foundation components
Working with accessibility to add in all the correct tagging and meeting the minimum AA compliance
Syncing with key stakeholders
But quick came to realize during my discovery that this was a largeto extra large effort as there were dozens of unidentified must-haves for this MVP. We were missing many use cases not yet identified as well many stakeholders from misc products still not identified. This is where my PM and I divided and conquered,
He would tackle all the product and engineering meetings
I would tackle all the design, accessibility and research meetings
We would then have 1:1 meetings twice a week (more if needed) and then do a stand-up style session where we filled each other in on all the detailed updates. This “non-scalable” way of working was only possible because we had built such a trusting working relationship. These 1:1 sessions were on top of our overlapping team meetings or required stakeholder meetings.
WHAT IS THE DESIGN PROCESS?
WHAT IS THE DESIGN PROCESS?
The design process itself consisted of various stages like defining product patterns from all the acquired products which caused a fragmented UX and UI across Chegg. This was a problem from a design standpoint and caused quite array of issues because of things like visual and interaction design inconsistencies. The process was very agile and consisted of,
Defining the problem
Disjointed UX/UI across login & sign-ups (which caused visual / interaction design inconsistencies)
Identifying all the security risks (many auth-end points, token leaks, etc)
Understanding all the back-end complexities (dependencies and heavy dev efforts)
Identifying the goal
Design reusable design system Auth component for all Chegg products
Work with the Design System by defining, designing and introducing a new shared component as well as as define content and adoption behaviors
To be fully a11y compliant (WCAG) according to Deque University Guidelines
Designing the solution
A design that could objectively improve conversion, clarity and accessibility
Single Auth profile for ALL Chegg products
Reduce Design & Development redundancy
The design process itself consisted of various stages like defining product patterns from all the acquired products which caused a fragmented UX and UI across Chegg. This was a problem from a design standpoint and caused quite array of issues because of things like visual and interaction design inconsistencies. The process was very agile and consisted of,
Defining the problem
Disjointed UX/UI across login & sign-ups (which caused visual / interaction design inconsistencies)
Identifying all the security risks (many auth-end points, token leaks, etc)
Understanding all the back-end complexities (dependencies and heavy dev efforts)
Identifying the goal
Design reusable design system Auth component for all Chegg products
Work with the Design System by defining, designing and introducing a new shared component as well as as define content and adoption behaviors
To be fully a11y compliant (WCAG) according to Deque University Guidelines
Designing the solution
A design that could objectively improve conversion, clarity and accessibility
Single Auth profile for ALL Chegg products
Reduce Design & Development redundancy
↳ DEFINING THE PROBLEM
There was quite an array of issues from a design standpoint,
Visual inconsistencies
Fonts & type sizes
color schemes
input fields stylings
grids and spacing
inconsistant CTA, SSO
Interaction Inconsistencies
Single steps vs multi steps
no capability support security (MFA, pass policies)
All different error language handling (no content or tone consistency)
All different breakpoints (responsive/adaptive)
Poor accessibility (tabbing, reader support, etc)
There we were also issues in terms of business problems as well. Users were dropping off at different key moments, customer support spent a lot of time per ticket. Each products team were developing their own version of similar flow (due to the many auth end points and acquired products). Inconsistent visual language eroded brand trust cause customer satisfaction to scores to drop. changes had to be done in multiple places (GDPR took 3x longer because login forms weren't unified).
There was quite an array of issues from a design standpoint,
Visual inconsistencies
Fonts & type sizes
color schemes
input fields stylings
grids and spacing
inconsistant CTA, SSO
Interaction Inconsistencies
Single steps vs multi steps
no capability support security (MFA, pass policies)
All different error language handling (no content or tone consistency)
All different breakpoints (responsive/adaptive)
Poor accessibility (tabbing, reader support, etc)
There we were also issues in terms of business problems as well. Users were dropping off at different key moments, customer support spent a lot of time per ticket. Each products team were developing their own version of similar flow (due to the many auth end points and acquired products). Inconsistent visual language eroded brand trust cause customer satisfaction to scores to drop. changes had to be done in multiple places (GDPR took 3x longer because login forms weren't unified).
Fragmented UI (This was Drop off different key moments, time spent per ticket with customer support, each product team had their own version of similar flow, inconsistent visual language eroded brand trust, changes had to be done in multiple places such as GDPR took 3x longer because login forms weren't unified)
Fragmented UI (This was Drop off different key moments, time spent per ticket with customer support, each product team had their own version of similar flow, inconsistent visual language eroded brand trust, changes had to be done in multiple places such as GDPR took 3x longer because login forms weren't unified)
↳ IDENTIFYING THE GOAL
With a clear understanding of the problem, It was now important to identify the goal. The goal in this case clearly to merge the tech stack. To have a scalanle and single source of truth for auth and token management for all the acquired products. With the guiding principles focusing on:
Accessibility
Mobile-first
Privacy/regulatory/Security (GDPR, SSO, etc)
Branding limitations
Tech constraints (backend limitations, localization, etc)
With a clear understanding of the problem, It was now important to identify the goal. The goal in this case clearly to merge the tech stack. To have a scalanle and single source of truth for auth and token management for all the acquired products. With the guiding principles focusing on:
Accessibility
Mobile-first
Privacy/regulatory/Security (GDPR, SSO, etc)
Branding limitations
Tech constraints (backend limitations, localization, etc)
Atomic Design System (Designing Auth based component within the guidelines of Atomic Design System implemented at Chegg so I could ensure it was re-usable and easy to adopt and use for all teams)
Atomic Design System (Designing Auth based component within the guidelines of Atomic Design System implemented at Chegg so I could ensure it was re-usable and easy to adopt and use for all teams)
↳ DESIGNING THE SOLUTION
When it was all put together, multiple designs were put through a rigorous A/B test to see which one converted best. Chegg has what we call "DNH Metrics" which are Do Not Harm metrics where we (as a team) are only allotted a 1-2% buffer in terms of drop-offs as just a 1-2% equates to millions of dollars for Chegg.
When it was all put together, multiple designs were put through a rigorous A/B test to see which one converted best. Chegg has what we call "DNH Metrics" which are Do Not Harm metrics where we (as a team) are only allotted a 1-2% buffer in terms of drop-offs as just a 1-2% equates to millions of dollars for Chegg.
Design A/B Testing (thoroughly test Organism variants through multitude of A/B to determine which converted best)
Design A/B Testing (thoroughly test Organism variants through multitude of A/B to determine which converted best)
Content design & Interaction design (worked with Content team to set up universal language guidelines for all messaging as well as "delight" interactive features like card flips defined for design system adoption)
Content design & Interaction design (worked with Content team to set up universal language guidelines for all messaging as well as "delight" interactive features like card flips defined for design system adoption)
Responsive Designs (finalizing all the potential use cases and edge cases for Organism across all the different auth entry point pages)
Responsive Designs (finalizing all the potential use cases and edge cases for Organism across all the different auth entry point pages)
a11y compliance (documented accessibility design system and devs ensuring proper guidelines and priorities according to Deque University guidelines)
a11y compliance (documented accessibility design system and devs ensuring proper guidelines and priorities according to Deque University guidelines)
High Fidelity Designs (some examples of the final designs delivered in Figma)
High Fidelity Designs (some examples of the final designs delivered in Figma)
FINAL METRICS
Sign In rate: OneAuth had a sign in rate of 80% (versus 54% for SuperAuth)
Sign up rate: OneAuth had a sign up rate of 20.6% (versus 14.7% for SuperAuth)
Error rate: OneAuth error reduction rate drop -22%
Subscriber journey drop off rate: Users had a higher sign up completion from subscriber pages and drop-offs reduced by -29.5%
Sign In rate: OneAuth had a sign in rate of 80% (versus 54% for SuperAuth)
Sign up rate: OneAuth had a sign up rate of 20.6% (versus 14.7% for SuperAuth)
Error rate: OneAuth error reduction rate drop -22%
Subscriber journey drop off rate: Users had a higher sign up completion from subscriber pages and drop-offs reduced by -29.5%
CONCLUSION
The most important metric we wanted to measure against was the DNH (do no harm). Chegg had a very low tolerance, if things trending even 1-2% in the wrong direction, leadership would force a deep audit and likely rollback. Even that small of a shift meant millions of dollars of lost revenue. This was not something the business was willing to wiggle on. So it was important to measure OneAuth (our new tech stack) with SuperAuth (our previous outdated tech stack).
The most important metric we wanted to measure against was the DNH (do no harm). Chegg had a very low tolerance, if things trending even 1-2% in the wrong direction, leadership would force a deep audit and likely rollback. Even that small of a shift meant millions of dollars of lost revenue. This was not something the business was willing to wiggle on. So it was important to measure OneAuth (our new tech stack) with SuperAuth (our previous outdated tech stack).