The title is intended to have double meaning. The obvious reference is that CSS is about styling web pages. But the talk also covers some long-term trends looking at ideas that have appear, disappear, and reappear over time. Hence, style as in trends and fashion.
There are some hyperlinks in the transcript but I also published a list of links if you’re interested in diving deeper into some of the topics mentioned in the talk.
I also published the slides but, as usual, they don’t make much sense out of context. They’re on Noti.st too.
It’s kind of interesting to compare the two (well, interesting to me, anyway). The pre-recorded version feels like a documentary. The live version has more a different vibe and it obviously has more audience interaction. I think my style of delivery suits a live audience best.
I almost called the talk The Overview Effect. My main goal with the talk was to instil a sense of perspective. Hence the references to the famous Earthrise photograph.
On the one hand, I wanted the audience to grasp just how far the web has come. So the first half of the talk is a bit of a trip down memory lane, with a constant return to just how much we can accomplish in browsers today. It’s all very positive and upbeat.
Then I twist the knife. Having shown just how far we’ve progressed technically, I switch gears the moment I say:
The biggest challenges facing the World Wide Web today are not technical challenges.
Then I dive into those challenges, as I see them. It turns out that technical challenges would be preferable to the seemingly intractable problems of today’s web.
I almost wish I could’ve flipped the order: talk about the negative stuff first but then finish with the positive. I worry that the talk could be a bit of a downer. Still, I tried to finish on an optimistic note.
Hello, my friends. I’d like us to try to collectively achieve something today. What I’d like us to achieve is a sense of perspective.
To do this we need to take a step back and cast an eye on the past.
For example, I can look back and say “Wow, what a terrible year!”
A year of death. A year of polarisation. Of inequality. A corrupt government. Protests in the street as people struggled to fight against systemic racism.
Yes, I am of course talking about the year 1968.
By the end of 1968, the United States of America was a nation in turmoil. Civil rights. The war in Vietnam. It felt like the polarising issues of the day were splitting the country in two.
But in the final week of the year, something happened that offered a sense of perspective.
In an audacious move, NASA decided to bring forward the schedule of its Apollo programme. Apollo 7 was a success but that mission was confined to Earth orbit. For Apollo 8, human beings would leave Earth’s orbit for the first time in history. The bold plan was to fly to and around the moon before returning safely to Earth.
From today’s perspective, you might just see it as a dry run for Apollo 11 when human beings would step foot on the moon. But at the time, it was an unbelievably bold move. A literal moonshot.
On the winter solstice, December 21st 1968, Jim Lovell, Frank Borman, and Bill Anders were launched on their six day mission to the moon and back.
The mission was a success. Everything went according to plan. But the reason why we remember the Apollo 8 mission today is for something that wasn’t planned.
First of all, after the translunar injection when the crew had left Earth orbit and were on their way to the moon (already the furthest distance ever travelled by our species), someone—probably Bill Anders—pointed a camera back at Earth.
This was the first picture ever taken by a human being of the whole earth. It’s quite a perspective-setting sight, seeing the whole Earth. To us today, it’s almost commonplace. But remember that were was a time when no one had ever seen this view.
In fact, throughout the 1960s activist Stewart Brand had a campaign, handing out buttons with the question, “Why haven’t we seen a photograph of the whole Earth yet?”
I like the “yet” at the end of that. It gives it a conspiracy-tinged edge.
Stewart Brand suspected that if people could see their home planet in one image, it could reset their perspectives. They would truly grok the idea of Spaceship Earth, as Buckminster Fuller would say. The idea came to Brand when he was on a rooftop, tripping on acid, experiencing the horizon curve away from him and giving him quite a sense of perspective.
Later, he would start the Whole Earth Catalog. It was like a print version of Wikipedia, with everything you needed to know to run a commune.
Later still, he went on to found the Long Now Foundation, an organisation dedicated to long-term thinking. I’m a proud member.
Their most famous project is the clock of the long now, which will keep time for 10,000 years. This is just a scale model in the Science Museum in London. The full-size clock is being built inside a mountain on geologically stable ground. Just thinking about the engineering challenges involved is bound to give you a certain sense of perspective.
But let’s snap back from 10,000 in the future to that Apollo 8 mission in December of 1968.
This picture of the whole earth wasn’t the most important picture taken by Bill Anders on that flight. By Christmas Eve, the crew had reached the moon and successfully entered lunar orbit.
Oh my God! Look at that picture over there! There’s the Earth coming up. Wow, that’s pretty.
Hey, don’t take that, it’s not scheduled.
You got a color film, Jim? Hand me that roll of color quick, would you…
Oh man, that’s…
This is what Bill Anders captured.
I could try to describe it. But they should’ve sent a poet.
Fifty years later, this poet puts it beautifully. This is Amanda Gorman’s poem Earthrise.
On Christmas Eve, 1968, astronaut Bill Anders Snapped a photo of the earth As Apollo 8 orbited the moon. Those three guys Were surprised To see from their eyes Our planet looked like an earthrise A blue orb hovering over the moon’s gray horizon, with deep oceans and silver skies.
It was our world’s first glance at itself Our first chance to see a shared reality, A declared stance and a commonality;
A glimpse into our planet’s mirror, And as threats drew nearer, Our own urgency became clearer, As we realize that we hold nothing dearer than this floating body we all call home.
Astronauts have been known to experience something called the overview effect. It’s a profound change in perspective that comes from seeing the totality of our home planet in all its beauty and fragility.
The Earthrise photograph gave the world a taste of the overview effect, right at a time when it was most needed.
The World Wide Web
I wonder if it’s possible to get an overview effect for the World Wide Web?
There is no photograph of the whole web. We can’t see the web. We can’t travel into space and look back at our online home.
But we can travel back in time. Let’s travel back to 1945.
That was the year that an article was published in The Atlantic Monthly by Vannevar Bush. He was a pop scientist of his day, like Neil de Grasse Tyson or Bill Nye.
The article was called As We May Think. In the article, Bush describes a hypothetical device called a memex.
Imagine a desk filled with reams and reams of microfilm. The operator of this device can find information and also make connections between bits of information, linking them together in whatever way makes sense to them.
This sounds a lot like hypertext. That word would be coined decades later by Ted Nelson to describe “text which is not constrained to be linear.”
Vannevar Bush’s idea of the memex and Ted Nelson’s ideas about hypertext would be a big influence on Tim Berners-Lee, the creator of the World Wide Web.
But his big breakthrough wasn’t just making hypertext into a reality. Other people had already done that.
Douglas Engelbart, who wanted to make the computer equivalent of the memex, had already demonstrated a working hypertext system in 1968 in an astonishing demonstration that came to be known as The Mother Of All Demos.
The idea of hypertext was kind of like a choose-your-own-adventure book. Individual pieces of text in a book are connected with unique identifiers and you can jump from one piece of text to another within the same book.
But what if you could jump between books? That’s the other piece of the puzzle.
The idea of connecting computers together came from the concept of “time sharing” allowing you to remotely access another computer.
With funding from the US Department of Defence’s Advance Research Projects Agency, time sharing was taken to the next level with the creation of a computer network called the ARPANET.
It grew. And it grew. Until it was no longer just a network of computers. It was a network of networks. Or internetwork. Internet, for short.
Tim Berners-Lee took the infrastructure of the internet and mashed it up with the idea of hypertext. Instead of imagining hypertext as a book with interconnected concepts, he imaged a library of books where you could jump from one idea in one book to another idea in a completely different book in a completely different part of the library.
This was the World Wide Web. And Tim Berners-Lee called it the World Wide Web even when it only existed on his computer. You have to admire the chutspah of that!
But the really incredible thing is that it worked! In March of 1989 he proposed a global hypertext system, where anybody could create new pages without asking anyone for permission, and anyone could access those pages no matter what kind of device or operating system they were using.
And that’s what we have today. While the World Wide Web might seem inevitable in hindsight, it was anything but. It is a remarkable achievement.
The World Wide Web was somewhat lacking in colour originally. When I started making websites in the mid nineties, colour had arrived but it was limited.
When I started making websites in the mid nineties, colour had arrived but it was somewhat limited.
We had a palette of 216 web safe colours. You knew if a colour was “web safe” if the hexadecimal notation was three sets of duplicated values. If you altered one of those values even slightly, there was no guarantee that the colour would display consistently on the monitors of the time.
I have a confession to make: I kind of liked this constraint in a weird way. To this day, if I have a colour value that’s almost web-safe, I can’t resist nudging it slightly.
Fortunately, monitors improved. They got flatter for one thing. They were also capable of displaying plenty of colours.
And we also got more and more ways of specifying colours. As well as hexadecimal, we got RGB: Red, Green, Blue. Better yet, we got RGBa …with alpha transparency. That’s opacity to you and me.
Then we got HSL: hue, saturation, lightness. Or should I say HSLa: hue, saturation, lightness, and alpha transparency.
And there are more colour spaces on the way. HWB (hue, whiteness, blackness), LAB, LCH. And there’s work on a color() function so you can specify even more colour spaces.
In the beginning, typography on the World Wide Web was non-existent. Your browser used whatever was available on your operating system.
That situation continued for quite a while. You’d have to guess which fonts were likely to be available on Windows or Mac.
If you wanted to use a sans-serif typeface, there was Arial on Windows and Helvetica on the Mac. Verdana was a pretty safe bet too.
For a while your only safe option for a serif typeface was Times New Roman. When Mathew Carter’s Georgia was released, it was a godsend. Here was a typeface specifically designed for the screen.
Later Microsoft released another four fonts designed for the screen. Four new fonts! It felt like we were being spoiled.
But what if you wanted to use a typeface that didn’t come installed with an operating system? Well, you went into Photoshop and made an image of the text. Now the user had to download additional images. The text wasn’t selectable and it was a fixed width.
We came up with all sorts of clever techniques to do what was called “image replacement” for text. Some of the techniques involved CSS and background images. One of the techniques involved Flash. It was called sIFR: Scalable Inman Flash Replacement. A later technique called Cufón converted the letter shapes into paths in Canvas.
All of these techniques were hacks. Very clever hacks, but hacks nonetheless. They were clever and they worked but they always reminded me of Samuel Johnson’s description of a dog walking on its hind legs:
It is not done well but you are surprised to find it done at all.
What if you wanted to use an actual font file in a web page?
There was only one browser that supported font embedding: Microsoft’s Internet Explorer. The catch was that you had to use a proprietary font format called Embedded Open Type.
Both type foundries and browser makers were nervous about allowing regular font files to be embedded in web pages. They were worried about licensing. Wouldn’t this lead to even more people downloading fonts illegally? How would the licensing be enforced?
The impasse was broken with a two-pronged approach. First of all, we got a new font format called Web Open Font Format or WOFF. It could be used to take a regular font file and wrap it in a light veneer of metadata about licensing. There’s a sequel that’s even better than the original, WOFF2.
The other breakthrough was the creation of intermediary services like Typekit and Fontdeck. They would take care of serving the actual font files, making sure they couldn’t be easily downloaded. They could also keep track of numbers to ensure that type foundries were being compensated fairly.
Over time it became clear to type foundries that most web designers wanted to do the right thing when it came to licensing fonts. And so these days, you can probably license a font straight from a type foundry for use on the web and host it yourself.
You might need to buy a few different weights. Regular. Bold. Maybe italic. What about extra bold? Or a light weight? It all starts to add up, especially for the end user who has to download all those files.
I remember being at the web typography conference Ampersand years ago and hearing a talk from Nick Sherman. He asked us to imagine one single font file that could go from light to regular to bold and everything in between. What he described sounded like science fiction.
It is now science fact, indistinguishable from magic. Variable fonts are here. You can typeset text on the web to be light, or regular, or bold, or anything in between.
When you use CSS to declare the font-weight property, you can use keywords like “normal” or “bold” but you can also use corresponding numbers like 400 or 700. There’s a scale with nine options from 100 to 900. But why isn’t the scale simply one to nine?
Well, even though the idea of variable fonts would have been pure fantasy when this part of CSS was being specced, the authors had some foresight:
One of the reasons we chose to use three-digit numbers was to support
intermediate values in the future.
With the creation of variable fonts, Håkon Wium Lee added:
And the future is now.
On today’s web you could have 999 font-weight options.
In the beginning, the World Wide Web was a medium for text only. There were no images and certainly no videos.
In an early mailing list discussion, there was talk of creating a new HTML element for images. Perhaps it should be called “icon”. Or maybe it should be more generic and be called “embed”. Tim Berners-Lee said he imagined using the rel attribute on the A element for embedding images.
While this discussion was happening, Marc Andreessen popped in to say that he had just shipped a new HTML element in the Mosaic browser. It’s called IMG and it takes an attribute called SRC that points to the source of the image.
This was a self-closing tag so there was no way to put fallback content in between the opening and closing tags if the image couldn’t be displayed. So the ALT attribute was introduced instead to provide an alternative description of the image.
For the images themselves, there were really only two choices. JPG for photographic images. GIF for icons or anything that needed basic transparency. GIFs could also do animation and today, that’s pretty much all they’re used for. That’s because there was a concerted campaign to ditch the GIF format on the web. Unisys, who owned the rights to a compression algorithm used by the GIF format, had started to make noises about potentially demanding license fees for its use.
The Portable Network Graphics format—or PNG—was created in response. It was more performant and it allowed you to have proper alpha transparency.
These were all bitmap formats. What if you wanted a vector format for images that would retain crispness at any size or resolution? There was only one option: Flash. You’d have to embed a Flash movie in your web page just to get the benefit of vector graphics.
By the 21st century there were some eggheads working on a text-based vector file format that could be embedded in webpages, but it sounded like a pipe dream. It was called SVG for Scalable Vector Graphics. The format was dreamed up in 2001 but for years, not a single browser supported it. It was like some theoretical graphical Shangri-La.
But by 2011, every major browser supported it. Styleable, scriptable, animatable, vector graphics have gone from fantasy to reality.
There’s more choice in the world of bitmap images too. WebP is well supported. AVIF is is gaining support.
These elements have been designed with more thought than the IMG element. They are not self-closing elements, by design. You can put fallback content between the opening and closing tags.
The audio and video elements arrived long after the IMG element. For a long time, there was no easy way to do video or audio on the web.
That was very frustrating for me. The first websites I ever built were for bands. The only way to stream music was with a proprietary plug-in like Real Audio.
While the web standards were still being worked on, Flash delivered the goods with streaming audio and video. This happened over and over. Flash gave us vector graphics, animation, video, and more. But the price was lock-in. Flash was a proprietary format.
Still, Flash showed the web standards bodies the direction of travel. Flash was the hare. Web standards were the tortoise.
We know how that race ended.
In a way, Flash was like the Research and Development incubator for the World Wide Web. We got CSS animations, SVG, and streaming video because Flash showed that there was an appetite for them.
Until web standards provide a way to do something, designers and developers will reach for whatever tool gets the job done. Take layout, for example.
In the early days of the web, you could have any layout you wanted …as long as it was a single column.
Before long, HTML expanded to provide some rudimentary formatting for that single column of text. Presentational elements and attributes were invented. And even when elements and attributes weren’t meant to be used for formatting, people got creative.
Tables for layout. A single pixel GIF that could be given width and height. These were clever solutions. But they were hacks. And they were in danger of turning HTML into a presentational language instead of a language for structuring content.
CSS came to the rescue. A language specifically for presentation.
But we still didn’t get proper layout tools. There was a lot of debate in the early days about whether CSS should even attempt to provide layout tools or whether that was a job for a separate technology.
We could lay things out using the float property, but really that was just another hack.
Floats were an improvement over tables for layout, but we only swapped one tool for another. Our collective thinking still wasn’t very web-like.
For example, designers and developers insisted on building websites with a fixed width. This started in the era of table layouts and carried over into CSS.
To start with, the fixed width was 640 pixels. Then it was 800 pixels. Then people settled on the magical number of 960 pixels. Designers and developers didn’t seem at all concerned that people had different sized screens.
That was until the iPhone came out. It caused a panic. What fixed width were we supposed to design for now?
The answer was there all along. Even before the web appeared in mobile devices, it was possible to build fluid layouts that would adapt to screen size. It’s just that the majority of designers and developers chose not to build in this way.
I was pleased that mobile came along and shook things up. It exposed the assumptions that people were making. And it forced designers and developers to think in a more fluid, webby way.
Even better, CSS had expanded to include media queries so it was possible to alter layouts at different breakpoints.
Ethan came along and put a nice bow on it with his definition of responsive design: fluid media, fluid layouts, and media queries.
I fell in love with responsive web design instantly becuase it matched how I was already thinking about the web. I was one of the handful of weirdos who insisted on building fluid websites when everyone else was using fixed-width layouts.
But I thought that responsive web design would struggle to take hold.
I’m delighted to say that I was wrong. Responsive web design has become the default!
If I could go back to my past self in the mid 2000s, I’d love to tell them that in the future, everyone would be building with fluid layouts (and also that time travel had been invented apparently).
Not only that, but we finally have proper layout tools for the web. Flexbox. Grid. No more hacks. We’re even getting container queries soon (thanks, Miriam!).
Web browsers now are positively overflowing with fantastic design tools that would have been unimaginable to my past self. Support for these technologies is pretty much universal.
When browsers differ today, it’s only terms of which standards they don’t yet support. There was a time when browsers differed massively in how they handled basic web technologies.
There was a time when being a web developer meant understanding all the different quirks between browsers.
And browser makers spent a ludicrous amount of time reverse-engineering the quirky behaviour of whichever browser was the market leader.
That changed with HTML5. We remember HTML5 for introducing new APIs, new form fields, and new structural elements. But the biggest innovation was completely invisible. For the first time, error-handling was standardised. Browsers had a set of rules they could work from. Once browsers adopted this consistent approach to error-handling, cross-browser differences dried up.
In the beginning, there was no scripting on the web, just like there was no styling. Tim Berners-Lee wasn’t opposed to the idea of executing arbitrary code on the web. But he pointed out that you’d need everyone to agree on which programming language browsers would use.
You need something really powerful, but at the same time ubiquitous. Remember a facet of the web is universal readership. There is no universal interpreted programming language.
The important thing is that multiple browsers implemented it. Then the hype started. We were told about this great new technology called DHTML. The D stood for dynamic! This would allow us to programmatically manipulate elements in a web page.
But… the two major browsers at the time, Netscape Navigator and Internet Explorer, used two completely incompatible syntaxes.
For Netscape Navigator you’d use document.layers. For Internet Explorer it was document.all.
This was when developers said enough was enough. We wanted standards. The Web Standards Project was formed and we lobbied browser makers to implement web standards, like CSS and also the Document Object Model. This was a standardised way of manipulating elements in a web page. You could use methods like getElementById and getElementsByTagName.
That worked fine, but it was yet another vocabulary to learn. If you already knew CSS, then you already understood how to get an element by ID and get elements by tag name, but with a different syntax.
Now we no longer need jQuery. We’ve got querySelector and querySelectorAll. But the reason we no longer need jQuery is because of jQuery. Just like Flash, jQuery showed what developers wanted. And just as with Flash, the web standards took more time. But now jQuery is obsolete …precisely because it was so successful.
It’s a similar story with Sass and CSS. There was a time when Sass was the only way to have a feature like variables. But now with custom properties available in CSS, Sass is becoming increasingly obsolete …precisely because it was so successful and showed the direction of travel.
But some capabilities can’t be polyfilled. If a browser doesn’t provide API access to a particular sensor, for example, there’s no way to spackle that gap.
For quite a while, if you wanted access to device APIs, you’d have to build a native app. But over time, that has changed. Now browsers are capable of providing app-like experiences. You can get location data. You can access the camera. You can provide notifications. You can even make websites work offline using service workers.
Native apps had all these capabilities before web browsers. Just as with Flash and jQuery, native apps pointed the way. The gap always looks insurmountable to begin with. But over time, the web always manages to catch up.
At the beginning of 2021, Ire said:
By the end of the year, I would predict that any major native mobile application could be instead built using native web capabilities.
The web has come along way. It has grown and evolved. Browsers have become more and more powerful while maintaining backward compatibility.
In the past we had to hack our way around the technological limitations of the web and we had a long wish list of features we wanted.
I’m not saying we’re done. I’m sure that more features will keep coming. But our wish list has shrunk.
The biggest challenges facing the World Wide Web today are not technical challenges.
Today it is possible to create beautiful websites that make full use of colour, typography, layout, animation, and more. But this isn’t what users experience.
This is what users experience. A tedious frustrating game of whack-a-mole with websites that claim to value our privacy while asking us to relinquish it.
This is not a technical problem. It is a design decision. The decision might not be made by anyone with designer in their job title, but make no mistake, business decisions have a direct effect on user experience.
On the face of it, the problem seems to be with the business model of advertising. But that’s not quite right. To be more precise, the problem is with the business model of behavioural advertising. That relies on intermediaries to amass huge amounts of personal data so that they can supposedly serve up relevant advertising.
But contextual advertising, which serves up ads based on the content you’re looking at doesn’t require the invasive collection of personal data. And it works. Behavioural advertising, despite being a huge industry that depends on people giving up their privacy, doesn’t even work very well. And on the few occasions when it does work, it just feels creepy.
The problem is not advertising. The problem is tracking. The greatest trick the middlemen ever pulled was convincing us that you can’t have effective advertising without tracking. That is false. But they’ve managed to skew our sense of perspective so that invasive advertising seems inevitable.
Advertising was always possible on the web. You could publish anything and an ad is just one more thing you could choose to publish. But tracking was impossible. That’s because the early web was stateless. A browser requests a resource from a server and once that transaction is done, they both promptly forget about it. That made it very hard to do things like online shopping or logging into an account.
Perhaps none of this applies to you anyway. You may be thinking that this is a problem for websites. But you build web apps.
But the phrase “single page app” has a more definite meaning. It refers to an architectural decision. That decision is to reinvent the web browser inside a web browser.
I think there’s a certain mindset being applied to web development here. And that mindset comes from the world of software. Again, it’s a testament to how far the web has come that it can be treated as a software platform on par with operating systems like iOS, Android, or Windows. There’s a lot to be learned from the world of software development, like testing, for example. But the web is different. When a user navigates to a URL, it shouldn’t feel like they’re installing a piece of software.
We should be aiming to keep our payloads as small as possible. And given how powerful browsers have become, we need fewer and fewer dependencies—fewer and fewer polyfills.
When asked to justify the enormous payloads, web developers have responded by saying that user’s expectations have changed. That is correct, but not in the way that I think they mean.
When I talk to people about using the web—especially on mobile—their expectations are that they will have a terrible experience. That websites will be slow to load. And I guarantee you that none of them are saying, “Well I’d be annoyed if this were a website but seeing as this is a web app, I’m absolutely fine with this terrible experience.”
I said that the biggest challenges facing the World Wide Web today are not technical challenges. I think the biggest challenge facing the web today is people’s expectations.
There is no technical reason for websites or web apps to be so frustrating. But we have collectively led people to expect a bad experience on the web.
There’s a great German word, “Verschlimmbessern”: the act of making something worse in the attempt to make it better. Perhaps we verschlimmbessert the web.
Stop solving problems you don’t yet have.
Lean into what web browsers can accomplish today. If you find something missing, that’s the time to reach for a library …but treat it like a polyfill. Whereas web standards stick around, every library and framework comes with a limited lifespan. Treat them as cattle, not pets.
I understand that tools and frameworks can make your life easier. And if we’re talking about server-side frameworks, then I say “Go for it.” Or if you’re using build tools that sit on your computer to do version control, linting, pre-processing, or transpiling, then I say “Go for it.”
But once you make users download tools or frameworks, you’re making them pay a tax for your developer convenience.
We need to value user needs above developer convenience. If I have the choice of making something the user’s problem or making it my problem, I’ll make it my problem every time. That’s my job.
We need to change people’s expectations of the World Wide Web, especially on mobile. Otherwise, the web will be lost.
Two years ago, I had the great honour of being invited to CERN to mark the 30th anniversary of the original proposal for the World Wide Web. One of the other people there was the journalist Zeynep Tüfekçi. She was on a panel along with Tim Berners-Lee and other luminaries of the early web. At the end of the panel discussion, she was asked:
What would you tell the next generation about how to use this wonderful tool?
If you have something wonderful, if you do not defend it, you will lose it. If you do not defend the magic and the things that make it wonderful,
it’s just not going to stay magical by itself.
I believe that we can save the web. I believe that we can change people’s expectations. We’ll do that by showing them what the web is capable of.
It sounds like a moonshot. But, y’know, moonshots aren’t made possible by astronauts. They’re made possible by people like Poppy Northcutt in mission control. Katherine Johnson running the numbers. And Margaret Hamilton inventing the field of software engineering to create the software for the lunar lander. Individual people working together on something bigger than any one person.
There’s a story told about the first time President Kennedy visited NASA. While he was a getting a tour of the place, he introduced himself to a janitor. And the president asked the janitor what he did. The janitor answered:
I’m helping put a man on the moon.
It’s the kind of story that’s trotted out by company bosses to make you feel good about having your labour exploited for the team. But that janitor’s loyalty wasn’t to NASA, an organisation. He was working for something bigger.
I encourage you to have that sense of perspective. Whatever company or organisation you happen to be working for right now, remember that you are building something bigger.
The future of the World Wide Web is in good hands. It’s in your hands.
I wrote about preparing this talk and you can see the outline on Kinopio. I thought it turned out well, but I never actually know until people see it. So I’m very gratified and relieved that it went down very well indeed. Phew!
Eric and the gang at An Event Apart asked for a round-up of links related to this talk and I was more than happy to oblige. I’ve separated them into some of the same categories that the talk covers.
I know that these look like a completely disconnected grab-bag of concepts—you’d have to see the talk to get the connections. But even without context, these are some rabbit holes you can dive down…
If you want to see the finished results, come along to An Event Apart Spring Summit on April 19th. To sweeten the deal, I’ve got a discount code you can use when you buy any multi-day pass: AEAJEREMY.
Recording the talk took longer than I thought it would. I think it was because I said this:
It feels a bit different to prepare a talk for pre-recording rather than live delivery on stage. In fact, it feels less like preparing a conference talk and more like making a documentary.
Once I got that idea in my head, I think I became a lot fussier about the quality of the recording. “Would David Attenborough allow his documentaries to have the sound of a keyboard audibly being pressed? No! Start again!”
I’m pleased with the final results. And I’m really looking forward to the post-presentation discussion with questions from the audience. The talk gets provocative—and maye a bit ranty—towards the end so it’ll be interesting to see how people react to that.
It feels good to have the presentation finished, but it also feels …weird. It’s like the feeling that conference organisers get once the conference is over. You spend all this time working towards something and then, one day, it’s in the past instead of looming in the future. It can make you feel kind of empty and listless. Maybe it’s the same for big product launches.
The two big projects I’ve been working on for the past few months were this talk and season two of the Clearleft podcast. The talk is in the can and so is the final episode of the podcast season, which drops tomorrow.
On the one hand, it’s nice to have my decks cleared. Nothing work-related to keep me up at night. But I also recognise the growing feeling of doubt and moodiness, just like the post-conference blues.
The obvious solution is to start another big project, something on the scale of making a brand new talk, or organising a conference, or recording another podcast season, or even writing a book.
The other option is to take a break for a while. Seeing as the UK government has extended its furlough scheme, maybe I should take full advantage of it. I went on furlough for a while last year and found it to be a nice change of pace.
As it happens, I’m preparing a conference talk right now for delivery online. Am I taking my advice about how to put a talk together? I am on me arse.
Perhaps the most important part of the process I shared with Hana is that you don’t get too polished too soon. Instead you get everything out of your head as quickly as possible (probably onto disposable bits of paper) and only start refining once you’re happy with the rough structure you’ve figured out by shuffling those bits around.
But the way I’ve been preparing this talk has been more like watching a progress bar. I started at the start and even went straight into slides as the medium for putting the talk together.
It was all going relatively well until I hit a wall somewhere between the 50% and 75% mark. I was blocked and I didn’t have any rough sketches to fall back on. Everything was a jumbled mess in my brain.
It all came to a head at the start of last week when that jumbled mess in my brain resulted in a very restless night spent tossing and turning while I imagined how I might complete the talk.
This is a terrible way of working and I don’t recommend it to anyone.
The problem was I couldn’t even return to the proverbial drawing board because I hadn’t given myself a drawing board to return to (other than this crazy wall of connections on Kinopio).
My sleepless night was a wake-up call (huh?). The next day I forced myself to knuckle down and pump out anything even if it was shit—I could refine it later. Well, it turns out that just pumping out any old shit was exactly what I needed to do. The act of moving those fingers up and down on the keyboard resulted in something that wasn’t completely terrible. In fact, it turned out pretty darn good.
The idea here is to get everything out of my head.
I should’ve listened to that guy.
At this point, I think I’ve got the talk done. The progress bar has reached 100%. I even think that it’s pretty good. A giveaway for whether a talk is any good is when I find myself thinking “Yes, this has good points well made!” and then five minutes later I’m thinking “Wait, is this complete rubbish that’s totally obvious and doesn’t make much sense?” (see, for example, every talk I’ve ever prepared ever).
Now I just to have to record it. The way that An Event Apart are running their online editions is that the talks are pre-recorded but followed with live Q&A. That’s how the Clearleft events team have been running the conference part of the Leading Design Festival too. Last week there were three days of this format and it worked out really, really well. This week there’ll be masterclasses which are delivered in a more synchronous way.
It feels a bit different to prepare a talk for pre-recording rather than live delivery on stage. In fact, it feels less like preparing a conference talk and more like making a documentary. I guess this is what life is like for YouTubers.
I think the last time I was in a cinema before The Situation was at the wonderful Duke of York’s cinema here in Brighton for an afternoon showing of The Proposition followed by a nice informal chat with the screenwriter, one Nick Cave, local to this parish. It was really enjoyable, and that’s kind of what Leading Design Festival felt like last week.
I wonder if maybe we’ve been thinking about online events with the wrong metaphor. Perhaps they’re not like conferences that have moved online. Maybe they’re more like film festivals where everyone has the shared experience of watching a new film for the first time together, followed by questions to the makers about what they’ve just seen.
Trying to predict the future is a discouraging and hazardous occupation becaue the profit invariably falls into two stools. If his predictions sounded at all reasonable, you can be quite sure that in 20 or most 50 years, the progress of science and technology has made him seem ridiculously conservative. On the other hand, if by some miracle a prophet could describe the future exactly as it was going to take place, his predictions would sound so absurd, so far-fetched, that everybody would laugh him to scorn.
This is probably more of a hope than a prediction, but 2021 could be the year that the ponzi scheme of online tracking and surveillance begins to crumble. People are beginning to realize that it’s far too intrusive, that it just doesn’t work most of the time, and that good ol’-fashioned contextual advertising would be better. Right now, it feels similar to the moment before the sub-prime mortgage bubble collapsed (a comparison made in Tim Hwang’s recent book, Subprime Attention Crisis). Back then people thought “Well, these big banks must know what they’re doing,” just as people have thought, “Well, Facebook and Google must know what they’re doing”…but that confidence is crumbling, exposing the shaky stack of cards that props up behavioral advertising. This doesn’t mean that online advertising is coming to an end—far from it. I think we might see a golden age of relevant, content-driven advertising. Laws like Europe’s GDPR will play a part. Apple’s recent changes to highlight privacy-violating apps will play a part. Most of all, I think that people will play a part. They will be increasingly aware that there’s nothing inevitable about tracking and surveillance and that the web works better when it respects people’s right to privacy. The sea change might not happen in 2021 but it feels like the water is beginning to swell.
Still, predicting the future is a mug’s game with as much scientific rigour as astrology, reading tea leaves, or haruspicy.
I really, really missed speaking at conferences in 2020. I managed to squeeze in just one meatspace presentation before everything shut down. That was in Nottingham, where myself and Remy reprised our double-bill talk, How We Built The World Wide Web In Five Days.
Giving a talk online is …weird. It’s very different from public speaking. The public is theoretically there but you feel like you’re just talking at your computer screen. If anything, it’s more like recording a podcast than giving a talk.
I’d like to take you back in time, just over 100 years ago, at the beginning of World War One. It’s 1914. The United States would take another few years to join, but the European powers were already at war in the trenches, as you can see here.
What I want to draw your attention to is what they’re wearing, specifically what they’re wearing on their heads. This is the standard issue for soldiers at the beginning of World War One, a very fetching cloth cap. It looks great. Not very effective at stopping shrapnel from ripping through flesh and bone.
It wasn’t long before these cloth caps were replaced with metal helmets; much sturdier, much more efficient at protection. This is the image we really associate with World War One; soldiers wearing metal helmets fighting in the trenches.
Now, an interesting thing happened after the introduction of these metal helmets. If you were to look at the records from the field hospitals, you would see that there was an increase in the number of patients being admitted with severe head injuries after the introduction of these metal helmets. That seems odd and the only conclusion that we could draw seems to be that cloth helmets are actually better than the metal helmets at stopping these kind of injuries. But that wouldn’t be correct.
You can see the same kind of data today. Any state where they introduce motorcycle helmet laws saying it’s mandatory to wear motorcycle helmets, you will see an increase in the number of emergency room admissions for severe head injuries for motorcyclists.
Now, in both cases, what’s missing is the complete data set because, yes, while in World War One there was an increase in the field hospital admissions for head injuries, there was a decrease in deaths. Just as today, if there’s an increase in emergency room admissions for severe head injuries because of motorcycle helmets, you will see a decrease in the number of people going to the morgue.
I kind of like these stories of analytics where there’s a little twist in the tale where the obvious solution turns out not to be the correct answer and our expectations are somewhat subverted. My favorite example of analytics on the web comes from a little company called YouTube. This is from a few years back.
Chris set about working on making a smaller version of a video page. He called this Project Feather. He worked and worked at it, and he managed to get a page down to just 98 kilobytes, so from 1.2 megabytes to 98 kilobytes. That’s an order of magnitude difference.
Then he set up shipping this to different segments of the audience and watching the analytics to see what rolled in. He was hoping to see a huge increase in the number of people engaging with the content. But here’s what he blogged.
The average aggregate page latency under Feather had actually increased. I had decreased the total page weight and number of requests to a tenth of what they were previously and somehow the numbers were showing that it was taking longer for videos to load on Feather, and this could not be possible. Digging through the numbers more (and after browser testing repeatedly), nothing made sense.
I was just about to give up on the project with my world view completely shattered when my colleague discovered the answer: geography. When we plotted the data geographically and compared it to our total numbers (broken out by region), there was a disproportionate increase in traffic from places like Southeast Asia, South America, Africa, and even remote regions of Siberia.
A further investigation revealed that, in those places, the average page load time under Feather was over two minutes. That means that a regular video page (at over a megabyte) was taking over 20 minutes to load.
Again, what was happening here was that there was a whole new set of data. There were people who literally couldn’t even load the page because it would take 20 minutes who couldn’t access YouTube who now, because of this Project Feather, for the first time were able to access YouTube. What that looked like, according to the analytics, was that page load time had overall gone up. What was missing was the full data set.
I really like these stories that kind of play with our expectations. When the reveal comes, it’s almost like hearing the punchline to a joke, right? Your expectations are set up and then subverted.
Jeff Greenspan is a comedian who talks about this. He talks about expectations in terms of music and comedy. He points out that they both deal with expectations over time.
In music, the pleasure comes from your expectations being met. A song sets up a rhythm. When that rhythm is met, that’s pleasurable. A song is using a particular scale and when those notes on that scale are hit, it’s pleasurable. Music that’s not fun to listen to tends to be arhythmic and atonal where you can’t really get a handle on what’s going to come next.
Comedy works the other way where it sets up expectations and then pulls the rug out from under you — the surprise.
Now, you can use music and you can use comedy in your designs. If you were setting up a lovely grid and a vertical rhythm, that’s like music. It’s a lovely, predictable feeling to that. But you can also introduce a bit of comedy; something that peeks out from the grid. You upset (just occasionally) something with a bit of subverted expectations.
You don’t want something that’s all music. Maybe that’s a little boring. You don’t want something that’s all comedy because then it’s just crazy and hard to get a handle on.
You can see music and comedy in how you consume news. You notice that when you read your news sources, all it does is confirm what you already believe. You read something about someone, and you think, “Yes, they’ve done something bad and I always thought they were bad, so that has confirmed my expectations.” It’s like music.
I read something that somebody has done and I always thought they were a good person. This now confirms that they are a good person. That is music to my ears. If your news feels like that, feels like music, then you may be in a bubble.
The comedy approach to music would be more like the clickbait you see at the bottom of the Internet where it’s like, “Click here. You won’t believe what these child stars look like now.” The promise there is that we will subvert your expectations, and that’s where the pleasure will come.
My favorite story from history about analytics is not from World War One but from the sequel, World War Two, where again the United States were a few years late to this world war. But when they did arrive and started their bombing raids on Germany, they were coming from England. The bombers would come back all shot up, and so there was a whole thinktank dedicated to figuring out how we can reinforce these planes in certain areas.
You can’t reinforce the whole plane. That would make it too heavy, but you could apply some judicious use of metal reinforcement to protect the plane.
They treated this as a data problem, as an analytics problem. They looked at the planes coming back. They plotted where the bullet holes were, and that led them to conclude where they should put the reinforcements. You can see here that the wings were getting all shot up, the middle of the fuselage, so clearly that’s where the reinforcements should go.
There was a statistician, a mathematician named Abraham Wald. He looked at the exact same data and he said, “No, we need to reinforce the front of the plane where there are no bullet holes. We need to reinforce the back of the fuselage where there are no bullet holes.”
What he realized was that all the data they were seeing was actually a subset of the complete data set. They were only seeing the planes that made it back. What was missing were all the planes that got shot down. If all the planes that made it back didn’t have any bullet holes in the front of the plane, then you could probably conclude that if you get a bullet hole in the front of the plane, you’re not going to make it back.
This became the canonical example of what we now call survivorship bias, which is this tendency to look at the subset of data — the winners.
You see survivorship bias all the time. You walk into a bookstore and you look at the business section and its books by successful business people; that’s survivorship bias. Really, the whole section should be ten times as big and feature ten times as many books written by people who had unsuccessful businesses because that would be a much more representative sample.
We see survivorship bias. You go onto Instagram and you look at people’s Instagram photos. Generally, they’re posting their best life, right? It’s the perfect selfie. It’s the perfect shot. It’s not a representative sample of what somebody’s life looks like. That’s survivorship bias.
We have a tendency to do it on the web, too, when people publish their design systems. Don’t get me wrong. I love the fact that companies are making their design systems public. It’s something I’ve really lobbied for. I’ve encouraged people to do this. Please, if you have a design system, make it public so we can all learn from it.
I really appreciate that people do that, but they do tend to wait until it’s perfect. They tend to wait until they’ve got the success.
What we’re missing are all the stories of what didn’t work. We’re missing the bigger picture of the things they tried that just failed completely. I feel like we could learn so much from that. I feel like we can learn as much from anti-patterns as we can from patterns, if not more so.
Robin Rendle talked about this in a blog post recently about design systems. He said:
The ugly truth is that design systems work is not easy. What works for one company does not work for another. In most cases, copying the big tech company of the week will not make a design system better at all. Instead, we have to acknowledge how difficult our work is collectively. Then we have to do something that seems impossible today—we must publicly admit to our mistakes. To learn from our community, we must be honest with one another and talk bluntly about how we’ve screwed things up.
I completely agree. I think that would be wonderful if we shared more openly. I do try to encourage people to share their stories, successes, and failures.
I organized a conference a few years back all about design systems called Patterns Day and invited the best and brightest: Alla Kholmatova, Jina Anne, Paul Lloyd, Alice Bartlett – all these wonderful people. It was wonderful to hear people come up and sort of reassure you, “Hey, none of us have got this figured out. We’re all trying to figure out what we’re doing here.” The audience really needed to hear that. They really needed to hear that reassurance that this is hard.
Gaps and overlaps
I did Patterns Day again last year. My favorite talk at Patterns Day last year, I think, was probably from Danielle Huntrods. I’m biased here because I used to work with Danielle. She used to work at Clearleft, and she’s an absolutely brilliant front-end developer.
She had this lens that she used when she was talking about design systems and other things. She talked about gaps and overlaps, which is one of those things that’s lodged in my brain. I kind of see it everywhere.
She said that when you’re categorizing things, you’re putting things into categories, that means some things will fall between those categories. That leaves you with the gaps, the things that aren’t being covered. It’s almost like Donald Rumsfeld, the unknown unknowns and all that.
What can also happen when you put things into categories is you get these overlaps where there’s duplication; two things are responsible for the same task. This duplication of effort, of course, is what we’re trying to avoid with design systems. We’re trying to be efficient. We don’t want multiple versions of the same thing. We want to be able to reuse one component. There’s a danger there.
She’s saying what we do with the design system is we concentrate on cataloging these components. We do our interface inventory, but we miss the connective part. We miss the gaps between the components. Really, what makes something a system is not so much a collection of components but how those components fit together, those gaps between them.
Danielle went further. She didn’t just talk about gaps and overlaps in terms of design systems and components. She talked about it in terms of roles and responsibilities. If you have two people who believe they’re responsible for the same thing, that’s going to lead to a clash.
Worse, you’re working on a project and you find out that there was nobody responsible for doing something. It’s a gap. Everyone assumes that the other person was responsible for getting that thing done.
“Oh, you’re not doing that?”
“I thought you were doing that.”
“Oh, I thought you were doing that.”
This is the source of so much frustration in projects, either these gaps or these overlaps in roles and responsibilities. Whenever we start a project at Clearleft, we spend quite a bit of time getting this role mapping correct, trying to make sure there aren’t any gaps and there aren’t any overlaps. Really, it’s about surfacing those assumptions.
“Oh, I assumed I was responsible for that.”
“No, no. I assumed I was the one who would be doing that.”
We clarify this stuff as early as possible in the design process. We even have a game we play called Fluffy Edges. It’s literally like a card game. We’d ask these questions, “Who is responsible for this? Who is going to do this?” It’s kind of good fun, but really it is about surfacing those assumptions and getting clarity on the roles at the beginning of the design process.
The design process
Now, the design process, I’m talking about the design process like it’s this known thing and it really isn’t. It’s a notoriously difficult thing to talk about the design process.
Here’s one way of thinking about the design process. This is The Design Squiggle by Damien Newman. He used to be at IDEO. I actually think this is a pretty accurate representation of what the design process feels like for an individual designer. You go into the beginning and it’s chaos, it’s a mess, and it’s entropy. Then, over time, you begin to get a handle on things until you get to this almost inevitable result at the end.
I’m not sure it’s an accurate representation of what the collaborative design process feels like. There’s a different diagram that resonates a lot with us at Clearleft, which is the Double Diamond diagram from Chris Vanstone at the Design Council. The way of thinking about the Double Diamond is almost like it’s two design squiggles back-to-back.
It’s a bit of an oversimplification, but the idea is that the design process is split into these triangles. First, it’s the discovery. Then we define. So we’re going out wide with discovery. Then we narrow it down with the definition. Then it’s time to build a thing and we open up wide again to figure out how we’re going to execute this thing. Once we got that figured out, we narrow down into the delivery phase.
The way of thinking about this is the first diamond (discovery and definition), that’s about building the right thing. Make sure you’re building the right thing first. The second diamond (about execution and delivery), that’s about building the thing right. Building the right thing and building the thing right.
The important thing is they follow this pattern of going wide and going narrow. This divergent phase with discovery and then convergent for definition. There’s a divergent phase for execution and then convergent for delivery.
If you take nothing else in the Double Diamond approach, it’s this way of making explicit when you’re in a divergent or convergent phase. Again, it’s kind of about servicing that assumption.
“Oh, I assumed we were converging.”
“No, no, no. We are diverging here.”
That’s super, super useful.
I’ll give you an example. If you are in a meeting, at the beginning of the meeting, state whether it’s a divergent meeting or a convergent meeting. If you were in a meeting where the idea is to generate as many ideas as possible during a meeting, make that clear at the beginning because what you don’t want is somebody in the meeting who thinks the point is to converge on a solution.
You’ve got these people generating ideas and then there’s one person going, “No, that will never work. Here’s why. Oh, that’s technically impossible. Here’s why.” No, if you make it clear at the start, “There are no bad ideas. We’re in a divergent meeting,” everyone is on the same page.
Conversely, if it’s a convergent meeting, you need to make that clear and say, “The point of this meeting is that we come to a decision, one decision,” and you need to make that clear because what you don’t want in a convergent meeting is it’s ten minutes to launch time, converging on something, and then somebody in the meeting goes, “Hey, I just had an idea. How about if we…?” You don’t want that. You don’t want that.
If you take nothing else from this, this idea of making divergence and convergence explicit is really, really, really useful. Again, like I say, this pattern of just assumptions being surfaced is so useful.
This initial diamond of the Double Diamond phase, it’s where we spend a lot of our time at Clearleft. I think, early in the years of Clearleft, we spent more time on the second diamond. We were more about execution and delivery. Now, I feel like we deliver a lot more value in the discovery and definition phase of the design process.
There’s so much we do in this initial discovery phase. I mentioned already we have this fluffy edges game we play for role mapping to figure out the roles and responsibilities. We have things like a project canvas we use to collaborate with the clients to figure out the shape of what’s to come.
We sometimes run an exercise called a pre-mortem. I don’t know if you’ve ever done that. It’s like a post-mortem except you do it at the beginning of the project. It’s kind of a scenario planning.
You say, “Okay, it’s so many months after the launch and it’s been a complete disaster. What went wrong?” You map that out. You talk about it. Then once you’ve got that mapped out, you can then take steps to avoid that disaster happening.
Of course, what we do in the discovery phase, almost more than anything else, is research. You can’t go any further without doing the research.
All of these things, all of these exercises, these ways of working are about dealing with assumptions, either surfacing assumptions that we didn’t know were there or turning assumptions into hypotheses that can be tested. If you think about what an assumption is, it kind of goes back to expectations that I was talking about.
Assumptions are expectations plus internal biases. That gives you an assumption. The things that you don’t even realize you believe; they lead to assumptions. This can obviously be very bad. This is like you’ve got blind spots in your assumptions because of your own biases that you didn’t even realize you had.
They’re not necessarily bad things. Assumptions aren’t necessarily bad. If you think about your expectations plus your biases, that’s another way of thinking about your values. What do you hold to be really dear to you? The things that are self-evident to you, those are your values, your internal expectations and biases.
Now, at Clearleft, we have our company values, our core values, the things we believe. I am not going to share the Clearleft values with you. There are two reasons for that.
One is that they’re Clearleft’s values. They are useful for us. That’s for us to know internally.
Secondly, there’s nothing more boring than a company sharing their values with you. I say nothing more boring. Maybe the only thing more boring than a company sharing their values is when a so-called friend tells you about a dream they had and you have to sit there and smile and nod politely while they tell you about something that is only of interest to them.
These values are essentially what give you purpose, whether it’s at an individual level, your personal moral values give you your purpose, or at a company or organization level, you get your purpose – or any endeavor. You think about the founding of a nation-state like the United States of America. You got the Declaration of Independence. That encodes the values. That has the purpose. It’s literally saying, “We hold these truths to be self-evident.” These are assumptions here. That’s your purpose is something like the Declaration of Independence.
Then you get the principles, how you’re going to act. The Constitution would be an example of a collection of principles. These principles must be influenced by the purpose. Your values must influence the principles you’re going to use to act in the world.
Then those principles have an effect on the final patterns, the outputs that you’ll see. In the case of a nation-state like America, I would say the patterns are the laws that you end up with. Those laws come from the principles encoded in the Constitution. The Constitution, those principles in the Constitution are influenced and encoded from the purpose in the Declaration of Independence.
The purpose influences the principles. The principles influence the pattern. This would be true in the case of software as well. You think about the patterns are the final interface elements, the user interface. Those are the patterns. Those have been influenced by the principles of that company, how they choose to act, and those principles are influenced by the purpose of that company and what they believe.
This is why I find principles, in particular, to be fascinating because they sit in the middle. They are influenced by the purpose and they, in turn, influence the patterns. I’m talking about design principles, something I’m really into. I’m so into design principles, I actually have a website dedicated to design principles at principles.adactio.com.
Now, all I do on this website is collect design principles. I don’t pass judgment. I don’t say whether I think they’re good design principles or bad design principles. I just document them. That’s turned out to be a good thing to do over time because sometimes design principles disappear, go away, or get changed. I’ve got a record of design principles from the past.
For example, Google used to have a set of principles called Ten Things We Know to Be True — we know to be true, right? We hold these truths to be self-evident. That’s no longer available on the Google website, those ten things, those ten principles. One of them was, “You can make money without doing evil.” Like I said, that’s gone now. That’s not available on the Google website.
There was another set of design principles from Google that’s also not available anymore. That was called Ten Principles That Contribute to a Googley User Experience. I think we understand why those are no longer available. The sheer embarrassment of saying the word Googley out loud, I think.
I’ll tell you something I notice when I see design principles. Like I say, I catalog them without judgment, but I do have ideas. I think about what makes for good or bad design principles or sets of design principles.
Whenever I see somebody with a list that’s exactly ten principles, I’m suspicious. Like, “Really? That’s such a convenient round number. You didn’t have nine principles that contribute to a Googley user experience? You didn’t have 11 things that we know to be true? It happened to be exactly ten?” It feels almost like a bad code smell to me that it’s exactly ten principles.
Even some great design principles like Dieter Rams, the brilliant designer. He has a fantastic set of design principles called Ten Principles for Good Design. But even there I have to think, “Hmm. That’s a bit convenient, isn’t it, that it’s exactly ten principles for good design? Isn’t it, Dieter?”
Now, just in case you think I’m being blasphemous by sugging that Dieter Rams’ Ten Principles for Good Design is not a good set of design principles, I am not being blasphemous. I would be blasphemous if I pointed out that in the Old Testament, God supposedly delivers 10 commandments, not 9, not 11, exactly 10 commandments. Really, Moses, ten?
Anyway, what I’m talking about here is, like I say, almost like these code smells for design principles. Can we evaluate design principles? Are there heuristics for saying whether a design principle is a good design principle or a bad design principle?
To get meta about this, what I’m talking about is, are there design principles for design principles? I kind of think there are. I think you can evaluate design principles and say that’s a good one or that’s a bad one. You can evaluate them by how useful they are.
Let’s take an example. Let’s say you’ve got a design principle like this:
Make it usable.
That’s a design principle. I think this is a bad design principle. It’s not because I don’t agree with it. It’s actually a bad design principle because I agree with it and everyone agrees with it. It’s so agreeable that it’s hard to argue with and that’s not what a design principle is for.
Design principles aren’t these things to go, “Rah-rah! Yes! I feel good about this.” They are there to kind of surface stuff and have discussions, have disagreements – get it out in the open.
Let’s say we took this design principle, “make it usable”, and it was rephrased to something more contentious. Let’s say somebody had the design principle like:
Usability is more important than profitability.
Ooh! Now we’re talking.
See, I think this is a good design principle. I’m not saying I agree with it. I’m saying it’s a good design principle because what it has now is priority.
We’re saying something is valued more than something else and that’s what you want from design principles is to figure out what the priorities of this organization are. What do they value? How are they going to behave?
I think this is a great phrasing for design principles. If you can phrase a design principle like this:
___, even over ___
Then that’s really going to make it clear what your values are. You can phrase a design principle as:
Usability, even over profitability.
Now you can have that discussion early on about whether everyone is on board with that. If there’s disagreement, you need to hammer that out and figure it out early on in the process.
Here’s another thing about this phrasing that I really like, “blank, even over blank.” It passes another test of a good design principle, which is reversibility. Rather than being a universal thing, a design principle should be reversible for a different organization.
One organization might have a design principle that says “usability, even over profitability,” and another organization, you can equally imagine having a design principle that says, “profitability, even over usability.” The fact that this principle is reversible like that is a good thing. That shows that it’s an effective design principle because it’s about priorities.
In case of conflict, consider users over authors over implementors over theoretical purity.
That’s so good.
First of all, it just starts with, “In case of conflict.” Yes! That is exactly what design principles are for. Again, they’re not there to be like, “Rah-rah! Feel-good design principles.” No, they are there to sort out conflict.
Then, “consider users over authors.” That’s like:
Users, even over authors. Authors, even over implementors. Implementors even over theoretical purity.
Really good stuff.
There are, I think, design principles for design principles, these kind of smell tests that you can run your design principles past and see if they pass or fail.
I talked about how design principles are unique to the organization. The reversibility test kind of helps with that. You can imagine a different organization that has the complete opposite design principles to you.
I do wonder: are there some design principles that are truly universal? Well, there’s kind of a whole category of principles that we treat as universal truths. That’s kind of these laws. They tend to be the eponymous laws. They’re usually named after a person and there’s some kind of universal truth. There are a lot of them out there.
Hofstadter’s law, that’s from Douglas Hofstadter. Hofstadter’s law states:
It always takes longer than you expect, even when you take into account Hofstadter’s law.
That does sound like a universal truth and certainly, my experience matches that. Yeah, I would say Hofstadter’s law feels like a universal design principle.
90% of everything is crap.
Theodore Sturgeon was a science fiction writer and people would poo-poo science fiction and point out that it was crap. He would say, “Yeah, but 90% of science fiction is crap because 90% of everything is crap.” That became Sturgeon’s law.
Yeah, you look at movies, books, and music. It’s hard to argue with Sturgeon’s law. Yeah, 90% of everything is crap. That feels like a universal law.
Here’s one we’ve probably all heard of. Murphy’s law:
Anything that can go wrong will go wrong.
It tends to get treated as this funny thing but, actually, it’s a genuinely useful design principle and one we could use on the web a lot more.
There’s Cole and Cole’s law. You’ve probably heard of that. That’s:
Shredded raw cabbage with a vinaigrette or mayonnaise dressing.
Moving swiftly on, there’s another sort of category of these laws, these universal principles that have a different phrasing, and it’s this idea of a razor. Here it’s being explicit about in case of conflict. Here it’s being explicit saying when you try to choose between two choices, which to choose.
Hanlon’s razor is a famous example that states:
Never attribute to malice that which can be adequately explained by incompetence.
If you’re trying to find a reason for something, don’t go straight to assuming malice. Incompetence tends to be a greater force in the world than malice.
I think it’s generally true, although, there’s also a law by Arthur C. Clarke, Clarke’s third law, which states that, “Any sufficiently advanced technology is indistinguishable from magic.” If you take Clarke’s third law and you mash it up with Hanlon’s razor, then the result is that any sufficiently advanced incompetence is indistinguishable from malice.
Another razor that we hear about a lot is Occam’s razor. This is very old. It goes back to William of Occam. Sometimes it’s misrepresented as being the most obvious solution is the correct solution. We know that that’s not true because we saw in the stories of metal helmets in World War One and motorcycle helmets or the bombers in World War Two or the YouTube videos that it’s not about the most obvious solution.
What Occam’s razor actually states is:
Entities should not be multiplied without necessity.
In other words, if you’re coming up with an explanation for something and your explanation requires that you now have to explain even more things—you’re multiplying the things that need to be explained—it’s probably not the true thing.
If your explanation for something is “aliens did it,” well, now you’ve got to explain the existence of aliens and explain how they got here and all this. You’re multiplying the entities. Most conspiracy theories fail the test of Occam’s razor because they unnecessarily multiply entities.
World Wide Web
These design principles that we can borrow, we’ve got these universal ones we can borrow. I also think maybe we can borrow from specific projects and see things that would apply to us. Certainly, when we’re working on the World Wide Web and we’re building things on the World Wide Web, we could look at the design principles that informed the World Wide Web when it was being built by Tim Berners-Lee, who created the World Wide Web, and Robert Cailliau, who worked with him.
The World Wide Web started at CERN and started life in 1989 as just a proposal. Tim Berners-Lee wrote this really quite boring memo called “Information Management: A Proposal” with indecipherable diagrams on it. This is March 12, 1989. His supervisor Mike Sendall, he later saw this proposal and must have seen the possibility here because he scrawled across the top:
Vague but exciting.
Tim Berners-Lee did get the go-ahead to work on this project, this World Wide Web project, and he created the first web browser. He created the first web server. He created HTML.
You can see the world’s first web server in the Science Museum in London. It’s this NeXTcube. NeXT was the company that Steve Jobs formed after leaving Apple.
I have a real soft spot for this machine because I was very lucky to be invited to CERN last year to take part in this project where we were trying to recreate the experience of using that first web browser that Tim Berners-Lee created on that NeXT machine. You can go to this website worldwideweb.cern.ch and you can see what it feels like to use this web browser. You can use a modern browser with this emulation inside of it. It’s really good fun.
My colleagues were spending their time actually doing the hard work. I spent most of my time working on the website about the project. I built this timeline because I was fascinated about what was influencing Tim Berners-Lee.
It’s kind of easy to look at the 30 years of the web, but I thought it would be more interesting to also look back at the 30 years before the web and see what influenced Tim Berners-Lee when it came to networks, hypertext, and format. Were there design principles that he adhered to?
We don’t have to look far because Tim Berners-Lee himself has published design principles (that he formulated or borrowed from elsewhere) in a document called Axioms of web Architecture. I think he first published this in 1998. These are really useful things that we can take and we can apply when we’re building on the web.
Particularly, now I’m talking about the second diamond of the Double Diamond. When we are choosing how we’re going to execute something or how we’re going to deliver it, building the thing right, that’s when these design principles come in handy.
He was borrowing; Tim Berners-Lee was borrowing from things that had come before, existing creations that the web is built on top of like the Internet and computing. He said:
Principles such as simplicity and modularity are the stuff of software engineering.
So he borrowed those principles about simplicity and modularity.
He also said:
Decentralization and tolerance are the life and breath of the Internet.
Those principles, tolerance and decentralization, they’d proven themselves to work on the Internet. The web is built on top of the Internet. So, it makes sense to carry those principles forward on the World Wide Web.
That principle of tolerance, in particular, is something I think you really see on the web. It comes from the principles underlying the Internet. In particular, this person, Jon Postel, who is responsible for maintaining the Domain Name System, DNS, he has an eponymous law named after him. It’s also called the Robustness Principle or Postel’s law. This law states:
Be conservative in what you send. Be liberal in what you accept.”
Now, he was talking about packet switching on the Internet that if you’re going to send a packet over the Internet, try to make it as well-formed as possible. But on the other hand, when you receive a packet and if it’s got errors or something, try and deal with it. Be liberal in what you can accept.
I see this at work all the time on the web, not just in terms of technical things but in terms of UX and usability. The example I always use is if you’re going to make a form on the web, be conservative in what you send. Send as few form fields as possible down the wire to the end-user. But then when the user is filling out that form, be liberal in what you accept. Don’t make them formulate their telephone number or credit card in a certain format. Be liberal in what you accept.
Be conservative in what you send when it comes from front-end development. This matters. Literally, just in terms of what we’re sending down the wire to the end-user, we should be more conservative in what we send. We don’t think about this enough, just the weight, the sheer weight of things we’re sending.
I was doing some consulting with a client and we did a kind of top four of where the weight was coming from. I think this applies to websites in general.
4: Web fonts
Coming in at number four, we had web fonts. They can get quite weighty, but we have ways of dealing with this now. We’ve got font display in CSS. We can subset our web fonts. Variable fonts can be a way of reducing the size of fonts. So, there are solutions to this. There are ways of handling it.
At number three, images. Images do account for a lot of the sheer weight of the web. But again, we have solutions here. We’ve got responsive images with source set and picture. Using the right format, right? Not using a PNG if you should be using a JPEG, using WebP, using SVGs where possible. We can deal with this. There are solutions out there, as long as we’re aware of it.
We’re seeing that now.
When it comes to choosing a language, there’s a fantastic design principle that Tim Berners-Lee used when he was designing the World Wide Web. It’s the principle of least power. The principle of least power states:
Choose the least powerful language suitable for a given purpose.
That sounds very counterintuitive. Why would you want to choose the least powerful language? Well, in a way, it’s about keeping things simple. There’s another design principle, “Keep it simple, stupid.” KISS.
It’s kind of related to Occam’s razor, not multiplying entities unnecessarily. Choose the simplest language. The simplest language is likely to be more universal and, because it’s simpler, it might not be as powerful but it’ll generally be more robust.
I’ll give you an example. I’ll quote from Derek Featherstone. He said:
He’s absolutely right. This is about robustness here. It’s less fragile.
There’s a set of design principles from the Government Digital Services here in the U.K. and they’re really good design principles. One of them stuck out to me. The design principle itself says:
By way of explanation, they say:
Government should only do what only government can do.
Government shouldn’t try to be all things to all people. Government should do the things where private enterprise can’t do these things. The government has to do these things. The government should only do what only government can do.
I thought that this could be extrapolated out and made into a more universal design principle. You could say:
Any particular technology should only do what only that particular technology can do
If that’s too abstract, let’s formulate it into this design principle:
Or, alternatively, you could use a button and you style it however you want using CSS.
Okay. That seems pretty straightforward and that is a perfect example of the principle of least power. Choose the least powerful language suitable for the purpose.
But then what if you’ve got a drop-down component, selecting an option from a list of options? Well, you could build this using bare minimum HTML. Again, divs, maybe. You style it however you want it to look and you give it that opening and closing functionality. You give it accessibility using ARIA. Now you’ve got to think about making sure it works with a keyboard — all that stuff, all the edge cases.
Or you just use a select element — job done. You style it with CSS …Ah, well, yes, you can style it to a certain degree with CSS, but if you ever try to style the open state of a select element, you’re going to have a hard time.
Now, this is where it gets interesting. What do you care about more? Can you live with that open state not being styled exactly the way you might want it to be styled? If so, yes, choose the least powerful technology. Go with select. But I can kind of start to see why somebody would maybe roll their own in that case.
Do you still pick the least powerful technology here?
This would be kind of the under-engineered approach: to just use the native HTML approach: input type="date", select, button.
What you get with the native approach is you get access. You get that universality by using the least powerful language. There’s more universal support.
What you get by rolling your own is you get much more control. You’re going from the spectrum of least power to most power and that’s also a spectrum going from most available (widest access) to least available but with more control.
You have to decide where your priorities lie. This is where I think, again, we can look at the web and we can take principles from the web.
The web does not value consistency. The web values ubiquity.
That’s the purpose of the web. It’s the universal access. That’s the value encoded into it.
To put this in another way, we could formulate it as:
Ubiquity, even over consistency.
That’s the design principle of the web.
This passes the reversibility test. We can picture other projects that would say:
Consistency, even over ubiquity.
Native apps value consistency, even over ubiquity. iOS apps are very consistent on iOS devices, but just don’t work at all on Android devices. They’re consistent; they’re not ubiquitous.
We saw this in action with Flash and the web. Flash valued consistency, but you had to have the Flash plugin installed, so it was not ubiquitous. It was not universal.
The World Wide Web is about ubiquity, even over consistency. I think we should remember that.
When we look here in the world’s first-ever web browser, we are looking at the world’s first-ever webpage, which is still available at its original URL. That’s incredibly robust.
What’s amazing is you can not only look at the world’s first webpage in the world’s first web browser, you can look at the world’s first webpage in a modern web browser and it still works, which is kind of amazing. If you took a word processing document from 30 years ago and tried to open it in a modern word processing document, good luck. It just doesn’t work that way. But the web values this ubiquity over consistency.
Let’s apply those principles, apply the principle of least power, apply the robustness principle. Value ubiquity even over consistency. Value universal access over control. That way, you can make products and services that aren’t just on the web, but of the web.
Designing and developing on the web can feel like a never-ending crusade against the unknown. Design principles are one way of unifying your team to better fight this battle. But as well as the design principles specific to your product or service, there are core principles underpinning the very fabric of the World Wide Web itself. Together, we’ll dive into applying these design principles to build websites that are resilient, performant, accessible, and beautiful.
To avoid technical difficulties, I’ve pre-recorded the talk. So while that’s playing, I’ll be spamming the accompanying chat window with related links. Then I’ll do a live Q&A.
Should you be interested in the links that I’ll be bombarding the attendees with, I’ve gathered them here in one place (and they’re also on the website of An Event Apart). The narrative structure of the talk might not be clear from scanning down a list of links, but there’s some good stuff here that you can dive into if you want to know what the inside of my head is like.
I remember being at that An Event Apart in Seattle where Ethan first unveiled the phrase and marvelling at how well everything just clicked into place, perfectly capturing the zeitgeist. I was in. 100%.
I’ll be speaking at this online version of An Event Apart on July 20th, giving a brand new talk called Design Principles For The Web—’twould be lovely to see you then!
Designing and developing on the web can feel like a never-ending crusade against the unknown. Design principles are one way of unifying your team to better fight this battle. But as well as the design principles specific to your product or service, there are core principles underpinning the very fabric of the World Wide Web itself. Together, we’ll dive into applying these design principles to build websites that are resilient, performant, accessible, and beautiful.
I was quite nervous about this talk. It’s very different from my usual fare. Usually I have some big sweeping arc of history, and lots of pretentious ideas joined together into some kind of narrative arc. But this talk needed to be more straightforward and practical. I wasn’t sure how well I would manage that brief.
The dates for next year’s Events Apart have been announced, and I’ll be speaking at three of them:
The question is, do I attempt to deliver another practical code-based talk or do I go back to giving a high-level talk about ideas and principles? Or, if I really want to challenge myself, can I combine the two into one talk without making a Frankenstein’s monster?
Come and see me at An Event Apart in 2020 to find out.
You can have a killer style guide website, a great-looking Sketch library, and robust documentation, but if your design system isn’t actually powering real software products, all that effort is for naught. At the heart of a successful design system is a collection of sturdy, robust front-end components that powers other applications’ user interfaces. In this talk, Brad will cover all that’s involved in establishing a technical architecture for your design system. He’ll discuss front-end workshop environments, CSS architecture, implementing design tokens, popular libraries like React and Vue.js, deploying design systems, managing updates, and more. You’ll come away knowing how to establish a rock-solid technical foundation for your design system.
I will attempt to liveblog the Frostmeister…
“Design system” is an unfortunate name …like “athlete’s foot.” You say it to someone and they think they know what you mean, but nothing could be further from the truth.
A design system is a set of rules enforced by culture, process and tooling that govern how your organization creates products.
A design system the story of how an organisation gets things done.
When Brad talks to companies, he asks “Have you got a design system?” They invariably say they do …and then point to a Sketch library. When the focus goes on the design side of the process, the production side can suffer. There’s a gap between the comp and the live site. The heart and soul of a design system is a code library of reusable UI components.
Brad’s going to talk through the life cycle of a project.
He begins with selling in a design system. That can start with an interface inventory. This surfaces visual differences. But even if you have, say, buttons that look the same, the underlying code might not be consistent. Each one of those buttons represents time and effort. A design system gives you a number of technical benefits:
Faster production—less time coding common UI components and more time building real features.
Higher-quality production—bake in and enforce best practices.
Reduce QA efforts—centralise some QA tasks.
Potentially adopt new technologies faster—a design system can help make additional frameworks more managable.
Useful reference—an essential resource hub for development best practices.
Future-friendly foundation—modify, extend, and improve over time.
Once you’ve explained the benefits, it’s time to kick off.
Brad asks “What’s yer tech stack?” There are often a lot of tech stacks. And you know what? Users don’t care. What they see is one brand. That’s the promise of a design system: a unified interface.
How do you make a design system deal with all the different tech stacks? You don’t (at least, not yet). Start with a high priority project. Use that as a pilot project for the design system. Dan talks about these projects as being like television pilots that could blossom into a full season.
Where to build the design system? The tech stack under the surface is often an order of magnitude greater than the UI code—think of node modules, for example. That’s why Brad advocates locking off that area and focusing on what he calls a frontend workshop environment. Think of the components as interactive comps. There are many tools for this frontend workshop environment: Pattern Lab, Storybook, Fractal, Basalt.
How are you going to code this? Brad gets frontend teams in a room together and they fight. Have you noticed that developers have opinions about things? Brad asks questions. What are your design principles? Do you use a CSS methodology? What tools do you use? Spaces or tabs? Then Brad gets them to create one component using the answers to those questions.
Guidelines are great but you need to enforce them. There are lots of tools to automate coding style.
Then there’s CSS architecture. Apparently we write our styles in React now. Do you really want to tie your CSS to one environment like that?
You know what’s really nice? A good ol’ sturdy cacheable CSS file. It can come in like a fairy applying all the right styles regardless of tech stack.
The idea of a design system is not to build 100% of your UI entirely from components in the code library. The majority, sure. But it’s unrealistic to expect everything to come from the design system.
When Brad puts pages together, he pulls in components from the code library but he also pulls in one-off snowflake components where needed.
The design system informs our product design. Our product design informs the design system.
Brad has seen graveyards of design systems. But if you make a virtuous circle between the live code and the design system, the design system has a much better chance of not just surviving, but thriving.
So you go through those pilot projects, each one feeding more and more into the design system. Lather, rinse, repeat. The first one will be time consuming, but each subsequent project gets quicker and quicker as you start to get the return on investment. Velocity increases over time.
It’s like tools for a home improvement project. The first thing you do is look at your current toolkit. If you don’t have the tool you need, you invest in buying that new tool. Now that tool is part of your toolkit. Next time you need that tool, you don’t have to go out and buy one. Your toolkit grows over time.
The design system code must be intuitive for developers using it. This gets into the whole world of API design. It’s really important to get this right—naming things consistently and having predictable behaviour.
Mina talked about loose vs. strict design systems. Open vs. locked down. Make your components composable so they can adapt to future requirements.
You can bake best practices into your design system. You can make accessibility a requirement in the code.
What does it mean to “launch” a design system?
A design system isn’t a project with an end, it’s the origin story of a living and evolving product that’ll serve other products.
There’s a spectrum of integration—how integrated the design system is with the final output. The levels go from:
Least integrated: static.
Front-end reference code.
Most integrated: consumable compents.
Chris Coyier in The Great Divide talked about how wide the spectrum of front-end development is. Brad, for example, is very much at the front of the front end. Consumable UI components can create a bridge between the back of the front end and the front of the front end.
Consumable UI components need to be bundled, packaged, and published.
Now we’ve entered a new mental space. We’ve gone from “Let’s build a website” to “Let’s maintain a product which other products use as a dependency.” You need to start thinking about things like semantic versioning. A version number is a promise.
A 1.0.0 designation comes with commitment. Freewheeling days of unstable early foundations are behind you.
What do you do when a new tech stack comes along? How does your design system serve the new hotness. It gets worse: you get products that aren’t even web based—iOS, Android, etc.
That’s where design tokens come in. You can define your design language in a platform-agnostic way.
This is hard.
Your design system must live in the technologies your products use.
Look at your product roadmaps for design system pilot project opportunities.
Establish code conventions and use tooling and process to enforce them.
Build your design system and pilot project UI screens in a frontend workshop environment.
Bake best practices into reusable components & make them as rigid or flexible as you need them to be.
Use semantic versioning to manage ongoing design system product work.
Use design tokens to feed common design properties into different platforms.
You won’t do it all at once. That’s okay. Baby steps.
Design systems have dominated web design conversations for a few years. Just as there’s no one way to make a website, there is no one way to make a design system. Unfortunately this has led to a lot of misconceptions around the creation and impact of this increasingly important tool.
Drawing on her experiences building design systems at two highly visible and vastly different organizations, Mina will debunk some common myths surrounding design systems.
Mina is a designer who codes. Or an engineer who designs. She makes websites. She works at Slack, but she doesn’t work on the product; she works on slack.com and the Slack blog. Mina also makes design systems. She loves design systems!
There are some myths she’s heard about design systems that she wants to dispel. She will introduce us to some mythological creatures along the way.
Myth 1: Designers “own” the design system
Mina was once talking to a product designer about design systems and was getting excited. The product designer said, nonplussed, “Aren’t you an engineer? Why do you care?” Mina explained that she loved design systems. The product designer said “Y’know, design systems should really be run by designers” and walked away.
Mina wondered if she had caused offense. Was she stepping on someone’s toes? The encounter left her feeling sad.
Thinking about it later, she realised that the conversation about design systems is dominated by product designers. There was a recent Twitter thread where some engineers were talking about this: they felt sidelined.
The reality is that design systems should be multi-disciplinary. That means engineers but it also means other kinds of designers other than product designers too: brand designers, content designers, and so on.
What you need is a hybrid, or unicorn: someone with complimentary skills. As Jina has said, design systems themselves are hybrids. Design systems give hybrids (people) a home. Hybrids help bring unity to an organization.
Myth 2: design systems kill creativity
Mina hears this one a lot. It’s intertwined with some other myths: that design systems don’t work for editorial content, and that design systems are just a collection of components.
Components are like mermaids. Everyone knows what one is supposed to look like, and they can take many shapes.
Your design system is your pantry, not your cookbook.
If you keep combining your ingredients in the same way, then yes, you’ll keep getting the same cake. But if you combine them in different ways, there’s a lot of room for creativity. Find the key moments of brand expression.
There are strict and loose systems.
Strict design systems are what we usually think of. AirBnB’s design system is a good example. It’s detailed and tightly controlled.
A loose design system will leave more space for experimentation. TED’s design system consists of brand colours and wireframes. Everything else is left to you:
Consistency is good only insofar as it doesn’t prevent you from trying new things or breaking out of your box when the context justifies it.
A good design sytem helps you improvise.
Thinking about strict vs. loose reminds Mina of product vs. marketing. A design system for a product might need to be pixel perfect, whereas editorial design might need more breathing room.
Mina has learned to stop fighting the one-off snowflake components in a system. You want to enable the snowflakes without abandoning the system entirely.
A loose system is key for maintaining consistency while allowing for exploration and creativity.
Myth 3: a design system is a side project
Brad guffaws at this one.
Okay, maybe no one has said this out loud, but you definitely see a company’s priorities focused on customer-facing features. A design system is seen as something for internal use only. “We’ll get to this later” is a common refrain.
“Later” is a mythical creature—a phoenix that will supposedly rise from the ashes of completed projects. Mina has never seen a phoenix. You never see “later” on a roadmap.
Don’t treat your design system as a second-class system. If you do, it will not mature. It won’t get enough time and resources. Design systems require real investment.
Mina has heard from people trying to start design systems getting the advice, “Just do it!” It seems like good advice, but it could be dangerous. It sets you up for failure (and burnout). “Just doing it” without support is setting people up for a bad experience.
The alternative is to put it on the roadmap. But…
Myth 4: a design system should be on the product roadmap
At a previous company, Mina once put a design system on the product roadmap because she saw it wasn’t getting the attention it needed. The answer came back: nah. Mina was annoyed. She had tried to “just do it” and now when she tried to do it through the right channels, she’s told she can’t.
But Mina realised that it’s not that simple. There are important metrics she might not have been aware of.
A roadmap is multi-faceted thing, like Cerebus, the three-headed dog of the underworld.
Okay, so you can’t put the design sytem on the roadmap, but you can tie it to something with a high priority. You could refactor your way to a design system. Or you could allocate room in your timeline to slip in design systems work (pad your estimates a little). This is like a compromise between “Just do it!” and “Put it on the roadmap.”
A system’s value is realized when products ship features that use a system’s parts.
The other problem with putting a design system on the roadmap is that it implies there’s an end date. But a design system is never finished (unless you abandon it).
Myth 5: our system should do what XYZ’s system did
It’s great that there are so many public design systems out there to look to and get inspired by. We can learn from them. “Let’s do that!”
But those inspiring public systems can be like a succubus. They’re powerful and seductive and might seem fun at first but ultimately leave you feeling intimidated and exhausted.
Your design system should be build for your company’s specific needs, not Google’s or Github’s or anyone’s.
Slack has multiple systems. There’s one for the product called Slack Kit. It’s got great documentation. But if you go on Slack’s marketing website, it doesn’t look like the product. It doesn’t use the same typography or even colour scheme. So it can’t use the existing the design system. Mina created the Spacesuit design system specifically for the marketing site. The two systems are quite different but they have some common goals:
Establish common language.
Reduce technical debt.
Allow for modularity.
But there are many different needs between the Slack client and the marketing site. Also the marketing site doesn’t have the same resources as the Slack client.
Be inspired by other design systems, but don’t expect the same resutls.
Myth 6: everything is awesome!
When you think about design systems, everything is nice and neat and orderly. So you make one. Then you look at someone else’s design system. Your expectations don’t match the reality. Looking at these fully-fledged design systems is like comparing Instagram to real life.
The perfect design system is an angel. It’s a benevolent creature acting as an intermediary between worlds. Perhaps you think you’ve seen one once, but you can’t be sure.
The truth is that design system work is like laying down the railway tracks while the train is moving.
For a developer, it is a rare gift to be able to implement a project with a clean slate and no obligations to refactor an existing codebase.
Mina got to do a complete redesign in 2017, accompanied by a design system. The design system would power the redesign. Everything was looking good. Then slowly as the rest of the team started building more components for the website, unconnected things seemed to be breaking. This is what design systems are supposed to solve. But people were creating multiple components that did the same thing. Work was happening on a deadline.
Even on the Hillary For America design system (Pantsuit), which seemed lovely and awesome on the outside, there were multiple components that did the same thing. The CSS got out of hand with some very convoluted selectors trying to make things flexible.
Mina wants to share those stories because it sometimes seems that we only share the success stories.
Share work in progress. Learn out in the open. Be more vulnerable, authentic, and real.
It’s Patty Toland’s first time at An Event Apart! She’s from the fantabulous Filament Group. They’re dedicated to making the web work for everyone.
A few years ago, a good friend of Patty’s had a medical diagnosis that required everyone to pull together. Another friend shared an article about how not to say the wrong thing. This is ring theory. In a moment of crisis, the person involved is in the centre. You need to understand where you are in this ring structure, and only ever help and comfort inwards and dump concerns and problems outwards.
At the same time, Patty spent time with her family at the beach. Everyone reads the same books together. There was a book about a platoon leader in Vietnam. 80% of the story was literally a litany of stuff—what everyone was carrying. This was peppered with the psychic and emotional loads that they were carrying.
There was a common assertion that slow networks were a third-world challenge. Remember Facebook’s network challenges? They always talked about new markets in India and Africa. The implication is that this isn’t our problem in, say, Omaha or New York.
Pew Research provided updated data this year. The research shows an increase in those trends. Half of the population access the web primarily on mobile. The cost of a broadband subscription is too expensive for many people. Sometimes broadband access simply isn’t available.
There’s a term called “the homework gap.” Two thirds of teachers assign broadband-dependent homework, while one third of students have no access to broadband.
At most 37% of people have unlimited data. Most people run out of data on a frequent basis.
Speed also varies wildly. 4G doesn’t really mean anything. The data is all over the place.
This shows that network issues are definitely not just a third world challenge.
On the 25th anniversary of the web, Tim Berners-Lee said the web’s potential was only just beginning to be glimpsed. Everyone has a role to play to ensure that the web serves all of humanity. In his contract for the web, Tim outlined what governments, companies, and users need to do. This reminded Patty of ring theory. The user is at the centre. Designers and developers are in the next circle out. Then there’s the circle of companies. Then there are platforms, browsers, and frameworks. Finally there’s the outer circle of governments.
There’s no way for a user to know before clicking a link how big and bloated the page is going to be. Even if they abandon the page load, they’ve still used (and wasted) a lot of data.
Third party scripts—like ads—are really bad at dumping in (to use the ring theory model). The best practices for ads suggest that up to 100 additional HTTP requests is totally acceptable. Unbelievable! It doesn’t matter how performant you’ve made a site when this crap gets piled on top of it.
In 2018, the internet’s data centres alone may already have had the same carbon footprint as all global air travel. This will probably triple in the next seven years. The amount of carbon it takes to train a single AI algorithm is more than the entire life cycle of a car. Then there’s fucking Bitcoin. A single Bitcoin transaction could power 21 US households. It is designed to use—specifically, waste—more and more energy over time.
What should we be doing?
Accessibility should be at the heart of what we build. Plan, test, educate, and advocate. If advocacy doesn’t work, fear can be a motivator. There’s an increase in accessibility lawsuits.
Our websites should be as light as possible. Ask, measure, monitor, and optimise. RequestMap is a great tool for visualising requests. You can see the size and scale of third-party requests. You can also see when images are far, far bigger than they need to be.
Take a critical guide to everything and pare everything down. Set perforance budgets—file size budgets, for example. Optimise images, subset custom fonts, lazyload images and videos, get third-party tools out of the critical path (or out completely), and seek out lighter frameworks.
Push the boundaries. See the amazing work that Adrian Holovaty did with Soundslice. He had to make on-the-fly sheet music generation work on old iPads that musicians like to use. He recommends keeping old devices around to see how poorly your product is working on it.
If you have some power, then your job is to empower somebody else.
Jason is on stage at An Event Apart Chicago in a tuxedo. He wants to talk about how we can make web forms magical. Oh, I see. That explains the get-up.
We’re always being told to make web forms shorter. Luke Wroblewski has highlighted the work of companies that have reduced form fields and increased conversion.
But what if we could get rid of forms altogether? Wouldn’t that be magical!
Jason will reveal the secrets to this magic. But first—a volunteer from the audience, please! Please welcome Joe to the stage.
Joe will now log in on a phone. He types in the username. Then the password. The password is hodge-podge of special characters, numbers and upper and lowercase letters. Joe starts typing. Jason takes the phone and logs in without typing anything!
The secret: Jason was holding an NFC security key in his hand. That works with a new web standard called WebAuthn.
Passwords are terrible. People share them across sites, but who can blame them? It’s hard to remember lots of passwords. The only people who love usernames and passwords are hackers. So sites are developing other methods to try to keep people secure. Two factor authentication helps, although it doesn’t help us with phishing attacks. The hacker gets the password from the phished user …and then gets the one-time code from the phished user too.
But a physical device like a security key solves this problem. So why aren’t we all using security keys (apart from the fear of losing the key)? Well, until WebAuthn, there wasn’t a way for websites to use the keys.
A web server generates a challenge—a long string—that gets sent to a website and passed along to the user. The user’s device generates a credential ID and public and private keys for that domain. The web site stores the public key and credential ID. From then on, the credential ID is used by the website in challenges to users logging in.
There were three common ways that we historically proved who we claimed to be.
Something you know (e.g. a password).
Something you have (e.g. a security key).
Something you are (e.g. biometric information).
These are factors of identification. So two-factor identification is the combination of any of those two. If you use a security key combined with a fingerprint scanner, there’s no need for passwords.
The browser support for the web authentication API (WebAuthn) is a bit patchy right now but you can start playing around with it.
There are a few other options for making logging in faster. There’s the Credential Management API. It allows someone to access passwords stored in their browser’s password manager. But even though it’s newer, there’s actually better browser support for WebAuthn than Credential Management.
Then there’s federated login, or social login. Jason has concerns about handing over log-in to a company like Facebook, Twitter, or Google, but then again, it means fewer passwords. As a site owner, there’s actually a lot of value in not storing log-in information—you won’t be accountable for data breaches. The problem is that you’ve got to decide which providers you’re going to support.
Also keep third-party password managers in mind. These tools—like 1Password—are great. In iOS they’re now nicely integrated at the operating system level, meaning Safari can use them. Finally it’s possible to log in to websites easily on a phone …until you encounter a website that prevents you logging in this way. Some websites get far too clever about detecting autofilled passwords.
Time for another volunteer from the audience. This is Tyler. Tyler will help Jason with a simple checkout form. Shipping information, credit card information, and so on. Jason will fill out this form blindfolded. Tyler will first verify that the dark goggles that Jason will be wearing don’t allow him to see the phone screen. Jason will put the goggles on and Tyler will hand him the phone with the checkout screen open.
Jason dons the goggles. Tyler hands him the phone. Jason does something. The form is filled in and submitted!
What was the secret? The goggles prevented Jason from seeing the phone …but they didn’t prevent the screen from seeing Jason. The goggles block everything but infrared. The iPhone uses infrared for Face ID. So the iPhone, it just looked like Jason was wearing funky sunglasses. Face ID then triggered the Payment Request API.
The Payment Request API allows us to use various payment methods that are built in to the operating system, but without having to make separate implementations for each payment method. The site calls the Payment Request API if it’s supported (use feature detection and progressive enhancement), then trigger the payment UI in the browser. The browser—not the website!—then makes a call to the payment processing provider e.g. Stripe.
E-commerce sites using the Payment Request API have seen a big drop in abandonment and a big increase in completed payments. The browser support is pretty good, especially on mobile. And remember, you can use it as a progressive enhancement. It’s kind of weird that we don’t encounter it more often—it’s been around for a few years now.
Jason read the fine print for Apple Pay, Google Pay, Microsoft Pay, and Samsung Pay. It doesn’t like there’s anything onerous in there that would stop you using them.
On some phones, you can now scan credit cards using the camera. This is built in to the operating system so as a site owner, you’ve just got to make sure not to break it. It’s really an extension of autofill. You should know what values the autocomplete attribute can take. There are 48 different values; it’s not just for checkouts. When users use autofill, they fill out forms 30% faster. So make sure you don’t put obstacles in the way of autofill in your forms.
Jason proceeds to relate a long and involved story about buying burritos online from Chipotle. The upshot is: use the autocomplete, type, maxlength, and pattern attributes correctly on input elements. Test autofill with your forms. Make it part of your QA process.
So, to summarise, here’s how you make your forms disappear:
Start by reducing the number of form fields.
Use the correct HTML to support autofill. Support password managers and password-pasting. At least don’t break that behaviour.
Provide alternate ways of logging in. Federated login or the Credentials API.
Test autofill and other form features.
Look for opportunities to replace forms entirely with biometrics.
Any sufficiently advanced technology is indistinguishable from magic.
Successful voice interfaces aren’t necessarily solving new problems. They’re used to solve problems that other devices have already solved. Think about kitchen timers. There are lots of ways to set a timer. Your oven might have one. Your phone has one. Why use a $200 device to solve this mundane problem? Same goes for listening to music, news, and weather.
People are using voice interfaces for solving ordinary problems. Why? Context matters. If you’re carrying a toddler, then setting a kitchen timer can be tricky so a voice-activated timer is quite appealing. But why is voice is happening now?
Humans have been developing the art of conversation for thousands of years. It’s one of the first skills we learn. It’s deeply instinctual. Most humans use speach instinctively every day. You can’t necessarily say that about using a keyboard or a mouse.
Voice-based user interfaces are not new. Not just the idea—which we’ve seen in Star Trek—but the actual implementation. Bell Labs had Audrey back in 1952. It recognised ten words—the digits zero through nine. Why did it take so long to get to Alexa?
In the late 70s, DARPA issued a challenge to create a voice-activated system. Carnagie Mellon came up with Harpy (with a thousand word grammar). But none of the solutions could respond in real time. In conversation, we expect a break of no more than 200 or 300 milliseconds.
In the 1980s, computing power couldn’t keep up with voice technology, so progress kind of stopped. Time passed. Things finally started to catch up in the 90s with things like Dragon Naturally Speaking. But that was still about vocabulary, not grammar. By the 2000s, small grammars were starting to show up—starting an X-Box or pausing Netflix. In 2008, Google Voice Search arrived on the iPhone and natural language interaction began to arrive.
What makes natural language interactions so special? It requires minimal training because it uses the conversational muscles we’ve been working for a lifetime. It unlocks the ability to have more forgiving, less robotic conversations with devices. There might be ten different ways to set a timer.
Natural language interactions can also free us from “screen magnetism”—that tendency to stay on a device even when our original task is complete. Voice also enables fast and forgiving searches of huge catalogues without time spent typing or browsing. You can pick a needle straight out of a haystack.
Natural language interactions are excellent for older customers. These interfaces don’t intimidate people without dexterity, vision, or digital experience. Voice input often leads to more inclusive experiences. Many customers with visual or physical disabilities can’t use traditional graphical interfaces. Voice experiences throw open the door of opportunity for some people. However, voice experience can exclude people with speech difficulties.
Making the case for voice interfaces
There’s a misconception that you need to work at Amazon, Google, or Apple to work on a voice interface, or at least that you need to have a big product team. But Cheryl was able to make her first Alexa “skill” in a week. If you’re a web developer, you’re good to go. Your voice “interaction model” is just JSON.
How do you get your product team on board? Find the customers (and situations) you might have excluded with traditional input. Tell the stories of people whose hands are full, or who are vision impaired. You can also point to the adoption rate numbers for smart speakers.
You’ll need to show your scenario in context. Otherwise people will ask, “why can’t we just build an app for this?” Conduct research to demonstrate the appeal of a voice interface. Storyboarding is very useful for visualising the context of use and highlighting existing pain points.
Getting started with voice interfaces
You’ve got to understand how the technology works in order to adapt to how it fails. Here are a few basic concepts.
Utterance. A word, phrase, or sentence spoken by a customer. This is the true form of what the customer provides.
Intent. This is the meaning behind a customer’s request. This is an important distinction because one intent could have thousands of different utterances.
Prompt. The text of a system response that will be provided to a customer. The audio version of a prompt, if needed, is generated separately using text to speech.
Grammar. A finite set of expected utterances. It’s a list. Usually, each entry in a grammar is paired with an intent. Many interfaces start out as being simple grammars before moving on to a machine-learning model later once the concept has been proven.
Here’s the general idea with “artificial intelligence”…
There’s a human with a core intent to do something in the real world, like knowing when the cookies in the oven are done. This is translated into an intent like, “set a 15 minute timer.” That’s the utterance that’s translated into a string. But it hasn’t yet been parsed as language. That string is passed into a natural language understanding system. What comes is a data structure that represents the customers goal e.g. intent=timer; duration=15 minutes. That’s sent to the business logic where a timer is actually step. For a good voice interface, you also want to send back a response e.g. “setting timer for 15 minutes starting now.”
That seems simple enough, right? What’s so hard about designing for voice?
Natural language interfaces are a form of artifical intelligence so it’s not deterministic. There’s a lot of ruling out false positives. Unlike graphical interfaces, voice interfaces are driven by probability.
How do you turn a sound wave into an understandable instruction? It’s a lot like teaching a child. You feed a lot of data into a statistical model. That’s how machine learning works. It’s a probability game. That’s where it gets interesting for design—given a bunch of possible options, we need to use context to zero in on the most correct choice. This is where confidence ratings come in: the system will return the probability that a response is correct. Effectively, the system is telling you how sure or not it is about possible results. If the customer makes a request in an unusual or unexpected way, our system is likely to guess incorrectly. That’s because the system is being given something new.
Designing a conversation is relatively straightforward. But 80% of your voice design time will be spent designing for what happens when things go wrong. In voice recognition, edge cases are front and centre.
Here’s another challenge. Interaction with most voice interfaces is part conversation, part performance. Most interactions are not private.
Humans don’t distinguish digital speech fom human speech. That means these devices are intrinsically social. Our brains our wired to try to extract social information, even form digital speech. See, for example, why it’s such a big question as to what gender a voice interface has.
Delivering a voice interface
Storyboards help depict the context of use. Sample dialogues are your new wireframes. These are little scripts that not only cover the happy path, but also your edge case. Then you reverse engineer from there.
Flow diagrams communicate customer states, but don’t use the actual text in them.
Prompt lists are your final deliverable.
Functional prototypes are really important for voice interfaces. You’ll learn the real way that customers will ask for things.
If you build a working prototype, you’ll be building two things: a natural language interaction model (often a JSON file) and custom business logic (in a programming language).
Eventually voice design will become a core competency, much like mobile, which was once separate.
Ask yourself what tasks your customers complete on your site that feel clunkly. Remember that voice desing is almost never about new scenarious. Start your journey into voice interfaces by tackling old problems in new, more inclusive ways.
Research gets done …and then sits in a report, gathering dust.
Research matters. But how do we make it count? We need allies. Maybe we need more money. Perhaps we need more participation from people not on the product team.
If you’re doing real research on a schedule, sharing it on a regular basis, making people’s eyes light up …then you’ve won!
Research counts when it answers questions that people care about. But you probably don’t want to directly ask “Hey, what questions do you want answered?”
Research can explain oddities in analytics weird feedback from customers, unexpected uses of products, and strange hunches (not just your own).
Curious people with power are the most useful ones to influence. Not just hierarchical power. Engineers often have a lot of power. So ask, “Who is the most curious engineer, and how can I drag them out on a research session with me?”
At 18F, Cyd found that a lot of the nodes of power were in the mid level of the organisation who had been there a while—they know a lot of people up and down the chain. If you can get one of those people excited about research, they can spread it.
Open up your practice. Demystify it. Put as much effort into communicating as into practicing. Create opportunities for people to ask questions and learn.
You can think about communities of practice in the obvious way: people who do similar things to us, and other people who make design decisions. But really, everyone in the organisation is affected by design decisions.
Cyd likes to do office hours. People can come by and ask questions. You could open a Slack channel. You can run brown bag lunches to train people in basic user research techniques. In more conventional organisations, a newsletter is a surprisingly effective tool for sharing the latest findings from research. And use your walls to show work in progress.
Research counts when people can see it for themselves—not just when it’s reported from afar. Ask yourself: who in your organisation is disconnected from their user? It’s difficult for people to maintain their motivation in that position.
When someone has been in the field with you, the data doesn’t have to be explained.
Whoever’s curious. Whoever’s disconnected. Invite them along. Show them what you’re doing.
Think about the qualities of a good invitation (for a party, say). Make the rules clear. Make sure they want to come back. Design the experience of observing research. Make sure everyone has tools. Give everyone a responsibility. Be like Willy Wonka—he gave clear rules to the invitied guests. And sure, things didn’t go great when people broke the rules, but at the end, everyone still went home with the truckload of chocolate they were promised.
People who get to ask a question buy in to the results. Those people feel a sense of ownership for the research.
Research counts when methods fit the question. Think about what the right question is and how you might go about answering it.
You can mix your methods. Interviews. Diary studies. Card sorting. Shadowing. You can ground the user research in competitor analysis.
Back in 2008, Cyd was contacted by a company who wanted to know: how do people really use phones in their cars? Cyd’s team would ride along with people, interviewing them, observing them, taking pictures and video.
Later at the federal government, Cyd was asked: what are the best practices for government digital transformation? How to answer that? It’s so broad! Interviews? Who knows what?
They refined the question: what makes modern digital practices stick within a government entity? They looked at what worked when companies were going online, so see if there was anything that government could learn from. Then they created a set of really focused interview questions. What does digital transformation mean? How do you know when you’re done? What are the biggest obstacles to this work? How do you make changes last?
They used atechnique called cluster recruiting to figure out who else to talk to (by asking participants who else they should be talking to).
There is no one research method that will always work for you. Cutting the right corners at the right time lets you be fast and cheap. Cyd’s bare-bones research kit costs about $20: a notebook, a pen, a consent form, and the price of a cup of coffee. She also created a quick score sheet for when she’s not in a position to have research transcribed.
Always label your assumptions before beginning your research. Maybe you’re assuming that something is a frustrating experience that needs fixing, but it might emerge that it doesn’t need fixing—great! You’ve just saved a whole lotta money.
Research counts when researchers tell the story well. Synthesis works best as a conversational practice. It’s hard to do by yourself. You start telling stories when you come back from the field (sometimes it starts when you’re still out in the field, talking about the most interesting observations).
To understand what another person is saying, you must assume that it is true and try to imagine what it could be true of.
You’re probably familiar with the “five whys”. What about the “five ways”? If people talk about something five different ways, it’s virtually certain that one of them will be an apt metaphor. So ask “Can you say that in a different way?” five time.
Spend as much time on communicating outcomes as you did on executing the work.
After research, play back how many people you spoke to, the most valuable insight you gained, the themes that are emerging. Describe the question you wanted to answer, what answers you got, and what you’re going to do next. If you’re in an organisation that values memos, write a memo. Or you could make a video. Or you could write directly into backlog tickets. And don’t forget the wall work! GDS have wonderfully full walls in their research department.
In the end, the best tool for research is an illuminating story.
Cyd was doing research at the Bakersfield courthouse. The hypothesis was that a lot of people weren’t engaging with technology in the court system. She approached a man named Manuel who was positively quaking. He was going through a custody battle. He said, “I don’t know technology but it doesn’t scare me. I’m shaking because this paperwork just gets to me—it’s terrifying.” He said who would gladly pay for someone to help him with the paperwork. Cyd wrote a report on this story. Months later, they heard people in the organisation asking questions like “How would this help Manuel?”
Sometimes you do have to fight (nicely).
People will push back on the time spent on research—they’ll say it doesn’t fit the sprint plan. You can have a three day research plan. Day 1: write scripts. Day 2: go to the users and talk to them. Day 3: play it back. People on a project spend more time than that in Slack.
People will say you can’t talk to the customers. In that situation, you could talk to people who are in the same sector as your company’s customers.
People will question the return on investment for research. Do it cheaply and show the very low costs. Then people stop talking about the money and start talking about the results.
People will claim that qualitative user research is not statistically significant. That’s true. But research is something else. It answers different question.
People will question whether a senior person needs to be involved. It is not fair to ask the intern to do all the work involved in research.
People will say you can’t always do research. But Cyd firmly believes that there’s always room for some research.
Make allies in customer research.
Find the most curious engineer on the team, go to lunch with them, and feed them the most interesting research insights.
Record a pain point and a send a video to executives.
If there’s really no budget, maybe you can get away with not paying incentives, but perhaps you can provide some other swag instead.
One of the best things you can do is be there, non-judgementally, making friends. It takes time, but it works. Research is like a dandelion in flight. Once it’s out and about, taking root, the more that research counts.