Journal tags: design

257

sparkline

Tweaking navigation sizing

Gerry talks about “top tasks” a lot. He literally wrote the book on it:

Top tasks are what matter most to your customers.

Seems pretty obvious, right? But it’s actually pretty rare to see top tasks presented any differently than other options.

Look at the global navigation on most websites. Typically all the options are given equal prominence. Even the semantics under the hood often reflect this egalitarian ideal, with each list in an unordered list. All the navigation options are equal, but I bet that the reality for most websites is that some navigation options are more equal than others.

I’ve been guilty of this on The Session. The site-wide navigation shows a number of options: tunes, events, discussions, etc. Each one is given equal prominence, but I can tell you without even looking at my server logs that 90% of the traffic goes to the tunes section—that’s the beating heart of The Session. That’s why the home page has a search form that defaults to searching for tunes.

I wanted the navigation to reflect the reality of what people are coming to the site for. I decided to make the link to the tunes section more prominent by bumping up the font size a bit.

I was worried about how weird this might look; we’re so used to seeing all navigation items presented equally. But I think it worked out okay (though it might take a bit of getting used to if you’re accustomed to the previous styling). It helps that “tunes” is a nice short word, so bumping up the font size on that word doesn’t jostle everything else around.

I think this adjustment is working well for this situation where there’s one very clear tippy-top task. I wouldn’t want to apply it across the board, making every item in the navigation proportionally bigger or smaller depending on how often it’s used. That would end up looking like a ransom note.

But giving one single item prominence like this tweaks the visual hierarchy just enough to favour the option that’s most likely to be what a visitor wants.

That last bit is crucial. The visual adjustment reflects what visitors want, not what I want. You could adjust the size of a navigation option that you want to drive traffic to, but in the long run, all you’re going to do is train people to trust your design less.

You don’t get to decide what your top task is. The visitors to your website do. Trying to foist an arbitrary option on them would be the tail wagging the dog.

Anway, I’m feeling a lot better about the site-wide navigation on The Session now that it reflects reality a little bit more. Heck, I may even bump that font size up a little more.

Prepping

Speaking of in-person gatherings, I’ve got some exciting—if not downright nervewracking—events coming up soon.

Next week I’ll be in London for Leading Design. Looking at the line-up that Rebecca is assembled, I’m kind of blown away—it looks fantastic!

You’ll notice that I’m in that line-up, but don’t worry—I’m not giving a talk. I’ll be there as host. That means I get to introduce the speakers before they speak, and ask them a question or two afterwards.

Then, one week later, I do it all again at Clarity in New Orleans. I’m really honoured that Jina has invited me to MC. Again, it’s a ridiculously fantastic line-up (once you ignore my presence).

I really, really enjoy hosting events. And yet I always get quite anxious in the run-up. I think it’s because there isn’t much I can do to prepare.

During The Situation, I had something of an advantage when I was hosting UX Fest. The talks were pre-recorded, which meant that I could study them ahead of time. At a live event, I won’t have that luxury. Instead, I need to make sure that I pay close attention to each talk and try to come up with good questions.

Based on past experience, my anxiety is unwarranted. Once I’m actually talking to these super-smart people, the problem isn’t a lack of things to discuss, but the opposite—so much to talk about in so little time!

I keep trying to remind myself of that.

See, it’s different if I’m speaking at an event. Sure, I’ll get nervous, but I can do something about it. I can prepare and practice to alleviate any anxiety. I feel like I have more control over the outcome when I’m giving a talk compared with hosting.

In fact, I do have a speaking gig on the horizon. I’ll be giving a brand new talk at An Event Apart in San Francisco in December.

It was just a month ago when Jeffrey invited me to speak. Of course I jumped at the chance—it’s always an honour to be asked—but I had some trepidation about preparing a whole new talk in time.

I’ve mentioned this before but it takes me aaaaaaaages to put a talk together. Don’t get me wrong; I think it’s worth it. I may not be good at much, but I know I can deliver a really good conference talk …once I’ve spent ridiculously long preparing it.

But more recently I’ve noticed that I’ve managed to shorten this time period. Partly that’s because I recklessly agree to prepare the talk in a shorter amount of time—nothing like a deadline to light a fire under my ass. But it’s also because a lot of the work is already done.

When I have a thought or an opinion about something, I write it down here on my own website. They’re brain farts, but their my brain farts. I consider them half-baked, semi-formed ideas.

For a conference talk, I need something fully-baked and well-formed. But I can take a whole bunch of those scrappy blog posts and use them as raw material.

There’s still a lot of work involved. As well as refining the message I want to get across, I have to structure these thoughts into a narrative thread that makes sense. That’s probably the hardest part of preparing a conference talk …and the most rewarding.

So while I’ve been feeling somewhat under the gun as I’ve been preparing this new talk for An Event Apart, I’ve also been feeling that the talk is just the culmination; a way of tying together some stuff I’ve been writing about it here for the past year or two.

