Name: 先進設計システムの考察 - アレックス・セクストン｜JSConf Hawaii 2020 (Advanced Design System Considerations - Alex Sexton | JSConf Hawaii 2020)
Uploaded: 2021-01-14T10:25:15.000Z
Duration: 27 min 12 s
Description: VoiceTubeの動画で発音を聞きながら英語表現を覚えよう！学べる英語：

様態の副詞

uh, I'm here to talk today about I actually regret name of my talk, little bit advanced design systems considerations, mostly because it's a mouthful.

But also, I mean, advanced less like, uh, advanced math and more like advanced osteoarthritis or something, right?

I want to talk about what the work is once you convince everyone at your company to use your design system.

And once you're done building out all the name brand components s o, I work, it's stripe on our design system.

Team were two designers to engineers and a manager for a total of five people.

That stripe is over 2000 employees now, so that's a heck of a ratio of 1 to 5.

For design systems, their leverage dedicated team of four individual contributors can abstract and maintain the design language and technical implementation for a component library for 2000 people.

It's I think, uh, I think it does a good job.

It's not magic, despite, uh, my most sincere efforts.

That was a great talk, by the way, uh, we think we create more value than we remove.

And I think my coworkers and teammates on this team are some of the most thoughtful and capable people to be working on this problem in existence.

Uh, so we've done nifty work on accessible color systems, applying a lot of magic, uh, choosing one and we made building consistent strike looking interface is a little bit easier, and we have some or another version of just about every component that you can think of often to our detriment.

You don't look much further than an old NASA graphic standard manual from the sixties and seventies to find cool, cool design systems.

But there are very new challenges, especially technical ones that compound on the old challenges.

Robin Randall recently wrote an essay that compared design systems to the idea of hyper object, and that idea resonated with my team very strongly on me.

He's referencing a book by James Bridal called The New Dark Age.

It says, Ah, hyper object is gonna read to you a thing that surrounds us envelopes and entangles us that is literally too big to see in its entirety.

Mostly, we perceive hyper objects through their influence on other things.

See the buffeting of a transatlantic flight.

Hyper objects happen everywhere at once, but we can only experience them in the local environment.

Fact that stand outside both our perception and our measurement.

They exist without us because they're so close and yet so hard to see that fire ability to describe them rationally and to master overcome them.

Traditional sense climate change is a hyper object, but so is nuclear radiation evolution on the Internet.

They do often feel like sneakily complex systems, like no single person can hold the whole thing in their head anymore.

It's like trying to figure out what shape the crop circle is from inside the cornfield.

You can spend an incredible amount of time softly tackling an issue, only to zoom out, zoom out again, just to see that you're working in a tiny subsection of a tiny subsection of your design system.

And that idea really sums up a lot of the work that's involved in the second and third waves there need to be put into a design system.

It's all about trying to make the entire thing useful, while all also making any arbitrary subset.

Equally useful, did not require each person each user of the system toe hold the entire thing in their heads.

There's, of course, lots of information that exists on how to create a design system, their books and tutorials and had a jump pass a lot of the difficult pain points.

That's not my focus here, but I certainly would be lost without all that prior art, so I'd be happy to recommend some of that.

If you want a chat later, you first get started on design system.

You have some fundamentally different and often opposite goals is when you're trying to level up on existing design system.

When you first get started, I want to make lots of new components.

You want to maximize the number of designs that are possible with your system.

You work on selling people to use it versus rolling their own components are doing one off designs and you actively seek real estate in your applications to see what you can replace with a cleaner design system.

You want people to be excited about using your design system.

Your goals are to start your goals start shifting pretty quickly.

You worry more about keeping the system healthy and alive, not about selling its value directly.

You fight to make sure you don't become too dated, but for the most part, it a stage where your goals to blend into the platform.

One of my favorite 2019 goals on my team that stripe was that another team would announce a conversion of their application to our design system without thanking us at the end of the email.

