Part 3 of a 3-part series. In Part 1, I got owned by a scrollbar. In Part 2, we redesigned Logfire's sidebar navigation and I talked about what design actually looks like on a small team.
What are we even doing here?
Not in an existential crisis way. In a genuine, practical, "are we using the right tools for the job" way. Working on the sidebar redesign, watching engineers pitch design PRs, shipping things that were directionally correct but far from done, all of this has had me thinking about bigger questions. How should design process even work when the work itself is changing this fast?
A lot of this started over brunch with my husband Andy, our neighbor Dana, and my cat Rios, talking about why design process feels so broken.
Don't trust the process (but know why it exists)
We touched on this talk by Jenny Wen called "Don't Trust the Process". If you haven't seen it, it's worth twenty minutes. She's a design lead at Anthropic, previously a director at Figma where she was the first designer on FigJam. She's smart, she's experienced, and the core of what she's saying is right: following the rigid design process we've all been taught (personas, journey maps, problem statements, wireframes, testing, rinse, repeat) doesn't produce great work. The best things she's seen come from teams that operated on intuition, skipped steps, started from solutions instead of problems.
I liked her talk, and I'm kind of annoyed about it.
It's the narcissism of small differences. In 2018 I gave a talk called "Burn the Concept Mocks" (YouTube, slides) making a similar argument: design artifacts are proxies for conversations, not substitutes for the real thing. Lower fidelity opens conversations, high fidelity shuts them down. At every stage, ask yourself what's the cheapest artifact that helps you have the conversation you need to have right now.
Jenny and I agree on a lot. Where we part is the diagnosis. She credits AI as the catalyst, I don't buy it. It felt broken to me back in 2018 when I was talking about frustrations from 2012. I can remember having an argument with a professor in my Masters degree (multimedia, lol) about her dogmatic insistence about following the SDLC process, and that being in direct conflict with my day-to-day experience inside a software team. AI is an amplifier of existing patterns, the cracks are more visible at speed.
So the question I want to ask isn't "what broke the process?" It's: "why does the process survive when the results don't?"
Sympathy versus spreadsheets
Design decisions sit on a spectrum. On one end: research. Data. User testing. A/B results. Evidence you can point to. On the other end: instinct. Gut. Taste. The thing you can't explain but know is right. Most people in this industry plant themselves at one end and spend their careers defending the position.
The best products I've worked on are an interplay along the spectrum. Great ideas from the founder or the team, and then contact with the market that crystallised some of those ideas and let others drop away. Tension and play between the two ends. Often landing closer to the instinct side than anyone would admit in a meeting.
Jenny champions intuition in her talk. Good. She calls it "a dirty word for designers." She's right about that. But she doesn't go far enough into why it's a dirty word. Why does intuition make organisations so uncomfortable?
Because it feels like magic. It's hard to reproduce. It's not fungible. It's organic. Sometimes it's wrong. Sometimes it's right and wrong at the same time. You can't hand it off when someone leaves the company. You can't A/B test it. You can't put it in a slide deck.
We even invented a term for it, heuristic evaluation, to make decision-makers less uncomfortable with something that felt too much like sorcery. When a senior designer looks at a screen and goes "yes, yes, no, no, DEFINITELY no, maybe, no, yes," that's not gatekeeping. That's not performance. It's deep knowledge expressing itself at speed. Watch Dieter Rams walk through a room pointing at things he doesn't like. The master just knows, from decades of engagement with the material.
Organisations default to the research end of the spectrum because research is legible. It can be written down, defended in a meeting, presented to a board. Intuition can't. And so intuition gets squeezed out. Not because it doesn't work. Because it can't be made safe for committees. People want the future to be knowable. They want a playbook that guarantees an outcome if followed correctly. That's understandable. It's also the thing that keeps us stuck.
Exhaust, not propulsion
The process is the chemtrail behind the jet. Exhaust, not propulsion.
When a team ships something great and someone asks "what was your process?", what they're describing after the fact is a reconstruction, not a recipe. Survivorship bias meets Methodological Attribution bias.
The successful team used Agile, therefore Agile works. The successful team did user research, therefore user research was the key ingredient. Never mind the ten teams that followed identical processes and shipped garbage. Never mind that what actually mattered was three specific people in a room who understood the problem and trusted each other enough to move fast.
This is Goodhart's Law playing out in design organisations every day. The process becomes the target, and the instant it does, it stops measuring anything useful. You see it with the Iron Law of Institutions too. As organisations grow, people optimise for power within the org rather than the org's survival.
And then there's enshittification. Agile is the textbook case: a reaction against bureaucracy that became the bureaucracy. Things start out strong, useful, powerful—a good idea about how to work—and then get commodified and codified until they've become a rod for our own backs instead of a tool in our toolkit.
I saw this up-close in a med tech startup that was replacing radio paging in hospitals. I spent a night shadowing a nurse through her shift. She had about twenty ambulatory patients. Each one had an eight-page clinical observation form to be filled out hourly. Do the maths, it's physically impossible. It would also require waking recovering patients to take blood pressure and temperature readings.
At some point process becomes a cudgel, it doesn't protect anyone. It just provides a paper trail for when things go wrong. We should be protecting our thinking, our time, and our attention. Instead we build systems that consume all three and call it rigour.
The prompt cargo cult
The AI parallel is almost too on the nose.
Developers love to feather their nests. Always have. We write custom bash aliases, we argue about IDEs, we have opinions about tabs versus spaces that border on theological. Gary Tan of Y Combinator recently published G-Stack, a repo of his Claude markdown files. My colleague Anthony quipped: "20 minutes into using gstack and I'm being prompted to apply to Y Combinator." Someone on Twitter recorded a very entertaining takedown: "Gary looked at his prompts and he saw greatness."
Would it be too mean-spirited to say that our obsession with our Claude setup is fundamentally no different from my dad bumping up the text size on his phone now that he's turning 80? Hear me out - they're both about getting comfortable, feeling like the technology is yours. My prediction is that we're only a few cultural moments away from seeing these as analogous behaviours along the same spectrum.
What interests me more is the work Andrej Karpathy shared recently on building internal knowledge bases. The approach operates at a different layer: engineering patterns that live above any specific agentic framework or coding system. Developers over-index on setup and ecosystem preferences the same way designers over-index on design process and design tools. The impulse is identical: if I get the setup right, the work will follow. It won't. The work follows from the problem, the people, and the willingness to stay uncomfortable long enough to find something good.
But despite the absurdity and the cargo culting, moments like this are good for one thing: permission. Permission to shake it off. Permission to ask questions that felt too large before.
The arc of software is long. Could it bend towards you?
We ship one interface to every user on earth and call it "consistency." But the defaults encode a specific worldview: left-to-right, English-first, mouse-and-keyboard, neurotypical WEIRD human sitting at a desk in the US or the EU. That monoculture gets exported globally as if it's universal. It's benign paternalism, and mostly nobody means harm, but the people it doesn't fit are expected to adapt to the software rather than the other way around.
TARS from Interstellar (2014). No screen, no interface chrome. Just a slab of metal that listens, responds, and gets out of the way. The human sets the pace.
What if the software adapted instead?
What if algorithm design is no longer the purview of computer scientists, but a way of encoding the intuitions and observations that everybody has every day?
An example: in my work with Logfire, we're drowning in user feedback. Feature requests buried in Slack threads, bug reports on GitHub, questions on Twitter, insights from sales calls. Recency bias rules because there's too much for any one person's head. Strategic gold lost in the noise.
I want a system that ingests all of it, clusters it, and lets me see patterns across hundreds of data points. That part exists, lots of tools do it. What I can't find is a tool that maintains source traceability: not just "users want better alerts" but the specific Slack thread, the specific message, the original words. Every tool I've looked at aggregates themes and loses the source material. I want to weight feedback by our own sense of which users matter most to the business. I want the conceptual relationships to be a graph, not a tree, not to fight the existing hierarchies. What I want most: software that helps me express, formalise, and include my opinions rather than enforcing its opinions on me.
The CSS cascade, the system I spent Part 1 of this series debugging, was originally designed with user personalisation in mind. The user was supposed to have their own stylesheet. The dream of software that adapts to the person using it was always there, baked into the earliest specifications. The technology wasn't ready.
Maybe it is now. And maybe that means rethinking whether software is even a destination anymore. People come to your website, log in, and use your app: is that still the right frame? Folks want to work where they're already working. In their editor, their terminal, whatever chat interface they have open. What if we delivered our core value at the coalface? Graph components people can embed. Notebook-like code cells they can run. Snippets of UI that surface inside Codex, Claude Code, whatever comes next. I suspect this is one of the things that will distinguish companies that survive the SaaSpocalypse from those that don't. Your application isn't a place. It's a set of capabilities that can be accessed across every surface where your users do their thinking.
An invitation
Hunter S. Thompson, in Fear and Loathing in Las Vegas:
And that, I think, was the handle—that sense of inevitable victory over the forces of Old and Evil. Not in any mean or military sense; we didn't need that. Our energy would simply prevail. There was no point in fighting—on our side or theirs. We had all the momentum; we were riding the crest of a high and beautiful wave. So now, less than five years later, you can go up on a steep hill in Las Vegas and look West, and with the right kind of eyes you can almost see the high-water mark—that place where the wave finally broke and rolled back.
This is not an optimistic passage. It's about self-delusion. The counterculture believed their energy would simply prevail. It didn't. The high-water mark is a monument to things that were promised but never came to fruition. Thompson could only see it clearly in retrospect, after the wave broke.
We are in a frothy high. The promises are everywhere and most of them will tumble into the surf when the wave crests. That's just how the hype cycle works. I'd encourage you to look for both things at once: which promises are comforting fictions, and which ones are real. The chance to rethink what software looks like, who it's for, how it gets built, what "done" even means. That chance is real. So is the froth. So if you're working on software in any capacity, I want to ask you some questions. Real ones.
- What would software look like if it bent toward you instead of the other way around? If it learned your priorities, your judgment, your way of thinking? If you could tune the weights, inject your opinions, teach it what matters to you?
- What if we stopped designing for everyone, a move that always means designing for no one in particular, and started designing for each?
- What would your work look like if you gave yourself permission to throw out some of the rules you've been holding onto? To think outside the box (model)?
You don't have to be young and fearless or old and expert to do this. You need the right mentality: treat your work as experiment, hold your ideas strongly enough to polish them, and be willing to see your hypothesis proved wrong. A willingness to kill your babies has always been one of the hallmarks of great design. It's not unique to an age group or a generation, it's a way of thinking and working.
I'm frustrated by people who get within sniffing distance of an interesting critique and fail to stick the landing. I'm aware I might be doing exactly that here. But I'd rather leave this open and pointed at the future than tie it up with a false conclusion.
The wave is still building. Look at it with the right kind of eyes.
Laura Summers is head of design at Pydantic. She has opinions about CSS, design process, and the future of software. She lives in Berlin with her husband, two cats, and a mass-market AI that still can't see scrollbars.