It’s still entirely possible that the talk could turn out to be crap, but I think the odds are in my favour. I’ve been able to see how the ideas I’ve been writing about have resonated with people, so I can feel pretty confident that they’ll go down well in a talk.

As for the topic of the talk? All will be revealed.

Knowing

There’s a repeated catchphrase used throughout Christopher Nolan’s film Tenet: ignorance is our ammunition.

There are certainly situations where knowledge is regrettable. The somewhat-silly thought experiment of Roko’s basilisk is one example. Once you have knowledge of it, you can’t un-know it, and so you become complicit.

Or, to use another example, I think it was Jason who told me that if you want to make someone’s life miserable, just teach them about typography. Then they’ll see all the terrible kerning out there in the world and they won’t be able to un-see it.

I sometimes wish I could un-learn all I’ve learned about cryptobollocks (I realise that the term “cryptocurrency” is the more widely-used phrase, but it’s so inaccurate I’d rather use a clearer term).

I sometimes wish I could go back to having the same understanding of cryptobollocks as most people: some weird new-fangled technology thing that has something to do with “the blockchain.”

But I delved too deep. I wanted to figure out why seemingly-smart people were getting breathlessly excited about something that sounds fairly ludicrous. Yet the more I learned, the more ludicrous it became. Bitcoin and its ilk are even worse than the occassional headlines and horror stories would have you believe.

As Jules says:

The reason I have such a visceral reaction to crypto projects isn’t just that they’re irresponsibly designed and usually don’t achieve what they promise. It’s also that the thing they promise sounds like a fucking nightmare.

Or, as Simon responded to someone wondering why there was so much crypto hate:

We hate it because we understand it.

I have yet to encounter a crypto project that isn’t a Ponzi scheme. I don’t mean like a Ponzi scheme. I mean they’re literally Ponzi schemes: zero-sum racing to the bottom built entirely on the greater fool theory. The only difference between traditional Ponzi schemes and those built on crypto is that crypto isn’t regulated. Yet.

I recently read The Glass Hotel by Emily St. John Mandel, a novel with the collapse of a Ponzi scheme at its heart. In the aftermath of the scheme’s collapse, there are inevitable questions like “How could you not know?” The narrator answers that question:

It’s possible to both know and not know something.

I’ve been thinking about that a lot.

Design systems thinking

As you can probably tell from the stuff I’ve been linking to today and today’s Clearleft newsletter, I’ve got design systems on my mind.

What I like about design systems is they encourage systems thinking …in theory. I mean, it’s right there in the name, right? But in practice I see design sytems focusing on the opposite of systems thinking: analytical thinking.

Okay, I realise that’s a gross oversimplification of both systems and thinking and analytical thinking, but why stop now?

Analytical thinking is all about breaking a big thing down into its constituent parts. By examining the individual parts you gain an understanding of the whole.

This is a great approach to understanding the world, particularly when it comes to phenonema that work the same everywhere in the universe. But it doesn’t work so well with messy phenonema like, say, people doing things together.

Systems thinking takes the opposite approach. You look at the bigger picture with the understanding that the individual parts are all interconnected somehow and can’t really be viewed in isolation.

To put it very bluntly, analytical thinking is about zooming in whereas systems thinking is about zooming out.

When it comes to design systems—or design in general—you need to have a mix of both.

If you neglect the analytical thinking, you may end up with a design system that has well-documented processes for how it operates, but is lacking the individual components.

If you neglect the systems thinking, you may end up with a design system that’s a collection of components, but with no understanding of how they’re supposed to work together.

Ideally, you want a good mix of both.

But I’ve got to be honest: if I had to err on one side more than the other, I think I’d rather have less analytical thinking and more systems thinking.

Accessibility is systemic

I keep thinking about this blog post I linked to last week by Jacob Kaplan-Moss. It’s called Quality Is Systemic:

Software quality is more the result of a system designed to produce quality, and not so much the result of individual performance. That is: a group of mediocre programmers working with a structure designed to produce quality will produce better software than a group of fantastic programmers working in a system designed with other goals.

I think he’s on to something. I also think this applies to design just as much as development. Maybe more so. In design, there’s maybe too much emphasis placed on the talent and skill of individual designers and not enough emphasis placed on creating and nurturing a healthy environment where anyone can contribute to the design process.

Jacob also ties this into hiring:

Instead of spending tons of time and effort on hiring because you believe that you can “only hire the best”, direct some of that effort towards building a system that produces great results out of a wider spectrum of individual performance.

I couldn’t agree more! It just one of the reasons why the smart long-term strategy can be to concentrate on nurturing junior designers and developers rather than head-hunting rockstars.

As an aside, if you think that the process of nurturing junior designers and developers is trickier now that we’re working remotely, I highly recommend reading Mandy’s post, Official myths:

Supporting junior staff is work. It’s work whether you’re in an office some or all of the time, and it’s work if Slack is the only office you know. Hauling staff back to the office doesn’t make supporting junior staff easier or even more likely.