Our goal was to become part of the expected platform rather than an exciting tool that people have to think a lot about.

It happened is both frustrating and very exciting.

Um, another surprising change in the second phase, uh, that were you once judge yourself on how many components you added in 1/4 you start valuing the opposite, whether it's crafty, old components that never did the right thing anyway Oh, are super specific components that could probably be achieved by customizing generic ones.

You quickly appreciate the things that reduce the system complexity.

The same is poor, though it's provide a system that it used to your values.

So the resulting you guys here to your values Really common design system thing I see sometimes even attached toe goals for your business metrics or something is the desire to add components in perpetuity.

First is the idea that the more components you make, the faster it will make developers and the more useful the library will be.

I think this assumption comes from a good place, but I've never seen it play out in practice.

Very solid core of atomic components could be well understood and composed and recomposed by your users and unlimited permutations.

You build them well, you won't have to fit new ideas into old components.

Faulty assumption is that having a component that does something close to what you want makes you faster.

But when I think back to the most frustrating waste of time in my career, it's almost always in trying to configure some mega component to do one thing that it wasn't quite designed to do.

So fight for atomic components doesn't mean your applications shouldn't make their own logic list complex, non non atomic components that they share between theat.

But it just means that those components probably shouldn't live in your design system.

The other reason I see engineers continuously add components is that they actually have a secret desire to rewrite the things that they don't own at the company.

I know this sounds like a conspiracy theory, uh, and I'm sorry for that, but I'm gonna keep going.

Uh, it does follow a pretty natural evolution.

First you fix all the buttons and then you fix all the menus and tabs and chords, and eventually you're out of, ah kind of the atomic seeming components.

And so instead of stopping, you find yourself searching for any patterns that are used more than one time to turn into components.

Here's a person card and a detailed person card.

We could kind of smash those together and and retake that land.

Suddenly, they're pretty business specific and pretty application Pacific, Uh, and then you want the pricing page toe look nicer, but it's so entrenched in the old stack that no one will touch it.

So eventually throw off all pretenses of component re use, and you build the pricing banner component throat in the design system and then replace it so you don't have to look at it anymore.

The 37 has these urges, but I'd recommend you work these things out or get organizationally rather than declaring manifest destiny on other teams.

You like your design system, or, in the end, I want to dig back into The first point I brought up there, though, is this common perception of design systems that they're intended to increase efficiency?

I don't think this is entirely wrong, but I think efficiency is a secondary goal of a design system.

The primary goal of a design system, in my opinion, is to uphold your values design systems air so you can ensure that when a developer is making tradeoffs to ship something before looming deadline, that that thing falls off the chopping block, that the thing that falls out the chopping block isn't accessibility performance or visual consistency or all attention to detail design systems air tools to uphold the quality of your product, even in the face of consuming teams that aren't paying particular attention to quality design systems.

Successful when someone can throw together a quick, a quick application and why, while that application may fail to achieve the specific business schools, it's still upholds the values that are otherwise left behind in crunch time.

Whatever else you've decided, it's important to you.

One of my first actionable recommendations is to fight against the wrong contextual specificity and components.

It's very common to end up with a lot of similar components that often do almost the same thing on maybe even describe, the context that they're used in icon, but a Nikon action Icon menu icon are seemingly icons.

Ah, it's also common to recognize this complexity and then move everything over into a single component on and you end up with kind of like an explosion of props that all do something very specific on Lee.

For one use case, you can't always avoid one of these traps, but we want to move in a direction that tries to allow the context dictate the difference is not a bunch of problems s so let's see if we can contextually create a button icon, which is the one at the top there, without actually needing a component like that.

In this example from the stripe dashboard, we have two icon types visible, uh, one icon inside the button and one outside.

字幕リスト動画再生

先進設計システムの考察 - アレックス・セクストン｜JSConf Hawaii 2020 (Advanced Design System Considerations - Alex Sexton | JSConf Hawaii 2020)

specific

entire

perception

approach