Everything you think you know about minimalism is wrong

January 16, 2020 • Everything, Think

It wasn’t that long ago that Instagram was flooded with saturated filters and low-resolution photos. But then the gaudy, maximalist look of the 2000s faded out of style and was replaced with an interest in clean lines and mature color palettes. Seemingly overnight, the platform became an ode to minimalism—filled with interior design and lifestyle posts from influencers anchored by organic, nautilus-shaped forms and eggshell-colored walls. Everything on the grid was carefully curated to be monochromatic, uncluttered, and uniform.

[Cover Image: Tree Abraham/courtesy Bloomsbury]

Minimalism has been eagerly adopted as an aesthetic by Instagram users and pretty much everyone else not on the social media application, too. Marie Kondo teaches us that minimalism is getting rid of anything that does not spark joy. Other influencers (and brands) suggest that it’s having a hyper-curated closet of a few basics, or a simple skincare routine featuring only three all-natural products. Minimalism has become a visual manifestation of “wellness”—a lifestyle trend rooted in conspicuous consumption.

But this loose misinterpretation belies its roots as a decades-old architecture and design philosophy. In his new book, The Longing for Less: Living with Minimalism, out from Bloomsbury January 21, culture critic Kyle Chayka investigates how we’ve veered away from minimalism’s true origins, and converted it into—what can be reduced to—a “look.” Here, Chayka helps dispel the four biggest myths of minimalism.

Minimalism has deeper roots than you think

Minimalism’s recurrence as an idea, in both society and art, reveals the philosophy’s central paradox: It is a quiet celebration of space, but bold in the way its simplicity overwhelms. “In the time right after World War II, minimalism was a popular aesthetic because it’s a perfect, utopian style that everyone can access,” Chayka says in a phone interview. Soon after, in the 1970s, the idea of “simple living” began to take hold, which is the last time eco-conscious consumer practices (less consumption, more self-reliance) were as in vogue as they are today. “I think the internet and social media and the financial crisis is what really caused the super popularity of minimalism this time around,” Chayka says.

Minimalism is not just a trendy style

It’s not difficult to imagine why we, as a society, long for less. Our lives are dominated by dizzying screens, which have forced us to prioritize images over the humanness of real life. “So much of our visual experience is on the internet now. That’s the container of our experience,” Chayka says. “And so it makes sense that the spaces we occupy would be very simple because we spend so much time on our phones.”

In an attempt to counteract the harm technology has done to our ability to focus, rest, and enjoy experiences, people have adopted minimalism as a visual aesthetic. It’s blank, inoffensive, natural. It’s even been marketed as a form of self-help.

Donald Judd, *15 Untitled Works in Concrete*, 1980-1984. [Photo: Flickr user Nan Palmero]

But according to Chayka, “minimalism is about experiencing the world directly and engaging with your surroundings.” Consider Agnes Martin’s austere canvases or Donald Judd’s spacious constructions in Marfa, Texas. In architecture, minimalism has roots in Japan, where “there’s a real interest in very refined textures and creating experiences with light and shadow—an architecture of ephemerality that modernism doesn’t really have,” Chayka says. In short, there was once a spirituality to minimalism that has been lost in its current expression. “The style now seems more like numbing yourself and creating a protective environment,” Chayka says.

Minimalism is not morally superior

Minimalism these days has an aura of moral superiority. “Minimalism has always been associated with moral purity or a sense of existing outside of society, whether that’s during the midcentury modern movement or the Voluntary Simplicity Movement of the ’70s,” Chayka says. “The problem with luxury minimalism today is that the style is associated with moral purity and outsiderness but it’s being adopted by the most insider people possible—wealthy women and tech billionaires. The style of minimalism [we see today] is a reality that’s not very minimal at all.” Clearing out one’s home for the sake of more space is not radical if there’s a financial safety net in place to buy it all back again, if one should so choose. (Steve Jobs’s uniform of black turtlenecks and jeans was not minimalist as much as it was a decision to not be burdened with variety.) So the suggestion that someone owning fewer objects is healthier and more put-together overlooks the fact that participating in the trend is less about the inward journey than it is about appearances. Nothing morally superior about that.

Eames House interior, 1952. [Photo: © Eames Office LLC/courtesy Bloomsbury]

Minimalism is not a commodity

