I can’t speak to how Fluent is working for folks within Microsoft, but from the outside looking in, it sure seems like one hell of a design system. The polish detail and pure production value is incredible and maybe even a little jealousy-inducing as I can only imagine the budget and resources it took to make this a reality. Again, these are all uninformed observations, but it sure gives me the vibes.
So, big kudos to the team and to Microsoft for making this a reality. This seems to have set the bar even higher.
A design system’s primary purpose is to serve as a single source of truth. When a design system is compromised, it no longer serves as a trustworthy source for product consistency and coherence.
I added this article not because of the specific suggestions (they’re fine) or even the subject of the article (which is also fine). I added it because of the quote above and how important trust is for a design system. I’m beginning to come to the conclusion that the greatest success a design system can achieve is to be seen as an institution. And institutions are built on trust.
That conclusion is starting shape my view on how to go about making a design system. Instead of guidelines or components, the most important things a design system can build are relationships, confidence and belief that the system will eventually get to that ideal state. Sure, practically speaking, that’s achieved through building guidelines and components. But you can make those things in a way that creates or erodes trust. I’d make the case to take the extra time or have the extra conversation to always be building trust.
And yes, testing is important too - obviously. But to me, it’s less interesting how to test and more so about why it’s so damned important to begin with.
The design systems community is about as welcoming and generous as you’ll find. I’ve met countless people who I both respect and thoroughly enjoy talking with. If you’re in the bay area, I’d suggest checking out this Design Systems Community Chapter. I’ll bet the farm you’ll meet some great folks.
This is another system design tool from the same cut of Shaper that is starting to define what a full-fledged system design tool could be. I think dedicated tooling is the ideal next step for this skillset. Figma ain’t it, at least how it currently works. There’s a need for a tool which designs the thing that designs the things. Do I know what that would look like? Nope. Do these begin to tickle my imagination? They sure do.
My hunch is this: folks can’t talk about real design systems problems because it will show their company as being dysfunctional and broken in some way. This looks bad for their company and hence looks bad for them. But hiding those mistakes and shortcomings by glossing over everything doesn’t just make it harder for us personally, it hinders progress within the field itself.
Bingo—this drives me batty. Design systems are incredibly challenging at the best of times due to their sheer scale and complexity. Mistakes are commonplace and their magnitude can be crippling. No one has “figured this out”. There’s no 5-step process to a successful design system. It’s galactic arrogance at best, willful grifting at worst.
And the speaking circuit is especially packed with this dysfunction. Attendees are showered with talks about how some speaker figured it all out and are winning their way through life. I obviously can’t attest to every talk, but I do know that many are taking some excessive liberties in their storytelling. People have books to sell, courses to pack and personal brands to inflate.
But that results in many folks who come to the conclusion they’re woefully incapable and the only kid on the block and hasn’t figured this all out. The truth is, no one really knows what they’re doing. We’re all muddling through it. And it is incredibly hard.
But saying things like that doesn’t sell any books.
To be useful for you, a design pattern has to come out of and express some reusable part of your particular product experience — those parts of the design you find yourself making again and again.
First off, this article wins the longest-yet-clearest-synopsis-of-the-subject award. Secondly, I really like this idea because I think it allows system designers and product designers to rally around their venn-diagram overlap. System designer are hyper focused on understanding how a thing fits within the entirety of an ecosystem. This can get really serpentine when getting into the nitty-gritty details of how every facet of a UI element is compatible with the rules and models of the overall system. And the same goes for product designers—understanding the specifics of the business goals and customer needs is usually deeply entrenched knowledge for a specific team.
But a UI pattern? Hey, we both do that! That seems to be the best place to collaborate and then allow each team to apply their specific know-how to that common artifact. It just makes way too much sense.
…the tension between craft and scale in tech has much more to do with the size of the product you’re building and the speed at which you’re trying to build it.
I agree that craft at scale is incredibly challenging. Additionally, the more time I spend in this industry, the less I think craft isn’t the right goal to begin with. Craft is associated with quality—which I would argue is the ultimate goal. If that’s the case, there are other ways to achieve quality that are in fact scalable. If we set our goal short and focus on craft, it’s easy to get sucked into the mindset of craft for the sake of craft. And that’s of highly questionable value.
Concepts like relationships, contribution, and installation don’t just apply to components. They’re generic functions of documentation. With care, these can be defined for use across any documentation pages and any documentation projects. That’s where a functional approach to documentation is powerful.
We’re all shouting like maniacs about AI while there are much simpler and, I would argue, more effective way to streamline documentation by applying a functional approach to documentation. To be honest, I’m kicking myself that I hadn’t considered this a long time ago.
Good systems are hyperobjects that capture decisions, language, patterns, history, and all of the things that make and have made your organization’s design what it is. They resemble knowledge graphs far more than products, and I’d like to see some of the emerging patterns around software for managing a knowledge graph applied to design systems.
And I would as well, although with reservations. Knowledge graphs are intriguing yet seem like something that can become a tangled web if not well thought through - exactly like a design system. Nevertheless, this is a subject area that I would love to flirt with in the future.
Typically, headlines for a case study tend to follow both the conceptual structure of (1) Problem, (2) Solution, (3) Results and are literally written that way. But putting the headline Problem above a paragraph only labels it. It presumes that a scanner will read the text that follows. But since we know that the majority of scanners will not do this, re-writing the headline to summarize the paragraph’s content is the right thing to do. “Solution”, for instance, becomes “**Reduced Time to Market by 60%.**” This small copywriting effort serves 100% of your audience.
Who here thinks their customers thoroughly read documentation? Yeah, me neither. This article wasn’t written specifically for design system practitioners, but it might as well have been. The article (which I thoroughly read, by the way) outlines realities of content consumption and provides some useful/concrete suggestion on how to adjust your content accordingly. It seems like a no brainer to abandon the “generic headline” and instead use it as a set of TL;DR cliffnotes for guidance.
If you click on one link, from this week’s post, click this one. Pinda shares a damned smart way to systemize language in a way that I could actually see being used. I never thought of baking writing standards into Figma components. Kudos to this team for a damned clever solution.
As you develop your design system, ensure you strike a balance between expressive patterns and necessary constraints. When a design diverges from an expected pattern, it can offer valuable insight depending on the intention of the design.
I’d argue constraints are what makes a design system. This is a good thing. First of all, it (should) create healthy boundaries to guide folks to ideal paths. Secondly, it creates a healthy tension between status quo (what the system supports) and change (what’s divergent from the system).
Do you enjoy writing? And once you’re done writing, do you enjoy writing some more? Well then, dear reader, design systems may just be for you! This article is a helpful resource to call out some of the larger communication touch points for a design system team. And believe it or not, I’d argue the things listed in this article are just the tip of the iceberg.
So, kind design system practitioner, warm up them fingers, because you probably have some typing to do.
I’m intrigued to say the least. For teams who are just getting started in their own design system and/or don’t have the luxury of spinning up their own solution, this could be a huge starter resource. I’m still of the mind that things like this often make sense to eventually be built internally so you can get exactly what you need. But definitely not something to start with. At some point I’d love to toy around with this.
There are some pretty helpful tips in here. I learned about the HTML thin space entity (cool). Plenty of things that can be applied to a design system. However…
Don’t Use Helvetica, Inter, & Roboto
Mike lost me on that one. His argument is that those fonts are too commonly used. I’m may not die on the hill for those fonts in particular, but I’m firmly in Massimo Vignelli’s camp on this one.
This project interests/baffles me. I also have no idea how to make it work. This may just be due to the fact that I’m a dummy, but things just didn’t seem to work in a way where I could grok what was happening. Again, this could just be me, so take what I say with a pinch of salt. That said, the thing that clearly stood out is the potential for Figma widgets in relation to design system workflows. My mind is already racing.
This article argues that from film to fashion and architecture to advertising, creative fields have become dominated and defined by convention and cliché. Distinctiveness has died. In every field we look at, we find that everything looks the same.
This is a great article and I think the rise of the internet has only accelerated/exaggerated homogeny. Why do I bring this up in a design systems editorial? Because I see this happen all the time in design systems and I die a little inside in every instance. Don’t get me wrong, we shouldn’t ignore convention or deny its value, but I also don’t think it should necessarily be the default to follow what other systems do because, well, they’re other systems.
Yes, I know, this is hysterically ironic coming from someone working in design systems, but there you go. I’m a contradictory enigma.
There’s a lot to like with the thinking here. I don’t necessarily think this version of the idea will work for teams working on mid-stream design systems, but the concept behind it is lovely. I’d be so excited to quickly “prototype” how changes to core visual attributes would impact entire interfaces for the product I serve.
So yeah, this concept has legs. I would love to see it keep going.
Automated testing (will not catch most issues)
First off, I appreciate the Washington Post design system team for calling out that automated tests won’t “fix accessibility”.
Second, this is the kind of accessibility guidelines that we should all aspire too. It’s exhaustive, actionable and seems completely devoid of fluffy jargon like, “We care about blah blah blah.”
Third, from an entirely outside perspective, I’m damned impressed with the Washington Post design system’s documentation. It reads clearly, checks all the boxes and is damned handsome (in that classic journalism kind of way).
This article is in no way intended to be an ultimate guide.
If that’s the case, I’d hate to see what an ultimate guide looks like.
You can go really deep into iconography. I did once upon a time (link omitted to avoid any hint of self-promotion). The conclusion I eventually came to is that it’s (usually) not worth it. Here’s my advice: Make well-designed icons. Make them readable. Make them clearly articulate the subject. Make them simple to use within the system. And then move on.
The purpose functions as an entity of the solution, regardless of how it is shaped, its features, or how the code optimizations will evolve—the entity will always abide by its purpose.
The author makes a strong case for the importance of intentionally and doggedly defining each piece of a system, centered on purpose. This is hard work and often unpopular as it requires correcting and corralling. But those unsettled misalignments can set people up to fail and lead to poor outcomes.
Daniil on the Volvo team share how their team deals with the challenges so many design systems teams also face–namely fragmentation across system touchpoints and communication of status/updates. My two cents is that these are the problems I’d love to see tool makers focus on as opposed to yet another all-in-one design systems platform.
It’s hard to believe Storybook is seven years old now. While I’m not necessarily a fan of Storybook as the documentation solution for an established design system, I think absolutely has an important role in the market. If I was as a startup building a new design system from scratch tomorrow, Storybook would be on the shortlist for documentation.
A nice podcast episode primer on design systems which adds more proof that each and every design systems conversation devolves into a discussion about naming.
The most important lesson we learned after designing the new Wikimedia grid was to focus on what really worked for us, and not to worry about what is commonly used on other websites.
First off, it’s great to see the use of a grid by the Wikimedia design team. It’s astonishing how many modern software products don’t have a grid in use. Secondly, it’s nice to see folks putting some critical thought into the application of a grid as opposed to stubbornly sticking with what’s been used in the past.
A distributed design system could decrease an organization’s total cost of ownership as its development and maintenance can be shared by several product teams rather than one dedicated team.
Ah, the eternal promise of federated design systems. I for one have not seen this model play out as dreamingly – at least at larger scale. A federated model assumes a lot of things like equal contributions across all teams, agreement on how components/patterns should look and work and agreement on how all the pieces fit together. Those assumptions have often been in short supply in my experience.
When we say “design systems create a shared language”, a lot hinges on creating agreement on the specific names for things.
I’m just going to go out there and say if naming is the biggest challenge your design system is facing, you’re doing just fine.