Josh Clark's Blog, page 3

Video Series: Foundations of Sentient Design

This is part of a series about Sentient Design, the already-here future of intelligent interfaces and AI-mediated experiences.

The book

Sentient Design by Josh Clark with Veronika Kindred will be published by Rosenfeld Media.

The talk

Watch Josh Clark's talk ���Sentient Design���

Need help?

If you’re working on strategy, design, or development of AI-powered products, we do that! Get in touch.

What happens when you weave intelligence into digital interfaces? Instead of thinking of AI as a tool or as a thing that ���makes stuff,��� consider it a design material for intelligent interfaces and radically adaptive experiences. Sentient Design is the form, framework, and philosophy for creating these intelligent interfaces���AI-mediated experiences that are conceived in real time to match user needs and intent.

Join Josh Clark and Veronika Kindred for a lively introduction to this new chapter of experience design. In this free three-part video series with Rosenfeld Media, the authors of Sentient Design take you from eye-opening possibilities to practical techniques, sharing strategies to use machine intelligence to craft experiences that are at once powerful, responsible, and effective.

This free video series comes in three episodes:

Sentient Design, AI, and the Radically Adaptive ExperienceNew Postures for AI-Mediated ExperiencesNew Design Patterns for Sentient Design Experiences

Watch the complete series with a free membership to the UX community of Rosenfeld Media, publisher of the Sentient Design book.

1. Radically Adaptive Experiences

What happens when interfaces adapt not just their content but their entire structure and interaction model to match the immediate moment? Explore how the radically adaptive experiences of Sentient Design are pushing beyond traditional interface models to create experiences that shift and respond to individual needs in real time.

Watch episode one now.

2. The New Postures of AI-Mediated Experiences

How do you get your head around all the different machine-intelligent experiences available to you as a designer? How do you develop an intuition for how and when to use each interaction paradigm? Sentient Design offers a framework for exploring and organizing these new experience patterns, or ���postures������the way each kind of experience positions itself in relation to the user. Within the broad postures of tools, chat, agents, and copilots, discover 14 new experience patterns. More than just distinct functionality, each has its own interaction style, communication manner, and user expectations.

Watch episode two now.

3. New Design Patterns for New Experiences

Discover the emerging UI patterns and techniques that address the unique challenges���and opportunities���of radically adaptive experiences. You���ll uncover emerging best practices that build trust, engage critical thinking, and help users develop healthy mental models for working alongside intelligent interfaces.

Watch episode three now.

Is your organization trying to understand the role of AI in your mission and practice? We can help! Big Medium does design, development, and product strategy for AI-mediated experiences; we facilitate Sentient Design sprints; we teach AI workshops; and we offer executive briefings. Get in touch to learn more.

TikTok Will Never Die

Damon Beres in the Atlantic Intelligence newsletter:

���Although it was not the first app to offer an endlessfeed, and it was certainly not the first to use algorithmsto better understand and target its users, TikTok putthese ingredients together like nothing else beforeit.��� The app was so effective���so sticky���that everymeaningful competitor tried to copy its formula. NowTikTok-like feeds have been integrated into Instagram,Facebook, Snapchat, YouTube, X, even LinkedIn.

Today, AI is frequently conflated with generative AIbecause of the way ChatGPT has captured the world���simagination. But generative AI is still a largely speculativeendeavor. The most widespread and influential AI programsare the less flashy ones quietly whirring away in yourpocket, influencing culture, business, and (in thiscase) matters of national security in very real ways.

TikTok Will Never Die | The Atlantic

2025: The Year Ahead

Is your team wrestling with what���s next for product strategy, design, or process? We can help! Get in touch to learn more about our engagements for product strategy, design/development, and Sentient Design workshops.

Big Medium is starting the year strong with a slew of ���design for what���s next��� engagements���and together they send interesting signals for the year ahead. Our clients are pursuing ambitious, forward-looking efforts, and we���re excited to help realize them. Just a few of our current projects:

We���re guiding product and UX strategy for a medical software company to create radically adaptive, AI-mediated experiences that will ease and transform doctor workflows.We���re creating new tools and processes for one of the world���s largest companies to deliver meaningful AI-assisted design solutions for improved quality and speed.We���re reimagining brand and messaging architecture for one of America���s leading media companies to meet a transforming media landscape.We���re elevating an already mature, successful design system to support cross-platform AI-powered applications for an enterprise category leader.We���re writing the Sentient Design book for Rosenfeld Media to describe how to build a new generation of intelligent interfaces.We���re teaching Sentient Design workshops to internal teams across a range of companies as designers adopt AI as a new material for product design.

These projects are exciting on their own, but what���s got me tingling is how the highlighted tidbits of those forward-looking efforts signal broader industry trends I’m seeing for the new year.

I���m in constant conversation with digital leaders about their strategic and operational hopes and struggles. Last year, AI generated lots of uncertainty and a ton of tentative pilot-project explorations. Perspectives and projects are changing now, and as we anticipate and move with these changes, that means a shift in emphasis and approach for Big Medium, too. Here���s what it adds up to for the new year:

AI shifts from tool to design materialDesign shifts from consolidation to innovationAI learns design systemsGenerative AI becomes boringAI hype continues to distractNew challenges need new perspectiveAI shifts from tool to design material

The AI focus for most companies has so far targeted process tooling or product features that focus on productivity and function: How does AI deliver efficiencies? What can generative AI make or do? This mindset has privileged feats of engineering over feats of experience. Product designers have focused more on how AI might change their process than how it could elevate the products they make.

That will change this year. Instead of treating AI as a tool, a function, or even as an enabling technology, we���re seeing design leaders start to explore it as a material for new product experiences. What becomes possible when you weave intelligence into the fabric of a digital interface instead of bolting on some sparkles and a chatbot? You get AI-mediated experiences conceived and compiled in real time based on your intent in the moment. These are radically adaptive interfaces that adapt to people instead of forcing the reverse.

Instead of cost-cutting efficiencies, this approach emphasizes how AI can increase product value by transforming experience. In our Sentient Design practice, we���ve identified 14 new experience patterns that intelligent interfaces enable, and we���re helping our clients deliver them now.

Sentient Design describes a wide range of AI-mediated experiences that go way beyond the chatbot.

This goes way beyond chatbots, and it���s exciting work, exploring and establishing new kinds of intelligent interfaces. Sometimes, this makes for dramatically new interaction models, but other times, it can be way more subtle���casual intelligence sprinkled into traditional interfaces like web forms.

