Hacker News new | ask | show | jobs
by devilshaircut 2638 days ago
I definitely agree that there is a perfect world where designs are fully researched with a battery of user tests and for large companies like Facebook, Atlassian, and Lyft this is critical to their success. Every design decision, large and small, matters when you have an audience of billions of people. Furthermore, there is no excuse not to conduct research when you have the resources to dedicate to doing design right.

That said, if you are a scrappy startup (or in the case of an article, a single founder who may not even be a designer to begin with), it is often necessary to simply do whatever it takes to deliver a product. Money, time, experience, infrastructure, personnel, etc., are all limiting factors.

If I were consulting on a project for a Fortune 500 I would tell them to leverage their resources to maximize their change of success. If I were consulting on a project for a small business or startup I would tell them to be smart and triage key pieces that represent their "special sauce" above features that feel more like known territory.

1 comments

This is (partially) why the major platforms have published their design decisions, and why we have open source libraries to leverage.

I agree generally, scrappy businesses should prioritize shipping (and validation, market fit, etc.) above almost all else at the start. But even if you're leveraging existing patterns and design elements, there's really no reason /not/ to spend a fraction of a fraction of your time to understand the differences between a checkbox and a radio button; especially when such fundamentals are already laid out for you online and your team can easily leverage them both in design comps and code.

Quality design doesn't require infinite budgets or unlimited time for research. A little effort to understand the work goes a long way!

It's the same thing with programming: copy+pasting something from SO might get you 75+% of the way to success, but relying solely on that approach without understanding the code also means you'll inevitably run into issues with things like memory management, technical debt by locking into approaches, etc. in your product sooner than later.

(fwiw I've also started several businesses myself, created my own products independently, and consulted with many startups; I haven't solely functioned in the deep pockets of silicon valley, if that's what my original comment came across as.)