They measured over 4,000 pilots on 140 different dimensions. The hope was that they could design to the average pilot. What a Lieutenant named Gilbert Daniels found was that even if you only looked at the 10 most important dimensions, not a single actual pilot was within 15% of them all. Even just a handful of dimensions would fit almost no-one.
The consequence of this was that everything became adjustable.
Compare https://www.gwern.net/Backstop
Basically, war (or the threat of war) is what keeps militaries honest.
Competition and the threat of bankruptcy keeps companies on their toes.
Evolution keeps brains honest.
But those forces are rather blunt, so the day to day optimization has to proceed by other means.
For example, just for humans a big, big driver of instability in the last few millennia has been other human brains.
Also keep in mind that (in-)stability and harshness of environment are too almost independent dimensions; if you see instability as something like the variance of outcomes.
Eg if some new opportunities open up, everything is strictly better (so the environment is less harsh), but variance might shoot up dramatically, perhaps because only the clever and resourceful can make use of the new opportunity.
Evolution only suffers brains to exists, if their advantage outweighs their costs. (Though keep in mind that the example I gave is a bit broader than just brains: any way for an organism to learn would fit the bill. That doesn't necessarily need to be a full sized brain, if fewer nerve cells do the trick, too.)
Similarly, smart and resourceful leaders for your company are only useful if their advantage outweighs their costs.
In any case, read the linked Gwern article for a deeper discussion. I'm just rehashing the main point here, Gwern has more to say.
It really does not.
> Competition and the threat of bankruptcy keeps companies on their toes.
Only some companies and some of the time.
And from the article:
> One defense of free markets notes the inability of non-market mechanisms to solve planning & optimization problems.
s/notes/falsely claims/
etc.
> It really does not.
I meant 'honest' in the sense of suffering if they bullshit themselves too hard. Not 'honest' in the sense of dealing with third-parties honestly.
Could you expand on your point?
>> Competition and the threat of bankruptcy keeps companies on their toes.
> Only some companies and some of the time.
Maybe. And that suggests that one goal of public policy should be to subject more companies more of the time to these pressures. Eg by abolishing tariffs, lowering barriers of foreign companies entering local markets or buying subsidiaries; allowing WalMart to become a bank, and banks to sell coffee etc.
>> One defense of free markets notes the inability of non-market mechanisms to solve planning & optimization problems.
> s/notes/falsely claims/
Not sure what you are complaining about here? If you read the rest of the introduction, it's rather clear from context that the author agrees with you here. (You don't even need to read the whole article for that insight.)
Belief that the mechanisms cited actually work, or at least its prima facie plausibility, is necessary to gain buy-in from people making decisions.
Then came a wave of companies focusing on UX with great success, who often dropped settings to focus on "magic" functions etc. This means UX becomes correlated with less settings, but removing options does not help users - on the contrary! But unfortunately it gives the impression that settings are bad for UX.
There's also the problem of bugs. Software with more settings have more code paths. It's harder to test, and harder to refactor.
Should we do A or B? There are decent sounding arguments for both, so... let's dump that decision on the user, and move on!
My car has both a steering wheel and a separate indicator light control; rain sensors and a manual wind screen wiper setting; light sensors and a manual setting for the headlights.
Are these all examples of designers' inability to make decisions?
Often used ones aside options are generally so hidden away anyway and thus the choice of a sensible or popular default can be made regardless without complicating the main UX.
Often, the user don't even know what they want, and assume the default is the right choice, since it's "professionals" who have chosen it.
Though often still theyll be afraid to look around at settings for fear of breaking things.
> It's easier to add another option and the keep the previous behavior as default than to do the hard work of figuring out what the best behavior is and then, if the new behavior is better, having the courage to change the default. Having no options is good for discipline as it removes the temptation of doing it the easy way.
Ideally, you already knew what the trade-offs are before you built the feature. That should have come out of a user study. Human psychology simply doesn't change as substantially or as frequently as modern UX seems to suggest. Of course, things can fall through the crack and you can learn new things (even that previous conclusions were misguided). But, setting up all options as a choice you need to make for the user isn't necessarily helping the user experience. Some portion of the world prefers a 12 hour clock, some portion a 24. If you're adamant about only showing one of those and it's not configurable, you haven't helped the people with a different preference. You're inflicting your design on people without really taking their cultural norms into account. I'd go a step further and suggest changing defaults on people is something that should never be taken lightly because the user experience isn't a point-in-time thing. Changing workflows on existing users is a negative user experience in many cases.
As a concrete example, the ReasonML language forked into another language call Rescript. The code formatting tool in Rescript works almost identically to the one in ReasonML and that's by design, since it's supposed to facilitate migration. But, for whatever reason, the new formatter dropped the option to configure line width. So, if you used to set your line width to 120 characters, too bad. You have to use 80 characters or don't use the tool. Also, you need to chance your workflow and any configurations using the old flag.
Having the option to change a numeric variable is not some overwhelming burden. Forcing a fixed value isn't some courageous decision and it's not based on any human factors studies. It feels like an overreach of "opinionated software" that ultimately made my code harder to read (both languages use annotations that artificially increase line length). In the end I abandoned the migration, which I suppose means if they poll community members, they'll have something of an echo chamber.
> There's also the problem of bugs. Software with more settings have more code paths. It's harder to test, and harder to refactor.
This sounds like a failing of software engineering to me. To the extent that this field's raison d'être is to make computers perform work for humans with minimal fuss, our tooling should be geared towards supporting that goal. Dropping functionality that would be beneficial to people because it's more difficult to support sounds like trying to mold people to the machine rather than the machine to people. Certainly, you can have a product that functions, but it's similar to all the other things we have to put up with because a better option doesn't exist. This take isn't drawn from the book I mentioned, but I think the book has influenced my opinion on the matter. If settings/options lead to a better user experience but our tooling and development processes make adding settings/options difficult, we should try to improve our tools and processes.
With that said, we have to operate with the constraints we have. I just don't think we should convince ourselves it makes for a better user experience. That sort of thinking tends to snowball.
Nobody wants to admit they're a scientist who follows experimental data at cocktail parties. Everyone dreams of being introduced as a creative genius.
That yearning metastasizes into hubris, which ultimately leads to people making arbitrary changes, just because they can.
Which isn't UX's, or architecture's, fault as a discipline, but is to say that the scientific process runs perpendicularly to our egotistical, flawed selves. And that the only way to avoid it is constant vigilance and pragmatism about what's actually driving a change request.
Harking back to the survivorship-bias example above (reinforce warplanes in the bits that weren't all shot up on the ones that returned), if they define "community" as the users of the new language, they'll never realise line length was a significant problem: You and all the others like you aren't there to answer the question "Was line length in the code converter a problem for you?" with a resounding "Yes!", they'll get only "No" answers, and not realise what a huge impediment it is.
As they become more proficient with your product, if they can’t tweak behaviour in certain ways, they might consider changing to a different product. And that’s where settings become useful.
Yeah, I think the issue is that once you've finished designing an interface or your software is feature complete, the company is faced with a problem: You don't have any actual work, but you absolutely need to maintain your expertise and sales.
What features can you really add to Excel at this point? What do you do when your market analysis says your application and interface are about the best they can possibly be? What do you do with your engineers when your product is, by nearly all measures, complete?
This is the problem that Google search has. And Microsoft's Windows and Office teams. We had basically everything on lock for quite awhile. Changes now are seldom improvements. They're just changes to justify the engineers' salaries that the company has to keep paying because maintaining that is a core competency. Moving all of them to a new project spoils your expertise in your own product so you can't just do that.
At this point, UX design for these products should probably shift to aesthetics, much like the auto industry did. And that's largely exactly what Windows has been since Windows 7. Aesthetic changes.
Aren’t there actually lots of good features Microsoft added in say the last 19 years (office 2003 having, for this argument, a perfectly capable Excel with all the features)? Off the top of my head:
- Ribbon and context-aware toolbox made it easier for infrequent or novice users.
- good default styles for tables, which is what lots of people actually use Excel for
- Better support for actual tables (ie defined extendable ranges of cells)
- OFFSET/MATCH instead of VLOOKUP (maybe this was a culture change. Not sure when OFFSET or MATCH were introduced)
- improvements to default graph appearance (though I still dislike them for just showing the data)
- Lambda functions
- Relational models for data
- bigger spreadsheets
- flash fill(?) which is a magical programming by example thing
- fancy conditional formatting with colour changing smoothly with values
- possibly faster evaluation. I don’t know if it was actually improved
- maybe someday: collaborative editing
I’d like to point out that some improvements were made for power users and others for more ordinary users.
But did they have to make it worse for nonnovice users by removing the old menus and toolbars?
> - good default styles for tables, which is what lots of people actually use Excel for
An Excel sheet is already in and of itself a table.
> - Relational models for data
Yeah, thanks, we already have RDBMSes for that. Turning Excel into an RDBMS (or an RDBMS into Excel) only gives you a jackalope: Worthless both as a jackrabbit and as an antelope.
> - flash fill(?) which is a magical programming by example thing
You mean that thing that resolutely refuses to be useful whenever I try to get some "magic" from it?
> I’d like to point out that some improvements were made for power users and others for more ordinary users.
More like against power users in many cases, I'd say. (See the first point.)
Or at least they exist just fine in Spread32 which is a nice tiny spreadsheet tool that was first released in 1999 and born with Excel 4.0 compatibility target.
I believe it is more the "culture change" you mention, the "new" function is Xlookup, introduced recently:
https://www.powerusersoftwares.com/post/xlookup-just-killed-...
The option to not guess the format of input data as calendar dates comes to mind.
Excel is a product so complex I doubt it will ever run out of things to improve.
Yeah, sure, but why do they all have to be for the worse?
(Probably because it was already as good as it could get in that respect too. And then what do you do?)
Having too many options is a curse too however, so that doesn't mean that one should add options without thought nor that sane defaults are unimportant (in fact, they are extremely important). Like most good things in life, the solution is not in either extreme but in the golden middle.
I think it's sometimes appropriate to reduce options, mainly in cryptography libraries. There the library should provide all the secure options and none of the wildly insecure options, maybe with some "secure if used correctly" options behind some heavy warnings. Likewise for anything else that might similarly be used in safety-critical situations: it MUST be easy to use, and hard to misuse. That tends to mean having fewer options, and making very careful choices about defaults.
Allegedly Microsoft found out that the problem was that the features covered by that fraction were wildly different in case of MS Office. That is, any cut down, simplification, etc. would result in huge amount of disappointed users, because the used featuresets didn't really overlap outside of certain core. At the same time trying to package it into market segments might just mean you end up with too small niches.
I maintain that the Ribbon on office is this problem writ large: I'm sure Microsoft did a lot of user studies, and I'm equally sure that by averaging out all those results they managed to prioritise nothing useful to any actual business - hence why the product feels bizarrely unprofessional these days and is now impossible to configure to suit any specific type of writing.
AFAIK the research behind the ribbon showed that 1) there was no way to find features easily 2) Main menu was too cluttered and undiscoverable.
Of course if you actually found the features you wanted before that, it was a big negative change.
It could be nicer like intellij, but I suspect they hit some threshold of changing keyboard shortcuts and end user reaction.
If the search interface was what was missing, why the fuck didn't they just add that to the old menus and toolbars? (Seems to work on many Macintosh applications, doesn't it? And probably some Windows ones too.)
Of course a lot of applications later "embraced" Ribbon without all that preparation, and to be quite honest, I don't hear much complaints about Ribbon in Office - outside of nostalgia it's rare.
Many modern video games start by displaying such settings. The defaults probably suit most users just fine, but being able to easily scale UI text is probably very useful for people with poor vision.
Where things get murky and become a matter of judgement and data is whether you are exposing settings gratuitously and therefore just making things confusing, or whether you are not offering enough settings and therefore not addressing common use cases.
*There are actual laws that say those without disability must be supported, and I think companies should strive to meet those, but that's more of a moral argument
Carving out a niche when getting started is probably quite prudent. But, that doesn't mean it's a good user experience. There's a lot of retorts in this comment section about how any amount of settings is tantamount to total design failure. I think that's too reductive and I'm trying to reconcile that research on the topic.
This is a reasonable limitation. If you implement infinite features, you end up with a bloatware, so some features can't be implemented, and users should use something else.
The modern UX ethos seems to be that settings indicate a failing of the product and if people don't like the path laid out for them, they're either wrong or they can go use something else. I think the book also makes the argument that constantly breaking workflows isn't very user-friendly either, but SaaS products routinely change their UI and workflows around. I suppose I can see the business justification for that, but that doesn't necessarily make it good UX.
Of course, Norman could just be wrong or my interpretation of his text could be wrong. Either way, something feels off to me with modern UX. I suppose if you've run actual user studies (not just A/B tests), then you have more contextual data than I do. But, I came away from reading the book really wishing more software products (both SaaS and the recent spat of "opinionated" frameworks/tools) followed the principles he championed.