Today’s Instagram-ready minimalism couldn’t have been born anywhere other than in the United States. “I think the commodification of minimalism has been very American,” Chayka says. “The idea of an entirely minimalist lifestyle is deeply American . . . we consume everything to excess, even minimalism.” Home organization entrepreneur Marie Kondo seems to have tapped into this American Achilles’ heel; her pivot to selling home goods reflects a genius awareness that consumers are eager to buy objects that represent an ideology, even though they are a shallow appropriation of it. This makes minimalism’s success on Instagram plain, too; it is now an element deeply embedded into a platform that has become synonymous with a certain brand of conspicuous consumption.

Inside a room at Yumiya Komachi in Kyoto. [Photo: Kyle Chayka/courtesy Bloomsbury]

What’s next

Sometime soon, the minimalism trend will likely slip out of the mainstream consciousness again, just as it has in the past. “I think we’ve hit peak minimalism and [are now moving] past it . . . minimalism is a trend and a style and it comes and goes in waves. We start obsessing over it and then find out that it doesn’t solve our problems,” Chayka says. For most people, minimalism is simply not a realistic lifestyle, because the very structure of our capitalist society relies on constant consumption and an attitude of overindulgence. To put it simply, minimalism—as it exists in the culture today—is a privilege. “It’s the difference between an Apple Store and a Zen temple,” Chayka says. “The Apple Store never changes—there’s perfectly clean glass and steel and empty space. But if you think of the rock garden in the Zen temple, it’s always changing and moving with time . . . it’s more interesting and sustainable than creating something that never changes.”

Buy The Longing for Less: Living with Minimalism, by Kyle Chayka, designed by Tree Abraham, Elizabeth Van Itallie, Mia Kwon, and Patti Ratchford for Bloomsbury on Amazon.

Everything You Need To Know About Green UX

January 11, 2020 • About, Everything

Climate change is taking its toll on the environment. The temperature is rising, the Glaciers are melting, sea levels are rising, and the fauna and flora ranges are shifting.

According to the Intergovernmental Panel on Climate Change,

“Taken as a whole, the range of published evidence indicates that the net damage costs of climate change are likely to be significant and to increase over time.”

From the very start, all of these effects and many others account for the change have accounted for critical damage induced mainly by human activity in the form of CO₂ emissions.

In the midst of it all, the internet is a prominent cause to blame. Sure, the virtual world is affecting the real world on a massive scale; how can a UX designer or developer be involved in the overall impact? Take an ecommerce site for example. As soon as the visitor approaches the website to buy their desired products, their actions initiate a chain of events that contribute to higher emissions.

It’s even reported that if the internet were a country, it would rank among the ones having a high carbon footprint, such as the USA, China, and India. Where the internet connects so many people, it’s also inviting other drastic measures for the evolving carbon footprint.

For most of the global climate change impacts, sustainable practices and resources have been brought in to combat and reduce the apparent damage shortly. Is there a way designers or web design companies worldwide can contribute?

Instead of digging in the solutions first, let’s start by identifying how UX is indirectly contributing to the environmental damage and what you should know about creating green UX projects.

How UX Contributes To Growing CO2 Emissions

Data Centers And E-Waste

Every activity you carry out on a website or any other online platform, you need storage for your projects, files, texts, documents, and other media. You may even contact a company that provides data storage of XYZ GBs. While you may be at ease for having saved your information, the data in cloud storage is negatively impacting the environment. According to Amanda Sopkins from Sustainable UX,

“Notifications replace daily newspaper deliveries, emails replace receipts, and virtual clouds replace boxes of photographs. At first, this seems like a natural way to build a more sustainable world. However, rather than leveraging our power to create minimal solutions for hard problems, we gorge ourselves on this seemingly limitless space.” She later adds, “The buildup of all this material has an impact beyond the carbon that is produced by the servers that stores it. It has an impact on us: we lose track of what matters and what we should save.”

With millions of people interacting on the internet daily, it won’t be wrong to say that the data is massively hurling towards hyper-emission. It’s something we don’t see every day!

Mobiles And Energy Consumption

Each day, a new smartphone is released. The growing number of these devices is serving the energy-hungry populations, becoming somewhat blind to the environment. The process of smartphone production and delivery to the end-consumer greatly impacts the CO₂ emissions. For instance, an iPhone requires several hours to be created and assembled and takes up to hundreds of thousands of miles, fuel, and energy to reach the user.

The case gets worse with mobile screens becoming larger. The bigger it gets, the more materials it needs, and the more energy it consumes. How does this account for environmental damage? Every activity done on the phone requires energy and storage. As much data is stored in the data centers, more resources are exploited and greater damage is done.

