For years, the design process for digital products has followed a familiar sequence: research users, create personas, map journeys, write problem statements, brainstorm solutions, wireframe, test, iterate. It's been taught in schools, codified in methodologies like Design Thinking and the Google Ventures Design Sprint, and treated as a mark of professional rigor. If you followed the process, you were doing good work.
The problem is - it doesn't consistently produce great work. And in the AI era, it's increasingly producing the wrong work.
I've seen this too. Teams follow the steps faithfully. They produce beautiful journey maps, well-crafted personas, and perfectly formatted problem statements. They spend days and weeks on these artifacts. And then the actual product - the thing the user touches and feels - gets a fraction of that attention. The process becomes the deliverable instead of the experience.
Jenny Wen, Design Lead at Anthropic and formerly Director of Design at Figma, made this case sharply in a recent talk at the Hatch Conference. She described watching designers fill portfolios with 80% process artifacts and one screen of the actual product at the end. Her keen observation is that the user doesn't care about your journey map. They care about whether the product makes them feel something.
This challenge is amplified with AI, where the technology changes what's possible with every model release. The traditional sequence - understand the problem, then design the solution - assumes the technology is relatively stable. But AI isn't stable. What was impossible three months ago is now a feature. You can't map the full problem space for capabilities that didn't exist when you started the project.
So what should replace the old process? Based on Jenny's principles, my own client work, and what I'm seeing in the most successful AI products, here are five principles for creating AI experiences that actually deliver user and business value.
1. Start with the solution or the technology - not the problem
This feels counterintuitive, maybe even reckless. But consider how Claude Artifacts came to life at Anthropic. A researcher built a rough prototype that rendered Claude's output as an interactive panel. No problem statement preceded it. A designer on the team saw it, recognized something was there, iterated on it, and they shipped it. It became one of the most influential AI interaction patterns of the past two years. As Jenny put it: "We didn't know it was a problem worth solving until we actually saw the solution."
This is something I apply in opportunity discovery workshops with clients. Rather than starting with journey maps, I guide teams to first understand what current AI capabilities actually are - what the models can do today in language, vision, reasoning, and tool use - and then match those capabilities to user and business problems. The technology illuminates problems you wouldn't have identified otherwise.
2. Do less - skip steps and make up new ones
Jenny described running design sprints in three days instead of five, cutting the steps that weren't producing value and spending most of the time on prototypes - because prototypes are what make people understand a concept. You could say she replaced Amazon's press release exercise with imagining tweets - how would users react on social media to this feature? - because that felt more relevant to Figma's audience.
The point isn't that her shortcuts are universal. The point is that every project demands its own process. As she put it, you don't know if you're building a bookshelf or a hot dog - so how can the same set of IKEA instructions work every time?
3. Don't trust the process - operate on intuition and conviction
This connects directly to the Have Backbone principle in Section 1. Jenny argues that intuition is not guessing - it's the ability to make sound judgments quickly because you know the domain deeply. She builds her intuition by reading user feedback constantly, attending research sessions across the entire product, and watching usage dashboards regularly. That deep familiarity lets her make design decisions without needing to research or A/B test every one.
For leaders building AI products or features, the equivalent is building your own AI intuition through hands-on use - not just reading about what's possible, but using the tools yourself, regularly, so you develop a feel for what works and what doesn't.
4. Care ruthlessly about the details
After launching FigJam, Jenny's team didn't rush to add new features. They spent years iterating on the core experience - snapping, alignment, selection borders, colors, font sizing, shape overflow behavior, toolbar interactions. This long tail of quality refinement is what turned a functional product into one people loved.
AI products especially need this attention. The difference between an AI feature that gets abandoned after one try and one that becomes part of someone's daily workflow often comes down to these details - how fast it responds, how clearly it shows its reasoning, how naturally it handles follow-up questions, how gracefully it recovers from mistakes. The fun part is that you can do all that much faster now. I completely redesigned the user flow for Castifai in a couple of days, based on feedback from early users.
5. Design to make people smile
FigJam's stamps, emotes, and Cursor chat features - some of the most beloved parts of major products - didn't come from a problem statement or a user journey. They came from a team that prototyped ideas in real code, showed up to people's meetings, and watched their reactions. The features had usability issues. But people were smiling and laughing. That signal was more valuable than any research report.
When designing AI experiences, ask: where is the moment of delight? Not every feature needs it, but the ones that make people smile are the ones that get shared, remembered, and used again.
These principles don't replace all research or strategy. They rebalance the equation - from process worship to outcome obsession, from following steps to building judgment.
For the full argument and the stories behind these principles watch Jenny Wen's talk from Hatch Conference Berlin: "Don't Trust the Process".