At GDG DevFest Hanoi on 15 November 2025, I had the opportunity to share a topic about “Design Systems in Flutter: Today, Tomorrow, and Beyond”.

It was an energizing room, with many developers and curious people wanting to understand how UI, frameworks, and design methodology are evolving together. In this post, I’d like to wrap up the session highlights and capture what we explored during the talk.

🧩 1. What is a Design System?

I kicked off the session with the basics:
What exactly is a design system?

Referring to Figma’s blog post, we explored design systems as a shared language - a combination of principles, patterns, components, tokens, and documentation that help teams build consistent interfaces faster and with fewer decisions.

Beyond being a repository of reusable pieces, design systems are about alignment - reducing ambiguity, increasing velocity, and keeping products visually coherent even as teams scale.

🎨 2. Material Design as an example

To ground the concept, I walked through one of the most influential design systems of our era: Material Design.

We explored:

  • Its history, from 2014 to 2025

  • It also came along with introduction videos showing the evolution through Material 1 → Material 2 → Material 3 → Material 3 Expressive

Material is more than just a theme - it’s a milestone in unifying design language across platforms, and it helps explain why design systems matter at framework level.

3. Introducing “Decoupling Design in Flutter”

This was the core of the talk: an inside look at the “Decoupling Design in Flutter” project currently being started and actively worked on by Flutter team.

A fun demo showing what built-in design systems in Flutter look like:

Why the decoupling project exists

I shared the context that led to this initiative:

  • Flutter now spans web, desktop platforms, but maintaining built-in design libraries inside the SDK doesn't scale well.

  • The community increasingly asks for support for third-party design systems like Fluent UI, Yaru, Shadcn, Hux, Moon, and more.

The arrival of Material 3 Expressive (May 2025) and Apple’s iOS 26 “Liquid Glass” design direction signaled a shift - UI design is becoming more dynamic and expressive than ever.

The 3 Core Problems Today

I highlighted three major limitations in the current Flutter UI architecture:

1. Forced Migrations

Big UI shifts- like Material 2 → Material 3 often require massive refactors just to get essential fixes or platform support. Teams and developers pay a high maintenance cost.

2. Slow Updates

Material and Cupertino updates are tied to Flutter’s quarterly releases. This delays bug fixes, design refinements, and feature updates that users expect sooner.

3. Custom UI Limits

Flutter’s core logic is tightly bound to Material, making custom design systems harder to build. Developers often end up duplicating components or losing accessibility features.

These problems become more visible while the ecosystem grows.

🎯 Project Goals & Targets

The Flutter team aims to solve these issues with a long-term architectural effort.

Key goals:

  • More flexibility: Let teams choose and swap design libraries without heavy refactors.

  • Faster updates: Material and Cupertino shouldn’t be locked to framework & engine releases.

  • Lightweight framework: Reduce the core SDK’s size and responsibility.

  • Better foundations: Invest in the core widget library so design systems can layer on top cleanly.

📦 What’s Changing?

The big shift:
Material and Cupertino will be moved out of Flutter’s core SDK.

They will live as standalone first-party packages in flutter/packages repo and on pub.dev.
This makes the framework:

  • lighter

  • more modular

  • able to iterate faster

  • friendlier to 3rd-party design systems

Alongside that, Flutter is significantly investing in the core widgets library, making it a stronger foundation for any design system.

Project Timeline

I shared the plan announced by the Flutter team:

  • Phase 1 (from July - End 2025):

    • Reinforcement - A Better Foundation Critical Pre-Decoupling Refactoring

    • Ongoing Reinforcement and Community Collaboration

  • Phase 2 (Early 2026): Relocation - Establishing New Packages and a Faster Release Process

  • Phase 3 (Late 2026 and Beyond): Removal: A Phased and Predictable Deprecation

This is a multi-year effort, and when completed, apps will need to migrate to use external Material/Cupertino packages but with clear guides and tooling to support the transition.

4. Community-Built Design Systems

After discussing the upcoming changes, I showcased examples of thriving community design systems, including demos and visuals.

These included:

  • Fluent UI

  • Yaru

  • Shadcn

  • Hux

  • Moon

  • And several experimental or indie design libraries

The takeaway:
Flutter’s future UI ecosystem will be more modular, expressive, and diverse than ever.

5. Introducing Flutter Phở community 🇻🇳

One highlight of my talk was sharing about Flutter Phở, a new community initiative in Vietnam.

I explained:

  • Why the community was started

  • The desire to bring local meetups and events similar to global Flutter communities

  • The goal of building a space where Vietnamese Flutter developers can connect, learn, and grow together

The response from the audience was incredibly encouraging. Many developers asked how they can join future events, exactly the kind of energy that sparks a strong community.

6. A Little Fun: Game time

To close the session, we played a quick Kahoot quiz, equal parts fun and chaotic 😄
It was a great way to test what people learned, spark laughs, and end the session with high spirits before moving into networking.

Disclaimer: Everything in this talk comes from Flutter’s public documents and design proposals. I’m not speaking on behalf of the Flutter team, just sharing what’s publicly known.

I also expect to listen to all your feedback and questions, if any:

Feel free to look again at my slide for the talk here.