Ways To Implement Green, Sustainable UX

While we mentioned just two examples of how UX is hurting the environment, we shouldn’t leave behind the measures to scale down the emission pressure. Here are a few ways we can think of.

1. Measure Your Carbon Foot Print

There’s no point in creating something if you can’t measure it. And when you can’t measure it, it will become impossible for you to manage it. When creating a sustainable user experience, one needs to review the existing research on the on-going web emissions and energy consumption. The sole purpose must base on understanding how this information can be used to estimate and cut website pollution.

For this purpose, websitecarbon.com launched a free tool to measure the amount of CO₂ a website is emitting. Upon entering the website URL, the tool rolls out the information about how much CO₂your website is emitting, and if it is following a sustainable approach.

2. Make The Experience Accessible For All

Among the practices for a sustainable UX, usability comes as the first and foremost priority, which can be enhanced with factors like readability and navigation. If the content on the website is light, guides the user expertly, and helps them recognize value, the overall experience expands into an accessible dimension.

The website’s cleanliness also matters. Less clutter and speedy loading mean lower carbon emission. If the content is presented with great clarity and directions, it builds a connection between sustainability and user experience.

3. Optimize Performance

Sometimes, websites designed with a user-focused approach have performance issues that have adverse impacts on the user experience. By optimizing the site, you not only reduce data consumption and emissions but also engage the users with satisfaction.

So, what type of content needs optimization? Text, images, and videos make up your website’s content, and optimization of these means improving your website’s performance and data usage. By using clear, concise text, high-quality images and videos, your website cuts down on the page loading time without losing the overall quality.

4. Teach Sustainability Through Practice

Designing for a better environment receives returns when the users interact with the design. Users are generally unaware of how a clean and eco-friendly website looks like, while they might be concerned about the environment in the other way.

At this point, it’s your responsibility to drop hints about a sustainable design along with motivating them to achieve green goals in a better way. However, you need to address what you’re making it, how people will use it, and how it reflects your strategy to create a safer environment. Your intent should be evident in your message throughout your website.

Everything is as simple or complex as you want it to be

December 19, 2019 • Everything, simple

Everything is as simple or complex as you want it to be.

As creators, our role is to not only look at the top, face level of what it is we build (or what inspires us) but also the many different layers of complexity contained within the thing.

That is: when we perceive the world around us we can do so with as much or as little attention to—and consideration for—detail as we want. This intention in how we perceive things influences what we can do with the information we have available on us.

Simple concepts are more efficient for communication purposes, they’re easier to parse or break apart, and generally more likely to be what the general population thinks about. But simple things are also easily misunderstood and poor representations of the whole. Nothing is ever as simple as we first perceive them to be.

People, projects, devices with screens, the things we see on a screen, products we buy, apps we use, everything in the world around us are designed to be either immensely complex or plainly simple. How complex something appears to us depends mostly on how it’s presented, but also how we choose to look at it. The more you look into and think about something, the more complex it becomes.

At the most simplistic level things are singular: a problem is… well, a problem. A computer is a computer. These simple generalizations are helpful for us to understand the complexity of the thing and to communicate about it.

This is an over simplifications and yet it’s also how we tend to view projects in our careers. You have a problem and some concept of a solution to remedy it. Simple.

If you ask a child to explain how they did something, their response usually follows this framing; first there was this, then this. Two ends of the same line. This is also how we tend to choose to view strangers on the internet, products we don’t like, and politicians.

But if we really look at any of these things we start to see additional layers to it. The computer is made up of many complicated parts. The path to a project solution is rarely straight, it’s often much more complex. When it comes to design problems there are constraints—technological, financial, time, energy, and others—as well as additional considerations such as unforeseen situations or pre-existing concepts not previously considered, a competitive market, access to information and insights, and so on. You may even find that what you thought as being a straight-forward problem was jut one small piece of a larger issue.

Those outside the realm of design tend to see design as simple, but those within the space understand just how complex the work can be. This is true of all careers.

When we look at something closely it becomes evident that any one problem consists of many smaller problems. When we look closer, our perspective shifts to see things in slightly more complex lens. We begin to see that there is more than just a linear path to what it is we’re evaluating, there are tentacles to the complexity. We end up with something that looks more like this a tree, with roots branching out from a trunk. We can choose to look closely at the project now and see it for what it is: a mess of objectives, constraints, resources, and energy.

