ClassOwl

01 Context

ClassOwl is a growing EdTech platform used by 10+ Swiss schools — the system teachers, students, and parents rely on to run daily academics that otherwise sprawl across spreadsheets, email, and SharePoint. Replacing that status quo is the whole pitch: it's why a school signs, and it's the bar every flow has to clear.

I joined as the sole designer, working directly with the two founders and a small engineering team. Even with real schools already on the product, the entire design function ran through one person — and the work pulled in two very different directions, which is what this case is about.

02 Lists

Problem

Lists is one of the most-used utilitarian features in ClassOwl: teachers generate printable lists of students, parents, or staff for everyday needs — tracking who submitted what, printed name badges, class rosters. It's unglamorous, high-frequency, and exactly the kind of feature that quietly costs a product its users when it's awkward to use.

By the time I picked it up, three problems were working against it.

It was fragmented. The same job — build a list — lived in more than one place in the product, with a different interface depending on whether you were listing a class of students or the teaching staff. There was no single, predictable way to do a routine task, so users had to relearn it depending on where they started.

The creation flow didn't guide. The existing "create list" modal exposed every option at once in a two-column layout — title, ranges, fields, layout, sorting, sharing — with no clear order of operations. For something most teachers do occasionally rather than daily, that put the full complexity on them upfront, leaving it unclear what to fill first or what was even required.

The output was a guess. Lists can be generated in very different formats — a plain table, a checklist, printable labels, HERMA badge sheets, an Excel grid. But users couldn't see what they'd get until after generating, so with that many output types, choosing meant regenerating until it looked right.

Discovery

I had access to Microsoft Clarity on the live product, so before redesigning I went to the recordings and heatmaps to check my assumptions against real behaviour rather than my own reading of the UI. I reviewed around 8 session recordings of the old list flow alongside the click heatmap.

The evidence was directional rather than statistical — a low-frequency feature, a modest number of sessions — so I treated it as signal to confirm the problem, not as a metric. Two behaviours recurred across the sessions and matched the hypotheses:

Users moved between separate list flows to complete one task. In replay, users went back and forth between different entry points rather than finishing the job in one place — behavioural confirmation of the fragmentation problem, not just a structural observation of the UI.

The busiest element was a dropdown opened to “look inside.” On the click heatmap, the single most-clicked control in the old modal was the area-selection dropdown — and in replay, users opened it to see what it contained rather than to make a known choice. That's the tell of an interface that doesn't advertise its options: people explore the control instead of acting through it. It pointed directly at two needs — a guided order of operations, and a way to preview an outcome before committing to it.

Together the sessions didn't reveal a surprise so much as sharpen the direction: the flow needed to guide rather than expose, and to show rather than make users guess. That framing set up the redesign.

Decisions

Designing against the risks, not just the happy path. Before committing to the wizard, I worked through its trade-offs with the founders and engineers rather than assuming it was the right call.

Working through these before building meant the wizard shipped as a considered decision, with its cost and its trade-offs already on the table — not a redesign that looked cleaner while ignoring build reality and the users who relied on the old flow most.

Outcome

shipped in phases · redesign live in product

03 Forms

Problem

The old flow for sending documents to families was really just an exporter. A teacher picked students from a list and hit "Export to PDF" — that was the extent of it. Everything around the actual job of running a document campaign lived outside the product: choosing which form to send, filling in known data by hand, distributing it, chasing who had responded, and collecting signatures. For a school running official Swiss paperwork — government declarations, medical authorizations, permission slips — the product handled the easy 10% (generate a PDF) and left the hard 90% to email and manual tracking.

Decisions

I designed Forms as a full campaign system rather than an export button, built on the same wizard logic validated in Lists — but applied to a larger, multi-sided problem:

• A template library. Admins start from ready-made document types organized by category (Government, Medical & Safety) instead of producing files from scratch.
• Auto-fill with a data-conflict check (concept direction). The concept populates known student data into the form automatically and flags conflicts with what's already in the system — cutting the manual re-typing the old flow never touched. This part is an early direction rather than a resolved flow: the intent and interface are designed, the underlying logic isn't fully specified yet.
• In-system distribution and tracking. A campaign goes to the right audience — students, parents, or staff — and its status stays visible in the product: draft, scheduled, sent, and response counts against a due date. The chasing moves inside the tool.
• A guided experience for the recipient. On the receiving end, a parent or student is walked through completion like a DocuSign flow — the same "guide, don't expose" principle from Lists, carried all the way to the end user, not just the admin.

