Josh Clark's Blog, page 7

Ian Frost

Ian Frost is a technical lead for Big Medium. Ian is an accomplished front-end architect and developer, with extensive experience in the construction and management of enterprise design systems.

Ian is also an enthusiastic and patient mentor, helping other developers gain skills and confidence in complex tasks. As the dad of a young son, Ian is also a fan of playing nice with others; he helps foster cross-discipline collaboration between designers and developers through clean process and clear communication.

Before taking up front-end development in 2015, Ian was a professional meteorologist. He is open to all of your weather-related questions, but cannot be held responsible for any bad weather. He maintains a personal blog at ianfrostweather.com.

Ian lives with his family in Pittsburgh, PA. He is dangerous from both the three-point line and driving the lane.

Stay in touchian@bigmedium.comLinkedIn

Jessi Hall

Jessi Hall is executive producer for Big Medium. Jessi organizes our collective efforts���for your team and ours���with crisp project management and clear communication. She pulls people together to create an environment where they do their best work���helping teams focus on solving the right problems at the right time, organizing details, and communicating transparently.

This is more than just “getting stuff done.” Jessi applies deep knowledge and empathy to challenges of process, organization design, and change management. She not only makes sure that projects are successful���her work helps our client companies make future projects successful, too.

Jessi lives in Dallas with her family. They write songs occasionally and cook often.

Stay in touchjessi@bigmedium.comLinkedIn

Online Event: AI and Design Systems

Join Brad Frost (that guy above), Kevin Coyle, Afyia Smith, Ian Frost, and Josh Clark for a lively session exploring AI’s role in design systems.

June 13, 2024
12:00–1:30pm ET
Check your timezone

Sign up for free

This free online event on June 13, 2024, at 12pm ET will introduce you to the many ways AI can supercharge the build and maintenance of design systems.

At Big Medium, we use AI to speed and improve our design system work���and we help our client organizations do it, too. In this session, we’ll share all the ways we use AI for code generation, translation, testing, QA, documentation, and design workflow. Bring your curiosity and burning questions around AI; we’ll discuss how your organization can leverage these new tools in your design system practice.

The Big Medium team will present for around 45 minutes with the rest of the time dedicated to discussion. So bring your curiosity and burning questions around AI; we’ll discuss how your organization can leverage these new tools in your design system practice!

Sign up for free

Interested in other Big Medium events?

Our events newsletter will keep you in the know about other online events and workshops. (Signing up here will also subscribe you to A Little Big Medium, our email newsletter. You can unsubscribe at any time.)

Email Address Interested in: Events (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);

AI and Design Systems

This free online event will introduce you to the many ways AI can supercharge the build and maintenance of design systems.

At Big Medium, we use AI to speed and improve our design system work���and we help our client organizations do it, too. In this session, we’ll share all the ways we use AI for code generation, translation, testing, QA, documentation, and design workflow. Bring your curiosity and burning questions around AI; we’ll discuss how your organization can leverage these new tools in your design system practice.

Stay tuned! We’re still putting the details of the event together, but we will announce everything soon. Meanwhile, sign up below and we’ll notify you when we have more to share.

Sign up for event details Email Address Interested in: Events (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);

(Signing up here will also subscribe you to A Little Big Medium, our email newsletter. You can unsubscribe anytime.)

Don't Put Crap in the Design System

One of my favorite��Josh��lines that’s really stood the test of time and cuts through a lot of noise in a conversation:

Don’t put crap in the design system.

Josh Clark

What is crap?��Crap is rushed work, low-quality work, shortcuts, experiments, first drafts, one-offs, and other unvetted/untested/unverified work.

Let’s be clear:��crap is inevitable. Urgent product deadlines, limited perspective, lack of time to vet/validate approaches, “move fast and break things” cultures, uneven skills, partners with limited perspective, too many cooks, and more contribute to the creation of crap. While some of these reasons are unfortunate, many of the reasons are quite understandable. We all wish we could produce more perfect work, but the realities of time, money, and energy require us all to fall short of perfect. A deadline-strapped developer tasked with creating an accordion component for a specific product feature likely won’t produce the most scalable, holistic, sturdy accordion the world has ever seen.

While crap is an unavoidable part of product design and development, it has no place in a design system.��A design system is critical frontend infrastructure, therefore it needs to be sturdy, reliable, and dependable.��Design systems contain��boring, tried-and-true, vetted, high-quality solutions to common problems encountered at an organization.��When consuming teams encounter crap when working with the design system, trust is broken and the integrity of the system erodes. Those experiences can very much impact the long-term success of the system. For those reasons, a design system needs to be protected from crap.