The problem of “how to build a computer” is made up of thousands of smaller problems: how to machine the case, how to wire circuitry and fit it into a small container, how to provide power and ensure the power source is reliable and can last for many years, how to layout keys onto the casing and the mechanics of the keys themselves. On and on the complexity goes, only ever as deep as what we’re willing to look at. There are problems with thermodynamics, machine physics, and the elasticity of the materials used in the thing.

What often makes the initial problem a problem to begin with is that it entails many smaller problems. In the absence of these complexities the problem wouldn’t be a problem because the solution would be straight-forward. Most things are not as simple as we anticipate them to be. People, projects, and products certainly fall into this category of being more complex than what we often see at-a-glance.

These smaller components—problems, constraints, and information—are connected in a way that influences the others as well. They’re less of a branching off a central problem and more akin to a web of complexity.

Looking at a problem in terms of many smaller problems is a good way to zoom into the complexity, but there’s more to the situation than looking closer at it! Not only do we need to zoom-in on all the smaller elements of something, we need to also zoom-out to see what additional problems are influence the one we’ve set out to solve. We end up in a space that looks something like a solar system of problems and solutions.

Where will the thing be used, in what environment? How often will it be used or abused? What are the constraints and resources available to the thing that will exist outside of it? What is the history of things like this? Suddenly what we thought of as being simple is far more elaborate, and far more reliant on things outside our initial consideration.

This is why whenever you’re stuck on a problem it’s easier to come up with a solution by stepping back from it—both literally and figuratively. Often the thing that has us stuck is just outside where we’re looking.

Problems and concepts are rarely linear lines to solutions, nor are problems ever siloed on their own. What’s more likely is that any given thing is itself a complexity to a larger ecosystem.

To really be a truly critical thinker is to consider the larger and smaller complexities of any given thing, and the interplay between them.

To be an effective product designer, engineer, product manager, data scientist, or any other function within the product development lifecycle, we must be capable of navigating the spectrum of complexity in the world around us. Doing so gives us insights into the things we build, and enable us to use the layers of complexity to our advantage. We can simplify concepts in order to communicate them with outside markets, or we can draw on the complexity of a concept in order to ensure the work we’re doing is going to be long-lasting or highly effective.

In standard design practices this process of looking in and out at the problem landscape is the very first step to creating solutions. It’s a divergence of perspective and thinking in order to ensure you aren’t overlooking critical information that could influence how you pursue solving the problem.

Before we can seriously attempt to solve a problem, we must first understand everything around it. The more time you have to consider the landscape, the better equipped you will be for solving the problem. As Don Norman wrote in his seminal book on modern design, The Design of Everyday Things:

“In design, the secret to success is to understand what the real problem is… complexity is essential, it is confusion that is undesirable.”

The world around us is only ever as simple or complex as we want it to be. We control this narrative by how long and how intently we look at something. Asking questions like: “What does this consist of? What is it made of? How do the parts work together?” as well as: “What is the larger ecosystem this is part of? What outward forces play a part in how this thing comes together?” add to our ability to perceive the complexities of something.

And when we understand the whole parts of something, we’re better equipped to change it. To add to it, modify it, remove it, or improve it.

In the absence of understanding the complexities we’re merely setup to talk about the thing. Sometimes communication is all we need, but if we’re to build or design something truly meaningful we need to look a bit closer than what’s on the surface—or in the message—of any thing.

Two Images and an API: Everything We Need for Recoloring Products

October 12, 2019 • Everything, images

I recently found a solution to dynamically update the color of any product image. So with just one of a product, we can colorize it in different ways to show different color options. We don’t even need any fancy SVG or CSS to get it done!

We’ll be using an image editor (e.g. Photoshop or Sketch) and the image transformation service imgix. (This isn’t a sponsored post and there is no affiliation here — it’s just a technique I want to share.)

See the Pen

Dynamic Car color by Der Dooley (@ddools)

on CodePen.

I work with a travel software company called CarTrawler on the engineering team, and I recently undertook a project a revamp our car images library that we use to display car rental search results. I wanted to take this opportunity to introduce dynamically colored cars.

We may sometimes load up to 200 different cars at the same time, so speed and performance are key requirements. We also have five different products throughout unique code bases, so avoiding over-engineering is vital to success.

I wanted to be able to dynamically change the color of each of these cars without needing additional front-end changes to the code.

