The paradox of performance:
This era of incredibly fast hardware is also the era of programs that take tens of seconds to start from an SSD or NVMe disk; of bloated web applications that take many seconds to show a simple list, even on a broadband connection; of programs that process data at a thousandth of the speed we should expect. Software is laggy and sluggish — and the situation shows little signs of improvement. Why is that?
Because we prioritise the developer experience over the user experience, that’s why:
Although our job is ostensibly to create programs that let users do stuff with their computers, we place a greater emphasis on the development process and dev-oriented concerns than on the final user product.
We would do well to heed Craig’s observations on Fast Software, the Best Software.
Jesse has his Oppenheimer moment, with much wailing and gnashing of teeth.
What got lost along the way was a view of UX as something deeper and more significant than a step in the software delivery pipeline: an approach that grounds product design in a broad contextual understanding of the problem and goes beyond the line-item requirements of individual components. Also lost along the way were many of the more holistic and exploratory practices that enabled UX to deliver that kind of foundational value.
I click the link. The page loads fast. I navigate the surprisingly sparse yet clear form inputs. And complete the whole thing in less than thirty seconds.
Oh, how I wish this experience weren’t remarkable!
Simple forms with clear labels. Little to no branding being shoved down my throat. No array of colors, big logos, or overly-customized UI components.
Increasingly, I think UX doesn’t live up to its original meaning of “user experience.” Instead, much of the discpline today, as it’s practiced in Big Tech firms, is better described by a new name.
UX is now “user exploitation.”
4 Design Patterns That Violate “Back” Button Expectations – 59% of Sites Get It Wrong - Articles - Baymard Institute
Some interesting research in here around user expecations with the back button:
Generally, we’ve observed that if a new view is sufficiently different visually, or if a new view conceptually feels like a new page, it will be perceived as one — regardless of whether it technically is a new page or not. This has consequences for how a site should handle common product-finding and -exploration elements like overlays, filtering, and sorting. For example, if users click a link and 70% of the view changes to something new, most will perceive this to be a new page, even if it’s technically still the same page, just with a new view loaded in.
There is a gentle sadness to being present in a moment so precious that you know you’ll never forget it, and will revisit it as a memory time and time again. It will be a shadow, many details missing, the moment bittersweet.
Know any graduates who’d like to take part in a fun (paid) three month scheme at Clearleft? Send ‘em our way.
We have a tendency in our line of work to assume that what benefits us as developers translates to a benefit for those who use what we make. This is an unsafe assumption.
It’s our job as designers to bring clarity back to the digital canvas by crafting reading experiences that put readers first.
This long zoom by Andy is right up my alley—a history of UX design that begins in 1880. It’s not often that you get to read something that includes Don Norman, Doug Engelbart, Lilian Gilbreth, and Vladimir Lenin. So good!
Yes! Yes! Yes!
Our efforts to measure and improve UX are packed with tragically ironic attempts to love our users: we try to find ways to improve our app experiences by bloating them with analytics, split testing, behavioral analysis, and Net Promoter Score popovers. We stack plugins on top of third-party libraries on top of frameworks in the name of making websites “better”—whether it’s something misguided, like adding a carousel to appease some executive’s burning desire to get everything “above the fold,” or something truly intended to help people, like a support chat overlay. Often the net result is a slower page load, a frustrating experience, and/or (usually “and”) a ton of extra code and assets transferred to the browser.
Even tools that are supposed to help measure performance in order to make improvements—like, say, Real User Monitoring—require you to add a script to your web pages …thereby increasing the file size and degrading performance! It’s ironic, in that Alanis Morissette sense of not understanding what irony is.
Stacking tools upon tools may solve our problems, but it’s creating a Jenga tower of problems for our users.
This is a great article about evaluating technology.
A web of anxiety: accessibility for people with anxiety and panic disorders [Part 1] | The Paciello Group – Your Accessibility Partner (WCAG 2.0/508 audits, VPAT, usability and accessible user experience)
Enumerating the anti-patterns that cause serious user experience issues that don’t get nearly enough attention:
While such intrusions can be a source of irritation or even stress for many people, they may be complete showstoppers for people with anxiety or panic disorders.
I’m looking forward to reading the follow-up post.
(I was going to say I was anxiously awaiting the follow-up post but …never mind.)
I agree completely. And AMP is not the answer:
Given the assumption that any additional bandwidth offered to web developers will immediately be consumed, there seems to be just one possible solution, which is to reduce the amount of bytes that are transmitted. For some bizarre reason, this hasn’t happened on the main web, because it somehow makes more sense to create an exact copy of every page on their site that is expressly designed for speed. Welcome back, WAP — except, for some reason, this mobile-centric copy is entirely dependent on yet more bytes. This is the dumbfoundingly dumb premise of AMP.
Adriana Blum lists progressive web apps that are doing very, very well from Twitter, Trivago, Starbucks, Forbes, Debebhams, West Elm, Washington Post, Pinterest, AliExpress, and Lancôme.
Instead of choosing between the immediacy of a mobile website and the rich experience offered by native apps, you can now offer your target audiences the best of both and improve the commercial performance of your business to boot.
Here’s a really quick (ten minute) talk about the offline user experience that I gave at the Delta V conference recently. I’m quite happy with how it turned out—there’s something to be said for having a short and snappy time slot.
There’s a common misconception that making a Progressive Web App means creating a Single Page App with an app-shell architecture. But the truth is that literally any website can benefit from the performance boost that results from the combination of HTTPS + Service Worker + Web App Manifest.
I was just talking about how browser-based games are the perfect use-case for service workers. Andrzej Mazur breaks down how that would work:
- Add to Home screen
- Offline capabilities
- Progressive loading
Following on from Ben’s post, this is also giving me the warm fuzzies.
I, in no uncertain terms, have become a better designer thanks to the people I’ve had the pleasure of working alongside at Clearleft. I’ll forever be thankful of my time there, and to the people who helped me become better.
Ben is moving on from Clearleft. I’m going to miss him. I found this summation of his time here very moving.
Working at Clearleft was one of the best decisions I ever made. 6 years of some work that I’m most proud of, amongst some of the finest thinkers I’ve ever met.
He also outlines the lessons he learned here:
- Writing and speaking will make you a better thinker and designer.
- Autonomy rules.
- Own stuff.
- Aim high.
Should you ever choose to work with, or work for Clearleft, I hope these words will give you some encouragement — it is an exceptional place to be.