So how should we handle crap?

how to deal with crapSlow down��– hahahaha kidding not kidding. It can be incredibly hard to slow an organization’s breakneck product delivery pace, but many of the egregious reasons for crap production have a lot to do with trying to do too much too fast. We’ve encountered many organizations making new messes while hastily trying to clean up other messes. Many messes can be avoided by slowing down, but as we all know that’s a lot easier said than done.Establish��a layered UI ecosystem��– A successful UI ecosystem is like a delicious layer cake, with the design system as the base, individual apps at the top, and a few potential (optional) layers in between. With a layered ecosystem in place, the design system isn’t the arbiter of all UI so crap can live at another layer in the stack.Recognize the��design system and products move at their own pace��– The design system shouldn’t rush work to meet breakneck product deadlines, and product shouldn’t slow down to the design system’s pace. Product and the design system layers each need to be able to work at their respective pace, and the design system needs to prioritize quality over speed.Create a recipes layer��in the ecosystem��– A recipe layer allows product teams to create and manage their own patterns, which means that they can be in charge of their own crap. Teams can keep product-specific shortcuts or hacks within their own walls and manage it in a controlled manner.Formalize a��governance process��and prioritize conversation and communication��– Before any production happens, it’s incredibly helpful for product and design system teams to talk. A little conversation can avoid days, weeks, or months of crap production. And because crap is inevitable, the teams can discuss how to create crap in a thoughtful, deliberate way that can then be rectified in the future. Short-term design & tech debt might be necessary, but the teams can put a long-term strategy in place to pay that debt down in the future.Always use��branching��in your workflow��– This is old hat for developers, but design teams are still getting up to speed with this relatively rigorous process. Branching and peer reviews are incredibly helpful at keeping half-baked/experimental crap at bay.

Crap is inevitable, but implementing these tactics can help organizations manage it in a controlled and thoughtful way. At��Big Medium, we help teams sturdy up their foundations: bolstering design and code quality, fixing crucial accessibility bugs, filling in missing unit tests, creating desperately-needed documentation, separating product-specific recipes out from the core design system, establishing sound token architecture, creating codemods, establishing collaborative governance models, improving cross-disciplinary collaboration, and many other��dirty jobs��that come with enterprise software design & development. In short, we’re experts in helping teams take care of crap! If your team would welcome help address some crap,��get in touch!

The Art of Design System Recipes

Recipes are a critical — and often misunderstood! — layer in the��design system ecosystem. First of all, what exactly are recipes?

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.

We see a lot of teams struggle with how to think about, create, and govern design system recipes. This post aims to demystify recipes so your team can successfully wield them to create great design-system powered products. We’ll discuss how recipes:

don’t live in the core design systemhelp teams work at their own pacecome in a few different flavorscan graduate into core design system componentstend to be more complex componentsshould still use design tokensare a great place for collaborationcan be easily added to your architecture

With that windup out of the way, let’s get cooking!

recipes don’t live in the core design system

A core design system contains common components, patterns, principles, and conventions that are to be shared across��an entire organization.��Recipes on the other hand contain UI solutions that may only apply to��a specific��product, product family, or brand within the organization.��Because of recipes’ narrower focus, they live outside the core design system layer.

But why is this additional layer needed?��Without a recipe layer, one of two things can happen:

The core design system becomes polluted��with scores of product-specific components, making the system unwieldy and unusable.The design system team assumes the role of naysayer��in a futile attempt to prevent product teams from creating too much sprawl or deviation from existing design system conventions.

Both of these scenarios are unpleasant and ultimately unsuccessful.��Introducing a recipe layer preserves the integrity of the core design system while also letting product teams do what they need to do.

Adding this layer that on top of a core design system is critical for organizations who need to do support:

Multiple productsMultiple brands (e.g. Global brand, Child brand, Acquisition, etc)Multiple product families (e.g. marketing websites vs SaaS web applications)Multiple product generations (e.g. “legacy” vs “next gen”)

Creating and managing any or all of these necessitates teams being able to work at their own pace.

Recipes help teams work at their own pace

In��Ship Faster by Building Design Systems Slower, Josh Clark asks “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?”

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.

Recipes serve as an important pressure release valve for the natural tension that arises between a design system and the products it serves. A recipe layer gives product teams the autonomy they need in order to make the best products possible while still working with the grain of the core design system.

