Reducing Duplicate Accounts

Improving onboarding flows and reducing the support costs associated with accidental duplicate accounts

The Problem

Pearson’s higher education division primarily offered a variety of courseware products designed to replace and expand upon the traditional college textbook. This typically included written content paired with interactive features such as videos, practice questions, maps, essay prompts, and more.

Instructors could configure the courseware with due dates and grading policies, and then track student performance over time.

One of the first major projects I worked on at Pearson was reducing the number of duplicate accounts that students would create as they tried to join and access these courseware products.

A combination of legacy architectural issues and poor user onboarding meant that students could easily and frequently create duplicate accounts in our system.

This resulted in several problems:

Students had trouble returning to their content.

Support teams spent too much time finding and merging duplicate accounts.

Instructors dealt with the same student appearing multiple times in their dashboard.

My Role

Partner with product owners to generate potential solutions.

Create wireframes and mockups to communicate solution ideas.

Build prototypes for user research.

Analyze data and metrics to understand the problem.


1. Understand the problem

Feedback from our support team helped identify duplicate accounts as a common and time-consuming issue that would be worth addressing. I wanted to understand the problem in more detail so I obtained some of our logs and ran analysis using python data analysis tools.

I was able to determine that the vast majority of students with duplicate accounts only created two accounts with the same email address. A much smaller minority wound up with three accounts.

A snippet of the data analysis I performed.

Our data couldn’t tell us how many accounts with different email addresses were tied to the same student, but this initial evaluation helped frame the problem and scope our solution.

2. Identify solutions

There were multiple points in the flow of a student’s interactions with our product where we could nudge them towards the happy path of creating and using a single account. I worked with the product owner to identify these key touch points and develop targeted improvements.

3. Improve invite links

For classes that used traditional textbooks, instructors could just list the name of the book in their syllabus and students would go pick it up at the bookstore. This process worked the same way for classes with only one section and classes with many sections.

(Some college classes have multiple sections: the same class taught at different times in the same semester. For example, there might be a Monday/Wednesday/Friday version of a class as well as a Tuesday/Thursday version offered in the same semester.)

Because Pearson’s courseware products were typically customized for each section, the process of gaining access was a little more complicated than just visiting the bookstore.

Instructors had to invite students to join the appropriate instance of the courseware product linked to the section each student registered for. They accomplished this by sharing a unique link with each section’s roster.

In our initial version of this flow instructors had access to the raw tools necessary to invite students to their courses, but we offered very little support or guidance on how this process should work.

Instructors could access the invite link, but weren’t offered any instructions on how to use it.

I updated the invite feature to better explain the process and provide instructors with pre-written directions they could easily copy and paste into their syllabi.

Including an explanation helped newer instructors learn the new process and understand the details. Providing pre-written directions eliminated the possibility of instructors misunderstanding the invite flow and could speak directly to the students.

4. Improved course identification

Upon visiting the invite link the student would be presented with a screen where they could log in and pair their Pearson account with the specific courseware instance created for them.

We learned from support calls that sometimes students would use the invite link from a different section of the course (typically when they borrowed the syllabus from a friend in the same class, but a different section).

To help address this I created a dedicated course card on the invite page designed to help students identify exactly which section they were signing in to.

My initial approaches used a calendar-inspired widget to emphasize the course’s meeting days — often the most recognizable difference between sections.

After working through the possibility of multiple meeting times on the same day, I landed on a more traditional list of times, along with other identifying information such as instructor names and section code. Overall the card was styled to match the course cards from the dashboard homepage to emphasize continuity.

5. Duplicate account checker

It was on this same invite page that most duplicate accounts were created. Our screen originally provided a fairly prominent “Create Account” option right at the top.

Students often forgot they already had a Pearson account or didn’t realize they could re-use the same account to join a new course. For legacy reasons our backend system allowed multiple accounts to be created with the same email address, so it was easy to unknowingly create duplicate accounts.

I redesigned this page to de-emphasize the account creation option and include a new account lookup feature which would help students find their existing accounts, instead of making a duplicate.

I de-emphasized the account creation option and created a flow for looking up existing accounts.

We even offered to look up a different email address if the first one didn’t find an account, because we learned that students often had several email addresses (typically a personal account and then one provided by the school).

6. Student first run experience

One of the issues we identified from support tickets was that students were using the invite link to return to their content throughout the semester.

We partly addressed this by including the direct dashboard link in the instructions we provided to instructors, but also felt it would help to point students directly to the proper url.

To support this I updated the first run experience to suggest students bookmark the homepage. This banner responded to the current browser, presenting the proper instructions.


I worked with a key product owner to develop, validate, pitch, and implement several key improvements to our onboarding flows that eliminated one of our top support issues.

This project was part of a broader initiative to address issues that consumed a lot of our support team’s resources. Altogether, this initiative was able to reduce support costs by several million dollars.

My specific contributions streamlined the user journey and helped users avoid common pitfalls.

What I learned

The process of proposing ideas and integrating them into the quarterly roadmap of a large agile organization.

How to evaluate and improve key touchpoints in an existing user journey.

How to explain new workflows to users and support their adoption.


Pam Portman

Product Owner

Matt Hoffman

UX Researcher

Yelena Kippur

Project Manager

Kim Adams

Dev Manager

Next ➜

Read about my latest project, evolving and maintaining Pearson’s first design system.