CASE STUDY | ux research & design
Improving Self-Serve Features with Account Visibility
Overview
Problem to solve
Every summer, before the new school year, customers added new classroom rosters to our EdTech platform.
And every year, importing and managing lists of students left our customers, support staff, and developers frustrated and overwhelmed.
This seasonal pain point became predictable, but everyone suffered through it because this older product wasn’t a new-feature priority. How could we make small adjustments for maximum impact?
Research approach
I used detailed stakeholder interviews and a heuristic evaluation to investigate user and staff pain points, revealing two main problems:
Inconsistent goals for the task flow of managing classrooms
Customers didn't have enough visibility into their account details to make useful decisions
“81% of all customers attempt to take care of matters themselves before reaching out to a live representative.”
— Harvard Business Review
My contributions to a new customer experience
Guided product team through workshops to agree on desired outcomes and data structures.
Proposed a design that clearly surfaced account statuses and permissions to help users understand how data arrived in the platform and what they can do with it.
Added dynamic personalized help text so customers could use the platform more effectively and achieve satisfying results through self-service features.
Impact
Increased user agency on the platform for 10K+ teachers and school administrators
Decreased urgent demands for customer support to solve predictable user problems
Eliminated 10% of tickets that interrupted developer focus on top priorities in July & August
Replaced annual frustration with confidence that problems could be handled effectively
Prepared future projects for success by defining terms and setting rules for user account types
Project specs
Case study notes & credits
Industry
EdTech (SaaS, DTC)
Company
American Reading Company Reading and writing solutions for grades K-12
Product
Academic data collection tool and dashboard
Product Stage
Refinements (10+ yrs)
Platform
Web app, desktop
My Roles
UX Researcher, UX Designer, UI Designer
Team Members
Project Manager, Developer, 3 Support Team stakeholders
Scope
Discovery, guide decision making, prototype, handoff
Tools
Figma, Confluence, Jira
Wireframes and artifacts
The wireframes in this case study are semi-fictional. Functionally, they are based on actual designs I created for American Reading Company. However, I have simplified elements of the interface that were not relevant to this project, anonymized all customer data, and given my own spin to the style elements and page structure.
Illustrations
I use illustrations to tell the UX Research part of this story. In some places, I use them to demonstrate the function of a decision-making artifact because the actual Confluence documents and tables I created remain confidential. Illustrations are composed from multiple Excalidraw libraries and include my own additions, also drawn in Excalidraw.
Animation
Created by me, in Figma.
Want to hear the whole story?
Let’s start with the business context and technical goals: what did the product team want users to be able to do, and why?
Meet American Reading Company, an EdTech company that provides literacy web apps to K-12 schools and districts.
Schools use these apps to help students improve their reading and writing. As students make progress, teachers record their growth and new skills.
School administrators use that student data to create reports identifying trends and areas of need.
Each student ID is an anchor point for other data about that student’s goals, status, and progress.
So, why couldn’t schools and teachers simply import their data and edit it on their own? Why were they inundating the support team with help requests?
To set a start-of-year baseline for all that student data, school districts must first import lists of students—sometimes hundreds or thousands of students at once.
Importing students to a class is not the end of the story! Students may change schools, be assigned to a new teacher, go up or down a grade, or start a new personalized learning track.
In these cases, teachers and administrators need to add or remove students from a given class after the initial import.
The root of the problem
To locate the source of customer confusion, I carried out detailed internal interviews with support team stakeholders and with the developer who specialized in this product.
I learned that there were five different ways to import student data into the app. Our company directly controlled two of those methods, but the other three were controlled by customers (teachers, school administrators, district IT) and by Single Sign-On (SSO) platforms that schools use to manage many learning apps all in one place.
When teachers looked at a list of students, they couldn't tell which method was used to import that list.
Which method should they use to manage it? Who should be responsible for making updates?
Without enough information to guide them, customers invented creative—but ultimately frustrating—solutions.
A heuristic evaluation confirmed that customers didn’t have enough information to make effective choices.
The existing instructions and task flow had several issues:
The support team reported that customers routinely:
Created duplicate data,
Made manual changes that got overwritten by automatic updates,
Tried to manage data using features that had other purposes,
Got upset when data disappeared or failed to update as expected.
How could we encourage customers to make only the changes that would benefit them, and not attempt solutions that would frustrate them later on?
Underlying uncertainties
In my internal research conversations with stakeholders from the CTO to junior support team members, I discovered that before we could give customers better direction, we needed to clarify our intentions for the student import process.
I identified key decisions the product team needed to make:
1. Permissions and user types
Which user types should be able to add, edit, and delete students?
2. Permissions hierarchy
Should the user type or the data import method take priority, when determining which users can do what?
3. Import method and support
Should our company take responsibility for supporting the process of managing which students appeared in which classrooms?
Or could we lessen the burden on our support team by directing customers to other appropriate help points, such as their school district IT department or the 3rd-party SSO portal that controlled access to the app at their school?
Redefining requirements
I created a matrix that mapped out each user type and permission level. As a team, we filled in each variable, establishing clear decisions about the functionality and interactions we wanted customers to have.
To navigate the team to actionable decisions,
I also gathered the support team's subject-expert input to write dynamic, personalized help text for each combination of user type and data import method . This information would help customers understand what they could do, any risks to their data, and who to ask for help.
There was one more key question to answer: How should I integrate this newly visible information for customers into the existing interfaces?
From decisions to design
Usability goals
I synthesized my research findings and used the answers to these questions to direct my design choices:
-
Users need to know which method was used to import each list. Using that same method to manage any future changes will ensure that data stays clean and up to date.
-
Dynamic help text will only describe options that users have permission to choose based on their user type and level of access.
-
The list management method determines what kinds of problems may occur if the user tries to manage the list using a method that wasn't used to import it. Dynamic alerts for potential errors and data loss can help the user avoid overwriting and manual editing mistakes.
-
The list management method determines which support team can help the user. Dynamic help text based on the management method tells each user exactly who to contact for help.
I also incorporated the priorities that the Project Manager defined for UI updates on this project:
1. Better visibility.
Updates needed to catch user attention for effective contextual onboarding.
2. Minimal disruption.
Refinements should not interrupt familiar use patterns or the look and feel of the UI.
3. Feasible.
Recommend design changes had to be small and flexible, achievable in a legacy code base for a developer with limited time.
To share the necessary information with teachers and school administrators, I added a personalized informational panel that pulls in a cluster of explanations, alerts, and instructions tailored to the user’s account.
Out of 10 possible combinations of data import methods (5) and user permission types (2), each user now sees only the messages tailored to their own specific use case.
The mid-phase iteration at right shows these variable messages.
The final iteration, below, shows what a single user would find in the interface.
In context, teachers and school administrators now encounter slight, intentional friction on the Manage Classroom page if the data import method selected by their school district does not function well with manual edits.
This friction produced the intended result by preventing some user errors, diverting other users to the appropriate help channels before they could make manual changes that might cause later issues, and clarifying for users which actions would be a frustrating waste of time even if their permissions status enabled them to perform manual edits.
