Thinking out loud

“Make it pretty” has always been an insidious expression, but I think it goes deeper than most people realize or acknowledge.

As I’ve heard it used, “Make it pretty” is usually deployed in one of the following ways:

…As a derogatory way of describing a role that one considers lesser than their own. This could be managers, devs, clients, or other stakeholders belittling design work. It could be UX designers carving out a space for themselves higher up the ranks than visual designers. The implication is always darkly the same: whoever spends time on this aspect of the work is sillier/fussier, less important, and less valuable.

…As an admonition for “doing design wrong”. Here, the implication is that something has been “made pretty” in the way that one might put lipstick on a pig: to wallpaper over deeper issues that should be prioritized and thought through. Think a help section with poor coverage and confusing navigation—but set in a legible font with a readable measure.

…As an unhelpful piece of feedback when someone reviewing a design thinks something is wrong, but lacks the time, willingness, or vocabulary to articulate what they actually mean.

All of these are already problematic, but in the world of digital product design, the negative implications of these tendencies have become encoded not just in worker social interactions, but in our tools, roles, and processes.

I’m thinking in particular of the seemingly evergreen challenge of bridging the so-called “gap” between design and development. This has been a hot topic for nearly as long as I can remember, but sometime around a decade or so ago, I started seeing folks treat this more as a tooling problem than a human problem.

We built sophisticated tools for design systems, for documenting design decisions and organizing sources of truth. We trained designers, developers, managers, teams, whole companies on the idea that if only these tools were set up properly, the translation between design intent and software implementation would be smooth.

No such thing has happened. We have succeeded only in cleaving visual design further from its medium, and given workers a new way to fight over “that doesn’t look right!” We dismantled the human communication and roles meant to bridge creative reasoning about human needs and the structural work of design engineering.

The irony is: our work—the work of design—is to make choices about how, when, where, and to what extent to abstract the complexity of computing systems away from users. Our job is to manage abstraction. Removing designers from the complexity of the medium doesn’t simplify the work—it only makes the problems intangible and undiscoverable, so that when something goes awry, there’s no one left to take responsibility for it.

I think it’s high time to stop trying to abstract the complexity of user interfaces away from designers, and invite them into the workshop where software lives and breathes.

I’m teaching this pilot coding course for designers, and I’ve been surprised by something I wasn’t expecting when I planned the course.

The students in the class are making stuff that is really playful and fun, and it seems like they’re having a ball doing it. They’re trying out wacky animations, stretching toward different aesthetics from retro to casual game to Rams, putting sound effects to their interactions, building things with full interactive states.

They’re responding to simple project prompts in an environment where they’re wrangling code with some of the most playful work I’ve ever seen come out of a design class. Less of the bleak sameness that tends to be the center of gravity for professional product design, and more exploration.

Why am I surprised by this? I think this is challenging some of my assumptions. In my experience, when working with code, especially as beginners, designers tend to play it safe. Poking and learning the limits of the system. I’ve read nearly two decades’ worth of hand-wringing criticism about how working directly in code limits creativity and blinds you to possibilities that only a design canvas might open up.

What do I think might be going on? Well I don’t know but I have a few guesses.

For one thing, these designers are building something real, but they’re not doing everything by hand—they have an LLM tool at their side, which has deep training data and pattern recognition for syntax and code structures, which which they can express ideas in natural language and reasonably expect some pattern matching to translate between their ideas and code. I can’t imagine completely what that feels like for a designer right now, but I’m fascinated to see it in action.

I also think that because they’re pushed outside of the normal comfort zone of designers—tools like Figma—and are aware that they’re learning without the expectation of knowing everything, they’re giving themselves more permission to play. Forget about design, as a teacher, if I get to see learners feel like the “work” part is slipping away, and they have permission to really play—that’s a great day. For any teacher.

Anyway, I’m excited to check out what they’re sharing in Discord every day, and just so curious to see how their work and thinking develops. It’s time for some new blood, energy, and thinking out there, and I enjoy my role the most when I simply get to sit back and appreciate the exploration.

