// NAVIGATION
CONNECT ON LINKEDIN
BANGALORE, IN

WorkCase study

Aulas // EdTech, B2B SaaS, 0 to 1The whole classroom in one app

In 2020, Indian classrooms moved online overnight and landed in four different apps. I designed the first version of Aulas, a white-label platform that puts live classes, attendance, study material and tests in one place, under each institute's own name. It was my first full-time UI/UX job, and the product is still live today.

Four tools, with the student as the only link between them. V1 kept the four jobs and removed the joins.
Role
UX/UI Designer and Researcher
Company
Brigosha Technologies
Timeline
V1, 2020 to 2022
Platforms
Web, Android, iOS
Users
Students, teachers, institute admins
Status
Live, still growing

Prologue// Where I started

First UX job. Deep end.

Aulas was my first full-time job as a UI/UX designer. I had plenty of enthusiasm and no real idea yet what I was good at.

Then the pandemic closed classrooms across the country, and I was asked to design a product that could put a whole institute online: three kinds of user, three platforms, starting from a blank file.

So this page tells two stories. One is how the product took shape. The other is how I found out what I do well, and what I do badly, by doing it for real.

What came naturally
  • Listening firstSitting with students and teachers until the same problem showed up in different words.
  • Bringing orderTurning four tools and three roles into one structure people could find their way around.
What I had to learn the hard way
  • Making my caseI could see a bad call coming and still fail to stop it.
  • Proving itI tested usability with care and thought about business outcomes too late.

You will meet all four below. The first two run through the research and the decisions. The other two are in the feature we should not have built, and in the reflection at the end.

Case / 00// Overview

The story in thirty seconds

Problem

Institutes were running school on WhatsApp, Zoom, Google Drive and a separate test tool. Students lost links and notes. Teachers lost teaching time. Institutes lost their identity.

What I did

As the UX/UI designer and researcher on v1, I framed the problem, set the information architecture for three roles, built the design system and tested with real students, teachers and admins.

Result

Launched on web, Android and iOS, with 100+ institutions onboarded. The product is still live in 2026, and white-label branding and role-based access are still central to it.

100+Institutions onboarded
3×Growth in institute sign-ups, first 3 months
56%Fewer student queries after launch
3×3Roles and platforms, one design system

What shipped

Real product screens: the schedule on web for an admin and on a phone for a student. Names and dates are sample data.

Case / 01// The problem

School moved online. It landed in four apps.

When COVID-19 closed classrooms in 2020, institutes rebuilt school from whatever was free. WhatsApp carried announcements. Zoom or Google Meet carried the class. Google Drive held the notes. A separate tool ran the tests.

Each tool worked. The system did not. Nothing connected a class to its notes, its attendance or its test. Students and teachers did that joining work in their heads, on a phone, every day.

"I forget Zoom links all the time. Sometimes notes are in WhatsApp, other times in Drive. It's a mess."

Student, user interview

One morning, four apps

5 app switches before lunch

  1. 1ChatScroll up to find today's class link
  2. 2VideoJoin the class
  3. 3ChatAsk which file has today's notes
  4. 4FilesOpen the notes
  5. 5ChatFind the link for the test
  6. 6TestsTake the test

The same six tasks, in one app, with no switching. The schedule answers the first question of the day: what is next?

Illustrative, not measured. Every switch is a chance to lose the thread.

Who paid the cost

Students

High The mental effort a task demands. Every extra thing to remember or find adds to it. from constant context switching. A lost link meant a missed class.

Teachers

Admin work with no payoff: sharing links, chasing attendance, resending files.

Institutes

No visibility and no identity. Their school now lived inside other companies' products.

The classes existed. Finding them was the hard part. People were doing integration work that software should do.

The problem statement

How might we give an institute one place to run teaching and learning, so students stop stitching tools together and the institute keeps its own identity?

What made it hard: Aulas is B2B. The institute buys it, but teachers and students use it every day. V1 had to win both. Something an owner would put their name on, and something a 17-year-old could use on a phone without help.

Case / 02// Research

Three roles, three different jobs

I chose each method for a reason. The goal was to learn how people already ran class online, then design around those habits and not against them.

Research methods, why each was used and what it gave the team
MethodWhy I used itWhat it gave us
User interviews, tier 1 to tier 3 citiesTo avoid designing only for metro users with good devices and fast networks.The fragmentation problem, in users' own words.
Survey on online class workflowsTo see whether the interview themes held across a wider group.Pain points at each step of an online class.
What a person believes about how something works, built from the tools they already use. mapping of WhatsApp, Zoom and Drive usePeople had already formed habits. The product had to match them.The vocabulary and navigation patterns worth keeping.
Secondary research and competitive benchmarking: Google Classroom, Microsoft Teams, ZoomTo see what was already solved and what was left open.The gap: no platform an institute could run under its own brand.

One product, three people