Step 1: The Base Layer

I’m using car photos here, but this technique could be applied to any product. First we need a base layer. This is the default layer we would display without any color and it should look good on its own.

Step 2: The Paint Layer

Next we create a paint layer that is the same dimensions as the base layer, but only contains the areas where the colors should change dynamically.

A light color is key for the paint layer. Using white or a light shade of gray gives us a great advantage because we are ultimately “blending” this image with color. Anything darker or in a different hue would make it hard to mix this base color with other colors.

Step 3: Using the imgix API

This is where things get interesting. I’m going to leverage multiple parameters from the imgix API. Let’s apply a black to our paint layer.

We changed the color by applying a standard black hex value of #000000.

https://ddools.imgix.net/cars/paint.png?w=600&bri=-18&con=26&monochrome=000000

If you noticed the URL of the image above, you might be wondering: What the heck are all those parameters? The imgix API docs have a lot of great information, so no need to go into greater detail here. But I will explain the parameters I used.

w. The width I want the image to be
bri. Adjusts the brightness level
con. Adjusts the amount of contrast
monochrome. The dynamic hex color

Because we are going to stack our layers via imgix we will need to encode our paint layer. That means replacing some of the characters in the URL with encoded values — like we’d do if we were using inline SVG as a background image in CSS.

https://ddools.imgix.net/cars/paint.png?w=600&bri=-18&con=26&monochrome=000000

Step 4: Stack the Layers

Now we are going to use imgix’s watermark parameter to stack the paint layer on top of our base layer.

https://ddools.imgix.net/cars/base.png?w=600&mark-align=center,middle&mark=[PAINTLAYER]

Let’s look at the parameters being used:

w. This is the image width and it must be identical for both layers.
mark-align. This centers the paint layer on top of the base layer.
mark. This is where the encoded paint layer goes.

In the end, you will get a single URL that will look like something like this:

https://ddools.imgix.net/cars/base.png?w=600&mark-align=center,middle&mark=https://ddools.imgix.net/cars/paint.png?w=600&bri=-18&con=26&monochrome=000000

That gives the car in black:

Now that we have one URL, we can basically swap out the black hex value with any other colors we want. Let’s try blue!

Or green!

Why not red?

That’s it! There are certainly other ways to accomplish the same thing, but this seems so straightforward that it’s worth sharing. There was no need code a bunch of additional functionality. No complex libraries to manage or wrangle. All we need is a couple of images that an online tool will stack and blend for us. Seems like a pretty reasonable solution!

Everything About Style Guides, Design Systems, and Component Libraries

August 18, 2019 • About, Everything

August 7, 2019

For the better part of the last year, I’ve been investing heavily in front-end development and design.
When I started my new role at Hy-Vee, I identified a need for a component library and created it.
Since then, I’ve learned a lot about style guides, design systems, component libraries, and their best practices. This post will be a deep-dive on everything I’ve learned in the past year.

Why Should You Care?
What Is a Style Guide?
What Is a Component Library?
What Is a Design System?
Where Should You Begin?
Building the Design System
Conclusion
Resources

Why Should You Care?

Every website starts simple. There’s maybe one page with a few distinct pieces. It has modest intentions.

Then, slowly, it begins to scale.

More pages are added and new features are built. There might even be multiple teams devoted to specific sections of the site. You could be developing for mobile, too.

You start to notice the buttons in one part of the site are slightly different than everywhere else. One team decides to build a feature that another team has (unknowingly) already completed. Communication breakdowns happen. Consistency is lost.

Is this a preventable problem? Absolutely. Yet, why does it happen over and over again? Unless you think about your design and development process upfront, you will run into issues later as you scale.

To prevent this issue from happening, or to fix the existing lack of consistency in your products, you need three things:

Style Guide
Component Library
Design System

Don’t worry if you have no idea what I’m talking about yet. By the end of this article, you’ll have consumed almost a year’s worth of trial & error, research, and development.

What Is a Style Guide?

A style guide is a set of rules for how your brand should be displayed. This is both visual (design & imagery) as well as written content (voice & tone).

The purpose of a style guide is to allow multiple contributors to create content clearly that cohesively represents the brand. Almost every major brand has a style guide, though not all are public.

What Is a Component Library?

A component library is living, breathing implementation of your style guide. It’s a shared set of UI components that developers can consume to build applications reflecting your brand. Some notable benefits:

