1–9 of 9 posts
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
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.
Then, pay attention to when one of those decisions turns out to really matter, and be willing to revisit it when actually needed.
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.
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, the…
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…
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.
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 anyh…
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.