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

[719Ben]

Hi HN,

I am currently working on a project with my co-founder. We will sit down and talk about the design decisions we want to make before we start to code anything up. We have been doing this for about 2 months now. Sometimes the chats feel like design talks and sometimes it feels like bikeshedding.

Where and how do you draw the line between application design and bikeshedding?

https://en.wikipedia.org/wiki/Parkinson%27s_law_of_triviality

[angersock]

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.

[719Ben]

I like this advice. You hit it right on the head. I am asking about programing design, not interface design. We will start to flip a coin.

[nostrademons]

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.

[719Ben]

We have yet to launch. I was talking about system design, not so much user design but I will keep this in mind as we start to get more and more into user design.

[AnimalMuppet]

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.

[a-dub]

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.

[719Ben]

I worded this incorrectly. We have quite a lot bilt. We talk about code design for each part before we build that.

[spotman]

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.