The three user roles: their job to be done, biggest friction and what success looks like
RoleJob to be doneBiggest frictionSuccess looks like
StudentGet to class, find notes and take tests, all on a phone.Links and files scattered across apps.Everything for today on one screen.
TeacherRun a live class and track each student's progress.Scheduling and attendance done by hand.Class starts in one tap and attendance takes care of itself.
AdminRun the whole institute online.No visibility, no brand, no control.One console for users, settings and branding.

What the market already offered

Alongside the interviews, we did secondary research on the tools institutes were already using, then benchmarked three of them against our use case. This was a gap analysis with one question: what would an institute still have to stitch together itself?

Competitive benchmark: what Google Classroom, Microsoft Teams and Zoom offered in 2020 for each thing a coaching institute needed, next to Aulas V1
What an institute neededGoogle ClassroomMicrosoft TeamsZoomAulas V1
A live class inside the same appPartlyopens Google MeetBuilt inBuilt inBuilt in
Attendance taken automaticallyNot therePartlya list to downloadPartlya report to exportBuilt in
Notes kept with the classBuilt inBuilt inNot thereBuilt in
Tests with auto-gradingPartlythrough Google FormsPartlythrough Microsoft FormsNot thereBuilt in
A timetable to start the day fromPartlydue dates in CalendarBuilt inPartlya list of meetingsBuilt in
The institute's own name and logoNot thereNot thereNot thereBuilt in

Our reading in 2020, judged against a coaching institute's needs. All three products have changed since.

Google Classroom

Strong on coursework, thin on the class itself.

The live class, the attendance and the timetable each lived in another app.

Microsoft Teams

The closest to all-in-one, and the heaviest to set up.

It was made for organisations already on Microsoft 365, with someone to administer it.

Zoom

A very good live class with nothing around it.

No notes, no tests and no timetable, so everything else stayed in chat and drive.

Every feature we needed already existed somewhere. No product put them in one place, under the institute's name.

What the research told us

Insight

Context switching was the real barrier, not content.

Every jump between apps was a chance to lose the thread.

Insight

Teachers adopt tools that give time back.

Scheduling and attendance had to become effortless, or the product would be one more chore.

Insight

Institutes buy control and identity before features.

Admins wanted visibility across the school and their own name on the door.

Case / 03// Strategy

Win on the joins, not the features

We were never going to beat Zoom on video or Google on storage, and we did not try. The value sat in the joins: class to attendance, class to notes, class to test. If those connections were automatic, the product would feel like a classroom and not a toolkit.

BeforePeople do the joining

Four separate tools. The only thing connecting them is a person with a phone.

V1The product does the joining

The class sits at the centre. Everything a class needs is already attached to it.

Three principles behind every screen

Principle

One place, one path.

Every task starts from one home screen. Nobody hunts for a link.

Principle

Familiar over novel.

Users spend most of their time in other apps. We borrowed the patterns they already knew from WhatsApp and Zoom.

Principle

The institute is the brand.

Aulas stays in the background. The school's name, logo and colour come first.

Scoping v1

We ran ideation workshops, then used Sorting features into must have, should have, could have and won't have this time. to hold the line on what a first release needed. Five things made the cut.

What shipped in version one and why each item made the cut
In v1Why it made the cut
Unified dashboardIt answers the first question every user has: what do I need to do now?
Live class with built-in attendanceThe core job, and the biggest time saving for teachers.
Digital libraryIt ends the search across WhatsApp and Drive.
Tests with auto-gradingIt closes the loop from teaching to assessment.
Admin console with brandingThe reason an institute would choose Aulas over free tools.

Case / 04// Key decisions

Five decisions that shaped v1

Each one has a reason and a cost. The cost is the part most case studies leave out. Real product screens are labelled; the diagrams are illustrative.

Admin // web
Student // phoneReal screens
Decision 01 // Information architecture

One product, three front doors

A role-based How content and features are organised and labelled, so people can find what they need., with a separate journey for students, teachers and admins. On web, an admin's navigation is grouped by job: management, resources and communication. On a phone, a student gets five tabs.

Why
The three roles share data but not tasks. One shared navigation would show everyone controls they cannot use.
Trade-off
Three sets of flows to design and maintain. A shared component library kept that cost down.
Real screen
Decision 02 // Navigation

The schedule is the starting point

The app opens on today's schedule, with the class in progress and its Join button in view.

Why
A usability heuristic: show people their options so they don't have to remember them.. Nobody should have to remember where a link was posted.
Trade-off
Every feature wanted that first screen. The schedule won, because "what is next?" is the first question.
Decision 03 // Platform

Mobile first

Layouts were designed for the phone, then scaled up to tablet and web.

Why
In tier 2 and tier 3 cities the phone was the classroom. Designing desktop first would have failed most students.
Trade-off
Dense screens, like the admin console, needed more care to work on a small display.
Decision 04 // Language

One label, one meaning

"Resources" and "Library" became a single Library.

Why
In testing, students could not tell the two apart. Labels should match the user's language, not the team's.
Trade-off
One longer list to organise, which put more weight on clear grouping.

Showing the app themed for Northfield Academy.

