Redesigning Discord using Material Design 3 to find out exactly where the system breaks.
What if Google bought Discord?
Project Type
Design System, UX Research
My Role
User Experience Design
Project Timeline
2 weeks
Software Used
Figma, Material Design 3, Discord
Overview
Discord x Material Design 3
Design Systems are easy to follow when the product fits the system's assumption. The interesting question is what happens when it doesn't. Discord is on eof the most expressive, community driven interfaces on the internet. It wasn't built for discoverability, but for peopel who alreayd know exactly where they are going.
material Design.3 was buildt for opposite, structured systematic, design to orient a user who moght be encountering an interface for the first time. I wanted to find out what happens when you take a system built for one set of assumptions and apply it to a product built on completelyy differen ones. Not to imporve Discord but because the gap between them was a most honest stress test I could think of.
FInal Design
Title
Surfaces Redesigned
System Gaps found
Mistakes
System stress tested
Scope note: This is a design systems exercise, not a UX redesign. The goal wasn't to improve Discord's UX. It was to find out whether MD3's component hierarchy can absorb a high-expressivity product and where is runs out
The Tension
Discord's layout was built around one behavioral pattern: a user who returns to the same server and channels every day. Its navigation isn't designed to help you find things; it's designed to disappear once you already know where everything is.
Discord's Assumption
The user has been here a hundred times. Navigation is muscle memory. Discoverability is not the goal, habitual return is. Every layout decision optimizes for the user who already belongs.
Material Design's Assumption
The user might be encountering this interface for the first time. Every component assumes it could be lost. Every decision traces back to a structural rule that orients a new visitor
"Discord assumes you've been here a hundred times. MD3 assumes you might be lost. I had to design for both and document every impossible place"
Before any screens
Mapping Discord to MD3's token structure
MD3 is not a UI kit. It's a dependancy chain, tokens inform components, components build patterns, patterns define layouts. A single wrong token cascades through everything build on it. So before touching Figma, I had to answer one question, where does Discord's brand actually live inside MD3's structure?
Running Discord's #5865F2 through Material Theme Builder generated 40 color values. I used the Navigation Rail, App Bar, cards, and tabs, which were inherited automatically. Get the tokens wrong, and every screen that follows is wrong.
What I missed
I build it wrong.
Here's what I learned,
Most case studies show the final design. This isn't one of those. Two significant wrong turns happened before any surface looked right and they're more instructive than the final screens.,
Two system, neither resolved
Mistake 1
The components are MD3. The foundation isn't.
I placed MD3 components but never ran Discord's colors through Material Theme Builder. The dark backgrounds, the blurple, the surfaces still Discord's raw hex values. MD3's tonal system never generated them. Every component was sitting on a foundation that the system didn't build.
Mistake 2
I confused what a component can do with what it's designed for
While designing the onboarding list and content area, an architecture problem was happening one column to the left Discord's server rail and an MD3 nav rail running alongside each other. Two systems, neither resolved into the other. I only saw it stepping back after the fact. of
Final Design
What MD3 did to Discord, surface by surface
Design Solution 1
Navigation + onboarding screen
Discord's layout assumes three independent columns: server membership on the left, channel navigation in the middle, and content on the right. MD3 has clear names for two of these, which are Navigation Rail and Navigation Drawer, and precise rules for both.
The question was whether Discord's columns could map cleanly onto MD3's architecture without losing what each one does.
What MD3 required
Navigation Rail at 80dp with icon + label stacked. Tonal container on the selected state using secondary-container. Navigation Drawer for channels. Three distinct surface tonal levels across the three panels: rail, drawer, and content area, each on a different elevation token.
What I built
surface - container - low
Surface - Container
Rail, drawer, and content mapped to
surface
,
, and
MD3 List Component structure with section headers in
on - surface - variant
respectively. Events selected with tonal container. Channel list items using
Unresolved
The onboarding list icons are still Discord's
MD3 requires tonal icon containers rounded square,
secondary - container
background
Material Symbol inside. The current icons ( pink starburst, teal diamond, green circle) are Discord's custom blob shapes. The list structure is MD3. The icons inside it aren't. This is the one place the translarion is incomplete, and it shows exactly where Discord's expressiveness resists the system.
The Cost: The server avatar at the top of the Navigation Rail, "the "SR's server" circle" is Discord's community identity sitting inside an MD3 component slot designed for a Material Symbol. MD3 has no pattern for community membership inside navigation. The structure is correct. The concept underneath it has no MD3 equivalent.
Design Solution 1
Video call interface
This is the surface where MD3 runs out of components entirely. Discord's call controls float loosely over the video. MD3 has icons, buttons, FABs, and Action Chips, none of which are designed for a persistent call control bar with grouped hierarchical actions. There was no component to drop in. Everything had to be built from primitives
What MD3 required
MD3 has no call control bar component. Building it required going one level down to the primitives: Icon Buttons for individual actions, Split Button for grouped controls with dropdown states, and a Surface-level container for the bar itself, every touch target at 48dp minimum.
What I built
Icon Buttons for mute, camera, screenshare, effects, overflow. Split Button on the microphone (icon left, dropdown chevron). End call in error color, the one place MD3's error role is semantically correct here. Bar anchored tothe bottom on
surface container
The Cost: Discord's call controls disappear when you're not hovering, keeping attention on the video. An anchored MD3 bar is always visible, more accessible, and less immersive. Whether that's the right trade for Discord's users, where the call is the point, isn't a question this project can answer without testing.
Design Solution 3
Discord uses gg sans, a custom typeface designed specifically for the product. Casual, slightly playful at small sizes, optimized for dense chat. MD3 requires Roboto and a fixed type scale at every level.
The Cost: gg sans was designed to feel like Discord casual, a little playful, optimized for dense chat at small sizes. Roboto was designed to feel like nothing in particular, which is exactly the point for a system typeface. Every MD3 component works correctly with Roboto. Discord's personality in text is quieter.
System gaps
Three places MD3 had no rule
Every design system has edges. You don't find them by reading the documentation. You find them by building something the system wasn't designed for.
Gap 01 - Component Missing
Multi layered floating call controls
MD3 covers Icon Buttons, FABs, and Action Chips. None of these handles a persistent call control bar with hierarchical grouped actions. My first attempt put the FAB in the Navigation Rail with a phone icon, wrong semantics, and wrong placement. FABs represent primary creation actions. A call-in-progress module is a persistent status interface.
Resolution
Build one level down. When MD3 has no component for your use case, use the components that component would have been built from. Icon Buttons for individual actions. Split Button for grouped controls with dropdown. Surface level 2 container for the module itself.
01
Gap 02 - Concept mismatch
Server identity inside a Navigation rail
Navigation Rail destinations are places you go. Discord's server column is the communities you belong to. MD3 expects icons to be Material Symbols 24dp, from a specific icon library. Discord server icons are 512×512 community avatars representing hundreds of members. The system had no pattern for this distinction between navigation and identity.
Resolution
Used Navigation Rail structure and spacing exactly 80dp width, 8dp padding, tonal container for selected state, but replaced the Material Symbol slot with a circular avatar image. Every structural rule was kept. One visual rule broken. The distinction matters: structural rules solve problems. Visual rules create consistency. When they conflict, structural wins.
02
Gap 03 - Context Mismatch
Urgency and Promotional surfaces
MD3 was built for Gmail, Calendar, Drive, and Maps. None of these runs on conversion urgency. There are no "Only 2 spots left" patterns. No promotional banner components. No visual language for scarcity or time pressure. Discord uses promotional surfaces, such as Server Boost banners, Nitro upgrade prompts, and event announcements. MD3 gives you Cards, informational Banners, and Dialogs. None is promotional in intent.
Resolution
Built promotional surfaces using MD3's foundations, the 12-column grid, elevation, color roles, but invented the layout pattern. Used the tertiary color role for promotional surfaces to separate them from primary navigation. MD3 gives you vocabulary and grammar. Some sentences you have to write yourself.
03
The answers
" Can an interface built on community- driven chaos survive inside a system built on structure?"
YES.
But it won't look like itself anymore
MD3 absorbed every surface I gave it. The navigation is clearer. The call controls are more reachable. The typography is more legible. The hierarchy is explicit in a way Discord's never needed to be.
, And Discord's character, the expressive depth, the ambient layering, the sense that something grew from a community rather than was designed top-down, is quieter inside MD3's structure. Not gone. Quieter.
"That's not a failure of Material Design 3. That's what systems do. They reworganize everything on their own terms"