Having a component library means less custom code for consumers.
Since there’s a central location, you can ensure all components meet accessibility requirements.
Components become more robust with multiple contributors submitting bug fixes and improvements in a single place.
Less duplication of code allows you to ship new products and rewrite legacy code faster.

What Is a Design System?

A design system is a complete set of standards, documentation, and principles along with the components to achieve those standards. It is the marriage between your style guide and component library. One of the most popular design systems is Google’s Material Design.

A design system should contain:

Content — The language to design a more thoughtful product experience.
Design — The visual elements of the design system.
Components — The building blocks for developing new products and features.
Patterns — The individual pieces for creating meaningful product experiences.

Where Should You Begin?

Depending on the state of your company/product, you might have a different starting point. This is the outline before we dive into specifics.

Create an inventory of existing design patterns.
Establish design principles and begin a style guide.
Define your design tokens.
Create or identify an icon set.
Choose languages/frameworks supported.
Evaluate Monorepo vs. single package.
Evaluate CSS/Sass vs. CSS-in-JS.
Create a component library.
Choose a documentation platform.
Write design system documentation.

Building the Design System

Create an Inventory of Existing Design Patterns.

Unless you are starting from scratch, you will need to identify all the design patterns currently in use in your interface and document any inconsistencies.
The goal should be the same user experience regardless of which part of the product the user is in.

Start documenting and reviewing these amongst your team and identifying your preferred interaction patterns.
This should start to paint a picture of which pieces your style guide will need.

Establish Design Principles and Begin a Style Guide.

It’s time to translate these findings into the beginnings of a style guide. You can use tools like:

My recommendation would be Sketch, but it’s ultimately up to your team and company. Make sure you understand best practices around Sketch symbols and when to use nesting.

Define Your Design Tokens.

Design tokens are the visual design atoms of the design system — specifically, they are named entities that store visual design attributes. We use them in place of hard-coded values (such as hex values for color or pixel values for spacing) in order to maintain a scalable and consistent visual system for UI development.

This includes things like:

Colors (text, backgrounds, borders)
Fonts
Typography sizes
Spacing values
Shadows

For example, let’s take a look at Geist – Zeit’s Design System.

--geist-foreground: #000;
--geist-background: #fff;
--accents-1: #fafafa;
--accents-2: #eaeaea;
--accents-3: #999999;
--accents-4: #888888;
--accents-5: #666666;
--accents-6: #444444;
--accents-7: #333333;
--accents-8: #111111;
--geist-success: #0070f3;
--geist-error: #ee0000;
--geist-warning: #f5a623;
--dropdown-box-shadow: 0 4px 4px 0 rgba(0, 0, 0, 0.02);
--dropdown-triangle-stroke: #fff;
--scroller-start: var(--geist-background);
--scroller-end: rgba(255, 255, 255, 0);
--shadow-small: 0 5px 10px rgba(0, 0, 0, 0.12);
--shadow-medium: 0 8px 30px rgba(0, 0, 0, 0.12);
--shadow-large: 0 30px 60px rgba(0, 0, 0, 0.12);
--portal-opacity: 0.25;

There is now a shared language between designers and developers.

Create or Identify an Icon Set.

If you already have existing icons, you’ll need to determine which to keep. It might not make sense to create your own icons depending on the size and priorities of your company. You might be better off utilizing an open-source icon library. Here are some examples:

Regardless if you build your own or use open source, you should standardize on usage and identify consumption patterns. It’s also worth considering who are the end-users of your icons set – designers, developers, and marketing?

Using SVGs, you can make the icon library your single source of truth. Your process might look like this:

Designers create/provide raw SVGs.
Optimize and compress the SVGs using SVGO.
Automatically create React components using SVGR for developers.
Output PNGs and JPEGs at different sizes/resolutions for marketing.
Compile SVGs into a bundled font for mobile applications to use.

Choose Languages/Frameworks Supported.

What languages or frameworks are you currently supporting? Which should the component library support?
It’s important to think about this ahead of time so you can properly architecture your library.

If you have an application which uses script tags instead of ES Modules, then you’ll need to
configure your component library to bundle into a single distributable file. For example,
a vanilla JavaScript application would need something like this in an HTML file.

<script src="/js/component-library.min.js">script>

To achieve this, you can use either Webpack or Rollup.
I would recommend Webpack, as it’s the industry standard.

Evaluate Monorepo Vs. Single Package.