Big Medium is making this next chapter of interaction and product design a core focus in 2025, and we���re excited to help the industry turn this corner, too. We���re doing that in a few different ways: intelligent interfaces are central to a growing portion of our product design work; Veronika Kindred and I are writing the Sentient Design book for Rosenfeld Media; we���re giving talks at SXSW and conferences around the world; and we���re teaching Sentient Design workshops to product teams who want to learn how to make what���s next.

Speaking of that appetite for ���what���s next,��� that’s another strong industry shift we���re seeing for product design and strategy…

Design shifts from consolidation to innovation

We���re emerging from a long period of design retrenchment. The last 15 years has been marked by companies bringing design in-house���and learning how to metabolize that function to make creative process work inside company structures. That real and important need gave rise to the design system discipline over the past decade. Design systems represent the systemization and adoption of best practices. They���re the best way to get everyone to work from the same playbook.

But design systems are about curation, not invention. Their whole job is to consolidate, not innovate. The real innovation was in creating the design system discipline in the first place���the assets, technique, and process to make them go. That���s been an area where Big Medium has contributed a ton for many years. My longtime partner Brad Frost developed the Atomic Design methodology across our many projects together. We contributed directly to the success of hundreds of design systems���and indirectly to hundreds of thousands.

But now��� mission accomplished. Design system best practices have settled; the discipline has become established; and having a design system is now considered the baseline. (That doesn���t mean it���s easy. Brad continues to do the important work of helping teams put these established practices to effective work. Brad has moved on to focus exclusively on delivering this content and education at scale. Check out Subatomic: The Complete Guide to Design Tokens, Brad���s new course with Ian Frost���so great!)

Meanwhile, Big Medium is focused on the next wave. I���m seeing a fresh appetite���and a real need���for product design innovation. Creative momentum is shifting from the consolidation of best practices to the invention of new ones. I haven���t felt this level of curiosity, urgency, and enthusiasm to explore new digital experiences since mobile changed everything. AI-mediated experiences are that new thing, and nurturing its innovation and mastery is the big focus of Big Medium���s product design and strategy work right now. We���re excited to help lead that exploration at both the client and industry levels.

Creative momentum is shifting from the consolidation of best practices to the invention of new ones.

But this is cool: the last chapter informs the next. All that design-system work creates the foundation to enable AI-mediated interfaces.

AI learns design systems

Big Medium���s design system practice is shifting to focus on helping mature teams to capitalize on the interplay of design system and machine intelligence. Part of that is the productivity angle of how AI can better enable the maintenance and adoption of design systems���we���ve been doing some impactful work on that with our clients. But the bit that���s even more exciting and novel is the role that design systems play in creating radically adaptive, intelligent interfaces.

The essential job of a design system is to create a library of solved UI problems organized around common language and purpose. Everyone is on the same page: when you see this UI problem, you know to reach for that UI solution. When AI-powered systems become part of the team, they can make use of that design system know-how, too.

One aspect of Sentient Design is interfaces that morph according to immediate context. Modern chat experiences can field any question and then take the conversation in any direction the user cares to take. What happens when other interaction models take on the same open-ended flexibility? You get things like Google���s bespoke UI or Salesforce���s generative canvas, where content and interface elements are chosen on the fly���but always from the design system.

More than just a new experience, it suggests a new role for designers and design systems, too. When we allow machine intelligence to share real-time UI decisions, the designer���s job shifts to designing the rules and materials that govern those decisions. That means building robust design systems that can be flexibly composed, developing clear principles for when and how experiences should adapt, and establishing guardrails to ensure coherence even as presentations shift. The experiences themselves may be ephemeral���built for the moment���but the foundations or generating them must be even more solid than traditional interfaces.

When AI-powered systems become part of the team, they can make use of the design system, too.

We���re already helping product design teams build these forward-looking experiences���in reliable ways that don���t turn the interface into a robot fever dream. And we���re helping mature design system teams explore how to support radically adaptive interfaces with their UI patterns. I expect much more of this in 2025.

Generative AI becomes boring

This is already happening as last year���s magic turns into this year���s everyday software. Systems that can hold conversations on any imaginable topic (!!) are just… taken for granted. Image generation, writing, summarization, natural language understanding���all of this stuff is already getting baked into everyday operating systems, fast becoming as expected and commonplace as spam filters, predictive keyboards, or recommendation systems before them.

This has been the path of AI for the last 75 years���every breakthrough quickly becomes ���just software,��� and AI gets redefined as something better/smarter. AI has always been a moving target hovering just out of reach, but the broader category of machine intelligence has kept chugging away, putting AI���s castoffs to work on sober, workaday tasks. It���s the algorithms and machine learning that power the software we use every day. While machine intelligence enables AI���s sensational new experiences, it also enables a slew of boring but important features and business processes. ���Somehow machine learning is both rocket science and tractors,��� says analyst Benedict Evans.

The new banality of generative AI is a good thing, because it means that we can treat this design material with calmer rationality. We can understand what it���s good at and bad at, find its proper place in our products and workflows���and leave it aside when it���s not fit for purpose.

At Big Medium, we���ve always focused on ���teaching teams to fish��� in our client engagements. As we work alongside client teams, our goal is to make our knowledge their knowledge. In 2025, I expect a big part of that will be helping our partners adopt AI as part of their everyday toolkit without fuss or fanfare. It���s just software.

AI hype continues to distract

If AI developments stopped right now���if frontier models got no better and advancements froze���we would still have plenty of material to develop years and years of new product experiences. The pace of technology always outpaces the ability of organizations to adopt it, and the astonishing speed of AI developments makes it especially true in this area. There���s a lot to process here and so much yet to create with the actual concrete tools of machine intelligence available today���with all their capabilities and shortcomings.

And yet the constant drumbeat from big tech and the companies behind the big foundation models is: wait til you see what���s behind the curtain. It���s always the thing that���s about to arrive. There���s a ton of money at stake in keeping anxiety aroused and anticipation heightened���billions and billions being invested in promises to make the next generation of machine intelligence even better. The dangled promise is AGI���artificial general intelligence���the threshold when machine intelligence can do any general task better than human intelligence.

I have no idea whether and when AGI will happen. People way more informed than I about the science of this stuff disagree strongly about the timing or even the plausibility. We���ll see.

But whatever happens next, the hype and distraction about what might be tends to distract from what���s possible now. Language and expectations race far ahead of what���s delivered. At Big Medium, we���re very pragmatic in our approach to machine intelligence. We keep an eye on what���s emerging, but we���re very focused on what���s practicable, affordable, and ethical within the current set of tools.

