Designers of Tonic: Our Config 2026 Roundup

Takeaway: Code Layers is less about speed and more about where the conversation happens.

What stuck with me most from Config was Code Layers, specifically what they do to the handoff conversation between designers and development teams. So much of our day-to-day work is spent translating between our design intent and what a dev team builds, and that translation is where things can often get lost. After all, a comment on a static mock-up doesn't carry the same weight as critiquing the way something actually behaves in implementation. If a code layer sits right there on the canvas and teammates can duplicate it, comment on it, and compare directions the same way we already do with design frames, that's a real shift in how early feedback happens; not just a faster way to get from Figma to production.

That said, I'm withholding full enthusiasm or skepticism until I've used it on a real project, which will hopefully be soon. So far, the design community's reaction seems split between "nothing will get lost in translation between design and code anymore" and "this just makes Figma an exploration tool you could bypass by going straight from AI prompt to shipped code,” and I think both camps have a point.

For consulting work specifically, where we're often the connective tissue between a client's internal dev team and our own design process, I'm curious whether Code Layers actually reduces friction (be it good or bad) or just moves it earlier in the process. I'd also want to know how (or if) it holds up against accessibility scrutiny, since "generate it and it just works!" tooling has historically treated a11y as an afterthought. *five-minute-long-sigh*

Takeaway: There's no "caught up" with AI, only how comfortable you get with staying in motion.

There's a moment in Chelsea Larsson's talk, "Writing for humans in an AI world", where she asks, half-joking, "are we cooked?" It's the question every designer has quietly asked themselves at some point in the last few years. Larsson's answer, eventually, is a kind of design principle: build on ground that never stops shifting, make decisions that shape a future you can't see the shape of yet. No pressure.

I keep coming back to both of those lines, the panic and the principle, because I don't think one replaces the other. The fear probably isn't going anywhere. What I'm trying to release is the idea that "catching up" is even possible. That word assumes there's a fixed point ahead of you, something stable enough to close the distance to. There isn't one. The gap between what AI can do and what we understand about it doesn't shrink, it just moves. Sometimes sideways, sometimes backwards, rarely in a straight line. So the goal can't be catching up. It has to be getting comfortable with motion itself.

Larsson calls the personal side of this "ego death,” realizing that a skill you built your identity around isn't needed in quite the same way anymore. That's its own kind of discomfort, separate from the fear of falling behind.

But discomfort is usually just what growth feels like before you've named it. I don't think I'll ever feel caught up, and I'm working on being okay with that. That's not resignation, it's just what comfort with motion actually looks like from the inside.

Takeaway: You rarely know which skills matter most until you look back, so build the ones that pull you, not just the ones on the roadmap.

The talk I keep returning to wasn't even about Figma: Lauren Hom's talk on juggling multiple creative passions, specifically her idea of "preparing for your big break" before you know what it is. Her own path (fine arts, ad agency, hand-lettering, chalkboards, murals, eventually culinary school) never looked like a plan from the inside; it only reads as one in reverse. That resonated with my own zigzag: fine arts to mechanical engineering to architecture to graphic design to UX, with a handmade jewelry side project in the mix. None of it makes sense as a plan, but it does in hindsight, as a body of work.

