Big Medium - Full Feed

Design Systems Q&A

Mon, 18 Nov 2024 17:20:14 UT

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

“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

Sun, 10 Nov 2024 18:14:29 UT

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

Wed, 16 Oct 2024 14:06:17 UT

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 team

A 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

Tue, 15 Oct 2024 17:02:35 UT

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.

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 enables
Moving beyond the chatbot: Where AI-powered interfaces go next
Role of designers in shaping the next generation of digital products
Types of relationships Gen Z and Gen Alpha will have with machine intelligence
Should 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 in

This AI Pioneer Thinks AI Is Dumber Than a Cat

Mon, 14 Oct 2024 12:47:15 UT

Christopher Mims of the Wall Street Journal profiles Yann LeCun, AI pioneer and senior researcher at Meta. As you’d expect, LeCun is a big believer in machine intelligence—but has no illusions about the limitations of the current crop of generative AI models. Their talent for language distracts us from their shortcomings:

Today’s models are really just predicting the next word in a text, he says. But they’re so good at this that they fool us. And because of their enormous memory capacity, they can seem to be reasoning, when in fact they’re merely regurgitating information they’ve already been trained on.

“We are used to the idea that people or entities that can express themselves, or manipulate language, are smart—but that’s not true,” says LeCun. “You can manipulate language and not be smart, and that’s basically what LLMs are demonstrating.”

As I’m fond of saying, these are not answer machines, they’re dream machines: “When you ask generative AI for an answer, it’s not giving you the answer; it knows only how to give you something that looks like an answer.”

LLMs are fact-challenged and reasoning-incapable. But they are fantastic at language and communication. Instead of relying on them to give answers, the best bet is to rely on them to drive interfaces and interactions. Treat machine-generated results as signals, not facts. Communicate with them as interpreters, not truth-tellers.

This AI Pioneer Thinks AI Is Dumber Than a Cat | WSJ

Beware of Botshit

Sun, 13 Oct 2024 15:21:57 UT

botshit noun: hallucinated chatbot content that is uncritically used by a human for communication and decision-making tasks. “The company withdrew the whitepaper due to excessive botshit, after the authors relied on unverified machine-generated research summaries.”

From this academic paper on managing the risks of using generated content to perform tasks:

Generative chatbots do this work by ‘predicting’ responses rather than ‘knowing’ the meaning of their responses. This means chatbots can produce coherent sounding but inaccurate or fabricated content, referred to as ‘hallucinations’. When humans use this untruthful content for tasks, it becomes what we call ‘botshit’.

A Radically Adaptive World Model

Sun, 13 Oct 2024 14:21:25 UT

Ethan Mollick posted this nifty little demo of a research project that generates a world based on Counter-Strike, frame by frame in response to your actions. What’s around that corner at the end of the street? Nothing, that portion of the world hasn’t been created yet—until you turn in that direction, and the world is created just for you in that moment.

This is not a post that proposes the future of gaming or that tech will replace well-crafted game worlds and the people who make them. This proof of concept is nowhere near ready or good enough for that, except perhaps as a tool to assist/support game authors.

Instead, it’s interesting as a remarkable example of a radically adaptive interface, a core aspect of Sentient Design experiences. The demo and the research paper behind it show a whole world being conceived, compiled, and delivered in real time. What happens when you apply this thinking to a web experience? To a data dashboard? To a chat interface? To a calculator app that lets you turn a blank canvas into a one-of-a-kind on-demand interface?

The risk of radically adaptive interfaces is that they turn into robot fever dreams without shape or destination. That’s where design comes in: to conceive and apply thoughtful constraints and guardrails. It’s weird and hairy and different from what’s come before.

Far from replacing designers (or game creators), these experiences require designers more than ever. But we have to learn some new skills and point them in new directions.

Ethan Mollick's post on LinkedIn

Exploring the AI Solution Space

Sun, 13 Oct 2024 13:58:23 UT

