Designing Without Designing
Designing Without Designing
and the new AI-Driven workflows
As a designer who has extensively experimented with AI-driven tools—both chat-based and using agents—I've noticed an interesting shift in my workflow:
I've skipped “design”!
Well, not exactly skipped “design” per se, but more skipped the phase where I iterated using a high-fidelity design tool like Figma. Instead, I started with a simple sketch and used natural language with tools like Claude or ChatGPT to generate UI code—whether through vanilla JavaScript and CSS or frameworks like Tailwind or DaisyUI. This process was compelling, fast, sometimes frustrating, but mostly led to tangible results. I managed to release a few simple apps using this approach, like NodePad, BusDash, and Presence.
I later discovered that this approach isn't unique to me. Other designers, such as Meng To of Design+Code, have reported similar experiences while developing complex applications like DreamCut.ai.
This is not the only trend—there's a growing experimentation within the Cursor or Replit users around finding the best ways to design and build, almost at the same time.
What does this mean?
It’s simply a new way of working, and I'm feeling conflicted about it, because it’s a bit more than being able to code. Here are some personal observations:
Design Still Matters, but in a Different Way
The important thing to highlight is that the design phase in software development wasn’t necessarily tied to Figma or any particular tool. Something changed in the last few years, where Figma became the go-to place for visual exploration and building systems that developers could easily use. Think of design as planning—or more appropriately, architecture: it involves clear understanding of constraints then visualising, imagining, and dreaming, providing something concrete to start with.
Increasingly, there is a reliance on tools like Vercel’s V0, a prompt-based UI code builder, as a starting point for design and prototyping.
Another important point I think is research. In theory, research synthesis may be easier now with LLMs, but we might have to think about research differently as well, beyond just uploading a bunch of documents and chatting with them.
Design research is a continuous process that, from my personal experience, has often been an afterthought in smaller companies, not to mention evaluation and usability testing.
There’s a major difference between small and big teams
This is all new, and we're yet to see how large companies (with 100+ design and development teams) will incorporate these workflows into their processes. A good argument is that these numbers were inflated to begin with. But while these approaches seem to work well with solo developers or small teams, there will be complications. Acceleration has a price. Think of code reviews, hand-off, or inspections when things go wrong. What will happen to the design systems that were built and how will they be maintained? The rise of a “design engineer” is probably a response to the question, “What do we need Figma for anymore?”.
You still need to know what you’re doing
Since we’re dealing with code-based outputs, a baseline knowledge of the framework we’re working with is essential. This approach will significantly speed things up, especially during customisation. Designer or developer agency are major topics worth exploring, but these tools also shift a lot of control away from development teams, even though they can accelerate processes.
One of the most haunting observations I've had is that these tools tend to foster a sense of laziness or complacency. When interacting through natural language, it's easy to get the impression that the model or agent will intuitively understand what I need. In reality, as the complexity of my concept increases, it often doesn't. This means that sometimes even simple or obvious requests don’t result an expected outcome. The time I think I’m saving is often spent adjusting prompts, rephrasing instructions, or reverting to an earlier version where things worked better. In a way, this new mode of interaction shapes my behaviour, requiring a period of adjustment.
In this context, design becomes more about careful planning and having a clear understanding of what I need assistance with. It’s practical orchestration.
This journey into skipping parts of an established design process is still evolving, and I certainly don't have all the answers. This is not to say that what we had as designers before was necessarily better; it was also, in a way, an adaptation to the rise and popularity of design software (think Photoshop → Sketch → Axure → and now Figma). What I do know is that we're at the beginning of a major transformation in how we think about and approach design for software.