A Monorepo allows you to build and publish multiple libraries from a single repo. While it does solve some very real problems, it also creates others. It’s important to understand the pros and cons.

Pros

✅ Small bundle sizes by decreasing the scope of components included in one package.
✅ Shared built, lint, test, and release process for multiple packages versus separate repositories with duplicated code.
✅ More granular control of semver on a package-by-package basis.

Cons

⛔️ Additional tooling and infrastructure needed.
⛔️ Consumers are required to import from a variety of packages instead of one single component library.
⛔️ Cutting edge technology. There is industry adoption, but you can run into issues very few have experienced without a clear path for a solution.

Some questions that will help you identify which solution is right for your company.

Do you currently have multiple repositories all publishing to NPM?
Is your build, test, lint infrastructure complex? Is it duplicated in many places?
How many repositories do you have (or plan to have in the next year?)
How large is your team? How many people will be consuming the component library?
Will it be open-source? Can you lean on others in the industry to help solve problems?
Do you see the need for multiple packages in the future? (e.g. icons, codemods, etc)

For most smaller companies, I would argue that a Monorepo is unnecessary. It has its time and place. We use it at Hy-Vee (~150 developers) to distribute 10 different packages at once, spanning both internal and external apps.

Note: Want to use a Monorepo? Check out Creating a Monorepo with Lerna & Yarn Workspaces.

Evaluate CSS/Sass Vs. CSS-In-JS.

I’ve come to prefer CSS-in-JS, especially styled-components. There’s a variety of different CSS-in-JS options outlined here. The major selling points for styled-components for our component library were:

Feels like writing traditional CSS vs. JavaScript objects
React & React Native support
Auto-prefixing vendor styles
Scoped styles which eliminate global CSS conflicts

If your component library needs to support outputting raw HTML/CSS as an option, I would recommend sticking with Sass. A great example of this is IBM’s Carbon Design System.

<button class="bx--btn bx--btn--primary" type="button">
    Button
button>

Regardless of the technology you choose, I would recommend using CSS variables to contain your design tokens.

Create a Component Library.

With your technical requirements defined and your style guide started, you should now be able
to begin constructing a component library. My recommendation would be to use React alongside Storybook.

Creating a component library is much more than just translating the style guide into code.

You’ll need to think about how consumers will interact with your components.
What sort of API would they expect? What provides the most clarity and is self-documenting?
For example, consider buttons. You have different variations of buttons – primary, secondary, etc.

Should you have separate components for each?

<PrimaryButton>Hello World!PrimaryButton>
<SecondaryButton>Hello World!SecondaryButton>

or should you use a prop?

<Button>Hello World!Button>
<Button variant="secondary">Hello World!Button>

Secondarily, what should the prop be called? variant? type? Did you consider that type is a reserved attribute for the HTML

Everything you?ve ever wanted to know about Lyft?s design system

August 15, 2019 • Everything, wanted

There are a lot of great design systems out there. And these days, it seems that every organization publishes their design system publicly. And that’s great for transparency and inspiration. But it’s not a good idea to just use their template for your own organization.

“A design system isn’t like a code of ethics. It’s more like a set of company values. It’s good for everyone to share the same ethics. But it’s not necessarily appropriate for every company to share the same values,” says UX Interaction designer Alex MacDuff.

The bottom line is that trying to Frankenstein everything together from other places will leave you with something less desirable: an ineffective (but very organized!) design system.

Trying to Frankenstein everything together from other places will leave you with something less desirable: an ineffective (but very organized!) design system.

Building a design system is kind of like being a personal trainer. A trainer tailors workout and nutrition plans to a person’s goals, lifestyle, experience, body type, and budget. In the same vein, you need to consider every team’s unique needs and feature sets and build a design system around those distinct demands.

It didn’t take us long to notice that Lyft’s design system team was doing something right. Linzi Berry, Product Design Systems Manager at Lyft, has been instrumental in thinking through the problems that face folks using a phone in real-life situations. Customers aren’t just sitting in a perfectly lit room. The majority of the time, Lyft customers are on a busy street and drivers are looking at tiny phones from 2-3 feet away.

We chatted with her about her approach to building Lyft’s design system, core principles and learnings, and how her team communicates the design system out to the broader team.

Why did Lyft decide to build a design system from scratch rather than use something off-the-shelf (Material, Bootstrap, HIG)?

