Great products do less, but better
uxdesign.cc
uxdesign.cc
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.
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.
Calling SSO, audit logs and RBAC "cruft" in a business setting might not exactly inspire confidence in prospective customers.
I'm bookmarking this for future reference, both to use it for side projects and to study.
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.
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.
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?
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"?
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.
Well… all of them. I may not need tan every day, but when I do, I need it to be there.
Not everything is a todo list app with rounded corners.
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.
I highly doubt Airbus will produce a commercial airliner with a big red “fly to destination” button. (Though I’ve been wrong before)
This attitude is how you get Macbook "Professional"s whose keyboards stop working in 2 months.
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.
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 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.)
Minimalism just for the sake of it doesn't end well.
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.
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...
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.
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.
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.
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.
(Joe Spolsky wrote about it in the past; lack of vendor lock-in was crucial for it winning the market in the early days.)
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.
The fact your user understands their requirements better than the designer doesn't mean that the user is a better designer. If only.
tan x = sin x / cos x
cos x = sin π/2 - xDo not listen to those pesky customers who whine they have to press "+" button lots of times.
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.
Hard to apply that to a physical calculator I suppose.
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.
IRC hardly does what it does well.
(Not Outlook, not Gmail, these are super loaded with features.)
> 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...
I am pretty sure modern IDEs are quite configurable. Why not word processors?
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
A simpler product might serve my needs, but this is one I've used for years and understand well (and works with existing hardware).
Solving fewer problems, better makes for a great product.
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.
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.
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.
Removing features can eliminate a customer or two.
Unfortunately feature bloat on a simple device often results in making things no longer easily discoverable. (I'm looking at you, force touch.)
(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.)
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 key on that alternate layout is tan^-1.
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://github.com/sharkdp/insect
There is a web version available as well: https://insect.sh
Alt-2 (for Scientific mode), Inv, Tan
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.
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)))
)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.
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.
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.
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.
Great products don't have to be spartan. But in my experience they do seem to be intentional and value craftsmanship.
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 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.
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.
...
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.
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.
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.
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." "
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.
UX designers in particular are delighted by thoughtful design. You want to avoid an "inmates running the asylum" kind of situation.
Others prefer better looks over function. See above.
"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."
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.
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.
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.
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.
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.
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.
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.
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.