Case study · EdTech · paid pilot · 2024

Most EdTech looks like school software.
BrainTech had to feel like the product teens picked.

A paid pilot to redesign a teen tech-education platform end to end: brand identity, a web learning platform, a mobile app, and the design system that holds them together. Solo designer across the whole surface.

Role: Lead Designer · brand + product · solo Type: Paid pilot · EdTech · teen audience Design: Brand · UI · token-based design system Surface: Web app · mobile app · design system

The problem

The product was built for adults, almost by accident, for an audience of teens

BrainTech teaches teenagers coding, digital literacy, and tech entrepreneurship. But the product that existed when the pilot started had been built by an EdTech team using EdTech defaults: muted colors, dense layouts, an adult information hierarchy, and screens that looked indistinguishable from the LMS those same teens had to use at school. The content wasn't the problem. Teens turned away because it looked like something they'd been assigned rather than something they'd choose.

On paper the brief was a redesign. The real job was figuring out what a tech-education product for teens should look like once it stops borrowing the visual language of school software and starts borrowing from the apps teens already choose.

Visual

Interface didn't match the brand's ambition

Muted colors, generic typography, corporate-feeling layouts that didn't reflect the exciting, forward-looking nature of tech education for teens.

UX

No coherent design system

Inconsistent component patterns across screens, with every feature built in isolation. That led to visual fragmentation and unpredictable interactions.

Product

Critical screens missing

Onboarding, certificate, lesson player, and achievement screens were underdeveloped. Those are the exact touchpoints that drive teen engagement and retention.

The constraint

A pilot, not a production build, but the output still had to feel like a product

It was pilot scope. There was no engineering team to validate against and no live users to test with mid-flight. The output had to do three things: be convincing enough to win the production build, coherent enough to read as one real product across a web app and a mobile app, and flexible enough for a future team to extend. The way to get there was to design the system first and everything on top of it, so a couple dozen screens across both surfaces still felt like a single product.

The decisions

Three calls that defined the redesign

These are the points where I had credible options to choose between. For each one I've laid out what was on the table, why I picked what I did, and what it cost.

Decision 01

Violet and orange over the usual blue and grey.

The options on the table

  1. 01 Blue and grey, the EdTech default. Safe and accessible, but instantly recognizable as school software and forgettable in a category fighting for attention.
  2. 02 A bright primary palette of yellow, lime, and hot pink. High energy, but it reads cartoonish to a teen who's spent the last two years on Instagram and Discord.
  3. 03 Violet and orange, creativity (violet) and action (orange), paired with a warm cream surface. Premium and youthful without being childish.

Why this one

Teens are the most visually critical audience a product can target. They consume polished social media all day, so an interface that looks like school software reads as a downgrade the second it loads. Violet and orange puts BrainTech in the same visual world as the apps teens already pick, instead of the LMS they got assigned. The cream surface keeps it warm rather than feeling like another dark dashboard. The palette sets the brand promise before the user reads a single word.

The trade-off

Violet and orange is a harder pair to keep accessible than blue and grey, especially at small UI scales, so every text-on-color pairing had to be checked against WCAG AA explicitly. I also had to introduce two semantic colors (teal for correct, rose for wrong) so the brand pair could stay tied to identity rather than status. That meant a wider token set than a single-brand palette would have needed.

Decision 02

Build one design system for the web app and the mobile app.

The options on the table

  1. 01 Design each surface on its own. Fastest per screen, but the web platform and the mobile app would drift into two different-looking products.
  2. 02 Share a palette and a logo across surfaces, but let each one define its own components. Some consistency, but every new screen re-solves buttons, cards, and navigation from scratch.
  3. 03 Build a single token-based design system first (color, type, spacing, components), then design every surface on top of it, so the brand holds from a web dashboard down to a mobile lesson screen.

Why this one

BrainTech had to show up as one brand in two very different places: a web platform a teen uses on a classroom laptop, and a mobile app they use on their phone. If those felt like two products, the whole "this is a real, premium thing" argument fell apart. So the system came first: twelve color tokens, six component families, two layout systems. Every screen after that pulled from the same parts, which is what lets a web certificate and a mobile onboarding flow both feel unmistakably BrainTech.

The trade-off

Building the system before the screens is slower to first pixel. There's a stretch where you have tokens and components but nothing that looks like a finished page yet, which is uncomfortable in a pilot that has to show progress. It paid off once the screen count climbed, because by then each new screen was assembly rather than invention.

Decision 03

Treat the learner as a builder, not a student.