Jorge Arango explores what it means for machine intelligence to be “used well” and, in particular, questions the current fascination with general-purpose, open-ended chat interfaces.

There are obvious challenges here. For one, this is the first time we’ve interacted with systems that match our linguistic abilities while lacking other attributes of intelligence: consciousness, theory of mind, pride, shame, common sense, etc. AIs’ eloquence tricks us into accepting their output when we have no competence to do so.

The AI-written contract may be better than a human-written one. But can you trust it? After all, if you’re not a lawyer, you don’t know what you don’t know. And the fact that the AI contract looks so similar to a human one makes it easy for you to take its provenance for granted. That is, the better the outcome looks to your non-specialist eyes, the more likely you are to give up your agency.

Another challenge is that ChatGPT’s success has driven many people to equate AIs with chatbots. As a result, the current default approach to adding AI to products entails awkwardly grafting chat onto existing experiences, either for augmenting search (possibly good) or replacing human service agents (generally bad.)

But these ‘chatbot‘ scenarios only cover a portion of the possibility space — and not even the most interesting one.

I’m grateful for the call to action to think beyond chat and general-purpose, open-ended interfaces. Those have their place, but there’s so much more to explore here.

The popular imagination has equated intelligence with convincing conversation since Alan Turing proposed his “imitation game” in 1950. The concept is simple: if a system can fool you into thinking you’re talking to a human, it can be considered intelligent. For the better part of a century, the Turing Test has shaped popular expectations of machine intelligence from science fiction to Silicon Valley. Chat is an interaction cliché for AI that we have to escape (or at least question), but it has a powerful gravitational force. “Speaks well = thinks well” is a hard perception to break. We fall for it with people, too.

The “AI can make mistakes” labels don’t cut it.

Given the outsized trust we have in systems that speak so confidently, designers have a big challenge when crafting intelligent interfaces: how can you engage the user’s agency and judgment when the answer is not actually as confident as the LLM delivers it? Communicating the accuracy/confidence of results is a design job. The “AI can make mistakes” labels don’t cut it.

This isn’t a new challenge. I’ve been writing about systems smart enough to know they’re not smart enough for years. But the problem gets steeper as the systems appear outwardly smarter and lull us into false confidence.

Jorge’s 2x2 matrix of AI control vs AI accuracy is a helpful tool to at least consider the risks as you explore solutions.

Source: Jorge Arango

This is a tricky time. It’s natural to seek grounding in times of change, which can cause us to cling too tightly to assumptions or established patterns. Loyalty to the long-held idea that conflates conversation with intelligence is doing a disservice. Conversation between human and machine doesn’t have to mean literal dialogue. Let’s be far more expansive in what we consider “chat” and unpack the broad forms these interactions can take.

Exploring the AI Solution Space | Jorge Arango

Introducing Generative Canvas

Tue, 08 Oct 2024 21:06:04 UT

On-demand UI! Salesforce announced its pilot of “generative canvas,” a radically adaptive interface for CRM users. It’s a dynamically generated dashboard that uses AI to assemble the right content and UI elements based on your specific context or request. Look out, enterprise, here comes Sentient Design.

I love to see big players doing this. Here at Big Medium, we’re building on similar foundations to help our clients build their own AI-powered interfaces. It’s exciting stuff! Sentient Design is about creating AI-mediated experiences that are aware of context/intent so that they can adapt in real time to specific needs. Veronika Kindred and I call these radically adaptive interfaces, and it shows that machine-intelligent experiences can be so much more than chat. This new Salesforce experience offers a good example.

For Salesforce, generative canvas is an intelligent interface that animates traditional UI in new and effective ways. It’s a perfect example of a first-stage radically adaptive interface—and one that’s well suited to the sturdy reliability of enterprise software. Generative canvas uses all of the same familiar data sources as a traditional Salesforce experience might, but it assembles and presents that data on the fly. Instead of relying on static templates built through a painstaking manual process, generative canvas is conceived and compiled in real time. That presentation is tailored to context: it pulls data from the user’s calendar to give suggested prompts and relevant information tailored to their needs. Every new prompt or new context gives you a new layout. (In Sentient Design’s triangle framework, we call this the Bespoke UI experience posture.)