Hiring highly experienced designers and developers makes total sense, at least in the short term. But I think the better long-term solution—as outlined by Jacob—is to create (and care for) a system where even inexperienced practitioners will be able to do good work by having the support and access to knowledge that they need.

I was thinking about this last week when Irina very kindly agreed to present a lunch’n’learn for Clearleft all about inclusive design.

She answered a question that had been at the front of my mind: what’s the difference between inclusive design and accessibility?

The way Irina put it, accessibility is focused on implementation. To make a website accessible, you need people with the necessary skills, knowledge and experience.

But inclusive design is about the process and the system that leads to that implementation.

To use that cliché of the double diamond, maybe inclusive design is about “building the right thing” and accessibility is about “building the thing right.”

Or to put it another way, maybe accessibility is about outputs, whereas inclusive design is about inputs. You need both, but maybe we put too much emphasis on the outputs and not enough emphasis on the inputs.

This is what made me think of Jacob’s assertion that quality is systemic.

Imagine someone who’s an expert at accessibility: they know all the details of WCAG and ARIA. Now put that person into an organisation that doesn’t prioritise accessibility. They’re going to have a hard time and they probably won’t be able to be very effective despite all their skills.

Now imagine an organisation that priorities inclusivity. Even if their staff don’t (yet) have the skills and knowledge of an accessibility expert, just having the processes and priorities in place from the start will make it easier for everyone to contribute to a more accessible experience.

It’s possible to make something accessible in the absence of a system that prioritises inclusive design but it will be hard work. Whereas making sure inclusive design is prioritised at an organisational level makes it much more likely that the outputs will be accessible.

Declarative design systems

When I wrote about the idea of declarative design it really resonated with a lot of people.

I think that there’s a general feeling of frustration with the imperative approach to designing and developing—attempting to specify everything exactly up front. It just doesn’t scale. As Jason put it, the traditional web design process is fundamentally broken:

This is the worst of all worlds—a waterfall process creating dozens of artifacts, none of which accurately capture how the design will look and behave in the browser.

In theory, design systems could help overcome this problem; spend a lot of time up front getting a component to be correct and then it can be deployed quickly in all sorts of situations. But the word “correct” is doing a lot of work there.

If you’re approaching a design system with an imperative mindset then “correct” means “exact.” With this approach, precision is seen as valuable: precise spacing, precise numbers, precise pixels.

But if you’re approaching a design system with a declarative mindset, then “correct” means “resilient.” With this approach, flexibility is seen as valuable: flexible spacing, flexible ranges, flexible outputs.

These are two fundamentally different design approaches and yet the results of both would be described as a design system. The term “design system” is tricky enough to define as it is. This is one more layer of potential misunderstanding: one person says “design system” and means a collection of very precise, controlled, and exact components; another person says “design system” and means a predefined set of boundary conditions that can be used to generate components.

Personally, I think the word “system” is the important part of a design system. But all too often design systems are really collections rather than systems: a collection of pre-generated components rather than a system for generating components.

The systematic approach is at the heart of declarative design; setting up the rules and ratios in advance but leaving the detail of the final implementation to the browser at runtime.

Let me give an example of what I think is a declarative approach to a component. I’ll use the “hello world” of design system components—the humble button.

Two years ago I wrote about programming CSS to perform Sass colour functions. I described how CSS features like custom properties and calc() can be used to recreate mixins like darken() and lighten().

I showed some CSS for declaring the different colour elements of a button using hue, saturation and lightness encoded as custom properties. Here’s a CodePen with some examples of different buttons.

See the Pen Button colours by Jeremy Keith (@adactio) on CodePen.

If these buttons were in an imperative design system, then the output would be the important part. The design system would supply the code needed to make those buttons exactly. If you need a different button, it would have to be added to the design system as a variation.

But in a declarative design system, the output isn’t as important as the underlying ruleset. In this case, there are rules like:

For the hover state of a button, the lightness of its background colour should dip by 5%.

That ends up encoded in CSS like this:

button:hover {
    background-color: hsl(
        var(--button-colour-hue),
        var(--button-colour-saturation),
        calc(var(--button-colour-lightness) - 5%)
    );
}

In this kind of design system you can look at some examples to see the results of this rule in action. But those outputs are illustrative. They’re not the final word. If you don’t see the exact button you want, that’s okay; you’ve got the information you need to generate what you need and still stay within the pre-defined rules about, say, the hover state of buttons.

This seems like a more scalable approach to me. It also seems more empowering.

One of the hardest parts of embedding a design system within an organisation is getting people to adopt it. In my experience, nobody likes adopting something that’s being delivered from on-high as a pre-made sets of components. It’s meant to be helpful: “here, use this pre-made components to save time not reinventing the wheel”, but it can come across as overly controlling: “we don’t trust you to exercise good judgement so stick to these pre-made components.”

