Big Medium - Full Feed Big Medium is a digital agency that helps complex organizations build design systems, craft exceptional online experiences, and transform digital operations. en Thu, 14 Mar 2024 15:44:02 UT Big Medium 3.0 http://blogs.law.harvard.edu/tech/rss https://bigmedium.com/ When will AI Replace Us? <div class="bmw_pageContent"> <div class="video video--16x9"> <iframe width="560" height="315" src="https://www.youtube.com/embed/8mnCC73BCFU?si=IyeCkdhwMLd7MT8u" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe> </div> <aside class="aside media-right"> Kevin gave this talk at Smashing Magazine&#8217;s <a href="https://smashingconf.com/meets-future-design-systems">The Future of Design Systems Meet</a> on February 7th, 2024. </aside> <p>Who&#8217;s not afraid that AI will replace their job? In his talk, Big Medium&#8217;s Kevin Coyle shows us how this isn&#8217;t a new fear and how AI can be our new colleagues, and not our replacements. These new colleagues make lots of mistakes (as Kevin hilariously points out) but your team can start using AI today (seriously!) to guide them in the right direction.</p> </div> <!-- end bmw_pageContent --> Thu, 14 Mar 2024 15:22:30 UT https://bigmedium.com/speaking/when-and-how-will-ai-replace-us.html df0b8e57cad9b3877b27ea0e81b70903-1636 ai design system webdev kevin coyle web design future Talks Kevin Coyle https://bigmedium.com/ideas/ai-and-design-systems.html https://bigmedium.com/speaking/ai-web-development-communication-gap.html https://bigmedium.com/ideas/links/a-coder-considers-the-waning-days-of-the-craft.html What's Next for a Global Design System <div class="bmw_pageContent"> <aside class="aside media-right"> <p>This article was originally published at <a href="https://bradfrost.com/blog/post/whats-next-for-a-global-design-system/">bradfrost.com</a>.</p> <p><strong>Looking for help?</strong> If you&#8217;re planning, building, or evolving an enterprise design system, that&#8217;s what we do. <a href="/hire/">Get in touch.</a></p> </aside> <p>I recently published an article outlining the need for a <a href="https://bradfrost.com/blog/post/a-global-design-system/">Global Design System</a>. In my post, I wrote, &#8220;A Global Design System would improve the quality and accessibility of the world&#8217;s web experiences, save the world&#8217;s web designers and developers millions of hours, and make better use of our collective human potential.&#8221;</p> <p>I&#8217;m thrilled to report back that many, many people feel the same. The response to this idea has been overwhelmingly positive, with people chiming in with responses like:</p> <ul> <li>&#8220;Hell yeah!&#8221;</li> <li>&#8220;I&#8217;ve been saying this for years!&#8221;</li> <li>&#8220;This would save us so much effort!&#8221;</li> <li>&#8220;I recently started my new design system job and am disheartened to effectively be rebuilding the same thing I did in my last company.&#8221;</li> <li>&#8220;At my agency, I literally have 3 developers implementing accordion components in 3 separate (but essentially the same) projects.&#8221;</li> <li>&#8220;I find it so hard and confusing to find the most accessible components to reach for; I wish there were official accessible components to use.&#8221;</li> <li>&#8220;I&#8217;d love to not have to think about markup as much as I do now.&#8221;</li> </ul> <p>I was recently a guest on <a href="https://bencallahan.com/the-question">Ben Callahan&#8217;s The Question</a>, and he posed the question &#8220;should there be a Global Design System?&#8221; The results were overwhelmingly positive:</p> <p>The thought of having a trustworthy, reliable, and capital-O Official Global Design System is clearly attractive to a lot of people. I agree! But even us proponents aren&#8217;t so naive to believe the creation of a Global Design System wouldn&#8217;t be without plenty of effort, alignment, and challenges.</p> <figure class="media-center bmc_image"> <a href="https://bigmedium.com/bm.pix/image-14-1024x334.png" rel="bm_lightbox" title="" target="_blank"><img src="https://bigmedium.com/bm.pix/image-14-1024x334.orig-250.png" alt="Bar graph with title &quot;Should there be a global design system?&quot; The &quot;yes&quot; bar shows 71 (80.7%) responses, while the &quot;no&quot; bar shows 17 (19.3%) responses" srcset="https://bigmedium.com/bm.pix/image-14-1024x334.orig-2000.png 1024w, https://bigmedium.com/bm.pix/image-14-1024x334.orig-1000.png 1000w, https://bigmedium.com/bm.pix/image-14-1024x334.orig-500.png 500w, https://bigmedium.com/bm.pix/image-14-1024x334.orig-250.png 250w" sizes="(min-width: 1050px) 1050px, 100vw" title="Click to enlarge" /></a> </figure> <p><strong>In addition to many of the positive responses, I heard plenty of skepticism, open questions, and apprehension. So much of it is valid and shared by me!</strong> <a href="https://chriscoyier.net/2024/02/05/thoughts-on-a-global-design-system/">Chris Coyier published a great post</a> that sums up a lot of it, and we were able to <a href="https://shoptalkshow.com/601/">dive into things together on ShopTalk Show</a>. In this post, I&#8217;d like to dig into of the feedback and skepticism, and also share an update on some of the progress that&#8217;s been made so far.</p> <p>I&#8217;ll go through some of the themes that I heard and address them as best as I can. Here goes!</p> <h3 id="wealreadyhaveaglobaldesignsystem.">&#8220;We already have a global design system.&#8221;</h3> <blockquote> <p>Isn&#8217;t every open-source design system a &#8220;global design system&#8221;? Aren&#8217;t the people making them trying to make them as useful as possible for as many people as possible? If that&#8217;s right, and thus they have failed, why did they fail? What are they doing that doesn&#8217;t map to the philosophy of a global design system?</p> </blockquote> <p>This is true! Open source design systems aim to be useful for as many people as possible. In <a href="https://bradfrost.com/blog/post/a-global-design-system/">my original post</a> I explain some of the challenges of existing solutions:</p> <blockquote> <ol> <li><strong>These solutions were (understandably!) created with a specific organization&#8217;s specific goals &amp; considerations in mind</strong>. The architecture, conventions, and priorities of these libraries are tuned to the organization it serves; they don&#8217;t take into account the sheer breadth of the world&#8217;s UI use cases.</li> <li><strong>They nearly always come with a specific default aesthetic.</strong> If you adopt Material Design, for example, your products will look like Google&#8217;s products. These libraries can be configurable, which is great, but themeabilitiy has limits and often results in many teams fighting the default look-and-feel to achieve custom results. In our experience, this is where folks end up creating a big mess.</li> </ol> </blockquote> <p>Existing solutions haven&#8217;t &#8220;failed&#8221;, but none are positioned as a formal standard and lack the authority beyond their corporate/open-source reputation. They are de facto standards, and while that isn&#8217;t a terrible thing, it still leads to duplicative effort and requires consumers to go comparison shopping when searching for a sound solution.</p> <p><strong>A Global Design System is less about the &#8220;what&#8221; and more about the &#8220;who&#8221; and &#8220;where&#8221;.</strong> Nearly all of the popular open-source systems out there are perfectly fine from a component/feature/architecture perspective. The goal of a Global Design System is not to create a sibling to these existing systems, but to introduce a new canonical, more formal layer that can feed into these systems and beyond.</p> <h3 id="isntthisjusthtml">Isn&#8217;t this just HTML?</h3> <p>Isn&#8217;t HTML the Global Design System? Shouldn&#8217;t missing components simply be added to HTML? I discuss this at length in <a href="https://bradfrost.com/blog/post/a-global-design-system/">the original post</a>:</p> <figure class="media-left bmc_image"> <a href="https://bigmedium.com/bm.pix/cleanshot-2024-03-11-at-09-27-17-700x720.png" rel="bm_lightbox" title="" target="_blank"><img src="https://bigmedium.com/bm.pix/cleanshot-2024-03-11-at-09-27-17-700x720.orig-250.png" alt="A meme that reads: &quot;Mom, can we have a Global Design System?&quot; &quot;No. There is already a Global Design System at home&quot; &quot;Global design system at home...&quot; Followed by a picture of many UI buttons from popular design systems" srcset="https://bigmedium.com/bm.pix/cleanshot-2024-03-11-at-09-27-17-700x720.orig-2000.png 700w, https://bigmedium.com/bm.pix/cleanshot-2024-03-11-at-09-27-17-700x720.orig-500.png 500w, https://bigmedium.com/bm.pix/cleanshot-2024-03-11-at-09-27-17-700x720.orig-250.png 250w" sizes="(min-width: 640px) 720px, 100vw" title="Click to enlarge" /></a> </figure> <blockquote> <p>Thanks to the tireless work of browser folks and standards bodies, I think that by and large we have most HTML elements and primitives in place to make most common web user interfaces. <strong>What we need now are more prefabricated UI components</strong> that abstract away much of the close-to-the-metal HTML and give developers composed, ready-to-use modules to drop into their projects.</p> </blockquote> <p>In my opinion, HTML already has what we need, and it could be overkill to flood the HTML spec with <code>&lt;badge&gt;</code> and <code>&lt;card&gt;</code> and <code>&lt;textfield&gt;</code> and <code>&lt;alert&gt;</code> et al. Popular design system components tend to be more <em>opinionated compositions</em> rather than low-level elements. Moreover, the standards process needs to account for every use case since decisions are cooked into the very fabric of the web, which I explain in my earlier post:</p> <p>The HTML standards process is necessarily slow, deliberate, and comprehensive, so a Global Design System layer on top of HTML can pragmatically help developers get things done now while also creating a path to future inclusion in the HTML spec if applicable.</p> <h3 id="xkcdstandardscomic">xkcd standards comic</h3> <p>Unsurprisingly, <a href="https://xkcd.com/927/">this classic XKCD comic</a> has been brought up plenty of times after I&#8217;ve shared the idea of a Global Design System:</p> <figure class="media-left bmc_image"> <a href="https://bigmedium.com/bm.pix/standards-1.png" rel="bm_lightbox" title="" target="_blank"><img src="https://bigmedium.com/bm.pix/standards-1.orig-250.png" alt="A three-frame XKCD comic that has the title &quot;How Standards Proliferate&quot; Frame 1: &quot;Situation: there are 14 competing standards&quot; Frame 2: A stick person says &quot;14! Ridiculous! We need to develop one universal standard that covers everyone's use cases.&quot; Stick person two says &quot;Yeah!&quot; Frame 3: &quot;Soon: Situation: there are 15 competing standards&quot;" srcset="https://bigmedium.com/bm.pix/standards-1.orig-2000.png 500w, https://bigmedium.com/bm.pix/standards-1.orig-250.png 250w" sizes="(min-width: 640px) 720px, 100vw" title="Click to enlarge" /></a> </figure> <p>One of the most challenging aspects of articulating this idea is that it differs from the current paradigm. The proposal isn&#8217;t to create a better Bootstrap. The proposal isn&#8217;t to create an alternative to HTML. In my view, there&#8217;s a layer missing in between the base HTML layer and the myriad design system implementations out there:</p> <figure class="media-center bmc_image"> <a href="https://bigmedium.com/bm.pix/cleanshot-2024-03-11-at-17-37-392x.png" rel="bm_lightbox" title="" target="_blank"><img src="https://bigmedium.com/bm.pix/cleanshot-2024-03-11-at-17-37-392x.orig-250.png" alt="An illustration depicting a layer cake with an HTML layer on the bottom, a missing second layer, a third-layer that has &quot;org-specific design systems&quot; and &quot;open-source design system&quot; beside each other, and a fourth layer that reads &quot;product&quot;" srcset="https://bigmedium.com/bm.pix/cleanshot-2024-03-11-at-17-37-392x.orig-2000.png 2000w, https://bigmedium.com/bm.pix/cleanshot-2024-03-11-at-17-37-392x.orig-1000.png 1000w, https://bigmedium.com/bm.pix/cleanshot-2024-03-11-at-17-37-392x.orig-500.png 500w, https://bigmedium.com/bm.pix/cleanshot-2024-03-11-at-17-37-392x.orig-250.png 250w" sizes="(min-width: 1050px) 1050px, 100vw" title="Click to enlarge" /></a> </figure> <p>The thought is that a Global Design System can help bridge the gap between HTML and existing design systems. Capture and centralize the components we see organizations building and rebuilding ad nauseam under one roof that is blessed by the appropriate organizations of the web.</p> <figure class="media-center bmc_image"> <a href="https://bigmedium.com/bm.pix/cleanshot-2024-03-11-at-17-38-132x-1.png" rel="bm_lightbox" title="" target="_blank"><img src="https://bigmedium.com/bm.pix/cleanshot-2024-03-11-at-17-38-132x-1.orig-250.png" alt="An illustration depicting a layer cake with an HTML layer on the bottom, a second layer labeled &quot;Global Design System&quot;, a third-layer that has &quot;org-specific design systems&quot; and &quot;open-source design system&quot; beside each other, and a fourth layer that reads &quot;product&quot;" srcset="https://bigmedium.com/bm.pix/cleanshot-2024-03-11-at-17-38-132x-1.orig-2000.png 2000w, https://bigmedium.com/bm.pix/cleanshot-2024-03-11-at-17-38-132x-1.orig-1000.png 1000w, https://bigmedium.com/bm.pix/cleanshot-2024-03-11-at-17-38-132x-1.orig-500.png 500w, https://bigmedium.com/bm.pix/cleanshot-2024-03-11-at-17-38-132x-1.orig-250.png 250w" sizes="(min-width: 1050px) 1050px, 100vw" title="Click to enlarge" /></a> </figure> <p>So yeah, the goal is not to create a competing standard, but to introduce a new layer in order fill a gap in the landscape.</p> <h3 id="youdhavetoaccountforeveryusecase">&#8220;You&#8217;d have to account for every use case&#8221;</h3> <p>Don&#8217;t get me wrong: creating a design system for the world would be hard work. But! While HTML needs to account for <em>every</em> possible use case, a Global Design System could aim to handle common use cases. From my earlier post:</p> <blockquote> <p>If the Global Design System could provide solutions for the majority of use cases for a given component, that would be a huge win! But what if you have a need to make a custom SVG starburst button that does a backflip when you click on it? That&#8217;s fine! We still have the ability to make our own special pieces of UI the old-fashioned way. This is also why a layer on top of HTML might be a better approach than extending HTML itself; HTML <em>has to</em> account for all use cases, where a Web Component library can limit itself to the most common use cases.</p> </blockquote> <p>After all, this is what we see in design systems all over the world. A design system doesn&#8217;t (and shouldn&#8217;t!) provide every solution for <em>all</em> tabs, <em>all</em> buttons, and <em>all</em> cards, but rather provides sensible solutions for the <a href="https://bigmedium.com/ideas/boring-design-systems.html">boring</a>, common use cases so that teams can instead focus on the things that warrant more effort and brain power. The hope is that pragmatism and focusing on commonplace solutions would expedite the process of getting this off the ground.</p> <h3 id="thingswilllookthesame">&#8220;Things will look the same!&#8221;</h3> <p>Ah yes, the age-old &#8220;<a href="https://bradfrost.com/blog/link/design-systems-and-creativity-unlikely-allies/">design systems are killing creativity</a>&#8221; trope.</p> <p>To be perfectly clear: a Global Design System would need to be generally unstyled and extremely themeable. A Global Design System component might look something like this out of the box:</p> <figure class="media-left bmc_image"> <a href="https://bigmedium.com/bm.pix/cleanshot-2024-03-11-at-17-58-272x-2.png" rel="bm_lightbox" title="" target="_blank"><img src="https://bigmedium.com/bm.pix/cleanshot-2024-03-11-at-17-58-272x-2.orig-250.png" alt="An email address input field with no default styles applied to it.-2" srcset="https://bigmedium.com/bm.pix/cleanshot-2024-03-11-at-17-58-272x-2.orig-2000.png 1272w, https://bigmedium.com/bm.pix/cleanshot-2024-03-11-at-17-58-272x-2.orig-1000.png 1000w, https://bigmedium.com/bm.pix/cleanshot-2024-03-11-at-17-58-272x-2.orig-500.png 500w, https://bigmedium.com/bm.pix/cleanshot-2024-03-11-at-17-58-272x-2.orig-250.png 250w" sizes="(min-width: 640px) 720px, 100vw" title="Click to enlarge" /></a> </figure> <p>The decision to make a door sky blue with fancy brass hinges or white with matte black hinges is a separate concern from &#8220;does the door open and close?&#8221;. A Global Design System would contain the proper semantics, relationships, accessibility, functionality, but leaves styling largely out of the equation. Think Global <a href="https://bradfrost.com/blog/post/creating-themeable-design-systems/">Design System + CSS Zen Garden</a>. Thanks to CSS custom properties, design token values can flow through the Global Design Systems components to accomplish any look and feel:</p> <figure class="media-left bmc_image"> <a href="https://bigmedium.com/bm.pix/cleanshot-2024-03-11-at-17-58-392x.png" rel="bm_lightbox" title="" target="_blank"><img src="https://bigmedium.com/bm.pix/cleanshot-2024-03-11-at-17-58-392x.orig-250.png" alt="An email address input field with a specific design aesthetic applied to it" srcset="https://bigmedium.com/bm.pix/cleanshot-2024-03-11-at-17-58-392x.orig-2000.png 1480w, https://bigmedium.com/bm.pix/cleanshot-2024-03-11-at-17-58-392x.orig-1000.png 1000w, https://bigmedium.com/bm.pix/cleanshot-2024-03-11-at-17-58-392x.orig-500.png 500w, https://bigmedium.com/bm.pix/cleanshot-2024-03-11-at-17-58-392x.orig-250.png 250w" sizes="(min-width: 640px) 720px, 100vw" title="Click to enlarge" /></a> </figure> <p><a href="https://shoptalkshow.com/601/#t=00:25:52">On the ShopTalk Show, we got into theming</a> and the fact that many people reach for design systems specifically because they provide a particular aesthetic. Which makes total sense! I could absolutely envision a Global Design System theme marketplace (using that term loosely, not necessarily implying a store) where people could choose a Tailwind-based theme, a Material Design theme, a Bootstrap theme, an <a href="https://open-props.style/">Open Props</a>-based theme, or of course create whatever custom themes designed to meet the brand/design language needs of their organization. But again, I think it&#8217;s important that the system is &#8220;theme-less&#8221; default.</p> <h3 id="webcomponentshaveproblems">&#8220;Web Components have problems&#8221;</h3> <p>In the <a href="https://bradfrost.com/blog/post/a-global-design-system/">original post</a>, I outline the reasons why it likely makes sense for a Global Design System to exist as a library of Web Components, which could contain something like this:</p> <pre><code>&lt;www-text-field label=&quot;Email Address&quot; type=&quot;email&quot; required&gt; &lt;/www-text-field&gt; </code></pre> <p>Setting aside the specific details like attribute names (which would require careful research and consideration), the gist is that a Global Design System&#8217;s Web Component library would deliver the component markup, behavior, and any core styles to user developers. <strong>Developers would interface with each Web Component&#8217;s API instead of having to author markup themselves, which would drastically reduce many low-level accessibility errors (e.g. associating a label with its corresponding input) and improve the quality and semantics of the world&#8217;s web experiences.</strong></p> <p>The unfortunate reality is that Web Components currently require JavaScript to deliver this abstraction. What would be <em>awesome</em> is to be able to simply wire Web Components up and have them Just Work, even if JS fails <a href="https://www.kryogenix.org/code/browser/everyonehasjs.html">for whatever reason</a>. It would be awesome if something like this Just Worked:</p> <pre><code>&lt;script type=&quot;module&quot; src=&quot;path/to/global-design-system.js&quot;&gt;&lt;/script&gt; &lt;form&gt; &lt;www-text-field label=&quot;First name&quot;&gt;&lt;/w3c-textfield&gt; &lt;www-text-field label=&quot;Last name&quot;&gt;&lt;/w3c-textfield&gt; &lt;www-text-field label=&quot;Email&quot; type=&quot;email&quot;&gt;&lt;/w3c-textfield&gt; &lt;www-textarea-field label=&quot;Comments&quot;&gt;&lt;/w3c-textfield&gt; &lt;www-button variant=&quot;primary&quot;&gt;Submit&lt;/w3c-button&gt; &lt;/form&gt; </code></pre> <p>Thankfully, much work has been done around <a href="https://www.google.com/search?q=web+components+server+side+rendering&amp;oq=web+components+serv&amp;gs_lcrp=EgZjaHJvbWUqBwgAEAAYgAQyBwgAEAAYgAQyBggBEEUYOTIICAIQABgWGB4yCAgDEAAYFhgeMggIBBAAGBYYHjIICAUQABgWGB4yCAgGEAAYFhgeMgYIBxBFGD2oAgCwAgA&amp;sourceid=chrome&amp;ie=UTF-8">server-side rendering</a> for Web Components and <a href="https://lit.dev/docs/ssr/overview/">solutions exist</a>. But unfortunately this requires extra work and configuration, which is a bit of a bummer as that currently limits the reach of a Global Design System.</p> <p>And much as I love many peoples&#8217; excitement around <a href="https://cloudfour.com/thinks/html-web-components-are-having-a-moment/">HTML Web Components</a>, this technique defeats the purpose of removing the burden of markup on consuming developers, doesn&#8217;t create clean abstractions, and complicates the delivery of updated design system components to users. There&#8217;s more to say about Web Components but that&#8217;s a post for another day.</p> <p>Despite their current challenges, Web Components are part of the web platform and these current shortcomings will continue to be addressed by the super smart people who make these things happen. I&#8217;d hope that this whole effort could serve as a lens to make Web Components even more awesome.</p> <h3 id="tooflexible">Too flexible?</h3> <p>In <a href="https://chriscoyier.net/2024/02/05/thoughts-on-a-global-design-system/">Chris&#8217;s article</a>, he wonders if a Global Design System would need to be so &#8220;flexible to the point of being useless.&#8221; I understand what Chris is saying, but I think that scores of popular design systems share a similar architectural shape, and that certain components need to be architected in an extremely composable way. <a href="https://getbootstrap.com/docs/5.3/components/card/">Bootstrap&#8217;s card</a>, <a href="https://m2.material.io/components/cards#anatomy">Material&#8217;s card</a>, <a href="https://www.lightningdesignsystem.com/components/cards/">Lighting&#8217;s card</a>, and other cards don&#8217;t dictate what goes in the box, they simply define the box. A design system card must be extremely flexible to account for so many varied use cases, but the defining the box as a component is still incredibly valuable. Like all design system components, the rigidity-vs-flexibility dial needs to be considered on a case-by-case basis. This holds true for a Global Design System.</p> <h3 id="thiswouldbehardtodo.">&#8220;This would be hard to do.&#8221;</h3> <p><em>Lol, yep.</em></p> <p>Like most design system challenges, the true hurdles for a Global Design System have little to do with tech stack, API design, or feature set. Instead, <strong>the challenges have everything to do with orchestrating and aligning people.</strong></p> <p>As mentioned before, <strong>this effort is more a matter of &#8220;who&#8221; and &#8220;where&#8221; than &#8220;what&#8221;.</strong> Getting the right people and organizations involved, formalizing this whole shebang, figuring out how to fund an effort like this, determining architecture and priority, and winning hearts and minds is the bulk of the work. And that&#8217;s just to get the thing off the ground!</p> <p>This feels like a good segue into a status report and next steps on this whole effort.</p> <blockquote class="pullquote media-center"> The challenges around creating a Global Design System have everything to do with orchestrating and aligning people. </blockquote> <h3 id="statusreport">Status report</h3> <p>Since publishing my post, I was able to connect with the inimitable <a href="https://twitter.com/gregwhitworth">Greg Whitworth</a>, the chair of <a href="http://open%20ui/">OpenUI</a>. For years, Greg and the merry folks who participate in OpenUI have been living in between the worlds of popular design systems and the W3C. Their tireless work, <a href="https://open-ui.org/components/accordion.research/">research</a>, <a href="https://open-ui.org/research/component-matrix/">component matrix</a>, and <a href="https://open-ui.org/components/combobox.explainer/">proposals</a> have paved the way for standardization of widely-implemented UI components.</p> <p>They&#8217;re well-positioned for an effort like this, and it seems like once upon a time OpenUI even had aspirations of creating a Web Component library to give some teeth the specifications they&#8217;ve been developing. Greg and I had a great initial conversation, and we just had another meeting with more members to discuss the idea. There&#8217;s been some great validation, some healthy skepticism, and some legitimately tough questions around this whole thing. These are exactly the types of conversations that should be happening, so I&#8217;m glad we&#8217;re having them!</p> <h3 id="nextsteps">Next steps</h3> <p>I&#8217;ve taught tens of thousands of people all over the world about the soup-to-nuts process of getting a successful design system off the ground. I tend to break the process down into these general phases:</p> <ol> <li>Sell</li> <li>Kickoff</li> <li>Plan</li> <li>Create</li> <li>Launch</li> <li>Govern</li> </ol> <p>(Keep in mind this often isn&#8217;t a linear process; selling is never done!)</p> <p>The creation of a Global Design System would follow this same process, albeit through a different lens. We&#8217;re still very much in the selling phase, and the next steps will require getting some alignment and traction with the appropriate organizations. I reckon continuing the conversation with OpenUI will bear fruit, and hey! <a href="https://discord.gg/TN6M73mu">They have a Discord; you can join too</a> and get involved.</p> <p>Many, many people have reached out with some form of &#8220;I have insights/research/design/code I&#8217;d love to share whatever would help this effort.&#8221; Which is AWESOME. While it may be a bit premature to start digging into specific solutions or architecture, I think this enthusiasm a real testament to the legitimacy of this idea. It&#8217;s all very encouraging.</p> <p><strong>I truly feel like we can dramatically improve the world&#8217;s web experiences while making better use of our collective human potential.</strong> I&#8217;m looking forward to keeping the conversation going, and would love to hear your thoughts, skepticism, and ideas around the creation of a Global Design System.</p> </div> <!-- end bmw_pageContent --> Wed, 13 Mar 2024 19:54:16 UT https://bigmedium.com/ideas/whats-next-for-a-global-design-system.html df0b8e57cad9b3877b27ea0e81b70903-1634 design system global design system web components Ideas Brad Frost https://bigmedium.com/ideas/a-global-design-system.html https://bigmedium.com/speaking/brad-frost-shoptalk-global-design-system.html https://bigmedium.com/ideas/links/thoughts-on-a-global-design-system-chris-coyier.html AI and Design Systems <div class="bmw_pageContent"> <aside class="aside media-right"> <p>This article was originally published at <a href="https://bradfrost.com/blog/post/ai-and-design-systems/">bradfrost.com</a>.</p> <p><strong>Looking for help?</strong> If your organization needs help integrating AI into your design system operation, or making your digital production more effective, that&#8217;s what we do! <a href="/hire/">Get in touch.</a></p> </aside> <p>We&#8217;ve all witnessed an avalanche of AI-powered tools flood the landscape over the last year and a half. At <a href="https://bigmedium.com/">Big Medium</a>, we help complex organizations design at scale and pragmatically adopt new technologies, so naturally we&#8217;ve been putting AI tools through their paces in order to uncover opportunities to help people produce better digital products and work better together.</p> <p>As we all know, design systems have proven to be effective tools that help organizations ship higher-quality user interfaces more efficiently. <strong>We&#8217;re finding that this new crop of AI tools can help supercharge design system efforts across many categories</strong>, and we&#8217;re starting to help our clients use AI to do exactly that. Our resident AI expert, <a href="https://kevincoyle.co.uk/">Kevin Coyle</a>, has been leading the charge in this wild new landscape, and we&#8217;ve all been exploring some promising ways that AI can assist in various aspects of design system creation and consumption. The future is here, and in this post we&#8217;ll demonstrate some of the ways we&#8217;re applying AI to the world of design systems, including:</p> <ol> <li><a href="#componentcodegeneration">Writing component code</a></li> <li><a href="#componenttranslation">Translating components across frameworks</a></li> <li><a href="#componenttestingandqa">Writing unit tests</a></li> <li><a href="#accessibilityreview">Reviewing accessibility</a></li> <li><a href="#documentation">Writing documentation</a></li> <li><a href="#documentationviewing">Making documentation more accessible/inclusive</a></li> </ol> <p>Of course, these are only some of the potential use cases and there&#8217;s plenty more potential still to explore. In any case, let&#8217;s dig in!</p> <h3 id="componentcodegeneration">Component code generation</h3> <p>One of the most obvious examples of AI for design systems is to generate design system component code. Last year, <a href="https://bradfrost.com/blog/post/design-systems-in-the-time-of-ai/">I wrote</a> that AI could be trained to act on instructions like this:</p> <blockquote> <p>Make a new component called badge that has 4 variants: success, error, warning, and info. It has a text string prop, and a size prop that has sm and lg as available options. The background colors for the 4 variants should use the success, error, warning, and info background color design token variants. And splat goes the AI.</p> </blockquote> <p>Turns out this is absolutely possible:</p> <figure class="video video--16x9"> <iframe width="560" height="315" src="https://www.youtube.com/embed/cmSVQn7Vyoc?si=o3qIEcY9M5rp5R3z" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen="" class="fluidvids-item" data-fluidvids="loaded"></iframe> </figure> <p><strong>When you train a LLM on a design system&#8217;s codebase, conventions, syntax and documentation, you get a component boilerplate generator on steroids.</strong> Human developers can then evaluate any outputted code, refine it (with or without the help of AI), and bring it over the finish line. In this scenario, AI becomes a junior developer contributing code for review like any other developer. <strong>We guestimate this approach could help developers create components 40&#8211;90% faster than manually writing things from scratch</strong>.</p> <blockquote class="pullquote media-center"> AI can be trained on bespoke conventions, technology choices, and preferences in order to generate output that matches an organization&#8217;s existing standards. </blockquote> <p><strong>It&#8217;s important to underscore that the AI can be trained on existing &#8212; often bespoke &#8212; conventions, technology choices, and language preferences.</strong> In our work across organizations of all shapes and sizes, we&#8217;ve seen all manner of approaches, standards, syntax, and preferences baked into a design system codebase. Turns out that stuff really matters when it comes to creating a design system that can successfully take root within an organization. So while we&#8217;ve seen plenty of impressive AI-powered code generator products, they tend to produce things using specific technologies, tools, and syntax that may not be compatible with conventions and preferences found at many capital-E Enterprises. We&#8217;re skeptical of general-purpose AI code generators and err on the side of solutions that are closely tailored to the organization&#8217;s hard-won conventions and architecture.</p> <h3 id="componenttranslation">Component translation</h3> <p>A different flavor of AI code generation involves translating code from one tech stack to another. Need to support Vue in addition to your existing Angular library? Want to create a Web Component library out of your existing React library? <strong>Without the help of AI, translation is a labor-intensive and error-prone manual effort. But with AI, we&#8217;ve dramatically reduced both effort and error when migrating between tech stacks.</strong></p> <p>The video below demonstrates AI converting a badge Web Component built with LitElement into a React component in a matter of a few keystrokes.</p> <figure class="video video--16x9"> <iframe width="560" height="315" src="https://www.youtube.com/embed/OdZOG-yBbs0?si=WImHAGzyqHobl5y0" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen="" class="fluidvids-item" data-fluidvids="loaded"></iframe> </figure> <p>Code and conventions that are shared between the tech stacks (SCSS, Storybook stories, component composition, doc blocks, props, state, and functionality) persist, and code and conventions that differ between tech stacks update in order to match the specific tech stack&#8217;s conventions.</p> <p><strong>This is powerful! Working with AI has brought our team closer to a true &#8220;write once, deploy anywhere&#8221; reality.</strong> Similar to how tools like <a href="https://prettier.io/">Prettier</a> have disarmed the Spaces vs Tabs Holy Wars, we envision AI tools making specific implementation details like tech stack, conventions, syntax, and preferences less important. Instead, we can name or demonstrate requirements, and then the robots handle the implementation details&#8212;and port the code accordingly.</p> <h4 id="platform-specificconventions">Platform-specific conventions</h4> <p>We&#8217;ve leaned on AI to assist with translating components to work with proprietary conventions in specific popular platforms. For example, we&#8217;ve used AI to convert a more standards-based <code>&lt;a&gt;</code> tag into <a href="https://nextjs.org/docs/pages/api-reference/components/link">Next.js&#8217;s <code>&lt;Link&gt;</code></a> convention in a way that preserves a clean source of truth while also leaning into platform-specific optimizations.</p> <p>It&#8217;s possible to take a clean design system codebase and use AI tools to create adaptations, wrappers, codemods, glue code, etc to help everything play nicely together. Our team is already doing all of these things with AI to great effect.</p> <h3 id="componenttestingandqa">Component testing and qa</h3> <p>As we&#8217;ve demonstrated, AI component code generation can be quite powerful. But a healthy level of skepticism is encouraged here! How can we be sure that component code &#8212; whether human or AI generated &#8212; is high quality and achieves the desired effect? <strong>We like to think of AI as a smart-but-sometimes-unsophisticated junior developer.</strong> That means we need to review their work and ask for revisions, just as you would with a human developer.</p> <p>Testing and QA are critical activities that help ensure that a design system&#8217;s codebase is sturdy and sound. Setting up AI automation for this can also help keep us honest when the pressure is on.<strong> Testing and QA often fall by the wayside when the going gets tough and teams are distracted by tough deadlines. AI can help make sure those tests keep getting written even as developers focus on shipping the project.</strong></p> <h4 id="unittests">Unit tests</h4> <p>Unit tests are a special kind of chore that always felt like pseudo-code to me. &#8220;Click the accordion; did the accordion open? Now click it again; did it close?&#8221; Manually writing unit test code is something we&#8217;ve seen many teams struggle with, even if they know unit tests are important. Thankfully with AI, you can write prompts as unit test pseudo code and the AI will generate solid unit test code using whatever tools/syntax your team uses.</p> <figure class="video video--16x9"> <iframe width="560" height="315" src="https://www.youtube.com/embed/p8j9EJtsfUw?si=T3PfI2Mj8E5e8rnq" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen="" class="fluidvids-item" data-fluidvids="loaded"></iframe> </figure> <p>There may be some manual last-mile stuff to bring tests over the finish line, but I see this as a big step forward to help developers actually create component unit tests. This also means no more excuses for not having unit tests in place!</p> <h3 id="accessibilityreview">Accessibility review</h3> <p>There are many great accessibility testing and auditing tools out there; AI adds another layer of accessibility QA to the puzzle:</p> <figure class="video video--16x9"> <iframe loading="lazy" width="560" height="315" src="https://www.youtube.com/embed/-9H4fykFn2Y?si=ylReSZ1Y02MQio4X" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen="" class="fluidvids-item" data-fluidvids="loaded"></iframe> </figure> <p>AI-powered accessibility review can be integrated into a design system workflow, ensuring that component code is up to snuff before being released. And unlike existing automated accessibility testing that often surface a simple &#8220;pass vs fail&#8221; checklist, AI-powered accessibility testing can integrate your organization&#8217;s specific accessibility guidelines and also surface helpful context and framing for best practices. We like this as this additional context and framing can really help teams grow their accessibility understanding and skills. Hooray!</p> <h3 id="documentation">Documentation</h3> <p><strong>Here&#8217;s the painful truth about documentation: nobody likes authoring it, and nobody likes reading it. But documentation is also critical to a design system&#8217;s success.</strong> I liken it to Ikea furniture construction: sure you could technically build a piece of furniture with only the parts on hand, but you&#8217;ll likely screw it up, waste time, and get frustrated along the way. Maybe AI can help solve the documentation paradox?</p> <h4 id="documentationauthoring">Documentation authoring</h4> <p>Authoring design system documentation by hand is a laborious, painful task. Teams are tasked with authoring pithy component descriptions, providing a visual specification, detailing each component&#8217;s API names and values, writing usage guidelines, and more. This information is incredibly helpful for design system consumers, contributors, and other stakeholders, but again, it&#8217;s all a pain in the butt to create. Moreover, documentation risks falling out of sync with the design system&#8217;s design and code library, and also has</p> <p>If LLMs can generate entire novels, they certainly would have no problem generating some words about some well-trodden UI components. <strong>The gist is to get AI to extract human-friendly documentation from design files, code libraries, and any other relevant sources (user research, personas, analytics, etc).</strong> And just as with code generation, <strong>LLMs can learn your organization&#8217;s specific conventions so documentation is custom tailored to your reality.</strong> Pretty dang cool.</p> <figure class="video video--16x9"> <iframe loading="lazy" width="560" height="315" src="https://www.youtube.com/embed/Jb5xDn6EgZY?si=4UvMzSq33gk3oiMv" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen="" class="fluidvids-item" data-fluidvids="loaded"></iframe> </figure> <p>Moreover, when this AI-powered documentation is wired up to the teams&#8217; workflows, the documentation can always represent reality and doesn&#8217;t get stale.</p> <h4 id="documentationviewing">documentation viewing</h4> <p>In Douglas Adam&#8217;s Hitchhikers Guide to the Galaxy, a <a href="https://hitchhikers.fandom.com/wiki/Babel_Fish">Babel fish</a> &#8220;can be placed in someone&#8217;s ear in order for them to be able to hear any language translated into their first language.&#8221; Indeed, many emerging AI technologies get awfully close to the sci-fi dream of real-time language translation. <strong>But beyond <em>linguistic</em> language, design systems need to account for language differences between disciplines, experiences, and other contexts.</strong></p> <p>Design systems promise to deliver a shared language, but current design system documentation tends to be static and either too specific or too general to be useful for the myriad stakeholders that make up a digital organization. Wouldn&#8217;t it be cool if design system documentation morphed itself into a form that&#8217;s custom-fit to the individual looking for guidance? AI can be the babel fish that speaks in the manner and lingo that you personally need things to be explained.</p> <blockquote class="pullquote media-center"> AI can tailor design system documentation to the individual, taking into account their discipline, their skill level, their context, and even their preferred spoken/written language. </blockquote> <p>A junior-level designer understands the design system in a different way than a senior-level designer. A consuming front-end developer has different goals than a consuming designer. <strong>AI can address this by tailoring the design system&#8217;s documentation to the individual: their discipline, their skill level, their context, and yes even their preferred spoken/written language.</strong></p> <p>Perhaps this AI-powered personalized guidance can help design systems realize the lofty goal of delivering a shared vocabulary across a digital organization?</p> <h3 id="principlesandconsiderations">Principles and considerations</h3> <p>As we&#8217;ve demonstrated here, AI tools can supercharge many facets of design system work. Of course it&#8217;s critical to stress that all of this is emerging technology, has the potential to do a lot of harm, and should be handled with care. <strong>A human-centric mindset along with a healthy level of skepticism (especially in these early days!) should be employed when wielding these new tools.</strong></p> <blockquote class="pullquote media-center"> Wielding AI tools requires a human-centric mindset along with a healthy dose of skepticism. </blockquote> <p>At Big Medium, we&#8217;re formulating some guiding principles and important considerations as we dig into these technologies:</p> <ul> <li><strong>Respect</strong> &#8211; With all of our work, we want to respect peoples&#8217; time, energy, and talents. AI can be wielded in many ways and has the potential to stomp all over our craft and our humanity. How can we let the machines take over our drudgery and free us up for more important, thoughtful, and fulfilling work? How can AI elevate and enhance our work?</li> <li><strong>Org-specific solutions</strong> &#8211; Design systems need to be tuned to the needs of a specific organization in order to be successful. AI can help evangelize &#8220;this is how we do things here&#8221;, but in order to do so these AI tools need to be internalize a specific organization&#8217;s culture, people, needs, technology, architecture, tools, and preferences.</li> <li><strong>Security and privacy</strong> &#8211; Related to the above point, in order for AI to be successfully integrated into an organization&#8217;s workflow, it needs to clear a high bar for security and privacy. Security is critical, and AI is rightly sounding alarm bells across the enterprise landscape. We feel strongly that on-premises AI tools are preferred over chucking an organization&#8217;s intellectual property into ChatGPT.</li> <li><strong>Human-owned input and output</strong> &#8211; It&#8217;s crucial for humans to control what gets fed into AI, and it&#8217;s crucial for humans to have the ability to modify/extend/fix any AI-generated output. While AI itself tends to be a black box, organizations should have full control over the input materials that the AIs are trained on, and should have full control over any outputted materials. Human team members can coach the AI, similar to how they might train a smart-yet-naive junior team member.</li> <li><strong>Predictability and reliability</strong> &#8211; Any AI tool needs to produce predictable, reliable results in order to be allowed anywhere near <a href="https://bigmedium.com/ideas/design-system-pace-layers-slow-fast.html">critical front-end infrastructure</a> at an organization. Training AI on an organization&#8217;s specific conventions is an important first step, but then it takes some finessing refining, and evolving to ensure the AI systems behave in a reliable manner.</li> <li><strong>Enhancement vs replacement</strong> &#8211; Teams shouldn&#8217;t have to throw away all of their hard-earned knowledge, architecture, and assets in order to make use of AI. AI should work with the grain of hard-earned solutions and architecture, and teams should feel like AI enhances their work versus replacing their jobs.</li> </ul> <p>Of course, these principles and considerations aren&#8217;t exhaustive, and we fully expect them to change and evolve as the landscape continues to shift.</p> <h3 id="abravenewworld">A brave new world</h3> <p>As we&#8217;ve demonstrated here, there&#8217;s so much potential to integrate AI into many facets of design systems work. What we&#8217;ve shared is by no means comprehensive; for instance, we haven&#8217;t shared much around how AI impacts the world of UX and visual designers. There&#8217;s also plenty more cooking in the lab; Kevin the AI wizard is conjuring up some downright inventive AI solutions that make the demos shared here look like child&#8217;s play. And of course we&#8217;re all witnessing the AI Big Bang unfold, so the landscape, capabilities, and tools will continue to evolve. It feels inevitable that the world of design systems &#8212; along with the rest of the world! &#8212; will be shaped by the evolution of AI technologies.</p> <p><em>Does your organization need help integrating AI into your design system operation? We can help! Big Medium helps complex organizations adopt new technologies and workflows while also building and shipping great digital products. Feel free to <a href="https://bigmedium.com/hire/">get in touch</a>!</em></p> </div> <!-- end bmw_pageContent --> Wed, 06 Mar 2024 19:15:20 UT https://bigmedium.com/ideas/ai-and-design-systems.html df0b8e57cad9b3877b27ea0e81b70903-1630 design system technology development principles documentation web components ai Ideas Brad Frost, Kevin Coyle & Ian Frost A Coder Considers the Waning Days of the Craft <div class="bmw_pageContent"> <p>In the New Yorker, writer and programmer James Somers shares his personal journey discovering just how good AI is at writing code—and what this might mean both individually and for the industry: <a href="https://www.newyorker.com/magazine/2023/11/20/a-coder-considers-the-waning-days-of-the-craft">A Coder Considers the Waning Days of the Craft</a>. “Coding has always felt to me like an endlessly deep and rich domain. Now I find myself wanting to write a eulogy for it,” he writes. “What will become of this thing I’ve given so much of my life to?”</p> <blockquote> <p>Software engineers, as a species, love automation. Inevitably, the best of them build tools that make other kinds of work obsolete. This very instinct explained why we were so well taken care of: code had immense leverage. One piece of software could affect the work of millions of people. Naturally, this sometimes displaced programmers themselves. We were to think of these advances as a tide coming in, nipping at our bare feet. So long as we kept learning we would stay dry. Sound advice—until there’s a tsunami.</p> </blockquote> <p>Somers travels through several stages of amazement (and grief?) as he gets GPT&#8211;4 to produce working code in seconds that would normally take him hours or days—or sometimes that he doubts he&#8217;d be capable of at all. If the robots are already so good at writing production-ready code, then what&#8217;s the future of the human coder?</p> <p>Here at Big Medium, we&#8217;re wrestling with the same stuff. We&#8217;re already using AI (and helping our clients to do the same) to do production engineering that we ourselves used to do: writing front-end code, translating code from one web framework to another, evaluating code quality, writing automated tests. It&#8217;s clear that these systems outstrip us for speed and, in some ways, technical execution.</p> <p>It feels to me, though, that it&#8217;s less our jobs that are being displaced than where our attention is focused. We have a new and powerful set of tools that give us room to focus more on the “what” and the “why” while we let the robots worry about the “how.” But our new robot colleagues still need some hand-holding along the way. In 2018, Benedict Evans wrote that <a href="https://www.ben-evans.com/benedictevans/2018/06/22/ways-to-think-about-machine-learning-8nefy">machine learning “gives you infinite interns, or, perhaps, infinite ten year olds”</a>—powerful but, in important ways, unsophisticated. AI has come a long, long way in the six years since, but it still misses the big picture and fails to understand human context in a general and reliable way.</p> <p>Somers writes:</p> <blockquote> <p>You can’t just say to the A.I., “Solve my problem.” That day may come, but for now it is more like an instrument you must learn to play. You have to specify what you want carefully, as though talking to a beginner. … I found myself asking GPT&#8211;4 to do too much at once, watching it fail, and then starting over. Each time, my prompts became less ambitious. By the end of the conversation, I wasn’t talking about search or highlighting; I had broken the problem into specific, abstract, unambiguous sub-problems that, together, would give me what I wanted.</p> </blockquote> <p>Once again, technology is pushing our attention higher up the stack. Instead of writing the code, we&#8217;re defining the goals—and the approach to meet those goals. It&#8217;s less about how the car is built and more about where we want to drive it. That means the implementation details become&#8230; well, details. As I wrote in <a href="https://bigmedium.com/ideas/do-more-with-less-digital-leadership-lean-times.html#enlist-the-robots">Do More With Less</a>, “Done right, this relieves us of nitty-gritty, error-prone, and repetitive production work and frees us to do higher-order thinking, posing new questions that solve bigger problems. This means our teams will eventually engage in more human inquiry and less technical implementation: more emphasis on research, requirements, and outcomes and less emphasis on specific outputs. In other words, teams will focus more on the right thing to do—and less on how to do it. The robots will take care of the how.”</p> <p>And that seems to be where Somers lands, too:</p> <blockquote> <p>The thing I’m relatively good at is knowing what’s worth building, what users like, how to communicate both technically and humanely. A friend of mine has called this A.I. moment “the revenge of the so-so programmer.” As coding per se begins to matter less, maybe softer skills will shine.</p> </blockquote> <div class="bmc_external_link"> <a href="https://www.newyorker.com/magazine/2023/11/20/a-coder-considers-the-waning-days-of-the-craft" class="btn btn--next"> A Coder Considers the Waning Days of the Craft | The New Yorker </a> </div> </div> <!-- end bmw_pageContent --> Mon, 19 Feb 2024 17:41:48 UT https://bigmedium.com/ideas/links/a-coder-considers-the-waning-days-of-the-craft.html df0b8e57cad9b3877b27ea0e81b70903-1629 work future programming productivity newyorker ai Ideas/What We’re Reading Josh Clark ShopTalk: Brad Frost on a Global Design System <div class="bmw_pageContent"> <figure class="media-right bmc_image"> <a href="https://bigmedium.com/bm.pix/bradtalkshop.png" rel="bm_lightbox" title="" target="_blank"><img src="https://bigmedium.com/bm.pix/bradtalkshop.orig-250.png" alt="Brad Frost on the TalkShop Podcast" srcset="https://bigmedium.com/bm.pix/bradtalkshop.orig-2000.png 500w, https://bigmedium.com/bm.pix/bradtalkshop.orig-250.png 250w" sizes="(min-width: 1100px) 690px, (min-width: 830px) 501px, (min-width: 640px) 380px, 100vw" title="Click to enlarge" /></a> </figure> <p>Big Medium&#8217;s Brad Frost joined the ShopTalk podcast for <a href="https://shoptalkshow.com/601/">a conversation with Chris Coyier and Dave Rupert</a>. The big topic: Brad&#8217;s call to action to create <a href="https://bigmedium.com/ideas/a-global-design-system.html">a global design system</a>. (And okay, a little bit about what he&#8217;s planning for his 40th birthday, too.)</p> <blockquote> <p>Brad Frost has got design systems on his mind—at a global scale. What is a global design system? Are two design systems ever the same? How would this slot inside atomic design? What has been the response from the web community to global design system as an idea? And what&#8217;s Frostapalooza? </p> </blockquote> <p><a href="https://shoptalkshow.com/601/">Listen to the podcast here.</a></p> </div> <!-- end bmw_pageContent --> Tue, 06 Feb 2024 22:39:32 UT https://bigmedium.com/speaking/brad-frost-shoptalk-global-design-system.html df0b8e57cad9b3877b27ea0e81b70903-1624 global design system podcast interview business design system brad frost Talks https://bigmedium.com/ideas/a-global-design-system.html https://bigmedium.com/ideas/whats-next-for-a-global-design-system.html https://bigmedium.com/ideas/links/thoughts-on-a-global-design-system-chris-coyier.html https://bigmedium.com/speaking/is-atomic-design-dead.html Thoughts on a Global Design System <div class="bmw_pageContent"> <p>Hot on the heels of his <a href="https://shoptalkshow.com/601/">podcast conversation with Big Medium’s Brad Frost</a>, Chris Coyier shared his ruminations on Brad’s call to create <a href="https://bigmedium.com/ideas/a-global-design-system.html">a universal design system</a>.</p> <p>Chris&#8217;s post, <a href="https://chriscoyier.net/2024/02/05/thoughts-on-a-global-design-system/">Thoughts on a Global Design System</a>, is a smart, incisive, and thought-provoking set of questions and critiques about Brad&#8217;s proposal. It&#8217;s the tough love that an ambitious idea needs in order to survive.</p> <p>Chris nods to the problem that Brad seeks to solve with a global design system: &#8220;Surely, the world is wasting the brain power of too many smart people solving the same set of problems again and again.&#8221; And then he pokes at whether this is the right solution. How would it work in practice? Who would run it? How could it be opinionated enough to be useful without being so opinionated that it&#8217;s no longer universal? And why haven&#8217;t similar efforts succeeded? Is what we already have as close as we&#8217;re likely to get?</p> <blockquote> <p>That feels like I’m being awfully critical. Sorry! Like I said, I like the enthusiasm and I do think there is potential here. But <strong>to realize the potential, I think you need to ask really hard questions and have really strong answers.</strong> Ultimately I sincerely hope it can be done. Having a super robust go-to set of components that are essentially vetted by the world would be awesome. I think it will take very strong set of principals and leadership to get there.</p> </blockquote> <p>We love both the spirit of the critique, and the depth of the commentary. Thanks, Chris, for the great framing for the conversation to come.</p> <div class="bmc_external_link"> <a href="https://chriscoyier.net/2024/02/05/thoughts-on-a-global-design-system/" class="btn btn--next"> Thoughts on a Global Design System – Chris Coyier </a> </div> </div> <!-- end bmw_pageContent --> Tue, 06 Feb 2024 22:23:15 UT https://bigmedium.com/ideas/links/thoughts-on-a-global-design-system-chris-coyier.html df0b8e57cad9b3877b27ea0e81b70903-1625 collaboration brad frost design system webdev community future web design Ideas/What We’re Reading https://bigmedium.com/ideas/a-global-design-system.html https://shoptalkshow.com/601/ https://bigmedium.com/speaking/is-atomic-design-dead.html A Little Big Medium <div class="bmw_pageContent"> <p>Love email? Neither do we! But we really, really, really love sharing and receiving genuinely helpful perspectives and resources that help everyone do their work better.</p> <p>That’s what we deliver in Big Medium’s occasional email newsletter “A Little Big Medium”: practical insights to help complex organizations design for what’s next—and do it at scale.</p> <p>So what will you get? Lots of signal, no noise; the newsletter is certified spam-free. Sign up to receive links to Big Medium&#8217;s <a href="/ideas/">latest ideas</a>, case studies of <a href="/projects/">recent projects</a>, and, sure, hot takes on process, technique, and technology from <a href="/about/">the industry&#8217;s best</a>.</p> <p>Sound good? Let&#8217;s go! Sign up here:</p> <div id="mc_embed_shell" class="moreinfo bmc_mailchimp"> <div id="mc_embed_signup" class="bmc_external_link"> <form action="https://bigmedium.us5.list-manage.com/subscribe/post?u=6c0c3f4dcd40d88bc1cedb3fa&amp;id=7540015453&amp;f_id=00d6c4eaf0" method="post" id="mc-embedded-subscribe-form" name="mc-embedded-subscribe-form" class="validate" target="_blank"> <div id="mc_embed_signup_scroll"> <div class="mc-field-group"><label for="mce-EMAIL">Email Address</label><input type="email" name="EMAIL" class="required email" id="mce-EMAIL" required="" value=""></div> <div id="mce-responses" class="clear"> <div class="response" id="mce-error-response" style="display: none;"></div> <div class="response" id="mce-success-response" style="display: none;"></div> </div><div aria-hidden="true" style="position: absolute; left: -5000px;"><input type="text" name="b_6c0c3f4dcd40d88bc1cedb3fa_7540015453" tabindex="-1" value=""></div><div class="clear"><input type="submit" class="btn" name="subscribe" id="mc-embedded-subscribe" class="button" value="Subscribe"></div> </div> </form> </div> <script type="text/javascript" src="//s3.amazonaws.com/downloads.mailchimp.com/js/mc-validate.js"></script><script type="text/javascript">(function($) {window.fnames = new Array(); window.ftypes = new Array();fnames[0]='EMAIL';ftypes[0]='email';fnames[1]='FNAME';ftypes[1]='text';fnames[2]='LNAME';ftypes[2]='text';fnames[4]='COMPANY';ftypes[4]='text';fnames[5]='PHONE';ftypes[5]='phone';}(jQuery));var $mcj = jQuery.noConflict(true);</script> </div> </div> <!-- end bmw_pageContent --> Fri, 02 Feb 2024 20:35:00 UT https://bigmedium.com/ideas/big-medium-newsletter.html df0b8e57cad9b3877b27ea0e81b70903-1620 newsletter Ideas Do More with Less: Digital Leadership in Lean Times <div class="bmw_pageContent"> <p>Nothing concentrates the mind like tough times. Adversity invites you to return to fundamental priorities. With the right response, you can turn crisis to opportunity, setting yourself up for success well beyond the current storm. Tough times are an opportunity to get your head right.</p> <p>The digital industry is in one of those moments. Waves of layoffs have washed over the tech giants in the past several months after years of exuberant hiring. Traditional firms have pulled back on digital investment, shelving projects that are deemed non-essential. Despite signs that the US economy is growing and that interest rates will relent, companies are easing into the year with conservatism. Lean budgets are the order of the day, and execs are obliged to turn a gimlet eye to how well their digital teams and initiatives are performing.</p> <p>If there’s a silver lining here, it’s that there’s fresh urgency for the important—a focus on what should have been in focus all along. For digital leaders, the top focus has to be nurturing a high-performing digital organization. If there’s investment to be made, it must be here. Savings and profit will both follow many times over. </p> <blockquote class="pullquote media-center"> For digital leaders, the top focus has to be nurturing a high-performing digital organization. </blockquote> <p><strong>By “high performing,” I mean “doing more with less.”</strong> Become an organization that can realize the elusive trifecta of faster/better/cheaper while delivering exceptional digital experiences. The goal is hardly novel, but it’s surprising how rarely it’s an actual priority. Big Medium works with the world’s biggest companies—organizations that have the potential to realize huge economies of scale. Too often, though, their size only magnifies each company’s particular dysfunctions. We guide our clients to develop healthy processes and organizational strategy to be their best selves—to be that high-performing digital team.</p> <p>Economic uncertainty is an invitation for companies to do just that, to become their best selves. So while this essay may be framed as “digital leadership in lean times,” it’s more truly a call to return to the touchstones of responsible digital leadership. As a leader, how do you focus on what is really valuable to both the company and its customers, and how do you set up your team to deliver that value? How do you tell your group’s story in a way that reinforces your ability to do new and useful things with technology?</p> <p>Before jumping into it, here’s a preview of the key principles I’ll cover for leading and nurturing your “do more with less” high-performing team:</p> <ol> <li><a href="#earn-your-keep">Earn your keep</a></li> <li><a href="#rally-around-delivery">Rally around delivery</a></li> <li><a href="#enlist-the-robots">Enlist the robots</a></li> <li><a href="#bust-silos">Bust silos</a></li> <li><a href="#mind-your-vendors">Mind your vendors</a></li> <li><a href="#build-institutional-knowledge">Build institutional knowledge and promote radical reuse</a></li> <li><a href="#innovate-within-constraints">Innovate within constraints</a></li> <li><a href="#set-the-vision">Set the vision</a></li> <li><a href="#lean-into-kindness-and-safety">Lean into kindness and safety</a></li> </ol> <h3 id="earn-your-keep">1. Earn your keep</h3> <p>First, let’s be straight about the cold calculus of your business goals: you must make or save money for the company. If your team contributes to making/saving more money than it spends—and if it can do that with a bigger margin than competing initiatives—then you earn your keep and win the budget. The more direct the connection to making/saving money, the better. It’s important that this connection be explicit in the story that you tell internally about the work—and understood by the teams doing that work.</p> <h4 id="makemoney">Make money</h4> <p>Digital organizations make money by launching successful products or marketing vehicles—and by keeping/retaining customers through feature updates and bug fixes. Shipping and supporting these products is typically the focus for in-house teams, so chances are, you already have a handle on the research, design, and development of good products that are core to your business. The metrics to measure and the desired outcomes are generally clear and understood. But things tend to get messy in the other category…</p> <h4 id="savemoney">Save money</h4> <p>You save money by developing processes or platforms that help get things done faster, with fewer resources, or with less reliance on outside vendors. There’s often lots of untapped opportunity here, because digital organizations often contend with lots of inefficiencies—especially in large and complex organizations. That’s where teams encounter the friction and inefficiencies of siloed bureaucracy, politics, and poor visibility. There’s lots to be done, but it means fighting the tide of corporate scale. This is the realm of slow decisions, reinvented wheels, waterfall handoffs, and inconsistent solutions.</p> <p><strong>Saving money by reducing friction and creating new efficiencies is the big opportunity to move the needle for most digital organizations.</strong> Do more with less: make more money while spending the least money, time, and resources possible. You can spot high-performing teams by their speedy, low-friction, collaborative process—complete with supporting tools and platforms—for designing and delivering digital products.</p> <blockquote class="pullquote media-center"> Saving money by reducing friction and creating new efficiencies is the big opportunity to move the needle for most digital organizations. </blockquote> <p>The trick is that investing in projects that will save money often looks at first glance like pouring funds into an operational cost center. Hiring folks to improve process can be misunderstood as adding a layer of middle management that doesn’t directly contribute to shipping product. Building a well-considered, effective design system can be misconstrued as a costly convenience for internal teams, a distraction from building actual applications. (I’ll address the very real benefits of investing in these things later.)</p> <p>To avoid this false impression, commit fully to these efficiency-building efforts by plugging them immediately into roadmap projects so that you can prove (or disprove) their value right away. For example, apply new process improvements to the scrum teams working on the latest project. Or use that project to build your design system by introducing component-driven design/development and then extracting the foundational components for the system from that project.</p> <p>When Big Medium helps client companies build money-saving design systems, for example, we tuck in with production teams working on strategically important roadmap projects. We help them accelerate those projects with new design/development process—and end up with a bouncing baby design system on the other end. The efficiencies and savings from that design system snowball as it continues to be used and evolved in follow-on projects.</p> <p>Working this way lets you realize the value of the effort immediately, and contribute directly and materially to money-<em>making</em> projects at the same time that you’re developing your money-<em>saving</em> efforts. But just as important, it also helps you justify the expense of these initiatives by leaning into this important fact of corporate finance:</p> <h4 id="yourcfolovesacapitalexpenditure">Your CFO loves a capital expenditure</h4> <p>I bet you didn’t see this coming, but we’re going to take a brief detour into the intoxicating realm of… accounting. How your project is categorized by the finance department affects how it affects the company’s bottom line—and how profitable or costly your group is perceived to be.</p> <p>It takes money to design and build a website, application, or platform. If that expense is charged as an operational expense (“OpEx” in the lingo), then the full cost dings the company’s bottom line for the year. However, if it’s considered a capital expense (“CapEx”), then on the books, the cost can instead be spread out over the product’s useful lifespan—typically three to five years.</p> <p>A simple example: A company spends $1 million to deliver a software product. If it’s categorized as OpEx, then the company books a $1 million expense before it’s able to realize any revenue—your project just cost the company a ton of money this year with no income to show for it yet. If it’s categorized as CapEx, however, then the accountants view the software product as a $1 million asset with a five-year lifespan. The $1 million expense to build it can be amortized over five years ($200,000 per year). So the balance sheet for the first year shows a $1 million asset with $200,000 expenses—an increase of $800,000 in the company’s net worth for the year, instead of a $1 million expense.</p> <p><em>What is this witchcraft?</em> CapEx means “investment.” It applies to the purchase or creation of assets that will deliver value over time: buildings, machinery… and software. Capitalization is an accounting method that spreads out the cost of the asset over its useful lifespan. Even though the company lays out the cash all at once, it looks on paper like a payment plan. The reasoning is that it aligns the expense of a revenue-producing product with the timing when it’s actually expected to generate that revenue—a more accurate reflection of an asset’s financial performance. The end result: capitalization improves financial statements, enhances the balance sheet, and unlocks tax savings that can free up money for further investment and operations.</p> <aside class="aside media-right"> <p><strong>Caveat: The Magic Dissipates</strong></p> <p>Every year, the value of the software asset decreases on the balance sheet (the $1 million asset is worth $800,000 the next year, $600,000 in the year after that, and so on). And the amortized expense hits the income statement every year, too. So CapEx accounting is only effective over the long haul if the software actually delivers revenue that matches or exceeds its original expense. Otherwise, wave after wave of amortized expenses will drag the whole thing down like a house of cards.</p> </aside> <p><strong>Position your work as asset creation, not operational expense.</strong> This is not only better accounting, but better storytelling: “we’re creating value, not a cost center.” It means that the company understands your digital organization as a builder of enduring, profit-generating machinery. The design system you build for savings and efficiency becomes more than an operational artifact: it is a platform. It is critical front-end infrastructure and a financial asset of enduring value.</p> <p>Here’s the catch: to qualify as CapEx, expenses have to be direct contributors to the creation of revenue-generating software—building new products or adding new features. For digital products, this includes UI design, application development, QA, and some content creation, but it <em>does not</em> include requirements gathering, research, maintenance, bug fixes, modernization, or training, all of which are all considered operating expenses. (<a href="https://www.iasplus.com/en/standards/sic/sic-32">Here are the rules for websites.</a>)</p> <p>So don’t get it twisted. We still need to spend on OpEx efforts that reduce technical debt and keep these beautiful CapEx projects running well and delivering profit. Likewise, we need to be smart about funding research and building good requirements that will ensure the products deliver the expected revenue. But don’t miss any opportunity to frame (and fund) the work that you do as value-building capital assets. It’s not only savvy and timely, it’s also true.</p> <blockquote class="pullquote media-center"> Don’t miss any opportunity to frame (and fund) the work that you do as value-building capital assets. It’s not only savvy and timely, it’s also true. </blockquote> <h4 id="choosemetricsthatmatter">Choose metrics that matter</h4> <p>This has to be more than storytelling. You have to demonstrate the value your team is creating, and that means gathering and sharing the right measurements. Too many teams get swept up in measuring the wrong thing, if they bother to measure at all.</p> <p>Many design system teams, for example, try to measure the success of the system by tracking how many projects have adopted it, or how complete its component coverage is. Neither is directly relevant to the bottom line. A better measure is how much money the system is saving by reducing design, development, and maintenance time: how much faster (or with how many fewer resources) can you build/maintain a project that uses the system, versus one that does not? That’s the stuff that will keep the lights on for your design system team.</p> <p>All of this is about having your financial story straight for how you’re delivering value to the business. <strong>This is your first priority: get clear on how you’ll make/save money, justify your work as capital expenditure, and understand how to prove its value with the right metrics.</strong></p> <p>This asset-building mindset also establishes an important cultural and process imperative for digital organizations, which brings us to the next principle for digital leadership in lean times.</p> <h3 id="rally-around-delivery">2. Rally around delivery</h3> <p>Everyone on the team has to understand that their job is all about actually shipping a great product. In digital design and development, it’s all too easy to get precious about the things we make along the way. I’ve certainly been guilty of this, confusing the output of my individual contribution as my end goal. And so we convince ourselves that the wireframes we build have to be exhaustive. The Figma file must be perfect in every high-fidelity detail. The design system library has to have complete coverage and be “pure” from a system perspective. We treat our work as if it’s the product itself.</p> <p>In the end, none of those artifacts matter. <strong>The only thing that’s important is what actually gets delivered to customers—and what happens next.</strong> That’s where the value of your digital organization is realized. Everything else along the way is a stepping stone that will be discarded after the next phase is complete. Recognize that requirements, wireframes, designs, and prototypes are disposable—and treat them accordingly.</p> <h4 id="documentlessshipfaster">Document less, ship faster</h4> <p>Doing more with less means reducing the time and energy spent on these ephemeral artifacts, so that you can ship faster and realize product benefits as quickly as possible. At each stage, figure out what you need to do to understand with confidence what the next step toward delivery should be. Invest precisely that effort and no more. <a href="https://bigmedium.com/ideas/mvp-does-not-mean-what-you-think-it-means.html">That’s the real meaning and value of the much-misunderstood MVP process.</a></p> <blockquote class="pullquote media-center"> Figure out what you need to do to understand with confidence what the next step toward delivery should be. Invest precisely that effort and no more. </blockquote> <p>This doesn’t mean cutting corners. This doesn’t mean avoiding appropriate thinking and exploration. This doesn’t mean that design is unimportant. It simply means that we should not treat every phase of planning, design, and development with the same polish that the shipping product needs to have. Instead, let’s recognize when further design work has diminishing returns and ask instead how we can push production downstream into code as soon as possible.</p> <p>I discuss this approach and its implication in more detail in my essay <a href="https://bigmedium.com/ideas/only-one-deliverable-matters.html">Only One Deliverable Matters</a>. The gist is: document only what’s necessary to communicate what needs to be done next, and figure out how/where you can express that work most efficiently. The essay stakes out these core principles:</p> <blockquote> <ol> <li>Words, not wireframes</li> <li>Skip the wireframe, sketch mobile UI</li> <li>Push the point of production downstream</li> <li>Code commits instead of redlines</li> <li>Cultivate trust outside of documentation</li> <li>The product is the common workspace, and vice versa</li> </ol> </blockquote> <p>If you’re not already working this way, it will feel… uncomfortable… when you first adopt it. Hiring folks who bring this mindset can help shepherd the process and realize the associated savings. Product owners, design directors, delivery managers, and project managers are all influential roles here. Outside consultants can also help.</p> <p>At Big Medium, for example, we help our client companies work in this way. Doing so lets you ship faster—and it creates a common sense of purpose and collaboration among disciplines. Instead of tossing highly polished documentation over the wall waterfall-style, you’re instead having conversations to ask your colleagues, “what do you need from me in order to know what to do next?” It’s almost always less than you think it needs to be. Do more by doing less.</p> <h3 id="enlist-the-robots">3. Enlist the robots</h3> <p>As you revisit <em>what</em> needs to be done, also ask <em>how</em>—and whether it can be automated. The recent sudden breakthroughs and broad availability of generative AI in particular mean that our new robot friends are becoming important teammates in digital organizations.</p> <p>At Big Medium, we’ve begun helping our clients use AI to do production work for design and development. We’re setting up private, secure systems that use large language models (LLMs) to deliver high-quality results in seconds instead of the hours or days of our human colleagues. Some examples that we’re delivering right now:</p> <ul> <li>Writing production-ready code for design system components across multiple web frameworks (React, Web Components, Vue, etc) in the organization’s house style</li> <li>Assessing and delivering recommendations on the quality and accessibility of designs and front-end code</li> <li>Writing and communicating design system documentation (UX guidelines, developer docs, tutorials) in a context- and audience-specific manner</li> <li>Writing automated tests for code libraries</li> <li>Writing pull requests and changelogs, including high-level summaries of their impact—including breaking changes and the migration path for developers</li> </ul> <p>We’ve got all of that working today, and we’re teaching our clients to do it, too. Still to come: we’re working on teaching the robots to read and write Figma files to create designs based on communicated requirements, to identify gaps between design and code, and to deliver useful code based on the designs.</p> <p><strong>Digital leaders and their teams can’t afford to ignore this.</strong> This is the time to learn, adopt, and invest in this kind of automation and how to manage it. These are early days, but it’s clear that this is where the industry is headed—and quickly. The tools and methods are available now, and improving steadily.</p> <p>This is at once great news and deeply unsettling. Broad swaths of digital production are fast becoming automated commodity work. The business implication is that we can realize the value of digital products much faster and at lower cost—terrific! But the professional implications at the personal, organizational, and societal levels are profound. This is a sea change in how work gets done and by whom (or by what).</p> <p>This is a big topic and more than can be shoehorned into this essay, but: as you begin to introduce your inevitable robot workforce, anticipate necessary shifts in roles and responsibilities. The technical aspect of human work will shift to training and maintaining the robots and their models, writing prompts based on clear requirements, and reviewing the design/code output. Done right, this relieves us of nitty-gritty, error-prone, and repetitive production work and frees us to do higher-order thinking, posing new questions that solve bigger problems.</p> <p>This means our teams will eventually engage in more human inquiry and less technical implementation: more emphasis on research, requirements, and outcomes and less emphasis on specific outputs. <strong>In other words, teams will focus more on the right thing to do—and less on how to do it. The robots will take care of the how.</strong></p> <p>In that context, human relationships and shared vision within your digital organization become even more important. Divvying people up by technical specialty may become more of a hindrance than a help as the robots take on more of the technical work. That brings us to the next principle.</p> <h3 id="bust-silos">4. Bust silos</h3> <p>Another way to think about rallying around delivery is that you’re blurring the lines between production stages, so that the whole team is involved, informed, and invested throughout the process. This means busting the silos that isolate disciplines.</p> <p>Painful design-to-development handoffs disappear, for example, when you decide <em>we will no longer have formal handoffs</em>. Instead, pull developers back into the design process, and push designers forward into the development process. This is what happens when you prioritize pushing production downstream into code as soon as possible. It’s also easier said than done. That’s because it intentionally blends roles/responsibilities across production stages, introducing a degree of ambiguity into your delivery process. But it also bolsters the agency of the production team and its individual contributors. It empowers the team to focus on what’s needed across disciplines <em>for this feature right now</em> in order to ship faster.</p> <blockquote class="pullquote media-center"> Painful design-to-development handoffs disappear when you decide <em>we will no longer have formal handoffs</em>. </blockquote> <p><strong>Done right, busting silos improves both the speed and quality of delivery, with fewer surprises.</strong> You know it’s working when you see a decline in adversarial relationships between disciplines. By contrast, it’s a danger signal when you see frayed working relationships and lack of trust simmering between designers and developers, for example. That frustration represents a ton of wasted time and energy. You have to resolve it to stop burning money.</p> <h4 id="isyourorgchartbroken">Is your org chart broken?</h4> <p>Improvements in process and personal relationships can go a long way there, but friction between disciplines is often seeded by structural issues in the organization. When a company dumps design, development, product, and marketing into completely different departments, these groups inevitably have different incentives, goals, and cultures. The structure alone threatens to turn these teams into disdainful competitors instead of supporters of a common mission.</p> <p><strong>High-performing digital organizations have cross-discipline production teams that share responsibility for shipping great features.</strong> At Big Medium, we’ve helped clients establish a variety of different reporting relationships to manage the individual contributors in those teams (designers versus developers versus product managers etc). There’s no single best org chart for high-performing teams, but there is a common factor: the reporting relationships merge not far above the production team itself.</p> <p>To rally around product delivery, you have to have common leadership to do the rallying. The closer that shared leadership is to the teams doing the work, the more effective it will be. When reporting relationships for distinct disciplines don’t merge until they hit the C-suite, that’s especially fertile territory for dysfunction. The silos are way too tall for collaboration to be effective, and a reorganization is almost certainly necessary.</p> <h3 id="mind-your-vendors">5. Mind your vendors</h3> <p>Agencies and other vendors are their own silos. Although hired to accomplish specific outcomes for the business, these third-party companies have their own management structures and incentives, which can diverge in ways large or small from the interests of their clients. This divergence is made worse when you have multiple vendors working on the same projects, making coordination challenging and responsibilities murky. Streamlining your agency roster delivers cost savings, eliminates duplicate work, reduces management overhead, and lets you focus on the healthiest business partnerships.</p> <p>I lead an agency. I’m a fan of agencies. Agencies and contractors play an important role in lean times, filling gaps when companies can’t risk full-time hires. But those same lean times oblige digital leaders to ask: where are my agencies taking me and to what end? Are they the right partners for the moment? </p> <p>Many agencies are keen to create long-term dependencies and get as many heads in the door for as long as possible. That’s the whole business model. Their DNA rejects getting projects done in the leanest way, which means that these agencies are at cross purposes with their clients’ interests, at least in that particular sense.</p> <p>At Big Medium, our goal is to enable meaningful change—in product, in process, in culture, in technique—and then step aside. We purposely avoid making our clients dependent on us in the long term. Instead, we want to empower them by teaching them what we know, making our knowledge their knowledge. We don’t create superfluous deliverables to boost our billing. We’ve done a lot of work to design a business that aligns our goals with those of our clients, and our clients tell us we leave them more effective, happier, transformed. That’s a healthy partnership. The question to ask: can you say the same of all of your vendors?</p> <blockquote class="pullquote media-center"> Lean times oblige digital leaders to ask: where are my agencies taking me and to what end? Are they the right partners for the moment? </blockquote> <p>Find your trusted partners, the ones that line up with your own goals and incentives, and streamline to them. If you discover that this leaves you empty-handed, then it’s time to find new partners better suited to the challenges you’re facing today and tomorrow. On the other hand, if your agency roster is still stacked, consider trimming the long tail of vendors who don’t offer unique value or services. Having multiple agencies who solve the same problems in the same way does you no good. It only costs you time, money, and attention to coordinate all the companies doing the exact same work. Consolidate to the difference makers.</p> <p><strong>Be careful not to confuse difference makers with those who introduce change for change’s sake. Innovation and novelty are not the same thing.</strong> Many agencies, especially design agencies, understand their job to be to create something new and novel and dazzling. Nothing is inherently wrong with those things, and sometimes that’s what the moment warrants. But too often the pursuit of novelty abandons valuable foundations. Too many agencies deliver product designs that ignore a company’s existing design system or standards, without creating an alternative. They create solutions that don’t show consideration for what’s come before or what will come next.</p> <p>Circumstances sometimes call for dramatic change. I am not calling for incrementalism. But as you work on innovative projects with your agency vendors, ask yourself how the new thing you’re creating can capitalize on what you’ve already built. If you’re walking away from that, do it with clear eyes about what you’re gaining and what you’re giving up—and what will replace it. Otherwise your shiny new project risks becoming a money pit.</p> <p>Novelty is not innovation. Continuity is not stagnation. In fact, there’s a lot to be said for building upon what you’ve already got.</p> <h3 id="build-institutional-knowledge">6. Build institutional knowledge and promote radical reuse</h3> <p>High-performing teams figure out the right thing to do faster than other teams. That’s not because they’re more clever; it’s because they have good habits. In particular, they quickly identify “our team’s way” to do the thing at hand, and they have the assets, routines, and culture to stay in sync with each other and with other teams.</p> <p>On the other hand, teams introduce friction (and delays and re-work) when individual contributors are never clear on the settled solution for a specific problem—and don’t know where to turn. When that’s the case, institutional knowledge, such as it is, is locked up in the heads of longtime employees. Knowledge is conveyed via direct message, which requires knowing who to ask. Onboarding is painful as new team members don’t have easy access to the basic knowledge to do their job.</p> <p>When there’s no clear “our way,” designers and developers burn lots of time and energy to find answers. And when they can’t find them, they wind up reinventing the wheel by solving a problem that’s already been solved… somewhere. Quality, consistency, and velocity all take a hit. Design and technical debt abound.</p> <p>This is the whole reason for design systems, of course. They are repositories of institutional knowledge—<a href="https://bigmedium.com/ideas/boring-design-systems.html">libraries of solved problems</a>. They’re all about encouraging radical reuse through the principles of <a href="https://atomicdesign.bradfrost.com">Atomic Design</a>, the methodology created by Big Medium’s <a href="https://bigmedium.com/about/brad-frost.html">Brad Frost</a>. Done right, design systems provide a single source of truth with common language, clear guidelines, and grab-and-go elements for designers and developers.</p> <p><strong>In lean times, developing a mature design system has to be an area of focus and investment.</strong> It pays off quickly in stanching redundant work, wasted time, and poor-quality design &amp; development. Creating design and code libraries for common patterns has become table stakes for a healthy digital organization.</p> <p>It’s also not enough. High-performing teams have design systems, but having a design system won’t make you a high-performing team. What makes the difference is how you operationalize that system to fit naturally into the everyday workflow and practice of teams and individual contributors. That is the real work: establishing the processes to use, govern, and contribute to those systems in ways that elevate the team and deliver bottom-line value in shipping product. </p> <blockquote class="pullquote media-center"> High-performing teams have design systems, but having a design system won’t make you a high-performing team. </blockquote> <p><strong>This effort requires committed leadership—especially for large, siloed organizations that tend to favor local solutions.</strong> In our work with big companies, we often see similar-but-different design systems spring up in different pockets of the company. Companies bring in Big Medium to bridge the gap, unify systems, and help teams work together. The fact that this is happening in the first place, though, is a sign of teams trying to create institutional knowledge and radical reuse within their spheres of influence—but their effort to reduce duplicative work is only duplicating the work of others elsewhere in the organization. </p> <p>That’s a signal that design system work is no longer a team issue. It’s a leadership issue that demands silo-busting and collaboration organization-wide. The result sweeps away ambiguity for common use cases. Getting the design system implementation right means teams can spend less time on reinventing old boring solutions and more on solving new problems. Speaking of new solutions&#8230;</p> <h3 id="innovate-within-constraints">7. Innovate within constraints</h3> <p>When you consolidate what you already know how to do, you create time, energy, and resources for exploring the new. That’s how companies make space for innovation projects in lean times, and it’s what we’re seeing right now.</p> <p>Confronted by flat or shrinking budgets, high-performing teams are deploying all the efficiencies described above in order to protect space for exploring new technologies and opportunities—especially AI. “There is a reallocation of resources from noncore areas to projects such as AI rather than hiring new people,” <a href="https://www.wsj.com/tech/techs-new-normal-microcuts-over-growth-at-all-costs-b80bb18b?st=0x4bl7wy5x6jxqz&amp;reflink=desktopwebshare_permalink">the Wall Street Journal reports.</a> Another <a href="https://www.wsj.com/articles/facing-tight-budgets-in-2024-cios-seek-wiggle-room-for-tech-investments-81c113c1?st=xgpxbt8i8hwhfly&amp;reflink=desktopwebshare_permalink">Journal report</a> surveyed CIOs and found that “while their budgets for the new year remain flat, they’re under pressure to deliver new innovations, especially using generative AI. Getting the cash for that means that the cost-control priorities of 2023—from reducing cloud usage and consolidating vendors to negotiating discounts and leaning on automation—will remain in effect into 2024, they said.”</p> <blockquote class="pullquote media-center"> “Doing more with less” also means doing <em>new</em> with less. </blockquote> <p>“Doing more with less” also means doing <em>new</em> with less. When there’s no contingency budget for failed projects, you’re asked to reduce risk even as you chase big results.</p> <p><strong>Choose innovation projects with care, selecting the ones most likely to return high value, with limited risk. </strong> At Big Medium, for example, we’re helping clients adopt AI in the service of delivering roadmap projects. Our client teams develop new skills and explore new features without the risk of giant moonshot projects.</p> <p>This approach transforms AI from daunting next-generation technology into a practice of <a href="https://bigmedium.com/ideas/links/making-software-with-casual-intelligence.html">making software with casual intelligence</a>. (Designing for casual uses of AI has been a focus of ours for several years now; <a href="https://www.youtube.com/watch?v=Tgzu351uDIc&amp;t=638s">here are some examples</a> from my 2019 talk, <a href="https://bigmedium.com/speaking/ai-is-your-new-design-material.html">AI Is Your New Design Material</a>.)</p> <p>From there, as your team’s skills grow in pace with demonstrated product benefits, innovation efforts can become bolder. That’s the maturity path we’re following, for example, when Big Medium helps companies use AI to write production code, as described earlier—moving from using AI-supported <em>features</em> to AI-produced <em>applications</em>.</p> <p>Here are a few key concepts as you follow this trajectory with tight resources:</p> <ul> <li><strong>Keep innovation projects rolling even in lean times—but grow those features in step with the growth of your skillset, and vice versa.</strong> If you don’t have the skillsets you need, hire those skills—or hire a consultant like Big Medium to help you get them.</li> <li><strong>Prefer lots of little bets to one giant bet.</strong> Don’t send a team into an “innovation cave” to disappear for a year in hopes that they come back with a company-saving product. Instead, do lots of experiments as targeted product interventions, measure the results of each, and then based on those results, decide what the next intervention will be. Over your time, your “small” experiments will get bigger. <a href="https://bigmedium.com/ideas/mvp-does-not-mean-what-you-think-it-means.html">(This, again, is what MVPs are intended to be and do.)</a></li> <li><strong>Mind the difference between innovators and implementers.</strong> The people who dream up or demonstrate the new idea aren’t always the best ones to take it forward—and often don’t want to be. Inventing and operationalizing are different tasks, often best handled by different people or teams. In lean times, make sure you have the right people in their best place.</li> </ul> <h3 id="set-the-vision">8. Set the vision</h3> <p>Where does all of this effort and innovation take you? Where are you headed? Much of what I’ve covered so far has focused on the management and operational considerations of nurturing a high-performing team. But once you’ve got this team zipping along like a sleek and nimble jet, where will you fly together? Building, fueling, and flying the jet are all different from imagining its destination—and persuading people to come along.</p> <p>That’s vision, and a leader isn’t a leader without a vision. Vision provides the “why” for all the “how” and “what” that occupy everyone’s day to day. This is the flag that you plant in the distance to orient your team, to show them where you’re leading them, and to what end.</p> <blockquote class="pullquote media-center"> Vision provides the “why” for all the “how” and “what” that occupy everyone’s day to day. </blockquote> <p><a href="https://www.petermerholz.com/blog/to-lead-design-you-must-have-an-agenda/">Peter Merholz shares a good example</a> from Kaaren Hanson, chief design officer at Chase Bank. Kaaren had four near-term initiatives—each similar to the principles I’ve described so far—all of them focused on making her team more effective: build a senior team, nurture executive relationships, establish UX metrics, and evolve product development processes. These initiatives were concrete goals intended to serve as stepping stones to the long-term vision that Kaaren staked out: to create “one freaking experience”—a seamless, coherent, and consolidated way to navigate all the bank’s many-faceted services. The near-term initiatives were all in service of that longer-term vision.</p> <p>The vision—“one freaking experience”—is so simply stated, yet it’s brimming with implicit value for both the business and its customer. It’s a simple container that contains tons of complexity, suggests many stages, and prompts lots of inquiry, yet also provides clear directional orientation. It describes to Kaaren’s team of 800+ people why they’re doing their work. It is the desired eventual meta-outcome for the team.</p> <p>Naming the simple “why” is important for several reasons: the vision provides mission and clarity for your team; it provides a strong organizing principle that guides you to make clear and deliberate decisions as a leader; and it takes us all the way back to our first principle, “earn your keep,” to tell the story of how your team provides <em>real and meaningful value</em> to both company and customer.</p> <p>I want to highlight the word “meaningful” for a moment. One of the common <a href="https://hbr.org/2023/08/what-makes-some-teams-high-performing">characteristics of high-performing teams</a> is a culture motivated by a strong sense of purpose and meaning—specifically work that benefits others. David Burkus writes:</p> <blockquote> <p>More and more people desire to do work that benefits others. Knowing the reason behind their work’s importance isn’t enough — employees also want to know <a href="https://www.ted.com/talks/david_burkus_the_simple_way_to_inspire_your_team">who their work is serving</a>. One <a href="https://doi.org/10.1037/0021-9010.93.1.108">study</a> even indicated that when people hear stories about how their colleagues’ work benefits others, they become more motivated to engage in helpful actions. This suggests that when people hear how their work is positively affecting others, they’re more likely to set their own goals and desires aside and focus on the needs and objectives of the team.</p> </blockquote> <p>What’s your vision for your team? How does that vision benefit colleagues, clients, or the community? And how does your vision dovetail with undeniable business value for the company? Expressing that vision provides comforting reassurance and motivational purpose for your team—both of which are especially important in lean times.</p> <h3 id="lean-into-kindness-and-safety">9. Lean into kindness and safety</h3> <p>The importance of purpose in your team’s work is a reminder that high-performing teams are built on more than technical skill, good funding, or effective management alone. <strong>Teams that “do more with less” emerge from healthy and supportive culture.</strong></p> <blockquote class="pullquote media-center"> While it may be tempting to apply pressure to teams to wring more out of them, fear and adrenaline are not sustainable management methods. </blockquote> <p>Lean times introduce a ton of stressors—tight budgets, the threat of layoffs, changes in leadership, shifts in how we work. You may not have control over all or even any of the factors that leave your team unsettled. But you can still help your team find professional grounding in ungrounded times by fostering a culture of kindness and psychological safety. This kind of healthy culture not only boosts individual satisfaction but turns out to be the essential ingredient for effective team dynamics.</p> <p>And this may be a bit crass, but: fear is bad for business. Fear of failure, fear of losing work, fear of management, fear of speaking up—all of it hurts creativity, motivation, and team collaboration. A work culture that is adversarial, intimidating, impatient, or judgmental will not take you where you need to go, a fact that’s doubly true in tough times. While it may be tempting to apply pressure to teams to wring more out of them, fear and adrenaline are not sustainable management methods. The better thing is to encourage people to show up as their whole selves, not as robot exemplars of efficiency. Done right, the results are remarkable.</p> <p>A decade ago, <a href="https://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-its-quest-to-build-the-perfect-team.html?unlocked%5C_article%5C_code=1.N00.hJ8q.zy4ZzSdvezXl&amp;smid=url-share">Google embarked on a study called Project Aristotle</a> to study hundreds of Google’s teams and figure out why some were way more successful than others. They looked at team composition, personalities, social relationships, and management style, but no strong patterns emerged from those. Instead, the secret of high-performing squads turns not on <em>who</em> is on the team but <em>how</em> team members behave with each other. The common element: <em>team psychological safety</em>. </p> <p><a href="https://web.mit.edu/curhan/www/docs/Articles/15341_Readings/Group_Performance/Edmondson%20Psychological%20safety.pdf">The term was coined in 1999 by Harvard’s Amy Edmondson</a>: “the belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes, and that the team is safe for interpersonal risk taking.” This is a professional context where you can be confident being yourself (including your confused or uncertain self). It emerges from “a blend of trust, respect for each other&#8217;s competence, and caring about each other as people.” Project Aristotle and a bevy of other studies have found strong links between psychological safety and improvements in performance, creativity, resilience, and learning.</p> <p><strong>Leaders cultivate team psychological safety by encouraging input, replacing blame with curiosity, and perhaps most important: by offering their own vulnerability and trust to the team.</strong> The trust is offered by openly acknowledging uncertainties, failures, and even personal weaknesses. This is interpersonal risk, for sure; it runs counter to the instinct of many leaders to front a false confidence, especially in times of crisis. But offering this trust is rewarded with a culture where nobody is expected to be perfect—a place where it’s safe to admit mistakes, share half-formed ideas, and ask naive questions. Instead of being a leader who has to have all the answers, it allows you to frame questions for your team to answer—and give them confidence that they won’t be punished for trying.</p> <p><a href="https://www.nasdaq.com/articles/kindness-isnt-a-weakness.-at-work-its-your-greatest-strength">Kindness is not weakness.</a> Psychological safety is not at odds with demanding standards or industry-beating outcomes. On the contrary, psychological safety delivers those outcomes by providing the space for a constant flow of new ideas and critical thought—and the confidence to explore both. Critique and hard conversations remain critical; the difference is that the critique is always understood to be about the work, not the person. In lean times it’s especially important to be clear about expectations—and to listen when those expectations aren’t realistic.</p> <p>At Big Medium, we think a lot about how to promote this kind of healthy culture, especially since we’re constantly forming new teams by joining forces with our clients. We’re told by those same clients that we not only deliver fast, highest-caliber results, but that we’re also kind—and awfully fun to work with. (That rings true, since we look for the same in our clients.) We care about the challenges of the teams we work with—and of the people that make up those teams. We’re invested in their success and we’re interested in their ideas, both the ones that work and the ones that don’t.</p> <p>In every engagement we lean into process, habits, and norms that foster this kind of kindness and safety in our client teams. We know the engagement is working when we’re all enjoying our work together, not only the results. That makes all of us real partners at a personal level in making our client’s vision real.</p> <p>In lean times, who could ask for better friends than that?</p> <h3 id="let’sreturntofundamentals">Let’s return to fundamentals</h3> <p>Leadership is always a tough gig. The squeeze is hardest when money is tight and you’re called upon to do more with less—all while giving teams what they need to do their best work. The good news is that digital leadership in tough times is basically the same as what <em>great</em> digital leadership looks like all the time. So let’s get back to fundamentals. Focus on what delivers value, and create the circumstances for your team to get it done.</p> <p>From accounting to AI, from automation to Atomic Design, from vision to vendors, from innovation to institutional knowledge, from constraints to a culture of kindness… you have a lot of tools and methods to meet the moment.</p> <p><strong>And hey, Big Medium is here if you need help.</strong> We help complex organizations do big design, and nurturing high-performing teams is what we do. We can help your team to:</p> <ul> <li>fit AI into into your products (and production process)</li> <li>realize all the benefits of a design system</li> <li>design and build websites/applications that deliver value and earn your keep</li> <li>build the skills, process, and culture to deliver better products faster</li> <li>and much more</li> </ul> <p><a href="https://bigmedium.com/hire/">Get in touch</a>, and we’ll help you do more with less.</p> <hr /> <p><em>Is your design, development, or product organization struggling with AI, process, delivery, or roles &amp; responsibilities? Need help designing and building your next great product? We can help. Big Medium helps complex organizations do big design—building and shipping great digital products at scale. <a href="https://bigmedium.com/hire/">Get in touch to find out how.</a></em></p> </div> <!-- end bmw_pageContent --> Mon, 15 Jan 2024 23:43:42 UT https://bigmedium.com/ideas/do-more-with-less-digital-leadership-lean-times.html df0b8e57cad9b3877b27ea0e81b70903-1619 psychology process workflow design principles culture design system collaboration business motivation work leadership ai Ideas Josh Clark A Global Design System <div class="bmw_pageContent"> <aside class="aside media-right"> <p>This article was originally published at <a href="https://bradfrost.com/blog/post/a-global-design-system/">bradfrost.com</a>.</p> <p><strong>Looking for help?</strong> If you&#8217;re planning, building, or evolving an enterprise design system, that&#8217;s what we do. <a href="/hire/">Get in touch.</a></p> </aside> <p><strong>TL;DR: This is a call to action to create a Global Design System that provides the world’s web designers &amp; developers a library of common UI components. A Global Design System would improve the quality and accessibility of the world’s web experiences, save the world’s web designers and developers millions of hours, and make better use of our collective human potential.</strong></p> <p>Sounds pretty good, right? In this article, I’ll talk about our collective design system journey, the rationale for creating a Global Design System, some thoughts on how to make a Global Design System actually happen, and discuss how a Global Design System would impact the world’s web designers and developers. Let’s dig in!</p> <h3 id="ourdesignsystemsjourney">Our design systems journey</h3> <p>Once upon a time, people had to design, construct, and maintain a bespoke user interface for each and every web digital product. This was manageable when an organization’s digital landscape looked something like this:</p> <figure class="media-left bmc_image"> <a href="https://bigmedium.com/bm.pix/monolithic-website.png" rel="bm_lightbox" title="" target="_blank"><img src="https://bigmedium.com/bm.pix/monolithic-website.orig-250.png" alt="Monolithic website: an illustration showing a single large bubble labeled &quot;website&quot;" srcset="https://bigmedium.com/bm.pix/monolithic-website.orig-2000.png 2000w, https://bigmedium.com/bm.pix/monolithic-website.orig-1000.png 1000w, https://bigmedium.com/bm.pix/monolithic-website.orig-500.png 500w, https://bigmedium.com/bm.pix/monolithic-website.orig-250.png 250w" sizes="(min-width: 640px) 720px, 100vw" title="Click to enlarge" /></a> </figure> <p>But as we all know, the digital landscape has exploded into a cacophony of websites, web apps, native mobile applications, and other software applications we can collectively call “digital products.” It’s not unusual for an organization’s digital product landscape to look something like this:</p> <figure class="media-left bmc_image"> <a href="https://bigmedium.com/bm.pix/many-products.png" rel="bm_lightbox" title="" target="_blank"><img src="https://bigmedium.com/bm.pix/many-products.orig-250.png" alt="Many products: an illustration of many bubbles, each labeled &quot;product&quot;" srcset="https://bigmedium.com/bm.pix/many-products.orig-2000.png 1928w, https://bigmedium.com/bm.pix/many-products.orig-1000.png 1000w, https://bigmedium.com/bm.pix/many-products.orig-500.png 500w, https://bigmedium.com/bm.pix/many-products.orig-250.png 250w" sizes="(min-width: 640px) 720px, 100vw" title="Click to enlarge" /></a> </figure> <p><strong>Designing, building, and maintaining a bespoke user interface for each individual digital product is expensive, inefficient, and fraught.</strong> And so a chorus of voices rings out across organizations the world over: <strong>“Let’s stop reinventing the wheel! Let’s save designers and developers time and agony! Let’s promote consistency and cohesion! Let’s ship higher-quality users interfaces!”</strong> This is the rallying cry for what we have come to know as design systems. </p> <p>Over the past ~10&#8211;15 years, concepts around modular UIs have matured, technologies have been born, and tools have evolved to create a library of common user interface components that power an organization’s portfolio of digital products.</p> <figure class="media-center bmc_image"> <a href="https://bigmedium.com/bm.pix/design-system-supporting-many-products.png" rel="bm_lightbox" title="Design systems have become critical tools to help scale design across many products and teams." target="_blank"><img src="https://bigmedium.com/bm.pix/design-system-supporting-many-products.orig-250.png" alt="Design system supporting many products: illustration of a bubble labeled &quot;design system&quot; with an arrow pointing at a collection of bubbles each labeled &quot;product&quot;" srcset="https://bigmedium.com/bm.pix/design-system-supporting-many-products.orig-2000.png 2000w, https://bigmedium.com/bm.pix/design-system-supporting-many-products.orig-1000.png 1000w, https://bigmedium.com/bm.pix/design-system-supporting-many-products.orig-500.png 500w, https://bigmedium.com/bm.pix/design-system-supporting-many-products.orig-250.png 250w" sizes="(min-width: 1050px) 1050px, 100vw" title="Click to enlarge" /></a> <figcaption class="bmc_caption"> Design systems have become critical tools to help scale design across many products and teams. </figcaption> </figure> <p>With a design system in place, <strong>product teams can wield the design system’s buttons, form controls, accordions, and other common UI components in order to increase speed, improve UI quality, and free teams up to work on more worthwhile tasks</strong>. This approach has proven to be very effective, and now design systems have become a best practice employed by digital organizations of all shapes and sizes around the world. Hooray design systems!</p> <h3 id="ourduplicativepresent">Our duplicative present</h3> <p>And we all live happily ever after, right? Well, not so fast. Organization-wide design systems have eased the individual burden of designing/building (and redesigning/rebuilding ad nauseam) common solutions over and over again. But an ironic pattern emerges: every organization ends up building solutions that overlap substantially with what every other organization is building. <strong>Our efforts to reduce duplicative work at the individual level are resulting in duplicative work at the inter-organization level</strong>.</p> <figure class="media-center bmc_image"> <a href="https://bigmedium.com/bm.pix/duplicative-design-systems.png" rel="bm_lightbox" title="Our efforts to reduce duplicative work at the individual level are resulting in duplicative work at the inter-organization level." target="_blank"><img src="https://bigmedium.com/bm.pix/duplicative-design-systems.orig-250.png" alt="Duplicative design systems: illustration of many organization-specific design systems" srcset="https://bigmedium.com/bm.pix/duplicative-design-systems.orig-2000.png 2000w, https://bigmedium.com/bm.pix/duplicative-design-systems.orig-1000.png 1000w, https://bigmedium.com/bm.pix/duplicative-design-systems.orig-500.png 500w, https://bigmedium.com/bm.pix/duplicative-design-systems.orig-250.png 250w" sizes="(min-width: 1050px) 1050px, 100vw" title="Click to enlarge" /></a> <figcaption class="bmc_caption"> Our efforts to reduce duplicative work at the individual level are resulting in duplicative work at the inter-organization level. </figcaption> </figure> <p>This phenomenon is understandable: organizations are trying to bring order where they have influence. (We see this <em>within</em> organizations as well, where several production teams under the same roof build their own systems because they don’t have influence beyond their group to build an org-wide system.) But the result is the same: <strong>now we have a meta design system problem</strong>.</p> <p><strong>Right now, vast numbers of human beings are devoting their time and energy</strong> <strong>to designing, building, documenting, and maintaining the exact same set of common components.</strong> Accordions that open when a user clicks them. Accordions that — you guessed it — close when a user clicks them again. Datepickers that…pick dates. Tabs that switch panels when selected. <a href="https://bradfrost.com/blog/post/enforcing-accessibility-best-practices-with-automatically-generated-ids/">Form fields that associate labels with their respective inputs</a>. Alerts that communicate success, error, warning, and information status. Dialogs and tooltips and drawers oh my! By and large,<strong> these components are unexceptional commodities that assume the same general shape and behavior</strong> regardless of whether the design system serves a non-profit, a federal agency, a bank, a publication, an e-commerce site, a Fortune 500 enterprise, a dog salon, a startup, SaaS company, you get the picture. </p> <p>These basic UI components are tricky to get right. Looking across the World Wide Web, <a href="https://meiert.com/en/blog/html-conformance-2023/">zero of the top 100 websites use valid HTML</a>, and our collective accessibility game is abysmal. The <a href="https://webaim.org/projects/million/">WebAIM Million project</a> crawls the top million websites and reliably delivers a depressing annual report about the state of website accessibility:</p> <blockquote> <p>Across the top one million home pages, 49,991,225 distinct accessibility errors were detected—an average of 50.0 errors per page.</p> <p>—<a href="https://webaim.org/projects/million/">WebAIM Million</a></p> </blockquote> <p>While these issues can’t solely be attributed to the constant reinvention of common UI components, they certainly contribute to the problem! Historically our approach to this important issue has been to shout louder at developers to construct things with accessibility as a primary consideration, but that strategy doesn’t appear to be working.</p> <p>All of this duplicative work yields experiences that still suffer serious quality deficiencies, and there are even more wrinkles to consider. <strong>Each design system is isolated and disconnected</strong>, which means each organization is left to its own devices to ensure the library keeps up with the web’s ever-evolving best practices. Updating components to adopt new HTML elements, attributes, and techniques has so far been a manual process that is delicate and error-prone. And it’s a two-way street: there’s not a clear path for the broader web to benefit from excellent solutions and ideas that were born in org-specific systems.</p> <p>So what are we to do? Let’s return to our wise design systems rallying cry: <strong>“Let’s stop reinventing the wheel! Let’s save designers and developers time and agony! Let’s promote consistency and cohesion! Let’s ship higher-quality users interfaces!” </strong></p> <p><strong>Only now let’s redirect that rallying cry outside of any individual organizations’ walls and apply it to the world at large.</strong></p> <h3 id="aproposalforaglobaldesignsystem">A proposal for a Global Design System</h3> <blockquote> <p>When the design system is boring, it frees designers and developers to do the new stuff, to solve new problems. <strong>The design system carries the burden of the boring, so that designers and developers don’t have to.</strong></p> <p>—Josh Clark, <a href="https://bigmedium.com/ideas/boring-design-systems.html">The Most Exciting Design Systems Are Boring</a></p> </blockquote> <p>There is a massive opportunity to <strong>save the world’s designers and developers millions upon millions of hours, freeing up time and human potential</strong> to work on far more pressing problems than making an accordion open and close. </p> <p>There’s a massive opportunity to <strong>dramatically improve the accessibility, semantics, and overall quality of the world’s web experiences</strong>.</p> <p>There’s a massive opportunity to <strong>harness the collective brain power of the world’s best and brightest</strong>. </p> <p>There’s a massive opportunity for the web community <strong>to demonstrate to a volatile world what true worldwide collaboration and cooperation looks like</strong>.</p> <p>I think there’s a massive opportunity to create a Global Design System.</p> <figure class="media-center bmc_image"> <a href="https://bigmedium.com/bm.pix/global-design-system-supporting-many-systems.png" rel="bm_lightbox" title="A Global Design System would support the common elements of many design systems." target="_blank"><img src="https://bigmedium.com/bm.pix/global-design-system-supporting-many-systems.orig-250.png" alt="A Global Design System would support many design systems" srcset="https://bigmedium.com/bm.pix/global-design-system-supporting-many-systems.orig-2000.png 2000w, https://bigmedium.com/bm.pix/global-design-system-supporting-many-systems.orig-1000.png 1000w, https://bigmedium.com/bm.pix/global-design-system-supporting-many-systems.orig-500.png 500w, https://bigmedium.com/bm.pix/global-design-system-supporting-many-systems.orig-250.png 250w" sizes="(min-width: 1050px) 1050px, 100vw" title="Click to enlarge" /></a> <figcaption class="bmc_caption"> A Global Design System would support the common elements of many design systems. </figcaption> </figure> <p><strong>A Global Design System would centralize common UI components, reduce so much of this unnecessary duplication, integrate with any web-based tech stack, and create a connected vehicle for delivering front-end best practices to the world’s web experiences.</strong></p> <p>What exactly would a Global Design System look like? We’ll get to that, but first let’s talk about how it differs from a few things that already exist.</p> <h3 id="alayerontopofhtml">A layer on top of HTML</h3> <p>You might be asking, “So you’re saying we just need to add a bunch of new elements to the HTML spec?” To which my answer is “Maybe!” But also “Maybe not!” </p> <p>HTML is amazing, and provides the elemental pieces we need to make websites and apps work. I think about HTML elements and attributes as the most elemental, low-level IKEA furniture parts:</p> <figure class="media-left bmc_image"> <a href="https://bigmedium.com/bm.pix/ikea-parts.jpg" rel="bm_lightbox" title="" target="_blank"><img src="https://bigmedium.com/bm.pix/ikea-parts.orig-250.jpg" alt="Ikea parts" srcset="https://bigmedium.com/bm.pix/ikea-parts.orig-2000.jpg 1925w, https://bigmedium.com/bm.pix/ikea-parts.orig-1000.jpg 1000w, https://bigmedium.com/bm.pix/ikea-parts.orig-500.jpg 500w, https://bigmedium.com/bm.pix/ikea-parts.orig-250.jpg 250w" sizes="(min-width: 640px) 720px, 100vw" title="Click to enlarge" /></a> </figure> <p>Historically, that’s all developers have had to work with. We’d rummage around the pile and pick out the things we need to create our products. As we’ve already discussed, there’s <em>a lot</em> of room for error in this process; it’s a bit like <a href="https://knowyourmeme.com/memes/how-to-draw-an-owl">drawing the rest of the owl</a>. </p> <p>Thanks to the tireless work of browser folks and standards bodies, I think that by and large we have most HTML elements and primitives in place to make most common web user interfaces. <strong>What we need now are more prefabricated UI components</strong> that abstract away much of the close-to-the-metal HTML and give developers composed, ready-to-use modules to drop into their projects.</p> <figure class="media-left bmc_image"> <a href="https://bigmedium.com/bm.pix/modular-home.jpg" rel="bm_lightbox" title="We don’t necessarily need more HTML elements; we need more sturdy pre-fabricated components that developers can drop in with confidence." target="_blank"><img src="https://bigmedium.com/bm.pix/modular-home.orig-250.jpg" alt="Modular home being assembled at a construction site" srcset="https://bigmedium.com/bm.pix/modular-home.orig-2000.jpg 1914w, https://bigmedium.com/bm.pix/modular-home.orig-1000.jpg 1000w, https://bigmedium.com/bm.pix/modular-home.orig-500.jpg 500w, https://bigmedium.com/bm.pix/modular-home.orig-250.jpg 250w" sizes="(min-width: 640px) 720px, 100vw" title="Click to enlarge" /></a> <figcaption class="bmc_caption"> We don’t necessarily need more HTML elements; we need more sturdy pre-fabricated components that developers can drop in with confidence. </figcaption> </figure> <p>Many — or even most! — web developers shouldn’t need to understand many close-to-the-metal HTML concepts in order to make web applications function. What would it mean to centralize the markup of dozens of common components and provide those as plug-and-play solutions to <a href="https://bradfrost.com/blog/post/front-of-the-front-end-and-back-of-the-front-end-web-development/">back-of-the-front-end developers</a>? </p> <p>A Global Design System can also serve as an incubator or test kitchen for new HTML elements or properties. We see this with <a href="https://bigmedium.com/ideas/design-system-ecosystem.html#recipelayeroptional">recipes in the layered design system ecosystems</a> we encounter; great ideas born in product-specific layers can eventually be absorbed by the lower-level system. The HTML standards process is necessarily slow, deliberate, and comprehensive, so a Global Design System layer on top of HTML can pragmatically help developers get things done now while also creating a path to future inclusion in the HTML spec if applicable. </p> <h3 id="whydon’twejustuse">Why don’t we just use [third-party library]?</h3> <p>For many years, we’ve heard “Why doesn’t everyone just use [Material Design | Bootstrap | Tailwind UI | Foundation by Zurb | etc]?” After all, these tools are already constructed, tested, documented, open sourced, and put through their paces by some of the world’s largest organizations.</p> <p>This instinct makes a ton of sense! Great artists steal, and there’s a real pragmatism in reaching for existing, sturdy work. <strong>However, adopting someone else’s design system surfaces two important issues: </strong></p> <ol> <li><strong>These solutions were (understandably!) created with a specific organization’s specific goals &amp; considerations in mind</strong>. The architecture, conventions, and priorities of these libraries are tuned to the organization it serves; they don’t take into account the sheer breadth of the world’s UI use cases.</li> <li><strong>They nearly always come with a specific default aesthetic.</strong> If you adopt Material Design, for example, your products will look like Google’s products. These libraries can be configurable, which is great, but themeabilitiy has limits and often results in many teams fighting the default look-and-feel to achieve custom results. In our experience, this is where folks end up creating a big mess.</li> </ol> <p>Projects like <a href="https://headlessui.com/">Headless UI</a> and <a href="https://react-spectrum.adobe.com/react-aria/">react-aria</a> provide primitive UI components and functionality without a default look and feel. This is what we’re shooting for! We want the common structure and functionality that third-party components provide, but we often want to bring our own styles to the party. However, many of these libraries are tied to a specific technology, namely React, which limits their reach.</p> <p>So while existing libraries are great, they come with a default look and feel that have limits to their customizability. And while headless UI libraries capture the right spirit, they’re tethered to specific libraries or frameworks. <strong>What we need is a library of aesthetic-and-technology-agnostic UI components that provides sturdy semantics and functionality while also providing a ton of aesthetic flexibility.</strong></p> <h3 id="makingaglobaldesignsystemhappen">Making a Global Design System happen</h3> <p>Here’s where the rubber meets the road. What does this look like? How would all of this go down? Who would be involved? Where would this live? When should this happen?</p> <p>The answers to these questions require a lot of conversation, collaboration, and coordination amongst a diverse, yet-to-be-determined set of stakeholders. I don’t pretend to know exactly how to turn this idea into a reality, and I’d very much welcome ideas and conversation about how to make it happen! With that caveat, I’d like to share a few ideas that could be helpful.</p> <h3 id="whatwouldaglobaldesignsystembe">What would a Global Design system be?</h3> <p><strong>A Global Design System would be a common library containing common UI components currently <a href="https://open-ui.org/research/component-matrix/">found in most design systems</a></strong> (Shout out to the brilliant <a href="https://open-ui.org/">Open UI</a> project for this epic matrix!). In order to be successful, these components would need to be: </p> <ul> <li><strong>Vehicles for accessibility and other front-end best practices</strong>, creating a single source of truth for common UI components.</li> <li><strong>Easily themeable</strong> in order to match any brand or design language.</li> <li><strong>Intuitive</strong> to use, providing users with a cohesive &amp; consistent API language, sensible structure, and grokkable syntax.</li> <li><strong>Interoperable</strong> to be able to power any website or app.</li> <li><strong>Be <a href="https://web.dev/learn/design/internationalization">internationalized</a></strong> in order to account for the sheer diversity of languages, writing modes, et al. found throughout the world.</li> <li><strong>Be composable and extensible</strong> so users can modify or extend the system without having to hack things to pieces.</li> </ul> <p>Given the above principles, I think it would make sense for the Global Design System to be a library of <a href="https://developer.mozilla.org/en-US/docs/Web/API/Web_components">Web Components</a>. Web Components are part of the web platform and are interoperable (in theory at least) with any web-based tech stack. Setting aside current weirdness with Web Components (that’s a post for another day), they seem like a sensible technology choice for an initiative like this.</p> <p>Web Components for a Global Design System could look something along the lines of these examples:</p> <pre><code>&lt;w3c-text-field label=&quot;Email Address&quot; type=&quot;email&quot; required&gt; /w3c-text-field&gt; </code></pre> <pre><code>&lt;w3c-alert variant=&quot;error&quot;&gt; &lt;w3c-icon name=&quot;stop&quot; slot=&quot;icon&quot;&gt;&lt;/w3c-icon&gt; Your credit card is expired. Please update your information. &lt;/w3c-alert&gt; </code></pre> <pre><code>&lt;w3c-button-group&gt; &lt;w3c-button variant=&quot;primary&quot;&gt;Log In&lt;/w3c-button&gt; &lt;w3c-button&gt;Cancel&lt;/w3c-button&gt; &lt;/w3c-button-group&gt; </code></pre> <p>For all you literal people out there, take all of this with a grain of salt. I’m not proposing this exact syntax or structure; take this as a “for instance” gesture sketch. </p> <p>A Global Design System would exist as a standalone library of components that consumers would pull into their projects, style to match their brand/visual language, and integrate into their application’s business logic. Not only would this be far more efficient than having to design, build, test, deploy, and integrate bespoke components from scratch, a Global Design System would give teams added confidence that the components are sturdy and reliable.</p> <p>Of course it would also make sense to create a corollary UI library in Figma and other design tools that share the same API, structure, conventions, and default appearance as the Global Design System code library. And of course there would need to be solid reference documentation for this library, which would take the burden away from each and every design system team on the planet to define and describe what a freaking button is. And while we’re at it, it likely makes sense to consider native mobile and desktop operating systems as well; while these environments differ in important ways, there are also many shared conventions that a Global Design System can help define or inform.</p> <h4 id="whatwouldn’taglobaldesignsystembe">What <em>wouldn’t</em> a Global Design System be?</h4> <p>I think there are a few special callouts for what a global design system wouldn’t be. A Global Design System wouldn’t:</p> <ul> <li><strong>Provide a particular aesthetic</strong> – Think of this as a vanilla base containing only browser-default styles. People can create their own custom themes or use styles contained in <a href="https://tailwindui.com/">Tailwind</a>, <a href="https://open-props.style/">Open Props</a>, <a href="https://getbootstrap.com/">Bootstrap</a>, <a href="https://m3.material.io/">Material</a>, et al. In our experience working with scores of different design systems, common components have a shared general semantics and behavior, but are styled dramatically different. Think Global <a href="https://bradfrost.com/blog/post/creating-themeable-design-systems/">Design System + CSS Zen Garden</a>.</li> <li><strong>Be a comprehensive solution for all UI needs</strong> – It’s impossible to account for every use case on the planet. Think pragmatism and the 80/20 rule here. If the Global Design System could provide solutions for the majority of use cases for a given component, that would be a huge win! But what if you have a need to make a custom SVG starburst button that does a backflip when you click on it? That’s fine! We still have the ability to make our own special pieces of UI the old-fashioned way. This is also why a layer on top of HTML might be a better approach than extending HTML itself; HTML <em>has to</em> account for all use cases, where a Web Component library can limit itself to the most common use cases. It would be critical for the library itself to be quite conservative and focus on extremely common use cases or else it would buckle under its own weight and endless requests from the peanut gallery. Governance would be key!</li> </ul> <h3 id="who">Who</h3> <p><a href="https://bradfrost.com/blog/post/design-systems-are-for-user-interfaces/">I tend to define a design system as the official story of how an organization builds user interfaces</a>. A design system needs to be tuned for the specific digital product landscape that exists at an organization in order for it to be successful. But the organization we’re talking about here is this:</p> <figure class="media-left bmc_image"> <a href="https://bigmedium.com/bm.pix/the-blue-marble.jpg" rel="bm_lightbox" title="This is the target organization for the Global Design System." target="_blank"><img src="https://bigmedium.com/bm.pix/the-blue-marble.orig-250.jpg" alt="Earth: The &quot;blue marble&quot; photograph" srcset="https://bigmedium.com/bm.pix/the-blue-marble.orig-2000.jpg 1280w, https://bigmedium.com/bm.pix/the-blue-marble.orig-1000.jpg 1000w, https://bigmedium.com/bm.pix/the-blue-marble.orig-500.jpg 500w, https://bigmedium.com/bm.pix/the-blue-marble.orig-250.jpg 250w" sizes="(min-width: 640px) 720px, 100vw" title="Click to enlarge" /></a> <figcaption class="bmc_caption"> This is the target organization for the Global Design System. </figcaption> </figure> <p>Because of the global nature of this effort, it couldn’t be owned by a specific corporation. With that said, it seems like it would make sense for huge tech companies to sponsor and fund an effort like this! </p> <p>From my perspective, an organization like the <a href="https://www.w3.org/">W3C</a> would be the best home for something like this. Their mission is pretty hand-in-glove with this whole idea:</p> <blockquote> <p>The World Wide Web Consortium (W3C) develops <a href="https://www.w3.org/standards/">standards and guidelines</a> to help everyone build a web based on the principles of <a href="https://www.w3.org/mission/accessibility/">accessibility</a>, <a href="https://www.w3.org/mission/internationalization/">internationalization</a>, <a href="https://www.w3.org/mission/privacy/">privacy</a> and <a href="https://www.w3.org/mission/security/">security</a>.</p> </blockquote> <p>It’s also worth mentioning the amazing <a href="https://open-ui.org/">Open UI</a> project, which has been doing a lot of the hard legwork on rounding up <a href="https://open-ui.org/research/component-matrix/">common UI components</a> across many <a href="https://open-ui.org/design-systems/">popular design systems</a>. And I have no doubt there are many other organizations, projects, and people from the design system community who would love to participate in an effort like this.</p> <h3 id="where">Where</h3> <p>A Global Design System would need to consist of a set of assets that include:</p> <ul> <li><strong>A code repository</strong> containing the source code for the Web Components</li> <li>Any necessary <strong>code packages</strong> (npm, yarn, composer) to deliver the Web Components to any environment. (Note: reliance on JS, packages, etc is something to address in order to create components that can be easily used by any web environment. <a href="https://lea.verou.me/blog/2020/09/the-failed-promise-of-web-components/">This post by Lea Verou</a> captures how the modern landscape creates barriers for people to create/use Web Components)</li> <li>A <strong>design library</strong> in popular design tools like Figma and Sketch.</li> <li>A <strong>reference website</strong> to provide documentation and information about the project.</li> </ul> <p>Where exactly those things would live is determinant on a whole slew of factors, so we can leave it here for now.</p> <h3 id="how">How</h3> <p>As mentioned before, I have no idea how exactly this would all go down. I’d figure it would require a lot of conversation, alignment, and coordination before anything tangible could happen. Here’s my hand-wavy stab at a process from my naive outsider perspective:</p> <ul> <li><strong>Have conversations</strong> with any interested party, including: standards bodies, relevant existing groups, design system teams, individual designers &amp; developers, etc to get some momentum going.</li> <li>Probably <strong>create a <a href="https://www.w3.org/groups/wg/">working group</a></strong> or similar to start moving forward in a more formal way.</li> <li><strong>Do research</strong> to better understand what common UI components and variants should exist in a Global Design System. Have conversations with and learn from popular design system teams and popular UI library maintainers. Talk to product designers and web developers to better learn what their pain points are and learn what they’d like to see in a Global Design System. Involve experts in accessibility, semantics, internationalization, and other relevant specialists to ensure a Global Design System embodies best practices. Sync with <a href="https://open-ui.org/">Open UI</a> to see how this overlaps with their existing work. Study existing design systems. <a href="https://bradfrost.com/blog/post/interface-inventory/">Conduct an interface inventory</a> across the web to capture a cross-section of in-the-wild use cases.</li> <li><strong>Lay out a plan of attack</strong> to build a Global Design System library. Define what exactly it is, align on technology choices, establish architecture, align on naming conventions, etc. Establish a roadmap for creating and delivering the Global Design System components. Figure out who’s doing what, and so on.</li> <li><strong>Design and build</strong> – This is the easy part 😂. Design, build, document common UI components according to the architectural conventions. Test alpha/beta releases with guinea pigs.</li> <li><strong>Release</strong> – Make the Global Design System components available to use; get everyone in the web community to evangelize, and get prominent design systems and projects to adopt the new library.</li> <li><strong>Iterate</strong> – Add new components and variants to the library according to the roadmap. Get feedback, etc.</li> <li><strong>Govern</strong> – A core group would of course need to <a href="https://bradfrost.com/blog/post/a-design-system-governance-process/">govern the design system</a> on an ongoing basis to address issues, field requests, protect the system’s integrity, and so on. This would obviously be a tough gig considering the global nature of the project, but I’d imagine it would be fulfilling in the same ways that working on big globe-spanning projects are.</li> </ul> <p>Something like that. Again, my perspective is naive so take all of this with a grain of salt. For now, let’s at least get the conversation part started!</p> <h3 id="when">When</h3> <p>I’ve had the opportunity to speak about this topic at <a href="https://www.youtube.com/watch?v=9H3tDkZU088&amp;t=2246s">several</a> <a href="https://www.youtube.com/watch?v=PK_PICNTgAg">conferences</a>, and I’ve thoroughly enjoyed the subsequent discussion about the prospects of a Global Design System. The number of “I’ve been saying this for years!” and “you have my sword!” responses leads me to believe there’s a strong appetite for a Global Design System. People are hungry for this to happen, the technologies are now largely in place, and the whole industry has a far better understanding of component-driven design and development. I think the time for a Global Design System is now. </p> <hr /> <h3 id="whatwouldthismeanfortheworld’swebdesignersanddevelopers">What would this mean for the world’s web designers and developers?</h3> <p>I think that a Global Design System has the potential to transform how web designers and developers do their jobs. </p> <p>When I talk about design systems, I often talk about <strong>respect and human potential</strong>. Every design system team having to build their own common components isn’t a respectful use of their time and potential. Lord knows there are some wicked problems to solve, so let’s free our hands and brains up to work on those problems instead!</p> <p><strong>If a Global Design System existed, what would design system teams do? </strong>While I understand anxiety around being replaced (hey, we hear this about design systems from product designers &amp; developers all the time), there’s still plenty of work to do. I find this tremendously exciting: <strong>design system teams would be freed up to focus on more interesting aspects of creating great digital products than simply component construction.</strong></p> <p>Plenty of the current work would remain:</p> <ul> <li><strong>Crafting a design language</strong> – The design system team would continue to be responsible for the applying the brand’s application to digital product as a thoughtful design language.</li> <li><strong>Documenting guidelines</strong> for specific use and context of components within the organization would still need to</li> </ul> <p>But there would also be a huge opportunity to free teams up to focus on bigger-picture issues. In our work at <a href="https://bigmedium.com/">Big Medium</a>, we help our clients with the human, process, product-level, and organization-level aspects of design systems. This is the stuff that truly makes or breaks a design system effort, <strong>but too often gets lost in the ground-level work of component production</strong>. With a Global Design System in place, teams could:</p> <ul> <li><strong>Architect and orchestrate a thoughtful <a href="https://bigmedium.com/ideas/design-system-ecosystem.html">design system ecosystem</a></strong> that helps the organization ship better products faster, realizing the value of a design system.</li> <li><strong>Collaborate with production teams</strong> to create and curate high-value product-specific design patterns, on top of the common UI.</li> <li><strong>Create smart components</strong> that are wired up and ready to integrate into product codebases.</li> <li><strong>Build new automation tools</strong> (hello, AI!) to scaffold designs, code, and tests quickly.</li> <li><strong>Use the design system to bust barriers between disciplines</strong>, especially between design and development. A Global Design System can help these world’s get closer together, but</li> <li><strong>Help consuming teams make great UX and development decisions</strong> with common and org-specific components.</li> <li><strong>Capture, curate, and celebrate the organization’s standards</strong>, best practices, and innovations.</li> </ul> <p>Freed from much of the mechanical production work, design system teams can spend more time on the stuff that is truly unique to the organization. There’s still a ton of work to do, and that remaining work makes better use of our human intellect. </p> <h3 id="what’snext">What’s next?</h3> <p>That’s a damn good question! How to transition from “A Global Design System seems like a good idea” into “let’s do this!” is a big question mark. So I’ll pose the question to you: what’s next? What do you think about the idea of having a Global Design System? Good idea? Bad idea? What would you like to see in a Global Design System? How do you envision it all going down? </p> <p>I believe in the web. There have been many weird twists and turns over the years, but the idealistic embers of the World Wide Web are still burning. I want the web to thrive, and I want people working to build the web to thrive and realize their potential as human beings. I bet you feel the same way. So let’s make a Global Design System happen together!</p> <hr /> <p><em>Is your design, development, or product organization struggling with process, delivery, or roles &amp; responsibilities? We can help. Big Medium helps complex organizations do big design—building and shipping great digital products at scale. <a href="https://bigmedium.com/hire/">Get in touch to find out how.</a></em></p> </div> <!-- end bmw_pageContent --> Fri, 12 Jan 2024 15:54:32 UT https://bigmedium.com/ideas/a-global-design-system.html df0b8e57cad9b3877b27ea0e81b70903-1618 global design system collaboration brad frost web design future design system webdev community Ideas Brad Frost https://bigmedium.com/ideas/whats-next-for-a-global-design-system.html https://bigmedium.com/speaking/brad-frost-shoptalk-global-design-system.html https://bigmedium.com/ideas/links/thoughts-on-a-global-design-system-chris-coyier.html https://bigmedium.com/speaking/is-atomic-design-dead.html https://bigmedium.com/ideas/design-system-ecosystem.html Scaling Digital Strategy in Complex Organizations <div class="bmw_pageContent"> <p>Big Medium’s Josh Clark joined The Design Systems Podcast for a conversation with Knapsack CEO Chris Strahl. Josh shared <a href="https://www.designsystemspodcast.com/episodes/episode/7a2f3b00/94-josh-clark-founder-of-big-medium-scaling-digital-strategy-within-complex-organizations">why big, complex organizations struggle to scale digital design and delivery</a>—and why solving that is more important than ever in a period of economic uncertainty. <a href="https://www.designsystemspodcast.com/episodes/episode/7a2f3b00/94-josh-clark-founder-of-big-medium-scaling-digital-strategy-within-complex-organizations">Listen to the podcast or read the transcript.</a></p> <p>“Let&#8217;s figure out how to do more with less. Let&#8217;s figure out how to fix our process so that we&#8217;re getting to market faster, doing more with less, improving stuff for our customers,” Josh said. “That investment comes back to you really quickly again, especially if you can capitalize it.”</p> <p>Although design systems have become a piece of critical infrastructure for scaling design and development of digital interfaces, Josh talked about why they’re also not enough. “High-performing teams have design systems, but having a design system doesn&#8217;t make you a high-performing team,” Josh said. “It takes time and care and leadership to make the thing actually work at its best. You&#8217;re always going to get some benefit from it at some level, but you&#8217;re not going to get the exponential benefits that you can get from design systems without having the right process in place.”</p> <p>When that collaborative process is missing, it usually can’t be built from the ground up. It takes a commitment from leadership, Josh said:</p> <blockquote> <p>What it suggests is that this is no longer a team issue, but a leadership issue. We need companies to say, “You know what, we are serious about our digital process. We have made this investment. It has gotten messy because we&#8217;ve moved quickly and we haven&#8217;t had the discipline or experience to do it right. We now need to have a concerted effort to make this happen in the right way.”</p> <p>Doing that in the context of lean budgets means that this sort of persuasion and explanation to get the attention of leadership around this stuff is more important than ever. And I think that often the designers and developers who are leading design systems aren&#8217;t necessarily well equipped in the language of finance and in the language of value to actually make that case.</p> </blockquote> <p>Josh shared ways that designers and developers should make the financial case for efficiency-building efforts—including how to categorize those efforts as capital expenditures, which in turn helps the company’s balance sheet (and makes the CFO happy).</p> <p>“What leadership cares about is really only three things: how are we making money; how are we saving money; and how are we attracting new customers?” Josh said. “I think design systems have a great story to tell there: that actually investing in design systems as a capital project also means that you&#8217;re going to do better on all those things.”</p> <p>Along the way, Josh and Chris also talk about:</p> <ul> <li>the issues to resolve in operationalizing a design system to realize its benefits</li> <li><a href="https://bigmedium.com/ideas/design-system-pace-layers-slow-fast.html">how to reconcile the different timeframes of production work and design system work</a></li> <li>how companies should mind their agencies to make sure their incentives are aligned with business goals</li> <li>how AI and automation can help companies not only scale their digital delivery but also <a href="https://bigmedium.com/speaking/ai-web-development-communication-gap.html">elevate the work and wellbeing of the humans involved</a></li> <li>how to balance innovation with leaning into established best practices</li> </ul> <p><a href="https://www.designsystemspodcast.com/episodes/episode/7a2f3b00/94-josh-clark-founder-of-big-medium-scaling-digital-strategy-within-complex-organizations">Listen to the podcast or read the transcript.</a></p> <hr /> <p><em>Is your design, development, or product organization struggling with process, delivery, or roles &amp; responsibilities? We can help. Big Medium helps complex organizations do big design—building and shipping great digital products at scale. <a href="https://bigmedium.com/hire/">Get in touch to find out how.</a></em></p> </div> <!-- end bmw_pageContent --> Tue, 02 Jan 2024 12:00:01 UT https://bigmedium.com/speaking/podcast-scaling-digital-strategy-complex-organizations.html df0b8e57cad9b3877b27ea0e81b70903-1617 business money josh design system podcast interview Talks Can AI Bridge the Dev/Design Gap? <div class="bmw_pageContent"> <div class="video video--16x9"> <iframe width="560" height="315" src="https://www.youtube.com/embed/SaeNQrgvuaU?si=CBwb8tdQKxanbM8u" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe> </div> <aside class="aside media-right"> Kevin gave this talk at <a href="https://zeroheight.com/events/converge/">Converge 2023</a> on September 21, 2023. </aside> <p>Big Medium senior developer Kevin Coyle has been cooking up all kinds of experiments in the Big Medium laboratories to test the opportunities and challenges of AI and machine learning. His work has blazed new paths for Big Medium&#8217;s client work, for our individual practices, and even for the way we relate to each other as friends and colleagues.</p> <p>Kevin is responsible for creating Dr. Frank, Big Medium&#8217;s AI sandbox. In this talk at the Converge conference, Kevin shares some of the ideas and findings that have emerged from that work.</p> <p>He digs into how and why web development has become siloed, burdened by frustrating communication barriers between developers, designers, and product managers. With a blend of technical demos and good ol’ human kindness/empathy, Kevin shows how artificial intelligence can help us overcome those barriers by streamlining workflows and improve human-to-human communication.</p> <p>You&#8217;ll discover:</p> <ul> <li>The roots of bad communication in digital product teams</li> <li>The benefits that come from meaningful communication with your colleagues, no matter their skillset</li> <li>How AI can make it easier for designers to create for developers, and for developers to understand designers’ work</li> <li>How AI can make design system documentation more inclusive</li> <li>How anyone and any organization can build their own AI platform (and yes, your data will stay private!)</li> </ul> </div> <!-- end bmw_pageContent --> Tue, 12 Dec 2023 17:07:44 UT https://bigmedium.com/speaking/ai-web-development-communication-gap.html df0b8e57cad9b3877b27ea0e81b70903-1611 culture collaboration webdev web design product management kevin coyle ai Talks Ship Faster by Building Design Systems Slower <div class="bmw_pageContent"> <aside class="aside media-center"> “The times are urgent; let us slow down.”<br/> —<a href="https://www.bayoakomolafe.net/post/a-slower-urgency">Bayo Akomolafe</a> </aside> <p>It’s a signature trait of design system teams to believe they’re moving too slow and must move faster. In <a href="https://bigmedium.com/hire/">Big Medium’s work</a> guiding and building <a href="https://bigmedium.com/projects/">dozens of enterprise design systems</a>, we see it over and over again:</p> <ul> <li>When a design system team isn’t delivering new features, components, or patterns as fast as product teams need them, the team believes it’s a bottleneck.</li> <li>When a UI component in the system doesn’t provide for every product-level variation or use case, the team convinces itself the component isn’t production-ready—and taking too long to get to “done.”</li> <li>If system patterns don’t include fresh ideas or experiments, the team worries that they’re promoting stagnation by not moving at the speed of innovation.</li> </ul> <p>For design system teams, this feels like an existential problem. After all, a design system is supposed to improve the efficiency (and quality and consistency) of user interfaces by delivering a library of solved problems. And so of course it feels like a fundamental failure if this supposedly efficient system is instead a bottleneck. And worse: if product teams believe that, too, then they’ll resist adopting the system.</p> <p>Successful design systems do indeed help product teams move more quickly, but here’s the twist: <strong>Successful design systems move more slowly than the products they support. That’s a feature, not a bug. The slower pace doesn’t mean that design systems have to be a bottleneck to shipping product.</strong></p> <p>Product and design system can and should run at their own independent speeds, and we’ve developed strategy and process to help the two do their thing without tripping over each other. Read on to learn:</p> <ul> <li>why design systems should move more slowly than product</li> <li>what to do when product has a need that the design system can’t support in time</li> <li>how to coordinate the design system roadmap with product roadmaps</li> </ul> <h3 id="designsystemsshouldprioritizequalityoverspeed">Design systems should prioritize quality over speed</h3> <p><strong>The design system is critical front-end infrastructure.</strong> When it’s successful, its components and patterns drive the UI, UX, and front-end code of the entire organization. You inject the design system into the very bloodstream of the whole product portfolio—as a general rule, it’s a bad idea to inject crap into the bloodstream. </p> <p>That’s why “quality over speed” is one of the core principles of our design system practice. Critical infrastructure is not a place for rushed solutions and quick hacks. Infrastructure should be stable, durable, and well engineered. A design system establishes this reliability in its approach to experience, in the craft of its design and development, in the standards it always observes, and even in the practice and rituals followed by the team that builds it.</p> <blockquote class="pullquote media-center"> Successful design systems move more slowly than the products they support. That’s a feature, not a bug. </blockquote> <p>Quality can’t be rushed. This infrastructure layer should move more deliberately than the faster product layer, where products often have to emphasize speed over quality. Shipping a product feature on time, even if just a rough MVP, often has enormous business implications. And so short-term hacks, design debt, and technical debt are often necessary to meet business goals. Sometimes you just have to take shortcuts to get the thing out the door. That’s a fact of life for the product world.</p> <p>While that’s true for product, it’s not true for the design system or other infrastructure projects, where design and technical debt are far more expensive. Understanding the design system as critical infrastructure—not mere production support—provides the logic and permission to move deliberately in pervasive, high-stakes aspects of your product development (infrastructure) while still moving very quickly in others (product).</p> <p>But how can a slower-moving design system support a faster-moving product? How do those varied speeds and efforts coexist? That’s the whole idea behind pace layers.</p> <h3 id="pacelayers:therightspeedfortherightjob">Pace layers: the right speed for the right job</h3> <p>If you’re not familiar with pace layers, here’s the gist. Say you have an object in orbit, like a planet around the sun. It moves at a steady pace, returning with every rotation to the same spot in the same fixed amount of time.</p> <div class="video video--16x9"> <video width="1024" height="576" autoplay loop muted playsinline poster="https://bigmedium.com/vids/pace-layers-one-orbit.png"> <source src="https://bigmedium.com/vids/pace-layers-one-orbit.webm" type="video/webm" /> <source src="https://bigmedium.com/vids/pace-layers-one-orbit.m4v" type="video/mp4" /> <img src="https://bigmedium.com/vids/pace-layers-one-orbit.png" width="1920" height="1080" alt="An object moving in a circular orbit at a steady pace."> </video> </div> <p>Now say that you have another planet in an outer orbit, and that it circles the sun in the very same amount of time as the inner object. That outer element necessarily moves much faster, covering more ground in the same interval—same time period, different speeds.</p> <div class="video video--16x9"> <video width="1024" height="576" autoplay loop muted playsinline poster="https://bigmedium.com/vids/pace-layers-two-orbits.png"> <source src="https://bigmedium.com/vids/pace-layers-two-orbits.webm" type="video/webm" /> <source src="https://bigmedium.com/vids/pace-layers-two-orbits.m4v" type="video/mp4" /> <img src="https://bigmedium.com/vids/pace-layers-two-orbits.png" width="1920" height="1080" alt="Two objects orbiting the same point. The inner object is closer to the center, so it has less distance to travel than the second outer object to complete its rotation."> </video> </div> <p>Back in 1999, Stewart Brand applied this to how civilization works in his book, <a href="https://www.amazon.com/Clock-Long-Now-Responsibility-Computer/dp/0465007805/">The Clock of the Long Now</a>. Instead of orbits, think of geological layers that move at different speeds but are all part of one whole. Brand called these <em>pace layers.</em></p> <figure class="media-left bmc_image"> <a href="https://bigmedium.com/bm.pix/stewart-brand-pace-layers.png" rel="bm_lightbox" title="Stewart Brand&amp;#8217;s original diagram of pace layers from his book, &lt;cite&gt;The Clock of the Long Now&lt;/cite&gt; (1999)." target="_blank"><img src="https://bigmedium.com/bm.pix/stewart-brand-pace-layers.orig-250.png" alt="Stewart Brand's original diagram of pace layers from &quot;The Clock of the Long Now&quot; (1999)" srcset="https://bigmedium.com/bm.pix/stewart-brand-pace-layers.orig-2000.png 1420w, https://bigmedium.com/bm.pix/stewart-brand-pace-layers.orig-1000.png 1000w, https://bigmedium.com/bm.pix/stewart-brand-pace-layers.orig-500.png 500w, https://bigmedium.com/bm.pix/stewart-brand-pace-layers.orig-250.png 250w" sizes="(min-width: 640px) 720px, 100vw" title="Click to enlarge" /></a> <figcaption class="bmc_caption"> Stewart Brand&#8217;s original diagram of pace layers from his book, <cite>The Clock of the Long Now</cite> (1999). </figcaption> </figure> <p>Nature, for example, moves slowly but influences culture, which moves faster and influences governance, which influences infrastructure and so on. And out at the outer edge, fashion is moving at a frenetic and sometimes chaotic pace, bouncing around like crazy. Brand wrote that each of these pace layers have an important role to play, and that the speed (or slowness) of each one is crucial to its role:</p> <blockquote> <p>Fast learns, slow remembers. Fast proposes, slow disposes. Fast is discontinuous, slow is continuous. Fast and small instructs slow and big by accrued innovation and by occasional revolution. Slow and big controls small and fast by constraint and constancy. Fast gets all our attention, slow has all the power.</p> <p>—Stewart Brand<br/> <a href="https://jods.mitpress.mit.edu/pub/issue3-brand/release/2">Pace Layering: How Complex Systems Learn and Keep Learning</a></p> </blockquote> <p>Here’s the point. All of these pace layers are part of the whole, coexisting in the same ecosystem and moving productively at their own speed. <strong>The fast and slow serve each other:</strong> Fast layers innovate, and slow layers stabilize. Out at the edge is where experimentation and discovery and innovation happens. At the center is where institutional memory and stability happens.</p> <p>Fast learns, slow remembers. Fast instructs slow, slow controls fast.</p> <h3 id="thepacelayersofdigitalproductprocess">The pace layers of digital product process</h3> <figure class="media-center bmc_image"> <a href="https://bigmedium.com/bm.pix/design-system-pace-layers.png" rel="bm_lightbox" title="In the pace layers of digital products, product zips along at the outer layer while design systems and other supporting infrastructure move more slowly at the inner layer." target="_blank"><img src="https://bigmedium.com/bm.pix/design-system-pace-layers.orig-250.png" alt="Design systems and the pace layers of digital product process" srcset="https://bigmedium.com/bm.pix/design-system-pace-layers.orig-2000.png 1920w, https://bigmedium.com/bm.pix/design-system-pace-layers.orig-1000.png 1000w, https://bigmedium.com/bm.pix/design-system-pace-layers.orig-500.png 500w, https://bigmedium.com/bm.pix/design-system-pace-layers.orig-250.png 250w" sizes="(min-width: 1050px) 1050px, 100vw" title="Click to enlarge" /></a> <figcaption class="bmc_caption"> In the pace layers of digital products, product zips along at the outer layer while design systems and other supporting infrastructure move more slowly at the inner layer. </figcaption> </figure> <p>In the pace layers of digital product process, products occupy the fast outer layer. Products ship constantly and iterate quickly, keeping up with the fast tide of changing customer needs, competitive trends, and market demands.</p> <p>Product research meanwhile keeps tabs on what’s happening, and how well a product is answering those product needs, but research inquiry typically trails product, delivering its insights slower than product timelines.</p> <p>That’s in the context of visual brand, which moves more slowly but often has epochal shifts like a rebrand, or maybe has new brands come and go with white-labeling, for example.<a href="#fn:12472" id="fnref:12472" title="see footnote" class="footnote">[1]</a></p> <p>And then at the base is the design system—along with other slow-moving standards and infrastructure that govern the foundations of the product build.</p> <p>When that design system layer is missing or poorly developed, the product layer doesn’t enjoy consistency, reuse, efficiency and other benefits of a design system’s institutional knowledge. When that design system is built with care and quality, however, it speeds the work of product because teams can use it with confidence: drop it in, and it just works.</p> <h3 id="tensionandfrustrationbetweenpacelayers">Tension and frustration between pace layers</h3> <p>Sparks sometimes fly among the layers. That happens when one layer is impatient with the speed of the others. </p> <p>Customers want product to move faster, or at least to be flexible enough to bend and get out of customers’ way when they need to do something the product can’t yet accomplish. Product teams meanwhile are frustrated by the deliberate pace of research-informed decisions (so they skip research entirely) or by infrastructure pacing (so they build their own). </p> <p>For design system teams, the fear surrounding this tension is that the design system could be seen as a bottleneck, or a distraction, or an expense—something that slows down production, that becomes a drag on the business. This comes to a head when a product team wants something that is outside the design system’s scope or timeline. </p> <p><strong>What do you do when a product team needs a UI component, pattern, or feature that the design system team cannot provide in time, or is not part of their scope?</strong></p> <p>The answer is not to add a rushed or ill-considered solution to the design system library to meet the product team’s urgent need. But it also doesn’t mean that the product team should slow down and wait. The pace layers should move at their pace and in their own lane, without hurrying or slowing the others. Here’s what that means in practice.</p> <h3 id="productteamsshouldcooktheirownrecipes">Product teams should cook their own recipes</h3> <p>Product can’t be expected to pause for the design system to catch up. If they need a feature that the design system does not yet (or may never) provide, the product team should move ahead and build the solution themselves.</p> <p>We call these solutions <em>recipes.</em> Recipes are UI patterns that are cooked up in whole or in part from design system ingredients (components, design tokens, icons and/or styles). <a href="https://bigmedium.com/ideas/design-system-ecosystem.html#recipelayeroptional">Recipes are their own layer of the design system ecosystem.</a> These recipes are not part of the core system itself, but are examples of how the system can be used—or even first-draft proposals for new features for the system. Product teams often have entire cookbooks of pattern recipes built out of design system goodies. These cookbooks are often represented by their own Figma libraries, code repos, and style guides. While Google’s Material design system provides lots of building-block components, for example, Google products like Calendar, YouTube, or GMail all have their own product-specific pattern recipes that they maintain themselves, to serve their specific domains.</p> <p><strong>It is good and desirable for product teams to invent, prototype, ship, and maintain their own UI recipes.</strong> In fact, <a href="https://bradfrost.com/blog/post/a-design-system-governance-process/">as Big Medium’s Brad Frost describes</a>, this is a formal part of <a href="https://coggle.it/diagram/XTZ3TKMV3SdbE6Pq/t/product-team-comes-to-design-help-design-and-build-new-work/">the design system governance workflow we recommend</a>.</p> <p>This is true even for components or patterns that the design system team eventually intends to include in the library but can’t commit to building in time while still meeting the design system’s standard of quality and satisfying all the contexts beyond the immediate product ask. In that case, the product team should build what they need—effectively building the first draft of the feature, component, or pattern—and the design system team should add that component to its backlog for review, improvement, and eventual inclusion in the library. Meanwhile, the product team owns and hosts the recipe.</p> <p>When product teams follow this path, they should collaborate with the design system team on high-level approach and architecture, so that the coded component has properties that anticipate and align with how the eventual design system component will be developed and delivered. This allows teams to drop in the official design system component when it becomes available and with as little rework as possible.</p> <p>Let it be said: this approach does accrue design and technical debt, but that’s also the cost of innovation and of doing something new. Debt is a trade-off, not an absolute evil, and it has to be wielded with intention and transparency. With proper communication with the design system team, the debt can be mitigated over the long term. Meanwhile, debt at the product layer is at least cheaper than debt at the infrastructure layer.</p> <p>Maybe more fundamentally, this approach recognizes the role of product as the innovative outer pace layer. Product is where experiments and first efforts should happen. The design system should capture and share the successful experiments after they prove out. “Fast learns, slow remembers.”</p> <p>In other words: The job of the design system team is not to innovate, but to curate. The system should provide answers only for settled solutions: the components and patterns that don’t require innovation because they’ve been solved and now standardized. Answers go into the design system when the questions are no longer interesting—proven out in product. <a href="https://bigmedium.com/ideas/boring-design-systems.html">The most exciting design systems are boring.</a></p> <blockquote class="pullquote media-center"> The job of the design system team is not to innovate, but to curate. </blockquote> <p>The corollary to this is that product teams should prefer design system solutions when they’re available. When there’s already a settled solution for the problem at hand, then&#8230; settle for that solution. While the recipe approach gives permission to product teams to take a first stab at features and patterns, it’s not permission to willy-nilly build whatever they like, just because they don’t care for the existing solution or they have a whim for something new. Experiments should still be chosen with intention and with spiritual alignment with the design system and the standards it offers.</p> <p>But! This still leaves room for innovation and growth when the product team believes they have an idea that could improve on an existing design system solution—and perhaps eventually replace the interaction or design pattern that the design system provides. This too should be treated with communication, transparency, and intention: the product team should propose the new approach to the design system team, suggest a scoped experiment, and then both teams can evaluate the result to see if it should be brought into the system as an addition or replacement. (And if it fails, then the product team should go back to the design system’s proven approach.)</p> <h3 id="allofthistakesplanningandcooperation">All of this takes planning and cooperation</h3> <p>This has to happen in good faith. This tends to fall apart when there’s not trust, clear communication, and healthy dialogue among the teams and layers. As usual, the biggest challenge is not the technical implementation but the coordination of humans.</p> <p>The design system team should communicate that product teams will have the best results with the design system team if they share new-feature wants and needs in advance. When product teams do annual or quarterly feature roadmapping, they should keep the design system team up to date on anticipated needs for features and components. If it aligns with design system roadmaps and timing, then the design system team can prioritize that work accordingly. If the feature doesn’t fit the plans or capacity of the design system team, then the product team can plan for building it themselves. No surprises.</p> <blockquote class="pullquote media-center"> As usual, the biggest challenge is not the technical implementation but the coordination of humans. </blockquote> <p>Either way, both teams know that they’re working at exactly the right pace for their layer—and have confidence that they’re serving the organization in the best way by doing so.</p> <p>Meanwhile, design system teams, you can put aside your existential dread. You’re an infrastructure team. Moving with steady deliberation is what infrastructure teams are supposed to do. Support the culture of speed by going slow.</p> <hr /> <p><em>Is your design, development, or product organization struggling with process, delivery, or roles &amp; responsibilities? We can help. Big Medium helps complex organizations do big design—building and shipping great digital products at scale. <a href="https://bigmedium.com/hire/">Get in touch to find out how.</a></em></p> <div class="footnotes"> <hr /> <ol> <li id="fn:12472"> <p>In some organizations, visual brand may be more fixed and slower moving; for the multi-brand design systems we create, we’re building design systems meant to support and outlast brands, sub-brands, and so on. So we think of brand as moving faster than infrastructure. <a href="#fnref:12472" title="return to article" class="reversefootnote">&#160;&#8617;</a></p> </li> </ol> </div> </div> <!-- end bmw_pageContent --> Mon, 23 Oct 2023 11:46:41 UT https://bigmedium.com/ideas/design-system-pace-layers-slow-fast.html df0b8e57cad9b3877b27ea0e81b70903-1606 design system collaboration management workflow business process Ideas Josh Clark Is Atomic Design Dead? <div class="bmw_pageContent"> <div class="video video--16x9"> <iframe width="560" height="315" src="https://www.youtube.com/embed/9H3tDkZU088?si=xm6q6l02Fc8qYj0O&amp;start=2315" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe> </div> <aside class="aside media-right"> Brad gave this talk at <a href="https://frontconference.com">Front Conference Zurich</a> on August 31, 2023. </aside> <p>Big Medium’s Brad Frost invented the Atomic Design methodology for creating, maintaining, and evolving design systems. In this talk, Brad reflects on the past, present, and future of design systems—sharing bumps, bruises, and best practices along the way. He explores the current design system ecosystem, dives into best practices and common pitfalls, and peeks into the exciting future of design systems. (Spoiler: Atomic Design is going stronger than ever.)</p> </div> <!-- end bmw_pageContent --> Tue, 17 Oct 2023 19:15:00 UT https://bigmedium.com/speaking/is-atomic-design-dead.html df0b8e57cad9b3877b27ea0e81b70903-1604 design system brad frost web design webdev future ai Talks Brad Frost The Design System Ecosystem <div class="bmw_pageContent"> <aside class="aside media-right"> <p>This article was originally published at <a href="https://bradfrost.com/blog/post/the-design-system-ecosystem/">bradfrost.com</a>.</p> <p><strong>Looking for help?</strong> If you&#8217;re planning, building, or evolving an enterprise design system, that&#8217;s what we do. <a href="/hire/">Get in touch.</a></p> </aside> <p>What does a mature, end-to-end design system look like in a big, complex organization? What are all the moving pieces, and how do they hang together in a well-considered architecture? What’s required and what’s optional? <a href="https://www.youtube.com/watch?v=UjvGAYuWSUA">Hold onto your butts</a>, because we’re going to go deep on this one.</p> <p>Let’s start here: a design system’s relationship to digital products can be boiled down like so:</p> <figure class="media-center bmc_image"> <a href="https://bigmedium.com/bm.pix/design-system-product-cycle.png" rel="bm_lightbox" title="The virtuous cycle of design system and product. Both feed each other." target="_blank"><img src="https://bigmedium.com/bm.pix/design-system-product-cycle.16x9-250.png" alt="Illustration showing the relationship between design system and product" srcset="https://bigmedium.com/bm.pix/design-system-product-cycle.16x9-2000.png 1920w, https://bigmedium.com/bm.pix/design-system-product-cycle.16x9-1000.png 1000w, https://bigmedium.com/bm.pix/design-system-product-cycle.16x9-500.png 500w, https://bigmedium.com/bm.pix/design-system-product-cycle.16x9-250.png 250w" sizes="(min-width: 1050px) 1050px, 100vw" title="Click to enlarge" /></a> <figcaption class="bmc_caption"> The virtuous cycle of design system and product. Both feed each other. </figcaption> </figure> <p>There’s a design system. Products use the design system. The design system informs and influences the products, and in turn the products inform and influence what’s in the design system. </p> <p>While this depiction is true, it ignores the complexities many organizations wrestle with day in and day out. Over the years, <strong>the digital product landscape has become vastly more complex, the responsibilities of design systems have grown substantially, tooling has evolved and matured, and processes &amp; organizational structures for managing digital products have grown up.</strong></p> <p>In order to account for this complex reality, it’s important to paint a more nuanced picture of a design system ecosystem that can power an enterprise’s portfolio of digital products. The design system ecosystem of a complex organization takes the form of a delicious-yet-dense layer cake. Call it a devil cake: the devil’s in the details, and the devil can end up looking something more like this:</p> <figure class="media-center bmc_image"> <a href="https://bigmedium.com/bm.pix/design-system-layer-cake.png" rel="bm_lightbox" title="Design systems are a layer cake of implementations, all interconnected. The core design system is the bottom layer, technology-specific implementation on top of that, recipes on top of that, smart components on top of that, and product sitting on top." target="_blank"><img src="https://bigmedium.com/bm.pix/design-system-layer-cake.16x9-250.png" alt="Illustration of the design system layer cake" srcset="https://bigmedium.com/bm.pix/design-system-layer-cake.16x9-2000.png 1920w, https://bigmedium.com/bm.pix/design-system-layer-cake.16x9-1000.png 1000w, https://bigmedium.com/bm.pix/design-system-layer-cake.16x9-500.png 500w, https://bigmedium.com/bm.pix/design-system-layer-cake.16x9-250.png 250w" sizes="(min-width: 1050px) 1050px, 100vw" title="Click to enlarge" /></a> <figcaption class="bmc_caption"> Design systems are a layer cake of implementations, all interconnected. The core design system is the bottom layer, technology-specific implementation on top of that, recipes on top of that, smart components on top of that, and product sitting on top. </figcaption> </figure> <p>And to <em>really</em> show it in all of its terrifying detail:</p> <figure class="media-left bmc_image"> <a href="https://www.figma.com/file/TfztDS5nOYVLGChUTbR78B/Design-System-Ecosystem?type=whiteboard&amp;node-id=0-1&amp;t=IZ7RRCW3MfZYbTEg-0" title="https://www.figma.com/file/TfztDS5nOYVLGChUTbR78B/Design-System-Ecosystem?type=whiteboard&amp;node-id=0-1&amp;t=IZ7RRCW3MfZYbTEg-0"><img src="https://bigmedium.com/bm.pix/design-system-ecosystem.orig-250.png" srcset="https://bigmedium.com/bm.pix/design-system-ecosystem.orig-2000.png 1600w, https://bigmedium.com/bm.pix/design-system-ecosystem.orig-1000.png 1000w, https://bigmedium.com/bm.pix/design-system-ecosystem.orig-500.png 500w, https://bigmedium.com/bm.pix/design-system-ecosystem.orig-250.png 250w" sizes="(min-width: 640px) 720px, 100vw" alt="Diagram of the design system ecosystem" title="https://www.figma.com/file/TfztDS5nOYVLGChUTbR78B/Design-System-Ecosystem?type=whiteboard&amp;node-id=0-1&amp;t=IZ7RRCW3MfZYbTEg-0" /></a> <figcaption class="bmc_caption"> A terrifying and detailed flow chart of a 5-tier design system ecosystem. The diagram maps out the relationships between all of the design, code, and documentation assets in a design system ecosystem. </figcaption> </figure> <p>Wow, that looks overwhelming huh!? Before you freak out, it’s important to stress a few things. </p> <p>First of all, <strong>nearly all of these layers are optional and don’t necessarily apply to every organization.</strong> Instead, this is a visualization of a complete, mature enterprise design system. It’s informed by our work helping some of the world’s largest companies successfully establish and evolve their design systems. We know companies start seeing value after implementing only a fraction of what’s shown here.</p> <p>Second, Gall’s Law is extremely relevant here:</p> <blockquote> <p>A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.</p> <p><a href="https://en.wikipedia.org/wiki/John_Gall_(author)#Galls_law">Gall’s Law</a></p> </blockquote> <p>All to say, <strong>it’s critical for a design system architecture to be only as complex as it needs to be</strong>, and add additional layers or complexity only when real needs arise. Growing a design system is a gradual process. (And if it seems overwhelming, well, we’re happy to help. <a href="https://bigmedium.com/hire/">Get in touch</a> to hire us to help plan, build, or evolve your design system.)</p> <p>In this article we’ll get down to the gory details of what makes up a successful, sophisticated, and mature design system ecosystem. We’ll break down what the capital-E Enterprise folks call the “end-to-end experience” for deploying user interfaces at scale. This is tricky, nuanced work, but that’s the nature of the beast for digital organizations managing several/dozens/hundreds/thousands of products and people. </p> <p>Alright, let’s dive in!</p> <h3 id="anatomyofadesignsystemecosystem">Anatomy of a design system ecosystem</h3> <p>We’re going to detail <a href="https://www.figma.com/file/TfztDS5nOYVLGChUTbR78B/Design-System-Ecosystem?type=whiteboard&amp;node-id=0%3A1&amp;t=IZ7RRCW3MfZYbTEg-1">this diagram</a>, which describes the various UI assets and the relationships between them. While the diagram looks intimidating, the crux of the ecosystem can be broken down like so:</p> <figure class="media-center bmc_image"> <a href="https://bigmedium.com/bm.pix/design-system-layers.png" rel="bm_lightbox" title="Illustration of the five layers of a mature, end-to-end design system." target="_blank"><img src="https://bigmedium.com/bm.pix/design-system-layers.16x9-250.png" alt="Illustration of design system layers" srcset="https://bigmedium.com/bm.pix/design-system-layers.16x9-2000.png 1920w, https://bigmedium.com/bm.pix/design-system-layers.16x9-1000.png 1000w, https://bigmedium.com/bm.pix/design-system-layers.16x9-500.png 500w, https://bigmedium.com/bm.pix/design-system-layers.16x9-250.png 250w" sizes="(min-width: 1050px) 1050px, 100vw" title="Click to enlarge" /></a> <figcaption class="bmc_caption"> Illustration of the five layers of a mature, end-to-end design system. </figcaption> </figure> <ul> <li><strong>Core design system layer</strong> – which contains the common, organization-wide UI building blocks for both design and development.</li> <li><strong>Optional technology-specific layer</strong> – which contains framework-specific and native implementations of those common UI components.</li> <li><strong>Optional recipe layer</strong> – which contains composed UI components to be used consistently across specific contexts (like a product or product family), but aren’t reusable across the entire organization.</li> <li><strong>Optional smart components layer</strong> – which contains UI components wrapped in logic, functionality, or other smarts to make the integration of common components and services easier for product developers.</li> <li><strong>Product layer</strong> – the actual websites and apps that we ship to customers (aka the whole reason we’re doing all of this!)</li> </ul> <p>If those are the broad layers of a UI ecosystem, here’s a breakdown of the types of assets that go into those layers:</p> <figure class="media-center bmc_image"> <a href="https://bigmedium.com/bm.pix/design-system-assets.png" rel="bm_lightbox" title="The many assets that populate the complete design system ecosystem: design library or file, code repository, code package, reference website, front-end workshop, and application codebase." target="_blank"><img src="https://bigmedium.com/bm.pix/design-system-assets.16x9-250.png" alt="Illustration of design system assets" srcset="https://bigmedium.com/bm.pix/design-system-assets.16x9-2000.png 1920w, https://bigmedium.com/bm.pix/design-system-assets.16x9-1000.png 1000w, https://bigmedium.com/bm.pix/design-system-assets.16x9-500.png 500w, https://bigmedium.com/bm.pix/design-system-assets.16x9-250.png 250w" sizes="(min-width: 1050px) 1050px, 100vw" title="Click to enlarge" /></a> <figcaption class="bmc_caption"> The many assets that populate the complete design system ecosystem: design library or file, code repository, code package, reference website, front-end workshop, and application codebase. </figcaption> </figure> <ul> <li><strong>Design library</strong> – <a href="https://help.figma.com/hc/en-us/articles/360041051154-Guide-to-libraries-in-Figma">Figma team library</a> or similar</li> <li><strong>Design file</strong> – Figma project file or similar</li> <li><strong>Code repository</strong> – the source code home – GitHub or similar</li> <li><strong><a href="https://bradfrost.com/blog/post/a-frontend-workshop-environment/">Front-end workshop</a></strong> – a tool like <a href="https://storybook.js.org/">Storybook</a> to build, view, test, review and document coded UI components</li> <li><strong>Code package</strong> – a code library packaged up and published (on <a href="https://www.npmjs.com/">npm</a> or similar) in order to be consumed as a dependency by other applications.</li> <li><strong>Reference website</strong> – <a href="https://zeroheight.com/">Zeroheight</a> or <a href="https://bradfrost.com/blog/post/self-hosted-vs-third-party-design-system-reference-website/">similar</a></li> </ul> <p>With all of that table setting out of the way, let’s dig into the anatomy of the core design system!</p> <h3 id="coredesignsystem">Core design system</h3> <p>The core design system contains common components, patterns, principles, and conventions that help an organization: </p> <ol> <li><a href="https://bradfrost.com/blog/post/design-systems-are-for-user-interfaces/">tell the official story of how it designs and builds user interfaces, </a>and</li> <li>provide the building materials to do it.</li> </ol> <p>It’s a library of solved problems, the settled solutions that don’t need re-hashed for the 15th time It’s <a href="https://bigmedium.com/ideas/boring-design-systems.html">the boring stuff</a> like form controls, buttons, accordions, and the standard-fare components you see <a href="https://open-ui.org/research/component-matrix/">across many popular design systems</a>. </p> <p>So what ingredients are included in the core design system? The key assets the design system includes are <strong>design tokens, icons</strong>, <strong>UI components</strong>, and a <strong>reference website</strong>.</p> <figure class="media-center bmc_image"> <a href="https://bigmedium.com/bm.pix/core-design-system-assets.png" rel="bm_lightbox" title="The core design system layer includes design tokens, icons, and UI components, each represented by their own set of assets." target="_blank"><img src="https://bigmedium.com/bm.pix/core-design-system-assets.16x9-250.png" alt="Illustration of the core design system layer and its assets" srcset="https://bigmedium.com/bm.pix/core-design-system-assets.16x9-2000.png 1920w, https://bigmedium.com/bm.pix/core-design-system-assets.16x9-1000.png 1000w, https://bigmedium.com/bm.pix/core-design-system-assets.16x9-500.png 500w, https://bigmedium.com/bm.pix/core-design-system-assets.16x9-250.png 250w" sizes="(min-width: 1050px) 1050px, 100vw" title="Click to enlarge" /></a> <figcaption class="bmc_caption"> The core design system layer includes design tokens, icons, and UI components, each represented by their own set of assets. </figcaption> </figure> <h4 id="designtokenslayer">Design tokens layer</h4> <p><strong><a href="https://css-tricks.com/what-are-design-tokens/">Design tokens</a> are low-level design definitions</strong> (the <a href="https://bradfrost.com/blog/post/extending-atomic-design/">sub-atomic particles</a> if you will) — color, typography, border radius, spacing, elevation, and other values — that make up a design language. Design tokens are ultimately applied to UI components in order to achieve a specific look and feel. Think of them as brand variables.</p> <p>Nearly all of our design-system client work over the last 5 years has included creating/evolving some form of themeable design system. Architecting a <a href="https://bradfrost.com/blog/post/creating-themeable-design-systems/">thoughtful 3-tier token architecture</a> is the secret sauce for making a design system <a href="https://bradfrost.com/blog/post/the-many-faces-of-themeable-design-systems/">support multiple brands, white-labeling, different product families, redesigns, dark mode, and more</a>.</p> <p>We recommend splitting design tokens into their own layer (separate from the UI component layer) to unlock theming, create a separation of concerns between brand language and UI components, and version brand languages independent of UI components.</p> <figure class="media-left bmc_image"> <a href="https://bigmedium.com/bm.pix/design-token-assets.png" rel="bm_lightbox" title="The design tokens layer consists of a foundations design library, a code repo, and a design tokens package." target="_blank"><img src="https://bigmedium.com/bm.pix/design-token-assets.orig-250.png" alt="Illustration of design token assets" srcset="https://bigmedium.com/bm.pix/design-token-assets.orig-2000.png 1800w, https://bigmedium.com/bm.pix/design-token-assets.orig-1000.png 1000w, https://bigmedium.com/bm.pix/design-token-assets.orig-500.png 500w, https://bigmedium.com/bm.pix/design-token-assets.orig-250.png 250w" sizes="(min-width: 640px) 720px, 100vw" title="Click to enlarge" /></a> <figcaption class="bmc_caption"> The design tokens layer consists of a foundations design library, a code repo, and a design tokens package. </figcaption> </figure> <h5 id="foundationsdesignlibrary">Foundations design library</h5> <p>Design tokens and associated styles are often referred to as “foundations” in the design discipline. In Figma, these design token foundations are defined as <a href="https://help.figma.com/hc/en-us/articles/15339657135383-Guide-to-variables-in-Figma">variables</a> for most values, while typography-specific tokens need to be defined as styles (Note: for now! <a href="https://help.figma.com/hc/en-us/articles/4406787442711#01H8DQBXK0JPJYZQ4EEF42H71T">Figma said</a> they’re working on making typography-specific variables available). The foundations should be managed in their own <a href="https://help.figma.com/hc/en-us/articles/360041051154-Guide-to-libraries-in-Figma">design library</a> that other files and libraries — including the UI component library — can subscribe to. This library can contain the definitions for each supported theme, though organizations supporting dozens or hundreds of themes might want to consider chunking things out into different foundations libraries.</p> <h5 id="designtokensrepo">Design tokens repo</h5> <p>In code, the design token source of truth is a repository of JSON files that define all theme values. Tooling (<a href="https://amzn.github.io/style-dictionary/#/">Style Dictionary</a> has become the standard) then converts design token JSON files into the appropriate technology-specific format (CSS custom properties, Sass, iOS, Android, etc), which can then be applied to UI components. </p> <h5 id="designtokenspackage">Design tokens package</h5> <p>The technology-specific formatted tokens are packaged up and published on a software registry in order for consuming developers to pull them into web products, native apps, and other environments. </p> <h4 id="icons">Icons</h4> <p>Icons are a weird one! Like design tokens, they can exist as their own product that gets packaged up and consumed by many different environments. More commonly, we tend to see icons bundled up alongside the design tokens. Teams powering web, native, and other non-web software that need to manage/version icons independently might want to consider splitting icons out as its own independent layer supported by the following assets:</p> <figure class="media-left bmc_image"> <a href="https://bigmedium.com/bm.pix/icons-assets.png" rel="bm_lightbox" title="The icons layer consists of a design library, a code repo, and an icons package." target="_blank"><img src="https://bigmedium.com/bm.pix/icons-assets.orig-250.png" alt="Illustration of icon assets" srcset="https://bigmedium.com/bm.pix/icons-assets.orig-2000.png 1800w, https://bigmedium.com/bm.pix/icons-assets.orig-1000.png 1000w, https://bigmedium.com/bm.pix/icons-assets.orig-500.png 500w, https://bigmedium.com/bm.pix/icons-assets.orig-250.png 250w" sizes="(min-width: 640px) 720px, 100vw" title="Click to enlarge" /></a> <figcaption class="bmc_caption"> The icons layer consists of a design library, a code repo, and an icons package. </figcaption> </figure> <ul> <li>Icon Figma library</li> <li>Icon SVG repository</li> <li>Icon package</li> </ul> <h4 id="uicomponents">UI Components</h4> <p>This is the star of the design system show! When people think of a design system, they think of a set of common UI components that can be used and reused in other products. There are a few different assets that constitute a design system’s UI component library, so let’s break it down.</p> <figure class="media-center bmc_image"> <a href="https://bigmedium.com/bm.pix/ui-component-assets.png" rel="bm_lightbox" title="The UI components layer consists of a Figma component library, a Web Component repo, a Web Component package, a Web Component storybook, and a reference website" target="_blank"><img src="https://bigmedium.com/bm.pix/ui-component-assets.orig-250.png" alt="Illustration of UI components assets" srcset="https://bigmedium.com/bm.pix/ui-component-assets.orig-2000.png 2000w, https://bigmedium.com/bm.pix/ui-component-assets.orig-1000.png 1000w, https://bigmedium.com/bm.pix/ui-component-assets.orig-500.png 500w, https://bigmedium.com/bm.pix/ui-component-assets.orig-250.png 250w" sizes="(min-width: 1050px) 1050px, 100vw" title="Click to enlarge" /></a> <figcaption class="bmc_caption"> The UI components layer consists of a Figma component library, a Web Component repo, a Web Component package, a Web Component storybook, and a reference website </figcaption> </figure> <h5 id="coreuicomponentsfigmalibrary">Core UI components Figma library</h5> <p>For designers, a design system’s <a href="https://help.figma.com/hc/en-us/articles/360041051154-Guide-to-libraries-in-Figma">design library</a> is a dedicated project where designers capture the design specifications for common UI components. Here’s where the design system designers sweat the small stuff (Alert layout! Accordion affordances! Badge variants! Required form field treatment! Etc etc) so other product designers don’t have to. The published design library becomes the thing product designers subscribe to in order to drag-and-drop the system’s components into their product design files.</p> <h5 id="webcomponentslibraryrepository">Web Components library repository</h5> <p>While a Figma library is super helpful for designer efficiency, the true source of truth for a design system is a library of coded components that build real digital products. After all, despite all of this ecosystem mumbo jumbo, the <a href="https://bigmedium.com/ideas/only-one-deliverable-matters.html">only thing that really matters</a> at the end of the day is the actual user experience human beings interact with. And that reality snags many design system teams; it’s really easy to lose the forest for the trees. Don’t get it twisted: a design system is a means to an end.</p> <p>We’ve helped organizations build design systems in a multitude of technologies over the years, but as time goes by <strong>we now heartily recommend one specific technology to build a core design system for the web: <a href="https://bradfrost.com/blog/post/lets-talk-about-web-components/">Web Components</a></strong>. Web Components are a standard, part of the web platform itself. That means they’re interoperable with any web framework or technology, they’re lightweight, they’re themeable, and they’re self-contained. <small>Note: It’s totally possible to build the coded design system in a specific technology like React, but just be eyes-wide-open to the fact that the system can’t power products that aren’t compatible with that technology. Everything has pros and cons! </small></p> <p>The Web Component repository contains the source code for your design system’s common components. We’ve been using <a href="https://lit.dev/">Lit</a> for the last few years with great success (and have used <a href="https://stenciljs.com/">Stencil</a> successfully in the past) to help us author Web Components in a thoughtful, efficient manner. </p> <h5 id="webcomponentsstorybook">Web Components Storybook</h5> <p><a href="https://bradfrost.com/blog/post/atomic-design-and-storybook/">We use Storybook</a> in order to build, visualize, test, review, and document our coded design system library. Storybook is included in the web component repository as a dev dependency; it’s not a separate repository or anything like that. We publish our Storybook to a URL for testing/review/documentation, and like to use <a href="https://www.netlify.com/">Netlify</a> or similar to publish each work-in-progress branch of the Web Components so that our client teams can test, review, and discuss changes before they get merged into the main library.</p> <h5 id="webcomponentlibrarypackage">Web component library package</h5> <p>A build step converts the web component source code into a <code>dist</code> directory containing the built library of Web Components, which then gets packaged up and published on a software registry. This allows for any web product — a static website, React/Angular/Vue/Etc app, a CMS-powered website, whatever — to pull the web component library into their project and use the design system’s components in their products’ user interfaces. </p> <h5 id="referencewebsite">Reference website</h5> <p>A reference website <a href="https://bradfrost.com/blog/post/the-workshop-and-the-storefront/">serves as the storefront</a> that is part marketing website, part documentation, part support channel, and all things design system. The reference website gather all of the assets described above under one roof to help the organization successfully wield the design system to build great interfaces for digital products.</p> <p><a href="https://bradfrost.com/blog/post/self-hosted-vs-third-party-design-system-reference-website/">You can build the reference website from scratch, or power it using a third-party tool like Zeroheight</a>. As time goes on, we’ve found great success with Zeroheight as it elegantly pulls design assets from Figma and code assets from Storybook. This maintains Figma and code (visualized through Storybook) as the workshops for design and dev respectively, but brings them together in a single location to provide cross-disciplinary guidance for teams using the system.</p> <h3 id="technology-specificimplementationoptional">Technology-specific implementation (optional)</h3> <p>This optional layer translates the core design system into specific technical implementations. This can help application developers working in specific tech stacks easily wield the design system’s ingredients.</p> <figure class="media-center bmc_image"> <a href="https://bigmedium.com/bm.pix/tech-specific-implementation-assets.png" rel="bm_lightbox" title="The technology-specific implementation layer includes code for specific platforms like web frameworks, native apps, and more." target="_blank"><img src="https://bigmedium.com/bm.pix/tech-specific-implementation-assets.16x9-250.png" alt="Illustration of the technology-specific implementation layer" srcset="https://bigmedium.com/bm.pix/tech-specific-implementation-assets.16x9-2000.png 1920w, https://bigmedium.com/bm.pix/tech-specific-implementation-assets.16x9-1000.png 1000w, https://bigmedium.com/bm.pix/tech-specific-implementation-assets.16x9-500.png 500w, https://bigmedium.com/bm.pix/tech-specific-implementation-assets.16x9-250.png 250w" sizes="(min-width: 1050px) 1050px, 100vw" title="Click to enlarge" /></a> <figcaption class="bmc_caption"> The technology-specific implementation layer includes code for specific platforms like web frameworks, native apps, and more. </figcaption> </figure> <h4 id="frameworkwrapperlayer">Framework wrapper layer</h4> <p>As we’ve discussed, Web Components are a fantastic choice for <a href="https://bradfrost.com/blog/post/front-of-the-front-end-and-back-of-the-front-end-web-development/">front-of-the-front-end</a> code that serves as the backbone of a design system. But! It can be helpful or necessary to maintain a framework-specific flavor of the design system. This entails wrapping the design system’s Web Components in framework-specific syntax (for example, the button Web Component <code>&lt;ds-button variant=&quot;primary&quot;&gt;</code> could be wrapped in React and exposed to developers as <code>&lt;DsButton variant=&quot;primary&quot;&gt;</code>).</p> <p>Our team thinks framework-specific implementations will diminish over time; most frameworks can consume Web Components as is. But in our experience, we’ve encountered a few good reasons to create and maintain these framework-wrapped versions:</p> <ul> <li>Some frameworks — especially earlier versions of React — need some massaging to get Web Components to work properly. <a href="https://github.com/lit/lit/tree/main/packages/labs/react">Lit’s React wrapper</a> is an example of a bit of glue code that’s necessary to get Web Components to work smoothly with the way React handles events.</li> <li>Teams with existing React/Angular/Vue/etc libraries that power real products should preserve all that hard-earned adoption! Those-framework-specific libraries can continue to exist, but we often help teams replace the component guts with new web component-powered internals instead.</li> <li>Maintaining existing framework-specific libraries can be a good way of incrementally adopting a sturdier API naming standard while still supporting legacy API language.</li> <li>Teams used to wielding framework-shaped components (e.g. <code>&lt;DsButton text=&quot;Click me&quot;&gt;</code>) don’t have to adopt an unfamiliar web component convention (<code>&lt;ds-button text=&quot;Click me&quot;&gt;</code>). This layer can also serve as a safeguard in case teams want to swap out different technologies under the hood over time.</li> </ul> <h5 id="frameworkcoderepo">Framework code repo</h5> <p>Where does the framework-wrapper repository live? We’ve seen it live under the formal design system umbrella (often as a sibling of the web component package in a monorepo), but we’ve also seen framework-wrapper layers live outside of the formal system maintained by downstream teams working in a specific technology.</p> <p>Regardless of where the framework layer lives, it’s crucial for the core and framework-specific layers to stay in sync with one another. This can be helped along by the technical architecture of the system, but it ultimately requires coordination between the humans managing the different layers.</p> <h5 id="frameworkstorybook">Framework Storybook</h5> <p>If a React flavor of the design system exists, spinning up a React-specific Storybook is necessary to provide React developers the appropriate code syntax to reference and copy-and-paste. </p> <h5 id="frameworkcodepackage">Framework code package</h5> <p>Each framework-specific flavor of the design system library gets built and published on a software registry, which allows product teams working in a specific framework to pull in the appropriate flavor of the design system as a dependency. </p> <h4 id="nativelayer">Native layer</h4> <p>Native apps are often an important part of an organizations’ digital landscape. They’re challenging from a design system perspective for a number of reasons: </p> <ul> <li>Native app UIs can be coded in an array of technologies. Some use (often heavily-modified) web tech like React Native or Ionic. There’s Jetpack Compose, Flutter, Swift UI, UIKit, and others for bespoke native application development. At the end of the day, there’s not exactly a standard for developing UI components for native platforms, so implementation can be uneven.</li> <li>iOS and Android bring OS-level UI conventions and OS-provided UI components along for the ride, which means an organization’s bespoke UI needs to work with the grain of the operating systems.</li> <li>Design system tooling for native codebases are absent or immature (If I had a nickel for every time I’ve been asked “is there a Storybook for iOS and Android?”, I’d have a handful of nickels).</li> <li>Native teams tend to be more siloed (or outsourced) compared to their web counterparts.</li> </ul> <p>Whatever the challenges may be, organizations creating native design systems will need the following assets:</p> <h5 id="iosandorandroidcomponentlibraryrepositories">iOS and/or Android component library repositories</h5> <p>These repositories contain the source code for a design system’s native app implementations, similar to <a href="https://github.com/material-components/material-components-android">Material Design’s Android codebase</a>.</p> <h5 id="iosandorandroidcodepackages">iOS and/or Android code packages</h5> <p>The native landscape operates a bit differently than the web landscape, but package managers exist (e.g. <a href="https://www.swift.org/package-manager/">Swift Package Manager</a>) to help deploy a native design system’s library to other native application codebases.</p> <h4 id="othernon-webimplementations">Other non-web implementations</h4> <p>iOS and Android mobile apps are certainly some of the more common non-web digital products, but there can be a vast array of other software interfaces floating around an organization. We’ve dealt with airplane seat-back UIs, banking ATM UIs, kiosk UIs, medical equipment UIs, scientific equipment UIs, and more. All of these UIs come to life <em>somehow</em>, and the technologies that power these experiences vary widely (and often frighteningly!). Regardless of the specific tech employed for these experiences, the same guidance applies: create a dedicated repository for common UI-specific code, and deploy that code using some form of software registry.</p> <h3 id="recipelayeroptional">Recipe layer (optional)</h3> <p>We often encounter design system teams who are frantically trying to keep up with every UI-related product decision happening across their organization. The (often small-and-scrappy) team runs from meeting to meeting, captures other product teams’ UI needs in their already-crowded backlog, and then gets to work implementing those requests. This road leads to bottlenecks and burnout.</p> <p>There’s a better way. The design system doesn’t have to own, include, or oversee every bit of UI across a company’s product landscape. It just needs to provide a core set of ingredients—and support/encourage teams to build recipes with those ingredients.</p> <p>When we introduce the concept of a <a href="https://bradfrost.com/blog/post/design-system-components-recipes-and-snowflakes/">recipe component layer</a> to these frazzled teams, you can almost see the weight lift from their shoulders. The recipe layer serves as an important pressure release valve for the UI ecosystem. With recipes, product designers are able to own their product-specific UI components and work at a relatively fast pace, while design system designers carry on working on the core component ingredients at a slower, more considered pace.</p> <p>The recipe layer proves to be a really crucial layer in the ecosystem for many teams, and an essential layer for massive organizations managing many business units or sub-brands. <a href="https://shinytoyrobots.substack.com/p/the-hub-and-spoke-design-system-model">This article</a> by Robin Cannon explains why IBM’s Carbon Design System team leaned into this concept of recipes:</p> <blockquote> <p>Business units needed extra capability to tailor how the design system was going to be consumed in their domain.</p> <p><a href="https://shinytoyrobots.substack.com/p/the-hub-and-spoke-design-system-model">Robin Cannon</a></p> </blockquote> <p>This layer provides individual business units, sub-brands, product families, or products with important agency and autonomy over their domain while still adhering to the standards defined by the core design system.</p> <p>What are recipes, exactly? As the name suggests, recipes combine ingredients to create UI experiences that are complex, delicious, nutritious. The design system’s core components are the ingredients stocked in the pantry. Other product designers then take those ingredients to create product-specific compositions that meet their product needs. </p> <p>A design system’s core component library might contain a card, button, button group, heading, text passage, badge, and key-value table:</p> <figure class="media-center bmc_image"> <a href="https://bigmedium.com/bm.pix/individual-component-examples.png" rel="bm_lightbox" title="A smattering of design system components: a card, heading, text passage, badge, button group, and key-value pair table." target="_blank"><img src="https://bigmedium.com/bm.pix/individual-component-examples.orig-250.png" alt="Screenshots of a collection of individual components" srcset="https://bigmedium.com/bm.pix/individual-component-examples.orig-2000.png 1818w, https://bigmedium.com/bm.pix/individual-component-examples.orig-1000.png 1000w, https://bigmedium.com/bm.pix/individual-component-examples.orig-500.png 500w, https://bigmedium.com/bm.pix/individual-component-examples.orig-250.png 250w" sizes="(min-width: 1050px) 1050px, 100vw" title="Click to enlarge" /></a> <figcaption class="bmc_caption"> A smattering of design system components: a card, heading, text passage, badge, button group, and key-value pair table. </figcaption> </figure> <p>Out of those ingredients, different product teams can create their own compositions to be used consistently across their digital products. The e-commerce team can compose a product card recipe, the marketing team can compose a promo card recipe, and the analytics team can compose a customer data card recipe. </p> <figure class="media-center bmc_image"> <a href="https://bigmedium.com/bm.pix/recipe-example.png" rel="bm_lightbox" title="Recipes compose system components into context-specific uses. Here: a product card for e-commerce, a promo card for content marketing, and a customer data card for an application dashboard." target="_blank"><img src="https://bigmedium.com/bm.pix/recipe-example.orig-250.png" alt="Design system recipe examples" srcset="https://bigmedium.com/bm.pix/recipe-example.orig-2000.png 1918w, https://bigmedium.com/bm.pix/recipe-example.orig-1000.png 1000w, https://bigmedium.com/bm.pix/recipe-example.orig-500.png 500w, https://bigmedium.com/bm.pix/recipe-example.orig-250.png 250w" sizes="(min-width: 1050px) 1050px, 100vw" title="Click to enlarge" /></a> <figcaption class="bmc_caption"> Recipes compose system components into context-specific uses. Here: a product card for e-commerce, a promo card for content marketing, and a customer data card for an application dashboard. </figcaption> </figure> <p>The cool thing is that the design system team can monitor these recipes and decide to “graduate” a recipe component into the core design system if it proves to be super successful. While not every recipe is a core design system candidate, it’s cool that the recipe layer provides a little design system component incubator.</p> <figure class="media-center bmc_image"> <a href="https://bigmedium.com/bm.pix/recipe-assets.png" rel="bm_lightbox" title="The recipes layer includes assets for specific contexts, like individual products (or families of products)." target="_blank"><img src="https://bigmedium.com/bm.pix/recipe-assets.16x9-250.png" alt="Illustration of the recipes layer" srcset="https://bigmedium.com/bm.pix/recipe-assets.16x9-2000.png 1920w, https://bigmedium.com/bm.pix/recipe-assets.16x9-1000.png 1000w, https://bigmedium.com/bm.pix/recipe-assets.16x9-500.png 500w, https://bigmedium.com/bm.pix/recipe-assets.16x9-250.png 250w" sizes="(min-width: 1050px) 1050px, 100vw" title="Click to enlarge" /></a> <figcaption class="bmc_caption"> The recipes layer includes assets for specific contexts, like individual products (or families of products). </figcaption> </figure> <h5 id="recipedesignlibraries">Recipe design libraries</h5> <p>Think of recipe design libraries as cookbooks. They are Figma libraries that contain product- or discipline-specific components and compositions. Recipe libraries subscribe to both the design system foundations and core UI component libraries. Designers working in these libraries create composite components out of core design system components that are meant to be used consistently across their product or product family, but may not be abstract enough or broadly used enough (yet?) to include in the core design system. </p> <p>Product design teams maintain and publish their own recipe libraries, and downstream product designers subscribe to them in order to use recipe components in individual product files.</p> <h5 id="reciperepositories">Recipe repositories</h5> <p>Recipe code repositories contain the coded corollaries to the recipe Figma libraries. These repositories contain the source code for component compositions meant to be used consistently across a product or product family. A product’s website header is a great example of a recipe: the specific header composition is reusable across one product family, but likely distinct from other headers in other product families:</p> <pre><code>&lt;site-header&gt;&lt;/site-header&gt; </code></pre> <p>Specific card recipes can be created so downstream developers don’t have to assemble raw design system ingredients for every product card instance:</p> <pre><code>&lt;product-card heading=&quot;Kids Sloth T-Shirt&quot; price=&quot;$18&quot; imgSrc=&quot;path/to/image.jpg&quot; imgAlt=&quot;Purple t-shirt with smiling sloth illustration graphic&quot; href=&quot;path/to-product&quot;&gt; &lt;/product-card&gt; </code></pre> <p>Developers can create reusable recipes as Web Components, React/Angular/Vue/etc components, or native components. Because recipes are product-specific, they can be written in whatever language is practical for the team and technical architecture.</p> <h5 id="recipestorybooks">Recipe Storybooks</h5> <p>We’ve discussed how important it is for design system teams to be able to view, review, test, and document core UI components, and the same holds true for coded recipe components. Each recipe repository ought to maintain and publish a Storybook for the recipes used in a product or product family. Any recipe Storybook should mirror the corresponding recipe Figma library.</p> <h5 id="recipecodepackages">Recipe code packages</h5> <p>In order for recipes to be consumable to downstream products developers, they need to be published on a software registry.</p> <h5 id="recipereferencewebsites">Recipe reference websites</h5> <p>Think of this as a product-specific style guide. If YouTube uses Google’s Material Design System, the YouTube reference site would detail the YouTube-specific components and recipes built on top of Material. It’s important to provide guidelines, rationale, and examples for recipes. How should designers and developers use that product card recipe? What are the configurations? The gotchas? </p> <h3 id="smartcomponentlayeroptional">Smart component layer (optional)</h3> <p>Design system UI components are intentionally dumb. This is by design! In order to be as portable and interoperable as possible, design system components (and many recipes) don’t contain business logic and aren’t wired up to any backend services; they strictly handle a component’s presentation and basic functionality (e.g. an accordion opens and closes on click). </p> <p>However, these components actually need to work eventually! Enter the smart component layer. If core design system components are strictly <a href="https://bradfrost.com/blog/post/front-of-the-front-end-and-back-of-the-front-end-web-development/">front-of-front-end</a>, then smart components introduce the back-of the-front-end. This is is a place where the dumb design system components and recipes get wrapped in logic in order to provide downstream development teams with drop-in, ready-to-use functional components and services.</p> <p>Some smart component layer use cases include:</p> <ul> <li>Form submission and validation (e.g. <a href="https://react-hook-form.com/">React Hook Form</a> and <a href="https://redux-form.com/">React Redux Form</a>)</li> <li>Payment component for processing credit card payments</li> <li>Typeahead querying specific services or databases (e.g. search a company directory or product database and the typeahead dropdown returns the appropriate results)</li> <li>Data tables with sorting/filtering/searching logic (e.g <a href="https://www.ag-grid.com/">AG Grid</a>)</li> <li>Product grids with sorting/filtering</li> <li>Wiring up analytics to UI components</li> <li>CMS-ready components that make design system and recipe components available to CMS editors.</li> </ul> <p>In the same way design systems keep teams from reinventing the wheel, these common smart components and services take care of common business logic and functionality so downstream teams can focus their energy on more worthwhile tasks.</p> <p>We’ve seen this concept extend beyond smart components and into the realm of full-blown software starter kits. We’ve had a few clients develop their own custom boilerplates akin to Create React App: “here’s a NextJS environment with the design system tokens, components, and other recipes linked as dependencies, all the form fields wired up, and routes ready to go.” Product developer teams can quickly spin up a new project and immediately get to work building their application logic rather than futzing with plumbing and infrastructure. Pretty cool!</p> <p>This layer is often maintained by the team that also supports the underlying service, using the design system components to deliver ready-to-roll solutions for application teams.</p> <figure class="media-center bmc_image"> <a href="https://bigmedium.com/bm.pix/smart-components-assets.png" rel="bm_lightbox" title="The smart component layer is composed of components or flows integrated with back-end services and business logic." target="_blank"><img src="https://bigmedium.com/bm.pix/smart-components-assets.16x9-250.png" alt="Illustration of the assets of the smart components layer" srcset="https://bigmedium.com/bm.pix/smart-components-assets.16x9-2000.png 1920w, https://bigmedium.com/bm.pix/smart-components-assets.16x9-1000.png 1000w, https://bigmedium.com/bm.pix/smart-components-assets.16x9-500.png 500w, https://bigmedium.com/bm.pix/smart-components-assets.16x9-250.png 250w" sizes="(min-width: 1050px) 1050px, 100vw" title="Click to enlarge" /></a> <figcaption class="bmc_caption"> The smart component layer is composed of components or flows integrated with back-end services and business logic. </figcaption> </figure> <h5 id="smartcomponentrepositoriesandpackages">Smart component repositories and packages</h5> <p>The structure and location of smart component repositories and packages can vary wildly since they’re directly adjacent to specific product architecture built using specific technologies. But ultimately, smart components and drop-in services should be managed as discrete products to make usage, versioning, and maintenance as easy as possible. </p> <h3 id="productlayer">Product layer</h3> <p>Friends, we have finally arrived! The product layer is where the rubber meets the road. This is where all of this infrastructure comes together to help power real websites and apps used by real human beings. </p> <p>It’s at this product level where a design system’s success can truly be measured. In order for a design system to be successful, it needs to become the critical front-end infrastructure that powers real digital products. So let’s discuss how all of this design system ecosystem makes its way into real product environments.</p> <figure class="media-center bmc_image"> <a href="https://bigmedium.com/bm.pix/product-assets.png" rel="bm_lightbox" title="The product layer consists of the production files that integrate design system components into end-result design files and application code." target="_blank"><img src="https://bigmedium.com/bm.pix/product-assets.16x9-250.png" alt="Illustration of product layer assets" srcset="https://bigmedium.com/bm.pix/product-assets.16x9-2000.png 1920w, https://bigmedium.com/bm.pix/product-assets.16x9-1000.png 1000w, https://bigmedium.com/bm.pix/product-assets.16x9-500.png 500w, https://bigmedium.com/bm.pix/product-assets.16x9-250.png 250w" sizes="(min-width: 1050px) 1050px, 100vw" title="Click to enlarge" /></a> <figcaption class="bmc_caption"> The product layer consists of the production files that integrate design system components into end-result design files and application code. </figcaption> </figure> <h5 id="productdesignfiles">Product design files</h5> <p>Product designers working at this layer would spin up Figma files that subscribe to:</p> <ul> <li>The design systems Foundations library with the appropriate theme applied</li> <li>The design system’s UI component library</li> <li>Any relevant recipe library</li> </ul> <p>With all of those tools at their disposal, designers can go about their business designing product-specific screens and flows. </p> <h5 id="framework">Product codebase powered by</h5> <p>For organizations building React apps, here’s where you’d find apps powered by Next.js/Express/Remix/Gatsby/whatever. It’s at this layer that <a href="https://bradfrost.com/blog/post/front-of-the-front-end-and-back-of-the-front-end-web-development/">back-of-the-front-end things</a> like business logic, routing, state management, and cache invalidation come into play. </p> <p>Product codebases consume as dependencies the appropriate framework flavor of the design system’s component library, any applicable recipe packages, and any smart components. A <code>package.json</code> file could look something like this: </p> <pre><code>&quot;dependencies&quot;: { &quot;@your-org/design-system-name&quot;: &quot;^0.1.0&quot;, &quot;@your-org/marketing-site-recipes&quot;: &quot;^0.1.0&quot;, &quot;@your-org/smart-form-components&quot;: &quot;^0.1.0&quot; } </code></pre> <p>With these packages installed, product engineers can pull in design system components and recipes into their projects like so:</p> <pre><code>import DsButton from &quot;@your-org/design-system-name/Button&quot;; import SiteHeader from &quot;@your-org/marketing-site-recipes/SiteHeader&quot;; import TextField from &quot;@your-org/smart-form-components/TextField&quot;; &lt;SiteHeader /&gt; &lt;form onSubmit={handleSubmit(onSubmit)}&gt; &lt;TextField label=&quot;Email&quot; /&gt; &lt;TextField label=&quot;Password&quot; /&gt; &lt;DsButton variant=&quot;primary&quot; text=&quot;Sign in&quot; /&gt; &lt;/form&gt; </code></pre> <p>The <code>SiteHeader</code> is provided by the recipe package. The <code>TextField</code> is coming from the smart component package that handles the form logic. And the <code>DsButton</code> is coming from the design system. The ecosystem provides all of the look and feel and even some common functionality, which frees up product developers’ time to focus on bringing the application to life. </p> <h5 id="framework">Product codebase not powered by</h5> <p>Products that aren’t based on React/Angular/Vue/whatever can consume the design system’s Web Components directly, either via npm/yarn or even by pulling them into a regular ol’ webpage.</p> <pre><code>&lt;head&gt; &lt;link rel=&quot;stylesheet&quot; href=&quot;ds.css&quot; /&gt; &lt;script type=&quot;module&quot; src=&quot;ds-web-components.js&quot;&gt;&lt;/script&gt; &lt;/head&gt; &lt;body&gt; &lt;ds-button variant=&quot;primary&quot; text=&quot;Hello&quot;&gt;&lt;/ds-button&gt; &lt;/body&gt; </code></pre> <p>It’s worth stepping back for a second to marvel that the design system’s web component source of truth can power any web-based digital product — irrespective of tech stack. It’s incredible! And because these are directly consumable components, improvements and additions can be deployed simply by pulling down the latest version of the library. </p> <h5 id="iosandroidnon-webproductcodebases">iOS/Android/Non-web product codebases</h5> <p>As we’ve already covered, native apps are likely written in non-web languages, which means they can’t share in the web component goodness. Native app environments would pull in their own flavors of the component library as dependencies.</p> <h3 id="it’sthateasyfolks">It’s that easy, folks!</h3> <p>Whew, what a ride, huh!? We’ve gone deep into the weeds, so let’s zoom out a bit. A mature design system ecosystem for a complex organization may not be simple, but this layer-cake approach provides a robust way to orchestrate UI for designers and developers across the company. The word “ecosystem” is apt here; these are interconnected systems that all play an important role in powering the UI of a company’s digital products.</p> <p><strong>It bears repeating that every piece articulated here doesn’t apply to every organization.</strong> We’ve explained that most of these layers are optional and can be added iteratively. Start simple and iterate your way to a more complex ecosystem as real needs arise.</p> <h3 id="it’speople">It’s People!</h3> <p>Here’s the fun part: you can craft all of these layers and assets and the whole thing can still fall to pieces. <strong>Design systems are less about assets and their relationships to one another, but more about people and their relationships to one another.</strong></p> <p>What we’ve covered here simply defines the ingredients and relationships between the different assets of a design system ecosystem. Of course, it’s human beings that hold it all together. We’ll be following this article up with others that detail the <em>human</em> relationships and processes that make this whole Rube Goldberg machine work. Also, I’ll update this post with demos we’re putting together to show examples of nearly every piece of this vast ecosystem. </p> <p><em>Do you see yourself in this post? We’d love to hear about how you’re defining and managing your organization’s design system ecosystem. And hey! Do you need help figuring out how to make all of this work? At Big Medium, we help complex organizations plan, architect, build, evolve, and manage design systems and other aspects of big design at scale. Feel free to <a href="https://bigmedium.com/hire/">get in touch</a>!</em></p> </div> <!-- end bmw_pageContent --> Mon, 16 Oct 2023 13:30:00 UT https://bigmedium.com/ideas/design-system-ecosystem.html df0b8e57cad9b3877b27ea0e81b70903-1603 workflow process web design brad frost design system webdev Ideas Brad Frost Brad Frost <div class="bmw_pageContent"> <figure class="media-right bmc_image"> <a href="https://bigmedium.com/bm.pix/brad-frost-speaking.jpg" rel="bm_lightbox" title="" target="_blank"><img src="https://bigmedium.com/bm.pix/brad-frost-speaking.orig-250.jpg" alt="Brad Frost speaking" srcset="https://bigmedium.com/bm.pix/brad-frost-speaking.orig-2000.jpg 1280w, https://bigmedium.com/bm.pix/brad-frost-speaking.orig-1000.jpg 1000w, https://bigmedium.com/bm.pix/brad-frost-speaking.orig-500.jpg 500w, https://bigmedium.com/bm.pix/brad-frost-speaking.orig-250.jpg 250w" sizes="(min-width: 1100px) 690px, (min-width: 830px) 501px, (min-width: 640px) 380px, 100vw" title="Click to enlarge" /></a> </figure> <p>Brad Frost is principal and technical strategist at Big Medium. He created the Atomic Design methodology and taught the industry design-system architecture. He architects design systems, develops front-end code, establishes collaborative workflows, and helps teams create better software together.</p> <p>Brad is author of the book <a href="https://atomicdesign.bradfrost.com">Atomic Design</a> and has helped create several tools and resources for people who create and manage design systems, including <a href="https://patternlab.io/">Pattern Lab</a>, <a href="http://styleguides.io/">Styleguides.io</a>, <a href="https://bradfrost.github.io/style-guide-guide/">Style Guide Guide</a>, and <a href="https://bradfrost.github.io/this-is-responsive/">This Is Responsive</a>. He co-hosted the <a href="http://styleguides.io/podcast/">Style Guide Podcast</a>, and he shares ideas with astounding frequency at <a href="https://bradfrost.com">bradfrost.com</a>.</p> <p>Brad and his family live in beautiful Pittsburgh, PA.</p> <p><strong>Stay in touch:</strong></p> <ul> <li><a href="&#109;&#97;&#105;&#108;&#x74;&#111;&#x3a;&#x62;&#x72;&#97;&#x64;&#x40;&#x62;&#x69;&#103;&#109;&#101;&#100;&#105;&#117;&#109;&#46;&#x63;&#111;&#109;">&#x62;&#x72;&#x61;&#x64;&#64;&#x62;&#x69;&#103;&#109;&#101;&#x64;&#105;&#x75;&#x6d;&#x2e;&#99;&#x6f;&#109;</a></li> <li>Twitter / X: <a href="https://twitter.com/brad_frost">@brad_frost</a></li> <li>Mastodon: <a href="https://mastodon.social/@brad_frost">@brad_frost</a></li> <li><a href="https://www.linkedin.com/in/bradfrost/">LinkedIn</a></li> <li>Github: <a href="https://github.com/bradfrost">bradfrost</a></li> <li>Instagram: <a href="https://www.instagram.com/brad_frost/">@brad_frost</a></li> </ul> </div> <!-- end bmw_pageContent --> Tue, 12 Sep 2023 20:54:05 UT https://bigmedium.com/about/brad-frost.html df0b8e57cad9b3877b27ea0e81b70903-1602 About