So the benefits are: 1) highly tailored content and presentation to deliver the most relevant content in the most relevant format (better experience), and 2) elimination or reduction of manual configuration processes (efficiency).

In Sentient Design, we call this the Bespoke UI experience posture.

Never fear: you’re not turning your dashboard into a hallucinating robot fever dream. The UI stays on the rails by selecting from a collection of vetted components from Salesforce’s Lightning design system: tables, charts, trends, etc. AI provides radical adaptivity; the design system provides grounded consistency. The concept promises a stable set of data sources and design patterns—remixed into an experience that matches your needs in the moment.

This is a tidy example of what happens when you sprinkle machine intelligence onto a familiar traditional UI. It starts to dance and move. And this is just the beginning. Adding AI to the UX/UI layer lets you generate experiences, not just artifacts (images, text, etc.). And that can go beyond traditional UI to yield entirely new UX and interaction paradigms. That’s a big focus of Big Medium’s product work with clients these days—and of course of the Sentient Design book. Stay tuned, lots more to come.

Introducing Generative Canvas: Dynamically Generated UX, Grounded in Trusted Data and Workflows

Your Sparkles Are Fizzling

Sat, 28 Sep 2024 21:23:51 UT

Please put the ✨sparkles✨ away. They’re sprinkled everywhere these days, drizzled on every AI tool, along with a heaping dollop of purple hues and rainbow gradients. It’s magic, it’s special, it’s sparkly.

It’s really not magic, of course—it’s just software. And because so many companies have heedlessly bolted AI features onto existing products, the shipped features are often half-baked, experimental, frequently shoddy. Instead of “magic” or “new,” sparkles are fast becoming the new badge for “beta.” The message sparkles now convey is, “This feature is weird and probably broken—good luck!” It would be more honest to use this emoji instead: 🤪

So what symbol should you use to represent machine-intelligent tools? How about no symbol at all. No need to segregate AI features or advertise their AI-ness as anything special. What matters to the user is what it does, not how it’s implemented.

We give no special billing to spell checkers or spam filters or other algorithmic tools; we just expect them to work. That’s the expectation we should set for all features, whether they’re enabled by machine intelligence or not. Features should just do what it says on the tin, without the sparkle-shaped asterisk. You’re revising text, generating images, assembling insights, making music, recommending content, predicting next steps, etc. These are simply product features—like every other powerful feature your experience offers—so present them that way. No special label required, no jazz hands needed.

Drop the sparkles. No need to segregate AI features or advertise their AI-ness as anything special. What matters to the user is what it does, not how it’s implemented.

One of the essential characteristics of Sentient Design is that it is deferential. It’s a posture that suggests humility. Put the disco ball away. Your goal should be to make machine intelligence a helpful and seamless part of the user experience, not a novelty or an afterthought.

If the feature actually is weird, unreliable, or broken, that’s a bigger problem that sparkles won’t solve. Maybe your feature isn’t ready to ship. Or better, perhaps you need to find a way to make the weirdness an asset instead of a reliability. Now that’s a fun design challenge to solve—and one that engages with the grain of machine intelligence as a design material. Take a measured pragmatic approach to what machine intelligence is good at and what it isn’t—and be equally measured in how you label it. Be cool. Put away the sparkles.

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.

Data Whisperers, Pinocchios, and Sentient Design

Fri, 27 Sep 2024 13:00:28 UT

It took all of three minutes for Google’s NotebookLM to create this lively 12-minute podcast-style conversation about Sentient Design:

Bonkers, right? The script and the voices—along with the very human pauses, ums, and mm-hmms—all of it is machine-generated. It even nails the emotional tenor of the podcast format. I gave NotebookLM several chapters of the Sentient Design book manuscript, pushed a button, and this just popped out.[1]