The declarative approach is less controlling: “here are pre-defined rules and guidelines to help you make components.” But this lack of precision comes at a cost. The people using the design system need to have the mindset—and the ability—to create the components they need from the systematic rules they’ve been provided.

My gut feeling is that the imperative mindset is a good match for most of today’s graphic design tools like Figma or Sketch. Those tools deal with precise numbers rather than ranges and rules.

The declarative mindset, on the other hand, increasingly feels like a good match for CSS. The language has evolved to allow rules to be set up through custom properties, calc(), clamp(), minmax(), and so on.

So, as always, there isn’t a right or wrong approach here. It all comes down to what’s most suitable for your organisation.

If your designers and developers have an imperative mindset and Figma files are considered the source of truth, than they would be better served by an imperative design system.

But if you’re lucky enough to have a team of design engineers that think in terms of HTML and CSS, then a declarative design system will be a force multiplier. A bicycle for the design engineering mind.

Pace layers and design principles

I think it was Jason who once told me that if you want to make someone’s life a misery, teach them about typography. After that they’ll be doomed to notice all the terrible type choices and kerning out there in the world. They won’t be able to unsee it. It’s like trying to unsee the arrow in the FedEx logo.

I think that Stewart Brand’s pace layers model is a similar kind of mind virus, albeit milder. Once you’ve been exposed to it, you start seeing in it in all kinds of systems.

Each layer is functionally different from the others and operates somewhat independently, but each layer influences and responds to the layers closest to it in a way that makes the whole system resilient.

Last month I sent out an edition of the Clearleft newsletter that was all about pace layers. I gathered together examples of people who have been infected with the pace-layer mindworm who were applying the same layered thinking to other areas:

My own little mash-up is applying pace layers to the World Wide Web. Tom even brought it to life as an animation.

See the Pen Web Layers Of Pace by Tom (@webrocker) on CodePen.

Recently I had another flare-up of the pace-layer pattern-matching infection.

I was talking to some visiting Austrian students on the weekend about design principles. I explained my mild obsession with design principles stemming from the fact that they sit between “purpose” (or values) and “patterns” (the actual outputs):

Purpose » Principles » Patterns

Your purpose is “why?”

That then influences your principles, “how?”

Those principles inform your patterns, “what?”

Hey, wait a minute! If you put that list in reverse order it looks an awful lot like the pace-layers model with the slowest moving layer at the bottom and the fastest moving layer at the top. Perhaps there’s even room for an additional layer when patterns go into production:

  • Production
  • Patterns
  • Principles
  • Purpose

Your purpose should rarely—if ever—change. Your principles can change, but not too frequently. Your patterns need to change quite often. And what you’re actually putting out into production should be constantly updated.

As you travel from the most abstract layer—“purpose”—to the most concrete layer—“production”—the pace of change increases.

I can’t tell if I’m onto something here or if I’m just being apopheniac. Again.

Agile design principles

I may have mentioned this before, but I’m a bit of a nerd for design principles. Have I shown you my equivalent of an interesting rock collection lately?

If you think about design principles for any period of time, it inevitably gets very meta very quickly. You start thinking about what makes for good design principles. In other words, you start wondering if there are design principles for design principles.

I’ve written before about how I think good design principles should encode some level of prioritisation. The classic example is the HTML design principle called the priority of consitituencies:

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.

It’s wonderfully practical!

I realised recently that there’s another set of design princples that put prioritisation front and centre—the Agile manifesto:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

And there’s this excellent explanation which could just as well apply to the priorty of constituencies:

That is, while there is value in the items on the right, we value the items on the left more.

Yes! That’s the spirit!

Ironically, the Agile manifesto also contains a section called principles behind the Agile manifesto which are …less good (at least they’re less good as design principles—they’re fine as hypotheses to be tested).

Agile is far from perfect. See, for example, Miriam Posner’s piece Agile and the Long Crisis of Software. But where Agile isn’t fulfilling its promise, I’d say it’s not because of its four design principles. If anything, I think the problems arise from organisations attempting to implement Agile without truly internalising the four principles.

Oh, and that’s another thing I like about the Agile manifesto as a set of design principles—the list of prioritised principles is mercifully short. Just four lines.

Even more UX London speaker updates

I’ve added five more faces to the UX London line-up.

Irina Rusakova will be giving a talk on day one, the day that focuses on research. Her talk on designing with the autistic community is one I’m really looking forward to.

Also on day one, my friend and former Clearleftie Cennydd Bowles will be giving a workshop called “What could go wrong?” He literally wrote the book on ethical design.

Day two is all about creation. My co-worker Chris How will be speaking. “Nepotism!” you cry! But no, Chris is speaking because I had the chance to his talk—called “Unexpectedly obvious”—and I thought “that’s perfect for UX London!”:

Let him take you on a journey through time and across the globe sharing stories of designs that solve problems in elegant if unusual ways.

Also on day two, you’ve got two additional workshops. Lou Downe will be running a workshop on designing good services, and Giles Turnbull will be running a workshop called “Writing for people who hate writing.”

