If you're building a product as a solo dev or part of a small team, you've probably struggled with design.
You open Figma. You pick a font. Then a color palette. Then you browse some Dribbble shots. Then you go down a dark hole of animations, blur effects, neumorphism... and suddenly you've spent three hours tweaking gradients but your product still doesn't feel right.
Here's the problem: you're thinking about design backwards.
Design isn't about how your app looks. It's about what it lets people do and how easily they can do it.
That's why I follow a dead simple rule:
Design functionality first. Make it beautiful later.
Design Functionality First. Make It Beautiful Later
Design isn't about how something looks it's about what it lets people do.
When you focus on visual details too early, you're decorating an idea that hasn't even proven itself yet. But when you focus on core functionality what needs to be on the screen, how users move through it, and what actions they take the right interface starts to emerge naturally.
This mindset helped me build UserJot, a feedback tool for SaaS teams. I built the whole product solo and I didn't start with a fancy UI. I started with a clear, minimal layout and just made sure the feedback flow worked. It wasn't flashy, but it worked. And that's what mattered.
Most Devs Start With the Wrong Layer
Too many devs start design by picking fonts, colors, and spacing scales before they even know what the app does.
That's like choosing decorations for a house that hasn't been built yet.
Instead, start from the inside:
- What's the main action the user needs to take?
- What's the simplest flow to support that?
- What components are absolutely necessary?
Build that first. Design the layout and the interaction. Then (only then) think about making it pretty.
Think in Layers Like You Write Code
Good design is built like a frontend stack:
- Structure (layout and flow)
- Content (real copy, labels, buttons)
- Spacing and hierarchy (visual clarity)
- Interactivity (transitions, feedback)
- Visual styling (color, fonts, illustrations)
Each layer builds on the one before it. If your layout and spacing are rock solid, even a grayscale UI with a system font can feel great.
If you try to start from the last layer styling without the foundation, it almost always falls apart.
Grayscale First: Focus on the Foundation
This is why I recommend designing your first version in black and white.
Grayscale forces you to:
- Nail down the layout
- Use contrast and spacing properly
- Create a clear visual hierarchy
It's hard to hide a bad UI in grayscale. Which is exactly the point.
If it works in black and white, it'll only get better with color.
If it doesn't work in black and white color won't save it.
Most of the Value Comes From the Core Flow
Here's the big insight:
The part of your product that users care about most is the core flow the thing it helps them do.
That's where 90% of the value lives. That's what makes or breaks whether someone sticks around or churns.
Adding aesthetic flourishes like shadows, rounded corners, and animations can enhance that experience but they can't replace it.
They're the last 10% the part that makes something feel nicer, not the part that makes it work.
And a lot of the time, your product is better off without them if they slow you down or add complexity.
Bad Visuals Are Worse Than No Visuals
Here's a hard truth: A clunky animation or a confusing hover effect can make your product feel worse.
Some examples:
- A janky slide-in menu that drops frames
- A blurry shadow that makes buttons unreadable
- A soft color palette that kills contrast
Minimal and functional > flashy and broken. Every time.
If you can't get an effect right, just leave it out.
Clarity is better than "style."
Common Design Mistakes Devs Make
- Picking a color scheme before sketching a flow
- Choosing fonts before writing real copy
- Adding animations too early
- Designing UI elements that don't map to any real user need
These are all distractions. You're solving problems that don't exist yet.
A Simple Workflow for Designing Interfaces (That Don't Suck)
Here's how to approach your next UI project:
- Start in grayscale wireframe the layout
- Use real copy (no lorem ipsum)
- Align spacing, font sizes, and actions
- Build the core product flow
- Validate it with real usage
- Then and only then add colors, icons, transitions, etc.
That's exactly what I did with UserJot.
I kept things stupidly simple at first. Focused on feedback, clarity, and speed. Only after it was working and people were using it did I start layering in visual improvements.
And I didn't have to undo a bunch of bad design decisions because the foundation was already solid.
Final Thought: You Don't Need Fancy
Most people think design means decoration.
But good design especially for early products is about clarity and functionality.
Start minimal.
Build the layers in the right order.
Make it usable before you make it "beautiful."
Get the layout right.
Get the flow right.
Then ship it.
That's what good design actually looks like.
Top comments (13)
Good post.
However I would have loved to see some Screenshots of the single stages of your journey. That would have spiced it up.
Insane how much time I used to waste messing with colors before even knowing if my layout worked-you think most devs even realize they're stuck on the decoration step?
I think we all fall for it.
I thought the MVP needs to be flashy to impress the would-be sponsor...
Some of my projects never got finished.
tbh i always mess this up and start picking colors before even knowing what i want the app to do - you ever find yourself accidentally over-designing stuff before it's even usable
Working in grayscale first totally changed how fast I ship new features. Love this mindset shift.
That's the reason for like old win apps in Gui were literally gray form boxes by default and then Devs used to add buttons and functionality, see the old 90s era Web 1.0 sites also look gray by default. So yeah this going back to basics of GUI design really helps.
Pretty much what I wish someone told me ages ago, love this so much
This really resonate with me. I love designing and when it gets to make the website functional, I get stuck with an overdesigned web that doesn't do anything. Thanks for sharing this!
Good points. The book "Refactoring UI" by the creators of Tailwind has these same points. Great reference tool.
I start with DB design 1st, that dictates the pages and the layout, then I go from there.
If I'm wrong I deeply apologize but it looks like you used Radix / Shadcn. So talking about design when your app looks like any other app made with default Shadcn components... I don't know, there's nothing original nor nice there. Just a nth boring lookalike website.
Creativity is limitless, I don't understand why you guys keep using those, they kill creativity and create websites that all look the same. You're too lazy to style something right? Too lazy to create components that are accessible? Then please don't talk about design.
And congrats for creating Trello, it looks nice nonetheless.
Hey, no offense taken. I’m actually not using Shadcn in this project.
The blog post isn’t about promoting a specific design system or framework. It’s about the approach: starting with functionality and clarity first, then layering on visual design once the experience works. Whether you're using a UI kit, writing everything from scratch, or just sketching on paper, that mindset still applies.
As for frameworks and component libraries, they exist to help people move faster and adopt shared accessibility and UX standards. There's nothing wrong with using them. It's what you do with them that counts.
That said, if you’ve built something you feel does this better or differently, I’d genuinely love to see it.
I think that was his point.
We are not designers, we are devs. Truly speaking we really dnt know how to choose fonts. Hence it takes forever to find a suitable font...
He can now call you and pay you to design a unique web App. On something that is already functional - not on Figma.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.