The feature users loved to leave: Building saved views to stop the spreadsheet exodus
TL;DR
The challenge: NYC's 10,000+ educators were abandoning the Portal's most-used feature. They were forced to rebuild their grid setups every morning and ultimately exported to static spreadsheets, defeating the platform's core value of live, updated data across 900+ columns.
My solution: Designed a hybrid view system with role-based templates plus custom saved views, featuring intuitive save/manage controls and sidebar organization.
The impact: Support tickets about session timeouts dropped 80% (from ~15 to 2-3 weekly), feature abandonment dropped from 60% to 20%, and users returned to working with fresh daily data instead of static exports.
My role
Lead Product Designer responsible for user research, stakeholder alignment, and design strategy.
Before and after of the student profile page
Scroll to learn more
01The great spreadsheet migration
Our student profile data grid served 10,000+ NYC educators daily, but it was driving them away. Users faced all 927 columns at once, creating an overwhelming interface. New users would abandon it immediately, while experienced users rebuilt their entire setup every morning after session timeouts or school switches.
Users abandoned the Portal entirely, exporting to Excel and Google Sheets just to preserve their work. This defeated our core value of fresh, daily-updated data as users traded live information for static snapshots.
02From Symptoms to Root Cause
Initial support data showed a high volume of session timeout complaints where users would configure their grid, navigate away to other tasks, then return to find their work lost. This led us to assume users simply needed save functionality.
Through 8 interviews with principals, counselors, and teachers, I discovered that session timeouts were just the final straw in a much larger workflow problem.
- 927-column cognitive overload forcing lengthy daily setup
- No role-appropriate starting points, so everyone began with the same overwhelming interface
“I’d spend 20 minutes setting up my grid, leave to help a student, then come back to find the system logged me out and all my work gone. Now I just export to Sheets instead.”
- Quote from a support ticket received
03Designing with constraints
This made me realize we needed to shift. Instead of just adding the ability to save, how might we give users role-appropriate starting points while maintaining flexibility?
Our MongoDB architecture limited how much view data we could efficiently store, but this constraint led to a better solution. After multiple meetings with engineering, product managers, and school liaisons (where various teams initially wanted their own specialized templates), we established 5 core templates covering essential use cases.
Three view types emerged:
Template views
Role-based starting points (5 options, 10 columns max) prominently displayed in a sidebar for fast performance and focused workflows.
Custom views (called My views)
User-created configurations for flexibility. Could be created from a modified template view, or created from scratch.
Default view
A simplified view with 7 columns max that covers essential student details. This would be the first thing users see when they land on the data grid.
04Core interface design
The interface centered on an intuitive split-button save control. 'Save Changes' was prominently displayed with 'Save As New' accessible via dropdown, plus quick view switching via sidebar. We also added a save prompt that appeared whenever users navigated away from the grid, preventing work loss during session timeouts.
To accommodate new controls without overwhelming the interface, I restructured the page into two stacked menu bars: grid-related actions in the top bar, student-related actions in the bottom bar.
I tested this split-button concept with 5 users to ensure the distinction was clear before finalizing the design. Users immediately understood the primary action while easily discovering the secondary option.
05Supporting workflows and validation
I also designed a workflow for creating views from scratch. Users could click a plus icon next to custom views to open the edit columns modal with no pre-selected columns, then name and save their new view.
Before launch, I conducted usability sessions with 4 users to test the end-to-end workflow of switching between views and saving configurations, which confirmed the new system was intuitive and significantly faster than their previous manual setup process.
06Impact
Three months post-launch, results validated the approach:
- 80% reduction in support tickets about session timeouts and lost work (from ~15 to 2-3 weekly)
- Feature abandonment rate dropped from 60% to 20% as educators stopped avoiding the grid
- Average sessions per user per week increased from 2.3 to 4.1 showing sustained engagement
- Percentage of users creating custom views increased from 15% to 55% demonstrating deeper adoption
Follow-up interviews confirmed users appreciated accessing fresh data daily without setup burden, restoring our competitive advantage. Users also requested view sharing with colleagues—a feature we had identified during initial research but decided to prioritize for a future release.
“Before, I’d spend the first half hour of my day rebuilding my graduation tracking view. Now I just switch to my saved view and I'm immediately seeing which students need interventions.”
- From a guidance counselor, post launch
User research reveals root causes, not just symptoms.
What seemed like a simple "save button" request became a complete workflow redesign once I understood how different roles used the data grid. Eight user interviews uncovered that the real problem wasn't saving configurations. It was starting with role-appropriate ones. This taught me to dig deeper into user workflows before jumping to solutions.
Technical constraints can drive better design decisions.
MongoDB's storage limitations forced us to choose 5 focused templates over dozens of specialized ones. Rather than fighting these constraints, I used them to create a cleaner, faster experience that served users better than unlimited flexibility would have. Sometimes the best solutions come from working with limitations, not around them.
Stakeholder alignment requires strategic compromise.
Getting various team members to abandon their specialized template requests took extensive negotiation and user data analysis. I learned that focusing on core use cases (attendance tracking, GPA trends) and showing how constraints benefit the user experience was more effective than trying to accommodate every stakeholder request.
08What I’d do differently
I would have tested the two-bar layout concept with users before implementation. While the two-bar solution worked well and solved our space constraints, getting user feedback on the grid vs. student action separation earlier could have validated this approach and potentially revealed other layout solutions I hadn't considered.
Next Project
Student Profile: A UX case study on improving academic success
