Featured Case Study · Education Technology / SaaS
Education Technology and University SaaS
An education technology company serving universities and multiple institutional audiences needed to solve two different problems for two different audiences at once: external marketing and recruitment for prospective students, and internal product usability for students, teachers, and staff already using the platform.
Engagement snapshot
- Business model
- SaaS serving multiple institutional audiences (prospective students via external marketing, plus students, teachers, and staff via internal product interfaces)
- Industry
- Education Technology / SaaS
- Work performed
- Treat acquisition and product usability as one connected system: run usability lab sessions and user testing across distinct audience groups (students, teachers, staff) as the primary evidence layer, and let research-driven design recommendations shape both the external recruitment experience and the internal interface work.
- Capabilities
- Personalization, Conversion Optimization, Experimentation
Business context
Education Technology / SaaS · SaaS serving multiple institutional audiences (prospective students via external marketing, plus students, teachers, and staff via internal product interfaces) · Mid-Market.
The business problem
Audience Segmentation
An education technology company serving universities and multiple institutional audiences needed to solve two different problems for two different audiences at once: external marketing and recruitment for prospective students, and internal product usability for students, teachers, and staff already using the platform.
The decision we made
One Research Layer, Two Audiences: usability lab sessions and user testing run across distinct audience groups (students, teachers, staff) as the primary evidence layer, with findings shaping both the external recruitment experience and the internal product interface from the same research base
Research-driven, audience-specific design across external recruitment and internal SaaS interfaces for students, teachers, and staff
What changed
Treat acquisition and product usability as one connected system: run usability lab sessions and user testing across distinct audience groups (students, teachers, staff) as the primary evidence layer, and let research-driven design recommendations shape both the external recruitment experience and the internal interface work.
Observed outcome
Research-driven, audience-specific design across external recruitment and internal SaaS interfaces for students, teachers, and staff
What this teaches
Recruiting prospective students and serving students, teachers, and staff already on the platform are two different problems with two different audiences, but usability lab sessions and user testing run across all of those audience groups functioned as one connected evidence layer, surfacing interface and workflow problems that survey or analytics data alone wouldn't have caught, and shaping design decisions on both sides of the engagement.
How we would apply AI today
Today, AI would accelerate the personalization work behind this engagement: synthesizing evidence about the audience segmentation pattern faster, drafting audience-specific page and message variants for review, and learning from what visitors actually do so the next iteration is better-informed. Expert judgment still decides what to test and what the evidence actually means; AI speeds up the work, it doesn't replace the decision.
Who this fits
This approach is useful when:
- Education technology or SaaS platforms that must serve both external prospects (recruitment, acquisition) and internal end users (existing customers, staff) with fundamentally different needs
- Organizations with three or more distinct internal user roles (e.g., student/teacher/staff) sharing one platform, where a generic one-size interface is underserving at least one role
Questions this case study answers
- Do you have both an external audience you're trying to recruit or acquire and an internal audience already using your product, with no shared research process between the two?
- Do students, teachers, staff, or other distinct roles on your platform currently see the same generic interface?
- Have you run usability testing or user testing with each of your distinct audience groups separately, or only aggregate analytics across all of them combined?
- Are your acquisition-side design decisions and your product-usability design decisions currently made by disconnected teams or processes?