I share the industry���s current fascination with the promise of AI agents���self-driving software that can set goals, plan and execute the steps to achieve them, and then recognize when the goal is complete. But I also don���t think 2025 will meet the breathless expectations that agents will handle all manner of open-ended tasks. 2025 will not be the year of autonomous, general-purpose agents. The oft-discussed software agent that can plan and book your vacation will remain elusive.

But! I do expect that agents will begin to handle more and more tasks in narrow domains within carefully scoped systems. That���s all within the capabilities of current tools���effective agents are already available for research and for software development. A big part of our work in both process and product is moving toward agentic/agentive features and applications in similarly scoped domains. We���re helping our clients transition from traditional automated tools to the first stage of AI-assisted agents that bring context and awareness to narrow tasks.

The hype and distraction about what might be tends to distract from what���s possible now.

We need to proceed with care and pragmatism. The work and the challenge for practitioners in 2025 is to develop the meaningful stuff that���s possible right now without overreaching what current tools can do���or falling into a hype-fueled hypnosis about what might be possible tomorrow.

New challenges need new perspective

The media and digital landscapes are changing. There are new ways to tell stories and share information through interactions that weren���t possible just a few years ago. We can convert content between style, tone, and medium���PDFs to podcasts���in minutes or seconds. We can generate both meaningful content and useless slop faster than ever. We can surface insights and hallucinations with astonishing ease, but often find it hard to tell the difference. What do we do with this?

AI has put companies, teams, and individuals on an existential roller coaster ride for the last couple of years���what does it mean to who we are and what we do? In what areas will our skills as individuals (and capabilities as companies) become even more important this year? Where should we acknowledge that AI is already better at some of our traditional tasks? What are the meaningful new offerings that emerge when we combine forces with machine intelligence? How does that change the way we are perceived and what we���re capable of?

For leaders, the work in 2025 is to develop clear-eyed perspective about this���and to craft crisp internal and external messaging to communicate it. We���re already helping our clients do this at the project, team, and enterprise levels, but I expect that work to broaden and deepen in 2025. That means developing new design principles around next-generation product work. It means developing new professional development programs to help teams adopt the skills and perspectives they need for their work. And it means developing new positioning and brand strategies at the organization level to help the world understand how you���re evolving. We���re doing all of this in our client work now.

2025 will be a year of transition. This won���t all be easy or comfortable; it means changing old habits and sometimes sense of self. But I believe this transition will also unlock a year of energetic invention���one that will be as fun and rewarding as it is challenging. Here at Big Medium, I���m excited to see that our current slate of client projects is already starting us quickly on that course. I���m even more excited about the story that those projects tell me about the year ahead for all of us.

Happy New Year, friends. There���s lots to do. Let���s get after it.

Is your team wrestling with what���s next for product strategy, design, or process? We can help! Get in touch to learn more about our engagements for product strategy, design/development, and Sentient Design workshops.

New Adventures for Old Friends

The people at Big Medium have always been so much more than colleagues. This wildly talented crew of kind, supportive creatives has been my friend group, my social network, my compass. We���ve cared for each other during highs and lows both personal and professional���and that also means cheering each other on at bittersweet moments.

Brad Frost, Ian Frost, and Jessi Hall are all moving on to new adventures. These turn-the-page moments tug the heart in every direction. I���m grateful and proud of what we���ve done together, excited for what this crew will do next, and sad that I won���t get to see them every day. But ultimately, I’m just really happy for these dear friends and longtime collaborators as they open new chapters.

Brad Frost and Ian Frost are going indie. The brothers Frost are launching a new set of projects that focus on what they do better than anyone: explaining and demonstrating best practices for design systems and front-end design/dev. Brad and Ian are shifting from bespoke client services to focus on publishing and teaching at scale���starting with their first online course, Subatomic: The Complete Guide to Design Tokens. Nobody knows this stuff like they do, and I���m excited to see them bring this course (and many more) into the world. I���m even more excited for the people who get to learn from these two. Brad and Ian offer more than know-how; they bring goofy fun and enthusiasm to everything they do. They make learning this stuff a pleasure.

Brad and I have worked arm in arm since 2013 (12 years!), and Ian joined the fun three years later. Brad developed the Atomic Design methodology throughout our projects together, and we formalized our collaboration as Big Medium partners two years ago. Brad���s been a brother to me, not just a creative and business partner. It���s the end of an era to see Brad and Ian go, but I���m proud of them for following their hearts and creative interests. I look forward to seeing what comes next, and you should, too. Follow Brad and Ian at bradfrost.com and ianfrostweather.com.

Jessi Hall is taking a hiatus to travel with family and consider her next chapter. Jessi has been the steady hand of Big Medium for nearly six years as producer and operational impresario, but that hardly begins to describe her contribution. Jessi is skilled at process, sure, but her real superpower at Big Medium is caring deeply about people���colleagues and clients alike���to understand what they need to unlock their most creative work. She has the rare skill of fostering safety, openness, and common vision in all the teams she works with.

Jessi is also incredibly creative herself. She���s a talented singer���a professional musician for many years���and a designer of stunning interiors and gardens. After years of using her considerable talents to organize the creative work of others, she���s taking time to nurture her own. Jessi has done so much to help our team connect our work with meaning, and I���m so glad she���s taking some deep time to do the same for herself. I���m grateful for everything Jessi���s done for Big Medium, but I���m even more grateful for her friendship. I���m a better person for knowing her���and you���ll be a better person for following her on LinkedIn.

New adventures for Big Medium, too. The new year already has us on exciting new paths but following the same compass: design for what���s next. We have a bunch of fascinating, forward-looking client projects that all signal some larger trends afoot in 2025 for product design and innovation.

We���re fortunate to have a deep bench as we shift gears and climb into the year���s challenges and opportunities. But I miss these three already, and it won���t be the same without their terrific talents���or seeing their faces on the daily. Giant thanks and much love to all of you.

MS Copilot Flying Straight Into the Mountain

AI agents have lately captured the industry’s imagination (and marketing communications) in recent months. Agents work on their own; they set and pursue goals, make decisions about how to achieve them, and take action across multiple systems until they decide the goal is complete. Vaclav Vincalek ponders what happens when anyone can create and set these loose.

Now imagine that anyone in the organization will beable to create, connect, interact with a ���constellationof agents.���

Perhaps you don���t see this as a problem.

That only means that you were never responsible fortechnology within your organization.

Maybe you had a glimpse in the news about all the latestthreats from viruses, phishing or other various formsof hacking. Every IT department is trying to stay abovewater just to safely run what they have now.

