Comment by tannerc | Hacker News Reader

Comment by tannerc | Hacker News Reader

Parent Full thread

This is a surprisingly good article. As a product designer of 10+ years (having worked at Facebook, Atlassian, and now Lyft), I would recommend anyone outside of the design field to read this.

It provides a much crisper picture of what modern designers workflow looks like than other resources.

Typically when these types of guidance are shared they're littered with more harmful advice than good. For example: "Look at what other apps are doing and copy it!" Except what another product is doing may not work for your product. The design of a final product isn't just the result of visual decisions, it's also driven by things like: business objectives, budgets, team size, time constraints, tech capabilities, target market size and demographics, etc.

So to have the article call attention to things like Dribbble being home to designs that are primarily "conceptual as opposed to the finished product when it comes to real applications" was refreshing.

Great read!

"Look at what other apps are doing and copy it!" doesn't work but "Look at what other apps are doing, understand it and see what you can copy or adapt" works really well.

Yes!

"Look at what other apps are doing and copy it!" Agree that most of the time this is horrible direction, but I've also experienced the opposite: "We need something like X, but do Y." Where Y is reinventing the wheel for what should be a standard interface element (ie it's the best implementation on the market and ours would only be worse/confusing if we didn't try to do the same).

Utilizing existing patterns can be good for sure, especially if they're platform standards from the likes of Material or Apple's HIG.

But what makes leveraging those existing designs so effective isn't simply seeing and copying them (that'll do in a pinch, but ultimately may lead to misuse).

What makes standard patterns from platform sources so effective is that you don't have to wonder whether they'll meet your needs or not: they're already standard, customers will understand them, and if you're so inclined you can look behind them to better understand their rationale via material.io for example.

But, again, without understanding what you're copying you're likely to run into small problems. Such as: when should you use a modal dialog over a sheet? When should a button be hollow vs. filled? When to use radio buttons vs. checkboxes? Should a transition animate from the bottom, left, or right of the screen (and how do those each help the user orient themselves in the experience)?

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.

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.)

> "Look at what other apps are doing and copy it!"

This is a bit ironic as the advertised tools provide templates which make all apps look and behave more or less the same.

You might find this article helpful: https://uxdesign.cc/ever-wonder-why-the-most-popular-apps-ar...

Reply on news.ycombinator.com