The options on the table

  1. 01 Use the standard EdTech vocabulary: students, lessons, grades, courses completed. Familiar, but it frames BrainTech as school, which is exactly what teens are trying to escape.
  2. 02 Add game mechanics on top of the school framing: points and badges bolted onto a course tracker. More fun, but it reads as gamified homework.
  3. 03 Build the whole identity around being a builder: "Log back in, builder," Lv5 Builder levels, a developer-style streak, shareable certificates, and copy like "Build the Future." The product treats the teen as the maker they want to become.

Why this one

The audience wants to be builders, not students, and the fastest way to lose them is to make the product feel like the LMS they use at school. So the identity leans on the language and signals from developer and maker culture: the streak echoes a GitHub contribution graph, the levels read as "Lv5 Builder" rather than a grade, the certificate is designed to be screenshot and shared, and even the sign-in says "Log back in, builder." Each one is a small cue that this is a place for people who make things.

The trade-off

Leaning hard into "builder" identity risks alienating the exact beginners the funnel needs, the ones who don't feel like builders yet. The onboarding answers that by asking "What do you want to build?" and letting anyone pick a path at a beginner level, so the identity stays aspirational and open rather than a gate.

What I built

A full product: a web platform, a mobile app, and the design system underneath

What shipped in the pilot, from the system up to the surfaces a teen actually touches.

  • Brand identity system

    Palette (violet, orange, and four semantic colors on cream), typography (Syne for display, Plus Jakarta Sans for UI), iconography, and motion principles. The visual language, defined before any screen.

  • Token-based design system

    12 color tokens, 6 component families (buttons, inputs, cards, navigation, progress, status badges), plus spacing, type, radius, and elevation scales. Documented as a full design-system reference.

  • Web learning platform

    Dashboard, course catalog, course detail, lesson player, live events, a certificates gallery, and account settings. Built for a classroom laptop, with wider layouts and more density.

  • Mobile app

    Sign-in, a "What do you want to build?" onboarding, home, courses, lesson player, certificates, live events, and profile. The teen's day-to-day surface, mobile-first.

  • Certificates system

    A shareable certificate with a verify link, QR, and real ID, plus download to PDF or PNG and share to LinkedIn or X. Designed as an artifact a teen is proud to post, on both web and mobile.

  • Live Events surface

    A "happening now" hero, upcoming and past sessions, and register flows, on both web and mobile. Content that keeps the product feeling alive between courses.

  • Builder identity and gamification

    The streak modeled on a GitHub contribution graph, Lv5 Builder levels with an XP-to-next-level bar, and the "Log back in, builder" voice running across the product.

  • Two-layout responsive system

    The same tokens and components across a mobile app and a web platform, each with a layout built for its context, without forking the components.

  • Onboarding flow

    A four-step interest and experience picker with visual chips instead of dropdowns, and Skip always visible so onboarding never blocks first entry.

  • Lesson player with dual modes

    Video and reading as first-class tabs (Notes, Transcript, Resources, Discussion), a key-concept callout, and a course outline that tracks progress.

  • Account and settings

    Profile, connected accounts, notifications, learning goals, subscription, and the danger-zone actions, consistent across web and mobile.

What I owned

Design end to end, across brand, product, and system

Discovery & UX

Scoped the problem space

There was no PM and no separate research lead. I mapped the two user journeys (teen learner and parent buyer), audited the existing product, and wrote the brief for what BrainTech needed to be before designing a single screen.

Brand + visual design

Identity and the full screen set

Palette, typography, motifs, and the screens across the web app and the mobile app. Designed in parallel with the system, so every screen used the tokens I'd already named.

Design system

Tokens + components first

Twelve color tokens, six component families, and two layout systems. Built before screen 01 so everything downstream would feel like one product instead of many.

Product surfaces

Web and mobile on one system

The same brand carried a web platform for laptops and a phone app, each with a layout built for its context while pulling from the same parts.

The design

One brand across a web app and a mobile app

The pilot as it stands: a web learning platform and a mobile app, both built on the same brand and design system. Click any screen to open it full size.

Web app

BrainTech web sign-in
Web · sign-in: Log back in, builder.
BrainTech web dashboard
Web · dashboard: streak, level, and the featured masterclass.
BrainTech web course catalog
Web · course catalog, filtered by track.
BrainTech web course detail
Web · course detail: overview, curriculum, and enrollment.
BrainTech web lesson player
Web · lesson player with a course outline and a key-concept callout.
BrainTech web live events
Web · Live Events: happening now, upcoming, and past sessions.
BrainTech web certificates gallery
Web · certificates gallery: earned and in progress.
BrainTech web certificate detail
Web · a single certificate, with share, verify, and download.
BrainTech web settings
Web · account and profile settings.

Mobile app