There are few different flavors of recipes

Recipes can assume a few different forms, which can make it tricky to talk about. They can be:

Compositions of design system components��meant to be used consistently across a product (e.g. a Product Card recipe consisting of a Card, Heading, Button, and Text that come from the design system).Custom components��that are novel inventions (e.g. a starburst badge) or intentional deviations from existing design system conventions (e.g. a deliberately funky button style or sophisticated filtering widget)A combination of design system and custom componentsComponent compositions

Assembling design system components into product-specific compositions is perhaps the most common recipe use case (and is also where the term “recipe” originates).��Certain design system components need to be extremely composable: cards, modals, drawers, headers, and footers come to mind.��They share the same general container structure but the guts of those components can vary wildly across products and implementations.

A design system’s core component library might contain a card container, button, badge, heading, text passage, star rating, and time like so:

Using those same ingredients,��different product teams can create their own compositions to be used consistently across their respective digital products.��The e-commerce team can compose a Product Card recipe, and the analytics team can compose a Customer Data Card recipe, the marketing team can compose a News Card recipe.

Each product team gets the benefits of wielding those core design system components (they don’t have to build all atomic elements from scratch, get visual/UX/front-end best practices for free, etc), but they also get to arrange those components into shapes that are most appropriate for their respective products.

Custom components

This is where we pull the hot sauce from our purses. This is where we substitute olive oil for the lard outlined in our grandmother’s recipe. This is where we sprinkle in a couple extra razzle-dazzle ingredients to our down-the-middle Food Network recipe.

Unlike recipes that merely compose existing design system components, custom component recipes either:

Intentionally deviate from the core design system conventions��(“Our product�� needs ��orange parallelogram primary buttons instead of the design system’s purple rectangular buttons”)Address a gap in the current core design system��(“We need a min/max range slider for our filters and we don’t see one in the design system”)Are truly custom snowflakes��(“We need this fancy-pants starburst badge and we know it doesn’t apply to any other product”)

All of these use cases are legitimate (even if they make design system purists’ eyes twitch). Back to the concept of��pace layers, Josh explains��that��the faster product pace layer’s job is to invent and innovate, while the slower design system pace layer’s job is to curate and capture sturdy solutions:

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.”

The recipe layer can be where fresh ideas, inventions, iterations, and improvements play out. And if those experiments prove to be successful?

Recipes can graduate into core design system components

Restaurant incubators are a really cool concept. A group of fledgling restauranteurs operate out of a shared space, test out a restaurant concept, and cut their teeth. They pilot their business and menu, and if they’re successful, they can graduate out of the incubator and into their own space. In Pittsburgh, my favorite pizza place, Iron Born Pizza, began in an incubator. If you find yourself in Pittsburgh, be sure to check out restaurant incubators like Federal Galley.

In the UI world, the recipe layer can serve the same role as a restaurant incubator. Product teams experiment and implement novel ideas. If those ideas bear fruit and perform well, those ideas ought to be considered at the core design system level. Maybe orange parallelogram buttons significantly outperform the current design system’s purple rectangle buttons. It may be worth experimenting with orange parallelograms in other applications and measuring the results. If and making a switch if success is found across the board.

The recipe layer can serve as a design system component incubator.

It’s important to note that��some��component recipes might become core design system candidates, while others will only ever remain as product-specific recipes.��Both paths are totally fine!

Design systems are living, breathing, evolving entities, and it takes a long time to get to comprehensive coverage.��Recipes-as-component-incubators can be a great strategy for kick-starting new design system components in a needs-based, thoughtful manner.

Recipes tend to be more more complex components

A core design system tends to include more of atomic-level elements, while recipes tend to be more complex components — “organisms” in atomic design-speak. Keep in mind this is more an observation than a hard rule.

This division makes sense: a checkbox atom can only assume so many forms, while a filtering toolbar can be an incredibly sophisticated and complex piece of UI machinery. More complexity can often limit a component’s portability and reusability across an organization’s portfolio of digital products.��A recipe layer allows different teams to combine the same atomic elements into product-specific components in order to achieve their respective goals without over-engineering the core design system component.

Custom-built recipes should still use design tokens

Custom components are going to happen, but thankfully there are ways of creating custom components in a way that works with the grain of the design system.��Teams should still apply the design system’s token system wherever possible to help stay aligned with the design system’s established conventions and ensure their custom components feel cohesive sitting alongside system-provided components.

