← Back

Designing better digital
classroom experiences

Superr  |  2025

Superr is an edtech company building tools that support teaching, learning and classroom operations for schools.

Over my time at Superr, I worked across Superrbook and the Admin Portal, designing experiences for students, teachers, and school administrators. My focus was on simplifying complex classroom workflows, improving information architecture and creating intuitive experiences across the platform.

For interaction heavy features, I often used Cursor to prototype behaviors, validate edge cases, refine motion and micro-interactions directly in code before development.

This case study highlights a collection of the features, systems and interaction patterns I helped design and ship while building a more connected digital classroom experience.

My Role

  • Designed and shipped experiences across Superrbook and the Admin Portal for students, teachers, and school administrators.
  • Simplified classroom workflows through navigation, information architecture and interaction design.
  • Designed learning experiences including assignments, quizzes, notebooks, whiteboards and collaborative classroom tools.
  • Created operational workflows and dashboards for school device management and administration.
  • Collaborated closely with product managers and engineers from concept to implementation.

Areas of Ownership

  • Learning Experiences

    Assignments, quizzes, notebooks, whiteboards, reports and classroom collaboration.

  • Systems & Information Architecture

    Navigation structures, content organisation and workflow simplification across the platform.

  • Interaction Design

    Geometry tools, stickers, drawing experiences, tool behaviors and micro-interactions.

  • Admin Operations

    Device management, operational dashboards, monitoring workflows and quick action systems.

  • Prototyping

    Cursor based prototypes used to test interaction logic, usability edge cases and motion before implementation.

How I approach design

I enjoy working on systems where interaction, usability, and structure come together. My process usually involves understanding workflows deeply, simplifying complexity, exploring multiple interaction patterns, and prototyping ideas quickly to test assumptions early.

Lately, I’ve also been experimenting heavily with AI-assisted workflows and code-based prototyping to iterate faster and explore interaction details beyond static screens.

Context Switching Between Learning Resources

01 / 03

Overview

One of the most common learning behaviors in Superrbook is switching between textbooks and notebooks. Students frequently read from a textbook, write notes in a notebook, and then return to continue reading. This simple workflow can happen multiple times within a single study session.

However, the existing experience made switching unnecessarily difficult. To move between resources, students had to leave their current content, navigate back through modules, browse directories, and manually find what they were looking for again.

The challenge wasn’t helping students open another textbook or notebook. It was helping them stay focused while moving between resources.

Existing Experience

Textbook
Go back
Browse files
Find notebook
Open notebook

Students often switched between textbooks and notebooks while studying. Each switch required multiple steps, breaking their focus and slowing down note-taking.

Why It Matters

Switching between resources is not an occasional behavior. It’s a high-frequency interaction that sits at the center of how students learn. The most common pattern looked like:

TextbookNotebookTextbook

Students wanted to quickly capture a thought and immediately return to where they left off. When switching became difficult:

  • Students lost their train of thought
  • Note-taking became less frequent
  • Learning sessions felt fragmented
  • Valuable context was lost between reading and writing

The ideal experience should feel almost invisible. Students should be able to move between resources without interrupting their learning flow.

Defining Success

  • Enable students to switch resources in as few steps as possible.
  • Support the most common workflow, reading and note taking side by side.
  • Make returning to previous resources effortless.
  • Reduce context loss during study sessions.
  • Avoid interfering with writing and drawing interactions.

Exploration

The trigger became the most debated part of the feature. The solution needed to be fast, discoverable, accessible, compatible with writing and drawing experiences, and flexible enough to work across textbooks and notebooks. I explored multiple directions before arriving at the final solution.

01 Single Pull-Down Swipe From Top

Swipe from top gesture exploration

Cons

  • Conflicted with system gestures
  • Difficult to own consistently across the OS

Pros

  • Quick access

Decision: Rejected

The gesture competed directly with operating system interactions and could not be reliably controlled within the product.

02 Toolbar Action

Toolbar action exploration

Cons

  • Slower for frequent usage
  • Added additional UI controls
  • Extra interaction steps required

Pros

  • Familiar interaction pattern

Decision: Rejected

The interaction felt too heavy for a workflow students perform repeatedly throughout a study session.

03 Handle + Pull Gesture

Handle and pull gesture exploration

Cons

  • Required persistent UI across the entire product
  • Valuable top-of-screen space lost in notebooks
  • Added visual clutter to focused reading and writing surfaces

Pros

  • Discoverable
  • Fast for repeat usage
  • Easy to understand

Decision: Rejected

While the handle improved discoverability, the tradeoff of adding permanent interface chrome across the product felt too expensive for a feature intended to stay lightweight.

Designing the Switcher

Once I decided the entry point for the switcher, the next challenge was determining what should happen after it opened.

Students primarily switched resources for two reasons:

  • Returning to something they had recently used (Recents)
  • Accessing resources they intentionally wanted to keep close (Favorites)

This led to exploring different ways of organizing content within the switcher.

Modal exploration 1
Modal exploration 2
Modal exploration 3

While these explorations helped validate the information architecture, they didn’t feel quite right as a final solution.

The switcher was triggered through a top-down gesture, but center modals and bottom sheets felt disconnected from that interaction. The experience lacked a sense of continuity between the gesture and the resulting UI.

The tabbed explorations also felt overly app-like and borrowed patterns commonly found in web products. Since Superrbook is built around notebooks, textbooks, and paper-based learning, I wanted the interaction to feel closer to how students naturally organize physical resources.

