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, covering brand, IA, 10 production-grade screens, and a token-based design system, all delivered as live HTML/CSS the future build team could read directly. Solo designer plus prototype front-end.

Role: Lead Designer + prototype FE · solo Type: Paid pilot · EdTech · teen audience Stack: HTML · CSS · token-based design system Output: 10 live screens · mobile + web · 2024

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, quiz, certificate, lesson player, and achievements 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 decisions 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, flexible enough for a future team to extend, and concrete enough that "what BrainTech could feel like" stopped being a hypothesis. That's why every screen on this page is real HTML/CSS rather than a Figma export. The prototype had to read as a working product to non-designers, and the cost of writing the front-end stayed bounded because I was holding both layers.

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

Ship live HTML prototypes instead of Figma high-fidelity.

The options on the table

  1. 01 Figma high-fidelity screens with a click-through prototype. The industry default for a pilot of this scope, and the deliverable the client expected.
  2. 02 Figma plus a small InVision-style flow demo. Slightly more interactive than static screens, but still inside a design tool.
  3. 03 Live HTML/CSS prototypes. Every screen on this page is real markup the future build team can read, with actual type rendering, responsive behavior, and interaction states.

Why this one

The pilot had to convince two audiences: an internal product team deciding whether to invest in a full build, and parent stakeholders trying to picture what their teen would actually use. Figma screens lose both. They feel like deliverables, beautiful but static and easy to wave off as "just design." A live HTML prototype reads as the product itself, because the type, components, and responsive behavior all work the way they will in production. And since I write the front-end as well as the design, the cost of HTML over Figma was real but bounded, roughly 2 to 3 times per screen, paid once.

The trade-off

It cost real time. Every screen took longer to produce than a Figma equivalent, measurable in weeks across 10 screens, and the pilot scope had to absorb that without slipping the client's schedule. HTML prototypes are also harder to iterate visually with non-technical reviewers, since Figma's instant edit-and-show is still where stakeholder review moves fastest. I gave up fast iteration in the design tool to get fidelity in the demo.

Decision 03

A GitHub-style streak calendar instead of stars, levels, or XP bars.

The options on the table

  1. 01 A Duolingo-style XP bar with level-ups and celebratory animations. A proven engagement loop, but it leans heavily on the "game" of learning.
  2. 02 Stars, medals, or achievement badges as the primary progress metric. Visually rewarding, but every other EdTech product looks the same.
  3. 03 A GitHub-style contribution calendar (violet for completed days, faded for missed, orange for today) as the primary visual proof of the user's effort over time.

Why this one

BrainTech's audience is teens learning to code, and they already recognize the GitHub contribution graph from developer profiles, "year in review" tweets, and the README of every project they've admired. Mapping learning streaks onto that pattern meets them in a visual language they already speak, and it signals "this is what real builders track" rather than "this is the kid version of Duolingo." That's why the streak calendar sits on the profile screen: it's about identity. Stars and XP bars work fine in general-purpose learning apps, but for teens learning tech, the right metaphor is the one they're aspiring toward.

The trade-off

A contribution graph is a longitudinal motivator. It rewards consistency rather than single sessions, so there's no dopamine spike at the end of a quiz the way an XP bar gives one. Single-session retention had to come from somewhere else, namely the quiz feedback states and the lesson-completion certificate. The streak carries the long arc, and other patterns carry the short one.

What I built

The full pilot: design system, screens, and the prototype front-end

What shipped during the pilot, roughly from the foundation 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, surface treatments, and motion principles. The visual language was defined before any screen.

  • Token-based design system

    12 color tokens, 6 component families (buttons, inputs, cards, navigation, progress, status badges), spacing scale, type scale, radius + elevation tokens. Documented in an interactive design system page (the iframe at the bottom of this case study).

  • 10 production-grade screens

    Sign-in, home, courses (web and mobile), course detail, quiz, certificate, onboarding, lesson player, profile, and notifications. Mobile-first for the teen flow, with full-width web layouts for classroom contexts.

  • Live HTML/CSS prototypes

    Every screen on this case study page is real markup rather than a Figma export. The future build team can read the CSS variables, copy the component HTML, and ship the same interaction directly. The pilot doubled as a starting codebase.

  • Onboarding flow with low-friction skip

    A four-step interest and experience picker that uses visual chips instead of dropdowns. Skip stays visible the whole time, so onboarding never blocks first-session entry, which is the highest-risk funnel moment for any teen product.

  • Quiz feedback engine

    Correct (teal) and wrong (rose) states with explanation cards that teach the concept right at the moment of feedback instead of after the quiz ends. A progress segment strip color-codes the run so the user can see their pattern while still in it. This is the interaction I spent the most time on.

  • GitHub-style streak system

    Contribution calendar on the profile, streak pill on the home, day streak in the notification system. Mapped to a visual language teens already recognize from the developers they aspire to be.

  • Certificate as shareable artifact

    A full-bleed violet phone shell with confetti, the only screen that breaks the cream background. It's designed to be screenshot-worthy: name, course, stats, issue date, and a Level 5 builder badge. Download-to-PDF and next-step CTAs prevent dead-ends after completion.

  • Lesson player with dual learning modes

    Video and reading as first-class tabs (Notes, Transcript, Resources, Discussion). Inline code blocks and key-concept callouts inside the reading view. Visual learners and text learners both get a real experience without digging through settings.

  • Responsive system: phone and classroom laptop

    The same tokens and the same components across two layout systems. The courses screen exists as both a mobile catalog and a web grid, and the design system absorbs both without forking the components.

  • Two-audience IA on one product

    Teen-facing surfaces (mobile-first, identity-led, status-rich) and parent-facing surfaces (web, dense, outcome-led) on a single content model. The IA has to serve the user who learns and the user who pays without insulting either.

