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.
"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.
"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.)
As a creative Director at UI/UX design firm http://fairpixels.pro - I’d like to highly recommend founders to build their first version on intuition. The best way to design a solid UI & UX is not from scratch, rather from a foundational prototype or v1 that’s being used by actual users. We found that the best products we helped design (where the design significantly helped the business move forward) was where the founders had a working prototype and user data to form the basis of crafting a simpler and more user friendly product.
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.
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:
The author mentions it in the first paragraph, just chooses to focus the article on the design part:
"At this stage, I'm going to assume you've conducted some user research or at the very least, spoken to potential customers to test your assumptions. That way you'll be much better positioned to turn your ideas into actual design."
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.
The article doesn’t mention that as a startup it makes sense to minimize novel, homegrown UI as much as possible. Unless, of course, that’s central to your product or is the product. In Pony [0]—an email service that delivers once a day—for example, I tried making the UI as familiar as possible, perhaps at risk of not making it exciting enough.
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.
> it makes sense to minimize novel, homegrown UI as much as possible
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.
It seems like the most upvoted comments are coming from designers -- which feels problematic. It seems like the author has done a great job to capture a UX/UI designer's flow, but that doesn't mean it translates well for developers.
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 liked their link to PageFlows, but I was wondering if an enterprise version exists. Is there something that focuses more heavily on the data side? The creation, the updating, the displaying, the analysis, the graphs, etc...
Good article, hits home my experience. But I’d rather have a seasoned UX designer to lead and sketch the flows rather than some one new to come up with a Frankenstein type of app.
Or, as an extension of this, implement your core logic as a library that you can call from your {iOS, Android, etc.} app. If you're only targeting one platform, this makes it easy for you to add another one in the future.
I second this approach. Building a prototype (or core features) of an app as a CLI is an excellent way to limit scope to the essentials first, and keep separation of concerns. It allows for "remote control" of the app, through the command line (great for dev/testing) or over the network to a web GUI or mobile app, all of them interfacing with the same API.
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!