.custom-error-recipe { background: var(--ds-color-background-utility-error); color: var(--ds-color-content-utility-error); border-color: var(--ds-color-border-utility-error);}

The exception here is custom components that are deliberately deviating from the established design system conventions. In these instances, teams may be trialing a new design language, creating campaign-specific or seasonal visual effects, or some other justifiable reason. These scenarios should be handled with care as they can veer into going-rogue-for-no-good-reason territory if not thoughtfully managed.

The recipe layer is a great place for collaboration

The recipe layer is a great watering hole for the core design system team and an individual product team to come together.��A formal recipe layer creates visibility into the product world where product teams are able to demonstrate how they’re using (and abusing!) a design system’s materials. The design system team can check in on the recipe layer, provide support, ask questions, and give advice.

In our work with scores of organizations, we’ve seen the recipe layer promote healthy relationships between design system teams and the product teams they serve.

Recipes can be easily added to your architecture

Establishing a recipe layer in a design system is thankfully pretty straightforward. The gist involves going from:

Core DS library -> Product

to:

Core DS library -> Product-specific recipes -> Product

Product teams manage their own recipes library that subscribes to the core design system library in both design and code. Individual product teams then subscribe to both the core design system and any relevant product-specific recipe libraries.

Recipe surgery

For design systems that may have cooked one-too-many recipes into their core design system, a quick and painless surgery can migrate recipes out of the core system and into a new recipe layer that product teams subscribe to in addition to the core library. These changes should be accompanied by a deprecation period, clear communication, and a bit of hand-holding to migrate to the new recipe architecture.

Get cookin’!

Whew! We’ve covered the many ways that recipes are a helpful addition to your design system ecosystem. I hope this post inspires you to whip up some delicious recipes using your design system’s ingredients.

Recipes require thoughtful coordination of architecture and people.��At Big Medium, we work with digital organizations to help teams put the right architecture, people, processes, and tools in place in order to set digital organizations up for long-term success. If you could benefit from expert help with your design system architecture and practice,��get in touch! And as always, we’d love to hear how you’re thinking about and executing these concepts in your work.

We Need To Talk About Our AI Fetish

In a powerful and historically grounded essay, Jeremy Wagstaff asks that we not abdicate the vision for AI solely to the companies who stand to gain from it:

���Admittedly, it���s not easy to assess the implications of a complex technology like AI if you���re not an expert in it, so we tend to listen to the experts,��� Wagstaff writes. ���But listening to the experts should tell you all you need to know about the enormity of the commitment we���re making, and how they see the future of AI. And how they���re most definitely not the people we should be listening to.���

The potential impact of AI on work, culture, and individual agency is both deep and broad. And that impact will have effects that are both positive and negative���including effects that we haven���t yet imagined. We should be prepared to adapt to both, but history tells us that when policy is in the hands of those who would profit from transformative technology, bad things get buried. See oil, plastics, asbestos, pesticides, etc.���and now big tech, where Wagstaff points out we���ve seen a cynical evolution of how technology ���helps��� us:

At first Google search required us to define what itwas that we wanted; Facebook et al required us to dodefine who and what we wanted to share our day with,and Twitter required us to be pithy, thoughtful, incisive,to debate. Tiktok just required us to scroll. At theend it turned out the whole social media thing wasnot about us creating and sharing wisdom, intelligentcontent, but for the platforms to outsource the expensivebit ��� creating entertainment ��� to those who would bewilling to sell themselves, their lives, hawking crapor doing pratfalls.

AI has not reached that point. Yet. We���re in this early-Googlesummer where we have to think about what we want ourtechnology to do for us. The search prompt would sitthere awaiting us, cursor blinking, as it does forus in ChatGPT or Claude. But this is just a phase.Generative AI will soon anticipate what we want, orat least a bastardised version of what we want. Itwill deliver a lowest-common denominator version which,because it doesn���t require us to say it out loud, andso see in text see what a waste of our time we arededicating to it, strip away while our ability to compute��� to think ��� along with our ability, and desire, todo complex things for which we might be paid a salaryor stock options.

It doesn���t have to turn out that way, of course. But it does require intention to change the course of technology and how companies and culture respectively profit from it, and not only financially. That intention has to come from many sources���from users, from policymakers, and from those of us who shape the digital experiences that use AI.

We all have to ask: What goals do we want to achieve with this technology? What is our vision for it? If we don���t decide for ourselves, the technology will decide for us. (Or the companies who would profit from it.) As I���m fond of saying: the future should not be self-driving.

