November 10, 2023

Inside Out, or Outside In?

The Question: Episode 2 Wrap-up

On Thursday, November 9 of 2023 we held the Episode 2 design system deep dive conversation as part of a series called The Question. Thanks for being part of it.

Review the FigJam file and the raw data from the Episode 2 deep dive.

For this week’s question, I provided this context:

This week we’re talking about how to get started with a design system. For the sake of this exercise, I want you to assume you actually need a system (a conversation we’ll save for another time).

The scenario is this: you are tasked with getting a design system started for your organization and you are planning out the first bit of work. There is no existing system. You have buy-in from leadership in the form of six months of funding for a team of two to three people. The reasons your leadership have agreed to this are twofold: to create a more consistent suite of products and to improve the efficiency of the product teams. After six months you’ll need to make your case that the effort was a good investment for the organization.

There are a lot of opinions out there about the first few things to prioritize. I’d like to suggest there are a two very general, high-level approaches:

Approach 1: Inside Out

Teams who take an Inside Out approach tend to focus on foundational pieces first (design principles, colors, type, etc) and then move out toward components and patterns.

Approach 2: Outside In

Teams who take an Outside In approach tend to focus on the larger experiences and patterns first (sign up flow, checkout, etc) and then work your way down to the more foundational pieces.

I’m asking you to take a side, mostly for the sake of the conversation. :) Here’s your question:

Which approach would you take to get your design system off the ground?

I’ll say this here—there are a LOT of ways to start a design system. I’m not suggesting these are the only two. This question was designed to get us thinking and force us to take a side. As you’ll see below, there’s a lot of nuance here. That’s the good stuff, and it’s where I wanted us to go!

With 141 people signed up to receive this question, we received 53 responses!

What we learned

In response to the question, 'Which approach would you take to get your design system off the ground?': 67.9% responded Inside Out, 22.6% responded Outside In, and 9.4% responded Other.

The responses were somewhat varied, but the major winner was the Inside Out approach—beginning with foundations and then working your way up to larger patterns. It’s also important to note that people were VERY opinionated about this one. :) Here are some of the comments from those who chose the Inside Out approach:

“Baking the brand and internal style into the components as an afterthought requires a lot of extra work later vs starting with those at a foundational level.”

“Colors, fonts, logos, buttons audit. Show the chaos. Get people FEELING like there is a need. The audit can be done in 1 week, a roadshow in the next, and then a Steering Committee (or leadership-type) alignment to ensure they know we are going to start pulling teams together. And try to get 1 simple change on everyone’s backlogs. This demonstrates VELOCITY.”

“Great designers can see past the artifacts, of course, but if your process only works for great designers, then it’s not a very good process.”

“The foundational bits are a force multiplier. It’s worth the investment to nail them before we do anything else. Otherwise it’s akin to building a house on quicksand.”

On the Outside In approach, people had a lot to say as well:

“Obviously in real life, we vacillate between looking inward and outward. But at the end of the day, the tail shouldn’t wag the dog.”

“I can imagine that if there is already a well worked out set of non-system components/design language and some repeated patterns, then the archaeological post-rationalization approach can be much quicker and more effective.”

“We can help ship the ‘sign on flow’ and give users a couple button styles WELL before we have clear primary/secondary/gray scale color palettes. Before we have every typographic style nailed down and each sub-style abstracted to a semantic token.”

“The easiest way to drive adoption is to meet people where they are.”

“Design Systems have gotten to the point that we ‘know’ what ‘must’ go into a system… which leads to over-built systems with components that aren’t often used. A more iterative approach to building only what teams actually need and will use means less maintenance down the road.”

And, though their numbers were small, the people who chose Other had strong opinions too:

“You need patterns to build foundations, and you need foundations to build patterns (that scale).”

“I think foundations and components are a little bit like chicken vs egg; you can’t establish scalable semantic tokens without knowing what your system is going to look like, and you risk a lot of rework if you create components without scalable foundations.”

“I would say that a design system can’t be done using only one approach. We polish our design system using a loop of both.”

“Depends on what areas of the business need impacted first. If the company wants demonstrable visual consistency, start with foundations. If the company wants cohesive experiences, start with patterns. Usually it’s a mix.”

The Why

Most of our participants also offered the reasoning behind their answer. I identified a few patterns in those responses and captured them on four quadrants. This highlights the advantages and the risks of the two approaches.

A plot of the advantages and risks of the inside out and outside in approach.

For the most part, the advantages of the Inside Out approach were the strong foundation it offers upon which components and patterns can be built. There was also a general idea that offering more foundational assets to subscribers of the system allows for some alignment in the interfaces of the products, although we acknowledged that a deeper cohesion across products and brands requires higher level components and patterns.

The risks for those Inside Out folks were:

• It’s too rigid when it comes time to focus on the holistic patterns.
• This approach quickly leads to scope creep.
• It’s hard to prove value one component at a time.
• It’s irresponsible to define a type scale without considering how it would present in a hero banner.

The last point was one everyone seemed to agree on. Which lead us to the idea that perhaps a good approach would be to: “Sell Outside In while building Inside Out.” (Thanks to Jeremy Elder for the succinct statement!) This also aligned with the advantages of the Outside In approach which covered ideas like more quickly satisfying leadership, easier to tie to OKRs, and making prioritization of the work easier.

The risks for those Outside In folks were:

• If you don’t get the foundations right, the system won’t scale.
• It’s hard to get time to go back and work on foundations once components are released.
• Creates tech debt before really getting started.
• More work to incorporate foundations AFTER building components

Spiraling

I’ve always imagined design systems as layers of complexity, fed by the brand, and used to build digital touch points that connect that brand to the desired audience. This is true, in a practical sense. But the conversation today helped me realize that the brand is actually informed by the way those customers experience it—this isn’t a one-way street. I don’t think the process we use to build systems should be either.

In Conclusion

It was a lively discussion! Near the end I gave folks a chance to change their minds, but everyone was pretty decided. While most people did stick to their original choice, I do think we all agreed that both perspectives are necessary. Maybe that’s the lesson in an exercise like this—remember that there are many ways to approach this work and take the time to understand the assumptions others are making. It’s much easier to address those different opinions early in the process than later, after expectations have been missed.

Additional resources

• Your Next Component (by Dan Mall)
• Starting a Design System (by Nathan Curtis)
• Start with the business (By Erika Hall)

Thank you

Many thanks to all who participated.

If you missed out this week, sign up for The Question and be ready to answer this coming Monday.

Writing Design Systems The Question