- Good design works for everyone
- Good design makes things obvious
- Good design puts users in control
- Good design is lightweight
This may mark the beginning of Gov.uk’s decline. The top-listed priorities are the very antithesis of starting with user needs. Instead from now on it’s going to be about growth, shiny new technology, having a native app, and literally pivoting to video.
It’ll be interesting to see if they try to maintain their existing design principles while simultaneously abandoning them.
Seven principles for journalism in the age of AI
- Be rigorous with your definitions.
- Predict less, explain more.
- Don’t hype things up.
- Focus on the people building AI systems — and the people affected by its release.
- Offer strategic takes on products.
- Emphasize the tradeoffs involved.
- Remember that nothing is inevitable.
- Make the right thing easy
- Always answer “so what”?
- Close the gap between “something is wrong” to “we fixed it”
The primary goals of this strategy are to inform decision-making and enhance the success of accessibility-related activities within the GOV.UK Design System team.
Interestingly, accessibility concerns are put into two categories: theoretical and evidenced (with the evidenced concerns being prioritised):
- Theoretical: A question or statement regarding the accessibility of an implementation within the Design System without evidence of real-world impact.
- Evidenced: Sharing new research, data or evidence showing that an implementation within the Design System could cause barriers for disabled people.
Here’s the video of the talk I gave at Web Dev Conf in Bristol recently. I think you can tell that I had fun—it was a good audience!
Modern computing is far too rigid. Applications can only function in preset ways determined by some far away team. Software is trapped in hermetically sealed silos and is rewritten many times over rather than recomposed.
This community catalogs and experiments with malleable software and systems that reset the balance of power via several essential principles…
I’ll be adding those principles to my collection.
The slides from Tess’s presentation on the W3C’s ethical web principles—there’s a transcript too.
A collection of design patterns and principles for mitigating the presence and spread of online hate and harassment in social platforms.
This is an oldie from Julie Zhou, but it’s a timeless message about the value of good (i.e. actually useful) design principles.
See also what she said on this podcast episode:
When push comes to shove and you have to make a trade off, how are you, in those moments, as a team or a company going to prioritize? What are you going to care about the most? Good values will be controversial in that respect because it’s something that another company might have made a different decision than you.
Here’s the video of the talk I gave in front of an enormous audience at the We Are Developers conference …using a backup slidedeck.
I think it was Jason who once told me that if you want to make someone’s life a misery, teach them about typography. After that they’ll be doomed to notice all the terrible type choices and kerning out there in the world. They won’t be able to unsee it. It’s like trying to unsee the arrow in the FedEx logo.
I think that Stewart Brand’s pace layers model is a similar kind of mind virus, albeit milder. Once you’ve been exposed to it, you start seeing in it in all kinds of systems.
Each layer is functionally different from the others and operates somewhat independently, but each layer influences and responds to the layers closest to it in a way that makes the whole system resilient.
Last month I sent out an edition of the Clearleft newsletter that was all about pace layers. I gathered together examples of people who have been infected with the pace-layer mindworm who were applying the same layered thinking to other areas:
My own little mash-up is applying pace layers to the World Wide Web. Tom even brought it to life as an animation.
See the Pen Web Layers Of Pace by Tom (@webrocker) on CodePen.
Recently I had another flare-up of the pace-layer pattern-matching infection.
I was talking to some visiting Austrian students on the weekend about design principles. I explained my mild obsession with design principles stemming from the fact that they sit between “purpose” (or values) and “patterns” (the actual outputs):
Purpose » Principles » Patterns
Your purpose is “why?”
That then influences your principles, “how?”
Those principles inform your patterns, “what?”
Hey, wait a minute! If you put that list in reverse order it looks an awful lot like the pace-layers model with the slowest moving layer at the bottom and the fastest moving layer at the top. Perhaps there’s even room for an additional layer when patterns go into production:
Your purpose should rarely—if ever—change. Your principles can change, but not too frequently. Your patterns need to change quite often. And what you’re actually putting out into production should be constantly updated.
As you travel from the most abstract layer—“purpose”—to the most concrete layer—“production”—the pace of change increases.
I can’t tell if I’m onto something here or if I’m just being apopheniac. Again.
To be honest, I’m not all that convinced by Robin’s arguments here about overhauling the governance model at the World Wide Web Consortium (partly because the way he describes the current model sounds pretty okay to me). But I’m very interested in what he has to say in the broader philosophical sense about using values to solve problems:
A value is worth something if it’s there to help you when the rubber hits the road and starts hydroplaning. Sure, you’ll need a handful of high-level lofty values as reminders, if only because there’s always a vocal guy (it’s always a guy) who thinks it’s just outrageous to put people before profits. But mostly you want Values You Can Use.
That might be the best description I’ve come across yet for design principles: values you can use.
When we say that engineering is about trade-offs, we’re saying that engineers solve their hardest problems using values (which they call “heuristics” because everyone’s entitled to be fancy some). In implementing a system, you might need to decide between an option that provides people with the best experience, another that delivers the greatest value to the shareholders, and yet a third one that makes the control centre blinkenlights dance in the prettiest way.
I may have mentioned this before, but I’m a bit of a nerd for design principles. Have I shown you my equivalent of an interesting rock collection lately?
If you think about design principles for any period of time, it inevitably gets very meta very quickly. You start thinking about what makes for good design principles. In other words, you start wondering if there are design principles for design principles.
I’ve written before about how I think good design principles should encode some level of prioritisation. The classic example is the HTML design principle called the priority of consitituencies:
In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.
It’s wonderfully practical!
I realised recently that there’s another set of design princples that put prioritisation front and centre—the Agile manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
And there’s this excellent explanation which could just as well apply to the priorty of constituencies:
That is, while there is value in the items on the right, we value the items on the left more.
Yes! That’s the spirit!
Ironically, the Agile manifesto also contains a section called principles behind the Agile manifesto which are …less good (at least they’re less good as design principles—they’re fine as hypotheses to be tested).
Agile is far from perfect. See, for example, Miriam Posner’s piece Agile and the Long Crisis of Software. But where Agile isn’t fulfilling its promise, I’d say it’s not because of its four design principles. If anything, I think the problems arise from organisations attempting to implement Agile without truly internalising the four principles.
Oh, and that’s another thing I like about the Agile manifesto as a set of design principles—the list of prioritised principles is mercifully short. Just four lines.
Time and again, organizations have sought to contain software’s most troublesome tendencies—its habit of sprawling beyond timelines and measurable goals—by introducing new management styles. And for a time, it looked as though companies had found in Agile the solution to keeping developers happily on task while also working at a feverish pace. Recently, though, some signs are emerging that Agile’s power may be fading. A new moment of reckoning is in the making, one that may end up knocking Agile off its perch.
As you may already know, I’m a nerd for design principles. I collect them. I did a podcast episode on them. I even have a favourite design principle. It’s from the HTML design principles. The priority of constituencies:
In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.
It’s all about priorities, see?
Prioritisation isn’t easy, and it gets harder the more factors come into play: user needs, business needs, technical constraints. But it’s worth investing the time to get agreement on the priority of your constituencies. And then formulate that agreement into design principles.
Jason is also a fan of the priority of constituencies. He recently wrote about applying it to design systems and came up with this:
User needs come before the needs of component consumers, which come before the needs of component developers, which come before the needs of the design system team, which come before theoretical purity.
That got me thinking about how this framing could be applied to other areas, like design.
Designers are used to juggling different needs (or constituencies); user needs, business needs, and so on. But what I’m interested in is how designers weigh up different inputs into the design process.
The obvious inputs are the insights you get from research. But even that can be divided into different categories. There’s qualitative research (talking to people) and qualitative research (sifting through numbers). Which gets higher priority?
There are other inputs too. Take best practices. If there’s a tried and tested solution to a problem, should that take priority over something new and untested? Maybe another way of phrasing it is to call it experience (whether that’s the designer’s own experience or the collective experience of the industry).
And though we might not like to acknowledge it because it doesn’t sound very scientific, gut instinct is another input into the design process. Although maybe that’s also related to experience.
Finally, how do you prioritise stakeholder wishes? What do you do if the client or the boss wants something that conflicts with user needs?
I could imagine a priority of design inputs that looks like this:
Qualitative research over quantitative research over stakeholder wishes over best practices over gut instinct.
But that could change over time. Maybe an experienced designer can put their gut instinct higher in the list, overruling best practices and stakeholder wishes …and maybe even some research insights? I don’t know.
I’ve talked before about how design principles should be reversible in a different context. The original priority of constituencies, for example, applies to HTML. But if you were to invert it, it would work for XML. Different projects have different priorities.
I could certainly imagine company cultures where stakeholder wishes take top billing. There are definitely companies that value qualitative research (data and analytics) above qualitative research (user interviews), and vice-versa.
Is a priority of design inputs something that should change from project to project? If so, maybe it would be good to hammer it out in the discovery phase so everyone’s on the same page.
Anyway, I’m just thinking out loud here. This is something I should chat more about with my colleagues to get their take.
Jason applies my favourite design principle to design systems.
User needs come before the needs of component consumers, which come before the needs of component developers, which come before the needs of the design system team, which come before theoretical purity.
Also: how frickin’ cool is it that the Cloud Four office has the priority of constituencies emblazoned on the wall!
The final episode of season three of the Clearleft podcast is out. Ah, what a bittersweet feeling! On the hand it’s sad that the season has come to an end. But it feels good to look back at six great episodes all gathered together.
Episode six is all about design principles. That’s a topic close to my heart. I collect design principles.
But for this podcast episode the focus is on one specific project. Clearleft worked with Citizens Advice on a recent project that ended up having design principles at the heart of it. It worked as a great focus for the episode, and a way of exploring design principles in general. As Katie put it, this about searching for principles for design principles.
Katie and Maite worked hard on nailing the design principles for the Citizens Advice project. I was able to get some of Maite’s time for her to talk me through it. I’ve also got some thoughts from my fellow Clearlefties Andy and Chris on the topic of design principles in general.
It’s nineteen minutes long and well worth a listen.
And with that, season three of the Clearleft podcast is a wrap!
Just like brand values, mission statements, or vision decks, design principles can be generic and provide little to no actual value.
But used correctly, design principles help you make decisions resulting in a superior experience.
There’s a really interesting discussion here, kicked off by Lea, about balancing long-term standards with short-term pragmatism. Specifically, it’s about naming things.
Naming things is hard. Naming things in standards, doubly so.