"It looked so simple in Figma."
[— Every developer, at least once]
After four years as a front-end developer, I've seen a pattern. It starts with a notification: 'New design ready for review.' I'd open the Figma link, and my first impression is almost always, 'Wow.' The UI is sharp, the animations are smooth, and the whole thing looks incredible. I'd get that little buzz of excitement, thinking, 'This is going to be fun to build.'
But then I'd start to navigate the prototype, and that excitement would curdle just a little. I'd stumble upon it.
What I've come to call The Hallucinated Feature™. It's a feature so wildly out of sync with the project's actual goals that it makes me question if the designer and I are even building the same application. And it's usually paired with its partner in crime, the Delusional Flow™, a user journey so optimistic it feels like it was designed for a perfect user who never makes mistakes, has a gigabit internet connection, and has already read the manual that doesn't exist.
The Hallucinated Feature
This is a feature that was clearly born in a creative brainstorming session with no pesky developers or project managers around to whisper words like "scope," "budget," or "technical feasibility."
It’s the settings page that has a full-blown, physics-based, interactive constellation map for a background. Why? Because it looks cool. It’s the "AI-powered personal assistant" for a simple note-taking app that’s supposed to be an MVP. It’s the button that, when you hover over it, triggers a micro-interaction so complex it would require its own dedicated physics engine.
These features are beautiful mirages. They look amazing in a portfolio, but they often solve a problem no user actually has, and they threaten to derail the entire project timeline.
The Delusional Flow
If the Hallucinated Feature is the "what," the Delusional Flow is the "how." It's a user flow that assumes the best-case scenario, every single time.
- The user never makes a typo in a form.
- The network connection is always instantaneous.
- The user provides a perfectly square, high-resolution profile picture.
- The user never, ever clicks the "back" button in the middle of a multi-step process.
These flows are designed in a vacuum, a perfect world where every user is a power user who has read the non-existent manual. They often completely forget about loading states, error messages, empty states, or the hundred other "unhappy paths" that make up 90% of a real-world application.
As a developer, you’re the one left to pick up the pieces. You have to ask the awkward questions: "So... what happens if the API call fails here?" or "What does this screen look like when there's no data yet?"
The Disconnect from Business and MVP
This isn't just about making a developer's life harder. It's about a fundamental disconnect from the business goals. The goal of an MVP (Minimum Viable Product) is to solve a core user problem with the least amount of effort to start learning. Hallucinated features and delusional flows are the antithesis of this.
They represent a departure from the business process, a flight of fancy that ignores the client's actual requirements and the user's most pressing needs. They are solutions in search of a problem.
A Plea for Collaboration
So, what's the solution? It's not to stifle creativity. It's to ground that creativity in reality through collaboration.
- Involve developers early. Don't just hand off a finished design. Bring a developer into the process while you're still wireframing. We can provide instant feedback on technical constraints and effort, which can help guide the design in a more practical direction.
- Design for the "unhappy path." Think about the edge cases. What happens when things go wrong? Designing these states isn't glamorous, but it's what separates a good-looking app from a good, usable app.
- Stay focused on the MVP. Let's work together to define the absolute core of what we need to build, build it well, and then iterate. The fancy constellation map can wait for V2.
This isn't a roast for the sake of it. It's a plea. We want to build the beautiful things you design. We just need them to be buildable, practical, and focused on solving real problems for real people.
A Question for Designers
And now, I want to turn the tables. I've shared my side of the story. But I know it's not that simple. So, if you're a designer reading this, I genuinely want to know:
What do you wish developers knew? What are your frustrations? Let us know.