“Is it possible to draw parallels between the art of the medieval cathedrals, and the design of a modern design system?”
This is the question I started to ask myself, while visiting the Freiburg Münster (cathedral) in a lunch break during Smashing Conference, a few years ago.
Paul Lloyd just finished giving one of his epic talks, in which he connected design, history, architecture, sociology, urbanism, and much more, to show how the design of systems always needs to embrace a multi-disciplinary approach, to analyze and understand a wider context of the problem.
The day before, Nathan Curtis explained in another great talk how a design system is made of multiple inter-related parts, and how we should “look beyond the toolkit” and work on the whole: it’s not about the parts but the connections that we draw across all of them. …
In recent months, I couldn’t help but notice how many people (and companies) when referring to “design tokens” what they actually mean is colors, typography, spacing (and in some cases elevation, timing, and sizing).
While this is perfectly true, I think a key part of the picture is missing: design tokens can be much more than this.
As Sarah Federman puts it perfectly:
In this post, I share my point of view and my experience on this topic, showing why so much more can be done with them, and how.
“Design tokens are so hot right now!” has become a meme in the Design Systems community, so you probably already know what they are. But if you don’t, or want to know more, I suggest you check out Sönke Rohde’s article (on how Salesforce, before everyone else, introduced the idea of design tokens), watch Jina Anne’s online course and talk, Danny Banks’ blog post, Stuart Robson’s repository, or Robin Rendle’s article. There is also a brand new W3C Working Group if you fancy contributing. …
A few days ago I was writing my bi-annual review, and I was thinking of how I could include some meaningful metrics about the success of our design system in Badoo.
It is undeniable that in the last six months Cosmos, the name we gave to it, has gained a lot of traction: everyone is mentioning Cosmos, everyone is starting to integrate or adopt Cosmos, there are even jokes around that if you have a problem, any problem, just open a ticket for Cosmos and it will be solved.
But this is not a metric. It’s really hard to measure people’s happiness, or the impact on how people work (and think) in term of UI, or the teams’ efficiency and velocity in delivering updates and new features to the product, and more in general the effect of a change in a complex system like a big company. …
This is the second part of a post about the creation of a pipeline that can take a Sketch file and export all the icons included in the file, in different formats, for different platforms, with the possibility of AB testing each icon.
You can read the first part of the post here: https://medium.com/@didoo/generating-multi-brand-multi-platform-icons-with-sketch-and-a-node-js-script-part1-82f438c7e16c
Using a custom build script in Node JS, it is possible to manipulate a series of Sketch files, and then, using an internal Sketch tool, automatically export their assets, to generate multiple icon libraries, for multiple platforms and different brands, that support dynamic colourisation of the assets via design tokens, and also AB testing of the assets via naming convention. Easy peasy :)
Well, actually it’s not that easy, but it can certainly be done. This post is a detailed explanation of how we did it, and what we discovered along the way.
Recently I have come across a tool, called Style Dictionary, developed by Danny Banks at Amazon, that allows you to manage design tokens (or “style properties”) for a design system. I’ve used it to replace the existing tool that we used to process the design tokens for our Cosmos design system. I’ve found the task very interesting, and I’ve decided to document it, so that other people may benefit from what I’ve learned during the process.
Notice: I’ve tried to be as comprehensive as possible, which means this blog post is extremely long. I know, I know… ¯\_(ツ)_/¯.
I was developing a UI component called “Page”. Essentially is the root component of a mobile web application. It has a main area that fills the viewport horizontally and vertically, and some sub-elements/containers with a fixed position (the tab-bar navigation, a modal overlay, the notifications).
The problem I had is that, in order to obtain this layout (that fills the entire viewport and has overlaying elements that remain fixed when the user scrolls the page) I need to use position: fixed in the CSS. Unfortunately this means that, when you showcase the component in the style guide, the “fixed” elements will overlay and fill the entire page! …
A few days ago I came across this lovely quote in a comment to a blog post about change (and why we are so extremely resistant to it). It’s from a book, There’s a Hole in My Sidewalk: The Romance of Self-Discovery, written by Portia Nelson, an American popular singer, songwriter, actress, and author.
It says a lot about how we need to be in a constant “learning-mode” if we wont to grow. It shows that our “experience” plays an important role in how we perceive what is difficult, what is blocking us, what is worth to step over. But most of all, how failure is part of the journey. …
This is the story of how a small style guide that was first introduced under the radar, became so appreciated by both developers and designers that it finally became a complex unification project — a design system called Cosmos.
Fast forward to today, a few months later, what has happened?
Our technical stack is pretty simple and “standard”. We are using a list of core design tokens processed with Theo. We are using React, because we have found it’s perfect for building UI components in the way we want to. On the CSS side, we are still relying on Sass and BEM for now: we have postponed the decision until we have a clearer idea of which approach we want to adopt (just BEM? Styled Components? CSS Modules? …