Design System Fundamentals
A designer’s guide to the Fluent Design process and co-creation one year after its introduction
The Fluent Design System launched one year ago at Build. Joey Pitt, a Principle Design Lead on the Fluent team, shared his inside perspective on how the system works, how it is evolving, and how to get involved. Here are excerpts from our conversation.
Release Waves
DB: We’re coming up on a Fluent birthday
Joey Pitt: Fluent works with biannual releases. This cadence gets us a lot closer to some of the things that Agile development can do, like being more hypothesis-driven, being able to test things in the wild, and then course correct based on feedback. For example, we can posit “Hey, we think that this is right,” or “This is where the industry is going, or where our core consumer is going, and we need to pivot that way,” whatever it may be. We have tools to help us quickly correct so ideally, we can act on feedback even before the larger public sees it.
So it’s like a software as a service (SaaS) model, except it’s design-system as a service?
Yes, twice a year we decide what to prioritize and build in the next release. There is always an abundance of ideas and feedback. We use things like the Feedback Hub, the Insider Program, talking to customers, the MVP Summit, and events like Build to gather information and feedback from customers — that help us prioritize that work.
This cycle allows us stay plugged into the industry. Our partner teams across Microsoft, like Office, Cloud and Enterprise (C&E) and Xbox do the same thing, so this is a collaborative and cumulative effort. At the end of the day, we’re building tools for app developers to create experiences for their customers, so we all need to be in sync.
We can also use these feedback avenues to focus on specific components in our platform like UX fundamentals, controls, or patterns. That might take the form of “That acrylic recipe wasn’t quite right. We need to fine tune it a bit.” Or, “The reveal needs to be faster or slower here,” or “This control that we’re doing wasn’t quite right, and we need to adjust it.”
That’s the general process. It’s really iterative. It really is hypothesis-driven, and we use data from shipping products and feedback to help us move forward. We do that internally, day to day, in designing and planning with partner teams around the company, and we do it externally through our feedback avenues.
Design Stages
Within each release, you’re not just working on one set of product features. You’re working broadly to make sure that there’s enough material in process so that each release can be substantive.
That’s right. Design systems by definition are large and complex, so it’s not like we do a little work, and then ship it. We have these four stages of design and engineering that we cycle through in each release: incubation, systemization, critical mass, and pervasive.
1. Incubation
We start with incubation. That’s where we collect all feedback, we get the market insights, customer input, and say, “Of all the ideas that are floating out there that we could invest in, let’s spend some time tending to this set of ideas,” and they’ll go into incubation. Engineers and designers get together to figure out what the scope of an idea is, how much effort it would be to do it, what the benefit is for customers. This effort could last for part of a release or it could last a few releases, depending on how complex the thing is. In Agile terms, incubation is developing the master backlog.
The important thing to note is that this isn’t just designers’ blue-sky thinking. It’s driven from real customer insight, as well as engineering and product goals.
2. Systemization
When we have a clear scope, and we understand what the feature is going to look like, when we’re ready to start writing real, shippable code — we go into systemization. This phase is creating a real API that is consumable, usually by first-party developers, to ensure we’re not doing something off-track. Depending on the feature or component, we share our work with close partners and MVPs during systemization to help us test things out.
3. Critical Mass
When we’re ready to release that feature into the wild, we bring it to critical mass. A feature goes into critical mass when there are at least a few of examples of first-party experiences: These could be from the Windows Shell team, first-party (Microsoft designed) apps, Xbox, or Office. When first-party customers have used these APIs and features we say that’s at critical mass, and that means we can go on stage at an event like Build and say, “This is a Fluent element. Here’s the control and feature in isolation. Here’s all the code. And here are a couple of examples of that feature or element in practice.” Or “Here is Reveal on the Start menu. Here is Acrylic in the Task Bar.” Whatever it may be.
At this point it’s ready for third-party designers to use and create experiences for their consumers?
Yes. If you were an MVP, you might have seen it earlier, but if you’re a 3rd party designer, that’s when you can say “OK, great, this is something that’s ready for me to run with.” Around that time, we’ll see that component or feature being adopted. Then, after a few months, we start to see it becoming pervasively available in the creator community.
4. Pervasive
We call something pervasive when it’s being used broadly enough so that a general customer might see it. That stage is really important because that’s when we get the bulk of our feedback. We gather feedback in the critical mass and systemization phase as well, but the pervasive phase is when we get real consumer feedback: “This is working; this isn’t working,” “It makes the app much better,” or, “It’s not doing what we want it to.” We listen and course correct from there.
These four phases occur in each release cycle, and they allow us to always have a full set of work that we’re rolling into. That way, we never have to be super precious about moving forward with any single hypothesis or feature.
Co-Creation
Your app creator audiences are made up of a mix of designers and developers. How do you engage with them?
We’re getting better at the design part of it. Historically, Microsoft has been such an engineering-oriented company that when we built the Insider Hub and the feedback tools, we started by wanting to energize and engage the developer community.
Now we’re doing more and more through Medium, witter, and our new Microsoft Design site (relaunching this May) to activate and engage the design community. Watch this space — it’s a work in progress.
As a designer, should I consider joining the Insider program?
Absolutely. Fluent is as much about designers as it is about developers. We want to talk about app creators in general. Right now, all of the places that we talk about are geared to engagement at the Dev Center. And by engage, we mean look at the APIs, download sample apps, look at the code.
At the same time, if you’re a designer, there’s a bunch of design-oriented discourse on those same pages where we have code. There are toolkits that for designers, too. Our intention is that as we grow, we’ll utilize assets like the Microsoft Design site to engage with designers without them feeling like they have to go to a developer’s place to get design stuff.
Right now, that’s a work in progress.
You’re already working with teams in Office, C&E, Xbox, HoloLens, and Cortana (as well as Insiders and MVPs). All those designers are helping the Fluent team iterate and make it better, but a unique thing about Fluent is that it’s also open to third-party designers. In addition to becoming an Insider, how do they go about getting involved in co-creation?
That’s a good overview of our co-creator communities, and it’s why events like Build are so important, because those events are ground-zero for engagement. MVPs and Insiders have additional avenues for feedback, but even for them, Build is the best place because we actually have people from the design and engineering team there. At other big events like Ignite and Dev Days we also have people from the design and dev teams there, showing and walking through code, “This is what we’re actually shipping,” giving MVP sneak peeks about, “This is what’s coming up next — what do you think? Give us feedback.” Those are the significant times where we all come together.
Build 2018 is happening from May 7–9th in Seattle. We hope to see you there and at other events throughout the year!
Attend Build
Find out more about Fluent Design and join the diverse community of creators
Check out #FluentFridays on Twitter @MicrosoftDesign
Check out the Insider program
Follow Microsoft Design on Dribbble, Twitter, and Medium
Follow Joey Pitt on LinkedIn
To stay in-the-know with Microsoft Design, follow us on Dribbble, Twitter and Facebook, or join our Windows Insider program. And if you are interested in joining our team, head over to aka.ms/DesignCareers.
