An interesting project that will research and document the language used across different design systems to name similar components.
I really like the work that IF are doing to document patterns around handling data:
- Signing in to a service
- Giving and removing consent
- Giving access to data
- Getting access to data
- Understanding automated decisions
- Doing security checks
Each pattern has a description, advantages, limitations, and examples.
There seems to be a tendency to repurpose existing solutions to other people’s problems. I propose that this is the main cause of the design sameness that we encounter on the web (and in apps) today. In our (un)conscious attempts to reduce the effort needed to do our work, we’ve become experts in choosing rather than in thinking.
A very thoughtful piece from Stephen.
When we use existing solutions or patterns, we use a different kind of thinking. Our focus is on finding which pattern will work for us. Too quickly, we turn our attention away from closely examining the problem.
The video of a talk in which Mark discusses pace layers, dogs, and design systems. He concludes:
- Current design systems thinking limits free, playful expression.
- Design systems uncover organisational disfunction.
- Continual design improvement and delivery is a lie.
- Component-focussed design is siloed thinking.
It’s true many design systems are the blueprints for manufacturing and large scale application. But in almost every instance I can think of, once you move from design to manufacturing the horse has bolted. It’s very difficult to move back into design because the results of the system are in the wild. The more strict the system, the less able you are to change it. That’s why broad principles, just enough governance, and directional examples are far superior to locked-down cookie cutters.
Making the case for moving your navigation to the bottom of the screen on mobile:
Phones are getting bigger, and some parts of the screen are easier to interact with than others. Having the hamburger menu at the top provides too big of an interaction cost, and we have a large number of amazing mobile app designs that utilize the bottom part of the screen. Maybe it’s time for the web design world to start using these ideas on websites as well?
This is a really interesting distinction:
An intentional design system. The flavour and framework may vary, but the approach generally consists of: design system first → design/build solutions.
An emergent design system. This approach is much closer to the user needs end of the scale by beginning with creative solutions before deriving patterns and systems (i.e the system emerges from real, coded scenarios).
It’s certainly true that intentional design systems will invariably bake in a number of (unproven?) assumptions.
Keep what you need, delete what you don’t and add whatever you like on top of whats already there.
The good folks at Sparkbox ran a survey on design systems. Here are the results, presented in a flagrantly anti-Tufte manner.
This is about designing forms that everyone can use and complete as quickly as possible. Because nobody actually wants to use your form. They just want the outcome of having used it.
A case study from Twitter on the benefits of using a design system:
With component-based design, development becomes an act of composition, rather than constantly reinventing the wheel.
I think that could be boiled down to this:
Component-based design favours composition over invention.
I’m not saying that’s good. I’m not saying that’s bad. I’m also not saying it’s neutral.
Mike follows up on the changes made by email startup Superhuman after his initial post:
I will say this: if you were skeptical of Superhuman’s commitment to privacy and safety after reading the last article, you should probably be even more skeptical after these changes. The company’s efforts demonstrate a desire to tamp down liability and damage to their brand, but they do not show an understanding of the core problem: you should not build software that surreptitiously collects data on people in a way that would surprise and frighten them.
A really excellent analysis by Mike of a dark pattern in the Superhuman email app.
That’s right. A running log of every single time you have opened my email, including your location when you opened it. Before we continue, ask yourself if you expect this information to be collected on you and relayed back to your parent, your child, your spouse, your co-worker, a salesperson, an ex, a random stranger, or a stalker every time you read an email.
Exactly! This violates the principle of least surprise. Also, it’s just plain wrong.
Amazingly though, Mike has been getting pushback from guys on Twitter (and it’s always guys) who don’t think this is a big deal.
Anyway, read the whole thing—it’s fair, balanced, and really well written.
Rachel makes the case for integrating content design patterns into component libraries:
Instead of content design systems and visual design systems existing in isolation, the ideal is one design system that accommodates everything, marrying the content and design together in the way it will actually be used and experienced.
Amy’s talk at Patterns Day was absolutely brilliant! Here’s an account of the day from her perspective.
The evident care Jeremy put into assembling the lineup meant an incredible mix of talks, covering the big picture stuff right down to the nitty gritty, and plenty in between.
Her observation about pre-talk nerves is spot-on:
I say all of this because it’s important for me and I think anyone who suffers with anxiety about public speaking, or in general, to recognise that having a sense of impending doom doesn’t mean that doom is actually impending.
Here’s a nice little round-up of Friday’s Patterns Day.
Just look at these fantastic pictures that Trys took (very unobstrusively) at Patterns Day—so rock’n’roll!
Stuart took copious notes during every single talk at Patterns Day—what a star!
1,841 instances of dark patterns on ecommerce sites, in the categories of sneaking, urgency, misdirection, social proof, scarcity, obstruction, and forced action. You can browse this overview, read the paper, or look at the raw data.
We conducted a large-scale study, analyzing ~53K product pages from ~11K shopping websites to characterize and quantify the prevalence of dark patterns.
If you find yourself wrestling with CSS layout, it’s likely you’re making decisions for browsers they should be making themselves. Through a series of simple, composable layouts, Every Layout will teach you how to better harness the built-in algorithms that power browsers and CSS.