Consider health care. What goals do we want to achieve by applying AI to patient care? If the primary goal is profit (reduce patient visit time and maximize the patient load), then the result might focus on AI taking over as much of the patient visit as possible. The machines would handle the intake, evaluate your symptoms and test, handle the diagnosis, suggest the course of action, and send you on your way. You might not even see another human being during most routine visits. If the experience ended there, that might be considered a business win in the coldest terms, but holy shit, what a terrible outcome for human care���even more soulless than our current health care machinery.

What if, instead, we change the goal to better care, lower health costs, and more employment? In that case, AI might still aid in intake, synthesize symptoms and test results, and provide a summary for medical review���so that medical staff don���t have to do as much rote data entry and summation.

But THEN the doctor or physician���s assistant comes in. Because the machines have already done the initial medical analysis, the caregiver���s role is to deliver the message in a way that is caring and warm. Their time can be spent on letting patients tell their stories. Instead of a rushed five minutes with a doctor, the patient will get time to feel heard, ask questions, get info, be reassured.

And perhaps that caregiver doesn���t need as much education as doctors today, because they are supported by knowledgeable systems. That in turn makes health care less expensive for the patient. It also means we could afford more caregivers, for more jobs. Instead of using AI to reduce human contact, in other words, we can use the technology to create the circumstances for better, more humane connection in the times and contexts when people can be so much more effective than machines. At the same time, we can also reduce costs and increase employment.

But that won���t happen on its own. We first have to talk about it. We have to decide what���s important and what our vision should be. Here���s how Wagstaff puts it:

What���s missing is a discussion about what we want our technology to do for us. This is not a discussion about AI; it���s a discussion about where we want our world to go. This seems obvious, but nearly always the discussion doesn���t happen ��� partly because of our technology fetish, but also because entrenched interests will not be honest about what might happen. We���ve never had a proper debate about the pernicious effects of Western-built social media, but our politicians are happy to wave angry fingers at China over TikTok. ���

AI is not a distant concept. It is fundamentally changing our lives at a clip we���ve never experienced. To allow those developing AI to lead the debate about its future is an error we may not get a chance to correct.

We Need To Talk About Our AI Fetish | Jeremy Wagstaff

Nobody Wants To Work with Our Best Engineer

Jacob Bennett writes:

If Jon was a great engineer, why was he so hard towork with? Isn���t his job to get things right?

No. The job of an engineer is to get things done. Andgetting anything done past a certain point requiresworking well with others.

If you are right but nobody wants to work with you,what net value are you bringing to the team? ���

Kindness is a valuable trait. Practice it.

Designing, building, and delivering digital experiences is hard, but it turns out the biggest challenges are almost always human, not technical. Are you making things better or worse? How can you improve collaboration and understanding to make your team more successful in realizing shared vision?

Nobody Wants To Work with Our Best Engineer | The Atomic Engineer

John Maeda: Josh Clark's 2019 talk on Design and AI

Design legend John Maeda found some old gold in this 2019 talk about Design and AI from Big Medium’s Josh Clark:

What���s especially awesome about Josh���s talk is thatit precedes the hullabaloo of the chatgpt revolution.This is a pretty awesome talk by Josh. He has been trailblazingmachine learning and design for quite a long time.

The talk, AI Is Your New Design Material, addresses use cases and applications for AI and machine learning, along with some of designing with (and around) the eccentricities of machine intelligence.

(Also be sure to check out John’s excellent SXSW Design in Tech Report, “Design Against AI,”.)

Josh Clark's 2019 talk on Design and AI | John Maeda

US Air Force Confirms First Successful AI Dogfight

Emma Roth reports for The Verge:

After carrying out dogfighting simulations using theAI pilot, DARPA put its work to the test by installingthe AI system inside its experimental X–62A aircraft.That allowed it to get the AI-controlled craft intothe air at the Edwards Air Force Base in California,where it says it carried out its first successful dogfighttest against a human in September 2023.

Human pilots were on board the X–62A with controlsto disable the AI system, but DARPA says the pilotsdidn���t need to use the safety switch ���at any point.���The X–62A went against an F–16��controlled solely bya human pilot, where both aircraft demonstrated ���high-aspectnose-to-nose engagements��� and got as close as 2,000feet at 1,200 miles per hour. DARPA doesn���t say whichaircraft won the dogfight, however.

What could possibly go wrong?

US Air Force Confirms First Successful AI Dogfight | The Verge