A little louder, a reminder:
"Good UX" mostly means "I've seen this before."
Have you ever seen an adult without your cultural baggage approach a doorknob for the first time? They'll start by pulling it, then pushing it. There's nothing "intuitive" about turning a round doorknob. But you've been trained, so you don't even notice.
"...but Apple, but the iphone", the iPhone was never "easy to use" or "intuitive". They bombarded TV with training videos disguised as ads for 6 months pre-release.
"You just point and click and drag everyone knows that" you spent hundreds of hours training to "just" point and click and drag, but you didn't call it training, you called it solitaire and minesweeper.
You practised.
Today, if we want a better user interface for any computing - and I think we do, and it's possible - we have two choices. Entirely 100% new - clean-break, fresh-start new - tech or to acknowledge and own that we're going to spend some time fighting reflexes honed over decades.
This is not an "it's the user's fault" or "it's never the user's fault" argument. There's not "fault" here, there is responsibility. There's an implicit social contract in computing, in navigating change that matters when we are using the tools we rely on.
Change is an _accessibility problem_ that demands assistive technologies to navigate, and building that tech is the responsibility of the developer.
"We put a 2nd floor on your house", great! "Climb a rope to get there", excuse me what.
The biggest own-goal I've ever experienced in this space was Windows 8.
Extremely Late Hot Take: Metro was Actually Pretty Good.
But the thing they bungled, hard, was making the Win8 changes _accessible_.
If you didn't see the first-run "swipe from off the screen" training montage, all the reflexes you might have from a phone or iPad were all 100% wrong and did nothing.
The first time I sat down in front of one of them it took me an hour to figure out how to log in at all.
And... not to put too fine a point on this, but I have been computering for a very, very long time. I have Seen Some Shit And I have Fixed More Than My Share Of That Shit. I am Quite A Bit Better Than OK at solving the problems that live near computers.
And it's been a long, long time since I've sat down in front of any computer of any kind and felt that helpless. Like I didn't even know where to start. Decades.
And making people feel helpless is the cardinal sin of UX design.
Anyway, I think there's been a generational shift in developer's perceptions of their obligations to that social contract and that it's made this industry substantially worse. The belief that "everyone knows" how to use the computers that are everywhere now has meant that nobody believes they need to, so nobody bothers, keeping training materials and docs up to date.
So developers think the costs of change are zero, because it's only the operators that bear those costs fully and invisibly.
Like, Windows documentation once upon a time was world-class, it was on-device, available at any moment and excellent. Today "Help" is a hyperlink to trash.
On a modern Mac, you can ask a question and get a few 'maybe' bullet points for your trouble. On System7 - the _stone_ age - the _OS would walk you through each step_ of solving your problem. It would say, click this thing and then draw a little circle around the thing. Apple's reputation comes from this period, when nobody was ever afraid.
Just to add one last note to this:
One of the major disconnects I've seen in my career between engineering and UX/UI design is rooted in this misconception.
The Engineers asks: we made a new feature, it does these new things, can I have a button for this new thing?
The design team hears: We want an applied anthropology research exercise. If our product has an international audience, it is fifty or two hundred research exercises.
What the Engineer thought they asked for: a little picture.
You can see how both sides of this conversation find the other side frustrating to deal with.
Engineers believe they've solved a major problem, and now "just" need a tiny label to make that solution discoverable.
Interface designers believe that "just" having some new ideas is the easy part, but making new ideas legible and discoverable is a major problem.
Both are correct. But one of those domains is... let's say far less prone to the practice of humility than the other.
i think jenn schiffer's 2014 talk about how "your grandparents probably didn't have node" helps put a lot of things into perspective for the farthest-flung version of this problem -- developers assuming their audience is only developers. but in a world where the UX designers at the tech megacorps are constantly pushing quarter-baked overhauls and paradigm changes out into the world... unlike the old world where Windows and Mac were teaching the user some of the fundamentals, the platform is often more of an adversary nowadays. we can't assume that even developers aren't having their 'struggling to use windows 8' moment, let alone people who can't devote so much time to staying familiar with the ever-changing interfaces on their featureless squircle-screen. but as long as participation in society demands these dangfangled machines, it's our responsibility to make learning them worth the investment.
i think a lot about unobtrusively tutorializing the human-computer-interactions we take for granted, from the perspective of game development. it can feel unlikely, perhaps even embarrassing, to consider that your own app could ever be the first thing of its nature that a person has ever seen -- but you can't assume that it's not!
take for example the three-week free-time project my friends and i submitted to a game jam last year, a 2D platformer for the gameboy advance ("getting around it with pheasant birdy"). as soon as i felt it growing in scope from 'tech demo' to 'playable game', designing and implementing a tutorial subsystem immediately became a non-negotiable feature to me, and was one of the first things i worked on once i had the basics of the engine in place. naively, one might think that the demographic of "people who own GBA flashcarts/emulators and download homebrew game jam entries" wouldn't need to be taught "press ➡️ to walk", "press 🅰️ to jump", "press ⬆️ to climb", since those would be obvious fundamentals to anyone who's played any game in the tradition of super mario bros within the past four decades, and surely cutting that scope on such a time-limited project would let us make the rest of it more substantial... and that may be true, but what about the parents/coworkers/etc. of my dev team and me, some of whom never touched anything video-game with their own hands after playing a few rounds of pac-man/tetris/galaxian in the 80s and deciding games weren't their cup of tea, or younger relatives whose experience of gaming are primarily mobile gachas? (we even embedded a javascript-based GBA emulator on the game's page with a special build of the ROM that replaces the button icons with keyboard keys -- many people we'd want to share it with don't need to know how to download and use an emulator.)
we sorely need to instill a patient, empathetic, noone-left-behind mindset in our development cultures. this probably means we have to re-educate a lot of arrogant technocrats who think "patience? teaching? isn't that what the chatbot we added is for?"
mhoye
jack
Torge Rosendahl
Peter Brett
Uwe Caspari
liffy 💜