Case Study — gyde
Admin Dashboard Redesign
Redesigning a B2B learning platform's admin tool so that no task has a prescribed path — and no admin has to know the data model to get work done.
- Role
- Product Designer
- Company
- gyde · EdTech, B2B SaaS
- Timeframe
- 2024/2025
- Team
- Two-person design team with the design lead; entity architecture shaped iteratively with the product team
- Initiative
- The push to rebuild rather than patch came from me and the PM
- Scope
- User journeys, flows, information architecture, all screens incl. CRUD patterns and system states
TL;DR
The problem
After gyde pivoted from running its own coaching programs to selling the platform as B2B SaaS, the admin tool still forced every task through one linear path — starting at “Companies”, a concept external admins never needed.
The decision
Replace the forced flow with an omnidirectional assignment model. Users, courses, tags, and cohorts became equal entry points; every relationship can be created from either side.
The result
A task like “enroll 30 employees in a mandatory course” went from 30 individual booking entries to a single tag assignment — and first-time admins get a guided path without it being the only path.
01 · The moment
A first-time admin lands on the Companies screen — and freezes.
Anna is the persona this redesign was built around: an HR manager at a mid-sized company, responsible for getting 30 employees through a mandatory training. She opens the admin tool maybe once a week, and her goal was never to understand the system — just to get her people through a course.
Walking her journey through the existing tool, the first documented reaction after signing up reads:
“Overwhelmed. She doesn't know what to do first.”
Anna isn't a real user — but the dead end is real. The persona walkthrough exposed a structural collision: a target user with a clear task, and a tool whose first question — “Which company?” — has nothing to do with that task.
02 · The problem
The tool outlived its product.
The old design wasn't bad — it was correct for a product that no longer existed. What survived the pivot was its root flaw: forced linearity.
The admin tool began as gyde's internal instrument for running its own coached learning journeys. In that world, every journey was the same construct: a coach, a fixed group, learning content — bound to a client company. The architecture mirrored that reality precisely. Then gyde pivoted: the platform itself became the product, sold to external companies who manage their own content, users, and programs.
| Before · internal | After · B2B SaaS | |
|---|---|---|
| Who administers | gyde staff | External admins at client companies |
| Coach | Always present | Optional |
| Time constraint | Always present | Optional |
| Course | Part of a journey | Independent entity, flexibly assignable |
| “Company” | The natural entry point | Background concept most admins never touch |
The push to rethink the tool rather than patch it came from me and the product manager at the time. Mapping the legacy flow end to end made the case: to publish one group, an admin had to prepare a company, a booking, a coach, and every participant — in that order, across 13 separate modals and four different screen layouts for a single group's lifecycle.
- 01Company
- 02Booking
- 03Group
- 04Sessions
- 05Participants
- 06Coach
- Publish
05 Participants · Participant missing? Interrupt the flow, create the user, find your way back.
13 modals · 4 screen layouts · one directed path
The structural consequence: a linear process has exactly two exits — completion or abandonment. Any missing prerequisite interrupted the entire task. And the misleading vocabulary (“Bookings” meant course entitlements, not appointments) made the first hurdle a conceptual one. The real design challenge was not “simplify the UI” — it was making a maximally flexible data model usable for someone like Anna, who doesn't know what a tag is, and shouldn't have to.
03 · The principle ★
No prescribed path.
Admins start where they already are — and create the missing relationship from there.
Every relationship works from both sides
Instead of shortening the old flow, the position I argued for was to remove its inevitability altogether. In the new model, the four central objects are equal entry points, and every relationship works from both sides.
This is not a diagram-only claim — it's how the shipped flows work. The same cohort membership can be created from either end: starting at a user and picking cohorts, or starting at a cohort and picking users. Both produce the identical relationship.
The assignment modal itself is context-aware: one component serves users, teams, companies, and tags, knows where it was opened, and only asks for what is still unknown. And creating an entity is never a dead end — a newly created user can be assigned to courses, tags, or cohorts in the same context, without a detour.
Freedom without orientation would be as bad as force without alternatives. The guided, step-by-step creation flow still exists — for first-time setups and for users like Anna. It's just no longer the only way through the system.
04 · The system
Three assignment types.
The flexibility works because the assignment types are deliberately different — not interchangeable.
Direct
1 : 1User ↔ Course
A user gets access to a specific course. Simple, one-off.
Free · via tags
O(n) → O(1)Tag ↔ Users · Courses
Tags group users independently of any company hierarchy. Entitle the tag once, and every member inherits the course — 30 individual assignments become one.
Time-bound · via cohorts
ScheduledCohort ↔ Users · Courses · Sessions
A cohort bundles users, courses, sessions, and optionally a coach into a scheduled program — the old “learning journey”, now one option among several instead of the only model.
The entity architecture — cohorts, tags, teams/companies, system users — took shape iteratively with the product team, including an explicit evaluation of tags against a pure company hierarchy. Hierarchies are rigid: a course shared across two departments must be assigned twice, and the structure breaks as organizations grow. Tags cut across hierarchy — which is exactly what course entitlement needed.
05 · What changed
Seven structural shifts.
| Old | New | |
|---|---|---|
| Entry point | Companies, mandatory for everything | Users, courses, tags, cohorts — all equal |
| Group creation | 3 disconnected modals | One coherent creation flow |
| Group lifecycle | 4 separate screen layouts | One detail view with a status indicator |
| Course entitlement | “Bookings” tab inside a company | Assignable from any object, both directions |
| Mass assignment | n individual entries | One tag entitlement |
| First-time experience | Empty Companies screen | Self-onboarding flow + actionable empty states |
| Edge cases | Decided ad hoc in implementation | Designed states for loading, errors, conflicts, duplicates |
06 · Takeaways
What I took away.
Mental models beat database structure.
The old tool mapped the database accurately and still failed its users. The point where a technically correct system becomes a usable product is when it maps how people think about their task.
Naming is information architecture.
“Bookings” for course entitlements cost every new admin real comprehension time. Terminology is an interface, not a detail.
Linearity forces completeness or abandonment.
An omnidirectional model lets people work with incomplete information — interrupt, fix, resume from anywhere. For admin tools, that is the difference between a workflow and a wall.
The user journeys, flows, and entity architecture were developed iteratively with the product team — the initial impulse to rebuild instead of patch came from me and the PM. The interface itself was a two-person effort: the design lead and I designed every screen, including the CRUD patterns and flows that emerged from the new assignment model.
Full analysis — complete data model, detailed legacy workflows, and the full feature comparison — documented separately; available on request.