I love that title! Usually when I contact speakers I don’t necessarily have a specific talk or workshop in mind, but I knew that I wanted that particular workshop from Giles.

When I wrote to Giles to ask come and speak, I began by telling how much I enjoy his blog—I’m a long-time suscriber to his RSS feed. He responded and said that he also reads my blog—we’re blog buddies! (That’s a terrible term but there should be a word for people who “know” each other only through reading each other’s websites.)

Anyway, that’s another little treasure trove of speakers added to the UX London roster:

That’s nineteen speakers already and we’re not done yet—expect further speaker announcements soon. But don’t wait on those announcements before getting your ticket. Get yours now!

More UX London speaker updates

It wasn’t that long ago that I told you about some of the speakers that have been added to the line-up for UX London in June: Steph Troeth, Heldiney Pereira, Lauren Pope, Laura Yarrow, and Inayaili León. Well, now I’ve got another five speakers to tell you about!

Aleks Melnikova will be giving a workshop on day one, June 28th—that’s the day with a focus on research.

Stephanie Marsh—who literally wrote the book on user research—will also be giving a workshop that day.

Before those workshops though, you’ll get to hear a talk from the one and only Kat Zhou, the creator of Design Ethically. By the way, you can hear Kat talking about deceptive design in a BBC radio documentary.

Day two has a focus on content design so who better to deliver a workshop than Sarah Winters, author of the Content Design book.

Finally, on day three—with its focus on design systems—I’m thrilled to announce that Adekunle Oduye will be giving a talk. He too is an author. He co-wrote the Design Engineering Handbook. I also had the pleasure of talking to Adekunle for an episode of the Clearleft podcast on design engineering.

So that’s another five excellent speakers added to the line-up:

That’s a total of fifteen speakers so far with more on the way. And I’ll be updating the site with more in-depth descriptions of the talks and workshops soon.

If you haven’t yet got your ticket for UX London, grab one now. You can buy tickets for individual days, or to get the full experience and the most value, get a ticket for all three days.

Declarative design

I feel like in the past few years there’s been a number of web design approaches that share a similar mindset. Intrinsic web design by Jen; Every Layout by Andy and Heydon; Utopia by Trys and James.

To some extent, their strengths lie in technological advances in CSS: flexbox, grid, calc, and so on. But more importantly, they share an approach. They all focus on creating the right inputs rather than trying to control every possible output. Leave the final calculations for those outputs to the browser—that’s what computers are good at.

As Andy puts it:

Be the browser’s mentor, not its micromanager.

Reflecting on Utopia’s approach, Jim Nielsen wrote:

We say CSS is “declarative”, but the more and more I write breakpoints to accommodate all the different ways a design can change across the viewport spectrum, the more I feel like I’m writing imperative code. At what quantity does a set of declarative rules begin to look like imperative instructions?

In contrast, one of the principles of Utopia is to be declarative and “describe what is to be done rather than command how to do it”. This approach declares a set of rules such that you could pick any viewport width and, using a formula, derive what the type size and spacing would be at that size.

Declarative! Maybe that’s the word I’ve been looking for to describe the commonalities between Utopia, Every Layout, and intrinsic web design.

So if declarative design is a thing, does that also mean imperative design is also a thing? And what might the tools and technologies for imperative design look like?

I think that Tailwind might be a good example of an imperative design tool. It’s only about the specific outputs. Systematic thinking is actively discouraged; instead you say exactly what you want the final pixels on the screen to be.

I’m not saying that declarative tools—like Utopia—are right and that imperative tools—like Tailwind—are wrong. As always, it depends. In this case, it depends on the mindset you have.

If you agree with this statement, you should probably use an imperative design tool:

CSS is broken and I want my tools to work around the way CSS has been designed.

But if you agree with this statement, you should probably use a declarative design tool:

CSS is awesome and I want my tools to amplify the way that CSS had been designed.

If you agree with the first statement but you then try using a declarative tool like Utopia or Every Layout, you will probably have a bad time. You’ll probably hate it. You may declare the tool to be “bad”.

Likewise if you agree with the second statement but you then try using an imperative tool like Tailwind, you will probably have a bad time. You’ll probably hate it. You may declare the tool to be “bad”.

It all depends on whether the philosophy behind the tool matches your own philosophy. If those philosophies match up, then using the tool will be productive and that tool will act as an amplifier—a bicycle for the mind. But if the philosophy of the tool doesn’t match your own philosophy, then you will be fighting the tool at every step—it will slow you down.

Knowing that this spectrum exists between declarative tools and imperative tools can help you when you’re evaluating technology. You can assess whether a web design tool is being marketed on the premise that CSS is broken or on the premise that CSS is awesome.

I wonder whether your path into web design and development might also factor into which end of the spectrum you’d identify with. Like, if your background is in declarative languages like HTML and CSS, maybe intrisic web design really resonates. But if your background is in imperative languages like JavaScript, perhaps Tailwind makes more sense to you.

