Microsoft Fluent: better-at-a-glance usability
Microsoft Azure (Windows, Webapp) concept. © Microsoft. For conceptual purposes only.
Fluent was announced in spring of 2016. How a small group designing for a big organization’s portfolio made it work.
An elegant system for a complex world.
A visual exploration in visual focus and hierarchy
This post was created in reference to Microsoft’s Fluent design system as a collaborative effort between Cloud + Enterprise Design and Windows Devices Group. The opinions below are my own and do not reflect those of Microsoft or its partners.
Muscle memory, consistency, speed and efficiency — all of them circle around one of the core principles we established early on in the design process. At face value, most designers would say ‘we want users of our product to be able to complete their tasks as frictionless as possible,’ but where the opportunity lies is in the supporting logic system.
There are three tenants shared across all of our designs aimed at addressing systematic thinking on a visual level: establishing a clear hierarchy, assigning semantic meaning to color, and reusable learning.
A clear visual hierarchy
When we began our exploration, we wondered how we could use ‘material’ to establish some sort of visual hierarchy. For those unfamiliar, the Fluent Design System explains material as -
The things that surround us in the real world are sensory and invigorating. They bend, stretch, bounce, shatter, and glide. Those material qualities translate to digital environments, making people want to reach out and touch our designs.
An early material exploration in-context with several apps open in the background
As we explored, we discovered the acrylic material worked well in helping apps maintain contextual focus on the workspace, but at lower opacities and visual densities apps in the background obstructed the app in focus.
To address the apparent context obfuscation, we began to establish a containership method that could scale using layered materials. For native apps acrylic was the base and web apps would use a color scale to imply opacity — in both cases we use shadows for the containers themselves. Additionally, we made the decision to only use a shadow when activated by a control or action.
The other piece of our hierarchy story was typography. At Microsoft, we use the typeface Segoe. For several years now, we’ve been using mainly ‘Regular’, ‘Semi-light’, and ‘Light’ weights for both our in-app and marketing experiences. In cases where there’s a clear parent-child containership architecture, we began to use variants of ‘Bold’ for titling on the focused window.
Containers, shadows, and the logical path
Logical path in-context
Assigning semantic meaning to color
Our color story is two-fold: color use on actions and navigation elements. In general, our aim is to extend meaning to color to help with discoverability.
In the past, we’ve explored using mono-chromatic icons for both actions and top level containers — and while this is visually pleasing, it doesn’t always help usability. What we’ve found both in user studies and anecdotally is a certain level of muscle memory in repetitive tasks as they relate to your everyday software experience. Any sort of change, big or small, needs to be thoughtful and enhance that experience.
When it comes to developer tools, there’s a certain amount of equity in how things look and where they’re located. In our explorations, we’ve updated the palette for existing actions inside full-color ribbons and introduced a similar color story to those apps which have different color variants.
Reusable learning (cohesion)
Developers use a variety of products to do their work. For the applications we create and maintain, we think there’s an opportunity to capitalize on commonality. Currently, our UI story is relatively fragmented so we thought we’d address it by aligning commonalities where applicable.
In addition to aligning our type and visual hierarchies, we’ve standardized placement of common elements like ‘settings’ and ‘notifications’. Each navigation system operate essentially the same way with a blend of both container and action-level commands. It’s consistent, but not constrictive in that we still allow for apps to keep the things that make them unique.
Our goal is to make the process of switching between apps as frictionless as possible — to make work as efficient as possible.
On this project I serve as, lead designer (US, Cloud + AI Studios)
The team
Learn more about our thinking. Read the article by Jamie Young my colleague from DevDiv. Learn more