Jules Bennett

CASE STUDY 001 · GOGUARDIAN DISCOVER

K–12 tech leaders were flying blind on $1.5M in app spend.

Discover is a 0→1 product that tells district technology leaders which software their schools actually use, what it costs, and whether it's safe to keep. I led the design from the first district interview through alpha. There was no existing product to borrow a mental model from — that was the hard part, and most of why the work was worth doing.

OUTCOME — contributed to $4M in projected 2026 bookings

ROLE
Lead Product Designer
TEAM
Me · 1 PM · 1 tech lead
TIMELINE
Summer 2025
PLATFORM
Web app
I OWNED
Research · IA · UI · prototype
The GoGuardian Discover dashboard showing license cost, cost per user, apps used, and a ranked Top Apps table
The shipped alpha. One screen a director can open in a Tuesday budget meeting and defend a renewal from — cost first, usage right behind it.

THE PROBLEM

Big decisions, made with no data behind them.

Districts run thousands of apps across students and staff — easily millions of dollars a year in licenses. Almost none of the technology leaders I talked to could tell me which of those apps people actually opened. Renewals came down to relationships and whoever sent the loudest email. One tech director called it, to my face, “the Wild West.”

GoGuardian was already trusted inside these districts for its admin and classroom tools, and the usage signal was sitting right there in the network. The product to make sense of it wasn’t. My job was to turn data nobody had asked for into one view a leader could open before a budget meeting and actually trust.

THE THREE QUESTIONS NOBODY COULD ANSWER

  1. Q1

    What are we actually paying for?

  2. Q2

    Is anyone using it?

  3. Q3

    Is it approved, compliant, or just redundant?

WHERE I STARTED

No product to react to, so I started with people.

I ran twelve interviews — CTOs, IT admins, and curriculum leaders — before I drew a single screen. The thing that kept tripping us up showed up early: “ROI” meant something different to every person in the room.

The CTO meant cost per license. The curriculum leader meant whether kids were actually learning. The IT admin meant privacy and approval status. Optimize hard for one of them and you’d quietly fail the other two. That tension became the whole design problem.

Research synthesis: District CTO defines ROI as cost savings per license, Curriculum Leader as learning impact and engagement, IT Admin as data privacy and approval status
Generative research synthesis. Three readers of the same word, and the design implication: build one flexible system that serves each of them without burying any.

STRUCTURE

Organized around decisions, not data feeds.

I worked out the IA and the core journeys with my PM and tech lead in FigJam before anyone prototyped anything. The rule we held to: structure the product around the decisions people were trying to make, not around the data we happened to have.

It shipped as three surfaces — a Dashboard for what needs attention now, an App Catalog for searching the whole portfolio, and App Detail pages for the renewal, compliance, and usage drill-downs.

Information architecture map paired with the acquisition-to-activation user journey
IA hierarchy beside the acquisition-to-activation journey — the working-session artifact the build was scoped from.

WHAT TESTING CHANGED

Six users, seven tasks, four pivots — one I'd argued for.

I ran a moderated study with six participants across seven tasks, onboarding through app-level decisions. Most of the core flows held up — a good sign for the value proposition. Two didn’t, and the one that stung was the export flow: the screen a CTO uses to build a renewal case for their board.

Evaluative research summary: overall usefulness 5.8 out of 7, with ease-of-use scores per task
Overall usefulness landed at 5.8/7. Export (5.4) and finding problem apps (4.8) were the two scores I couldn't argue away.

That export flow had been built on a pattern inherited from GoGuardian Admin, where it was made for IT admins managing device fleets. Discover’s export users aren’t doing that — they’re making a case to a school board. I’d had a hunch it wouldn’t transfer; the 5.4 gave me something better than a hunch to bring to the table. We rebuilt the flow around what people actually do with the file, and because the pattern was shared, the fix improved GoGuardian Admin too.

Four pivots based on testing: elevated app approval status, AI contract parsing, proactive license notifications, and an improved ROI scatter plot
The four pivots, each tied to a score or a user signal — not a preference.
“Jules excels at navigating abstract problems and translating them into thoughtful, evidence-based recommendations.”
JENNY THAI — PRODUCT MANAGER, GOGUARDIAN

WHAT HAPPENED

It earned its spot on the roadmap.

The $4M figure isn’t a model. It’s what CSMs heard directly from districts in the pipeline who finished the alpha and said they intended to buy — real intent, not a forecast.

A participant from Los Angeles Unified — the second-largest district in the country — told us it was further along than anything they’d seen from our competitors at that stage. Another said, unprompted, that they planned to advocate for it at their school board meetings. Those two sentences moved the roadmap conversation more than any deck I could have made. I owned the design; the win was the team’s.

$4M

in projected 2026 bookings the team attributes to Discover's alpha and validated fit.

12

districts in generative research, with every design decision traceable to one of them.

5.8 /7

overall usefulness in testing, with core workflows scoring 6.4–6.5.

THE SHIPPED ALPHA /

App Catalog — a searchable, filterable table of every app with unique users, usage time, and impact

WHAT I'D KEEP, WHAT I'D CHANGE

Two things this one taught me.

WHAT I'D CHANGE

Inherited patterns do not transfer for free.

I carried the export pattern over from GoGuardian Admin because reusing it felt efficient. For these users it wasn't. One prototype session up front would have caught it; instead it cost a redesign cycle. I'm less precious about reuse now, and quicker to test it against the actual context before I lean on it.

WHAT I'D KEEP

AI earns trust by being specific.

The contract-parsing feature worked because it did one thing: it killed the worst part of manual license entry and showed you the result. People didn't trust it because it was 'AI.' They trusted it because they could see exactly what it did. Given the choice, I'll take a narrow, visible win over a broad capability every time.

NEXT CASE STUDY — 002

Six products, no shared parts.

READ →