Again, there’s no right or wrong here. This is about matching the right tool to the right mindset.

Personally, the declarative design approach fits me like a glove. It feels like it’s in the tradition of John’s A Dao Of Web Design or Ethan’s Responsive Web Design—ways of working with the grain of the web.

UX London speaker updates

If you’ve signed up to the UX London newsletter then this won’t be news to you, but more speakers have been added to the line-up.

Steph Troeth will be giving a workshop on day one. That’s the day with a strong focus on research, and when it comes to design research, Steph is unbeatable. You can hear some of her words of wisdom in an episode of the Clearleft podcast all about design research.

Heldiney Pereira will be speaking on day two. That’s the day with a focus on content design. Heldiney previously spoke at our Content By Design event and it was terrific—his perspective on content design as a product designer is invaluable.

Lauren Pope will also be on day two. She’ll be giving a workshop. She recently launched a really useful content audit toolkit and she’ll be bringing that expertise to her UX London workshop.

Day three is going to have a focus on design systems (and associated disciplines like design engineering and design ops). Both Laura Yarrow and Inayaili León will be giving talks on that day. You can expect some exciting war stories from the design system trenches of HM Land Registry and GitHub.

I’ve got some more speakers confirmed but I’m going to be a tease and make you wait a little longer for those names. But check out the line-up so far! This going to be such an excellent event (I know I’m biased, but really, look at that line-up!).

June 28th to 30th. Tobacco Dock, London. Get your ticket if you haven’t already.

Eventing

In person events are like buses. You go two years without one and then three come along at once.

My buffer is overflowing from experiencing three back-to-back events. Best of all, my participation was different each time.

First of all, there was Leading Design New York, where I was the host. The event was superb, although it’s a bit of a shame I didn’t have any time to properly experience Manhattan. I wasn’t able to do any touristy things or meet up with my friends who live in the city. Still the trip was well worth it.

Right after I got back from New York, I took the train to Edinburgh for the Design It Build It conference where I was a speaker. It was a good event. I particularly enjoyed Rafaela Ferro talk on accessibility. The last time I spoke at DIBI was 2011(!) so it was great to make a return visit. I liked that the audience was seated cabaret style. That felt safer than classroom-style seating, allowing more space between people. At the same time, it felt more social, encouraging more interaction between attendees. I met some really interesting people.

I got from Edinburgh just in time for UX Camp Brighton on the weekend, where I was an attendee. I felt like a bit of a moocher not giving a presentation, but I really, really enjoyed every session I attended. It’s been a long time since I’ve been at a Barcamp-style event—probably the last Indie Web Camp I attended, whenever that was. I’d forgotten how well the format works.

But even with all these in-person events, online events aren’t going anywhere anytime soon. Yesterday I started hosting the online portion of Leading Design New York and I’ll be doing it again today. The post-talk discussions with Julia and Lisa are lots of fun!

So in the space of just of a couple of weeks I’ve been a host, a speaker, and an attendee. Now it’s time for me to get my head back into one other event role: conference curator. No more buses/events are on the way for the next while, so I’m going to be fully devoted to organising the line-up for UX London 2022. Exciting!

Hosting Leading Design New York

I went to New York to host the Leading Design conference. It was weird and wonderful.

Weird, because it felt strange and surreal to be back in a physical space with other people all sharing the same experience.

Wonderful, for exactly the same reasons.

Leading Design

This was a good way to ease back into live events. It wasn’t a huge conference. Just over a hundred people. So it felt intimate, while still allowing people to quite literally have space to themselves.

I can’t tell you much about the post-talk interviews I conducted with the speakers. That’s because what happens at Leading Design stays at Leading Design, at least when it comes to the discussions after the talks. We made it clear that Leading Design was a safe place for everyone to share their stories, even if—especially if—those were stories you wouldn’t want to share publicly or at work.

I was bowled over by how generous and open and honest all the speakers were. Sure, there were valuable lessons about management and leadership, but there were also lots of very personal stories and insights. Time and time again I found myself genuinely moved by the vulnerability that the speakers displayed.

Leadership can be lonely. Sometimes very lonely. I got the impression that everyone—speakers and attendees alike—really, really appreciated having a non-digital space where they could come together and bond over shared travails. I know it’s a cliché to talk about “connecting” with others, but at this event it felt true.

The talks themselves were really good too. I loved seeing how themes emerged and wove themselves throughout the two days. Rebecca did a fantastic job of curating the line-up. I’ve been to a lot of events over the years and I’ve seen conference curation of varying degrees of thoughtfulness. Leading Design New York 2022 is right up there with the best of them. It was an honour to play the part of the host (though I felt very guilty when people congratulated me on such a great event—“Don’t thank me”, I said, “Thank Rebecca—I’m just the public face of the event; she did all the work!”)

My hosting duties aren’t over. This week we’ve got the virtual portion of Leading Design New York. There’ll be two days of revisiting some of the conference talks, and one day of workshops.