These departments are managing networks, firewalls,desktops, laptops, people working remotely, integratingapplications, running backups and updates.

The list is longer than you can imagine.

Thanks to Microsoft, you will add to the mix an abilityfor anyone in the company to automate any task to ���orchestratebusiness processes ranging from lead generation, tosales order processing, to confirming order deliveries.���

What could possibly go wrong?

Look at the person sitting in the cubicle next to you(or in the next square on your Zoom call).

Would you trust the person with any work automation,or do you still question that person���s ability to differentiatebetween a left and right mouse click?

MS Copilot. Flying Straight into the Mountain | Vaclav Vincalek

Subatomic: All About Design Tokens

Subatomic: The Complete Guide to Design Tokens

Design Systems Q&A

I recently had the pleasure of doing a Q&A session with Molly Helmuth’s��Design System Bootcamp��cohort. The questions were great and varied, so I asked Molly if she’d be alright if I shared my answers with you all. Thankfully, Molly is awesome and agreed to let me share here. Be sure to check out Molly’s��UI Prep, which offers all Figma training and great resources for the community. Thanks Molly!

There’s a bunch of great questions about design systems, workflow, atomic design, the future of design systems, buy-in, designer-developer collaboration, personal development, and global design system stuff. Let’s dig in!

Was there an aha moment when you realized you had something cool on your hands and you knew you wanted to write the book?

Atomic design was��born in 2013��through our client work. I had come into the world of self employment after leaving��R/GA��and started working with my partner,��Josh Clark, on��a redesign of techcrunch.com��and��Entertainment Weekly. Those projects were the first to put atomic design’s ideas to work and was the genesis of the tool that became��Pattern Lab.��The book��followed suit in 2015, which felt good as we had validated a lot of the mental modal and workflow by then.

Is there anything you strongly believed about design systems or the concept of atomic design that you now think is false or no longer makes sense?

I’ve been giving a conference talk with a clickbait-y title called “Is Atomic Design Dead?”

In the talk, I suggest that��atomic design is more relevant now than when I first created it. Over the last number of years we’ve seen design systems become��A Real Thing��with dedicated people, money, resources allocated to them. In many respects, this is a great thing! It underscores the importance of this critical front-end infrastructure. But this success is also a double-edged sword.

This evolution has created distance between the system — and it’s stalwart makers — from the people and products they serve. This distance has many design system teams asking “how do we get better adoption of our design system?”

Atomic design continues to serve as a helpful model that connects design systems to the products they serve.��In my book, I quote��Frank Chimero’s excellent book��The Shape of Design:

The painter, when at a distance from the easel, can assess and analyze the whole of the work from this vantage. He scrutinizes and listens, chooses the next stroke to make, then approaches the canvas to do it. Then, he steps back again to see what he’s done in relation to the whole. It is a dance of switching contexts, a pitter-patter pacing across the studio floor that produces a tight feedback loop between mark-making and mark-assessing.Frank Chimero

Which I follow up with:

Atomic design lets us dance between contexts like the painter Frank so eloquently describes. The atoms, molecules, and organisms that comprise our interfaces do not live in a vacuum. And our interfaces’ templates and pages are indeed composed of smaller parts. The parts of our designs influence the whole, and the whole influences the parts. The two are intertwined, and atomic design embraces this fact.

Do you think the term design system is being misused? And should we consider adopting a different name in the future?

Buzzwords are weird. “Design systems” is the thing that stuck, even if it truly is an unfortunate name. The name implies this is the world and responsibility of designers. In reality, design systems are incredibly important and valuable for everyone responsible for making digital products, right?

If we had a time machine, we���d go back and call them ���User Interface Systems���

If we had a time machine, we’d go back and probably call them something like “User Interface Systems,” which is more accurate, inclusive, and doesn’t confuse people and organizations as much. But as someone who’s had a hand in creating a buzzword, these words really do have a staying power that are hard to change once they’re established.

Is it ever too soon to start creating a design system?

Here’s the context:

We’re a startup that’s pre-Product Market Fit and are looking to raise seed soon. We expect to grow the team over the next year. I’d like to have some semblance of reusable components (mapped 1-to–1 in design and code) by the time the next designers start, but I also know things are going to be very fluid over the next few months as we converge on our feature-sets and overall look-and-feel. I want to stay nimble and lean, but I also don’t want to accumulate too much design debt and then have a giant task of creating a Design System late in the game. In your experience, when is typically a good time to start investing in a Design System and how do they evolve over time?

It’s a great question that really gets to the heart of “what exactly is a design system?”

So many public-facing design systems are mature, comprehensive, well-documented, and serve giant organizations. But here’s the thing:��not every system needs enterprise-grade polish or comprehension. At the end of the day it really boils down to designing and building things in a component-driven manner. That best practice holds true irrespective of the context.

Not every design system needs enterprise-grade polish and comprehension.

A component-driven approach pays dividends even for startup MVPs and simple sites. It doesn’t really incur extra production work; it’s really about thinking thoughtfully about reuse from the start. Your users get a consistent, cohesive experience, and your future self (and team) will thank you as you scale down the road.

When I built my wife’s jewelry studio website, the first page required creating everything from scratch – header, footer, and everything in between. But by the second template, those core elements were ready to reuse. Each subsequent page became faster to build because I was assembling existing pieces rather than starting fresh. My design system wasn’t

As the only designer on the team, how can I ensure my design system work is not halting or slowing down development to avoid crap being added to the design system?

The creation of crap — shortcuts, hacks, experiments, rushed work — is inevitable in product design and development. But this mantra is really important:��Don’t put crap in the design system.

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.

Through our work, we’ve helped many organizations navigate this conundrum. Product teams want the design system to hurry up! Design system teams want product to slow down!��My partner Josh Clark wrote about acknowledging these different pace layers��and allowing each layer to move at their respective pace:

I’d recommend giving Josh’s whole article a read; there’s so much gold in there.

In your experience, is it better for design teams to get a head start before development begins?

Hell no! My soapbox has long been that��designers and developers need to work much closer to one another. This is especially in the context of a design system.

Design system success requires close collaboration between designers and developers.

A design system provides a library of user interface components in both design and code. These assets need to be synchronized and carefully orchestrated. Other teams depend on the design system’s assets and need to be able to trust they embody design and development best practices.

I regularly have conversations — including one this week — with people struggling with distance between design and development. Designers and developers are part of different groups and designers are working months ahead than developers.

This, my friends, is where the messes get made and where the agony begins. This is where piles of money get lit on fire and where people have a miserable, frustrating time.