The speed, quality, and believability of this podcast are remarkable, but they’re not even the most interesting thing about it. Here’s the bit that gets me excited: by transforming data from one format into another, this gives the content new life, enabling a new use case and context. It’s a whole new experience for content that was previously frozen into a different shape. Instead of 100 pages of PDFs that require your eyes and a few hours of time and attention, you’ve got a casual, relatable conversation that you can listen to on the go to get the gist in just a few minutes. It’s a new format, new mindset, new context, new user persona… and a new level of accessibility.

Listen to the data whisperer

In Sentient Design, Veronika and I call this the data whisperer experience pattern. The data whisperer shifts content or data from one format to another. One super-pragmatic example is extracting structured data from a mess of unstructured content: turn blobs of text into JSON or XML so that they can be shared among systems. Machine intelligence is great at doing things like this—translation among formats. But this can go so much farther than file types.

If you listen to the podcast, you’ll hear the robot hosts talk about the Sentient Triangle, a way to describe different postures for machine-intelligent experiences. Data whisperers stake out the interoperable point of the triangle.

Data whisperers stake out the interoperable corner of the Sentient Design triangle.

Interoperability is typically associated with portability among systems. But data whisperers become even more powerful when they enable portability among experiences. Instead of focusing only on the artifacts that machine intelligence can generate with these transformations, consider the new interaction paradigms they could enable.

As a designer, ask yourself: what becomes possible when I liberate this content from its current form, and how can machine intelligence help me do that? And even better: what if you think of it beyond rote translation of modes or formats (text to speech, English to Chinese, PDF to JSON) but also manner, interaction, or even meaning? That’s what the podcast example hints at; it’s doing something far more than converting 100 PDF pages into audio. It’s reinterpreting the content for a whole new context.

Tim Paul of GOV.UK put together this side project showing another example of using AI to rescue content from PDFs. His experiment translates static government forms into interactive multi-step web forms rendered in the gov.uk design system.

Tim Paul’s AI experiment rescues forms trapped inside PDFs and converts them to web forms using GOV.UK’s design system.

Here at Big Medium, we did something similar when we built a Figma plugin for one of our clients. The plugin takes a sketch (or text prompt or screenshot) and creates a first-pass Figma layout using the company’s design system components. Here it is in action, acting as a sous chef to organize the components so that the designer “chef” can take over and create the final refined result:

The Pinocchio interaction pattern

This plugin is a tight example of the data whisperer pattern: it thaws meaning and agency from a frozen artifact. But it’s also doing something more: it transforms content from low fidelity to high fidelity.

In Sentient Design, we call this the Pinocchio interaction pattern—turning the puppet into a real boy. Use the Pinocchio pattern to flesh an outline into text, zap a sketch into an artwork, or transform a wireframe into working code. Pinocchio is a data whisperer that elevates an idea into something functional.

Here’s another Pinocchio example. tldraw is a framework for creating digital whiteboard apps. The tldraw team created a “Make Real” feature that transforms hand-drawn sketches or wireframes into interactive elements built with functional code. Just draw a sketch, select it, and click the Make Real button to insert a working web view into the canvas. It’s an inline tool to enable quick and easy prototyping, turning a Pinocchio sketch into “real boy” markup.

When you bake the Pinocchio pattern into the fabric of an application, its interface becomes a radically adaptive surface—a free-form canvas that adapts to your behavior and context. You can see Apple working this angle in the iPad applications it previewed earlier this year. In Notes for iPad, Apple’s demo shows how you can circle a sketch, and the app creates a high-fidelity drawing based on the sketch and surrounding content context.

Or the Math Notes feature of iPad’s new calculator app lets you scrawl equations on the screen, and it transforms them into working math—spreadsheet functionality in sketch format. Scribbled numbers become variables. A column of figures becomes a sum. An equation becomes an interactive graph.

Experience over artifact