Friendly mid-week reminder that design contains multitudes. Just because we do things in different ways, and make different choices, doesn’t mean we are trying to invalidate each others’ approaches.

If we are going to have a lot of new folks making end to end products for the first time, I have some general advice for, and wishes from, all of you:

First of all, I hope you avoid the temptation to work primarily alone. We have technology that makes it easier than ever to stay connected with people, but we’ve used it too often to isolate. Team up, build trust, and embrace your diversity of perspectives. It’ll make what you make together better too.

Second, there are going to be an enormous amount of competing priorities on your minds—don’t let the basics around making products accessible slip or be treated as an afterthought. There are so many foundational layers built into the web and other platforms that make this easy if you know to look for it and take the time to think about it in your plans.

Third: don’t forget to have fun. Seriously.

Fourth—pay attention to how what you’re making can fit into and contribute to a healthy overall ecosystem. The environment you’re currently working in or around is probably not very healthy and likely even toxic. This isn’t easy to do, but here are a few pieces of advice: try to bootstrap your business by spending less than you make, consider using existing standards and formats so that your work can interoperate with other tools, and ask yourselves on a regular basis how you can give your users and customers control and security over their own information.

Now go have fun and make something awesome.

Skills I think matter most right now

First and foremost: writing. Every shift over my lifetime seems to have come with an increase in the utility of written language. Emails, text messages, chats. We are social and communicative creatures, with such a rich and textured written culture. We write things down to help us think, remember, convey, articulate, record… Written language is nothing more or less than our shared mind. If it’s in your head, no one else can consider it. Write, express, shape your ideas into common language where you can test it, validate it, shine it, share it.

Go read Bird by Bird by Anne Lamott. Start with the chapters Short Assignments and Shitty First Drafts.

Second: thinking and working in systems. Systems thinking gives us some hope of making sense of things that are too complex to hold in our minds all at once. We are swimming in all kinds of complex systems, in our work, in our homes, politically, culturally. The systems themselves don’t become less complex or easier to predict the behavior of, but we can sometimes land on useful simplifications that at least give us a chance of nudging systems toward better outcomes.

Go read Donella Meadows. Start small with her essay Dancing with Systems.

Third: giving and receiving feedback. Getting into healthy feedback cycles with your fellows can be uncomfortable work; it requires us to sharpen our observation skills, stretch our articulation muscles, prick up our ears, and open our minds. I know of little more challenging or rewarding.

More advanced: asking for feedback, and asking others what feedback they need.

Go read Liz Lerman’s Critical Response Process. Pay close attention to Forming Neutral Questions.

Bonus skill: teaching. OK, I’m a teacher, I’m biased. But teaching as a practice will push you in all of the skills above, in service to others as well as yourself. Teaching will make you a better communicator, listener, thinker, and learner. We are all teachers in some way, and the practice doesn’t have to look like a traditional role. Volunteer for tutoring or mentorship. Run a workshop on something you care about. Take some friends for a walk and show them how you look for things to photograph. Share music you love with your kids, and show them why you love it. However you do it, practice consciously and take time to reflect.

Teach something first, then go read Teaching Adults by Ralph Brockett. Start with the chapter What is Effective Teaching? Applies just as well to non-traditional teaching practice, and to people who aren’t quite adults yet but maybe think they are.

I’ve been extremely hesitant to offer any “AI” courses so far—especially for designers I personally think most of what’s been going on in this space is pretty questionable. Not to mention I have a lot of mixed feelings about the hype cycles around LLM tech in general.

That said I do personally use them in my work. I’ve never spoken about it publicly, and I don’t intend to start now, because I don’t want to add to the noise. But I do know that for me personally, having an LLM at my fingertips in my code editor has been the only really valuable use case I’ve encountered so far in playing around with these tools.

I’ve tried messing with Figma Make and Lovable and some of the other usual suspects targeted at designers and non-coders, and to be blunt, I find them frustrating and unsatisfying.

