Great products do less, but better(uxdesign.cc)
uxdesign.cc
Great products do less, but better
https://uxdesign.cc/great-products-do-less-things-but-better-5dde0ee3fc76
172 comments
My experience is that who you're selling to matters a lot. In case of B2B, enterprises usually have tons of requirements and the approach of "less features but better" will not work: there's too much enterprise "cruft" that need to be implemented (e.g. SSO, audit logs, RBAC, etc) before they will even start considering you.
> there's too much enterprise "cruft" that need to be implemented (e.g. SSO, audit logs, RBAC, etc) before they will even start considering you.
Calling SSO, audit logs and RBAC "cruft" in a business setting might not exactly inspire confidence in prospective customers.
Calling SSO, audit logs and RBAC "cruft" in a business setting might not exactly inspire confidence in prospective customers.
I think your parent poster's point is that SSO, audit logs, and RBAC aren't core product features. We could have a development team spend weeks on all of these, without implementing one feature that solves the core customer problem, that would get another business to use our product.
This was exactly my point, thanks for elaborating.
A while back I stared extracting all this cruft / boilerplate stuff into a parallel web application that complements your web app so we can avoid rewriting it and let it stably do the boring stuff while your application develops independently. I have a few details left to take care of in the coming weeks and then it will just be a rock-solid, well-tested, well-documented companion web app for everything from tiny web apps through to SaaS and Stripe Connect platforms which it supports through modules.
https://userdashboard.github.io/home
https://userdashboard.github.io/home
Based on a cursory review this looks really useful!
I'm bookmarking this for future reference, both to use it for side projects and to study.
I'm bookmarking this for future reference, both to use it for side projects and to study.
Thanks! Let me know if you need any help or have any questions. In the next couple weeks it's going to reach feature-completion with internationalization.
[deleted]
...which coincidentally is also where almost all the money is.
The average computer user doesn't buy anything. They use whatever software they need for work (which is B2B by extension) and whatever came pre-installed on their machine.
Even if you have a really simple app that's been designed to perfection and solves their exact problem, they will complain about paying more than a couple of dollars.
Maybe if you have a "the user is the product" type of business, simple and focused is really the way to go. Otherwise, beware.
The average computer user doesn't buy anything. They use whatever software they need for work (which is B2B by extension) and whatever came pre-installed on their machine.
Even if you have a really simple app that's been designed to perfection and solves their exact problem, they will complain about paying more than a couple of dollars.
Maybe if you have a "the user is the product" type of business, simple and focused is really the way to go. Otherwise, beware.
I can only underline that, before joining our current startup I was always of the impression that quality always trumps quantity, but the past four years really have shown me that in some markets it's really just about checkboxes and shipping mvps of features instead of actually pushing for the best possible ux, especially in a low price sector (5-30€/month).
I got one of my best jobs because I was able to implement a feature that was probably never used by a single customer. It was definitely a checkbox item, our main competitor offered it so we had to as well.
Could it be that a "great" product and a "commercially successful" product are not the same thing?
I work at a large employer who spends a lot on tools. I would characterize many of those tools as not being "great" for our needs. Replacing those tools is difficult because of the costs and logistics of licensing accross a large enterprise.
In my experience, businesses (and consumers) would rather buy a "good enough" solution for a complex problem than multiple "great" solutions which solve the same problem when engineered to work in conjunction with one another. Why do you think MS Office is so popular?
I work at a large employer who spends a lot on tools. I would characterize many of those tools as not being "great" for our needs. Replacing those tools is difficult because of the costs and logistics of licensing accross a large enterprise.
In my experience, businesses (and consumers) would rather buy a "good enough" solution for a complex problem than multiple "great" solutions which solve the same problem when engineered to work in conjunction with one another. Why do you think MS Office is so popular?
The problem probably wasn't that you didn't have enough features.
The problem was that your minimalist feature set didn't solve any real problems for anyone.
You must've been aiming at people with complex problems, which required complex solutions, so it's unsurprising that that you had to have a feature set to match to be actually useful.
The problem was that your minimalist feature set didn't solve any real problems for anyone.
You must've been aiming at people with complex problems, which required complex solutions, so it's unsurprising that that you had to have a feature set to match to be actually useful.
You don't need to solve problems too. You can create needs instead and they're much more stronger than problems http://minid.net/2019/07/30/on-building-products-for-necessi...
It's a good concept but needs fleshing out I think. I understand the thrust of the idea but it could also be seen as just playing word games.
What specifically is the difference between a need and a problem? What methodology might one use to search for needs? I wish this idea were a bit more developed.
What specifically is the difference between a need and a problem? What methodology might one use to search for needs? I wish this idea were a bit more developed.
Semantically are different things. A problem is a doubt and a need is driven feeling. Both things can cross in a situation but isn't apply 100% of the times. Since both need and problems can be subjective, the idea is to trigger the need instead of finding posible problems to solve. As the rule #1 say: not everyone has a problem, but you can create a need in everyone.
Does this mean it is not possible to have a "great" software product, one that does things "better", that does not also generate "real growth"?
Is it possible to have a "not great" product which neverthless generates "real growth"?
Is "real growth" the sole measure/determinant of whether a product is "great"?
Does that mean a small number of users who believe a product is "great" are "wrong" about said greatness if the product never experiences "real growth"?
Is it possible to have a "not great" product which neverthless generates "real growth"?
Is "real growth" the sole measure/determinant of whether a product is "great"?
Does that mean a small number of users who believe a product is "great" are "wrong" about said greatness if the product never experiences "real growth"?
Sure, revenue != greatness.
But a small number of users who find a product should have a minimum viable set of high quality features to be useful can also be right.
Case in point : the iPhone. it's a ipod/a (crappy compared to a laptop) web browsing device/ a (big) phone (and a camera/a flashlight/a game console...) . And it was feature packed from day one. And more or less replaced the products it embodied (sometimes a bit worse but portable and "free" once you have it in your pocket)
Other case: a computer. It's so versatile and has so many uses and features its not even funny. Gaming, accounting, word processor, paint tablet. Each worse than a dedicated hardware at the start.
Other case: a computer. It's so versatile and has so many uses and features its not even funny. Gaming, accounting, word processor, paint tablet. Each worse than a dedicated hardware at the start.
The article contains an image of a (relatively basic) calculator, asking the question: "How many of these buttons will you really push?"
Well… all of them. I may not need tan every day, but when I do, I need it to be there.
Well… all of them. I may not need tan every day, but when I do, I need it to be there.
I skimmed the article and closed it when I saw the Scientific Calculator being shown as an example of complexity. Most people would stop using it if a "UX Designer" tried to simplify it.
Not everything is a todo list app with rounded corners.
Not everything is a todo list app with rounded corners.
But there is a tension between badly implemented feature-rich solutions and well implemented special solutions and very often the specialized solution is much much better than anything else if it fits your usage.
I work with modular synthesizers and I certainly would use a well designed interface that knows it’s priorities over one that tries to make every parameter accessible and doesn’t priorize them in any way.
If all you want in a car radio is a USB charger and a volume control, a radio with just these two implemented in a deluxe variant (big knob with motor potentiometer?) would be better than say a super duper feature rich car radio that can do everything but hides it behind obscure button combinations and plastic encoders.
These complex all purpose devices of course also have their use cases. But very rarely any single user will need more than the most basic stuff.
Where it get’s dangerous, is when the general purpose device forgets to design these “90% of the time” use cases properly. So if you scientific calculator design makes it harder to do basic arithmetic, it is probably bad design. On the other hand if you leave out key scientific functionality because you want it to look sleek, it is also bad design.
Good design has to be based on real world usage and this is a very case-by-case thing. In the end we need to accept that it is hard to cover all use cases with one interface in a good way — so just make a more than one and let users switch.
I work with modular synthesizers and I certainly would use a well designed interface that knows it’s priorities over one that tries to make every parameter accessible and doesn’t priorize them in any way.
If all you want in a car radio is a USB charger and a volume control, a radio with just these two implemented in a deluxe variant (big knob with motor potentiometer?) would be better than say a super duper feature rich car radio that can do everything but hides it behind obscure button combinations and plastic encoders.
These complex all purpose devices of course also have their use cases. But very rarely any single user will need more than the most basic stuff.
Where it get’s dangerous, is when the general purpose device forgets to design these “90% of the time” use cases properly. So if you scientific calculator design makes it harder to do basic arithmetic, it is probably bad design. On the other hand if you leave out key scientific functionality because you want it to look sleek, it is also bad design.
Good design has to be based on real world usage and this is a very case-by-case thing. In the end we need to accept that it is hard to cover all use cases with one interface in a good way — so just make a more than one and let users switch.
I once had a car where I wanted to upgrade the stereo. Never did it, because the station buttons on the replacements were all too small.
I hope you didn't miss the overall message for one poorly articulated example, then. Because there was an informative point put forth.
This example made the point unbeknownst to the author.
This Dieter Rams mantra is a recurring theme.
What do you think about cockpits interfaces and Bloomberg terminals? Should we add some more “white spaces”?
Prioritising information/functionality does not mean sacrificing their density.
This Dieter Rams mantra is a recurring theme.
What do you think about cockpits interfaces and Bloomberg terminals? Should we add some more “white spaces”?
Prioritising information/functionality does not mean sacrificing their density.
Indeed. As a designer, I've seen 3000 DR articles. It's a pity designers abuse DR work just to justify their hedonisms. All apps I've seen with DR style have failed. I remember a bizarre podcast app for iOS in 2012 that was like insane DR nightmare and it was pleasant to eyes, but completely useless and utterly boring. It died against other options who were using generic iOS components. DR has born in another era of product design: most products had 1 or 2 features max. There were no playlists, no sharing, no connectivity, etc. It's easy to design when you have only those contraints.
I think some things can be easy and some things must trade low learning curve for functionality.
I highly doubt Airbus will produce a commercial airliner with a big red “fly to destination” button. (Though I’ve been wrong before)
I highly doubt Airbus will produce a commercial airliner with a big red “fly to destination” button. (Though I’ve been wrong before)
I think your comment points out “context matters”. Cockpits aren’t consumer goods.
Yes but most consumers aren't uneducated idiots, and for the purposes of this discussion, there is nothing that specific about a cockpit that can't be true for a scientific calculator or an audio console.
This attitude is how you get Macbook "Professional"s whose keyboards stop working in 2 months.
This attitude is how you get Macbook "Professional"s whose keyboards stop working in 2 months.
There might have been, but not a very original one at that. Why waste your time on an article written by someone who doesn't grasp the material fully?
> Most people would stop using it if a "UX Designer" tried to simplify it.
That’s true, I completely stopped using this type of calculator when the UX designers behind Calca, Soulver and their ilk came up with a much simpler and better design.
That’s true, I completely stopped using this type of calculator when the UX designers behind Calca, Soulver and their ilk came up with a much simpler and better design.
The better design for a scientific calculator is Maxima, or some other keyboard-driven system where the primary UI is a command line. Why? Because you're communicating information-dense messages (equations, arithmetic problems, functions) and text remains the only way we have to do that.
The command line is also the least discoverable UI imaginable. It has absolutely no obvious affordances beyond typing something into it and hoping you typed something the program understood. Even the error messages are going to be opaque unless you have some prior knowledge. There is no "just pick it up and go" with this.
On the gripping hand, however, a command line is the most fluent UI short of the Emacs/ITS affinity for keystroke bindings. Once you know how to do something, you can get amazingly fast. It actively rewards muscle memory and familiarity, as opposed to menus and progressive disclosure, which are precisely as clunky on day one thousand as they are on day one. Speaking as an HP-48GX owner, a good button array with shift keys and some context-dependent buttons can be nearly as fast as a command line, but it's inherently more limited.
My point is this: Discoverability is in tension with fluency, meaning that designing for experts is inherently different for designing for newbies, or people who use the software so rarely they're effectively always newbies. Removing functionality to unclutter an interface is newbie design thinking, as a command line is never cluttered.
(Which isn't to say you can't do both. The Emacs GUI is newbie-friendly unless a newbie is in the habit of jamming odd key combinations at random.)
The command line is also the least discoverable UI imaginable. It has absolutely no obvious affordances beyond typing something into it and hoping you typed something the program understood. Even the error messages are going to be opaque unless you have some prior knowledge. There is no "just pick it up and go" with this.
On the gripping hand, however, a command line is the most fluent UI short of the Emacs/ITS affinity for keystroke bindings. Once you know how to do something, you can get amazingly fast. It actively rewards muscle memory and familiarity, as opposed to menus and progressive disclosure, which are precisely as clunky on day one thousand as they are on day one. Speaking as an HP-48GX owner, a good button array with shift keys and some context-dependent buttons can be nearly as fast as a command line, but it's inherently more limited.
My point is this: Discoverability is in tension with fluency, meaning that designing for experts is inherently different for designing for newbies, or people who use the software so rarely they're effectively always newbies. Removing functionality to unclutter an interface is newbie design thinking, as a command line is never cluttered.
(Which isn't to say you can't do both. The Emacs GUI is newbie-friendly unless a newbie is in the habit of jamming odd key combinations at random.)
There's certainly big differences in command line apps and terminals though. Features like tab completion with inline docstrings, fish-style autocomplete, history with search-as-you-type, infinite scrollback, semantic colors, consistent interfaces, good help pages, dry-running and more all help to increase ease of use, discoverability and quicken the learning curve.
A lot of applications would be a lot better if all their functionality could be covered in one page with a bunch of buttons.
I agree. If any UX Designer thinks that SC are badly designed let them do one and let us figure out how good is their approach. 99.9% of failure for sure. Years and years of iterations on calculators can't be that wrong. But some designers love to write hedonist articles.
Not to mention that even if some features(or buttons) are unnecessarily removed it's often the wrong ones, and all that's left is a nonfunctional mess.
One of the most extreme examples I encountered was the OneDrive app preinstalled on Windows 8 which had basically no options at all, no features except clicking on files to open them, and couldn't even show how much storage was still available.
Minimalism just for the sake of it doesn't end well.
Minimalism just for the sake of it doesn't end well.
Isn't the removal of "wrong" stuff more as a consequence of business decision to pursue the masses and thus you optimize or develop for the lowest common denominator?
I don't think any company has ever straddled this line well especially if it's market overlaps between mainstream and power users.
Ofc, I mean this is in a general way. The Onedrive example you gave is actually very extreme.
I don't think any company has ever straddled this line well especially if it's market overlaps between mainstream and power users.
Ofc, I mean this is in a general way. The Onedrive example you gave is actually very extreme.
Great products do what is relevant, but better. Tools should be as simple as they can but stop there.
E.g. Despite my background in design I find Bulk Rename Utility UX - regarding its market target - really effective even if it's ugly.
https://www.bulkrenameutility.co.uk/assets/img-bru/mainscr.p...
E.g. Despite my background in design I find Bulk Rename Utility UX - regarding its market target - really effective even if it's ugly.
https://www.bulkrenameutility.co.uk/assets/img-bru/mainscr.p...
> Great products do what is relevant, but better.
I once got into an argument with someone (not a designer) about adding an "export" feature to a table UI. It was an easy feature to add, but the argument against it was that it was yet another rarely used button, that further crowded the UI. And further, users shouldn't need to export because they should be able to do everything they needed from within the app.
I was sympathetic to these arguments, especially the second. But many customers repeatedly asked for the export feature. We spoke to several and explained they could do what they needed without exporting, but even after that, they still wanted a "file" they could manipulate.
I won, and we added the export feature, and many other smallish features like it. Even though I love a minimalist design and look and feel, it shouldn't come at the expense of features. And in the end, our designers made it unobtrusive and kept it elegant.
Good design is not about deconstructing things just for simplicity's sake, but to expose the complexity in a way that feels natural.
I once got into an argument with someone (not a designer) about adding an "export" feature to a table UI. It was an easy feature to add, but the argument against it was that it was yet another rarely used button, that further crowded the UI. And further, users shouldn't need to export because they should be able to do everything they needed from within the app.
I was sympathetic to these arguments, especially the second. But many customers repeatedly asked for the export feature. We spoke to several and explained they could do what they needed without exporting, but even after that, they still wanted a "file" they could manipulate.
I won, and we added the export feature, and many other smallish features like it. Even though I love a minimalist design and look and feel, it shouldn't come at the expense of features. And in the end, our designers made it unobtrusive and kept it elegant.
Good design is not about deconstructing things just for simplicity's sake, but to expose the complexity in a way that feels natural.
> And further, users shouldn't need to export because they should be able to do everything they needed from within the app.
That's just greed and extreme entitlement dressed in UX clothes. Your software will never be good enough to suffice for all use cases within a domain; most likely it isn't even particularly ergonomic for bulk of them. Often, the output of your software is needed as input to another piece of software. That's why interoperability is so important, and lack of it is a black mark.
That's just greed and extreme entitlement dressed in UX clothes. Your software will never be good enough to suffice for all use cases within a domain; most likely it isn't even particularly ergonomic for bulk of them. Often, the output of your software is needed as input to another piece of software. That's why interoperability is so important, and lack of it is a black mark.
>> And further, users shouldn't need to export because they should be able to do everything they needed from within the app.
> That's just greed and extreme entitlement dressed in UX clothes.
I understand the passion here, especially today, users should be able to control data the way the want. However, greed or lock-down was not a relevant factor (we already had APIs for bulk data). The resistance to the "export" button was motivated by a genuine curiosity as to why someone would want to do that, and to better understand their use case. If someone is exporting something, it's because they want to do something that we do not do. The resistance was not about letting go of control of the data, but rather losing sight of what our users wanted.
> That's just greed and extreme entitlement dressed in UX clothes.
I understand the passion here, especially today, users should be able to control data the way the want. However, greed or lock-down was not a relevant factor (we already had APIs for bulk data). The resistance to the "export" button was motivated by a genuine curiosity as to why someone would want to do that, and to better understand their use case. If someone is exporting something, it's because they want to do something that we do not do. The resistance was not about letting go of control of the data, but rather losing sight of what our users wanted.
In this case replace greed with hubris.
The point is that you can't possible know what every single user will ever want to do. Thinking otherwise is entitlement.
No, but not providing an export button increases the chance they'll tell you.
Or just keep manually copy-pasting or printing, scanning and OCRing data from your system, wasting time and resources. People can go to great lengths working around software deficiencies before someone finally decides to mail the vendor.
Why should the app support printing or copy&pasting into other applications? You aren't supposed to use anything else.
Screenshots can be prevented using DRM. Linux users are hippies anyway so they don't have a job.
People could still photograph the screen or transcribe the data manually. But I'm sure a legislative solution for this problem can be found. After all, you wouldn't download a CSV file.
I hope this proposal won't be read by anyone insane enough not to see anything horribly wrong with it.
Screenshots can be prevented using DRM. Linux users are hippies anyway so they don't have a job.
People could still photograph the screen or transcribe the data manually. But I'm sure a legislative solution for this problem can be found. After all, you wouldn't download a CSV file.
I hope this proposal won't be read by anyone insane enough not to see anything horribly wrong with it.
Tell that to Excel.
Excel is great because it has every feature under the sun, is extensible and interoperable. There's little problem with getting any data into or out from it. That's why it became a crucial part of so many workflows, and in so doing, quite possibly delivered more value to end-users than any other application ever. Excel is a great product, and the opposite of greedy, entitled software design.
(Joe Spolsky wrote about it in the past; lack of vendor lock-in was crucial for it winning the market in the early days.)
(Joe Spolsky wrote about it in the past; lack of vendor lock-in was crucial for it winning the market in the early days.)
> I was sympathetic to these arguments, especially the second. But many customers repeatedly asked for the export feature.
This is the gist of what I think is good design: don't second-guess your users.
When you're doing the wireframe, you don't have all the information, ever. You don't know what your users are going to need, you don't know how they're going to use your application. You may have the best, most comprehensive specs ever written in the history of software development and users will still find new ways to use your application, that you've never thought about and couldn't even possibly imagine.
So when an user wants something, "good design" consists of figuring out how to integrate it in your application.
Not of patronizing your users and explaining them that they don't really need that, or that a clean, intuitive UI is more important than that thing they asked for. They asked for that thing precisely because that clean, intuitive UI was great but it came short of doing what they needed.
And when an application with a worse UI that does what that user needs comes along, they are going to switch to it, no questions asked. Because a bad-looking program that does what you need -- i.e. that helps you do your job and earn your pay -- will always trump one that doesn't do what you need.
This is the gist of what I think is good design: don't second-guess your users.
When you're doing the wireframe, you don't have all the information, ever. You don't know what your users are going to need, you don't know how they're going to use your application. You may have the best, most comprehensive specs ever written in the history of software development and users will still find new ways to use your application, that you've never thought about and couldn't even possibly imagine.
So when an user wants something, "good design" consists of figuring out how to integrate it in your application.
Not of patronizing your users and explaining them that they don't really need that, or that a clean, intuitive UI is more important than that thing they asked for. They asked for that thing precisely because that clean, intuitive UI was great but it came short of doing what they needed.
And when an application with a worse UI that does what that user needs comes along, they are going to switch to it, no questions asked. Because a bad-looking program that does what you need -- i.e. that helps you do your job and earn your pay -- will always trump one that doesn't do what you need.
Nah, "good design" consists of figuring out exactly what the users want based on what they say. Doing what they say is a recipe for terrible design because of the XY problem (among others).
The fact your user understands their requirements better than the designer doesn't mean that the user is a better designer. If only.
The fact your user understands their requirements better than the designer doesn't mean that the user is a better designer. If only.
It's probably not as accessible to naive users (pretty much must know regex), but StExBar has a real nice renaming tool:
https://tools.stefankueng.com/StExBar.html
https://tools.stefankueng.com/StExBar.html
Since tan was the example, we could remove cosine and tangent, and leave only sine, since the others can be computed from sine easily. It will be enough in a pinch.
tan x = sin x / cos x
cos x = sin π/2 - xI mean, since we're here already, we could remove those as well, as they can be approximated with sufficient precision using Taylor series.
And once we are here, we can remove multiplication as it can be sufficiently approximated by a plus operator. This will make the UI cleaner and UX neater.
Do not listen to those pesky customers who whine they have to press "+" button lots of times.
Do not listen to those pesky customers who whine they have to press "+" button lots of times.
And is not + just a mere shortcut for typing a larger number?
:) I think it's a quite an innovation to have automatic sine tables or whatever the button could be described as, and that the sine button is indispensable - if you do geometry or similar.
Regarding the calculator, I really loved those credit-card sized calculators of the 80s but I rarely see them anymore. Also, I'm curious what a modern credit-card sized device would be capable of.
All their circuitry was purpose-designed for the specific things the calculator did. That's why room light was enough to power them. Something more complicated would lose many of the benefits (tiny general purpose CPU) or be expensive and unreliable (big, complex circuits).
Modern microcontrollers can run on a fraction (uA range) of the power that those 80s credit card calculators ran on (mA range), and still have millions of times more powerful processing abilities.
Check out the Teenage Engineering Pocket Operators [0]! They're credit card sized electronic instruments. They've managed to fit a full fledged sampler in the PO-33 and a voice synthesizer in PO-35. The others aren't as processing intense but still have really powerful patterning and sounds. All running off of 2 AAA batteries, with months of battery life.
[0] https://teenage.engineering/products/po
[0] https://teenage.engineering/products/po
There are 2 separate dedicated buttons for log_e and log_10. Why can't we get a single general log_x button!? I'm tired of having to type log(y)/log(x) instead of log_x(y).
Any proper scientific calculator also has a dedicated logx button.
Would you care to recommend one? Causally browsing for scientific calculators, the overwhelming majority seem to not have a logx button.
https://www.amazon.in/Casio-FX-991ES-Plus-Scientific-Calcula...
I used this one for my BE in electronics. Casio 991es. If you look at the button just below the ON button, that is the logx function.
I used this one for my BE in electronics. Casio 991es. If you look at the button just below the ON button, that is the logx function.
The windows calculator has a decent compromise where you have to specifically change to the advanced mode and the UI exposes the other buttons.
Hard to apply that to a physical calculator I suppose.
Hard to apply that to a physical calculator I suppose.
Windows calculator is annoying me. I've frequently have to switch to and from programmer. It's not powerful enough to do anything useful, but can convert between number systems. But any switch clears the current input. And certainly doesn't move data over if I've already did a calculation or (, more often then I'd like to admit,) already inputted a number before noticing what mode I'm in. Another issue is hotkeys... sure, there is a way to switch between planes by keyboard. But the dumbed-down interface for mobile just doesn't provide any way to tell you.
The article is aimed at designers.
This line of thinking is how we end up with a market of disposable, crappy toys satiating the immediate needs of "minimum viable users" but being incredibly wasteful over time.
Out of the examples named:
- Twitter - has plenty of features, and a larger ecosystem of additional features that, despite them trying their hardest, they didn't manage to kill.
- Lyft - it's a meatspace service that's to some extent open-ended in terms of feature, but the app aspect itself is featureful compared to their simpler competitor: central dispatch taxi ordered through a phone call.
- Venmo - can't comment on it, it doesn't seem to exist in my parts of the world.
- Slack - it has lots and lots of features, constantly adds new ones, and it has a large ecosystem of integrations. Those features and integrations are a big reason Slack is adopted in organizations, over alternatives. If you want to compare it against a focused tool that does one thing and does it well, compare it against IRC.
Great products do their primary use case well, but have high mastery ceiling - meaning there's potential to learn to use the tool better to achieve higher efficiency/productivity/satisfaction - and support interoperability, which means a bespoke set of features can be integrated by users who need it.
Out of the examples named:
- Twitter - has plenty of features, and a larger ecosystem of additional features that, despite them trying their hardest, they didn't manage to kill.
- Lyft - it's a meatspace service that's to some extent open-ended in terms of feature, but the app aspect itself is featureful compared to their simpler competitor: central dispatch taxi ordered through a phone call.
- Venmo - can't comment on it, it doesn't seem to exist in my parts of the world.
- Slack - it has lots and lots of features, constantly adds new ones, and it has a large ecosystem of integrations. Those features and integrations are a big reason Slack is adopted in organizations, over alternatives. If you want to compare it against a focused tool that does one thing and does it well, compare it against IRC.
Great products do their primary use case well, but have high mastery ceiling - meaning there's potential to learn to use the tool better to achieve higher efficiency/productivity/satisfaction - and support interoperability, which means a bespoke set of features can be integrated by users who need it.
>If you want to compare it against a focused tool that does one thing and does it well, compare it against IRC.
IRC hardly does what it does well.
IRC hardly does what it does well.
It does it well but it’s not simple to use. Which has now become one of its features.
A better solid comparison would be a simple email client like old Phoenix Mail.
(Not Outlook, not Gmail, these are super loaded with features.)
(Not Outlook, not Gmail, these are super loaded with features.)
IRC vs slack is misguided comparison. Irc is protocol, slack is centralized service.
Still, if we just concentrate on a irc client implementation and ignore the service, it's the user experience we're comparing...
Counterpoint: Joel Spolsky's "Bloatware and the 80/20 myth" from 2001.
> Unfortunately, it’s never the same 20%. Everybody uses a different set of features. In the last 10 years I have probably heard of dozens of companies who, determined not to learn from each other, tried to release “lite” word processors that only implement 20% of the features. This story is as old as the PC. Most of the time, what happens is that they give their program to a journalist to review, and the journalist reviews it by writing their review using the new word processor, and then the journalist tries to find the “word count” feature which they need because most journalists have precise word count requirements, and it’s not there, because it’s in the “80% that nobody uses,” and the journalist ends up writing a story that attempts to claim simultaneously that lite programs are good, bloat is bad, and I can’t use this damn thing ’cause it won’t count my words. If I had a dollar for every time this has happened I would be very happy.
https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...
> Unfortunately, it’s never the same 20%. Everybody uses a different set of features. In the last 10 years I have probably heard of dozens of companies who, determined not to learn from each other, tried to release “lite” word processors that only implement 20% of the features. This story is as old as the PC. Most of the time, what happens is that they give their program to a journalist to review, and the journalist reviews it by writing their review using the new word processor, and then the journalist tries to find the “word count” feature which they need because most journalists have precise word count requirements, and it’s not there, because it’s in the “80% that nobody uses,” and the journalist ends up writing a story that attempts to claim simultaneously that lite programs are good, bloat is bad, and I can’t use this damn thing ’cause it won’t count my words. If I had a dollar for every time this has happened I would be very happy.
https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...
Following that example, looks like there is no minimalist general case, but should be possible to achieve a minimal product for journalist, taking into account what they need.
By further extending this logic, would be possible to arrange different sets of minimal features for every type of users, or at least cover a majority of those user cases and not force a one size-fits-all approach.
Except it’s much easier to learn how to ignore all the features you don’t necessarily need, than to start learning a completely new product every time one of the features you need isn’t in the one you’re currently using.
On that matter, it should be possible to re-package the same product but with different UI configurations.
I am pretty sure modern IDEs are quite configurable. Why not word processors?
I am pretty sure modern IDEs are quite configurable. Why not word processors?
Because now every repackaging works differently and you need N copies of the same product if one doesn't contain all features you need.
This is why a lot of applications provide something like workspaces where you get to pick and choose a UI configuration based on the task at hand. I first saw this in Blender and Eclipse (Blender 2.80 has made this feature more prominent, but it's from the old 1.x days). Maya has this to some extent. Adobe has introduced this in Photoshop and some other products. And all of these programs allow you to come up with your own configurations, too. FreeCAD also has this kind of concept, but there the workspaces are actually pretty much corresponding to UI modes, even though you can switch bith independently.
The worst outlier here is Visual Studio. It has this kind of concept internally and keeps different UI configurations for editing and debugging. But you get zero control over that as a user. The UI switch when entering/leaving the debugger is hardcoded.
The worst outlier here is Visual Studio. It has this kind of concept internally and keeps different UI configurations for editing and debugging. But you get zero control over that as a user. The UI switch when entering/leaving the debugger is hardcoded.
Sure. But workspaces are a way for the user to refocus the UI on particular family of features. But all other features are not gone; they're still there in the program. Depending on the feature type, some may be accessible through menus and could be included into workspace on demand by changing some options.
So what's the problem with having those features if we are focusing on the fact that only the presence of them in the UI may make the it more distracting?
The article we're discussing argues for removing features, not merely their UI indicators.
As for the justification for keeping rarely used features somewhere in the UI anyway, a minimally familiar user will be able to ignore currently unused features faster than they'll be able to find hidden features when they're needed. Human vision has an amazing ability to filter and focus.
As for the justification for keeping rarely used features somewhere in the UI anyway, a minimally familiar user will be able to ignore currently unused features faster than they'll be able to find hidden features when they're needed. Human vision has an amazing ability to filter and focus.
Word processors used to be. You could drag and rearrange toolbars and icons to reflect your own needs.
Normally the solution everyone gets then is that the products particular users need is done via some sort of plugin system, and then because the menu shouldn't get too bloated you have a plugins entry on the menu, and then the user has to click that, and then click the journalist entry, and then probably some other plugin specific entry that will be different from every other plugin writers' entries - something like Text functions (because probably the Journalist plugin was written by a programmer somewhere who thinks Text functions is totally a great name to put the little atomic functions that do stuff with text in) - to get to the word count entry.
And the installation process for these plugins is going to be arduous and mind-numbing too.
Why, yes, I have used eclipse before! How did you know?
And the installation process for these plugins is going to be arduous and mind-numbing too.
Why, yes, I have used eclipse before! How did you know?
I don't think this implies that there's five distinct groups of users that each use an independent set of 20% (for a total of 100%) -- such that all features implemented are mission critical.
Not everyone has an identical 20% --that part I can follow and agree with-- but surely a single user's feature usage overlaps substantially with many other users. Maybe there's a core 15%, and a few users customize the last 5%. All in all, maybe it's more 30-70 vs. 20-80.
It probably depends on the product in question, but I think this overestimates the length of the longtail, and the overall distribution of usage of product features.
Not everyone has an identical 20% --that part I can follow and agree with-- but surely a single user's feature usage overlaps substantially with many other users. Maybe there's a core 15%, and a few users customize the last 5%. All in all, maybe it's more 30-70 vs. 20-80.
It probably depends on the product in question, but I think this overestimates the length of the longtail, and the overall distribution of usage of product features.
While this is true, the non-overlapping parts are easily the one that drive decision making.
E.g. anectodal - We've passed on Google Drive enterprise usage in favour of Dropbox on several companies because they don't support Linux. Even though the majority of machines at those companies were macs and only a few of them were Linux machines, the lack of that feature led to a loss of a whole purchase order. Even though the "stats" only show that there's a few % of Linux users.
E.g. anectodal - We've passed on Google Drive enterprise usage in favour of Dropbox on several companies because they don't support Linux. Even though the majority of machines at those companies were macs and only a few of them were Linux machines, the lack of that feature led to a loss of a whole purchase order. Even though the "stats" only show that there's a few % of Linux users.
This is a problem that I've been increasingly encountering with software -- it's become so "lean" that it starts omitting features that are critical to me. When I mention it, I'm told that telemetry indicated that it wasn't used enough, so it was eliminated.
Fine, but that means that such software is now useless to me. I have a hard time believing that I am an exception and am the only one encountering this problem, and I'd be willing to bet that the features that others consider "critical" are not the same as the ones that are critical to me.
This whole trend is a race to the bottom.
Fine, but that means that such software is now useless to me. I have a hard time believing that I am an exception and am the only one encountering this problem, and I'd be willing to bet that the features that others consider "critical" are not the same as the ones that are critical to me.
This whole trend is a race to the bottom.
Agreed!
I'm going to sound old and cranky for a bit but Apple has been doing this with OSX for a while now.
Random examples:
- Preview no longer allows you to pan around documents by holding the space bar. I guess not enough people used that feature because they view documents on their Macbooks, and nobody at Apple Uses non-magic mice. Ugh.
- Dashboard (I know I'm waay the minority here). It's going away in favor of Notification Center. Its replacement on the right side of the screen is so much worse because I have to choose between viewing my notifications or the widgets, when I currently do not. I currently still use dashboard to take super quick notes, and unit conversions and calculations. IMO Dashboard in it's soon-to-be-deprecated state was a great idea that was never refined and should have been integrated with the App Store.
Seemingly I'm the only person I know that uses Hot Corners with Mission Control, and if that goes away I don't know what I'll do.
I'm going to sound old and cranky for a bit but Apple has been doing this with OSX for a while now.
Random examples:
- Preview no longer allows you to pan around documents by holding the space bar. I guess not enough people used that feature because they view documents on their Macbooks, and nobody at Apple Uses non-magic mice. Ugh.
- Dashboard (I know I'm waay the minority here). It's going away in favor of Notification Center. Its replacement on the right side of the screen is so much worse because I have to choose between viewing my notifications or the widgets, when I currently do not. I currently still use dashboard to take super quick notes, and unit conversions and calculations. IMO Dashboard in it's soon-to-be-deprecated state was a great idea that was never refined and should have been integrated with the App Store.
Seemingly I'm the only person I know that uses Hot Corners with Mission Control, and if that goes away I don't know what I'll do.
I feel the ‘solution’ MS Word, Excel, Chrome, SQL Developer ++ have taken on this is to give the user the bare minimum that everyone need to begin with and hidden all the features. This way they get the best from both worlds. The difficult part is how to group those hidden features together.
Don't think about this in terms of hiding features. That isn't the goal. The task is to put them somewhere in the UI wherentheyncan be explored and discovered while not being prominent. Hiding implies that features cannot be discovered by exploring the UI, which os rarely a good thing.
It might be an unpopular opinion, but IMO the MS Ribbon UI is still one of the best examples of this kind of UI (at least in a somewhat current incarnation).
My main criticism of the ribbon is how it radically changes its structure when the window is resized. This creates menus out of formerly top level elements etc. Thus, Word at half screen width is a radically different UI than at full width.
Then there are these almost invisible buttons next to the bottom group labels. Some features are hidden behind those but there is no good visual indication that these buttons open dialogs related to features the group.
So I am not totally convinced that they are the best in this field.
Then there are these almost invisible buttons next to the bottom group labels. Some features are hidden behind those but there is no good visual indication that these buttons open dialogs related to features the group.
So I am not totally convinced that they are the best in this field.
[deleted]
How would word count not be part of a minimalist WP? Did it have cut-and-paste capabilities? A spellchecker? Aiming for 20% is fine, but the final product must still hit the basic features everyone expects.
This tends to be true in case of consumer products and tend to be not true in case of professional products.
Google search is simple, Google AdWords is not, and never was.
You cannot create a professional 3D modeling software, photo editing software, IDE, video editing software without starting relatively complex. Professionals need to use quite a lot of sophisticated features to be productive. The learning curve is less of a concern in a professional setting.
(I kind of know it because I have been working on a VR 3D modeler for a while. To create a professional-grade software the barrier to entry is quite high, so small developers try to create simple-to-use consumer, hobby-ist, products. I am creating a hobby-ist product, which is already much more complex than a consumer product.) If you look at reviews of the smaller products, the overwhelming majority of criticism is lack of features.
This is an overly broad generalization.
Computer software products can and should come in all sizes and flavors and designs.
This is the most powerful and flexible machine invented. You can’t say the software that runs in them should be like this or like that.
What you can say is some products do well by being simple.
Computer software products can and should come in all sizes and flavors and designs.
This is the most powerful and flexible machine invented. You can’t say the software that runs in them should be like this or like that.
What you can say is some products do well by being simple.
It's likely true in their own bubble of small business apps on Product Hunt where performance is mostly measured in time savings and the simplification of processes.
But this doesn't hold for more creative applications that are more like games, where the time spend doing a task is time that is regarded as time well spend, where there is value in developing your own workflow and explorations.
But this doesn't hold for more creative applications that are more like games, where the time spend doing a task is time that is regarded as time well spend, where there is value in developing your own workflow and explorations.
I'd use every one of the buttons on that calculator. Admittedly I've never had need for gradians, but they're on the same button as degrees and radians, so it would still get pushed. For everyday use I use Qalculate!, and for more complicated calculations Maxima or LibreOffice Calc, all of which are far more advanced than a Sharp EL-501X. Dumbing down products makes them worse.
I think the scientific calculator could be an example of this principle on its own. It's often far more useful for a mathematician than struggling with the calculator app on a phone or booting up a clunky laptop.
Ultimately I think the principle is flawed. The amount of features isn't an issue but rather whether each and every feature works well and adds to the value of the product. Eg. a scientific calculator would be an awful fit for a todo list application.
Ultimately I think the principle is flawed. The amount of features isn't an issue but rather whether each and every feature works well and adds to the value of the product. Eg. a scientific calculator would be an awful fit for a todo list application.
[Wabbitemu](http://wabbitemu.org/) makes a TI-83 emulator for Windows / Mac / Android.
A simpler product might serve my needs, but this is one I've used for years and understand well (and works with existing hardware).
A simpler product might serve my needs, but this is one I've used for years and understand well (and works with existing hardware).
A more accurate statement would've been -
Solving fewer problems, better makes for a great product.
"Less features make my job easier, so please have less features" - UX designers reluctant to solve the problem they were hired to solve
Well, duh. Developers can relate, short programs are exponentially easier to write well than large ones. That's the challenge.
> Think about the most successful products you know. The ones you use everyday, as a customer. Twitter, Lyft, Venmo, Slack.
I wouldn't think of these products and I don't use them every day.
I would think of very complex applications with an incredible amount of features that I'll mostly never use. However, this large surface area overlaps with what I need. There is no "more focused" app that does the job.
I would also think of the top software companies - Microsoft, Oracle, SAP, IBM. None of these companies are known for their "simple and focused" applications. Quite the contrary.
Sure, if you have a little app that's just a frontend for one thing, keep the focus. Otherwise, keep in mind that "it doesn't do the one thing we need" is generally a deal-breaker, whereas "it does one-hundred things we don't need" is not. Everyone's needs are slightly different and critical mass is important.
Well, duh. Developers can relate, short programs are exponentially easier to write well than large ones. That's the challenge.
> Think about the most successful products you know. The ones you use everyday, as a customer. Twitter, Lyft, Venmo, Slack.
I wouldn't think of these products and I don't use them every day.
I would think of very complex applications with an incredible amount of features that I'll mostly never use. However, this large surface area overlaps with what I need. There is no "more focused" app that does the job.
I would also think of the top software companies - Microsoft, Oracle, SAP, IBM. None of these companies are known for their "simple and focused" applications. Quite the contrary.
Sure, if you have a little app that's just a frontend for one thing, keep the focus. Otherwise, keep in mind that "it doesn't do the one thing we need" is generally a deal-breaker, whereas "it does one-hundred things we don't need" is not. Everyone's needs are slightly different and critical mass is important.
That's good advice; if you are building a command-line tool for Unix. :)
The thing is I can chain command-line tools using a pipe, embed them into scripts and more. I probably can't do that with your app.
My guess is that great products are based around workflows rather than features. Have a vision, work towards it.
The thing is I can chain command-line tools using a pipe, embed them into scripts and more. I probably can't do that with your app.
My guess is that great products are based around workflows rather than features. Have a vision, work towards it.
And even with command line tools, a few extra features don't hurt. Going from GNU tools to the more barebone Unix stuff is often a pain. Things like no option for ls to sort by size, no "human readable" sizes, no recursive grep, etc... While some of these can be replaced by pipelines having a shortcut for common use cases is nice.
An example is "tar xvzf file.tgz". The "z" option is just a shortcut for "gzip -cd file.tgz | tar xvf -", but most people are quite happy with this bloat.
An example is "tar xvzf file.tgz". The "z" option is just a shortcut for "gzip -cd file.tgz | tar xvf -", but most people are quite happy with this bloat.
The pictured sharp calculator made me rage at the state of modern desktop calculators in most OS’s. The other day I needed atan (inverse tan) and found the built in windows/osx calculators do not support this function. Google for web calculator, nothing. In the end I hacked up a quick c based program. A 40 year old calculator with a 4004 or 6502 CPU can do more than default desktop applications.
Removing features can eliminate a customer or two.
Removing features can eliminate a customer or two.
Both Mac and window have scientific mode.
https://support.apple.com/guide/calculator/welcome/mac
https://support.microsoft.com/en-us/help/4039496/windows-10-...
There is also bc, that macos should have by default. https://www.gnu.org/software/bc/
https://support.apple.com/guide/calculator/welcome/mac
https://support.microsoft.com/en-us/help/4039496/windows-10-...
There is also bc, that macos should have by default. https://www.gnu.org/software/bc/
Having used bc as my calculator for a while, i recently switched to insect - because it has fore features. For example it can parse and convert between physical units and has a lot of predefined constants.
So instead of using two command line tools (bc to calculate, units to convert) i just use insect.
https://github.com/sharkdp/insect
There is a web version available as well: https://insect.sh
https://github.com/sharkdp/insect
There is a web version available as well: https://insect.sh
Turning the iPhone calculator sideways reveals a scientific calc layout, including tanh
Unfortunately feature bloat on a simple device often results in making things no longer easily discoverable. (I'm looking at you, force touch.)
Unfortunately feature bloat on a simple device often results in making things no longer easily discoverable. (I'm looking at you, force touch.)
tanh and arctan are different functions.
To get to inverse tan, you need to hit the “2nd” toggle on the far left.
(So yes, you need to turn your phone sideways and tap a poorly-marked and unexplained toggle button that looks like every other button on the screen.)
(So yes, you need to turn your phone sideways and tap a poorly-marked and unexplained toggle button that looks like every other button on the screen.)
And everyone else uses ‘inv’ instead of 2nd.
« 2nd » is the toggle for the alternate calculator layout (which has all the inverse functions).
The key on that alternate layout is tan^-1.
The key on that alternate layout is tan^-1.
That's not true at all.
The ti30 and relatives are arguably one of the most well known scientific calculators in the world, and it uses 2nd. http://i.ebayimg.com/00/$T2eC16FHJH4FHejHUSZ3BSB3Dzh6%20g~~_...
The hp35 and relatives use an upper and lower "shift" button to access the inverse trig functions. http://i.ebayimg.com/images/i/251900074306-0-1/s-l1000.jpg
The ti30 and relatives are arguably one of the most well known scientific calculators in the world, and it uses 2nd. http://i.ebayimg.com/00/$T2eC16FHJH4FHejHUSZ3BSB3Dzh6%20g~~_...
The hp35 and relatives use an upper and lower "shift" button to access the inverse trig functions. http://i.ebayimg.com/images/i/251900074306-0-1/s-l1000.jpg
> windows/osx calculators do not support this
First of all, the default OS X and Windows calculators both do support this feature. But that’s not really the easy way to approach this type of problem.
On OS X, first do command-space (to bring up the floating “spotlight” bar), then type e.g. atan(1), and it reveals the answer rounded to 10 digits, 0.7853981634
To get 20 digits, open up a terminal window, and type: bc -l <<< "a(1)"
Or use your favorite scripting language...
> Google for web calculator, nothing
Type atan(1) into google and it prints the answer.
Or open up the JavaScript console on this forum page (or any other web page) and type Math.atan(1) to get the answer to 16 digits 0.7853981633974483
Alternately, try https://www.wolframalpha.com/ for more complicated calculations.
> default desktop [calculator] applications
Imitating the buttons of a handheld electronic calculator on a computer with a full keyboard is anachronistic and cumbersome. Stop using those, even when they do include the specific functions you want.
First of all, the default OS X and Windows calculators both do support this feature. But that’s not really the easy way to approach this type of problem.
On OS X, first do command-space (to bring up the floating “spotlight” bar), then type e.g. atan(1), and it reveals the answer rounded to 10 digits, 0.7853981634
To get 20 digits, open up a terminal window, and type: bc -l <<< "a(1)"
Or use your favorite scripting language...
> Google for web calculator, nothing
Type atan(1) into google and it prints the answer.
Or open up the JavaScript console on this forum page (or any other web page) and type Math.atan(1) to get the answer to 16 digits 0.7853981633974483
Alternately, try https://www.wolframalpha.com/ for more complicated calculations.
> default desktop [calculator] applications
Imitating the buttons of a handheld electronic calculator on a computer with a full keyboard is anachronistic and cumbersome. Stop using those, even when they do include the specific functions you want.
> Google for web calculator, nothing.
https://www.google.com/search?q=atan(42)
https://www.google.com/search?q=atan(42)+in+degrees
(Personally, I usually do quick-and-dirty arithmetic directly in the shell, as ksh expressions include floating point.
https://www.google.com/search?q=atan(42)
https://www.google.com/search?q=atan(42)+in+degrees
(Personally, I usually do quick-and-dirty arithmetic directly in the shell, as ksh expressions include floating point.
echo $((atan(42)))
)First google result for "windows calculator atan": https://www.reddit.com/r/Windows10/comments/3kb0n1/how_to_do...
Pretty similarly, OSX's calculator (at least in 10.11) has a "2nd" / shifted layout with inverses:https://imgur.com/a/xFUKxwP
I use Python as my desktop calculator.
Are you sure? I haven’t seen a windows calculator that didn’t have that feature since before I learned trig. Were you using the scientific calculator layout and the shift/2nd key?
> built in windows calculator
Alt-2 (for Scientific mode), Inv, Tan
Alt-2 (for Scientific mode), Inv, Tan
[deleted]
WolframAlpha is still around, no?
Many great products have many, many features. One of the examples given (Lyft) might appear simple on the surface, but think about the complexity behind just one element: the matching and routing for Lyft Line (similar to UberPool).
Lyft has many, many engineers, and I'm pretty sure they're doing more than fixing bugs, dealing with infrastructure scaling etc.
One thing great products do seem to have in common is that they are easy to use, in the sense that their UI has few elements, and much complexity is hidden from the user.
This is similar to the concept of having APIs that are simple, but which are serviced by code that does a lot under the hood, hiding the complexity from the API consumer.
Lyft has many, many engineers, and I'm pretty sure they're doing more than fixing bugs, dealing with infrastructure scaling etc.
One thing great products do seem to have in common is that they are easy to use, in the sense that their UI has few elements, and much complexity is hidden from the user.
This is similar to the concept of having APIs that are simple, but which are serviced by code that does a lot under the hood, hiding the complexity from the API consumer.
Other examples include AutoCAD, Photoshop, Premiere, Corel suite, Office (Word, Excel, Access). Visual Studio, Eclipse, IntelliJ IDEA. Eagle. VMWorks management suite. Visio, Rational Enterprise Architect.
All of digital audio workstation products. Most video production applications.
Heck, Windows and Mac OS.
None of those cut features ever. This is why they're great, because you can do many things not possible otherwise, or hard and requiring hoops, with them.
The UX is nicely layered and chunked to overwhelm less. (With some mistakes like lately seen in Windows 8 or 10.)
Great products do more and better. None of these applications started small. They were only somewhat smaller from out and responded to feedback about additional features.
Comparing tiny apps like Twitter or Slack to these is funny.
None of those cut features ever. This is why they're great, because you can do many things not possible otherwise, or hard and requiring hoops, with them.
The UX is nicely layered and chunked to overwhelm less. (With some mistakes like lately seen in Windows 8 or 10.)
Great products do more and better. None of these applications started small. They were only somewhat smaller from out and responded to feedback about additional features.
Comparing tiny apps like Twitter or Slack to these is funny.
Tell that to WeChat and a bunch of other Asian products.
The idea of great products is kind of misguided.
Talking about great products is something industry people do it's not something users of the product think about them.
In other words, it's academically interesting but not useful to determine whether a product is actually successful which IMO is part of the greatness of a product.
The idea of great products is kind of misguided.
Talking about great products is something industry people do it's not something users of the product think about them.
In other words, it's academically interesting but not useful to determine whether a product is actually successful which IMO is part of the greatness of a product.
As examples of this thesis, apparently, it shows photographs of a camera flash, a bookshelf radio, a turntable, and a pocket calculator. Yow.
How many people have used any of those standalone devices in the past 10 years? How many of you have used, in the past 10 minutes, any of those as a feature of a single device that includes all of these? I rest my case.
The 1968 Braun catalog may end up in an industrial design museum for its beauty, but people aren't buying products like that for their beauty today, any more than they're buying 1968 sports cars. People open their wallet for features.
How many people have used any of those standalone devices in the past 10 years? How many of you have used, in the past 10 minutes, any of those as a feature of a single device that includes all of these? I rest my case.
The 1968 Braun catalog may end up in an industrial design museum for its beauty, but people aren't buying products like that for their beauty today, any more than they're buying 1968 sports cars. People open their wallet for features.
[deleted]
Though the article doesn’t say anything new, it’s astonishing how hard it is for founders (especially of SaaS products) to actually do this. I run a UI/UX design firm that focusses on B2B SaaS products and the biggest difference I see between great and ok products is the founder’s a ability to accept simplification and focus. Feature creep sounds like you may be adding ‘more value to your end users’. In reality, you’re making your product more generic, less valuable, and slower in terms of helping the user get from point A to B.
My iPhone is a great product because it does more.
Great products don't have to be spartan. But in my experience they do seem to be intentional and value craftsmanship.
Great products don't have to be spartan. But in my experience they do seem to be intentional and value craftsmanship.
The iPhone isn't spartan, but it does a great job of illustrating how Apple pares away features for a better user experience. Apple is famous for eliminating things that stun hackers: the disk drive, expandable memory, replaceable batteries, audio jacks. Slashdot famously pronounced the iPod "lame" for not having a bunch of things that a cheaper competitor offered, but Apple had zeroed in on exactly the things that people wanted. Their app store is much less open than Android's, but gives most people the things that they want.
Developers in particular seem to have a hard time remembering that most people don't want a product that can do anything. They want a product that does exactly the things that they want it to do and is optimized for those. Finding that sometimes requires a great leap of insight -- or faith.
Developers in particular seem to have a hard time remembering that most people don't want a product that can do anything. They want a product that does exactly the things that they want it to do and is optimized for those. Finding that sometimes requires a great leap of insight -- or faith.
My digital camera does one thing very well, but cameras are becoming extinct. My old iPod did one thing well and it's gathering dust in a drawer, next to my old cell phone. The argument for single-purpose vs multi-purpose devices is not as simple as the article wants to believe.
You're not thinking about how limited your iphone is.
I know It doesn't seem limited, but Apple abide by the premise of the title by having a closed app store, a really tight SDK and only a few handsets and platforms.
Contrast to Android which runs on everything and doesn't suck but it looks generally generic.
I know It doesn't seem limited, but Apple abide by the premise of the title by having a closed app store, a really tight SDK and only a few handsets and platforms.
Contrast to Android which runs on everything and doesn't suck but it looks generally generic.
I would rather have fewer, but higher quality apps on my smart phone.
I’ve used both android (2010-2015) and iphone (2015-2019) and I have to say, android has higher quality apps. Apple’s walled garden is not preventing low effort, low quality apps from flooding the store. The more restrictive userspace APIs really hurt a lot of useful functionality and having to pay upfront to develop, let alone distribute apps deters many excellent softwares (talk to someone else about the wonders of FOSS). I would say you have to be more careful with android, but I’m not sure that’s really the case since apple store apps are very often “dangerous”.
I am not sure I see your point. You choose what apps you install, and you can uninstall bad ones.
It is easier to develop high quality app for iOS than Android.
With iOS, there are only relatively few different devices, they behave almost the same and most of the users are running up to date OS. On the other hand, there are too many Android devices to test your app with, many of them are buggy in unique ways (especially some models from Samsung and Huawei, and you can't ignore those because they have largest market shares), and on top of that manufacturers generally don't port new Android releases to old devices, so you have to support old APIs if you want to reach most Android users.
Sometimes our users complain that we spend all of our resources supporting iOS, Windows and OS X and Android support is just a second thought. In reality we spend most of our time on Android and it's still the worst.
Source: I develop a multiplatform audio app for living.
With iOS, there are only relatively few different devices, they behave almost the same and most of the users are running up to date OS. On the other hand, there are too many Android devices to test your app with, many of them are buggy in unique ways (especially some models from Samsung and Huawei, and you can't ignore those because they have largest market shares), and on top of that manufacturers generally don't port new Android releases to old devices, so you have to support old APIs if you want to reach most Android users.
Sometimes our users complain that we spend all of our resources supporting iOS, Windows and OS X and Android support is just a second thought. In reality we spend most of our time on Android and it's still the worst.
Source: I develop a multiplatform audio app for living.
I recently wrote this to someone who was thinking of learning Pico-8 (a very minimal game engine) I was saying they should just learn Unity instead.
...
Something like Pico-8 reminds me of a program from my days as an architect. Sketchup, it was a very intuitive 3d modelling program aimed at architects, it was very easy to learn, but once you've got the hang of it you start running into all sorts of limitations, like the initially lovely UI becomes a total mess when u have a big and / or complex model, it performs really bad, it cant do proper renders at all, and so on. In the end, after struggling with Sketchups limitations I just learned 3DSmax It could do everything Sketchup could do + soooooo much more, the learning curve was much steeper at the very start, but afterwards, working with it was much easier and faster, and allowed me to do a lot more. I would have been much better off if I had started with 3DSMAX, as opposed to wasting time struggling with Sketchup trying to get it to do stuff it couldnt.
...
Something like Pico-8 reminds me of a program from my days as an architect. Sketchup, it was a very intuitive 3d modelling program aimed at architects, it was very easy to learn, but once you've got the hang of it you start running into all sorts of limitations, like the initially lovely UI becomes a total mess when u have a big and / or complex model, it performs really bad, it cant do proper renders at all, and so on. In the end, after struggling with Sketchups limitations I just learned 3DSmax It could do everything Sketchup could do + soooooo much more, the learning curve was much steeper at the very start, but afterwards, working with it was much easier and faster, and allowed me to do a lot more. I would have been much better off if I had started with 3DSMAX, as opposed to wasting time struggling with Sketchup trying to get it to do stuff it couldnt.
> Sketchup ... was a very intuitive 3d modelling program aimed at architects, it was very easy to learn, but once you've got the hang of it you start running into all sorts of limitations
I'm not sure Sketchup was really aimed at architects. Few real licensed architect rely on Sketchup (although they may use it occasionally). It's a great piece of software to get the uninitiated into modeling (it worked for you) and it can handle many non-professional tasks pretty well (e.g., light home renovation). Also (and this is big) sketchup is free. The professional tools cost thousands a year, if I remember correctly 3DSMax is ~$400/month. No 3D modeling newbie is going to drop that cash just to get their feet wet with the profession. Sketchup is not the end-all, but it has its place.
And lets take the analogy further: easy-to-use starter kits in every field are incredibly helpful. They allow you to learn a field without a huge commitment and then to decide whether you want to invest more of your time. If someone did indeed start with 3DSMax without using sketchup, there's a strong likelihood that they'd get frustrated and give up. More generally, if you have to tackle a difficult problem, start small and break off a piece rather than trying to conquer the whole.
I'm not sure Sketchup was really aimed at architects. Few real licensed architect rely on Sketchup (although they may use it occasionally). It's a great piece of software to get the uninitiated into modeling (it worked for you) and it can handle many non-professional tasks pretty well (e.g., light home renovation). Also (and this is big) sketchup is free. The professional tools cost thousands a year, if I remember correctly 3DSMax is ~$400/month. No 3D modeling newbie is going to drop that cash just to get their feet wet with the profession. Sketchup is not the end-all, but it has its place.
And lets take the analogy further: easy-to-use starter kits in every field are incredibly helpful. They allow you to learn a field without a huge commitment and then to decide whether you want to invest more of your time. If someone did indeed start with 3DSMax without using sketchup, there's a strong likelihood that they'd get frustrated and give up. More generally, if you have to tackle a difficult problem, start small and break off a piece rather than trying to conquer the whole.
> The professional tools cost thousands a year, if I remember correctly 3DSMax is ~$400/month. No 3D modeling newbie is going to drop that cash just to get their feet wet with the profession. Sketchup is not the end-all, but it has its place.
There's also an educational 3-year free license and regular 30-day trial, plus the usual way to learn pro software that companies unofficially accept: piracy.
> If someone did indeed start with 3DSMax without using sketchup, there's a strong likelihood that they'd get frustrated and give up. More generally, if you have to tackle a difficult problem, start small and break off a piece rather than trying to conquer the whole.
Depends on what they're trying to achieve. It has to be contrasted with awareness that for some users, learning Sketchup first is a waste of time.
I notice people seem to have an alergy for learning these days. 3DSMax isn't hard to get hang of once you pick up a book that starts by guiding you through the UI and basic concepts (Source: I'm teaching 3DSMax to someone right now, even though I know little of it myself - but I'm not afraid of opening a book or official help pages).
> More generally, if you have to tackle a difficult problem, start small and break off a piece rather than trying to conquer the whole.
That's true, but this applies to conceptual level; it does not necessarily mean you have to simplify tooling for it.
There's also an educational 3-year free license and regular 30-day trial, plus the usual way to learn pro software that companies unofficially accept: piracy.
> If someone did indeed start with 3DSMax without using sketchup, there's a strong likelihood that they'd get frustrated and give up. More generally, if you have to tackle a difficult problem, start small and break off a piece rather than trying to conquer the whole.
Depends on what they're trying to achieve. It has to be contrasted with awareness that for some users, learning Sketchup first is a waste of time.
I notice people seem to have an alergy for learning these days. 3DSMax isn't hard to get hang of once you pick up a book that starts by guiding you through the UI and basic concepts (Source: I'm teaching 3DSMax to someone right now, even though I know little of it myself - but I'm not afraid of opening a book or official help pages).
> More generally, if you have to tackle a difficult problem, start small and break off a piece rather than trying to conquer the whole.
That's true, but this applies to conceptual level; it does not necessarily mean you have to simplify tooling for it.
It definitely was aimed at architects (among others) when it came out in 2000.
I had just started architecture college then, we did everything on paper, I only learned Autocad during my 1st summer job. 'Computers' were more the realm of architectural technicians back then, I didnt know any architects who could use any 3d modelling software at all. Architects were generally quite computer illiterate, Sketchup was a program simple enough for a computer illiterate person to begin using.
Also quote from wikipedia about its intended purpose.
" SketchUp debuted in August 2000 as a general-purpose 3D content creation tool and was envisioned as a software program "that would allow design professionals to draw the way they want by emulating the feel and freedom of working with pen and paper in a simple and elegant interface, that would be fun to use and easy to learn and that would be used by designers to play with their designs in a way that is not possible with traditional design software. It also has user friendly buttons to make it easier to use." "
I had just started architecture college then, we did everything on paper, I only learned Autocad during my 1st summer job. 'Computers' were more the realm of architectural technicians back then, I didnt know any architects who could use any 3d modelling software at all. Architects were generally quite computer illiterate, Sketchup was a program simple enough for a computer illiterate person to begin using.
Also quote from wikipedia about its intended purpose.
" SketchUp debuted in August 2000 as a general-purpose 3D content creation tool and was envisioned as a software program "that would allow design professionals to draw the way they want by emulating the feel and freedom of working with pen and paper in a simple and elegant interface, that would be fun to use and easy to learn and that would be used by designers to play with their designs in a way that is not possible with traditional design software. It also has user friendly buttons to make it easier to use." "
Unfortunate. So many of the comments here seem to miss the point and this is a theme I have noticed through my career as a developer.
Yes, every button on a calculator is eventually needed by someone as are every optional concern in every application, but every optional concern is not needed by everybody and certainly not frequently.
Selectivity of desired features is a bias. The inability to account for bias in product design makes for shitty products that are either excessively complex or excessively expensive.
All terrain tires that are extremely safe for driving in snow are great, but I don’t need that living where I do since it almost never snows here. It is an unnecessary excess that I certainly would not want to pay for. For me this is no different than the tan button of a calculator which I have also never needed.
The inability to perceive or account for bias, as evidenced by the comments here, are why many employers are hesitant to elevate developers to product management positions, which is another form of selective bias.
Yes, every button on a calculator is eventually needed by someone as are every optional concern in every application, but every optional concern is not needed by everybody and certainly not frequently.
Selectivity of desired features is a bias. The inability to account for bias in product design makes for shitty products that are either excessively complex or excessively expensive.
All terrain tires that are extremely safe for driving in snow are great, but I don’t need that living where I do since it almost never snows here. It is an unnecessary excess that I certainly would not want to pay for. For me this is no different than the tan button of a calculator which I have also never needed.
The inability to perceive or account for bias, as evidenced by the comments here, are why many employers are hesitant to elevate developers to product management positions, which is another form of selective bias.
I think bad products do either too few things adequately or many things badly. Good products either do a few things well or many things adequately. Great products, on the other hand, do many things well, by appearing to do fewer things. Additional features are designed, in great products, to be discovered as you need them.
This is a religious debate. Some people are delighted by additional features, others by thoughtful design. It’s hard to see the other viewpoint and how this can be mutually exclusive.
> Some people are delighted by additional features, others by thoughtful design.
UX designers in particular are delighted by thoughtful design. You want to avoid an "inmates running the asylum" kind of situation.
UX designers in particular are delighted by thoughtful design. You want to avoid an "inmates running the asylum" kind of situation.
Some are delighted by fads like minimalism. You should keep those people as far from design as possible.
Others prefer better looks over function. See above.
Others prefer better looks over function. See above.
If you don't mind, here is my personal angle:
"In reality, great products do a whole lot, while providing a helpful, intuitive and somewhat shy interface. In this way, they allow to achieve solid results for complex problems in no time.
Customers who are lucky enough to interact with such product at least once in their life often describe it as being simple and even magical.
But do not let this fool you. Simplicity and magic do not equal to the lack of functions or settings.
Great products get the job done. They do it in timely fashion. They do not brag. They do not ask you to sign in. The do not put you through myriads of advertising. They do not overcast nor crash customers' lives by their own egos. They just work."
"In reality, great products do a whole lot, while providing a helpful, intuitive and somewhat shy interface. In this way, they allow to achieve solid results for complex problems in no time.
Customers who are lucky enough to interact with such product at least once in their life often describe it as being simple and even magical.
But do not let this fool you. Simplicity and magic do not equal to the lack of functions or settings.
Great products get the job done. They do it in timely fashion. They do not brag. They do not ask you to sign in. The do not put you through myriads of advertising. They do not overcast nor crash customers' lives by their own egos. They just work."
This might be a bit of professional bias on my part but I like to think of product-market fit using ideas inspired by information theoretic model-data fit:
Low resolution fit: The product vaguely and simply fits its market.
High resolution fit: The product is complex and is tightly tailored to the market.
Overfit: The product is so tightly tailored to some users that it only fits well a small part of the market.
Underfit: The product is so generic that it's easy to copy or is missing important features.
Then it becomes about trying to achieve optimal fit. It's almost a bayesian thing in my mind. You want a product or platform that is not overfitted, not underfitted, high resolution where it needs to be, low resolution otherwise.
There is one more dimension I find useful which I will call "crossfit" because it is inspired from the concepts of cross entropy (https://en.wikipedia.org/wiki/Cross_entropy) or KL divergence (https://en.wikipedia.org/wiki/Kullback%E2%80%93Leibler_diver...).
Having bad crossfit means that the product fit is biased in some suboptimal way. It might fit a side market of a greater market, it might focus on aspects that would be more important in another market or it might use a design language that is better tailored to different users.
Having bad crossfit often happens when product teams with expertise in one domain apply their knowledge to a second domain without being sufficiently familiar with the differences. Without taking into account differences in key details of the new domain, without learning the new lingo or without properly weighting the different levels of importance of challenges, product fit tends to end up not quite right.
An extreme but common example is that of software developers (like myself) designing interfaces that are very difficult to use for anyone but other software developers. However, it can also happen in subtler ways even for experienced product designers when they jump into a new field they are not very familiar with.
Having good crossfit is about learning to speak the language of your users.
Low resolution fit: The product vaguely and simply fits its market.
High resolution fit: The product is complex and is tightly tailored to the market.
Overfit: The product is so tightly tailored to some users that it only fits well a small part of the market.
Underfit: The product is so generic that it's easy to copy or is missing important features.
Then it becomes about trying to achieve optimal fit. It's almost a bayesian thing in my mind. You want a product or platform that is not overfitted, not underfitted, high resolution where it needs to be, low resolution otherwise.
There is one more dimension I find useful which I will call "crossfit" because it is inspired from the concepts of cross entropy (https://en.wikipedia.org/wiki/Cross_entropy) or KL divergence (https://en.wikipedia.org/wiki/Kullback%E2%80%93Leibler_diver...).
Having bad crossfit means that the product fit is biased in some suboptimal way. It might fit a side market of a greater market, it might focus on aspects that would be more important in another market or it might use a design language that is better tailored to different users.
Having bad crossfit often happens when product teams with expertise in one domain apply their knowledge to a second domain without being sufficiently familiar with the differences. Without taking into account differences in key details of the new domain, without learning the new lingo or without properly weighting the different levels of importance of challenges, product fit tends to end up not quite right.
An extreme but common example is that of software developers (like myself) designing interfaces that are very difficult to use for anyone but other software developers. However, it can also happen in subtler ways even for experienced product designers when they jump into a new field they are not very familiar with.
Having good crossfit is about learning to speak the language of your users.
This is a pretty interesting view, probably could be operationalized for web sites and apps with analytics data.
Article doesn't say anything new. It seems like a headline you send your boss because you want someone else to say the obvious.
That's what a lot of these articles - and a lot of consulting business - exist for. In environments with lots of internal politics, external validation is valuable for both credit and CYA reasons.
Great products appear to do less. Products should be composed in a way that allows them to do more while appearing to do less.
> The ones you use everyday, as a customer. Twitter, Lyft, Venmo, Slack.
Somehow I am living in a different world. I don't use any of those services on a daily basis. Actually, Twitter is the only one I come across sometimes when someone links/embeds some tweet.
Somehow I am living in a different world. I don't use any of those services on a daily basis. Actually, Twitter is the only one I come across sometimes when someone links/embeds some tweet.
There is a notion of feature death with products but to improve retention you do need to keep shipping out new features so I disagree here.
It feels like this article is piggybacking off the minimalism advocated in design schools. Minimalism is not the same thing as throwing out or ignoring features. How does the author reconcile their thesis with the fact that they're suggesting ignoring customer suggestions?
The attitude of if it ain't broke don't fix it is really you asking to be crushed by a competitor.
This said, the caveat here is when it comes to ideas. Better approaches to solving a problem are often simpler or more elegant, and require an out-of-the-box approach.
It feels like this article is piggybacking off the minimalism advocated in design schools. Minimalism is not the same thing as throwing out or ignoring features. How does the author reconcile their thesis with the fact that they're suggesting ignoring customer suggestions?
The attitude of if it ain't broke don't fix it is really you asking to be crushed by a competitor.
This said, the caveat here is when it comes to ideas. Better approaches to solving a problem are often simpler or more elegant, and require an out-of-the-box approach.
This is very timely advice for me. It sounds very easy in theory, but in practice it's been very difficult when you have lots of customers and leads pulling you in many different directions.
On the other hand, you can always have a distinction between products and companies. Especially when companies acquire other companies, just to add one more product to their portfolio (e.g. Google, Facebook.)
So no-one is saying that a single company can't work on multiple products at the same time. Sometimes it's just not very obvious whether something should be a feature or a separate product with it's own brand, landing page, and pricing.
On the other hand, you can always have a distinction between products and companies. Especially when companies acquire other companies, just to add one more product to their portfolio (e.g. Google, Facebook.)
So no-one is saying that a single company can't work on multiple products at the same time. Sometimes it's just not very obvious whether something should be a feature or a separate product with it's own brand, landing page, and pricing.
This article was written with full fallacies. One example of this logical fallacy is because it doesn't count that features are done based on KPI. It's not about adding nonsensical features, it's about to increase KPIs, therefore, make even more business. Also, this rule doesn't apply to all products, so it's a fallacy. People who downvote this just doesn't understand or never carried a business seriously. They're just hedonists on design. That's all.
Hmm. So the device in your pocket that replaces a cell phone,radio,camera,flashlight,computer,pager calculator,day timer, music player and more is not the perfect counter example?
Actually, I don't think that it is, as it does few of those things particularly well. In fact, this is a large part of why I've decided to stop using smartphones and to start carrying both a feature phone and a handheld computer instead.
Me: "I am selling this product that does X very well"
Prospect: "Does it do Y and Z?. If it can do Y and Z, I will buy it"
Y and Z is different for each and every client. That's how products becomes bloated. It is demand from real world clients that demands features to be added before they can buy your product.
Y and Z is different for each and every client. That's how products becomes bloated. It is demand from real world clients that demands features to be added before they can buy your product.
Has anyone used Notational Velocity / nvAlt? I've been reading about it all day (longingly -- sold my Mac a while back), and that's why this headline jumped out at me. I have tried dozens of apps and haven't found anything that even comes close.
Google Search is a good example of this. But this isn't always true. WeChat and Facebook can be considered as counter examples.
Nowadays, I come to think of it as 'Google Search' was a good example.
Back in the nineties, it was a very simple page, but today, there is all sort of clutter on that page. It starts with the privacy layers, goes on with the location bar (plus other bars) and goes on with all those boxes in the results (not even talking about ads). I mean, yes, some are truly valuable, but somehow the page doesn't feel as clean anymore as it used to be.
Back in the nineties, it was a very simple page, but today, there is all sort of clutter on that page. It starts with the privacy layers, goes on with the location bar (plus other bars) and goes on with all those boxes in the results (not even talking about ads). I mean, yes, some are truly valuable, but somehow the page doesn't feel as clean anymore as it used to be.
[deleted]
Ok let's apply this to phones. How could a phone without a rich app ecosystem become "great"?
It wouldn’t, because, I would argue, a modern phone serves as an API to apps, and all of its “features” are a necessity to facilitate its main feature, the apps it serves up.
Some must be integrated to provide those APIs effectively (eg store, file storage), but the rest that are provided by default I would consider separate products, given that they are discrete, often easy to remove, and easily replaced by 3rd party apps.
Some must be integrated to provide those APIs effectively (eg store, file storage), but the rest that are provided by default I would consider separate products, given that they are discrete, often easy to remove, and easily replaced by 3rd party apps.
Most people use less than 10 apps on their phone.
And it is a different 10 for each person.
And those 10 apps change over time. Heck I only use trip planning apps a couple times a year, but I wouldn't buy a phone that didn't allow me to use one at all.
And those 10 apps change over time. Heck I only use trip planning apps a couple times a year, but I wouldn't buy a phone that didn't allow me to use one at all.
Sounds easy but its really hard to do, and yes I agree with the concept
[deleted]
Wow, is it enough to read the title?
Fallacy.
Our customers would not accept not having some features because the fewer features are so great. Nope. They need many features, and have complex workflows, that's how it goes.
This doesn't mean that the features you offer shouldn't have a clear purpose and be easy to use.