Design tips for startups
Ben Shumaker
March 6, 2025
We worked on our first startup idea for over a year and completely failed. We never got real users. So a few months ago, we decided to pivot to Vigilant. When we did that, we had to build a new product from scratch. Restarting was humbling and depressing.
But on the bright side, it also made me realize how much better I am at design. At the same stage of development, our last product was garbage compared to our new one. Back when we started, I was clueless. I didn't have any experience designing interfaces. But now I've spent thousands of hours in Figma and React.
I wrote this to share what I learned during almost two years of trial and error. I divided it into three categories.
Big ideas - my top three pieces of advice
Lessons - helpful ideas to keep in mind
Practical tips - concrete advice on execution
Big ideas
Do multiple fast repetitions
When I started, I had no idea how long to spend designing a feature. An hour? A day? A week? My instinct was to design heavily. It seemed more efficient than experimenting during the development process. But in practice, it feels like there are huge diminishing returns on design time. No matter how long I spend, I always make mistakes.
I forget crucial functionality
I forget to handle corner-cases
The design confuses users in unexpected ways
Even if I spend a week on a design, my accuracy is only slightly better. It feels like mistakes are inevitable.
I also discovered that its much easier to improve a design once you build it. People tell you what's wrong. There's no guesswork. It's awesome. And real usage always reveals problems I never considered. Once I saw that pattern, I naturally shaped my whole design process around fast feedback and iterations, rather than simulating everything in my head.
So when we make new features, we often ship multiple versions back-to-back. It feels strange at first. "I just made that, why would I do it again?" But it works. You only need a few minutes of feedback to plan dramatic improvements. In my experience, design quality is strongly correlated with how many iterations you ship. Shipping a hasty version plus two updates in a week always outperforms shipping one high-effort version. And if you're afraid of shipping unfinished work, you can use feature flags.
Build with haste. Don't be afraid to rebuild. More reps = more good.
Design with clear goals
Sometimes I get stuck while designing. I might hate all my ideas, struggle to choose between versions, or simply not know where to start.
Eventually I realized that almost every time I feel stuck, it's because I don't have a clear goal. I never feel stuck when my task is something like: "Design a way to quickly filter timestamps on the logs screen using two clicks." Those tasks are easy because it's always obvious if I've achieved the goal or not.
But it feels impossible when my task is something like "improve the log screen." What am I supposed to do? How do I know when I've succeeded? I've wasted so much time banging my head against a wall without a clear goal. The best way to break through the wall is to ask myself, "What am I trying to do?"
Designing with a clear goal is dramatically easier.
Break features into small pieces
"Possibly the most common error of a smart engineer is to optimize something that shouldn't exist"
— Rocket Man
Here's a painful memory that's burned in my mind. Before we pivoted, I made a big design to let users create scrolling animations on their website.

It took a whole week. I had to:
Plan how the feature would work
Define the data structure
Figure out how to generate the css
Design the interface, including panels, popups, and a timeline with complex interactions
The design was beautiful. But we had important things to ship immediately after I finished the design, so we put it on the backlog. Weeks went by. We kept doing more important things. It kept sitting in the backlog... Eventually we realized it was doomed. Even if we made it, nobody was going to use it. Nobody was finishing a landing page, why would they need animations? In the end, we deleted my work.
That's just one severe case. I've had a dozen similar experiences. I learned to decrease the risk by breaking features apart as much as possible. Small updates are great because you ship faster, your goals are clearer, and you waste less time if you end up scrapping it. There's basically no reason to do a big update when you can do three small ones instead.
The real challenge is recognizing when you're about to build something unnecessary. Almost every time we work on something stupid, it starts like this:
"We're shipping this feature, which means we need to do X, Y, Z and W"
— Me
But I'm usually wrong. We probably don't need all those things. And even if we do, we can probably break it into separate updates. Most features can have a tiny first draft. Surprisingly often, when I break features into 'separate updates,' we never end up doing the rest of the updates. I've noticed that unimportant features typically sneak into our product by piggybacking on essential ones, like stowaways on a ship.
If you can break a feature into smaller pieces, you probably should.
Lessons
Here are some shorter ideas to keep in the back of your mind.
Adapt around instincts
Anytime someone assumes your product works a certain way, but they're wrong, pay attention. Most people have similar instincts. It's tempting to assume you need to explain the product better. But the best solution is usually to change the product so their instinct is correct.
Get inspiration from great products
I used to get most of my inspiration from similar products in our market. But recently, I've had more success looking at objectively great products, rather than similar products. It's usually easier to adapt a great design to your needs than it is to improve a similar design to be great. Probably because great design is hard.
I like getting inspiration from Notion, Linear, Vercel, Stripe, Figma, Google, and Airtable.
Minimize clicks
A simple and effective way to evaluate a design is to count clicks. If you have to click a lot, it's bad. When you optimize clicks, you start seeing free wins like removing submit buttons, swapping dropdowns for toggles, and combining multiple steps into one.
Everyone uses defaults
I first learned about this when I read Nudge. The vast majority of people use default settings. If your app starts dark mode, most people will use dark mode. If a collapsible sidebar starts open, most people will leave it open. Be careful with your default settings, because most people won't change them.
Nobody reads
Most people don't read instructions. And when they do, they jump around and read fragments. Nobody reads every word in your docs. So what can you do about it? Try to design a product that doesn't need explaining. But short of that, assume everyone is impatient and use short sentences.
Don't clutter the hot path
You clutter your UI when you write full sentences to explain features. But explanations also help new users who are unfamiliar with your features. My guideline is that if a feature is viewed often and used frequently, don't explain it in the UI. If a feature is hardly ever used, explain it in the UI.
Editors like Figma, Cursor, and Notion have almost no explanations on the surface. It's all hidden in tooltips, help menus, and documentation.
Settings pages are cold paths. You can afford full sentence descriptions because they're rarely viewed.
Administration products for payroll, taxes, or insurance can afford lots of explanations because you don't log in often. The whole product is on the cold path.
Practical tips
You don't need many colors. Color theory is for painters, not UI designers. Almost every app only uses one or two colors, along with 8 shades of black, white, and gray.
Avoid colored surfaces. Most large surfaces should be neutral colors. Even soft colors seem pretty aggressive on a large background.
Use lots of padding. Cramped interfaces look amateur. I recommend the approach where you start with too much padding, then remove it.
Use small text. Professional interfaces typically use small font sizes. Aside from headers and landing pages, most UI text ranges from 11-16px. Start small and increase size only when necessary.
Limit text styles. Don't use a wide range of fonts, weights, sizes, and colors in your text. It looks disorganized. Only add a new font style when you have a good reason.
Don't use wide sentences. It's hard to read sentences that are +1000px wide. Use max widths. The optimal width is thinner than most desktops.
Don't use all the screen width. It doesn't look good. Only do it if you need the space. Design-focused companies frequently use empty horizontal padding on desktop.
Not everything needs to be a multiple of 4. This common design rule is too rigid. On small scales, 4px increments are huge. When I inspect top products, I see plenty of deviations. Just pick numbers that look good.
Start with responsiveness guidelines. For fancy assets like the ones on our landing page, solve responsiveness before doing too much work. I had to scrap a number of designs because I couldn't make them responsive. It sucked.
Conclusion
I hope this helps! I think design can be a strong differentiator if you pick the right market. The high-water mark for design increases every year, and a lot of established products feel ancient compared to new tools.
On our last startup idea, we were competing with Figma and Framer; two of the best designed companies in the world. It was brutal. But now we're competing with complex, old, and laggy products. And so far, it feels like modern design is all we need to get a lot of people interested.
Ben Shumaker
Share