It’s so critical to get designers and developers closer together, getting them synchronized, getting them truly communicating and collaborating with one another. A lot of our work at��Big Medium��entails helping teams build — and sometimes repair — those relationships.

Is there such a thing as over designing a design system? If so, how can I avoid this?

We see people over-designing design systems all the time. Anytime you catch yourself deliberating over hypothetical situations like:

“Oh, we might need a tertiary button style, so let’s go ahead and build it.”

or

“We might need this extra token in case people need it.”

That’s a sign you’re over-designing the system. What to do instead?��Catch yourself and dial things back to what reality necessitates.��This underscores the importance of atomic design and the importance of connecting the design system to the products that it serves. Building design systems through the lens of a creating real products grounds your system in reality and keeps those hypotheticals at bay.

Endless deliberation over hypothetical situations slows teams down and can result in over-designed systems

We see a lot of teams get paralyzed by all of these hypothetical what ifs, or we’re trying to craft the perfect components that anticipate every future use case. Perfect is the enemy of good and done. All of that stuff. You gotta get things out the door. But at the same time, there is an art to being thinking about how this stuff might be reused down the road. But let’s not dwell on it or over dial on potential futures. So there’s an art to it. So you do.

Is there one thing you’ve noticed that successful design system teams have in common? And is there one thing you’ve noticed that unsuccessful design system teams have in common?

Yeah.��It really has everything to do with the service model around the design system.

What makes or breaks a design system is the service model around it. Design system teams must establish close, healthy relationships with consumers.

How well the design system team plugged into the rest of the product organization? How are they doing at reaching out, being proactive, offering good sort of support and customer service? That’s everything.

We observe many design system teams focus inwards, wanting to block everything out in order to sweat the details of these design tokens and components. Don’t get my wrong, that work is important! But that’s not the gig.

It can be a cold shower to remind design system teams that their jobs are to make other designers’ and developers’ lives easier, which requires to get close with those people. Design system teams build things for others to use, and the most successful teams are well aware of that and are really well connected with the people that they’re serving.��It’s good customer support and good user-centered design.

What’s the biggest mistake you see teams, make when tokenizing the system?

Back to over-designing the system, I’d say it’s dwelling in the land of hypotheticals and “what if”s. Naming is hard, but��we see teams getting trapped or trying to get too clever with naming and taxonomy. It’s freaking hard work though!

We also see teams create far too many component-specific tokens.��We worked with a client that had over 5,000 tokens, comprehensively covering every component and variant: alert error background, alert warning background, alert success background, badge error background, badge warning background…

Component-specific design tokens should be used sparingly; rely as much as possible on semantic tokens.

This is a recipe for disaster. As you add components, as you add variants, you need to add yet more design tokens to manage. It becomes unwieldy really, really quickly. We recommend a��three-tiered token system��for��creating themeable design systems, but we recommend reserving component-specific tokens for very specific use cases like heavily-branded buttons that can vary wildly between themes.

I’ve heard some design teams only adding components to their Figma design system once they’re in code. What do you think about this workflow?

Code really is the the source of truth in a design system, so the Figma library is really a contract or a promise of what’s available in code.

Code is the source of truth for a design system.

This can be jarring to designers who are used to a very different process! Designers are used to first painting a picture of what we want a product to be. And then eventually that picture gets built out in code.

Design systems are different because they are libraries that exist in both design and code.��So the Figma library needs to reflect the reality of what product teams — which include both designers and developers — can use from the library.

A design system is a product that provides several assets, and those assets need to be in sync with one another. Bad things happen when there’s drift between those assets and the people who create them.

Should a snowflake component live in the design system if it’s used only once?

Nope! A design system is a collection of solved problems — the��boring��stuff. Snowflakes by their very nature are not boring; they’re unique!

In a��design system ecosystem, product teams are welcome and encouraged to create their own snowflakes in order to solve their problems. Coming back to the idea of��pace layers:

The job of the design system team is not to innovate, but to curate. The system should provide answers only for settled solutions: the components and patterns that don’t require innovation because they’ve been solved and now standardized. Answers go into the design system when the questions are no longer interesting—proven out in product. The most exciting design systems are boring.

Josh Clark

A design system team’s job is to keep the finger on the pulse of what’s happening at the product level. If 5 teams are all creating snowflakes that are all doing similar things, that’s a super strong signal that there’s an opportunity for the design system to address a common need.

At what point does it make sense to build two separate design systems instead of one that can support two very different themes?

If you’re talking about aesthetic differences, it doesn’t usually make sense to build and maintain two separate design systems.��You can accomplish wildly different look and feels��with design tokens to��support many different brands, subbrands, modes, product families, rebrands, and so on.

A door on sale at a hardware store is going to open and close. That functionality will hold true irrespective of whether the door is pink or red or blue, or if the hardware is brushed nickel or brass, or matte balck. Here’s this vanilla door that works, and you can paint it whatever color you want.

There are plenty of good reasons to maintain separate design systems though. We work with a lot of organizations that have already existing multiple systems in place and serve a multitude of tech stacks. It becomes an “if it ain’t broke, don’t fix it” situation. It truly depends on the context and situation. Sometimes it makes sense to merge systems. Sometimes it makes sense to split them apart. Sometimes it makes sense to share tokens while keeping separate component implementations in place. Sometimes it makes sense to adopt��Web Components. It depends!

I have three designers on my team. How might we use branching for submitting new items to our design system in Figma? What happens if one item takes a really long time to develop, and a bunch of other changes get submitted in the meantime?

The world of branching, semantic versioning, variables, and variants are relatively new to designers, but are well-established conventions in the world of development. All the more reason to have designers and developers closer together; developers can help guide designers around these concepts.

You can create branches from the main library to do new feature work. You do your feature work and when that work is ready to be reviewed, you go in and you do a review. In code, a developer will issue a pull request, other people will review it, vet it, and ultimately validate it. It gets merged and released in the next version of the library.

The same process can and should happen in the world of design, but Figma’s branching in is not as sophisticated as Git for code.

What we do is orchestrate the release of libraries so that version numbers are synchronized in code, design, and documentation. Check out��Nathan Curtis’s excellent series on releasing design systems.

In development we have feature branches that hang out for weeks or months and sometimes even years. The work takes as long as it needs to do and they might miss a release and that’s okay. It’ll get there when it gets there. That’s the kind of nice thing about branching.

What’s the best way to kick off building your new design system?

It’s critical for a design system accelerate and advance critical business initiatives. Connecting the system’s success to product success is the path to…success.