This led to an approach inspired by physical file folders, where Recents and Favorites tabs felt like sections within the same collection rather than separate screens.

These explorations helped clarify not only what content should appear inside the switcher, but also how the switcher should feel.

Final Direction

After exploring multiple approaches, I landed on a switcher that could be accessed through a two finger swipe down gesture or directly from the Control Center.

Together, these interactions balanced speed and discoverability without introducing persistent UI into textbooks and notebooks. Students could quickly move between resources when needed, while the learning experience remained focused and distraction-free.

The final solution combined Recents and Favorites within a single surface, allowing students to return to recently used resources or access intentionally saved content from one place.

Designing for Edge Cases

A significant part of the project involved defining behavior beyond the happy path. Questions included:

  • Should the currently open resource appear in Recents?
  • What happens when a notebook is deleted?
  • What happens when there are no recent or favourite resources?
  • Should reading position be preserved?

Every edge case was intentionally defined to ensure the switcher behaved consistently, remained easy to understand, and could scale across future learning workflows.

Looking Ahead

The switching system was intentionally designed as a foundation for future workflows. One direction explored was split-screen learning — students could drag a resource from the switcher and open it alongside their current content.

Textbook+Notebook
Notebook+Notebook
Textbook+Textbook

This would allow students to compare, reference, and take notes simultaneously without repeatedly switching contexts.

Live Quizzes

Created interactive classroom experiences that made classroom participation feel more active and engaging during lessons.

Focused on

  • Real-time classroom interaction
  • Faster teacher controls
  • Clear participation states
  • Keeping students engaged during sessions

Geometry Tools: Making Digital Tools Feel Physical

02 / 03

The Challenge

Geometry tools are familiar in the physical world. Students already know how a ruler, protractor, or compass behaves on paper.

The challenge wasn't just adding these tools digitally, it was making them feel intuitive enough that students could use them without learning a completely new system.

The experience needed to support drawing, measuring, rotating, and positioning tools while remaining approachable for students across different age groups.

Understanding Existing Patterns

Before designing the interactions, I studied how geometry tools were implemented across learning platforms, whiteboard products, and drawing applications.

While most products provided similar toolsets, many interactions felt overly technical, hidden behind controls, or disconnected from how physical tools behave.

Design Principle

If a student already knows how the tool works on paper, the digital version should behave as closely as possible to that mental model.

Designing Around Physical Behaviors

Geometry tools are something students already understand from the physical world. Instead of introducing entirely new interaction patterns, I wanted the digital experience to build on behaviors students were already familiar with.

This meant constantly asking:

  • How would a student expect a ruler to move?
  • How would they rotate a protractor?
  • Where would they look to start drawing an arc or circle?
  • What feedback should appear while measuring?

The goal wasn't to replicate physical tools exactly, but to preserve the mental models students already had while taking advantage of digital capabilities.

As a result, interactions were designed around direct manipulation, allowing students to move, rotate, measure and draw directly from the tool itself without relying on separate control panels or complex menus.

Prototyping Interactions in Code

Many of these behaviors were difficult to evaluate through static Figma screens alone.

To better understand how the tools would feel in use, we prototyped interactions directly in Cursor and tested different approaches for movement, rotation, drawing and tool states.

Working in code allowed me to validate interactions much earlier, uncover usability issues and collaborate more effectively with engineers around implementation details and constraints.

Designing for Edge Cases

As the tools became movable and interactive, many edge cases had to be considered:

  • What happens when a tool is dragged partially off-screen?
  • How far can each tool move before becoming hard to access?
  • Where should action buttons move when they reach the screen edge?
  • What should be the default size of each tool?
  • How can students discover advanced features naturally?
  • How should the tools adapt across different screen sizes?

Prototyping helped uncover these scenarios early, making it easier to define clear behaviors before development and reduce implementation ambiguity.

Key Decisions

1. Tool Actions Stay Close to the Tool

Contextual actions were attached directly to the active tool instead of a separate toolbar, reducing visual scanning and making interactions more intuitive.

2. Discovery Through Use

Interactions were designed to reveal themselves naturally during use. Selecting a tool exposed relevant controls, helping students learn by exploring rather than through onboarding.

3. Familiar Gestures Over Custom Controls

Common touch gestures replaced custom controls — one finger to move, two fingers to rotate, and direct touch points for drawing and measuring — making the experience feel natural and easy to learn.

Outcome

The final experience balanced familiarity and flexibility by borrowing behaviors from physical geometry tools while adapting them for touch interactions.

Prototyping the interactions in code helped validate complex behaviors, uncover edge cases early and refine the experience before implementation.

Helping school admins manage devices better

03 / 03

Problem

School admins needed a quick way to monitor device health, assignments, classroom activity, and operational issues without feeling overwhelmed by large amounts of data.

Approach

I designed dashboards and workflows focused on quick scanning, prioritization, and actionable insights so admins could identify issues and take action faster.

Focus Areas

  • Information hierarchy
  • Scannability
  • Status visibility
  • Quick actions
  • Reducing operational effort

Reflection

What I learned

Designing for clarity at scale.

Designing classroom experiences taught me that students and teachers process information very differently. Every interaction needed to feel simple, focused, and easy to navigate without becoming overwhelming.

Thinking beyond individual screens.

The work pushed me to think more deeply about workflows, interaction systems, scalability, and how features connect across students, teachers, and admins instead of treating each screen separately.

A large part of the work involved interconnected features and evolving systems, so I’d be happy to walk through deeper explorations, iterations, prototypes, and shipped decisions in conversation.