With generative AI, the generation tends to get all the attention. That’s a missed opportunity. With the data whisperer and Pinocchios patterns, you can create not only new content artifacts but new experience paradigms. You can liberate content and interaction from frozen formats, unlock new use cases, and help people move from rough idea to refined concept. Lean into it, friends, there’s much to explore here.

My favorite part of the podcast is when one of the AI-generated hosts says, “Sometimes I even forget I’m talking to a computer.” The other responds, “Tell me about it.” ↩

Workshop: Craft AI-Powered Experiences with Sentient Design

Tue, 24 Sep 2024 12:56:30 UT

Now available! We offer private workshops to teach product and design teams to imagine, design, and deliver AI-powered features and products. It’s all backed by Big Medium’s Sentient Design methodology, a practical framework for designing intelligent interfaces that are radically adaptive to user needs and intent. We’ve been doing these workshops at conferences and with our clients, and now we want to share them with you. These workshops are available to organizations that would like to offer a private workshop for their design or product teams.

These measured, pragmatic workshops are zero hype. They provide real-world AI literacy and practical techniques that your team can use today—like right now—to imagine surprising new experiences or to improve existing products. You and your team will discover entirely new interaction paradigms, along with new challenges and responsibilities, too. This demands fresh perspective, technique, and process; Sentient Design provides the framework for delivering this new kind of experience.

What’s in the workshop?

Our Sentient Design workshops are immersive, hands-on experiences that guide participants through the whole life cycle of designing machine-intelligent experiences. Here’s what we’ll do together:

Prototype a new product: identify, imagine, and design AI-powered features that solve real problems (not just “because AI”).
Learn to use machine-generated content and interaction as design material in your everyday work.
Use machine intelligence to deliver entirely new interactions or simply elevate traditional interfaces.
Explore radically adaptive interfaces that are conceived in real-time based on user context and intent.
Get your hands dirty working with models directly to learn their strengths and quirks.
Discover emerging UX patterns and postures that go way beyond “slap a chatbot on it.”
Learn the art of defensive design. AI can be… unpredictable (and weird, wrong, and biased, too). Make its weirdness an asset instead of a liability.
Adopt techniques to set user expectations and guide behavior to match the system’s ability.
Use responsible practices that build trust and transparency.

The workshops mix it up with lecture (the fun kind), discussion, and hands-on exercises. You and your team will put theory into practice through collaborative design sessions, prototyping exercises, and critical analysis of real-world AI applications. By the end of the workshop, your team will have a solid foundation in Sentient Design principles and a toolkit of techniques and design patterns to apply in your work.

Who it’s for

This workshop is perfect for designers, product owners/managers, and design-minded developers who want to stay ahead of the curve in AI-powered experiences. If you’re curious about how to make AI work for people (instead of the other way around), this is for you.

The workshop can flex to accommodate groups from 10 to 100 people.

Who’s teaching?

The workshops are led by Big Medium’s Josh Clark and Veronika Kindred, authors of Sentient Design, the forthcoming book from Rosenfeld Media.

Reserve your workshop

Get in touch with Josh Clark to explore availability and pricing.

We offer flexible formats to suit your team’s needs:

Half-day introduction
Full-day immersion
Two-day comprehensive program

The workshops may be offered online via video conference or in person. No special preparation is required for your team. No prior AI or machine-learning experience is required—only a healthy mix of imagination and skepticism. Bring your human intelligence, and we’ll supply the artificial kind.

Workshops are flat-rate (not by number of attendees). Half-day workshops start at $5000, and pricing varies for length and for remote vs in-person.

Our workshops are also available at our frequent speaking events. Here’s what’s coming up:

The Already-Here Future of Prototyping

Fri, 20 Sep 2024 13:17:29 UT

I’ve spent pretty much my entire career helping teams design software rather than pictures of software. Development is design. Frontend design. Front-of-front-end code. Front-end workshop environments. Death to the waterfall. The Hot Potato process. Designer/developer collaboration. Pattern Lab. I’ve shared all of these concepts, words, and tools to help bring the worlds of design and development closer to one another so that people can make great things together.

