Intrado
5 Months
UX Researcher
Heuristic Analysis
Competitor Analysis
Workshops
User & Stakeholder Interviews
Unmoderated Testing
User Personas
Empathy Mapping
Project Manager
UX Researcher
UX Designer
Intrado's SchoolMessenger is a mobile application that helps connect parents and their child's teacher. Teachers can send out broadcast, one-way messages or engage in a back-and-forth chat with their parents in order to keep them updated on what's going on in their classrooms.
The SchoolMessenger platform was in desperate need of an overhaul. The UX and UI were both very outdated and largely built by developers with minimal thought given to design. Additionally, the feature set did not meet current user needs.
How might we balance the needs of both the teachers and the parents while not becoming a clone of competitors?
1) Research how parents and teachers were currently using the existing application.
2) Understand limitations of the existing product for the redesign.
3) Redesign the product to be more user-friendly.
We delivered to the Intrado team a pair of mobile prototypes that was heavily researched and backed by a plethora of usability testing. Our prototypes consisted of two versions: the MVP version that could be built within their timeframe, as well as a 2.0 version that expanded the feature set of the original platform.
To understand what we were working with, we first had to take a deep dive into evaluating the existing SchoolMessenger product. This allowed us to understand what was working well and what could be improved.
The initial SchoolMessenger platform was very simple. There were only a few features, but because they were built by developers, not enough focus was placed on usability. Leaning on our expertise, we evaluated the product on a qualitative level.
The recipient Inbox needed a major overhaul in many different facets.
We didn't want to limit ourselves to simply reskinning the product and improving a few patterns—we wanted to identify areas where we could bring additional value to the product. Looking at competitors helped us understand where we could flesh out or add some of these features. The challenge here was that we had to rely on 3rd party demos (like YouTube videos) to fully understand features since we didn't have access to competitor platforms.
After the evaluation phase where we gained a thorough understanding of the product (and its faults), we were ready to gain insight from key stakeholders.
We started with a workshop where we were able to gather stakeholders from a number of different departments together and talk through how to improve the SchoolMessenger application. Our workshops took place in two 2-hour sessions over two days. We discovered nuanced problems and ideated solutions to user pain points as a group, with each participant representing a different department, such as Sales, Marketing, and Product Development.
Our HMW questions were generated by the results of Day 1 for use on Day 2 (pictured here).
After conducting the workshop, we put together a preliminary feature roadmap, ranked in order of priority. Since we worked on this as a team within the workshop, we had already had buy in from stakeholders on how we would build the MVP version of the product.
We mapped out our generated ideas to determine a priority order for new features.
It wasn't just enough to create this roadmap, we had to understand the feasibility of some of these items. Taking what we learned in our workshops, we conducted interviews with our stakeholders to learn of any roadblocks that may occur when building out our MVP.
While we had spoken extensively with stakeholders at this point, we still needed to understand how users felt about our roadmap and whether there was anything missing. We identified a few additional features that we added to our roadmap during this stage.
One exercise within the workshop (and backed up with subsequent user interviews) helped us identify nuanced personas that went beyond just broad personas. For example, our personas weren't just parents, but they were divorced parents that needed to manage contact preferences, or temporary guardians who should only be allowed to access certain parts of the application.
Our personas captured the minutiae of our users.
After determining what we were building, we then had to figure out how it all fit together, not only from a practical perspective, but how the user would feel along the way.
Utilizing our personas, we mapped out the journeys a user would go through during each phase of interacting with the product. This helped us pay special attention to user needs that may not otherwise be as readily apparent. We mapped out both the current state of things as well as our ideal state based on our to-date research.
Most of the existing experience was fairly negative.
Although the application wasn't particularly large, it was still important to create user flows so that our design team knew what to build and what permutations a user might encounter. We paid particular attention to the onboarding flow, which we had previously identified as a major pain point for users, by adding additional steps to sync a user's data with the School Information System.
Before, during, and after our design team went to work, we conducted extensive usability testing to understand the pain points of our users.
All in all, we conducted roughly 20 individual usability tests via UsabilityHub. We wanted to understand broad perspectives about school messaging, opinions on how competitors were solving their problems, and whether our own solutions made sense to our target demographic. We used a variety of strategies during these tests including:
The sheer amount of usability testing that we did demanded a synthesis report. Overall, the designs tested very well, but there were some instances that we identified where improvements could be made, such as grouping together more closely the sender and recipient information.
Overall our tests performed very well, but we did make some alterations based on the results.
We delivered our initial MVP prototypes on time and under budget. Our 2.0 version continued to be refined by our team and underwent additional usability testing to make sure that it was the best possible version of the app that it could be, even though it's likely that that version would not be developed until 2024.
