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.
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.)
There is a cumulative effect of bullshit; its depth and breadth is especially profound. In isolation, the few seconds that it takes to load some extra piece of surveillance JavaScript isn’t much. Neither is the time it takes for a user to hide an email subscription box, or pause an autoplaying video. But these actions compound on a single webpage, and then again across multiple websites, and those seemingly-small time increments become a swirling miasma of frustration and pain.
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:
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.
A catalogue of design decisions that have had harmful effects on users. This is a call for more inclusive design, but also a warning on the fetishisation of seamlessness:
The focus on details and delight can be traced to manifestos like Steve Krug’s Don’t Make Me Think, which propose a dogmatic adherence to cognitive obviousness and celebrates frictionless interaction as the ultimate design accomplishment.
I wonder if I have twenty years of experience making websites, or if it is really five years of experience, repeated four times.
I saw Frank give this talk at Mirror Conf last year and it resonated with me so so much. I’ve been looking forward to him publishing the transcript ever since. If you’re anything like me, this will read as though it’s coming from directly inside your head.
In one way, it is easier to be inexperienced: you don’t have to learn what is no longer relevant. Experience, on the other hand, creates two distinct struggles: the first is to identify and unlearn what is no longer necessary (that’s work, too). The second is to remain open-minded, patient, and willing to engage with what’s new, even if it resembles a new take on something you decided against a long time ago.
I could just keep quoting the whole thing, because it’s all brilliant, but I’ll stop with one more bit about the increasing complexity of build processes and the decreasing availability of a simple view source:
Illegibility comes from complexity without clarity. I believe that the legibility of the source is one of the most important properties of the web. It’s the main thing that keeps the door open to independent, unmediated contributions to the network. If you can write markup, you don’t need Medium or Twitter or Instagram (though they’re nice to have). And the best way to help someone write markup is to make sure they can read markup.
Just to be clear, this isn’t about interaction design, it’s about how browsers and become unresponsive to interaction when they’re trying to parse the truckloads of Javascript web developers throw at them.
Top tip: lay off the JavaScript. HTML is interactive instantly.
Advice on building design systems:
- If you can avoid being ambiguous, please do.
- Favor common understanding over dictionary correctness.
- Make great operations a priority.
- Don’t get trapped in defining things instead of explaining things.
I really like this “evil” design exercise that Jared has documented on Ev’s blog.
I broke them up into small groups of three, spreading each role across separate groups. I then asked each person to grab a sheet of paper and make their own list of ways they imagined the product’s user experience could be made worse.
Two pieces of good news from Google:
A lovely outlook on designing with progressive enhancement:
There will always be users coming from places you didn’t expect, using devices you didn’t test for.
Jared explains how adding new features can end up hurting the user experience.
The Riegers are like emissaries from Planet Smart and we mere mortals are fortunate that they take the time to give us great articles like this.
Cennydd’s closing remarks from this year’s IA Summit. Huzzah!
Small interactions that serve no useful purpose but are nonetheless satisfying. "Design this interaction such that: It's “free,” i.e. having no significance to the task or content, It's discoverable in ordinary use of the product, It's quick and repeatable (Less than half a second.), It's pleasant"