A Designer and Developer Walk into a Bar…
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 17 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/63234 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
EmberConf 20232 / 17
13
14
00:00
RhombusComputer animationMeeting/Interview
00:33
Color managementSoftware frameworkProduct (business)Physical systemLevel (video gaming)Meeting/Interview
01:33
Physical systemBuildingBlock (periodic table)Source codeInstallation artPhysical systemComputer-assisted translationCodeDigital photographyCohesion (computer science)Computer animationLecture/Conference
03:16
Physical systemProduct (business)Software developerComplex analysisFormal languageVisualization (computer graphics)Representation (politics)Parity (mathematics)AreaMereologyIntegrated development environmentShared memoryUniqueness quantificationPoint cloudDivergenceOperator (mathematics)Power (physics)User interfaceConsistencyFocus (optics)Perturbation theoryTime zoneSoftware frameworkRight angleScaling (geometry)Level (video gaming)Arithmetic meanCharacteristic polynomialBuildingSelf-organizationContext awarenessExtension (kinesiology)TelecommunicationEnterprise architectureCodeVapor barrierGame theoryComputer animationPanel paintingDiagramLecture/Conference
07:41
Enterprise architectureSoftware frameworkPhysical systemTelecommunicationCloud computingProduct (business)Form (programming)BitDifferent (Kate Ryan album)Line (geometry)AreaExistenceShared memoryExpected valuePower (physics)Mobile appDivergenceVariety (linguistics)Strategy gameCartesian coordinate systemComputing platformComputer animation
10:34
Component-based software engineeringMobile appProduct (business)Library (computing)ChainPhysical systemData managementCodeComputer animation
11:09
Software developerWorld Wide Web ConsortiumIntegrated development environmentDifferent (Kate Ryan album)BitDivergenceWeb pageSoftware developerProduct (business)Component-based software engineeringPhysical systemImplementationINTEGRALComputer-assisted translationWordGroup actionWeb browserBranch (computer science)Zoom lensData structureCodeIndependence (probability theory)Covering spaceRevision controlComputer fileField (computer science)Library (computing)Context awarenessComputer animation
17:03
Complex (psychology)Physical systemProcess (computing)Scaling (geometry)CASE <Informatik>KreisprozessLevel (video gaming)Component-based software engineeringRight angleGroup actionEvoluteEnterprise architectureStrategy gameSoftware developerData structureResultantProduct (business)MereologyReading (process)Multiplication signSoftware testingFormal languageFeedbackPlanningExpected valueProjective planeDependent and independent variablesCodeSpacetimeWeb pageComputer fileBitImplementationRoundness (object)Computer animation
23:19
Sigma-algebraCodeFeedbackINTEGRALContext awarenessProduct (business)Software testingStreaming mediaTouch typingWebsiteComputer fileLattice (order)ConsistencyPoint (geometry)Formal languageVideo gameMereologyProduct (business)Process (computing)CodePhysical systemSurfaceLine (geometry)Multiplication signNatural numberComponent-based software engineeringEqualiser (mathematics)Software repositoryCore dumpSynchronizationImplementationPivot elementMathematicsToken ringDifferent (Kate Ryan album)Software developerVariable (mathematics)Web 2.0FeedbackCurveVariety (linguistics)Computer animation
29:35
SynchronizationDemo (music)PlanningLattice (order)Multiplication signStorage area networkComputer fontBitComputer animation
30:31
Computer iconElement (mathematics)Attribute grammarCodeFeedbackContext awarenessModel theoryComponent-based software engineeringFocus (optics)Modal logicUsabilityCore dumpProduct (business)EmailSelf-organizationWeb pageLevel (video gaming)Conformal mapLimit (category theory)Component-based software engineeringBounded variationElement (mathematics)Mobile appPhysical systemWeb pageModal logicDefault (computer science)Multiplication signRule of inferenceBitLine (geometry)InformationComputer animation
34:05
TrailMeasurementExpected valueRevision controlCausalityMultiplication signComponent-based software engineeringAdditionTouch typingPhysical systemPoint (geometry)TelecommunicationDigital photographyFlow separationProcess (computing)Library (computing)Product (business)VelocityCodeComputer animation
38:10
Free variables and bound variablesLink (knot theory)System programmingPhysical systemRevision controlPhysical systemSlide ruleMassMultiplication signCommitment schemeComputer animation
39:01
Physical systemPattern languageInstance (computer science)CodeProduct (business)Component-based software engineeringToken ringSoftware developerComputer animation
39:39
World Wide Web ConsortiumComponent-based software engineeringCASE <Informatik>Limit (category theory)Physical systemMultiplication signCodeComputer animation
40:21
Computer animation
Transcript: English(auto-generated)
00:00
Okay, so fun fact, we wrote this talk title and thought it was funny, and then we're
00:25
like, oh crap, we have to write the talk. Yeah, so let's see how it goes. Y'all know me, I'm working right now, I work for HashiCorp as an engineer on our
00:41
design systems team, and you have been hearing about me ad nauseam, so I'm going to introduce you to my lovely designer colleague, Jory. Hey folks, you probably don't know me at all, because I'm a product designer, I'm way out of my element here. My name is Jory Tindall, and I'm also a product designer with Melanie on our HashiCorp design
01:07
system team. Yes, but you do more than that, so tell us about your music. Well, yeah, I'm also a saxophonist, I'm from Seattle, so if you're ever up in the Pacific Northwest, you know, check me out, I've shared the stage with the Temptations,
01:25
Johnny Mathis, the OJ's, folks like that, it's pretty sick. So yes, we both work on this really pretty design system that we call Helios, no we did
01:40
not get to pick the name, I know, it's really pretty, you can visit the design system documentation, but not right now, listen to our talk first. So let's first talk about what you can expect this talk to include, because that helps you keep in mind when the end's going to be, and you're paying attention to that, because
02:02
we're the last talk today. So first we're going to talk about what design systems are themselves, kind of give a brief introduction. We're all used to UI add-ons, shared components, brand guidelines, but a design system isn't really any of those in isolation, rather it's all of those things and more in a cohesive
02:26
kind of system of systems. And next we'll talk about a few challenges, and I say a few because there's a lot of challenges and we singled a few of them out. A few challenges that we faced while starting our design system team, while starting a new
02:43
design system, we'll get into that, and I'll give you a hint, it was less about code and it was more about people. Next we're going to talk about how we decided to approach some of these challenges and some of the things that we did that we think are pretty cool to kind of solve them in our cross-functional
03:02
team. And finally we'll go over some lessons that we learned, are learning, will learn, and how they can help anybody that is working on a design system. Okay, before we start, here's some photos of our cats. The one that's yelling is Atlas, is mine.
03:24
And the one who is being woken up so abruptly is Avery. Okay, design systems, let's talk about that. So we all probably know what a design system is from a technical perspective, but from
03:42
a value perspective, a design system really helps product teams ship UI at scale. That's kind of our main goal. So what does this mean in the context of design systems at HashiCorp? Well, we're focused on Ember and we love that. All the niceties that Ember gives us when we're building a design system for developers
04:02
and for our consumers. We support a extremely wide array of products that are both on-prem products, they're enterprise level products, and cloud products, and they all kind of have divergent product lines, but benefit from a shared UI.
04:23
We also support multiple sub-brands underneath the HashiCorp brand, Terraform, Console, Boundary, etc., underneath the unified HashiCorp brand umbrella. And finally, HashiCorp products are complex. We're in the developer operations space, which is a pretty tough discipline.
04:40
The UIs are complex, they're data heavy, and they're often geared towards power users. So our consistent visual language and parity between design and code really benefits the consumers and helps them to move faster. So here's an abstract representation of all of the moving parts of a design system.
05:05
This is kind of captured in a concept called the system of systems, in which each focus area of the design system is treated as its own system in isolation, but is part of a larger system of systems, so that all of these systems operate in the cohesive environment.
05:28
So what makes a design system successful? I think the problems that a design system faces are kind of unique and kind of multifaceted and kind of span across the whole company.
05:42
But generally, I think a successful design system shares some common characteristics. There's parity between design and code, there's a similar or shared framework that they use, really great, really comprehensive documentation, and even then you can't really get people
06:01
to read it, p.s. Organic buy-in, organic adoption from the teams that have to use it, and then communication, and this is like the most challenging thing to overcome. So what are the breakdowns happening in a systems team? It's usually less often in the data they work, and more often in designers and developers
06:26
really struggling to speak the same language. And I know this to a certain extent from a personal perspective, because I kind of sit sometimes in between design and development. You know, if you ask me to write a complex function in Ember, you know, come back a couple
06:43
of hours later and maybe I'll have made some progress. But it's these communication barriers that really are challenging in a cross-functional team. For clarity's sake, Webflow is not code for you designers out there, if they're already.
07:01
And for engineers, maybe who don't understand design, unfortunately, Microsoft Paint is no longer here with us anymore. Dreamweaver ceases to exist, and Fireworks is put on its last show. I don't even know what that was. So really, Melanie just wants to be included in this communication mind game.
07:25
So let the folks around you in to help solve these problems in a collaborative environment. This is a baking hot meme zone right here. Yeah. Jory's our gift maker on our team.
07:41
Sure. So, as the design system team, we do have some communication problems. Our team is really actually quite advanced. Everyone has been doing what they do for a very long time, and even we have communication struggles. One challenge we do not have is Ember, our framework.
08:06
We get to use Ember, our product apps, our Ember apps, and this makes our lives easier for all of the reasons that we all are here and all love Ember. Shared understanding, common approaches to problems, easier to meet expectations because
08:21
we have shared expectations for the most part. Also shout-out to HashiCorp for using Ember from the start. I think it speaks to the power of the Ember community that HashiCorp has apps that are nine and ten years old and still using Ember. Michael Lang is going to talk about this tomorrow, so make sure you don't miss that talk.
08:46
So one of our huge challenges as a systems team at HashiCorp is scale, and it's even more challenging when your design system has to support a variety of divergent product lines. Some of these product lines exist in isolation now and may or may not exist in isolation
09:05
in the future. We don't really know. So at HashiCorp, there are around 12 individual product apps that we support. We think, yeah, there may be some stragglers out there. This is kind of just a capturing a little bit of the different areas of DevOps where
09:25
our product lines exist. All of these product lines have multiple teams working on them or different teams working on them, and there hasn't really been a unified design strategy at HashiCorp to bring all of these different applications together under one roof.
09:41
And even though we all use Ember, we can still write a form 25 different ways in an Ember app, right? And of course, all of our product apps write forms 25 different ways. So that's where one of our challenges comes in, and that's where the design system really helps, because if the design system is providing the form components, then we start to gather
10:05
around, oh, hey, wouldn't it be easier, wouldn't it be better if we all did our forms like this? Yeah, so the goal of this design system is to kind of be the glue that holds all of these products together. And by bringing these products together, of course, we mean the HashiCorp cloud platform.
10:23
It aspires to unify our product offerings into a single platform. We use Ember engines and our design system, and that helps bring it all together. But of course, like any company, we have that one React app. The developer documentation team decided to build the HashiCorp product user documentation
10:44
app in React, but then they saw our awesome design system, and they were like, oh, my god, we want to use that. So they use our design system artifacts, our components that we design, our foundational elements, colors, typography, et cetera, but they write all of the code in React and build
11:02
their own kind of component library for this developer documentation. Welcome in subject chain. Anyway, Jerry, I don't know about you, but when our manager recruited me, he was like, come work on this brand new design system, and I was like, oh, my god, yes, I've been wanting to do this for years, because maybe we'll get it right this time, and maybe it
11:22
will be accessible, and maybe all my dreams will come true. Yeah, and I was like, man, I'm in corporate America, and it's great. I love it. And I'm also in Angular world, and I would really like to get out of there. But yeah, I was happy to kind of continue my design system work at HashiCorp, where
11:41
there's a ton of buy-in from the top down to develop and deliver a great product. Except, you know, once I was there, I found out that this was not the green field I was looking for, and that a brand new team did not equal a green field project. I might have actually cried.
12:01
There's a saying in Zen Buddhism, desire is suffering, and I experienced a lot of that. But of course, we started strategizing about a path forward. So not only was there this legacy design system that existed at HashiCorp before our systems team existed, it's known as Structure, it was versioned in independent Figma files.
12:27
So these are two of the Figma cover screenshots, version 1.9 and 1.8. And what this resulted in was both of these libraries were being used by our product designers, and it wasn't really clear what the differences between them were.
12:43
An add-on to this is Structure only existed partially in code, so the different product teams implemented this legacy design system in different ways, and led to a lot of kind of divergent implementations of the system. There was also mixed buy-in from the product teams across HashiCorp.
13:03
Some teams used Structure, this design system, extensively, but other teams kind of forged their own path ahead. That's such a nice way to say that. We also found out that all these different products had their own UI add-ons.
13:21
So not only did we have to think about how we were going to move everyone forward from this partially implemented legacy design system, but we also had to figure out, well, how do we help them transition from their own UI add-ons, which they're probably really... Some of them are really well-crafted, and if they were mine, I'd be like, I don't want
13:41
your design system. I worked really hard on these. So how do we do that? We had to think about that, and it's really been like... Mm, herded cats. Pretty much. So this led to the creation of the HashiCorp design system, which is an integrated group of designers and developers and folks that kind of go back and forth.
14:05
And the goal of this system was to... To herd the cats. To herd the cats. Yeah. So an integrated team is essential to building a successful design system, but it surfaces other challenges, mainly surrounding the ways that designers and developers conceptualize
14:22
things really differently. A couple of examples. This is a little screenshot of our Helios badge component. Also known as a tag, a chip, a lozenge, a pill. These are a little strange, but they do exist. A stamp, a bullet, or just plain status.
14:46
So designers and developers use the same words, but sometimes mean different things. What is a variable? What is a variant? Also, we use the same words for different things.
15:00
What is a drop-down versus a pop-over? What's a tooltip versus a pop-over? What the fuck is a pop-over? Nobody knows. What's a menu? What's a pop-up? How are all these things different? We also have a difference in tooling. As a designer, I spend the majority of my day in Figma.
15:22
I don't understand Figma. Which, if you've worked in Figma, is sometimes a little bit, we'll say, removed from reality when it comes to actual browser implementation. Jory, I click on something, and then I've created a new branch and moved everything,
15:41
and all I was trying to do was zoom in so I could see what it is I'm supposed to create in CSS. Yeah, yeah, yeah. Seriously. If you have a developer who's often working in an IDE or working directly in the browser, and these differences in context and in day-to-day activity are what cause a fair amount of divergence
16:06
but also a little bit of overlap, depending on how you think about it. There are folks on our team and throughout HashiCorp that sit in the middle of design and engineering. Often times, though, these folks skew to one side or the other.
16:21
They're either a designer who can write a little bit of code or a developer who has a little bit of an eye for design. Yes, and that's why we're giving this talk. Although I like to design in, like, you know, code pen with code.
16:40
We literally just think differently as people. We still agree on most things. Most of the time, yeah. Sometimes it takes us a little while to sort through the details, but we get to the same page eventually. How do we address some of these challenges? Well, first we crack open a cold one or...
17:00
Poor scotch. Poor scotch or, you know, multiple of either of those. And our process has grown and adapted to meet our needs as our design system grows in both size and complexity. Here is an overcomplicated graphic that represents our process as a design system team.
17:22
Right now. We didn't start here. Right. This has evolved. This is the evolution. I'm not going to get into the nitty-gritty of this, but you might be asking, why is this process so complicated? Why is the process so important? Who manages this process? Well, this process exists out of a necessity, really, to support the scale that we need
17:43
to support at the enterprise level. And this process is largely managed by everybody on our team. It's a team effort. We're small, but we're integrated, and that leads lots of opportunity for us to manage our own kind of day-to-day exercises.
18:03
So this clearly defined process has really helped to establish this shared language between designers and developers and has essentially been the foundation for our work and allowed us to get to the scale that we're at right now.
18:21
Because we're all fairly advanced in our careers, having this shared language so any of us, designer or developer, could walk their way through the process, that's very clearly defined. It's important because there's really, I don't know about you, but like I've been doing this
18:41
for 25, 26 years, and it really sucks when someone treats me like it's my first day on the job or that's not your job role, like, yeah, but it is. So part of this process, we recognized that to successfully build a component, we would need to do some upfront planning.
19:03
It was a necessary first step because it answers the question, where do we start, in a really consistent way, and we have three parts now to our component planning process. First, we do an audit of both our design assets and code to figure out what already exists
19:21
in our partner teams. In this process, we partner with a group of folks that we call our ambassadors to help us dive into these complex use cases that may exist in their product lines. And then we organize all of our examples from our audits, and we brainstorm our spike topic
19:44
discussions into a components requirement document, or CRD, and this helps us align on things like scope, naming conventions, the structure of the component, like its anatomy, the features that we want to make sure we add, and the features that we want to add
20:03
later. We'll write all of this down. We fight about naming, so no one else has to. But they still kind of do. So once this CRD is fleshed out, we meet synchronously with our internal stakeholders to discuss
20:21
the CRD and the results of it and the component strategy going forward. And in this kickoff, we cover the roles and responsibilities of the project. We identify the stakeholders, whether they're internal or external to our team. We align on the scope. We discuss any risks or unknowns about the project.
20:43
We nail down a broad or loose timeline and some milestones. We address any open questions that folks might have before the actual work starts. And we assign some next steps to the individual contributors. And we do this because this kickoff creates a space for internal discussion to make sure
21:03
that we're all on the same page because the designer and the engineer that's assigned to the components might have different expectations than the rest of the designers, the rest of the engineers on the design system team. It also allows us to tie up any loose questions before we start our work.
21:24
Now that we've done this initial planning, we can actually get into the component creation work. So let's talk a little bit about our design process. Melanie's super familiar with this. This is a little bit of an oversimplification of our process, but we start with design exploration.
21:44
And I like to call this design playtime because that more effectively captures the attention of the process. It's quite childlike, yes, but we are designers. This can be a messy process a lot of the time. If you look into my Figma file when I'm going through an exploration phase, you may be very
22:05
confused by it. And that's partially intentional in a lot of circumstances. And it's meant to stretch our thinking and our creative juices. Then we progress onto a more tactical implementation where we're defining the structure of the
22:20
environment, the variance, the anatomy, mocking it up in context, and getting an initial round or a read from our ambassadors and our internal stakeholders to get some feedback. So obviously then we iterate off of that feedback if necessary, which often is the case. And we release that component as a beta experimental component for our ambassadors to test in their
22:45
design and in their mockups. And then, finally, we actually release the component. Unfortunately, this is the process in an ideal world, and the world is hardly ever ideal. Depending on the complexity of the component, this cyclical process might be quite repetitive
23:04
and repeat itself many, many, many times before we actually release the component. But Google doesn't. Can't we just do it because Google does it? Yeah. That's a trigger warning right there. So from an engineering perspective, I start with thinking about the component from, what
23:20
does the web give us by default? What do we already have? Let's start there. I'm thinking about the markup, then I start thinking about the functionality, and I'm doing that a long time before I'm thinking about what it might look like. Typically, I'll do a spike, I'll explore what pieces of code might already exist in our design system that I can reuse, because that's awesome.
23:42
And I'll get feedback from the designer and from the engineers on my team, and we're to create the actual component in code. But like Jerry said, it really is cyclical in nature because we want to get it right. And with all of the products that we support, getting it wrong, the cost of change is pretty
24:01
high, right? Backwards compatibility lessons that I've learned from Ember have proven very useful in creating a design system. We, I have to look at this closer, so we'll do a spike, right? A spike of the component as it might exist.
24:23
We'll meet and we'll talk it over, and usually there is someone that will say, hey, have you thought about this edge use case, and I'm like, oh, fuck, no, sorry. And then we'll iterate, and then we'll ship a beta, and then we'll review it again, and then we'll iterate it again, because I just didn't get that token variable name correct.
24:46
It was supposed to be like active on surface instead of just active, I don't know. And then we'll really release it, but we released the component code and the code in Figma, or the component in Figma, at the same time.
25:05
So designers and developers both get access to this component at the same time. And we do this on purpose because we're working to create a shared language between designers and developers to give them one less hurdle, one less giant gap.
25:24
And it's important because it ensures that everyone has access to the same assets at the same time. It consolidates our announcements so we're not being really confused by, oh, wait, did you mean you released the design, the component, or the other component?
25:43
They're both called component, what's going on here? It reinforces like the cross-function nature of our team, and it doesn't prioritize design or development ahead of one another. We're partners, we're standing side by side as equals.
26:01
And there's probably more that I'm not thinking of, but these are the heavy hitters for me. Yeah, so of course we don't just release Figma components and code components. Documentation is also a core part of our process. We document everything as code, absolutely everything, so that everything is in sync
26:24
between our component packages, our Figma libraries, and our documentation website. So this documentation is another touch point that creates the shared language between designers and engineers, and it really helps our consumers move faster and align on consistency across
26:45
all of our products for both usage and implementation. However, designers don't generally work in GitHub very often. We've been very intentional about this process, this part of our process, to really keep everything
27:04
in a visible nature, so that both our internal and external stakeholders have visibility on what part of the process we're in, what the process has gone through over its life cycle, and what the intended deliverables are. So there's definitely a learning curve for designers in getting up and running with the
27:23
general process of working within GitHub and working within the PR, but it's a totally necessary learning step to bridge that gap between design and development. Which we don't really tell them this because their egos are already too high, but it still feels like an accomplishment when I do a cherry pick, I don't know, first try, I'm like yes,
27:45
she shoots, she scores. Anyway, our ambassador engagement is another part of our process, and we've mentioned our ambassadors a few times already, but let's take a quick look into what that relationship is and how our ambassadors help us deliver at scale.
28:01
We work with a designer and a developer, they volunteer to be their products ambassadors, and we include them because they understand their product line better than we do, and they help with the audits, and so we can include them in the process of designing and developing
28:20
our components, and we really depend on them. We depend on them to tell us where the edges are, we depend on them to give us that early iterative feedback and like, no, this won't work for us because whatever reason. And we can then plan to either pivot ourselves or maybe we need to get them to stop doing
28:42
the weird thing. So not only does working with these ambassadors make our lives easier, it means we don't have to dig through all of these Figma files that may be spread across a variety of different teams, or dig through a bunch of different repos and code implementations, but this arrangement
29:01
with our ambassadors really helps us build strong relationships with our internal partners to promote the best end user experience and to get buy-in for our system. So not only is this a massive time save in the long run for us as a systems team, it helps us produce better components and write better documentation.
29:25
And because not everybody needs to be at not every meeting, we've developed a meeting cadence that helps and works really well for our globally distributed team. Yeah, we're calling in from all over the globe, including Vancouver, BC, Seattle, which is
29:42
where I'm from, Vancouver, Washington, San Jose, San Francisco, Chicago, Milwaukee-ish a little bit. And we have a couple of folks over in London. So we only really have a couple of hours per day where all of us overlap. Yeah. And I'm in the middle, which means I can never move because my meetings are like a perfect
30:03
time. They're not too early, not too late. They're just right. Yeah. So generally speaking, this is a little bit of an outline of our meeting cadence. All of these meetings generally happen in the first couple of hours of the day, at least for me as somebody on the West Coast, which means I'm up too early for me.
30:21
So my meetings are in the morning, our Midwest and East Coast folks are in the afternoon, and our folks in London are in closer to the end of their working day. Okay, so what about accessibility? Because y'all know me, and obviously I was going to talk about accessibility in a design system. So where do we fit this in our design system process?
30:42
We fit it every single step of the way. Accessibility is not an add-on. It's integrated. The day one from the CRD has accessibility requirements in it. Design has accessibility built into it.
31:01
We are talking about accessibility every single step of the way. By including accessibility on purpose in every step of the conversation, we're making sure that everyone is on the same page about our conformance goals. We have accessibility built into our components as much as possible, and wherever possible,
31:23
we'll use the handy assertions to let a developer know that they haven't included a vital piece of information. So this is our button component, and when you invoke this component, you have to provide a text value, even if it's an icon-only button, because we then automatically use the text
31:43
value as the ARIA label value. So we built that in for you, and if you forget, it's fine. We break your build. There's an assertion thrown, and it just reminds you to, like, you know, do the right thing. It's fine. You can do it, and in our documentation, we're very clear about what level of conformance
32:03
our components will achieve. This is especially important if we need to transitionally support a component variation that's not WCAG conformance. So right now, one of the limitations of tech is there's no way for a keyboard-only user
32:21
to access truncated content if it's in a non-interactive element. Somebody can fix this. Solve it. We'd love it. But right now, we can't do it. So because we have to support truncation in one of our components, we'll let folks know, hey, if you use this variant, your app will not be WCAG conformance.
32:46
We do, however, make a really nice modal. In our foundation documentation, we include the foundational elements of accessibility across an application, because no matter how good of a component we give you, you could
33:02
still put them together in a non-conformant way, and that would suck. It's our policy to provide the component variant – let me try that sentence again, because my brain just can't work.
33:21
It's our policy to provide the conformance component variant as the default. So when you invoke that component, all the defaults that are there, you can depend on that one being WCAG conformance. If further customization – bending the rules a bit – is required for the time being,
33:43
because remember, we're trying to take all these people that are on these legacy UI add-ons, these legacy design systems, and we're trying to get everyone to be in the same place. So we have to let them do weird stuff for a little while, while we get them to the same place. But we let them know what's conformant and what's not, and where those lines are, because
34:03
we want that to be really clear. So what have we learned in this process? I mean, honestly, we're still learning, and there are probably plenty of things that we're going to learn in the future where we'll screw up and piss somebody off. But legacy, everything is real.
34:22
legacy libraries are challenging to replace and hard to get buy-in for internally. Figma updates are very regular and have largely changed the way that we build components. We still have some components that were built at the earlier era of our design system that
34:44
are not utilizing some of the latest and greatest Figma features, which creates a certain amount of tech debt. And this tech debt is real across both disciplines, and this is largely why our process is so important and our bar for quality is so high.
35:02
One misstep in this process can impact hundreds of designers, developers, and consumers. So we make sure to get it right or as close to right as possible the very first time. And another lesson that we've learned is that our process is absolutely vital.
35:30
Shared expectations help us increase velocity. Everything is code, helps us unite cross-functional teams.
35:41
We get shared version control, we get the ability to track things and measure things and have really cool metrics, and it provides transparency and visibility to folks outside of our teams. And all of these things unite us. And our team has a very high bar for quality in our components.
36:04
Now this means, the trade-off is, of course, time. This can cause delays in shipping components, but it's worth it. Sometimes you have to just be willing to bite the bullet and say this is going to take longer
36:21
than we expected. We're sorry, but we promise it will be worth it. And every single time it's been worth it. We don't have to revisit components as frequently. We have a very clear justification for our decisions, which turns out is really important, because we've properly vetted our designs and our codes before we ship it.
36:41
So if someone comes and says, why didn't you do this thing that Google does? We can say, hey, we did this research and here's why. It also gives us an additional touch point to make sure that the final product is fully accessible. Or if it's not, then we document that too, or file a bug.
37:00
We've also learned to engage with your consumers anytime you can. This is a photo of our team and several of our consumer teams at a team off-site in Seattle. If anybody's familiar with Seattle, that's over in West Seattle on Alki Beach. I really regretted not bringing some glasses that day.
37:22
It was a gorgeous day. And we've really learned to celebrate our wins. Adoption is scaling rapidly across all of our consumers when engineers and designers try our design system, they're like, oh my god, we really like this. And we've begun, it's allowed us, because of our process, we've iterated on this process,
37:42
we've got this process pretty good now, we feel pretty confident about it, that's allowed us to start accepting internal contributions from other teams into our own code base. And because our design system is still largely driven by organic adoption, the fact that it's being adopted communicates to us that there's a lot of value in the high bar of
38:05
quality and our detailed documentation, even though they still don't read it as much as they should. So back in July, July 29th, almost a year ago, we released version 1.0 of the Helios design system.
38:24
We're now on version 2.8 at the time of this slide being created. We may have released a patch since then. Maybe they did stuff while we were gone. So this is a massive accomplishment for us, and it really speaks to the importance of
38:43
our process, and it showcases a successful cross-functional team, which can oftentimes not be successful for all of the reasons that we've already spelled out. And it captures our ongoing commitment to the consumers and our end users.
39:03
So some numbers, because those are fun. We've released 38 components. 325 design tokens. 537 icons. And we have support for three complex patterns. We've also had eight of our product teams adopt our design system.
39:26
We have around 3,400 instances of our components in code. 30,000 Figma instances? Too many, but wow. Asterisk connects to that. And hundreds of happy developers and consumers are consuming our system.
39:41
So here are a couple of little accolades from some of our consumers. The pagination component took something very complicated, and in a matter of minutes, it just worked. Love to hear it. It's such a nice thing to hear, y'all. Especially in pagination. It's well thought out and handles 95% of our use cases.
40:03
It's incredibly composable within the limits of what a component should be doing. Imagine getting that. I did a dance, y'all. I did a little happy dance. I think the design system fixed major accessibility issues we had. Of course it did.
40:21
Should have had you say that one. I know, right? All right. So it's time for this designer and this developer to go walk into a bar. So I'm going to leave you with this, like I always do. You do not require permission to create accessible code. And that's it. Thank you. Thanks.