I keep thinking about her distinction between doing something because you should versus because you want to. My history is a mixture of both, as I imagine it is for so many of us. Looking ahead, staying fluent in the latest Figma release or AI capability (or as fluent as I can, see Kellie's take above!) and growing my design skillset are simply part of delivering exceptional work for our clients.

But Lauren's talk is a good reminder that staying current isn't the only kind of growth worth investing in. The skills we pick up out of genuine curiosity, the ones nobody assigned, that don't show up on a roadmap, are often what end up adding something special. A new point of view, an unexpected service offering, a way of solving a client problem that didn't exist before someone poked at it for no particular reason. Making room for that kind of exploration alongside the expected skills-building is what keeps a design practice feeling like a craft, not a checklist.

Takeaway: Design can grow in more innovative ways when companies strive to benefit their community, and have the business model to match.

One of the talks that drew me in was Jésabel DC's "The future is low-tech" which made the case that we should take a lesson from early-2000s tech and build business models that reward community engagement over entrapment, and that doing so can lead to more innovative UX. As someone who also came to design through an anthropology background, I loved how she framed this less as a UX problem and more as a study of humans and their tech environments. It's a nice reminder that when the incentive is to create real value, design tends to follow, and can often lead down paths it wouldn't otherwise take. Her Animal Crossing example is a good one: Nintendo got paid when you bought the game, so they had no reason to trap you inside it. They could design for anticipation instead of retention.

Her Lego example was my other favorite because it touched on a problem I often face: if a step needs too much explaining, the fix is to change the design, not add a tutorial. People learn by doing, and I think there's a lot of room for us to lean into that more, building things that teach through use instead of onboarding flows, manuals, and tooltips. Designers should aim to make adoption fun and interactive.

I appreciated how the talk explored business strategy and UX, and the ways each shapes the other. Sometimes, business goals can feel disconnected from design goals, but it's a good reminder that we can create community and inspiration through the products we build.

Takeaway: Design has the power to include or exclude, so before designing for impact and connection, notice who's not in the room.

Public artist Ella Rochelle-Lawton gave a talk titled "The world of street art and care-filled design". Through her experience, she's learned that when art becomes public, it no longer exists in isolation. It's alive, evolving through each person who sees and interacts with it; its purpose and meaning are reshaped by the people and conversations that surround it. That's part of why starting is so hard when designing for public space. There's a permanence to it. There's no Cmd + Z, and no way to predict how the art will be experienced. Digital products give us far more room to change and iterate, but I think that same hesitation still lives in all of us as designers, because we, too, want to build something that lasts.

For Ella, the impact of design wasn't just something she witnessed in murals transforming people and communities, it's backed by research. A Yale-evaluated mural program found that when community members helped make the art (not just view it), neighborhoods saw measurable gains in social cohesion, agency, and feelings of safety. That's a takeaway for those of us shipping products, too. Designing with people, not just for them, isn't a nicety, it directly shapes the outcome. And the inverse is just as visible: Ella points to a community-inspired mural that lives in a neighborhood dotted with "hostile architecture" built to prevent resting.

That contrast is the whole point: design has the power to include or exclude. Street artists know their work will be seen, challenged, and built upon by everyone who passes it. Ours will be too. As designers, we have the responsibility to design with intention, with care, and with inclusion. So before I build anything meant to last, I'm asking: whose voice is missing? And how would it change what I design?

Takeaway: A great design system isn't defined by how well it enforces consistency, but by how well it enables teams to create, experiment, and evolve.

Lauren LoPrete's talk, "Design systems anarchy," challenged the way we often think about governance and consistency. Her observation that design systems can shift from being a resource to becoming a checkpoint really stuck with me. It made me reflect on my experiences across different clients and design systems, the ones that genuinely enabled better work versus the ones that unintentionally created friction. There have been moments where the best solution for a product didn't move forward simply because it didn't fit neatly within the boundaries of an existing system.

That's a reminder that design systems reach far beyond how a product looks and feels; they influence what teams feel empowered to create. A great system should open possibilities, not make teams second-guess decisions or spend energy working around constraints.

One of my biggest takeaways from Lauren's talk was that the best design systems aren't built around control, they're built around trust. They provide structure without suffocating creativity, establish principles without requiring permission for every decision, and evolve alongside the teams that use them. Her reminder that "deviation is the point" resonated with me, because the moments where teams push beyond an existing system are often the moments that reveal where the next evolution should begin. Just as we investigate why users struggle to adopt a product, we should approach system deviation with that same curiosity. A team working outside the system isn't necessarily a failure of governance. It may be a signal that the system has an opportunity to grow.

At Tonic, we often step into complex environments where teams are balancing existing systems, business needs, technical limitations, and evolving user expectations. Our role isn't to eliminate every deviation from a pattern or process; it's to understand why those moments happen and what they can teach us. The strongest solutions come from collaboration, curiosity, and a willingness to adapt. A design system should be a foundation that helps teams move faster and create better experiences, not a barrier standing in their way.