How it relates to Lists

Forms isn't Lists with different content — it's a larger, different problem: multi-audience distribution, data auto-fill, signing. What carried over was the system underneath — the Untitled UI component base I'd set up for Lists, plus the wizard pattern, extended into Forms. Reuse was partial by design, since the flows aren't identical, but that shared foundation is why a solo designer could take on a second feature of this size without rebuilding from zero.

Outcome

STATUS: designed · not in production

04 OYM

This is the other track. Where Lists and Forms sharpened features that already shipped, OYM was about designing something the product didn't have — a concept exploring how a school's learning material could live inside ClassOwl.

OYM College, a Swiss school with a sports focus, runs its learning modules in SharePoint. The founders were positioning ClassOwl as the replacement, and the open question was whether that existing teaching material could feel like a modern learning experience rather than another file store.

Problem

In SharePoint, each module is one long page — theory, tasks, and media stacked into a single continuous scroll. For a student that means losing the thread: it's unclear where you are in the module, what's done, what's left, and whether you're on track for the deadline. The tasks dissolve into the text, and the structure of the learning — a sequence of steps — never becomes visible.

The design question was whether that same content could live in an interface built as a learning path rather than a document — and do it so the school recognized its own material and felt at home, not confronted with a foreign new product.

Concept

Rethink the SharePoint module as a guided learning path: the module page becomes navigation, not a wall of text. Three ideas, shown in this slice (the student KG side):

• Orientation from the first screen. The student dashboard shows semester progress and active modules as readable statuses — how much is done, what's next, whether the student is on schedule. Instead of “open it and scroll,” it's “here's where you are and where to go.”
• Progress made meaningful through Soll. The key visual device is the Soll marker — the target point of where a student should be by plan. A module's progress bar shows not just a percentage but position against that plan: ahead, on track, or behind. It turns an abstract number into a signal that means something.
• A module as a path, not a document. The opened module is broken into a clear structure — a short overview plus a sequence of tasks with statuses (done / current / upcoming). The student sees the whole route and their place in it.

The prototype was built on OYM's real module content — their actual material — so the school would recognize its own, not an abstract example. The design position was deliberate: read as a natural evolution of their platform, in a restrained Swiss aesthetic, not a foreign product bolted on.

Scope, honestly

This is an exploratory concept — a proof of direction, not a delivered product. This live prototype is the unconstrained version: I used it to explore the ideal learning-path experience, iterating with a ClassOwl stakeholder. It covers a vertical slice — login, the KG student dashboard, and one opened module. The teacher side, the module editor, other school levels, and the assignment mechanics behind Soll are intentionally out of scope.

A separate, more constrained prototype — built to fit inside ClassOwl's existing system — was the version taken into client conversations. I go into the trade-off between the two in a portfolio walkthrough; here I'm showing the concept direction.

Concept exploration · proof of direction, not shipped

05 Reflection

Eight months, one designer, two very different modes of work — sharpening what already shipped and designing what didn't exist yet. A few things I'd carry forward, and a few I'd do differently.

I'd bring data in before the redesign, not after. On Lists, I reached for Clarity to confirm the problem — which worked — but the analytics came in once I already had a direction. The stronger move is to establish the baseline first, so the same signal that motivates the redesign can later measure it. I have the “before”; I'd want the “after” wired in from the start.

The usability trade-off is still a hypothesis, and it should be tested. The wizard opens up far more capability than the old modal, but it's also longer — and I flagged that it might cost time for frequent users without measuring it. That's an honest open question, not a closed one. The natural next step is to validate it post-release with the same Clarity data, rather than assuming the guided flow wins for everyone.

Constraints belong in the process earlier. The clearest lesson came from OYM: an unconstrained concept is easy to make beautiful, but the version that has to live inside a real system carries different trade-offs. I'd rather confront those constraints early and design with them than design the ideal first and reconcile later — the gap between the two is where the real work is.

Working solo is leverage and a limit at once. Direct founder access let me move across the whole product — utility features, campaigns, presale concepts — without hand-offs. But it also meant no design partner to pressure-test decisions. Where I could, I used analytics and stakeholder feedback as that second opinion; with more time, building lightweight, repeatable ways to get user input would matter more than any single redesign.