Ask HN: How do you draw the line between bikeshedding and design?

My ex-cofounder and I sat down at a table and hashed everything out at the interface level--what HTTP requests to make, how messages were handled, etc. We didn't second-guess each others' implementations, because as long as the interface was stuck to things were fine. That saved us a lot of bikeshedding.

I would say the line is generally "Are we both right given the current business needs?". If the answer is yes, then you're bikeshedding, and should just flip a coin and move on.

Ask "how much does the customer care"? If the answer is "not much", waste very little time deciding what to do.

Then, pay attention to when one of those decisions turns out to really matter, and be willing to revisit it when actually needed.

When are you getting feedback on the design? Real design is about adapting to the users' needs, not the founders. You do need to put something out there to get useful feedback, but you should spend the bulk of time implementing things that the users would not have thought of by themselves.

As a general rule of thumb for the startup phase, if people are arguing about it it's not worth arguing about. Pick one and show it to users, and usually the users will resolve the question for you. The design decisions that matter are the ones that everybody can look at and say "This looks off", eg. including adequate margins and whitespace, picking a sane color palette, making information easily skimmable, not forcing the user to perform extra clicks or interactions. When they fail, it's usually because the founders never thought about them in the first place rather than because they thought of them and picked the wrong one of two equally-viable alternatives.

Two people, two months, zero built?

Bikeshedding is piping up on trivial issues to draw attention to yourself in a group. There's only two of you? You should have enough mutual trust such that nobody feels the need to show off.

I'd suggest putting a stop to any more design meetings. Get a prototype working, iterate from there. What needs to happen will become apparent. It's all smoke and mirrors in the beginning anyhow. Take a page from the Italians and their fancy A-GEE-LAY methods.

depends on your project and its complexity.

perhaps one way to improve the approach is instead of thinking about your design and if it's perfect, encourage thought along the lines of "how do we build this so we can change how it works later?"

things always change. there is no perfect spec or style on day 1. the best code is always written during refactoring, so design to make that part easy and while your idea is new and not launched optimize to get it launched.