Driving Client Retention Through Optimizing Staff Access to Student Data


Company: Panorama Education, an EdTech company that supports 15 million students in 25,000 schools across 50 states


Project Summary

I led the experience design and user research to launch a Support Staff to Student Group Data Access Mapping tool.


Design Strategy

Experience Design

Prototype & Usability Testing

User Interviews

Timeline & Team

6 weeks start to finish with 3-person fully remote team of 1 Designer (me), 1 Product Manager, and 1 Developer.


When school districts implement Panorma's products, staff members who do not directly teach courses cannot see data for the students they are working with.


+ This data visibility barrier prevents school support staff, such as counselors, coaches, and interventionists, from being able to provide students the support they need.

+  Many clients express frustration with this lack of student data access for their critical staff.


I led this 6-week remote project from research through launch and collaborated closely with a product manager and 1 engineer.




My product manager and I conducted 15 remote interviews to better understand the challenges clients faced and learn more about the workarounds they used to address the problem.

What we learned was that clients fell into two camps:  

1.  Some devised elaborate workarounds to solve this issue. 

2.  And there were those clients who had abandoned using our products with this staff.   This second category of clients posed a churn risk, so it was crucial that we quickly provide a solution for them.



We also spoke to designers and PMs in the product areas most affected by this lack of data access for support staff.

1.  We learned that this lack of visibility touched many products in Panorama.

2.  Whatever solution we landed on would need to be product-agnostic to ensure we could drive the most impact we could.


Our research was invaluable in defining user personas.  Distilling these personas into jobs-to-be-done crystallized who I was creating the solution for.



These jobs-to-be-done helped to define the high-level requirements for what would be a new tool to map student data access for a support staff member to a group of students they were assigned to.  


This access would, in turn, allow the support staff to access the students across all the Panorama products their school was using.


Based on these requirements, I ideated solutions for 15% of the designsThe purpose of these initial designs was to help establish an L-0 engineering estimate and determine the engineering capacity for this project.

1.  In collaboration with our engineers, we wanted to determine the smallest possible slice of work we could deliver in the fastest amount of time to present a viable solution to the client.

2.  These lo-fi designs were invaluable in orienting the team around the solution's absolute must-haves.

3.  They were also important in determining what were nice-to-haves and what was outside of scope but might be included in future improvements to the tool.



As part of my duties, I kept stakeholders in the loop throughout the course of the project.  Once the MVP solution was agreed upon by the team, we brought it to our stakeholders to align on our project plan and the expected business impact of our solution.  

After finalizing the MVP solution with the team, we presented it to the stakeholders to discuss our project plan and the expected business impact. Our stakeholders approved our proposed solution, giving us the green light to proceed.



The School Admin wants to assign a caseload of students to one of the school psychologists.  As part of this workflow, the admin opens up the data access tool in Panorama.


1. A CTA to create a new support staff to students access mapping.

2.  A list of all the access list groups at the school.

3. Details about each access group are quickly viewable.

4. The admin can make updates to the contents of the access list.



The admin selects the counselor staff and adds students from the caseload file.


Our discovery showed that the school admin usually kept a file of students who were then added to this list.   

My initial solution was for them to use a CSV upload to add students to this part of the flow.   However, the technical difficulties of mapping students accurately via CSV would have ballooned our timeline of releasing in under six weeks.  As a tradeoff, we went with the manual selection of students instead.




When the admin needs to make updates to the group of students the counselor has access to, the admin can easily do this within the tool.




In collaboration with our engineer, I determined we could further cut scope, and deliver faster on an MVP, if we simplified the main page for the tool. 




We wanted to quickly validate these 30% designs to ensure we were on the right track.

Using a tool called Maze, I conducted moderated and unmoderated testing.


1. The focus of the testing was to understand specific use cases that would need to be supported in order for clients to adopt the tool.

2. Also, I wanted to validate our decisions for what to include, and not include, for the MVP release.

3. We also wanted to learn how this new tool would best fit into existing workflows for school districts, and how we could best support our clients in helping their admin staff in knowing when and how to use the tool.



Through our tests, we found that they didn't miss the ability to use a CSV upload, but they wanted the ability to batch-select students.

With this in mind, for subsequent design iterations, I moved towards using a data table to display and allow batch actions for selecting students.



The testing also revealed that clients saw filtering down to a subset of students as critical functionality.

"We need to find students based around gender and other demographics.   We don’t want to endlessly scrolll to find a kid.”

- Usability testing participant


We heard from clients that they often needed to form groups of students around a set of demographics, with grade level or gender being the most common. Additionally, many clients formed cohorts of students based on last names. Including filters that reflected the most common use cases would allow the client users to find quickly and group sets of students.



Partnering with our engineer, we made the hard choice of de-scoping other parts of the design in order to include time for engineering to build out filters.


Part of the trade-offs was removing the stepper flow in favor of a long form, which would allow the inclusion of this critical functionality.



This new user to student data access mapping tool is slated to be developed at the end of Q2 2024.

Key Outcomes & Results

+ This release is critical in providing key functionality, and reducing the risk of clients churning due to the lack of this feature.

What I Learned

+  Launching with some value sooner is better than waiting for the ideal later.  

As always, working closely with the smart and amazing people in my cross-functional team yields invaluable sights that drive forward the goal of having user-centered solutions.


Selected Works

Thanks for stopping by!

If you think I might be a good fit for your project or team, here are my contact details:

Email: qsbrown3@gmail.com   LinkedIn: www.linkedin.com/in/qbrown452