Redesigning the Family Experience for Mobile-First Use
Family users needed a way to track their students' academic progress, but our legacy platform was fragmented and completely unusable on mobile devices. Through Object-Oriented UX methods and collaboration, we created the first iteration of a mobile-responsive, connected system that gives families quick access to key information without excessive clicking.
My Role: UX Designer
Collaborators: Product Designer (UI), Product Director (Project Management), Frontend Development Team
Skills: User Research, Object-Oriented UX, Information Architecture, Workshop Facilitation, Wireframing, Prototyping, Usability Testing
Tools: Figjam, Google Forms, Dovetail, Figma, Maze
Problem
Our team was embarking on updating our platform with a new component library, user type by user type, starting with family users. This was an opportunity to improve their experience.
Family users had an interface that was essentially a copy-paste of the student experience with limited functionality and zero mobile optimization; some features were unusable on phones, especially on table-heavy pages. Information was fragmented across multiple areas of the platform, making it challenging for families to get a quick overview of how their student was doing in school.
Continuing this outdated experience risked undermining district satisfaction and retention, and we knew some districts were avoiding engaging their families in the platform because of a lack mobile responsiveness.
Challenge
How do you redesign a fragmented system into a connected experience while accounting for all existing functionality and content?
Solution
We designed the first iteration of a redesigned family user experience for the first milestone of features.*
I used Object-Oriented UX and other methods to design a structure that better honored the relationships between objects, reducing navigation friction and prioritizing important information.
*This is a long-term ongoing project so this section may change and develop as the impact becomes more clear.
My Approach
Discovery: Understanding What Families Need
I led a session with my product team to map out our assumptions and questions about improving the family experience, creating a foundation for focused discovery work.
I reviewed family-related feature requests across support channels. Better mobile access topped the list, and quicker access to what assignments their students were missing was another consistent request.
I created a survey to understand how parents use digital platforms to track their children's engagement and school communication. With limited school access during summer, we started with parents within our organization, including several who used our platform in their own children's districts. While not perfectly representative, it helped us unpack assumptions and gave us a starting point.
I reviewed several competitor platforms, focusing on how they provided overviews, structured navigation, and organized information. I gathered annotated screenshots in FigJam for team discussion. This informal effort revealed that we could improve on competitors simply by being mobile-friendly and better structured.
From this discovery, we established a clear vision for success: a mobile-first experience with easy navigation, quick access to key information from a cohesive hub, clear communication from teachers and schools, and a simple design that reduces confusion.
The product director and frontend lead made a key scoping decision and decided we'd focus on improving current structure without adding new features. This meant postponing new notification and communication features discovered during initial research, but we'd build a solid foundation for adding them later.
I documented all of this in a Project Brief to guide our work.
Deliverables: Questions/Assumptions Tracker, Feature Request Summary, Survey and Survey Results, Competitor Analysis Screenshots, Project Brief
OOUX Audit: Mapping System Structure and Identifying Opportunities
I mapped our current system structure to identify opportunities to improve information architecture and navigation. I documented all objects family users could access and analyzed their relationships using object maps. I time-boxed this effort instead of creating a polished artifact because this was exploratory work. I’d return to it in later design to use as a tool.
Next, I facilitated a session with the product team to review the objects family users had access to and determine what they actually needed. We also audited the CTAs (calls-to-action) available on each object to ensure we accounted for appropriate functionality levels.
This exercise revealed some low-usage or problematic legacy features we could consider sunsetting during this effort.
We also identified opportunities to better connect the most important data for family users.
For example, assessments and standards were fragmented in ways that didn't represent their full relationships. Users could see which assessments evaluated a standard, but not which standards an assessment evaluated. You couldn't click on an assessment under a standard to see the student's performance on it. This fragmentation likley contributed to our most common user complaint: too many clicks to get to information.
Deliverables: Object Maps, CTA Audit
Designing the Student Dashboard and Navigation
With key objects identified, we tackled structure and navigation. We knew families needed an easily accessible overview of their student's engagement, so we focused on designing the right home page that could surface high-level information about the most important data.
One constraint shaped the start of the experience: family users had to access student information one student at a time, like switching profiles on Netflix. This meant building seamless student switching into our navigation. Fortunately, similar profile selection existed in other parent apps and consumer products so we could leverage familiar patterns.
I created initial navigation flow variations and sketches of a potential home page / dashboard. In a typical OOUX process this comes later, but we needed to give the frontend team early direction on structure to inform their own work.
I planned and facilitated ideation workshops with the frontend team to refine our design for the Student Dashboard and navigation using my sketches.
We also explored navigation menu options within our new component library, aiming to use out-of-the-box components as much as possible.
Deliverables: Navigation Flows, Sketches, Workshop Assets
Testing Navigation and Student Dashboard
Before moving forward with additional design, we wanted to test our navigation and homepage, particularly the student-switching functionality, which was a significant change from the legacy experience. We also wanted to test removing certain legacy features and renaming features with unclear names.
I turned earlier sketches into a low fidelity wireframe, then linked them into a simple clickable Figma prototype.
I created a simple survey similar to a tree test to assess feature naming and understandability, asking colleagues to circulate it among non-Otus-using parents in their networks. I also created a short usability test, using colleagues from other teams as surrogate users to compensate for limited access to clients during summer.
Based on the results, the student selection process was understandable, people could successfully switch between students, and the Student Dashboard's intent was clear.
The navigation test revealed which features were chosen incorrectly most often, showing opportunities to improve feature naming. However, we couldn't rename things just for family users without risking confusion across other user types, so we tabled renaming for later consideration.
Deliverables: Wireframe, Prototype, Usability Test, Tree Test, Summary Test Results
Designing and Testing Core Features
It was time to design the features of the first milestone in more detail: classes, assessments, lessons, and standards. These were the most frequently used features and core to our platform.
For each object, I ranked the importance of attributes, sketched cards, and created additional wireframes, using the navigation flow as the foundation. I filled in each screen while considering filtering, sorting, and grouping for list pages.
I did another round of testing with internal surrogate users, and then incorporated feedback as I worked with the frontend team and product designer to create high-fidelity mock-ups using our new component library, focusing on simple, out-of-the-box implementations.
Along the way, the frontend team also created a frontend-only proof-of-concept in code so we could experience the redesign more authentically and use it for future testing.
We began using real content from real users in mockups, which exposed problems. For example, we found that listing all classes with their grades on the homepage made it extremely long, especially since most students have 9+ classes and many districts have multiple types of grades per class. We decided to move this info only one click away in the Classes page to make the Student Dashboard more digestible.
Eventually we landed on a more stable prototype for the first milestone of features. As the frontend team’s work shifted toward connecting the backend, we conducted ongoing testing with our district clients to continue identifying improvements.
The feedback revealed some small opportunities to improve clarity of certain minor elements, but overall testers were successful in navigating and finding key information. A tester from one district that has eagerly awaited this redesign shared that it had “everything a family member needs to answer their main 2 or 3 questions."
Deliverables: Wireframes, High-Fidelity Mockups, Prototype, Usability Test Results
Reflection
So, how do we redesign a fragmented system into a connected experience while accounting for all existing functionality and content? Here's what I learned:
Use OOUX to audit your existing system and guide improvements: An OOUX-driven approach helped me design more connected pages where users could navigate contextually, following the natural relationships between objects. This made navigation easier and reduced the "too many clicks" problem that plagued our legacy platform.
Make sure to use real content: Plugging in real content from actual users illuminated more opportunities to improve. We started to do this earlier in next milestone
Test regularly: Ongoing testing can be challenging to sustain, but it is helpful to gut-check redesign decisions early and often in a big project when you are creating the foundation of a system.
Bonus: Establishing a Repeatable Process
After the first milestone was more stable, I began working on the next milestone of features, which were much more data-heavy. By this point had developed a repeatable process for redesigning each feature. This process ensured nothing was overlooked, especially with intricate objects containing many attributes.
For each feature, I would:
Gather reference screenshots of the legacy feature.
Create an object map showing objects, relationships, and attributes; audit CTAs or actions family users could take. The old object map from discovery was helpful here, but in this phase I used more care because it would be my guide for making sure all important data and functionality would be retained.
Sketch lo-fi, high level navigation flows focusing on how users would click through to object details—multiple variations as needed to ideate.
Sketch modular cards for each object considering its important attributes.
Plug components into navigation flows along with needed CTAs to create rough wireframes.
Assess UX strengths and issues to create variations in structure.
Plug in rough wireframes with real data from a district's implementation, and evaluate.
Collaborate on mid or high-fidelity designs with the product designer using the component library and create a testable prototype.
This systematic approach has allowed us to quickly design subsequent features to get them ready for testing.