Watching vicariously as others experience amazing music for the first time brings me so much joy. Sure, it’s entertaining, but it also feels like some form of reality hack that allows you to go back in time and revisit your own feelings when you experienced certain music for the first time.
Music is deeply ingrained in us and many of us can recall in great detail the specific memories around when we first heard some of our most favorite music. Music is some powerful shit! It hits us in our soul and moves us is ways nothing else can. That’s why I find these videos so beautiful and entertaining.
I feel like this guy hearing Rage Against the Machine for the first time may have been the first “people hearing music for the first time” video I watched. There are scores of videos like this, and they are incredible even taken at face value. Sure this isn’t a true fly-on-the-wall scenario; the camera pointed at someone undoubtedly encourages them to exaggerate their response. But the reaction is incredible nonetheless. Music conjures something up in us; it pokes at us and forces us to react. To be able to witness that reaction is amazing. I love it.
One of my favorite things to do (though sadly it’s a rare occasion) is to actively listen to music with my friends. When playing my favorite music for others, and I carefully study their reaction and eagerly await their commentary. Music is glue that bonds us even closer together with the people we love. We’re not only interested in our own dopamine hit; music is something we feel compelled to share with others.
What’s cool is how the “people reacting to music” category has seemed to evolve and expand. For instance, my daughter and I recently watched tribal people from Sindh, Pakistan experience Stairway to Heaven for the first time:
It’s tremendous to see how culture is transmitted and received across time and space; it’s so cool to witness others making connections to their own lived experience and cultural references. I feel like this cross-cultural reaction video embodies the spirit of both the universal nature of music as well as the ideals of the World Wide Web. I freaking love it.
And now we enter the sub-category of “musical people hearing music for the first time”, which introduces a wonderful new lens to all of this. In addition to getting their visceral emotional reaction of the music, musicians are able provide an extra dimension of analysis. They’re able to articulate why certain parts of a song hit a certain way, break down the music theory, and connect a song to its musical lineage:
And then taking it to a whole other level is a sub-category where ridiculously-talented musicians hear a song for the very first time, listen exactly one time, and then proceed to PLAY IT PERFECTLY NOTE-FOR-NOTE. Even if you’re not a drummer, do yourself a favor and witness Snarky Puppy drummer Larnell Lewis absolutely shred Metallica’s Enter Sandman after hearing it just one time. Just jaw-dropping musical knowledge and expert-level retention skills on full display:
Taking this supernatural exercise to the next level is having an expert musician hear a song minus the part they’re to play. Here’s Justin Raines hearing The Trooper by Iron Maiden for the first time sans bass line and then proceed to play an incredible (and incredibly close!) bass part to the song. Just absolutely amazing:
These videos are something else, and I find myself eating them up. To me, these reaction videos really underscore why music such an incredibly powerful force. I’m here for it!
]]>If you’ve dabbled in design systems then you’re no doubt familiar with Brad Frost and atomic design. He’s laid the foundation for design systems teams around the world. So in this discussion we talk about the types of challenges he faces at Big Medium and how he’s envisioning the future of design systems: Why we should build a universal design system How Brad is using AI to elevate design systems How design systems designers can succeed in an AI world The highest leverage activities for DS designers to
I had a great time chatting with Michael Riddering on the Deep Dive podcast. We covered a lot of ground, including:
So write! Share! Publish!
But you know what? Screw what the world needs.
If we’re going to be hardnosed about this, then the world doesn’t need any more books. The world doesn’t need any more music. The world doesn’t need art. Heck, the world doesn’t need us at all.
So don’t publish for the world.
When I write something here on my website, I’m not thinking about the world reading it. That would be paralyzing. I do sometimes imagine that one person is reading it; someone just like me who hasn’t yet had this particular thought, or come up with that particular idea.
I couldn’t agree more. Mr Rogers comes to mind: “You are the only one like you.” Even if you feel like everything’s been said before, your perspective is wholly unique and valuable. So write! Share! Publish!
]]>
Luke and Michelle dive into the pros and cons of the idea of a global design system.
]]>As we speak, the battle that platforms are fighting is against generative spam, a cartoonish and obvious threat of outright nonsense, meaningless chum that can and should (and likely will) be stopped. In the process, they’re failing to see that this isn’t a war against spam, but a war against crap, and the overall normalization and intellectual numbing that comes when content is created to please algorithms and provide a minimum viable product for consumers.
Are We Watching The Internet Die? is quite the read. It’s been a decade since I made Death To Bullshit, and it’s clear that generative AI is unleashing a torrent of bullshit on the world. This post does a great job articulating this phenomenon.
]]>I was recently a guest on the CodingCatDev podcast, where we covered a lot of ground around design systems, including the design system ecosystem, the idea of a Global Design System, and many of the challenges teams face when creating successful design systems at an organization.
]]>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.
I’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:
I was recently a guest on Ben Callahan’s The Question, and he posed the question “should there be a Global Design System?” The results were overwhelmingly positive:
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’t so naive to believe the creation of a Global Design System wouldn’t be without plenty of effort, alignment, and challenges.
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! Chris Coyier published a great post that sums up a lot of it, and we were able to dive into things together on ShopTalk Show. In this post, I’d like to dig into of the feedback and skepticism, and also share an update on some of the progress that’s been made so far.
I’ll go through some of the themes that I heard and address them as best as I can. Here goes!
Isn’t every open-source design system a “global design system”? Aren’t the people making them trying to make them as useful as possible for as many people as possible? If that’s right, and thus they have failed, why did they fail? What are they doing that doesn’t map to the philosophy of a global design system?
This is true! Open source design systems aim to be useful for as many people as possible. In my original post I explain some of the challenges of existing solutions:
- These solutions were (understandably!) created with a specific organization’s specific goals & considerations in mind. 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.
- They nearly always come with a specific default aesthetic. 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.
Existing solutions haven’t “failed”, 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’t a terrible thing, it still leads to duplicative effort and requires consumers to go comparison shopping when searching for a sound solution.
A Global Design System is less about the “what” and more about the “who” and “where”. 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.
Isn’t HTML the Global Design System? Shouldn’t missing components simply be added to HTML? I discuss this at length in the original post:
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. What we need now are more prefabricated UI components that abstract away much of the close-to-the-metal HTML and give developers composed, ready-to-use modules to drop into their projects.
In my opinion, HTML already has what we need, and it could be overkill to flood the HTML spec with <badge>
and <card>
and <textfield>
and <alert>
et al. Popular design system components tend to be more opinionated compositions 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:
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.
Unsurprisingly, this classic XKCD comic has been brought up plenty of times after I’ve shared the idea of a Global Design System:
One of the most challenging aspects of articulating this idea is that it differs from the current paradigm. The proposal isn’t to create a better Bootstrap. The proposal isn’t to create an alternative to HTML. In my view, there’s a layer missing in between the base HTML layer and the myriad design system implementations out there:
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.
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.
Don’t get me wrong: creating a design system for the world would be hard work. But! While HTML needs to account for every possible use case, a Global Design System could aim to handle common use cases. From my earlier post:
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 has to account for all use cases, where a Web Component library can limit itself to the most common use cases.
After all, this is what we see in design systems all over the world. A design system doesn’t (and shouldn’t!) provide every solution for all tabs, all buttons, and all cards, but rather provides sensible solutions for the boring, 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.
Ah yes, the age-old “design systems are killing creativity” trope.
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:
The decision to make a door sky blue with fancy brass hinges or white with matte black hinges is a separate concern from “does the door open and close?”. A Global Design System would contain the proper semantics, relationships, accessibility, functionality, but leaves styling largely out of the equation. Think Global Design System + CSS Zen Garden. Thanks to CSS custom properties, design token values can flow through the Global Design Systems components to accomplish any look and feel:
On the ShopTalk Show, we got into theming 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 Open Props-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’s important that the system is “theme-less” default.
In the original post, 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:
<www-text-field
label="Email Address"
type="email"
required>
</www-text-field>
Setting aside the specific details like attribute names (which would require careful research and consideration), the gist is that a Global Design System’s Web Component library would deliver the component markup, behavior, and any core styles to user developers. Developers would interface with each Web Component’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’s web experiences.
The unfortunate reality is that Web Components currently require JavaScript to deliver this abstraction. What would be awesome is to be able to simply wire Web Components up and have them Just Work, even if JS fails for whatever reason. It would be awesome if something like this Just Worked:
<script type="module" src="path/to/global-design-system.js"></script>
<form>
<www-text-field label="First name"></w3c-textfield>
<www-text-field label="Last name"></w3c-textfield>
<www-text-field label="Email" type="email"></w3c-textfield>
<www-textarea-field label="Comments"></w3c-textfield>
<www-button variant="primary">Submit</w3c-button>
</form>
Thankfully, much work has been done around server-side rendering for Web Components and solutions exist. 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.
And much as I love many peoples’ excitement around HTML Web Components, this technique defeats the purpose of removing the burden of markup on consuming developers, doesn’t create clean abstractions, and complicates the delivery of updated design system components to users. There’s more to say about Web Components but that’s a post for another day.
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’d hope that this whole effort could serve as a lens to make Web Components even more awesome.
In Chris’s article, he wonders if a Global Design System would need to be so “flexible to the point of being useless.” 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. Bootstrap’s card, Material’s card, Lighting’s card, and other cards don’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.
Lol, yep.
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, the challenges have everything to do with orchestrating and aligning people.
As mentioned before, this effort is more a matter of “who” and “where” than “what”. 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’s just to get the thing off the ground!
This feels like a good segue into a status report and next steps on this whole effort.
Since publishing my post, I was able to connect with the inimitable Greg Whitworth, the chair of OpenUI. 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, research, component matrix, and proposals have paved the way for standardization of widely-implemented UI components.
They’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’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’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’m glad we’re having them!
I’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:
(Keep in mind this often isn’t a linear process; selling is never done!)
The creation of a Global Design System would follow this same process, albeit through a different lens. We’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! They have a Discord; you can join too and get involved.
Many, many people have reached out with some form of “I have insights/research/design/code I’d love to share whatever would help this effort.” 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’s all very encouraging.
I truly feel like we can dramatically improve the world’s web experiences while making better use of our collective human potential. I’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.
]]>As organizations race to deliver best-in-class digital experiences to their customers, the ability to innovate has become essential. Building a strong foundation is no longer the end-all-be-all to success; it’s also the ability to reimagine what’s possible tomorrow that truly sets organizations apart from their competition. We talked with design systems experts, owners, and builders for our latest ebook to share: Why investing in a scalable design system can transform your business How fast-growing teams
I had the opportunity to be interviewed for Webflow’s Evolving Design Systems whitepaper (ebook? it’s something!). I contributed my thoughts on the evolution and benefits of design systems, the nature of atomic design, and how AI might impact design systems.
]]>Why do we see so little reuse of web UI across organizations? Web projects freely use countless open libraries from npm and elsewhere, but it’s rare to find high-quality web UI code which is flexible and reliable enough for immediate reuse. This makes creating great user experiences both difficult and expensive.
This fantastic talk by Jan Miksovsky from 2019 does a fantastic job describing the current state of UI design/development, and articulates much of the rationale for the creation of a Global Design System. I found myself nodding along with this entire talk, and he naturally spends a fair amount of time describing how Web Components can be enlisted to help us all create and share sturdy solutions for common UI components.
]]>As we all know, design systems have proven to be effective tools that help organizations ship higher-quality user interfaces more efficiently. We’re finding that this new crop of AI tools can help supercharge design system efforts across many categories, and we’re starting to help our clients use AI to do exactly that. Our resident AI expert, Kevin Coyle, has been leading the charge in this wild new landscape, and we’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’ll demonstrate some of the ways we’re applying AI to the world of design systems, including:
Of course, these are only some of the potential use cases and there’s plenty more potential still to explore. Let’s dig in!
One of the most obvious examples of AI for design systems is to generate design system component code. Last year, I wrote that AI could be trained to act on instructions like this:
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.
Turns out this is absolutely possible:
When you train a LLM on a design system’s codebase, conventions, syntax and documentation, you get a component boilerplate generator on steroids. 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. We guestimate this approach could help developers create components 40-90% faster than manually writing things from scratch.
It’s important to underscore that the AI can be trained on existing — often bespoke — conventions, technology choices, and language preferences. In our work across organizations of all shapes and sizes, we’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’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’re skeptical of general-purpose AI code generators and err on the side of solutions that are closely tailored to the organization’s hard-won conventions and architecture.
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? Without the help of AI, translation is a labor-intensive and error-prone manual effort. But with AI, we’ve dramatically reduced both effort and error when migrating between tech stacks.
The video below demonstrates AI converting a badge Web Component built with LitElement into a React component in a matter of a few keystrokes.
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’s conventions.
This is powerful! Working with AI has brought our team closer to a true “write once, deploy anywhere” reality. Similar to how tools like Prettier 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—and port the code accordingly.
We’ve leaned on AI to assist with translating components to work with proprietary conventions in specific popular platforms. For example, we’ve used AI to convert a more standards-based <a>
tag into Next.js’s <Link>
convention in a way that preserves a clean source of truth while also leaning into platform-specific optimizations.
It’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.
As we’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 — whether human or AI generated — is high quality and achieves the desired effect? We like to think of AI as a smart-but-sometimes-unsophisticated junior developer. That means we need to review their work and ask for revisions, just as you would with a human developer.
Testing and QA are critical activities that help ensure that a design system’s codebase is sturdy and sound. Setting up AI automation for this can also help keep us honest when the pressure is on. 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.
Unit tests are a special kind of chore that always felt like pseudo-code to me. “Click the accordion; did the accordion open? Now click it again; did it close?” Manually writing unit test code is something we’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.
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!
There are many great accessibility testing and auditing tools out there; AI adds another layer of accessibility QA to the puzzle:
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 “pass vs fail” checklist, AI-powered accessibility testing can integrate your organization’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!
Here’s the painful truth about documentation: nobody likes authoring it, and nobody likes reading it. But documentation is also critical to a design system’s success. I liken it to Ikea furniture construction: sure you could technically build a piece of furniture with only the parts on hand, but you’ll likely screw it up, waste time, and get frustrated along the way. Maybe AI can help solve the documentation paradox?
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’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’s all a pain in the butt to create. Moreover, documentation risks falling out of sync with the design system’s design and code library, which erodes the trust in the documentation and the design system as a whole.
If LLMs can generate entire novels, they certainly would have no problem generating some words about some well-trodden UI components. 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). And just as with code generation, LLMs can learn your organization’s specific conventions so documentation is custom tailored to your reality. Pretty dang cool.
Moreover, when this AI-powered documentation is wired up to the teams’ workflows, the documentation can always represent reality and doesn’t get stale.
In Douglas Adam’s Hitchhikers Guide to the Galaxy, a Babel fish “can be placed in someone’s ear in order for them to be able to hear any language translated into their first language.” Indeed, many emerging AI technologies get awfully close to the sci-fi dream of real-time language translation. But beyond linguistic language, design systems need to account for language differences between disciplines, experiences, and other contexts.
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’t it be cool if design system documentation morphed itself into a form that’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.
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. AI can address this by tailoring the design system’s documentation to the individual: their discipline, their skill level, their context, and yes even their preferred spoken/written language.
Perhaps this AI-powered personalized guidance can help design systems realize the lofty goal of delivering a shared vocabulary across a digital organization?
As we’ve demonstrated here, AI tools can supercharge many facets of design system work. Of course it’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. A human-centric mindset along with a healthy level of skepticism (especially in these early days!) should be employed when wielding these new tools.
At Big Medium, we’re formulating some guiding principles and important considerations as we dig into these technologies:
Of course, these principles and considerations aren’t exhaustive, and we fully expect them to change and evolve as the landscape continues to shift.
As we’ve demonstrated here, there’s so much potential to integrate AI into many facets of design systems work. What we’ve shared is by no means comprehensive; for instance, we haven’t shared much around how AI impacts the world of UX and visual designers. There’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’s play. And of course we’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 — along with the rest of the world! — will be shaped by the evolution of AI technologies.
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 get in touch!
]]>And then she asked an interesting question: Is it art if it wasn’t your idea? I was glad to answer “yes,” and explain to her why — that all art is a copy of something — though I wish I’d had the presence of mind to ask her a question beforehand, like, “If I drew a picture of you, would it be art?” My explanation was that all art is a response to something. Sometimes an artist will see a beautiful landscape and try to express that beauty with paint on canvas or by taking a photograph. It’s a copy, in a way,
“All art is a copy of something”. “all art is a response to something.” Nothing exists in a vacuum. Great stuff. Periodical 15 – Christopher Butler
]]>I love me some Vulfpeck. Especially the music. But also the aesthetic and really the whole package.
This piece of commentary is great for a number of reasons, including his sensible proposed change in business model around music.
But the main reason I’m sharing this is when he speculates about future disruptions to music. He says:
Is it AI? No no no, humans are obsessed with humans making music. Ya know, that’s the base layer.
The keyboardist in Vulfpeck, Woody Goss, he’s getting spooked by AI in music, and he said “you know what? [he plays chess] Computers have been beating humans in chess for a little while now, but the sport of chess is bigger than ever.”
And I said “yeah you’re right; that is what people love about music. They want to rally around a human.” I’m sure a robot could jump higher than someone or is a better gymnast, but are we tuning into the robot Olympics? No, we like humans.
I think that gets at the philosophical heart of all of this emerging AI. Zooming way out, humans care about humans. AI can generate billions of images, movies, songs, books, whatever, and I bet at least some of it will be good! And it will likely continue to get better! I bet AI’s creative output will activate the same pleasure centers in our brains that human-produced work activate.
But there is no AI substitute for a human belting out some lyrics and baring their soul to the world in front of an audience of people. There’s no AI substitute for a human-produced drawing of someone on the subway, even if a similar-or-even-better result could be produced in seconds by AI. The artifact is often less important than the process — the human process — that made it. That’s why I suspect videos of creative processes are so attractive; we are captivated by seeing humans doing human things.
It is the act of human expression that intrigues us and connects us to one another. By expressing ourselves, we share our humanity with the world. When that is received and reciprocated by others, we create a feedback loop of our shared humanity. In my view, that’s one of the most powerful effects of art.
]]>Chris spells out a lot of tough questions and challenges around bringing something like this to life, and his conclusion sums things up quite nicely:
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 to realize the potential, I think you need to ask really hard questions and have really strong answers. Ultimately I sincerly 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.
I’ll sink my teeth into some of Chris’s questions in a forthcoming post! What a fantastic way to advance the conversation.
]]>There’s no particular “hair on fire” problem that design systems solve that instantly sells to management.
It’s really only through what Dave calls “Event Triggers” that organizations perk up and pay attention to the value that design systems can bring:
In Dungeons & Dragons and other action economies there’s a concept of “Event Triggers”. For example, a treasure chest looks like a normal treasure chest but turns into a monster when you try to open it. An event (opening the chest) exposed a problem (a monster) and now you need a solution (might and magic) to solve the problem. Design systems are a similar mechanic because the problems they solve are almost theoretical until you trigger an event.
Here’s some event triggers I’ve come across in my years of design systems work…
- Marketing commissioned a new logo, brand, and design language
- Oh, those brand updates rolling out in TV commercials next month
- Oh, and we’re launching a new line of hardware tablet devices
- The great re-platforming initiative
- An accessibility lawsuit
- A font license lawsuit
- Good design, poor code implementation
- Interface inventory reveals 60 different buttons and 12 site headers
- The CEO gets fired and you need to remove his face from the entire site
- 10 designers with high autonomy and no design review process
- 10 engineers with high autonomy and no design review on code changes
- One department with more autonomy than the other because it “makes the money”
- Company wholesaled the entire off-shore team and 150 new people start next week
- A year of heavy turnover and the time bomb of technical debt goes off
Getting buy-in for design system as a standalone thing can be incredibly challenging, so riding the wave of other “hair on fire” issues can be a great way to bot address urgent issues and put critical front-end infrastructure in place. As my partner Josh Clark recently shared in his post Digital Leadership In Lean Times:
]]>Position your work as asset creation, not operational expense. 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.
I was recently talking with Chris and Dave on the ShopTalk Show and they did a pretty good job pitching it:
I mean, just look at the epic Frostapalooza concert poster designed by Roberlan:
To say I’m excited about this show is a severe understatement. For the past 6 months, over 40 musicians spread across states and continents have been planning, scheming, and practicing for one epic night of music and shenanigans. It’s been so incredibly hard to keep all of the great stuff that everyone’s been producing under my hat, but that’s what needs to happen to make the show have its desired effect.
So yeah! Come to Frostapalooza. Get your tickets here. You’ll have a great time!
]]>We also were able to talk about Frostapalooza, the big-ass benefit concert I’m throwing on August 17th. Chris and Dave will be performing at the show, and Chris did a good job pitching it on the show! You should come! You can get your tickets here.
]]>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.
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.
So what will you get? Lots of signal, no noise; the newsletter is certified spam-free. Sign up to receive links to Big Medium’s latest ideas, case studies of recent projects, and, sure, hot takes on process, technique, and technology from the industry’s best.
Ever since the social media landscape imploded & splintered, we’ve been looking for ways to connect with people and be able to share valuable stuff on our own terms. This newsletter is one way we’re making that happen; I’m excited!
The first edition of “A Little Big Medium” drops tomorrow! If you’re interested, we’d love it if you sign up over here. Thanks!
]]>The most crucial mistake in the collaboration between designers and engineers happens when we conflate this division of tools with a need for a strong division of labor. Treating design and engineering as two completely separate processes leads to an isolated waterfall workflow where designers first get to dream up ideas in static tools, and engineers then implement the desired features when they are ready for development. The design handover, this supposedly magic moment where design has finished and engin
The Gulf Between Design and Engineering beats one of my favorite drums: the broken design/developer workflow. There are some great nuggets in here, including some principles for better workflows:
]]>
- Flatten your waterfalls
- Make code the design product
- Operate like an open source project
- Increase visibility through automation
- Plan like a farmer
I found this to be incredibly captivating.
]]>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!
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:
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:
Designing, building, and maintaining a bespoke user interface for each individual digital product is expensive, inefficient, and fraught. And so a chorus of voices rings out across organizations the world over: “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!” This is the rallying cry for what we have come to know as design systems.
Over the past ~10-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.
With a design system in place, 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. 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!
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. Our efforts to reduce duplicative work at the individual level are resulting in duplicative work at the inter-organization level.
This phenomenon is understandable: organizations are trying to bring order where they have influence. (We see this within 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: now we have a meta design system problem.
Right now, vast numbers of human beings are devoting their time and energy to designing, building, documenting, and maintaining the exact same set of common components. 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. Form fields that associate labels with their respective inputs. Alerts that communicate success, error, warning, and information status. Dialogs and tooltips and drawers oh my! By and large, these components are unexceptional commodities that assume the same general shape and behavior 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.
These basic UI components are tricky to get right. Looking across the World Wide Web, 0 of the top 100 websites use valid HTML, and our collective accessibility game is abysmal. The WebAIM Million project crawls the top million websites and reliably delivers a depressing annual report about the state of website accessibility:
Across the top one million home pages, 49,991,225 distinct accessibility errors were detected—an average of 50.0 errors per page.
WebAIM Million
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.
All of this duplicative work yields experiences that still suffer serious quality deficiencies, and there are even more wrinkles to consider. Each design system is isolated and disconnected, 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.
So what are we to do? Let’s return to our wise design systems rallying cry: “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!”
Only now let’s redirect that rallying cry outside of any individual organizations’ walls and apply it to the world at large.
When the design system is boring, it frees designers and developers to do the new stuff, to solve new problems. The design system carries the burden of the boring, so that designers and developers don’t have to.
Josh Clark
There is a massive opportunity to save the world’s designers and developers millions upon millions of hours, freeing up time and human potential to work on far more pressing problems than making an accordion open and close.
There’s a massive opportunity to dramatically improve the accessibility, semantics, and overall quality of the world’s web experiences.
There’s a massive opportunity to harness the collective brain power of the world’s best and brightest.
There’s a massive opportunity for the web community to demonstrate to a volatile world what true worldwide collaboration and cooperation looks like.
I think there’s a massive opportunity to create a Global Design System.
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.
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.
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!”
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:
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 a lot of room for error in this process; it’s a bit like drawing the rest of the owl.
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. What we need now are more prefabricated UI components that abstract away much of the close-to-the-metal HTML and give developers composed, ready-to-use modules to drop into their projects.
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 back-of-the-front-end developers?
A Global Design System can also serve as an incubator or test kitchen for new HTML elements or properties. We see this with recipes in the layered design system ecosystems 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.
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.
This instinct makes a ton of sense! Great artists steal, and there’s a real pragmatism in reaching for existing, sturdy work. However, adopting someone else’s design system surfaces two important issues:
Projects like Headless UI and react-aria 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.
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. 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.
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?
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.
A Global Design System would be a common library containing common UI components currently found in most design systems (Shout out to the brilliant Open UI project for this epic matrix!). In order to be successful, these components would need to be:
Given the above principles, I think it would make sense for the Global Design System to be a library of Web Components. 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.
Web Components for a Global Design System could look something along the lines of these examples:
<w3c-text-field
label="Email Address"
type="email"
required>
</w3c-text-field>
<w3c-alert variant="error">
<w3c-icon name="stop" slot="icon"></w3c-icon>
Your credit card is expired. Please update your information.
</w3c-alert>
<w3c-button-group>
<w3c-button variant="primary">Log In</w3c-button>
<w3c-button>Cancel</w3c-button>
</w3c-button-group>
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.
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.
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.
I think there are a few special callouts for what a global design system wouldn’t be. A Global Design System wouldn’t:
I tend to define a design system as the official story of how an organization builds user interfaces. 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:
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!
From my perspective, an organization like the W3C would be the best home for something like this. Their mission is pretty hand-in-glove with this whole idea:
The World Wide Web Consortium (W3C) develops standards and guidelines to help everyone build a web based on the principles of accessibility, internationalization, privacy and security.
It’s also worth mentioning the amazing Open UI project, which has been doing a lot of the hard legwork on rounding up common UI components across many popular design systems. 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.
A Global Design System would need to consist of a set of assets that include:
Where exactly those things would live is determinant on a whole slew of factors, so we can leave it here for now.
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:
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!
I’ve had the opportunity to speak about this topic at several conferences, 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.
I think that a Global Design System has the potential to transform how web designers and developers do their jobs.
When I talk about design systems, I often talk about respect and human potential. 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!
If a Global Design System existed, what would design system teams do? While I understand anxiety around being replaced (hey, we hear this about design systems from product designers & developers all the time), there’s still plenty of work to do. I find this tremendously exciting: design system teams would be freed up to focus on more interesting aspects of creating great digital products than simply component construction.
Plenty of the current work would remain:
But there would also be a huge opportunity to free teams up to focus on bigger-picture issues. In our work at Big Medium, 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, but too often gets lost in the ground-level work of component production. With a Global Design System in place, teams could:
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.
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?
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!
]]>I don’t know how else to answer this, besides: the gendering of design as women’s work is why people don’t use the title “web designer” anymore. It’s been belittled and othered away. It’s why we’ve split that web design role into two; now you’re either a UX designer and you can sit at that table over there or you’re a front-end developer and you can sit at the table with the people that build websites.
What a great post by Heather Buchel: It’s 2023, here is why your web design sucks. She’s hitting on a really fundamental issue with how the worlds of web design and development have progressed. Huge gaps have emerged as the role of “web designer” has splintered into “UX/product designers” and “front-end developers”.
I describe web designers (or frontend designers, or front-of-the-front-end developers) as “mortar people” who ooze between the gaps in the design/development process. Based on a ton of first-hand experience, this role is desperately needed, but as Heather points out, it’s difficult to hire for because it doesn’t fit neatly into the stratified roles that have evolved over the last ~10-15 years.
]]>This web site presents one reference glyph and basic information for each of the world’s writing systems.
Source: The World’s Writing Systems
]]>If all the company’s plastic from 2021 were converted into plastic air pillows — the inflated pouches inserted in some Amazon packages to reduce shifting during transit — and laid side by side, Miller said it would circle the globe more than 800 times.
This is ridiculous and shouldn’t be happening.
Here’s an idea: bring back the old-school milk man delivery format. Nearly every day an Amazon truck cruises down my street. Amazon should provide households with a reusable bin (bonus: made of their own recycled single-use plastic) similar to the ones I’d unload off of the weekly delivery truck when I worked at CVS as a teenager:
Amazon drivers would deliver goods in these bins, and collect the empty bins from the curb or doorstop or whatever. Just like the milk man.
It’s a tragedy that this isn’t more of a priority. This is the type of problem Amazon should be unleashing scores of designers on. Ruined By Design by Mike Monteiro comes to mind here. It’s a solvable (or at least drastically reducible) problem, and I’d love to see this change.
]]>OUT: An overstuffed design system library
IN: A thoughtful, layer-cake design system ecosystem
OUT: Unnecessarily verbose documentation
IN: Just enough, just-in-time documentation
OUT: Single discipline-focused design systems
IN: Cross-disciplinary design systems that serve the entire org
OUT: Rushing design system work to meet breakneck product deadlines
IN: Establishing pace layers that allow product to move quickly and design systems to prioritize quality over speed.
OUT: Design systems as an off-to-the-side cost center
IN: Design systems as critical UI infrastructure powering business-critical product initiatives
OUT: Ad-hoc, lop-sided, and fragile releases
IN: A thoughtful, transparent, and formal governance process
OUT: Protectiveness and ego
IN: Curiosity, collaboration, partnership, and support
We began our year utterly depleted from managing Melissa’s mom’s cancer treatment; we returned her home right after Christmas and we booked a stay at an all-inclusive resort in Punta Cana. We’ve never done an all-inclusive thing before, and despite our somewhat awkward feeling it was just what the doctor ordered. Ella had a blast and we were able to decompress.
As soon as I got back, I took a trip to Asheville to workshop with Josh about our business together. We’ve been doing great work with a great crew of people for 10 years, so we decided to formalize things! I officially joined Big Medium as a principal and design system consultant! This post explains things in more detail, and I’m extremely proud of the work we’ve done and excited about all the great stuff on the horizon. If your organization could use some help establishing/evolving your design system, scaling your digital organization, pragmatically weaving AI into your process, leveling up your team’s design/development capabilities, or planning other big initiatives, please get it touch!
As soon as I returned from Asheville, we got a puppy! Our home felt incomplete after losing Ziggy in 2022, and we needed some serious doggo therapy. Enter our French bulldog, Bootsy Frost!
Bootsy is now a year old and has now officially grown out of his velociraptor phase. He’s a great snuggler, flips out at balls and projectiles, and is constantly begging for food. He’s a good boy.
We also built a deck in the spring, which was great as we really got to enjoy it as the weather got warmer. I think that about does it for major home projects for us right now! I’m looking forward to smaller, more aesthetic improvements to our place.
In the summer, I took a long-planned 3-month sabbatical, which people were quick to dub my “Sabbradical”. I love it. I was careful not to commit to too much; I really wanted to experience what it was like to wake up and say “I wonder what I’m going to do today?” I got a taste of it! But probably not as much as I would have liked. But I had an absolute blast mostly laying low, working around the house, building things, making art, and most importantly, enjoying summertime with family and friends. A+++++++++ would highly recommend to anyone (The trick is to go way out in your calendar and block it off, then start planning). I’m already thinking about planning another one at some point.
2023 saw a return to some conference travel, including some international events! It was such a great feeling to get back out speaking in front of people and drinking up the whole conference experience. I truly enjoy it so much, and of course since Covid there have been far fewer conferences operating. So I’m thrilled to have been able to speak at Converge in San Francisco, Front Conference in Zurich, Hatch Conference in Berlin, and Smashing Conference in Antwerp, Belgium. These were super special trips and led to some pretty amazing adventures with my family and friends old and new.
Melissa and I traveled together on our first kid-free vacation since our daughter was born, and holy crap we had an amazing time. Front Conference Zurich was an amazing conference; I had a blast, learned a lot, and got to reflect on 10 years of atomic design and what’s next in the world of design systems.
Switzerland was absolutely bananas and totally under-the-radar for us. When thought of exotic locations, Switzerland didn’t pop to the front of my mind for whatever reason. But holy shit it was some of the most epic landscape I’ve ever encountered! We had a blast exploring gigantic mountains, waterfalls (including one INSIDE a mountain!), and glacier lakes. Highly recommend adding Switzerland to your list if it’s not already on there.
And then I came back to Europe in October for Hatch Conference in Berlin, and Smashing Conf in Antwerp, Belgium. Of course the conferences were super well-run and I had a blast delivering a full-day workshop and keynote talk at each of them. It was so great to pal around with my friends and meet new people doing interesting things. Post-Covid, I have a renewed appreciation for conferences and their ineffable beauty. There’s really no substitute for getting together and chatting about your passions with like-minded folks.
It was wonderful to see friends in Berlin and explore the city. I gave my workshop and talk at a beautiful old crematorium that was turned into a venue/cultural center! What a wild experience.
It was my first time to Belgium and I had the opportunity to visit Antwerp. Holy shit, what an amazing place! And once again, totally under-the-radar for me. Antwerp was absolutely stunning, picturesque, and delicious.
In addition to the conference, my awesome Smashing pals even set up a jam session for people from the conference to join. It was so much fun playing music with people coming from all different geographies and musical backgrounds. Music truly is the great uniter, and I’m hoping to try to line up a jam session wherever I go.
The cumulative stress of the last number of years has really taken its toll on us, and unfortunately going from multiple traumatic events to optimal health isn’t like flipping a light switch. I’m so proud of Melissa; she’s been on her own healing journey, adopting a rigorous regular meditation practice and doing a lot of other great therapeutic activities.
I was diagnosed with fibromyalgia this year. That sounds like a big diagnosis, but I learned it’s a diagnosis of exclusion that effectively translates to “you hurt a lot and we’ve ruled some things out”. My chronic TMJ pain that I’ve had for a decade got a lot worse to the point of interfering with my daily life. I just started some steps to address the root cause, and miraculously, just last week my new chiropractor adjusted my jaw and I feel like she dislodged my jaw from my skull. We both yelled “HOLY SHIT!” because of the intensity of the sound and movement. I’m happy to report that right now I can no longer feel my heartbeat in my jaw and feel a lot more comfortable. I’m now working with a TMJ dentist to make these positive changes permanent. For the first time in years, I’m feeling hopeful that I can overcome my chronic pain.
And last, but certainly not least! I’m absolutely thrilled to share that Frostapalooza is taking place August 17th, 2024. I’m using my 40th birthday as an excuse to throw an honest-to-goodness musical extravaganza in the form of a benefit concert featuring me and 40 of my musical friends and family from all over the world. I’m not entirely sure if this is a new type of live music concert, but it sure feels like we’re doing something pretty unique!
Planning this concert has been my obsession for the last 5 months, and I am so incredibly excited about it! It’s already been so amazing collaborating across time and space with my musical friends and family. It turns out I know some really killer musicians! And we have a year to plan one epic night of music. I’ve desperately wanted to share some of what we’ve already schemed and recorded, but it would ruin the surprise! You’re going to want to be there! Tickets are only $20, and the idea is to sell the place out! All the proceeds go to two great causes: Project Healthy Minds and NextStep Pittsburgh.
Seriously, check out this absolutely incredible concert posted designed by Roberlan (thanks to my pal Trent Walton for making it happen!).
I was so inspired by it that I took a stab at turning it into the event website! So yeah: come to Frostapalooza on August 17th in Pittsburgh. I promise you’ll have a blast; I sure as hell know that I will!
Given my family’s history, I’m now particularly nervous about even years. But I feel like I’m slowly rebuilding my optimistic tendencies. Here’s hoping for another year free of any unexpected emergencies. Here’s what I’m looking at getting into this year:
As I mentioned above, I’m tackling my chronic TMJ issues head on and would love to feel more put together in 2024. I’ve found that Frostapalooza has been a great motivator for me to get healthy and strong so that I can optimally rock out in August. So that’s what I’m shooting for!
I’ve been frustrated with myself as I haven’t been able to get into a groove and get shit done. I’ve found myself scattered, foggy, and tired and I don’t like it. Could be the chronic pain, the continued disorientation after being pulled away from work so many times, or some other things I need to explore. But in any case, I need to be able to focus because there is so much I want and need to do! This recent change for the better in the health department has me feeling optimistic that I’ll be rocking and rolling in 2024.
I have a strong desire to share things and put things out into the world, and I’m excited to build up a practice of creating, writing, blogging, recording, and publishing. There’s a lot to be said about the state of social media; I’ll reserve those thoughts for another post. But in any case, I’m hoping that my improved health, a lack of emergencies, and sense of momentum translates to being able to produce and share a lot of cool stuff this year!
As already discussed, I’m absolutely thrilled about Frostapalooza on August 17th. It’s taken a Herculean effort, planning, and coordination on everyone’s part to get this going, but everyone’s sustained enthusiasm has me loving every minute of it. I’m downright giddy about it all, and am excited to share a night of fun and music and dancing and positivity and joy with everyone. So once again, come to the show!
Dovetailing with our Frostapalooza efforts, Melissa and I are finally working on an EP together. The circumstances presented themselves; we’re working with our friend and neighbor Todd Gummermann (keyboardist for Twenty One Pilots and MuteMath) who is producing the album. We have over 15 years’ worth of musical ideas to play with, and we’re having fun making them real songs!
Above all, I’m looking forward to living life and making memories with my family. We’re started 2024 off with a bang by heading over to the Philippines to visit Melissa’s huge family and attend our great friend Robertino’s wedding. It will be Ella’s first time meeting an entire side of her family and connect with her heritage in a big way.
I’m excited to continue down the healing path. We’re in a much better place than we were last year, and I’m hopeful we’re transitioning from “surviving” to “thriving”. I wish that transition for me, my family, you, and everyone in the world.
Whew, so that does it! Thanks for following along; I’m wishing you all health, happiness, safety, and success in 2024 and beyond. Here we go!
]]>This gives me all the web design gallery nostalgic feels.
]]>It’s fascinating to see the song presets laid out using tape and shapes — a nice little system in a pre-digital preset world!
This makes me so happy for a number of reasons:
I decided to post this because this was found on Facebook, and that stuff tends to get sucked into the ether. But it also looks like Talking Heads shared a similar photo on their official Instagram page.
]]>