and why it doesn’t have to be
Year after year I see more companies investing in experience design and for every one of those years, I keep seeing unfriendly UX come out the other end. I see bad patterns, “dark patterns”, and outdated patterns show up in everything. They appear in just about any product. In my own projects, it’s a constant vigilance to keep them from appearing because I know to this day, it’s still difficult to keep them out.
You might ask, “Why is it so hard to keep bad UX patterns away? Isn’t that a core motivation of experience designers and researchers?”
The answer is: Bad UX is really cheap.
When you’re making software, the quicker and cheaper solutions are always sought after. They’re like gold. Everyone on a team is constantly panning for it, hoping to strike it rich. When UX people are hired and UX is being discussed by the team at large, it’s basically always in that context. Non-design folks are usually hoping designers will make or approve quick, cheap solutions. They’re hoping that just having designers on staff will just magically make the software more appealing without actually making it more expensive to develop.
Part of this is because often, the larger team equates “a good experience” with “pretty”. And pretty, well, you can just slap that on like lipstick on a pig. So fast and cheap!
UX is not understood or respected
Experience design is not lipstick on a pig. Too often designers are thought of as purveyors of pretty pixie dust, brought in to sprinkle on software as if it can make their customers believe their hideous beast appears to be a glorious stallion. Magico zappo, instant transmogrification!
“Pretty” is easy to think about for most people. It’s either pretty and you like it, or it’s not and you don’t. In that way it’s trivial, incidental, and maybe superfluous. It’s based mainly on opinion. There’s no objective truth in pretty. It’s easy to understand and approachable for everyone who can see. And because it’s so approachable — just about any coworker feels like they’re justified in critiquing and guiding it. It’s a dynamic we share with similarly approachable crafts like writing and illustration. They don’t realize that what they’re seeing is just the tip of the iceberg. They don’t realize they’re not qualified to dictate changes to all aspects of our work, based on their own preferences.
This is so boundless because our work isn’t obfuscated in mystery. Conversely, no one questions the work of software developers for example, because sharing a screen of javascript will make people in most professions feel confusion and dismay. If a dev, a lawyer, chemist, or mathematician says something has to be this way — everyone just believes them. If they says it’s impossible, no one argues otherwise. If they say a thing will cost 4 weeks of budget to do, no one tries to tell them how to do their job to make it cost less. But design is fair game. Remember its very nature is to be easily comprehendible. It’s no wonder the whole team can tell what a button is and tell you what they think about it for days.
Cheaper, worse patterns become design feedback.
Whenever a screen, button, transition, or anything threatens to be an expensive venture — team members go traipsing into design’s work — feeling fully entitled to suggest and even demand design changes. And most often those demands for a cheaper option are doled out without an ounce of doubt or hesitation. Why second-guess your demands when your concept of design is comprised of “pretty”?
You might argue that this is not the dynamic of every team and you’d be correct. Quite a few teams are not like this and hopefully less teams over time are this way. Hopefully more and more teams are realizing that experience designers have a special skill set and wealth of knowledge that goes far beyond visuals and does in fact take years of experience to hone — which is not shared by other professions. Maybe over time more organizations respect all of this and boundaries are not crossed.
So if this is not a problem in those teams, how can bad UX keep coming out of them as well? Why aren’t they immune? Why am I not even immune?
Bad UX is tradition
You might not realize it but unfriendly software experiences have a long and proud history. This is a lifespan that experience design does not share. Coding started (arguably) in the 1950’s but UX was only named in the 90’s. There were decades of interfaces being coded before anyone specialized in designing friendly patterns.
Many unfriendly patterns come from the very beginning. The password, the prompt, and the pop-up for example are found in the earliest apps and operating systems.
And why it’s cheap
These patterns were used all the time. They were used so frequently that software engineers put extra work into making them quick to reuse. These and many others were made so only one line of code needed to be written. A whole pop-up box with text, buttons, shadows, and whatever — just 1 short line!
With every new operating system, platform, and environment built on the shoulders of the last — these patterns and the short-cuts to implementing them were carried forward. From DOS to Windows to Web and VR.
- Want to make a pop-up dialog box today? It’s still just one line.
- Want to make a friendly alternative like a dismissible inline message? It’s usually a lot of custom work, re-inventing the wheel with dozens of lines of code.
- Want to make an even friendlier feature to replace a decision prompt like an undo history or caching unsaved changes? Say hello to hundreds of lines of custom code or customizing a 3rd party library to do what you need.
Since experience designers weren’t there in the beginning, friendlier patterns/features didn’t get invented. They weren’t there to be made cheap to implement and carried forward. They never existed until recently and so now they compete — unfairly — with the old, bad, cheap ones.
In the beginning, people did not choose software.
Back in those bad old days, UX didn’t exist because nothing spurred anyone to think such a thing might be useful. Software was created by engineers to fulfill a professional need and the people employed to operate the software were trained in whatever way was necessary to make it operate. It was strictly created for captive employees of a company or branch of government. It was the cutting edge of innovation. No one expected it to be easy, friendly, or “frictionless” because there were literally no alternatives. There was no competition or marketplace of options to choose from. You did not choose the software, you were chosen and trained for the software as part of your job.
The only reason experience design became anything was when software started getting written for the general public. Things like kiosks, automated teller machines, and in-flight entertainment needed interfaces. The makers of these things found that most people couldn’t figure out what to do with these machines. They’d get stuck and upset, unable to use the device as the makers had hoped. Shocking, right?
Eventually it dawned on a few people that, “Hey, maybe the software we’ve been making doesn’t make as much sense to us as it does to other people. Other people try things that we never would. Maybe we… should think of ways of making it… friendlier?” After years of team members shouting, “What? Never!” a few lucky people eventually saw us calling ourselves experience designers. Some companies realized the value of this early on and hired us, then some public-facing software started getting better. Many years stretched on with UX professionals persistently struggling to justify our existence with every new project, team, employer, or client. Then something amazing happened.
When the iPhone app store launched, everything changed.
The era After App Store ushered in a new dynamic for software. For the first time in history, the general public gained brutal control over the apps they used. They could — within minutes — obtain a piece of software and if they didn’t like it, they could remove it and warn others of its problems. Customers could, with minimal time and effort, deem apps unworthy and turn them into pariahs. Meanwhile the app developers could suddenly track how all of these people were installing, uninstalling, and talking trash about their apps. They could watch these disasters unfold in real time, helpless in their ignorance of why and how this could be happening.
The UX gold rush
In the aftermath of the App Store, the need for UX and people fluent in it became known. Suddenly instead of fighting our way to the planning table, we were invited in desperation to it. Anyone who didn’t want their app to be deleted learned fast: they’d need to hire UX people. They didn’t know who we were or how we worked but out went the job postings and hiring flurries ensued. Since it was such a new profession, many visual, interface, and graphic designers just swapped “UX” into their job title and boom, hired.
Unfortunately this resulted in confusion persisting about what good experience design is, who is capable of creating it, and what investment you really need to make in it — to keep your app from dreaded deletion. Experience designers were finally part of the team but not understood, trusted, or even respected yet. Again, sometimes we got all three but it’s usually difficult to overcome years of tradition to attain even one of them, in the minds of your coworkers.
The rush never ends
The history of software and the rush of UX into the fold has lead to what you could call The Culture Rushed Projects.
Creating software is continually expensive. It takes a lot of people and many of them earn very high wages. They’re usually produced in expensive offices filled with perks and plenty of equipment overhead. Hardware, software, patent licenses, etc. Every day costs money. It’s lovingly called your company’s “burn rate”, as if you all are a giant candle made of money. Your burn rate is a constant pressure to squeeze the most profitable productivity out of every working hour.
Hence, most projects are not expected to be crafted. They’re expected to be rushed. All the time, without pause or end. In this environment, everyone feels stress to pressure themselves and others to choose the quickest option for implementing any proposed functionality. Less experienced designers either won’t have the knowledge to suggest or the status to push for friendlier, more expensive patterns. More experienced designers might not have the professional respect to keep their decisions from being overruled. All designers are pressured to suggest the cheaper options against their better judgement — and are far more likely to make mistakes when not given the time to fully craft a given experience. Designers and/or researchers might not have enough resources for user testing, research, or A/B testing. They might not even be able to gather or learn from metrics on their existing usage.
Companies and agencies are frequently flying blind into software launches, with only the disrespected work of rushed designers to guide them. It’s not a good recipe for phasing out bad UX with friendly UX.
The existential dread of coworker extinction
Another aspect, which combines the aforementioned ingredients of disrespect and entitlement with an entirely different motivation, has the effect of eroding what experience designers bring to the table. The new motivation is the threat of obsolescence inspiring surrounding professions to co-opt work invented by experience specialists.
The first of these I encountered was from PMs (Project Managers, Product Managers, etc.) fearing the end of all they hold dear in the face of Agile Methodologies. As Agile was becoming mainstream, the PM world spent years in panic that they would be cast aside as dev teams became self-sufficient and able to say things like “no” to the defanged role of Product Owner. They scrambled to make themselves still seem useful to executives and part of that was to see what activities they could take away from their co-workers. They often saw UX people as I’ve already described, looked at some of our deliverables and thought, “Hey, I could do that, too!”
So I started seeing more and more PMs getting logins for a team’s analytics, testing, tracking, feedback, and user testing software. I heard them adopting our jargon with a serious face. I saw more attempts at “roughing out” designs and handing them to me. I saw enough of this to realize I had to have discussions about role boundaries and expectations with every new team. Again, just because you think you understand something doesn’t mean you actually do. This is especially important when you’re waltzing into the wheelhouse of your coworker who already does have a deep and multifaceted understanding of it — and a well-earned respect for what it means for creating and crafting quality experiences.
Developers, data people, SEO, and other roles started doing the same thing, often from feeling threat of extinction themselves. These other job titles began popping up with UX appended to the front of them. They too have been encroaching into user experience skills and tools, without invitation or qualification.
Hence, this lack of respect and entitlement from approachability have harmed the selection of cheap and bad vs expensive and friendly patterns to use in software — by way of once again, putting these decisions in the hands of people outside of experience design and research, with their own priorities and goals that can easily be at odds with their audience. It’s much easier to choose a bad pattern when you don’t even know its problems — or those problems don’t matter to you.
So all is lost? No hope for a better future?
With all that has been and still is going wrong, I think there is still reason to hope for a better tomorrow. The core of what needs to change is the simplification of friendly pattern implementation:
Friendly UX must become cheap.
Functionality we know today to be more friendly, helpful, effective, time-saving, and frictionless needs to become “single line of code” cheap in as many coding tools as possible. They need to share implementation simplicity conventions across plugins, libraries, frameworks, platforms, operating systems, languages, and markups. Instead of re-inventing the wheel by every team or individual, the hard work of coding these patterns needs to be pushed further and further back through code foundations.
Only then can friendly patterns be on a level playing field with the old bad patterns. Only if they’re as cheap to implement will they be a viable option for any team to choose, much less rushed and dysfunctional teams to utilize.
Only then can patterns be chosen on their merit.
Solutions to the other problems may follow with further collaboration and community but at the very least, this needs to happen for a lasting shift away from bad UX patterns.
So if your team has just implemented a friendly pattern, don’t just release it in your software. Push that code up the chain. Package it up as a plugin, a library, an addition to the codebase of the framework or platform you’re building in. Take that extra step or several steps to make it cheaper for more teams to use. You might not see the benefit today of doing so but when someone else takes it, enhances it, and you pull that into the next version of your own project — you’ll see your investment returned.
It’s in your own best interests to make friendly patterns cheap. Seriously, it’ll keep you from getting deleted.