What you��don’t��want to do is kick off a design system by going into a vacuum and starting to noodle on some buttons. What business critical product work needs to happen at the organization? That’s the lens to look at the design system. How can you create a design system that helps accelerate and advance those critical product initiatives?

It’s also critical to get at the good, bad, and ugly of making products at the organization.��We hold many discussions and interviews��with a cross section of stakeholders to get a sense of the challenges the design system needs to help address.

What do you believe is the most significant trend shaping the future of design systems? In what ways do you predict AI improving design systems for designers and developers?

Our team has been doing��a lot��of work around the intersection between��AI and design systems.

We’re finding that this new crop of AI tools can help supercharge many aspects of design system production, help products adopt the design system, and create entirely new design-system powered experiences.

We’re helping organizations adopt AI tools into their design system workflows, speeding up the creation of designs in Figma, the translation of designs to code, and the adoption of design systems in existing products. The power and potential are obvious, and it’s been a lot of fun to help our client teams navigate this new terrain.

While the efficiency angle to AI is apparent, the potential for an entirely new generation of user experience is truly exciting.��Josh Clark and Veronica Kindred are writing a book called��Sentient Design��that covers how AI can create radically-adaptive user experiences.

This new generation of radically-adaptive user experiences��depends on the sturdy foundations of a design system. We all know AI tools can hallucinate and introduce unpredictability. A design system provides welcome constraints and predictability

What are some ways I can convince stakeholders, what a design system is? What are some ways I can convince stakeholders a design system is or would be valuable?

Saying “Hey boss, I need four months to go off on my lonesome and create this component library” is not a winning strategy. Extolling the very real benefits of design systems often doesn’t do the trick, either.

Design systems cannot be a side project; they need to become critical front-end infrastructure that real products rely on.

As we’ve already discussed, it’s really important to attach the design system’s success to mission-critical product success. Design systems cannot be a side project; they need to become critical front-end infrastructure that products rely on.

There’s really no success like success. It’s so important to find a way —��even if it’s on the sly��— to create a design system that’s powering real product work. With a quick win under your belt, you’ve already demonstrated value! The conversation then becomes how much more valuable the system would be with more time and resources allocated to it.

That’s why it’s so important to focus on real product work. it cannot just kind of be like this side project. That eventually you will plug in.

What’s your hot take on dev mode? Is it helpful for developers yet? and as a designer, is there anything I could do to improve what my developers see in dev mode?

I worry that Dev Mode relegates designer/developer collaboration to a toggle switch, which is a shame.

Don’t get me wrong; it’s nice to not have to fumble around design files as much. But what we witness across many teams is that the tools have gotten to a “good enough” state that allows disciplines to stay in their respective bubbles, which ultimately yields subpar products and lukewarm relationships. I have a lot more to say about all of this, but that’s a post for another day.

So the latter part of the question as a designer, is there anything I can do to improve what my developers see in dev mode? I’d reframe it:��“As a designer, what could I do to improve my relationship with my developers?”��And the short answer is:��talk to them. Pull them closer, bring them into your world, express your curiosity to be pulled in closer to their world.

Rather than fixating on tools and documentation, designers should ask ���how can improve my relationship with my developers?���

We often look for tools to “solve” human communication & collaboration issues. No doubt tools can help, but they themselves cannot solve these issues.��My strong advice is to focus on building and maintaining relationships with your collaborators.

What is something designers would be surprised to learn works differently in code than in a design tool like Figma?

Lots! Animation, interactivity, responsive behavior, source order, box model,��performance, user preferences, true text rendering, true type rendering, browser/device quirks, ergonomics, and much more.

All of these things are important aspects of a user experience that cannot be articulated in Figma. These things are very much the realm of design, and need to be carefully considered.

I likely sound like a broken record by now, but this is why it’s so important for��developers to be considered to be part of the design process, and designers to be considered part of the development process. Getting those worlds closer together simply yields better products.

What tools outside of Figma are helpful for designers to use in order to better communicate with the dev team?

Your mouth. Your fingers. Real communication, real talking, real collaboration. I’m not talking status meetings and antagonistic review meetings; I’m talking real-time working sessions where you can jam on things and solve problems together. It really is that simple. You just need to spend time with one another and foster a relationship with one another. Tools can help, but often they get in the way of that human work.

What’s your ideal documentation from the design team look like?

Again, this feels loaded with “what do I need to produce in order for you to have what you need without me having to talk to you?” Don’t get me wrong, sometimes documentation is necessary and genuinely helpful. But often, teams get trapped in a ghoulish routine of artifact generation simply for the sake of running through the motions.

Ask developers what they’d welcome in terms of documentation. There’s a fair-to-good chance they don’t need comprehensive documentation; they may just need a quick conversation to be pointed in the right direction. Communication collaboration.

As a designer, what specific development concepts or skills should I learn?

Should designers code?��has always been a fun question.

It’s always a good idea to have a solid understanding of the nature of the medium for which you’re designing. When it comes to HTML CSS and JavaScript, it’s helpful to know the basics even if you don’t know how to implement it with your own two hands. Certain concepts are helpful to know:

The box model.Source order��is really important since it works differently than dragging elements around a blank canvas.CSS Layout, especially��Flexbox��and��Grid��are really important. Positioning is helpful.Performance basics, like being mindful of the number/size of images, fonts, etc.

Grid’s a great example of a sophisticated technology that isn’t really present in design tools. CSS Grid is extraordinarily powerful, and you’re not going to find that level of sophistication in a tool like Figma.

It’s helpful to learn those concepts, but coming back to what’s become a theme in this little session here: You don’t necessarily need to know how to do this stuff first hand. What you��do��need to know is how to talk to and collaborate with the people who really know these things so you can do great work togehter.

Is it important for designers to know how to use Storybook?

Storybook is a great tool for review, testing, comparison, and documentation. Do designers need to know how to fire up storybook locally and work there? Maybe, but it’s not necessary. That said, we’ve worked with designers who watched us prototyping in Storybook and learned how to do it themselves! Like we’ve been discussing though, it’s less about knowing how to do things yourself and more to do with creating great relationships with other disciplines.

The idea of a global design system is very interesting. How exactly would this work?

As we’ve been discussing, a design system captures common UI components in order to power an organization’s products.

When you look across the design system landscape, 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.

Here’s the��idea behind 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.

It would fill a gap in between HTML and organization-specific design systems:

How would the global design system be different than using a framework like Tailwind?

I discuss the shortcomings of existing solutions in my��post��and��follow-up post:

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.