BrainTech mobile sign-in
Mobile · sign-in.
BrainTech mobile onboarding
Mobile · onboarding: What do you want to build?
BrainTech mobile create account
Mobile · create-account screen.
BrainTech mobile home
Mobile · home: streak, a recommendation, and continue-learning.
BrainTech mobile course catalog
Mobile · course catalog.
BrainTech mobile lesson player
Mobile · lesson player with notes.
BrainTech mobile live events
Mobile · Live Events.
BrainTech mobile certificates
Mobile · certificates.
BrainTech mobile profile
Mobile · profile and settings.

Design system

Built before the screens: tokens, components, patterns

The design system was the first deliverable. Building the token library and components upfront is what makes every screen across web and mobile feel like a single coherent product.

Color tokens

Violet
#4C1D95
Violet Mid
#6D28D9
Violet Lite
#8B5CF6
Violet Bg
#EDE9FE
Orange
#EA580C
Orange Bright
#F97316
Amber
#D97706
Teal
#0D9488
Rose
#E11D48
Gold
#CA8A04
Cream
#F5F1EB
Ink
#1C1917

Component families

Buttons

5 variants

Primary (violet), Secondary (outline), Ghost (cream), CTA (orange), and Danger (rose), each with sm/md/lg sizes.

Form inputs

3 states

Default, focused (violet ring), error (rose). Text, password, and search variants with consistent label treatment.

Cards

4 types

Course card, lesson card, achievement badge, and notification row, each with appropriate information density.

Navigation

2 patterns

Bottom tab bar for mobile with icon + label. Sidebar nav for web with section groups and active states.

Progress

3 variants

Linear bar (quiz, onboarding), circular ring (course progress), dot-strip (onboarding steps).

Status badges

Semantic color

Completed (teal), In Progress (violet), Locked (grey), New (orange), Achievement (gold).

Full design system, click to open

BrainTech design system reference
BrainTech Design System

The texture

The detail I spent the most time on was the voice, the thing that decides whether a teen feels talked down to

The detail I spent the most time on doesn't show up as a feature. It's the voice. A teen can smell condescension in a product instantly, and most EdTech talks to them the way a school does. So every string got weighed against one question: does this treat them like a student, or like the builder they want to be? The sign-in says "Log back in, builder," not "Welcome back." The onboarding asks "What do you want to build?" The level reads "Lv5 Builder," not a grade. Small choices, but together they set the whole relationship.

The gamification followed the same rule. The streak is modeled on a GitHub contribution graph because that's what real builders already track, so it signals "this is what people who make things do" instead of "here's your gold star." The certificate is designed to be screenshot and posted, with a verify link and a real ID, because a credential a teen is proud to share is worth more than one that sits in an account. None of it is loud. All of it points at the same feeling: you belong here, and you're becoming something.

On the surface it's just copy and a few badges, but it's the difference between a product a teen tolerates for class and one they actually choose.

Impact

What shipped at the end of the pilot

18
Screens designed
across web and mobile
12
Color tokens
one system, every screen
6
Component families
buttons · inputs · cards · nav · progress · badges
1
Brand and product system, built solo
from brand and UI to the design system

The pilot delivered a full brand and product design: a web learning platform, a mobile app, and the token-based design system underneath both. Every screen pulls from the same twelve tokens and six component families, which is what makes a web certificate and a mobile lesson screen read as one product. The deliverable gave the client a concrete, coherent picture of what BrainTech could be before committing to a full build.

Shipped solo as the lead designer. Product direction came from the client stakeholders. Everything from research and brand through the UI, the design system, and every screen across the web app and the mobile app was mine.

What this project reinforced about designing for a specific audience.

Teens are not a generic user group with a brighter palette. They have higher visual standards than the products that target them, because they spend all day inside polished consumer apps. They respond to identity markers like streaks, badges, and shareable certificates, and to being treated as builders rather than students. Every decision in BrainTech ran through that filter: palette, typography, copy register, the streak metaphor, and the certificate moment. Designing for teens is about respect at least as much as it's about color.

Why the system had to come first.

Designing two surfaces that feel like one product is a systems problem before it's a screens problem. If the web app and the mobile app each invented their own buttons and spacing, no amount of shared color would make them feel related. Building the tokens and components first meant both surfaces spoke the same language by default, so the brand held from a laptop dashboard all the way down to a teen tapping through a lesson on their phone.

What's next.

The natural next step is a production build, and the interesting question is which parts of the system survive contact with engineering: which tokens hold, which components need new variants, which screens change once real data and real content arrive. The two things I'd most want to protect through that build are the builder identity and the cross-surface consistency, because those are what make BrainTech feel like a product a teen chose rather than one they were assigned.