Unfortunately, all these years later it still feels like our design processes have calcified into a one-dimensional, one-directional waterfall workflow. Design tooling has gotten significantly better over the years, which in my view is truly a double-edged sword. On one hand, getting designers using components, variants, autolayout, and variables is way better than Photoshop smart objects and these developments have been extremely welcome. On the other hand, the tooling has gotten to a “good enough” state that allows designers to stay in their comfort zone and insulated from the mediums for which they’re ultimately designing. The old limitations of design tools used to require designers to enlist the help of developers, which while not ideal still created opportunities for cross-disciplinary collaboration and shared understanding.

I’m still hopeful that we can restore a collaborative process and get teams working better together and to get designers closer to real software. It’s critical for designers to capitalize on the opportunities and confront the constraints of the medium for which they’re designing, which is why cross-disciplinary collaboration and prototyping in code are still so important.

[email protected]" alt="A tweet that reads Telling web designers they dont need to worry about code is like telling architects they dont need to worry about steel, wood, or physics" />

At the end of the day, design tools are abstractions that don’t paint the full picture of what a digital experience is. I dig into this in Atomic Design:

Working in HTML, CSS, and presentational JavaScript allows teams to not only create aesthetically beautiful designs, but demonstrates those uniquely digital design considerations like:

flexibility

impact of the network

interaction

motion

ergonomics

color and text rendering

pixel density

scrolling performance

device and browser quirks

user preferences

Crucially, jumping into the browser faster also kick-starts the creation of the patterns that will make up the living, breathing design system.

Atomic Design, Development Is Design

Every medium has its affordances, its opportunities, and its limitations, and the sooner we factor those into our design process the better. Thankfully, expressing design in code is easier than ever.

“Should designers code?” is a funny question now

“Should designers code?” has always been a hilariously charged question in the world of design. But LLM tools like ChatGPT and Claude have made it easier than ever for anyone — including and perhaps especially non-developers — to develop ideas in code. Designers, product managers, and even lay people don’t need to know how to code in order to create something and explore ideas. This democratization of code opens many doors and unlocks so many opportunities for creativity and collaboration.

You can create a functioning prototype of an idea in the time it would take you to draw 4 rectangles in Figma.

This new generation of tools erases many of the excuses used to avoid involving developers and exploring ideas in code during the “design phase” of an effort. “Oh we can’t free up time for our developers”, or “this will take too long.” Those excuses don’t hold water anymore. In fact, you can create a functioning prototype of an idea in the time it would take you to draw 4 rectangles in Figma. Sure, the window dressing might not be perfect, but there are really no excuses left for code to not be a key part of the design process.

Flow and a focus on results

As I’ve adopted these tools in my own workflow, I’m struck by how much these tools get me out of that place where I always seem to have a million ideas buzzing around in my head, and I often talk myself out of pursuing these ideas by mentally stressing about getting (the right!) environments stood up, choosing (the right!) tools, and (the right!) code syntax, and creating (the right!) features.

Rather than getting bogged down by all of these hypothetics, I can instead use these tools to focus my attention of getting my ideas out of my head and into the world. That’s why I wanted to put this video together to show a real-life example of turning a frequently-occurring idea (in this case, “I should have a ‘request song’ page on my website”) into actual working software:

This immediacy has already proven to be so valuable both in my personal practice as well as in our professional work. We’ll be on a Zoom call with a client discussing an idea, and when the conversation ventures into hypothetical back-and-forth, we’ll spin up a quick prototype to give everyone something tangible to latch onto and iterate over together. It really is a powerful tool in the creative toolkit.

The design process needs a serious shake-up

The ability to rapidly prototype in code — now supercharged by the introduction of LLM tools — brings us closer to truly designing for the web medium. It democratizes the process, allows more people to express ideas in code, makes it easier to consider the medium’s opportunities and constraints, and gets ideas further down the line faster than ever.