A global design system would be entirely theme-less so people can bring whatever design language to the party. The global design system is like the vanilla door that opens and closes irrespective of what color its painted.

What design systems do you look for, look to for inspiration?

I really liked the Nord health design system, especially��their support page. it does a great job at communicating the design system service model. Here’s some frequently asked questions, here’s our office hours, here’s where to get in touch with us. If you have questions, comments, or concerns, here’s what our processes look like for handling it all. That’s truly the stuff that makes or breaks a design system.

What’s the best name for a design system you’ve come across?

Polaris. We’ve worked with like seven Polaris’s haha.

If you’ve made it this far, WHEW! Thank you! Thanks again��Molly��for for letting me share my thoughts on all of these questions.

When Combinations of Humans and A.I. are Useful

This study from MIT researchers raises some challenging questions about collaborative AI interfaces, ���human in the loop��� supervision, and the value of explaining AI logic and confidence.

Their meta-study looked at over 100 experiments of humans and AI working both separately and together to accomplish tasks. They found that some tasks benefited a ton from human-AI teamwork, while others got worse from the pairing.

Poor Performers Make Poor Supervisors

For tasks where humans working solo do worse than AI, the study found that putting humans in the loop to make final decisions actually delivers worse results. For example, in a task to detect fake reviews, AI working alone achieved 73% accuracy, while humans hit 55%���but the combined human-AI system landed at 69%, watering down what AI could do alone.

In these scenarios, people oscillate between over-reliance (“using suggestions as strong guidelines without seeking and processing more information”) and under-reliance (“ignoring suggestions because of adverse attitudes towards automation”).

Since the people were less accurate, in general, than the AI algorithms, they were also not good at deciding when to trust the algorithms and when to trust their own judgement, so their participation resulted in lower overall performance than for the AI algorithm alone.

Takeaway: ���Human in the loop��� may be an anti-pattern for certain tasks where AI is more high-performing. Measure results; don���t assume that human judgment always makes things better.

Explanations Didn���t Help

The study found that common design patterns like AI explanations and confidence scores showed no significant impact on performance for human-AI collaborative systems. ���These factors have received much attention in recent years [but] do not impact the effectiveness of human-AI collaboration,��� the study found.

Given our result that, on average across our 300+ effect sizes, they do not impact the effectiveness of human-AI collaboration, we think researchers may wish to de-emphasize this line of inquiry and instead shift focus to the significant and less researched moderators we identified: the baseline performance of the human and AI alone, the type of task they perform, and the division of labour between them.

Takeaway: Transparency doesn���t always engage the best human judgment; explanations and confidence scores need refinement���or an entirely new alternative. I suspect that changing the form, manner, or tone of these explanations could improve outcomes, but also: Are there different ways to better engage critical thinking and productive skepticism?

Creative Tasks FTW

The study found that human-AI collaboration was most effective for open-ended creative and generative tasks���but worse at decision-making tasks to choose between defined options. For those decision-making tasks, either humans or AI did better working alone.

We hypothesize that this advantage for creation tasks occurs because even when creation tasks require the use of creativity, knowledge or insight for which humans perform better, they often also involve substantial amounts of somewhat routine generation of additional content that AI can perform as well as or better than humans.

This is a great example of ���let humans do what they do best, and let machines do what they do best.��� They���re rarely the same thing. And creative/generative tasks tend to have elements of each, where humans excel at creative judgment, and the machines excel at production/execution.

Takeaway: Focus human-machine collaboration on creative and generative tasks; humans and AI may handle decision-making tasks better solo.

Divide and Conquer

A very small number of experiments in the study split tasks between human and machine intelligence based on respectie strengths. While only three of the 100+ experiments explored this approach, the researchers hypothesized that “better results might have been obtained if the experimenters had designed processes in which the AI systems did only the parts of the task for which they were clearly better than humans.” This suggests an opportunity for designers to explore more intentional division of labor in human-AI interfaces. Break out your journey maps, friends.

Takeaway: Divvy up and define tasks narrowly around the demonstrated strengths of both humans and machines, and make responsibilities clear for each.

When Combinations of Humans and AI are Useful | Nature

���The Design System Isn't Working for Me!���

When design system users run into issues designing and developing with the system, they often have a hard time distinguishing between a bug, a missing feature, an intentional design deviation, a new pattern they need to create, or something else. Often,��all they know is the design system isn’t working for them. They need help!

���When in doubt, have a conversation.���
���Master design system governance with this one weird trick

Turns out there’s��one weird trick for helping those people and mastering design system governance:��TALK!

Design system teams need to be proactive and obnoxiously clear about how to connect with them.��Product teams don’t need to understand the details, lingo, and nuances of a��thorough design system governance processes; all they need to know is get in touch with their friendly neighborhood design system team.

Once connected,��the design system team can lean in to better understand what the team is wrestling with.��This right here, my friends, is a freaking art form and has everything to do with vibes.��No one wants to brace for a thorough scolding by the Pattern Police; people want to be heard, understood, and helped.��This is why kindness, empathy, and curiosity are such important qualities of design system teams.

It’s through this conversation that everyone can collaborate and unpack the nature of the issue.

Difference between a bug, visual discrepancy, gap, and pattern

Often design system issues arrive with a label of “bug”, simply because that’s the only button people ��� especially developers who are often the unfortunate downstream recipients of design work ��� know to push. But the issues rarely are actual bugs; that’s why we’ve found it helpful to distinguish between the the types of “issues” people encounter when working with the design system. Let’s break ’em down!

Bugs��are defects in existing design system components (e.g. the accordion doesn’t open when the user selects it, the primary button foreground and background colors don’t have sufficient color contrast).Visual discrepancies��are designs that don’t match the available coded UI components. Visual discrepancies can be a design system visual bug (the DS library and code library are out of sync) or it could be a product designer doing their own thing (detaching DS components or creating their own custom UIs)A design system feature��is a new component or variant that isn’t currently in the design system but maybe ought to be.A pattern����� or��recipe����� is a composition of design system components that is owned and assembled by the product teamA more nuanced governance process

We’ve dug into these details with a number of clients, and I’ve updated our��design system governance diagram��to detail how to handle these different scenarios.

Once the teams are chatting, they can unpack the scenario and figure out what ��� if anything ��� needs to be done. One of best outcomes is that no new work needs to happen and the DS team can guide the product team to existing solutions and save hours, days, or weeks of unnecessary work. Hooray!

But if the teams agree that new work needs to happen, the next question to ask is��“What’s the nature of the new work to be done?”

Handling bugs

