The value of design principles done right:
What I’ve learnt is that principles are not a luxury. Making explicit and conscious what drives your behaviour can be incredibly powerful as a means to critically shape a team and organisation to be who they want to be.
It’s often said that it’s easier to make a fast website than it is to keep a website fast. Things slip through. If you’re not vigilant, performance can erode without you noticing.
It’s a similar story for other invisible but important facets of your website: privacy, security, accessibility. Because they’re hidden from view, you won’t be able to see if there’s a regression.
That’s why it’s a good idea to have regular audits for performance, privacy, security, and accessibility.
I wrote about accessibility testing a while back, and how there’s quite a bit that you can do for yourself before calling in an expert to look at the really gnarly stuff:
When you commission an accessibility audit, you want to make sure you’re getting the most out of it. Don’t squander it on issues that you can catch and fix yourself. Make sure that the bulk of the audit is being spent on the specific issues that are unique to your site.
I recently did an internal audit of the Clearleft website. After writing up the report, I also did a lunch’n’learn to share my methodology. I wanted to show that there’s some low-hanging fruit that pretty much anyone can catch.
To start with, there’s keyboard navigation. Put your mouse and trackpad to one side and use the tab key to navigate around.
Caveat: depending on what browser you’re using, you might need to update some preferences for keyboard navigation to work on links. If you’re using Safari, go to “Preferences”, then “Advanced”, and tick “Press Tab to highlight each item on a web page.”
Tab around and find out. You should see some nice chunky :focus-visible styles on links and form fields.
Here’s something else that anyone can do: zoom in. Increase the magnification to 200%. Everything should scale proportionally. How about 500%? You’ll probably see a mobile-friendly layout. That’s fine. As long as nothing is broken or overlapping, you’re good.
At this point, I reach for some tools. I’ve got some bookmarklets that do similar things: tota11y and ANDI. They both examine the source HTML and CSS to generate reports on structure, headings, images, forms, and so on.
These tools are really useful, but you need to be able to interpret the results. For example, a tool can tell you if an image has no alt text. But it can’t tell you if an image has good or bad alt text.
Likewise, these tools are great for catching colour-contrast issues. But there’s a big difference between a colour-contrast issue on the body copy compared to a colour-contrast issue on one unimportant page element.
I think that demonstrates the most important aspect of any audit: prioritisation.
Finding out that you have accessibility issues isn’t that useful if they’re all presented as an undifferentiated list. What you really need to know are which issues are the most important to fix.
By the way, I really like the way that the Gov.uk team prioritises accessibility concerns:
The team puts accessibility concerns in 2 categories:
- 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.
The team will usually prioritise evidenced issues and queries over theoretical ones.
When I wrote up my audit for the Clearleft website, I structured it in order of priority. The most important things to fix are at the start of the audit. I also used a simple scale for classifying the severity of issues: low, medium, and high priority.
Thankfully there were no high-priority issues. There were a couple of medium-priority issues. There were plenty of low-priority issues. That’s okay. That’s a pretty good distribution.
If you’re interested, here’s the report I delivered…
There are a few issues with the pink colour. When it’s used on a grey background, or when it’s used as a background colour for white text, the colour contrast isn’t high enough.
The SVG arrow icon could be improved too.
--red is currently rgb(234, 33, 90). Change it to rgb(210, 20, 73) (thanks, James!)currentColor. Consider hardcoding solid black (or a very, very dark grey) instead.Alt text is improving on the site. There’s reasonable alt text at the top level pages and the first screen’s worth of case studies and blog posts. I made a sweep through these pages a while back to improve the alt text but I haven’t done older blog posts and case studies.
The site is using headings sensibly. Sometimes the nesting of headings isn’t perfect, but this is a low priority issue. For example, on the contact page there’s an h1 followed by two h3s. In theory this isn’t correct. In practice (for screen reader users) it’s not an issue.
h3 instead of h1.h3 headings for the industry sector (“Charities”, “Education” etc.) but these should probably not be headings at all. On the blog index page we use a class “Tags” for a similar purpose. Consider reusing that pattern on the case studies index page.h3 and the subsequent three headings are h2s. Ideally this would be reversed: a single h2 followed by three h3s.Sometimes the same text is used for different links.
The only form on the site is the newsletter sign-up form. It’s marked up pretty well: the input has an associated label, although a visible (clickable) label would be better.
The site doesn’t use JavaScript to mess with tabbing order for keyboard users. The source order of elements in the markup generally makes sense so all is good.
The focus styles are nice and clear too!
The site is using HTML landmark elements sensibly (header, nav, main, footer, etc.).
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.
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.
The only person who wants a carousel on your site is you. That’s it. It’s a self-serving vanity project so that you can showcase all of your babies at the same time without telling the world which one is your favorite.
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.
This is an excellent framing for minimal viable products—what would the black box theatre production be?
Forget about all the production and complexity you could build. What’s the purpose you want to convey at the core?
I think about design principles a lot. I’m such a nerd for design principles, I even have a collection. I’m not saying all of the design principles in the collection are good—far from it! I collect them without judgement.
As for what makes a good design principle, I’ve written about that before. One aspect that everyone seems to agree on is that a design principle shouldn’t be an obvious truism. Take this as an example:
Make it usable.
Who’s going to disagree with that? It’s so agreeable that it’s practically worthless as a design principle. But now take this statement:
Usability is more important than profitability.
Ooh, now we’re talking! That’s controversial. That’s bound to surface some disagreement, which is a good thing. It’s now passing the reversability test—it’s not hard to imagine an endeavour driven by the opposite:
Profitability is more important than usability.
In either formulation, what makes these statements better than the bland toothless agreeable statements—“Usability is good!”, “Profitability is good!”—is that they introduce the element of prioritisation.
I like design principles that can be formulated as:
X, even over Y.
It’s not saying that Y is unimportant, just that X is more important:
Usability, even over profitability.
Or:
Profitability, even over usability.
Design principles formulated this way help to crystalise priorities. Chris has written about the importance of establishing—and revisiting—priorities on any project:
Prioritisation isn’t and shouldn’t be a one-off exercise. The changing needs of your customers, the business environment and new opportunities from technology mean prioritisation is best done as a regular activity.
I’ve said it many times, but one on my favourite design principles comes from the HTML design principles. The priority of consitituencies (it’s got “priorities” right there in the name!):
In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.
Or put another way:
When it comes to evaluating technology for the web, I think there are a number of factors at play.
First and foremost, there’s the end user. If a technology choice harms the end user, avoid it. I’m thinking here of the kind of performance tax that a user has to pay when developers choose to use megabytes of JavaScript.
Mind you, some technologies have no direct effect on the end user. When it comes to build tools, version control, toolchains …all the stuff that sits on your computer and never directly interacts with users. In that situation, the wants and needs of developers can absolutely take priority.
But as a general principle, I think this works:
User experience, even over developer experience.
Sadly, I think the current state of “modern” web development reverses that principle. Developer efficiency is prized above all else. Like I said, that would be absolutely fine if we’re talking about technologies that only developers are exposed to, but as soon as we’re talking about shipping those technologies over the network to end users, it’s negligent to continue to prioritise the developer experience.
I feel like personal websites are an exception here. What you do on your own website is completely up to you. But once you’re taking a paycheck to make websites that will be used by other people, it’s incumbent on you to realise that it’s not about you.
I’ve been talking about developers here, but this is something that applies just as much to designers. But I feel like designers go through that priority shift fairly early in their career. At the outset, they’re eager to make their mark and prove themselves. As they grow and realise that it’s not about them, they understand that the most appropriate solution for the user is what matters, even if that’s a “boring” tried-and-tested pattern that isn’t going to wow any fellow designers.
I’d like to think that developers would follow a similar progression, and I’m sure that some do. But I’ve seen many senior developers who have grown more enamoured with technologies instead of honing in on the most appropriate technology for end users. Maybe that’s because in many organisations, developers are positioned further away from the end users (whereas designers are ideally being confronted with their creations being used by actual people). If a lead developer is focused on the productivity, efficiency, and happiness of the dev team, it’s no wonder that their priorities end up overtaking the user experience.
I realise I’m talking in very binary terms here: developer experience versus user experience. I know it’s not always that simple. Other priorities also come into play, like business needs. Sometimes business needs are in direct conflict with user needs. If an online business makes its money through invasive tracking and surveillance, then there’s no point in having a design principle that claims to prioritise user needs above all else. That would be a hollow claim, and the design principle would become worthless.
Because that’s the point with design principles. They’re there to be used. They’re not a nice fluffy exercise in feeling good about your work. The priority of constituencies begins, “in case of conflict” and that’s exactly when a design principle matters—when it’s tested.
Suppose someone with a lot of clout in your organisation makes a decision, but that decision conflicts with your organisations’s design principles. Instead of having an opinion-based argument about who’s right or wrong, the previously agreed-upon design principles allow you to take ego out of the equation.
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.
I worry that more and more nowadays, people jump to JavaScript frameworks because that is what they know or have been taught, even though they are entirely inappropriate for a wide array of things and can often produce poor results.
Last week I wrote about the great work that Matthew did and now he’s written up his process:
The important thing is to have a resilient base layer of HTML and CSS, and then to enhance that with JavaScript.
It’s been fascinating to see how television programmes have adapted to The Situation. It’s like there’s been a weird inversion with the YouTube asthetic. Instead of YouTubers doing their utmost to emulate the look of professional television, now everyone on professional television looks like a YouTuber.
No more lighting or audio technicians. No more studio audiences. Heck, no more studios.
There are some kinds of TV programmes that are showing the strain. A lot of comedy formats just fall flat without the usual production values. But a lot of programmes work just fine. In fact, some of them might be better. Watching Mary Beard present Front Row Late from her house is an absolute delight. It feels more direct and honest without the artiface of a television studio. It kind of makes you wonder whether expensive production costs are really necessary when what you really care about is the content.
All of this is one big belaboured metaphor for websites.
In times of crisis, informational websites sometimes offer a “lite” version. Max has even made an emergency website kit:
The site contains only the bare minimum - no webfonts, no tracking, no unnecessary images. The entire thing should fit in a single HTTP request. It’s basically just a small, ultra-lean blog focused on maximum resilience and accessibility. The Service Worker takes it a step further from there so if you’ve visited the site once, the information is still accessible even if you lose network coverage.
Eric emphasises the importance of performance in his post Get Static:
I’m thinking here of sites for places like health departments (and pretty much all government services), hospitals and clinics, utility services, food delivery and ordering, and I’m sure there are more that haven’t occurred to me. As much as you possibly can, get it down to static HTML and CSS and maybe a tiny bit of enhancing JS, and pare away every byte you can.
Tom Loosemore offers this advice to teams building new coronavirus services:
- Get a 4 year-old Android phone, and use it as your test/demo device.
- https://design-system.service.gov.uk is your friend.
- Full React isn’t your friend if it makes your service slow & inaccessible
Remember: This is for everyone.
Indeed, Gov.uk are usually a paragon of best practices in just about any situation. But they dropped the ball recently, as Matthew attests:
coronavirus.data.gov.uk is a static site, fetching and displaying remote data. It is also a 100% client-side JavaScript React site.
http://dracos.co.uk/made/coronavirus.data.gov.uk/ is 238K vs 770K (basics) on load. I’ve removed about 550K of JavaScript. It seems to work the same.
One sign that your website isn’t meeting the needs of all your users is when Matthew Somerville gets sufficiently grumpy about it to do a proper version himself.
It’s true enough that Matthew excels at creating lightweight, accessible versions of services that are too bloated or buggy to use. His accessible Odeon project from back in the day is legendary. And I use his slimline version of the National Rail website all the time: traintimes.org.uk—it’s a terrificly performant progressive web app.
It’s thankless work though. It flies in the face of everything considered “modern” web development. (If you want to know the cost of “modern” framework-driven JavaScript-first web development, Tim has the numbers.) But Matthew is kind of a hero to me. I wish more developers would follow his example.
Maybe now, with this rush to make lightweight versions of valuable services, we might stop and reflect on whether we ever really needed all those added extras in the first place.
Hope springs eternal.
Update: Matthew has written about his process in Looking at coronavirus.data.gov.uk.
Over the past few years, I’ve given quite a few workshops and talks on evaluating technology. This methodical approach to evaluation and prioritisation from Trys is right up my alley!
In any development project, there is a point at which one must decide on the tech stack. For some, that may feel like a foregone conclusion, dictated by team appetite and experience.
Even if the decision seems obvious, it’s always worth sense-checking your thought process. Along with experience and gut-feelings, we also have blind-spots and biases.
I feel like there’s a connection here to having good design principles—the kind that explicitly value one facet over another.
A ludicrously useful grab-bag of prioritisation techniques from Chris—so, so handy for workshops and sprint planning.
Jon’s ranting about Agile here, but it could equally apply to design systems:
Agile and design is like looking at a picture through a keyhole. By slicing big things into smaller things, designers must work incrementally. Its this incrementalism that can lead to what I call the ‘Frankensteining’ of a digital product or service.
Designing your design process:
- Know your strengths and focus resources on your weaknesses.
- Learn to identify the immovable objects.
- What has to be perfect now and what can be fixed later?
Shots fired!
I’ve come to believe that accessibility is not something you do for a small group of people. Accessibility is about promoting inclusion. When the product you use daily is accessible, it means that we all get to work with a greater number and a greater variety of colleagues. Accessibility benefits everyone.
Focusing on the median or average is the equivalent of walking around with a pair of blinders on. We’re limiting our perspective and, in the process, missing out on so much crucial detail. By definition, when we make improving the median or average our goal, we are focusing on optimizing for only about half of our sessions.
Tim does the numbers…
By honing in on the 90th—or 95th or similar—we ensure those weaknesses don’t get ignored. Our goal is to optimize the performance of our site for the majority of our users—not just a small subset of them.
It really, really bothers me that wireframes have evolved from being a prioritisation tool into a layout tool (disempowering UI designers in the process), so I’m happy to see an alternative like this—somewhat like Dan Brown’s Page Description Diagrams.
I’m not great at estimation, but I still try to do it on any project I’m working, even if it’s just for my own benefit. I break down different bits of the work, and ask myself two questions:
If I were smart, I’d plot the answers on a graph. I start doing the important stuff, beginning with whatever won’t take too long. Then I’ve got a choice: either do the stuff that’s not all that important, but won’t take long—or do the stuff that will take quite a while, but is quite important. Finally, there’s stuff that’s not important and will take quite a while to do. I leave that to the end. If it never ends up getting done, it’s not the end of the world.
I guess it’s not really about estimation; it’s more about prioritisation.
Anyway, I’m working on a fun little project right now—the website for one of Clearleft’s many excellent events. There was one particular part of the design that I had estimated would take quite a while to do, so I didn’t get around to it until today. It was a layout that I figured would take maybe half a day of wrangling CSS.
I used CSS grid and I was done in five minutes. That’s not an exaggeration. It was literally five minutes.
I thought to myself, “Well, I want these elements to be arranged in two rows of three columns, but I want that particular one to always be in the last column of the top row.”
Normally my next step would be to figure out how to translate those wishes into floats and clears, or maybe flexbox. But this time, there was almost no translation. I could more or less write the CSS like I would write English.
I want these elements to be arranged in rows of three columns.
display: grid;
grid-template-columns: 1fr 1fr fr
I want that particular one to always be in the last column of the top row.
grid-row: 1;
grid-column: 3;
That was it. I was done.
I think I may need to recalibrate the estimation part of my brain to account for just how powerful CSS grid is.
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.
Andy points one of the potential pitfalls in linearising your content for small screens.