Being a developer, I'm one of the main points of contact in my family whenever a relative can't figure out how to do something software-related, and boy has it been a sobering look into the future.
I recently helped a relative file for unemployment verification through ID.me, which is a popular identity verification platform. My relative, who is not well off financially, had an old phone that didn't play nicely at all with the ID.me verification flow. I spent an hour trying to get my relative signed up and I never could get it to work. The site was barely mobile-friendly, and the photo upload process kept failing, which was a required step for verification.
It was so Orwellian to see this kind of UX on a device that wasn't new (and of course, how is someone on unemployment expected to purchase a new phone?) I truly wonder how many people have starved because they didn't have access to devices that allowed them to collect their unemployment through this platform. It really kept me up that night.
I eventually borrowed a friend's phone. It proceeded to stonewall me and insist I was not a real person, again with no visible error message or explanation apart from a strange oscillating blue 3D head... Kafkaesque doesn't begin to describe it.
It's indeed one of the weirdest modern tech phenomena: you are blocked/flagged/shadowbanned/what have you by an inscrutable AI and given no reason or explanation, just a blank "you have been banned".
The other option was to go in person to the local social security office, but at the time it was completely closed due to COVID.
Always seemed a bit odd to me, because I would have thought that even if the government didn't trust its own departments to validate government-issued documents securely (fair enough, actually, they'd probably leave it on a train), all they had to do is provide their own separate, secure, service. They say the government won't know who you're validating with, but why is that an issue anyway. At some point you have to trust the government if you're verifying your identity with their own documents in order to access government services.
Though I guess it's probably just because when they eventually do get hacked they can just blame the provider and ditch them publicly rather than have another IT disaster in the papers with their name on it.
People are often missing a lot of inherited context, like what the steps of the process are (for buying, insuring and registering a car), what the terms mean (all the different numbers and IDs).
Then it gets messier. Immigrants have to get everything at once: papers, permits, certificates, IDs, accounts. All of them depend on each other, and most of them take weeks to get. People need an income now. A big part of my work was to disentangle a few catch-22 situations around residence permits, bank accounts, apartments and health insurance.
I've talked to a few employees at the immigration office, and since all of them are native to this country, they seemed surprised that a whole Facebook community was dedicated to navigating their office and its requirements.
The same problems apply to tech, but it's worsened by the fact that the builders are well-paid people in developed Western countries, but the users can be anyone, anywhere.
Here's to hoping that neither you or I ever become that irrelevant, because that doesn't look like a pretty existence to me.
It may be disheartening to hear, but this is by design. A (Western) government cannot get away with entirely not providing or dismantling basic elements of a social safety net (unemployment insurance, healthcare insurance, disability assistance) for publicity reasons... but what perfectly works is to make the system as complex and hoop-jumping-dependent as possible to reduce the number of claims:
- requiring modern devices (or not making sure that older devices work too, like you witnessed) is a major hurdle many people who are too poor and under-served by libraries or other public Internet access
- requiring in-person presence with short opening hours during weekdays discriminate against people who have to take care of sick relatives/children, have to work two or more jobs or have certain mental health issues that make following up with appointments very difficult (e.g. some of the strains of autism)
- requiring specific forms of ID or other paper documents (e.g. birth certificates) can be almost impossible (or, very expensive) to solve for people who have lost their belongings/are homeless
- requiring proof of residence is an automatic exclusion of the homeless
- complex forms with bureaucratic language discriminate against illiterate people, non-English speakers and frankly, most people who don't know or can't afford a lawyer to help them out
- automatically rejecting the first claim and only allowing after an appeal / a lawsuit is commonplace for disability claims, it is very effective in "weeding out" poor and already troubled people
The ones that do not require a lot of bureaucracy are not governments... the void that helps those left behind by governmental bureaucracy is more often than not religiously affiliated: churches, Salvation Army, other charities - but unlike government (which is theoretically bound by constitutions and anti-discrimination laws), they are free to choose whom they help and how much.
And now: good luck if you're a publicly outed LGBT member, a person of color or otherwise marginalized person right in a religious-conservative stronghold. The government won't help you as you can't jump the hoops that were designed to be that way, and the "private sector" won't help you as you are not mainstream conformant. This threat is what makes dysfunctional government bureaucracy so insidious.
thou, shifting the "navigation of service meshes" away from buerocatics, law literacy and ppl-skills to proficiency with electronic devices has done little for the kafkaesqueness.
Access to government services should be a right accessible to everyone, not just the select few that can jump through intentional hoops!
State Departments of Labor have access to extensive consumer data and are unable to utilize it effectively. ID.me shouldn’t exist.
Speed: Search-based puts a floor on how fast an interaction can be. "Button Syndrome" interfaces are a slow "hunt and peck" for new users, but experienced users can use them extremely fast, building up muscle memory so they don't even need to consciously think about the action they're taking. Imagine piloting an F35 with a search-based interface.
Discoverability: Buttons make it explicit what functionality is offered by the product... somewhat. Users may not know exactly what a button does, but they can make an educated guess based on labeling and context, and it gives them a jumping off point to experiment with it or find it in the documentation. With search-base interfaces, there's no natural way for a user to discover functionality they aren't aware of. Worse, a user may remember a function exists but forget the terminology, flailing in the search box guessing different terms.
This is not to say search-based interfaces are bad. There are mitigations to the downsides (the article mentions a few, like search suggestions), plenty of upsides to go along with it, and let's not pretend that button-based interfaces are all sunshine and rainbows. I only mean to say that these are things that should be considered.
I think the broader takeaway of the article is: Always be thinking holistically. It's important to consider how your users interact with your product as a whole, not just the individual features. Also important to consider how different users of varying experience with the product and the domain will feel with the UI—Often features for "power users" come at the expense of new users or vice versa.
Each search is an opportunity to build experience needed to use search less.
The buttons are there for those who want to run fast and or efficiently.
Doing that well is a lot of work, but it also delivers high value.
Going search only can be super lean, which has to be compelling. Everything costs something though, and the cost here is no user becomes adept. There is a permanently fairly high Ccost of interaction.
This is how MacOS X's help menu search box has worked for over a decade, and it's brilliant. Type in a search and it shows you every menu item that matches, and rolling down the list shows you live where each menu item is.
I wish Spotlight search was similar - showing paths more readily, and making it easier to open the folder that contains the item that you want to look at.
That concern won't apply everywhere, but it's worth keeping in mind. Even when my interactions with a simple menu are recorded (for analytics/profit) and reported the amount of data they get is at least limited.
I would not be surprised if newer fighter interfaces are already customized for the pilot in this way.
> It isn't just us, here's Office 2003.
> [image]
> Here it is after the rebuild.
> [image that is similar, but on a narrower screen]
> To understand why - and to find a solution - the history of software is helpful.
Step back. To understand why what? To find a solution to what?
In particular, I think it's strange to compare the F-16 with the F-35 when the former is regarded to be one of the best fighter jets ever made and the F-35 is infamous for being problematic. My understanding is that they are also different kinds of planes for different purposes, but at any rate, I struggle to focus on UX when there's that contextual elephant in the room.
Also bringing up fighter jets in general might not be the best comparison. A fighter pilot is about the farthest thing from a casual user of a fighter jet. My understanding is they're intensely dedicated to knowing how to operate it effectively, to the point of muscle-memorizing menu navigation button-presses to quickly perform different actions (e.g. memorizing something like the Konami Code to fire a particular type of missile).
So they're almost certainly not like the users of whatever web app your building, so maybe it's not the best idea to let a photo of their controls inspire your UX.
Back in the 80s, the earliest Mac interface guidelines said something to the effect of "eschew modes". There were lots of reasons for that. Some argue that as more people are familiar with computers, it's reasonable for the standards of good design to change.
But. Gigantic numbers of buttons are kind of a consquence of avoiding modes.
I don't think I need to reiterate all the bad things about modes, because quite a few were mentioned in the article, including life and death situations with military aircraft.
Quote: "segment our interface into a much larger number of smaller pages, each of which serves a specific function" - those are modes!
There's no right answer, and the article covers a lot of the ground, but I think the end of it is unbalanced, because it's fundamentally about a duality with no resolution, where intelligent people have argued for the opposite of the final advice.
There's nothing really wrong with the article, except it avoids the keyword that connects to significant history that shows both sides have merit. "Mode" is not used once.
The older I get, the more depressing it is when I see someone rediscovering something without recognizing it.
Later, the same man will be seen at conventions, meetings and workshops, extolling the virtues of his system, the “power” of which can be measured by the great number of commands it can execute. I believe this is usually a fallacy and users should recognize it as such.
— Jacques Vallee, The Network Revolution: Confessions of a Computer Scientist (1982) chapter six, Obfuscatology (https://books.google.com/books?id=6f8VqnZaPQwC)
To particular pieces of software has lost a lot of their utility for me thanks to dumbification:
- Google I have now given up. It was equally dumb as DDG when I last used it and the only reason I sometimes fell back to it was to see if it randomly provided a useful result.
- Firefox is still the best for me but is a shadow of its former self. I'm eagerly waiting for a fork and on Mac I have already switched to Orion which has built in vertical tabs, can fix ctrl-tab and support both FF and Chrome extensions. (My main criteria is: 1. works great 2. not Chrome- or Chromium-based)
You can have an "advanced" (whatever it may mean in context) system which fits into the first two categories, which is very useful to remember. Something I like is command prompts in the style of emacs accessed via M-x and similar shortcuts (or in VS Code, which many more people are familiar with). These permit discovery of new commands and activation of commands without overwhelming the UI. They can also "teach" the user, by providing information like what the keyboard shortcut actually is for activating it. Contrast this with something I've seen in many desktop projects (especially ones targeting a smaller number of power users, versus a more public system distributed to a broader user base): menu hell. All those same commands are still there (maybe), but buried in menus with submenus with submenus. Even though a command may logically appear in multiple places, it probably only appears in one. They may not even appear in a logical place, but just a conventional one, like search commands showing up under "Edit".
It reinforces the story even better than the given examples and has been there since Office 2007. The web version just added search-for-command in the right-click menu as well, which is similarly powerful.
This seems to be called the “mini toolbar”. Very hard to Google, easier to find through use. It is in Outlook for web now, too. The version in word is more powerful, especially when working with tables.
I googled it - but that only led back here!
I've been getting back into DCS recently, and one thing that's struck me with the A-10C (II) is just how incredibly resilient the entire design is.
Sure there's a lot of work starting the aircraft and setting up systems etc, and there's an immense learning curve, however you have a staggering amount of redundancy in case of failures, in all levels of the aircraft design.
As a consequence, pilots have been able to limp home ridiculously damaged planes, surviving to fight another day and go back to their children.
Then there's the F-16. I've only just begun to scratch the surface of this one, the simulation is equally as amazing as the A-10C. This aircraft is likewise very manual, but if something goes wrong the pilot has immediate control; in the F-35 (from what I've read) he would be completely reliant on the glass/ computers working as intended / desired, with a level of complexity that makes Tesla's entire FSD program appear as basic calculus.
That's perhaps a big tangent to computing, however I strongly feel that simplifying everything might take away more than you add. The best designs would combine quick, express usage functionality with expert panels for advanced, expert users/usage. This should be combined with a transparency of design that allows their users to understand the underpinnings.
true, but usually not the limiting factor.
more to the point; money is a finite resource if the product is intended to generate a profit.
Give me panels that I can open, close, and arrange as I see fit. Let me craft the interface of your complex, featureful program into something that matches what I need most often. Pick a simple set to expose to new users that covers the basics, sure, great idea. But let the skilled user tell the program exactly what sets of knobs they want to have handy.
If you look at the Navy, there have been several mishaps that have been blamed on poor electronic controls.
In addition, and likely more importantly, a fighter pilot trains for hundreds of hours in their cockpit. They develop muscle memory. Having a button at the same place, with the same feel, that does the same thing, is likely vital when you are engaged with an enemy fighter and don't want any extraneous distractions. Instead, it seems you have the cockpit version of Apple's Touch Bar.
I don't trust your integrated search feature to understand what I want, and in any event, I rarely feel like playing a game of Zork to get my work done.
Please use buttons, clearly labeled in English (if not the user's native language.)
Looking at your screenshots, you pretty much had it right the first time.
Add that to the fact that all user tests we've done have fared better with search and more verbose interfaces, and I wonder if we are both of us far from the target user profile.
> Application error: a client-side exception has occurred.
But from the other comments I get the impression that “button syndrome” has something to do with UX/accessibility. Tad ironic.
Usually well intentioned founders who know what they want to achieve, but fail to understand the subtleties of designing UI's and interaction. Or developers who sometimes lack the viewpoint of a "regular" user.
In most cases hiring a good (interaction/ux) designer can solve this pretty quickly.
Maybe a bit pretentious but it does kind of state it nicely: "To complicate is simple to simplify is complicated. Everybody is able to complicate. Only a few can simplify." - Bruno Munari
I see a lot of products these days using more of a hybrid approach. Some of the most basic buttons to get new users used to the product and discovering what it can do. Then adding in a CMD/CTRL + K search menu for when users reach a better understanding of the product and just need to get shit done.
There is a fine line between too basic and too advanced (depending on the audience for your product) and a challenging thing for most UXers is balancing new user onboarding against the power users of your product.
"Well, the documentation says this takes key X, but it doesn't work if I send key X, I have to send Y"
"This service seems to break when this JSON comes back down a second time".
"I press this button and it shows it being clicked, but it just locks up for 5-10 seconds before finishing the click. That's a really bad user experience. I'm surprised companyX doesn't seem to understand that's confusing to people."
And on and on. After... years of these observations, I pushed back a bit with "I'm surprised you continue to be surprised by any of this. You've worked in software for years now. You should probably be surprised that anything works and continues to work."
A system continuing to work between various client/browser versions and system upgrades over a period of years, serving multitudes of users, with as little downtime and no data corruption is really... surprising in these modern times. It shouldn't be, but there's so many moving parts, so many players, that long functioning services do surprise me.
A recent bank merger meant that two regional banks are merging. A recent mortgage refinance meant that this newly merged bank also bought my mortgage, and I'm supposed to make payments to them. Their system for setting up a mortgage payment is broken. Like.... errors in dev tools console, with relatively obvious root cause as in a field like CustomerId is referenced in another part of some code as CustomerID, and when I try to click X to move forward there's breaking JS code.
This was a problem for at least 5 weeks that I know of, but from the little I could see via twitter and forums, weeks before that. There is 0 way of me contacting anyone who could even understand my issue in the first place, and that's a whole other topic. That they likely didn't have monitoring in place (I couldn't see any obvious tools such as sentry installed) is another story, but... I didn't chose this bank. I don't have a choice in using them (same with regional utility companies, etc).
I haven't really felt in control of software since.