We are building off of and elaborating on Material Design and the HIG for core components within our custom system. We use those systems as a starting point because they’re backed by research. And they’ve created expected usability paradigms with users. So when we think about building a sheet, we first consider how a user expects to interact with an Action Sheet on iOS and a Bottom Sheet on Android, then solve it to meet our users’ needs, achieve parity across systems, and match our visual design style.

We also need elements that don’t exist in either system — especially when it comes to the map, which is a large portion of our app.

Does your design system have rules or principles that you follow? How did you arrive at your rules or principles? Who had a part in crafting them?

Of course!

Our goals, defined by the design system team’s designers and engineers, were created as solutions to the problems our company was facing internally and externally:

We aim to deliver consistency and predictability to our products.

Multiple designers solve the same problem, unbeknownst to each other. Others see those solutions, adopt, and adjust them to their needs. This further results in a disjointed experience for the user. The same button may do different things or the different buttons may do the same thing.
We aim to reduce design and engineering time and debt.

Copy and pasted code means everything is a one-off, which takes time to create. Not to mention if we want to update the style of a button, we need to hunt for every use and adjust it.
Today we aim to raise the quality of our experiences for every person and every edge case.

In the past we didn’t put a strong focus on accessibility, localization, and solutions for every state or edge case a component might encounter.
We aim to create a universal design system that works best for Lyft on all platforms.

Due to fast timelines, our designers usually only hand off iOS designs. Our Android developers look at those designs and make assumptions for how to solve it in Android. Sometimes the standard solution in the HIG or Material Design does not work best for us.

Additionally, our executive leadership team defined Quality Principles that applied to every department throughout Lyft. Our systems team turned those more holistic guidelines into a tangible checklist for components.

How do the needs of your users differ from other companies?

We have two types of users:

The riders and drivers who use our apps
The designers and engineers who use our system

Our riders and drivers use our app differently in two common scenarios:

“Focus” state, which is most commonly referred to when someone has the Lyft app open on their mobile device. The “focus” state requires us to meet guidelines presented in the HIG and Material Design, essentially designing for an experience 12” from the user’s eyes. That means 48×48 tap targets and type size above 15pt for legibility.
“Drive” state is more unique to Lyft. While our Rider app currently only exists within the “focus” modality, our Driver app uses both “focus” and “drive,” depending on what the driver is trying to do. This state required us to expand the guidelines presented in the HIG and Material Design to work for an experience 20” from the user’s eyes. That means 64×64 tap targets and type size above 24pt for legibility.

In order to best meet our users’ needs, we really have to focus on educating designers and engineers on what modality to use and when, and provide clear guidelines on component usage that may change between modalities for safety and accessibility.

How do you communicate your design system to your team? What did you think might work, but didn’t?

Systems design is not only scientific and meticulous, it’s the mastery of interacting with people in a sensitive and effective way. It takes human connection and empathy to go from a sticker sheet to a living, thriving system.

The time we invest in relationships with designers and engineers (and their bosses, their bosses’ boss, their project managers, and the accessibility guru down the hall) is as important as building the system itself.

Systems design is not only scientific and meticulous, it’s the mastery of interacting with people in a sensitive and effective way.

Linzi BerryLyft Product Design Systems Manager

In order to communicate our system in an effective way, we…

Empathize with teams and their users. Have meetings with teams to drive home the benefits a system provides and, arguably more importantly, how much we truly care about them and their users’ needs.
Reassure stability. Piecemeal updates and additions can be overwhelming and make the system feel unstable. A consistent, batched workflow and announcement process sets expectations and documents why we did what we did.
Educate, don’t enforce. We see ourselves as teachers, not the police.
Be flexible. By approaching our system as a living document, it remains flexible enough to be open to new ideas, challenge what we’ve created, and pull in new paradigms as they are proven successful.
Share ownership. Designers and engineers desire ownership of their work. But that can be difficult when you’re using a system you didn’t create. By creating clear pathways for all stakeholders to get involved, we can share ownership.

In my experience, the hardest thing for any team when it comes to communicating a design system is constructing clear and consistent communication avenues.

Depending on your department, you may use Facebook Workplace, Slack, JIRA, Google docs, email, etc. and your interpretation of effective communication can drastically change depending on what your team uses. I recommend considering your teammates’ communication habits and routines, and sharing updates wherever most people already spend their time.

Ultimately, we ended up sticking with a bi-weekly email with highlights because we came to understand it was the one place everyone looked.

Thanks so much, Linzi, for sharing your insights with us!