Developer happiness is only a benefit if it first does no harm to others. Even better if it genuinely amplifies benefits to those further up chain of priorities.
Do we have too many design systems?
Spoiler: the answer is “no”. There. Saved you a click.
(Not really; you should definitely click.)
A great slide deck from Alla, all about design principles. From purpose to principles to patterns.
Dave has curated a handy list of eponymous laws.
The transcript of a terrific talk by Paul, calling for a more thoughtful, questioning approach to digital design. It covers the issues I’ve raised about Booking.com’s dark patterns and a post I linked to a while back about the shifting priorities of designers working at scale.
Drawing inspiration from architectural practice, its successes and failures, I question the role of design in a world being eaten by software. When the prevailing technocratic culture permits the creation of products that undermine and exploit users, who will protect citizens within the digital spaces they now inhabit?
A remarkably practical in-depth guide to making ethical design decisions, with enjoyable diversions into the history of philosophy throughout.
I enjoyed chatting to Larry Botha on the Fixate On Code podcast—I hope you’ll enjoy hearing it.
- Fitts’s Law
- Hick’s Law
- Jakob’s Law
- Law of Prägnanz
- Law of Proximity
- Miller’s Law
- Parkinson’s Law
- Serial Position Effect
- Tesler’s Law
- Van Restorff Effect
- Murphy’s Law
- Sturgeon’s Law
Collections of design principles that you can contribute to.
The aim of the site is to help us analyse what good Design Principles are. How Design Principles are created and measured. How they develop.
The Fallacies of Distributed Computing (Applied to Front-End Performance) – CSS Wizardry – CSS Architecture, Web Performance Optimisation, and more, by Harry Roberts
Harry cautions against making assumptions about the network when it comes to front-end development:
Yet time and time again I see developers falling into the same old traps—making assumptions or overly-optimistic predictions about the conditions in which their apps will run.
Planning for the worst-case scenario is never a wasted effort:
If you build and structure applications such that they survive adverse conditions, then they will thrive in favourable ones.
I really like this exercise by Harry. I’ve done similar kinds of grading using dot-voting in the past. It feels like an early step to establishing design principles: “this over that.”
By deciding what we value up-front, we have an agreement that we can look back on in order to help us settle these conflicts and get us back on track again.
Relative Requirements remove the personal aspect of these disagreements and instead focuses on more objective agreements that we made as a team.
These are really good ideas for evaluating design principles. In fact, I would go so far as to say they are design principles for design principles.
- Good design principles are memorable
- Good design principles help you say no.
- Good design principles aren’t truisms.
- Good design principles are applicable.
I love what Ben is doing with this single-serving site (similar to my design principles collection)—it’s a collection of handy links and resources around voice UI:
Designing a voice interface? Here’s a useful list of lists: as many guiding principles as we could find, all in one place. List compiled and edited by Ben Sauer @bensauer.
BONUS ITEM: Have him run a voice workshop for you!
All you do is be mindful of when the team repeats design desires. This could be several members of the team say the same thing in a slightly different way, or that you keep circling around and around a problem but struggle to articulate it. By being mindful at all times to this a team can quickly pull together principles that are derived from doing the work on their particular problem rather than principles which are imposed on the work. An important difference.
This is a fascinating exercise—take a good set of design principles and test them for reversibility. The results are entirely plausible.
I’ve taken this exercise to the extreme. The philosophy behind inclusive design is that the thing you create works for everybody, no matter the context. The idea behind this experiment in Exclusive Design is that you design something for one specific person, in a controlled environment, in a specific context. Tailor made.
Maybe I should add these to my collection.
- Provide a unique experience
- Ignore situation
- Be inconsistent/innovative
- Take control
- Offer the best possible solution
- Prioritise identity
- Add nonsense
I love John’s long-zoom look at web development. Step back far enough and you can start to see the cycles repeating.
Underneath all of these patterns and practices and frameworks and libraries are core technologies. And underlying principles.
These are foundations – technological, and of practice – that we ignore, overlook, or flaunt at our peril.
I like this list:
This is not a checklist. Instead, it is a set of broad guidelines meant to preserve an underlying value. It can be used as a guide for someone working on implementation or as a tool to evaluate an existing project.
I’ve added them to my collection of design principles.
A series of questions to ask on any design project:
- What are my lenses?
- Am I just confirming my assumptions, or am I challenging them?
- What details here are unfair? Unverified? Unused?
- Am I holding onto something that I need to let go of?
- What’s here that I designed for me? What’s here that I designed for other people?
- What would the world look like if my assumptions were wrong?
- Who might disagree with what I’m designing?
- Who might be impacted by what I’m designing?
- What do I believe?
- Who’s someone I’m nervous to talk to about this?
- Is my audience open to change?
- What am I challenging as I create this?
- How can I reframe a mistake in a way that helps me learn?
- How does my approach to this problem today compare to how I might have approached this one year ago?
- If I could learn one thing to help me on this project, what would that one thing be?
- Do I need to slow down?
Analysing what the web is. It’s not the technology stack.
To count as being part of the web, your app or page must:
- Be linkable, and
- Allow any client to access it.
I think that’s a pretty good definition.
Mind you, I think this is a bit rich in an article published on The Verge:
The HTML web may be slow and annoying and processor intensive, but before we rush too fast into replacing it, let’s not lose what’s good about it.
Still, we can agree on this:
Preserving the web, or more specifically the open principles behind it, means protecting one of the few paths for innovation left in the modern tech world that doesn’t have a giant company acting as a gatekeeper.