So my question here at the beginning of 2026 for any designers who are out there: would you be interested in taking the plunge into the world of working with an LLM to write code? I have some roughly-formed thoughts on a course or a workshop to work with designers to build some code literacy, and potentially even to build their own tools to scratch their own itches, or to work on projects that overlap with dev stuff like design systems, or even just to be able to play around and think about software design differently.

At this stage, I’m really just curious if anyone is interested in this stuff, and what you’re curious and/or motivated about?

Leave a comment and let me know!

Dear Figma Friends,

We need to talk about content.

It’s at the core of almost every digital product and experience.

Designers working in Figma have fantastic tools to create mockups and prototypes; explore visual, interface, and interaction design ideas; and structure their design intentions in ways that can help developers carry proposals into production.

Content, however, is a second-class citizen in the world of Figma. Where are the tools for inspecting content changes over time? For marking screens as “content-ready”?

I’m concerned that as bad as the relationship between Figma designs and content have been, the addition of LLM tools to fill in realistic-seeming content is going to make this situation worse for a lot of teams.

How will anyone being handed a design to review be able to tell if the content has actually been considered, planned, aligned to the voice/tone/guidance for product or marketing, or if it’s been conveniently mocked up using a generation prompt or drag and drop infill?

Making things look like the real thing has drawbacks. It makes things look “done” and “ready” even when they are not.

I know I know—no tool is ever going to replace the need for people to communicate and have conversations with one another. There are more engineers than content folks, and most teams don’t have specialized content designers.

But your vision is to “make design accessible to everyone.” And you believe “the best way to design is together.”

Your tools need a first-class content experience. More importantly, the industry counts on you as its leading design tool provider to set a tone in what you build into your product for what digital products in general should prioritize.

I would love to see Figma take content as seriously as the rest of us, and start showing us a vision for how Figma can help content and design work together.

Your friendly neighborhood design teacher,
Nevan

Design starts earlier than you think.

Design doesn’t start with a spec. It doesn’t even start with a problem or a prompt or a need.

Design starts at the very beginning. All of the relationship-building, stakeholder-wrangling, process-defining, responsibilities-mapping, and goal-setting work is not just stuff you have to get out of the way in order to start. These are all crucial initial stages of the design process, with tangible impacts on how work is done, and on the end result of our efforts.

If you consider yourself a designer, of any stripe, try adding these to your mental model of the materials you have to work with: relationships, stakeholders, processes, responsibilities, and goals.

There is no one correct way these materials should be configured. There are only more and less conducive ways to configure them for more likely successful outcomes.

These materials are never 100% fixed or 100% malleable. You’ll have to assess where they default to now, where they might be improved, and how much you think they can realistically improve at any given time. Then you’ll have to plan for how you can go about nudging them in the right direction.

Getting better at this part of design will last your entire career. Be patient with yourself, and look for opportunities to practice whenever you can. Begin by welcoming them with open arms into your palette of design materials. Whether you engage with the configuration of these materials or not, you’ll have to work with them either way.

Today feels like a good time for a healthy reminder that change and progress are not synonymous. Just because something is new doesn’t mean that it’s better.

When you work in tech, it can be easy to get swept up with shiny new things, and believe that everything moves fast in an inexorable stampede toward a brighter future.

It’s worth it to check in with yourself every now and then, cast a skeptical look at what’s going on, and interrogate where your excitement comes from.

Excitement is a fun feeling, and a valid one. I’m certainly not here to yuck anyone’s yum. I get excited all the time over new font releases, even if the designs aren’t incredibly new, just because that’s my thing.

Most of the people who follow me here work in tech, so I think it’s safe to assume that we all know just how much tech companies invest in promoting and hyping their own products. I think jumping on those bandwagons can feel like a way to stand out, to stake a claim on the future, and to support growth for the tech job market. Maybe even to promote ourselves as good candidates for future work with new technologies and platforms.

But a powerful tech industry that builds “the future” without care, consideration, and healthy skepticism is not really the future we want, and a sure way to build a closed market that feeds primarily on itself.

A handful of big companies and investment firms don’t actually get to write the future for us, we do. It’s up to us to ask ourselves what kind of future we want to support, and get excited for that.