For the two days of talks, I’m going to be joined by two brilliant panelists for post-talk discussions—Julia Whitney and Lisa Welchman. This should be fun!

Best of all, for this portion of the event I don’t need to get into an airplane and cross the Atlantic.

That said, the journey was totally worth it for Leading Design New York. Also, by pure coincidence, the event coincided with St. Patrick’s Day. For the first time in two years, New York hosted its legendary parade and it was just a block or two away from the conference venue.

I nipped out during the lunch break to cheer on the marching bands. Every county was represented. When the representatives from county Cork went by, there’d be shouts of “Up Cork!” When the county Donegal delegation went by, it was “Up Donegal!”

It’s just a shame I couldn’t stick around for the representatives from county Down.

Going to New York

I’m flying to New York on Monday. That still sounds a little surreal to me, but it’s happening.

I’ll be hosting Leading Design New York. Even a month ago it wasn’t clear if the in-person event would even be going ahead. But there was a go/no-go decision and it was “go!” Now, as New York relaxes its mandates, it’s looking more and more like the right decision. It’s still probably going to feel a bit weird to be gathering together with other people …but it’s also going to feel long overdue.

Rebecca has put together a fantastic line-up of super-smart design leaders. My job will be to introduce them before they speak and then interview them afterwards, also handling questions from the audience.

I’m a little nervous just because I want to do a really good job. But I’ve been doing my homework. And given how well the hosting went for UX Fest, I’m probably being uneccesarily worried. I need to keep reminding myself to enjoy it. It’s a real privilege that I get to spend two days in the company of such erudite generous people. I should make the most of it.

If you’re going to be at Leading Design New York, I very much look forward to seeing you there.

If you’re not coming to Leading Design but you’re in the neighbourhood, let me know if you’ve got any plans for St. Patrick’s Day. I’ve already got my green paisley shirt picked out for my on-stage duties that day.

Curating UX London 2022

The first speakers are live on the UX London 2022 site! There are only five people announced for now—just enough to give you a flavour of what to expect. There will be many, many more.

Putting together the line-up of a three-day event is quite challenging, but kind of fun too. On the one hand, each day should be able to stand alone. After all, there are one-day tickets available. On the other hand, it should feel like one cohesive conference, not three separate events.

I’ve decided to structure the three days to somewhat mimic the design process…

The first day is all about planning and preparation. This is like the first diamond in the double-diamond process: building the right thing. That means plenty of emphasis on research.

The second day is about creation and execution. It’s like that second diamond: building the thing right. This could cover potentially everything but this year the focus will be on content design.

The third day is like the third diamond in the double dia— no, wait. The third day is about growing, scaling, and maintaining design. That means there’ll be quite an emphasis on topics like design systems and design engineering, maybe design ops.

But none of the days will be exclusively about a single topic. There are evergreen topics that apply throughout the process: product design, design ethics, inclusive design.

It’s a lot to juggle! But I’m managing to overcome choice paralysis and assemble a very exciting line-up indeed. Trust me—you won’t want to miss this!

Early bird tickets are available until February 28th. That’s just a few days away. I recommend getting your tickets now—you won’t regret it!

Quite a few people are bringing their entire teams, which is perfect. UX London can be both an educational experience and a team-bonding exercise. Let’s face it, it’s been too long since any of us have had a good off-site.

If you’re one of those lucky people who’s coming along (or if you’re planning to), I’m curious: given the themes mentioned above, are there specific topics that you’d hope to see covered? Drop me a line and let me know.

Also, if you read the description of the event and think “Oh, I know the perfect speaker!” then I’d love to hear from you. Maybe that speaker is you. (Although, cards on the table; if you look like me—another middle-age white man—I may take some convincing.)

Right. Time to get back to my crazy wall of conference curation.

Partnering with Google on web.dev

When the web.dev team at Google contacted Clearleft about writing a course on responsive design, our eyes lit up.

This was clearly a good fit. For one thing, Clearleft has been pioneering responsive design from day one—we helped launch some of the first responsive sites in the UK. But there was another reason why this partnership sounded good: we had the same approach to writing and sharing.

Ever since Clearleft was founded in 2005 we’ve taken on board the motto of the World Wide Web itself: let’s share what we know. As well as doing the work, we enjoy sharing how the work gets done. Whether it’s case studies, blog posts, podcasts, or conference talks, we’re always thinking about ways to contribute to the web community.

Many other great resources have contributed to our collective knowledge: A List Apart, CSS Tricks, Smashing Magazine, Mozilla Developer Network, and more recently web.dev, which has become an excellent resource for front-end developers. But they wanted to make sure that designers were also included. Una described her plan for a fifteen-part course on modern responsive design aimed at web designers.

It was ambitious. The plan included some cutting edge technology that’s just shipping in browsers now. It sounded daunting and exciting in equal measure. Mostly it sounded like far too good an opportunity for Clearleft to pass up so we jumped on it.