If it’s truly a��bug, the design system team should address it with extreme urgency and release a patch as soon as possible. Addressing true defects in the live system should be the highest priority for the design system team; teams won’t trust or use a busted system.

Handling visual discrepancies

In the case of a visual discrepancy, the first question to ask is: “is this an issue with the design system?” If it’s a misalignment between the design system’s design and code libraries, it should be treated as a bug and addressed immediately.

But often it’s a product-level discrepancy where a product designer has created a deviation from the system or invented new patterns. It’s important to ask:��are these changes deliberate and intentional?

A product designer creating some purple buttons simply because they like the color purple isn’t justifiable, so the course of action should be for them to update the design to better align with the design system. But! Perhaps the purple buttons were created to run and A/B test or to support a specific campaign. In that situation, the teams may agree that’s deliberate and justifiable, so the product team can carry on implementing that custom UI solution. The design system team should make a note to follow-up with the team to hear how things turned out.

Handling features

Often product teams have needs that aren’t handled by the current design system library. For these situations, the first question becomes:��Does the feature belong in the design system?

Many times, product teams need to create and own their own��recipes��— compositions of core design system components and/or custom UI elements. Those recipes should be used consistently within a product, but may not be universal enough to include in the core design system team. The design system team can help guide the product teams to create and own their own recipes that work with the grain of the design system.

In other situations, a new feature should indeed belong in the core design system. In these cases, the question becomes:��can that work happen to meet the product team’s timeline without sacrificing the high standards of the design system?��If the answer is yes, then great! The work can be built into the system. However if there’s not enough time, the product team should own that work in order to meet their deadline, and the DS team should add it to their backlog to address it when they can.

Design systems die in the darkness

We’ve trained the design system teams we work with to be extremely skeptical when they don’t hear from consuming teams. When you don’t hear from them, it’s typically not a sign of “everything is going great” and is more likely “something is going very wrong.” So be proactive and reach out. When in doubt, have a conversation.

Design system governance involves coming together and collaborating on the best way to handle fuzzy situations. It’s critical for teams to collaborate, communicate, and dig into the nuance of a situation to determine the best course of action. Hopefully this framing can help your team be effective.

We help organizations of all shapes and sizes establish and evolve their entire design system practice: from assets and architecture to people, process, and culture. If you could use help taking your design system to the next level,��feel free to reach out!

Design of AI: Sentient Design

This is part of a series about Sentient Design, the already-here future of intelligent interfaces and AI-mediated experiences.

The book

Sentient Design by Josh Clark with Veronika Kindred will be published by Rosenfeld Media.

The talk

Watch Josh Clark's talk ���Sentient Design���

The workshop

Book a workshop for designing AI-powered experiences.

Need help?

If you’re working on strategy, design, or development of AI-powered products, we do that! Get in touch.

The marvelous Design of AI podcast features a conversation with Big Medium���s Josh Clark and Veronika Kindred about Sentient Design and the already here future of intelligent interfaces. Along with hosts Brittany Hobbs and Arpy Dragffy, Josh and Veronika discuss AI as a design material���the hows, whys, and implications of using machine intelligence to create radically adaptive, context-aware digital experiences.

And friends, they get into it. The conversation highlights the importance of design in shaping machine-intelligent experiences, focusing on outcomes and human need over technology.

Listen on SpotifyListen on Apple PodcastsWatch at Design of AI

Josh and Veronika address the challenges and opportunities for using machine intelligence in various domains, from healthcare to education to consumer products. They also explore ethical considerations, the need for productive skepticism, and how to raise the bar for our expectations and experiences of AI-powered interfaces. And not least, the dad-daughter pair also dig into generational perspectives about this new technology���and why old heads like Josh need young heads like Veronika to escape calcified assumptions.

And no kidding, lots more:

The types of intelligent experiences that generative AI enablesMoving beyond the chatbot: Where AI-powered interfaces go nextRole of designers in shaping the next generation of digital productsTypes of relationships Gen Z and Gen Alpha will have with machine intelligenceShould this be a period of optimism or skepticism?What they said

A few highlights to get you started:

Josh: ���The flurry around AI has been on the low-hanging fruit of productivity, and I think that there’s something that is bigger���a more meaningful transformation of experience ���that is afoot here."

Josh: ���We are already used to this idea of radically adaptive _content_���Netflix, Amazon, these prediction or recommendation features that are so familiar that they seem almost boring. The opportunity now is to say, oh wait, we can do that with UX now."

Josh: "We are used to designing the happy path as designers. There���s a set of interactions and data over which we have complete control. We set up the levers and the knobs and the dials for people to turn, and we know the path that they’re going to follow. But once you start having machine-intelligent experiences where the system is mediating this, you don���t have that control anymore, which means that the design experience shifts from creating this static experience to something that is much more responsive.���

Veronika: "I’ve been surprised by how many of these products are put to market that just don’t work, or really don’t do what they promise to do. Maybe you can get one idea to be conceptualized out of it, but you can’t take it to the next level at all. It just completely falls apart when you try to initiate any sort of feedback loop. That���s been my my biggest surprise: just how fast people are rushing to get these products out of the gate when they are not good enough yet.���

Josh: “I’m a big fan of getting rid of the sparkles like I think that all that that’s doing is saying, ���this is going to be weird and broken.��� Let���s instead think: we’re making a thing that is going to work, and we should present it to the user as any other technology. It’s just software, after all. It���s not magic. It���s just software.”

Josh: ���How do we lean into that weirdness as an asset instead of as a liability? Because we can’t fix it being a liability."

Veronika: “I think the more you engage, the more skepticism you should bring. If your expectations are low, you can be so happy when you’re wrong.”

Josh: ���One of the things that Veronika and I are trying to do with Sentient Design is not only show how you can build new kinds of experiences and products and interactions , but also: how do you lean into the better part of this and not go into the fears around this? How do we create experiences that amplify judgment and agency instead of replace them?���

Veronika: “I kind of got the sense that AI is not so much a huge force for good or bad in the world. It’s more like oil. It helps people heat their home and drive their cars, but it also is a great tool for both equality and inequality.”

Josh: ���When you ask, you know, what’s a cutting edge application? I would say it’s not even a technology application. It’s a mindset application. What kind of world do we want to design for with this? And that’s what we talk about when we talk about sentient design. Let’s let the designers be sentient and mindful about what we can do with this technology.���

Veronika: “We should raise our standards and really see that this is the moment for designers to become the ultimate mediator for users’ needs.”

Tune inListen on SpotifyListen on Apple PodcastsWatch at Design of AI