Sara Cerutti
CV LinkedIn Email
Work
+A Educação · GPA Live

Evolving GPA through research with students, professors, and coordinators

The research showed where the new experience still broke in real use, and changed the product's priority.

TL;DR

GPA was a legacy academic platform that worked for some profiles and broke for others. I ran heuristic, generative and pilot research before designing, rebuilt navigation, feedback and interface states, and used pilot evidence to move mobile up the roadmap.

Research had to happen inside a project under pressure to launch at any cost: a complex product, a team that changed direction many times, and studies left for later. When the pilot came, I used it to bring evidence back into the roadmap.

Role
Product Designer
Timeline
2024 to 2026
Methods
Heuristic analysis, interviews, survey, production pilot
Product
Academic project management, B2B SaaS

59

students across two classes in the production pilot

0

support tickets identified during the pilot, per the pilot lead's account

55

students surveyed, cross-checked with 3 interviews

Problem

Context

GPA was a legacy platform: stable enough to run, but built around the system's structure, not the people using it. Student, professor and coordinator depend on the same system for opposite things, and the same screen could feel great to one and unworkable to another.

Conflict

GPA was complex, and the team was still working out what it wanted: priorities changed often, the pressure was to launch at any cost, and research was left for later. When the pilot came, it looked like a success: the desktop experience was clear, and students said they'd use it again. But the focus group pointed, unprompted, to mobile, and the roadmap was already set.

Goal

Rebuild the experience from how each profile actually works, not how the system was assembled, with decisions grounded in behavior rather than intuition.

Research

Method, from broad to real

  1. Heuristic analysis of the legacy product: status visibility, error prevention, recognition versus recall.
  2. Generative research: interviews and mental-model mapping of how students and professors organize academic work.
  3. A survey with 55 students, to spot recurring patterns, separate from the pilot.
  4. A production pilot: two classes (33 plus 26 students), about three months, with a focus group, the professor and the coordinator.
The discovery board: one frame per topic, from stakeholders, problem and pains to impact levers, risks, success measures, personas, references and next steps.
The discovery board that organized the research: problem and pains, impact, risks, how to measure success, personas and references.

Key findings

The error had no address

The professor couldn't pinpoint the error inside a generic feedback field.

Correction happened outside the product

Without context in the product, correction spilled into WhatsApp and in-person meetings.

Mobile locked people out

A locked screen, cut-off content, and having to rotate the phone to read.

One laptop, one typist

In a group with almost no computers, one classmate centralized the typing and the rest participated less.

What changed in the product

The legacy form to create a project template: a long grid of Yes/No dropdowns, from enabling mentors to student and professor permissions.
Before: setting up a project meant a wall of Yes/No fields, with no word on what each one changed.
The new project settings: one card per option, each with a description, required items marked, and on/off toggles.
Now: each setting says what it does, and required items are marked.
01

Navigation changes with each profile

Before

One interface for everyone, forcing people to memorize paths.

After

Each profile accesses its own context, and the system anticipates priority tasks.

The mentor's view: a menu with only My projects and Project mentoring, and an empty state that explains what will appear there.
A mentor sees only what is theirs: their own projects and the ones they mentor.
02

Feedback became actionable

Before

Generic correction with no context.

After

A structured flow with clear states: Pending, In review, Returned.

03

The system communicates its state

Before

No action feedback, no inline errors, no confirmation.

After

A full set of states: guided empty states, inline errors, success confirmations.

A new project template, still blank, offering two ways to start: create a stage, or a stage with sub-stages.
A blank template doesn't leave anyone guessing: it says it's empty and offers two ways to start.

Decision

Treat mobile as a participation barrier, not a tweak

What I chose

I brought the finding to the technical and business teams as a participation barrier, not a secondary tweak.

How it was decided

I presented the finding with the pilot evidence, and the team accepted the recommendation: mobile went onto the roadmap at that point.

What I gave up

A portfolio and dashboard request was pushed back so mobile could move up. The evidence for mobile had to outweigh work that was already planned. The portfolio was delivered later, and the dashboard is next.

Evidence

The focus group raised mobile unprompted. In one group almost nobody had a computer, while the professor, on desktop, reported no issues: the same platform was a barrier in one context and not in another.

Consequence

Improved

Mobile moved up the roadmap as a participation issue, and today it is resolved.

GPA on a phone: My projects, with tabs, search, filters and an empty state that fits the screen.
GPA on the phone today: the student's project list fits the screen, no rotating needed.

What the data shows

33%

of sessions come from mobile over the year

48%

from mobile in the busiest class months

26% / 31%

of sessions with frustration signals, mobile against desktop

At the institution with the most sessions, mobile gets more than half of the views on the entry page and the students' project area; at the others, between about 20% and 40%. The pages where professors build and manage, like templates and classes, stay on desktop.

What came next

I stayed on GPA. The portfolio that was pushed back for mobile is the one I designed and delivered in 2026, and the dashboard is next. I'm also designing how external companies and communities can sign up and submit challenges without the institution losing control.

The portfolio management screen: the public page, a notice about projects waiting for validation, and the count of projects already public. The editor's name is blurred.
The institution manages what goes public, and the screen says which projects are still waiting for the professor's validation.
A project page in the public portfolio: cover image, type and year, title and summary, with a side index. The institution's name is blurred.
A project page in the public portfolio.
A student's public profile: name, course, a short bio, contact buttons, location and the list of their projects. The institution's name is blurred.
Each student gets a public profile that gathers their projects, which turns academic work into something they can show.

What I'd do differently

I'd have measured mobile participation before the change, so I could compare the same thing afterward. I don't have a baseline from before, so today the data shows use, not the effect of the change.

What I take from it

The pilot looked like a success on desktop and, at the same time, showed a serious problem on mobile. Research is what separated the two and put mobile on the roadmap.

Mobile is used, but in sessions with a form submission or upload it still trails desktop (about 2.5% against 5.6%). That count mixes student deliveries with forms professors fill in to create projects and classes, so I can't yet say whether mobile limits delivery.

+A Educação. Some numbers and internal details have been generalized for external use.

Next case

Pilot

Designing an AI learning experience for psychology students

From an off-target first version to a pilot in two institutions, in six weeks.

View case study