With my fellow Clearlefties otherwise engaged in client work, it fell to me to tap out the actual words. Fortunately I’ve had plenty of experience with my own website of moving my fingers up and down on a keyboard in attempt to get concepts out of my head and onto the screen. I familiarised myself with the house style and got to work.

I had lots of help from the Chrome developer relations team at Google. Project management (thanks, Terry!), technical editing (thanks, Adam!), and copy editing (thanks, Rachel!) were provided to me.

Working with Rachel again was a real treat—she wrote the second edition of my book, HTML5 For Web Designers. Every time she suggested a change to something I had written, I found myself slapping my forehead and saying “Of course! That’s so much better!” It felt great to have someone else be a content buddy for me.

We had a weekly video call to check in and make sure everything was on track. There was also an epic spreadsheet to track the flow of each module as they progressed from outline to first draft to second draft.

Those were just the stages when the words were in a Google doc. After that, the content moved to Github and there was a whole other process to shepherd it towards going live.

Take note of the license in that repo: Creative Commons Attribution 3.0. That means that you—or anyone—is free to use and reuse all the material (as long as you include a credit). I think I might republish the fifteen articles on my site at some point.

If you’d like to peruse the outcome of this collaboration between Clearleft and Google, head on over to web.dev and learn responsive design. Then feel free to share it!

  1. Introduction
  2. Media queries
  3. Internationalization
  4. Macro layouts
  5. Micro layouts
  6. Typography
  7. Responsive images
  8. The picture element
  9. Icons
  10. Theming
  11. Accessibility
  12. Interaction
  13. User interface patterns
  14. Media features
  15. Screen configurations

Media queries with display-mode

It’s said that the best way to learn about something is to teach it. I certainly found that to be true when I was writing the web.dev course on responsive design.

I felt fairly confident about some of the topics, but I felt somewhat out of my depth when it came to some of the newer modern additions to browsers. The last few modules in particular were unexplored areas for me, with topics like screen configurations and media features. I learned a lot about those topics by writing about them.

Best of all, I got to put my new-found knowledge to use! Here’s how…

The Session is a progressive web app. If you add it to the home screen of your mobile device, then when you launch the site by tapping on its icon, it behaves just like a native app.

In the web app manifest file for The Session, the display-mode property is set to “standalone.” That means it will launch without any browser chrome: no address bar and no back button. It’s up to me to provide the functionality that the browser usually takes care of.

So I added a back button in the navigation interface. It only appears on small screens.

Do you see the assumption I made?

I figured that the back button was most necessary in the situation where the site had been added to the home screen. That only happens on mobile devices, right?

Nope. If you’re using Chrome or Edge on a desktop device, you will be actively encourged to “install” The Session. If you do that, then just as on mobile, the site will behave like a standalone native app and launch without any browser chrome.

So desktop users who install the progressive web app don’t get any back button (because in my CSS I declare that the back button in the interface should only appear on small screens).

I was alerted to this issue on The Session:

It downloaded for me but there’s a bug, Jeremy - there doesn’t seem to be a way to go back.

Luckily, this happened as I was writing the module on media features. I knew exactly how to solve this problem because now I knew about the existence of the display-mode media feature. It allows you to write media queries that match the possible values of display-mode in a web app manifest:

.goback {
  display: none;
}
@media (display-mode: standalone) {
  .goback {
    display: inline;
  }
}

Now the back button shows up if you “install” The Session, regardless of whether that’s on mobile or desktop.

Previously I made the mistake of inferring whether or not to show the back button based on screen size. But the display-mode media feature allowed me to test the actual condition I cared about: is this user navigating in standalone mode?

If I hadn’t been writing about media features, I don’t think I would’ve been able to solve the problem. It’s a really good feeling when you’ve just learned something new, and then you immediately find exactly the right use case for it!

Even more writing on web.dev

The final five are here! The course on responsive design I wrote for web.dev is now complete, just in time for Christmas. The five new modules are:

  1. Accessibility
  2. Interaction
  3. User interface patterns
  4. Media features
  5. Screen configurations

These five felt quite “big picture”, and often quite future-facing. I certainly learned a lot researching proposals for potential media features and foldable screens. That felt like a fitting way to close out the course, bookending it nicely with the history of responsive design in the introduction.

And with that, the full course is now online. Go forth and learn responsive design!

More writing on web.dev

Last month I wrote about writing on web.dev. At that time, the first five parts of a fourteen-part course on responsive design had been published. I’m pleased to say that the next five parts are now available. They are:

  1. Typography
  2. Responsive images
  3. The picture element
  4. Icons
  5. Theming

It wasn’t planned, but these five modules feel like they belong together. The first five modules were concerned with layout tools—media queries, flexbox, grid, and even container queries. The latest five modules are about the individual elements of design—type, colour, and images. But those elements are examined through the lens of responsiveness; responsive typography with clamp, responsive colour with prefers-color-scheme, and responsive images with picture and srcset.

The final five modules should be available later this month. In the mean time, I hope you like the first ten modules.