What I owned

Design end-to-end, plus the prototype front-end

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.

Visual + interaction design

Brand identity + 10 screens

Palette, typography, motifs, component patterns, and the 10 screens across mobile and web. I designed them in parallel with the system rather than on top of it, 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 (mobile and web). Built before screen 01 so the 10 screens would feel like one product instead of ten.

Prototype front-end

Live HTML/CSS, not Figma exports

Every screen on this page is live HTML, with the same tokens compiled into CSS variables and the same components built as real markup. The pilot needed to feel like a real product rather than a slide deck.

The redesign

10 screens, live and interactive

Click a tab to switch screens. These are the actual HTML designs, not screenshots. Scroll inside any screen to explore the full content.

braintech.app / sign-inmobile · 370px

01 · sign in

Violet hero panel with grid texture. It establishes the brand identity right away, and the grid references code and structure, which is relevant to the audience without being literal.

Orange brand mark on violet. The BT logomark uses the core color relationship from the very first screen, anchoring the palette before any interaction.

Wave SVG transition. Instead of a hard edge between the hero and the form, an organic wave creates a fluid, energetic division. It's a small detail that adds a lot of character.

"Log back in, builder." It speaks directly to the teen's identity. Not "Welcome back" but "builder," set in Syne 800 so it feels bold and ambitious.

Design system

Built before the screens: tokens, components, patterns

The design system was the first deliverable. Building the token library and components upfront meant every one of the 10 screens feels 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, scroll to explore

BrainTech · Design System v2 interactive

The texture

The interaction I spent the most time on was the one between a wrong answer and the next question

The quiz could have ended at correct or wrong, the way most learning apps do it: a check mark, a buzzer, on to the next question. The moment I obsessed over is the second right after a teen gets a wrong answer. That's what decides whether they quit the app or keep going, and most products lose them there by being preachy, slow, or condescending, which teens have near-zero tolerance for.

The "Good to know" explanation card had to land in under a second, explain the concept in plain language, never use the word incorrect, and stay tonally level with the user, more like a friend correcting a friend than a teacher correcting a student. The visual treatment had to read as a normal continuation of the quiz flow rather than a punishment screen. Getting there took a few rounds: the teal "Good to know" pill, the explanation prose at 14px on a soft cream surface, and the auto-advance with a hold-to-pause, across three passes of design, three of prose, and one of motion timing before it felt the way it should have all along.

On the surface it was just one card sandwiched between two screens, but it's what separated a quiz that teaches from a quiz that only tests.

Impact

What shipped at the end of the pilot

10
Live, interactive screens
mobile and web, real HTML rather than Figma exports
12
Color tokens defined
adopted across every screen and component
6
Component families
buttons · inputs · cards · nav · progress · badges
2
Audience tracks on one IA
teen learner + parent buyer · single content model

The pilot delivered a redesigned brand, a token-based design system, and 10 live HTML screens across mobile and web. Every screen pulls from the same 12 tokens and the same 6 component families, and that shared system is what makes 10 screens feel like one product. The deliverable doubled as a starting codebase: the future build team reads tokens from CSS variables and components from real markup instead of stickers in a Figma file.

Shipped solo as the lead designer with the prototype front-end. Product direction came from the client stakeholders. Everything between the brief and the built prototype was mine: research framing, brand, IA, design system, screens, and the HTML/CSS the screens render from.

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, the quiz feedback states. Designing for teens is about respect at least as much as it's about color.

Why the designer-who-codes matters.

Building the prototype in HTML/CSS rather than Figma changed what survived to the demo. Type rendering, responsive behavior, focus states, the wave SVG between the hero and the form: all of it would have been merely illustrative in a design tool, and it became real the moment the front-end held it. The pilot's job was to convince a future build team that BrainTech could be a real product, and the most convincing way to do that was to hand them a real product to read.

What's next.

The natural next move is watching what the build team does with the foundation: which tokens hold, which components extend, and which patterns earn new variants. The two I'd most want to carry into the production build are the streak calendar and the quiz feedback states. They use different metaphors but share the same posture, which is to treat the user as the builder they want to be instead of the student a school product assumes they are.