How developers and tech founders can turn their ideas into UI design
simonmccade.com
simonmccade.com
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!
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)?
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.
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.)
This is a bit ironic as the advertised tools provide templates which make all apps look and behave more or less the same.
As an engineer-founder trying to build a first prototype app, i've been conscious about not diving into building too fast, trying to get some of the design right upfront. This has meant doing user-interviews to understand people's problems in the area i'm working on, and doing some paper prototypes.
I was debating what is the best form to get the next round of feedback: wireframe the whole flow in balsamiq, or a bare-bones working prototype with ReactNative. For the former, i'd have to learn the tool. The latter i somewhat know.
-Talking to users
-Interviewing users
-Doing user testing
-Making sacrificial prototypes
This is a great way to develop a product that people don't need, with no way of knowing how good the UX actually is. I've worked like this before, and it really does produce suboptimal results. You really shouldn't even be making wireframes before validating assumptions and needs first.
NNgroup has a lot of writing on trying to shortcut UX:
https://web.archive.org/web/20190329103120/https://www.simon...
Anyways, it still doesn't make sense to talk to users once and then just go crazy with UI design. A lot of user research requires having prototypes (digital ones too). It's a back and forth, rather than a waterfall of talk to users, think, whip up some design.
I forget who said it—maybe it was the Eameses, maybe it was the Modernist movement in general—but the best UI is invisible and stays out of the users’ way while enabling them to accomplish what they want. I believe this to be true. The best way to do this usually is to provide a familiar, non novel UI.
So yeah, you need to make sure your flows make sense, etc, but if you’re having “eureka” moments when developing UI, maybe your users will have to do the same thing just to use it.
[0]: https://www.pony.gg
I believe this is true in most cases. Don't reimplement controls, unless you really know what you are doing, because you're probably going to do it wrong and break usability or accessibility or generally annoy people.
As a developer who has done this for many years, this is marginally helpful. I'm glad to know it, but I'll tell you that on my side projects I will not be nearly this extensive until later on, and likely pay for a designer for a few hundred before doing all this myself.
I would whip out my credit card so fast for that.
But still release your CLI version. Ordering food or managing stocks on the command line is fantastic!