There’s a time and a place for traditional design processes, and sure creating a prototype is not the same as creating a ready-to-ship product. It’s important to note that these approaches are not mutually exclusive; you can create and advance prototypes while sweating the design details and code architecture elsewhere. But too often we don’t create the practice nor the room for designers to do this type of exploration. Does everything need to originate in Figma and be fully articulated there? Increasingly, the answer is “no”. There’s a big world outside of Figma, and I recommend exploring it!

Rapid iteration and solid foundations

Of course, putting together a quick prototype detached from your design and development reality is all well and good. Cute, even! But at Big Medium, we’re helping our client teams integrate these new workflows and tools into their organization’s architecture, workflows, and culture. We’re finding that coupling this generative creative approach with the sturdy foundations of a design system yields some truly impressive results. Design systems and AI are a potent combination.

Sure these tools help save time and money, but it also blows open the doors of new creative terrain. Ideas that would have taken days, weeks, or months to pursue can now be explored over the course of a meeting. It’s truly wild. And when coupled with an organization’s solid design foundations, the ideas don’t seem like distractions or impossible-to-implement experiments; instead they feel like…the new design process.

Using these tools in our behind-the-scenes design process unlocks new opportunities, but it doesn’t need to stop there. With Sentient Design, my partner Josh Clark demonstrates how these tools can be used to create radically adaptive user experiences that morph and shift based on the user’s specific context and needs.

We’re entering a new era of design, and it’s been fun to explore and help our client teams navigate this new terrain. If your team would welcome help integrating these tools into your practice, feel free to reach out! We’re offering AI for designers and developers workshops and engagements to help organizations successfully integrate these these tools into their design practices.

Now get out there and get into some code!

Change Blindness

Tue, 13 Aug 2024 22:00:45 UT

A great reminder from Ethan Mollick of how quickly things have changed in AI generation quality in the last 18 months. AI right now is the worst that it will ever be; only getting better from here. Good inspiration to keep cranking!

When I started this blog there were no AI chatbot assistants. Now, all indications that they are likely the fastest-adopted technology in recent history.

Plus, super cute otters.

Change blindness | One Useful Thing

Introducing Structured Outputs in the API

Wed, 07 Aug 2024 14:26:20 UT

OpenAI introduced a bit of discipline to ensure that its GPT models are precise in the data format of their responses. Specifically, the new feature makes sure that, when asked, the model responds exactly to JSON schemas provided by developers.

Generating structured data from unstructured inputs is one of the core use cases for AI in today’s applications. Developers use the OpenAI API to build powerful assistants that have the ability to fetch data and answer questions via function calling(opens in a new window), extract structured data for data entry, and build multi-step agentic workflows that allow LLMs to take actions. Developers have long been working around the limitations of LLMs in this area via open source tooling, prompting, and retrying requests repeatedly to ensure that model outputs match the formats needed to interoperate with their systems. Structured Outputs solves this problem by constraining OpenAI models to match developer-supplied schemas and by training our models to better understand complicated schemas.

Most of us experience OpenAI’s GPT models as a chat interface, and that’s certainly the interaction of the moment. But LLMs are fluent in lots of languages—not just English or Chinese or Spanish, but JSON, SVG, Python, etc. One of their underappreciated talents is to move fluidly between different representations of ideas and concepts. Here specifically, they can translate messy English into structured JSON. This is what allows these systems to be interoperable with other systems, one of the three core attributes that define the form of AI-mediated experiences, as I describe in The Shape of Sentient Design.

What this means for product designers: As I shared in my Sentient Design talk, moving nimbly between structured and unstructured data is what enables LLMs to help drive radically adaptive interfaces. (This part of the talk offers an example.) This is the stuff that will animate the next generation of interaction design.

Alas, as in all things LLM, the models sometimes drift a bit from the specific ask—the JSON they come back with isn’t always what we asked for. This latest update is a promising direction for helping us get disciplined responses when we need it—so that Sentient Design experiences can reliably communicate with other systems.

Introducing Structured Outputs in the API | OpenAI