Decision 05 // Design system

A design system built for any brand

Material Design as the base, custom components on top, and theming driven by each institute's logo and colour. Pick an institute to re-theme the schedule screen. This one is a recreation, and the institute names are made up.

Why
Material gave Android users familiar patterns and gave engineering ready parts across three platforms. Theming made white-label possible without a redesign per customer.
Trade-off
Every component had to hold up under a colour we did not choose.

Case / 05// Speaking up

The feature we should not have built

Midway through design, our CEO proposed an AI feature. A student would raise a real hand on camera, image recognition would spot it, and the teacher would get an alert. It was a bold idea, and the instinct to stand apart from Zoom was right.

I was the UX subject matter expert on the project, so I spoke up. No student or teacher had asked for this in research. And a camera cannot tell a raised hand from a scratched head. But I brought opinions, not data, and the feature went into development.

At launch, the system did what I feared. Students fixing their hair or stretching triggered alerts. Teachers got a stream of false alarms in the middle of live classes. Teacher feedback made the case I could not, and we replaced the feature with a plain button.

Shipped firstCamera detection

Illustration: in a class of six, the camera flags four students. Three only scratched their head, fixed their hair or stretched. One raised a hand.

4 alerts for the teacher1 was real

What replaced itA raise-hand button

Illustration: the same class with a button. Only the student who taps it is flagged.

1 alert for the teacher1 was real

Illustrative class of six. The numbers show the pattern, not a measurement.

Why the button is the better design

Intent

A tap is deliberate. A movement on camera is ambiguous.

False alarms

Each When a system reports something that did not happen, like a raised hand that was only a stretch. pulls the teacher away from teaching. After enough of them, teachers stop trusting the signal at all.

Familiarity

Students already knew the raise-hand button from Zoom and Meet. There was nothing new to learn.

What I took from it

Speaking up is part of the job

This was tech-first bias: the technology came before the need. On any project, the subject matter expert is the person placed to question a call made on excitement instead of evidence. If that person stays quiet, bias makes the decision.

So I say it early, I say it plainly, and I bring proof with me.

What I do differently now

Habit

I speak up, and I treat it as part of the role.

Disagreeing with a senior leader is uncomfortable. Staying quiet costs the users more.

Habit

I bring evidence, not opinion.

A one-day A test where a person secretly plays the part of the technology, so an idea can be tried before anything is built., with a person faking the detection behind the scenes, would have shown the false alarms before any code was written.

Habit

I ask one question before any AI feature ships.

What does a false positive cost the user? That question now sits at the centre of my work on AI and high-stakes products.

"Good design makes a product useful."

Dieter Rams, ten principles for good design

Case / 06// Validation

Tested with the people who would use it

I ran remote usability tests on interactive prototypes with 10+ participants across all three roles. Each session used the Participants say what they are thinking as they work, so you hear where the design and their expectations part ways.. I tracked task success, time on task and error rate.

Usability test findings, what each one told us and what changed
What we sawWhat it told usWhat changed
Students hesitated between "Resources" and "Library"Two labels for one mental model.Merged into a single Library.
Teachers went looking for attendance right after classThe log was buried at the moment it was needed.Attendance logs reachable as soon as a class ends.
Admins asked to set their own logo and theme colourBranding was part of the buying decision, not decoration.A branding console for admins.

After iterating on the findings

+27%Task success
−43%Onboarding time

Case / 07// Outcome

Launched in a pandemic. Still running today.

V1 shipped on web, Google Play and the App Store. I delivered annotated specs with edge cases through Zeplin, worked in Agile sprints with engineering, and ran design QA on development builds.

100+Institutions onboarded, each under its own brand
3×Growth in institute sign-ups in the first 3 months
56%Fewer student queries, as navigation and notifications answered them

From v1 to today

  1. 2020Classrooms close

    Institutes rebuild school on chat, video and drive apps.

  2. V1One app, three roles

    Live class, attendance, library, tests and a branded admin console, on web, Android and iOS.

    My scope
  3. TodayStill live

    The team that followed has kept building, adding a course storefront, a CRM and AI tools.

Aulas now describes itself as the operating system for modern institutes. I designed v1 and moved on in 2022, so the later work belongs to the team that followed. What I am proud of is what lasted: role-based access, the white-label model and the idea that one app should hold the whole classroom.

Case / 08// Reflection

What I would do differently

  1. Agree on success measures before design starts

    I measured usability well and product outcomes late. Today I would set one measure per role with product and engineering, such as class join success for students, and track it from day one.

  2. Test the riskiest idea first, and cheaply

    The hand-raise feature was built before it was tested. A faked version would have taken a day and settled the question.

  3. Speak up with evidence, every time

    Being right in a meeting changed nothing. Being able to show it would have.

A 0 to 1 product is mostly a series of decisions about what to leave out. The ones that lasted here were the simple ones.

End of case study

More than one
kind of user? Let's connect.

Open to conversations about enterprise products, AI experiences and design leadership.

Connect on LinkedIn All work