Journal tags: understanding

We use metaphors all the time. To quote George Lakoff, we live by them.

We use analogies some of the time. They’re particularly useful when we’re wrapping our heads around something new. By comparing something novel to something familiar, we can make a shortcut to comprehension, or at least, categorisation.

But we need a certain amount of vigilance when it comes to analogies. Just because something is like something else doesn’t mean it’s the same.

With that in mind, here are some ways that people are describing generative machine learning tools. Large language models are like…

• …a blurry JPEG of the web,
• …fly-by-wire avionics,
• …drum machines,
• …an octopus.

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.

The latest episode of the Clearleft podcast is out. If you’re a subscriber, it will magically appear in your podcast software of choice using the power of RSS. If you’re not a subscriber, it isn’t too late to change that.

This week’s episode is all about design ops. I began contructing the episode by gathering raw material from talks at Leading Design. There’s good stuff from Kim Fellman, Jacqui Frey, Courtney Kaplan, and Meredith Black.

But as I was putting the snippets together, I felt like the episode was missing something. It needed a bit of oomph. So I harangued Andy for some of his time. I wasn’t just fishing for spicy hot takes—something that Andy is known for. Andy is also the right person to explain design ops. If you search for that term, one of the first results you’ll get is a post he wrote on the Clearleft blog a few years back called Design Ops — A New Discipline.

I remember helping Andy edit that post and I distinctly recall my feedback. The initial post didn’t have a definition of the term, and I felt that a definition was necessary (and Andy added one to the post).

My cluenessness about the meaning of terms like “design ops” or “service design” isn’t some schtick I’m putting on for the benefit of the podcast. I’m genuinely trying to understand these terms better. I don’t like the feeling of hearing a term being used a lot without a clear understanding of what that term means. All too often my understanding feels more like “I think I know it means, but I’m not sure I could describe it.” I’m not comfortable with that.

Making podcast episodes on these topics—which are outside my comfort zone—has been really helpful. I now feel like I have a much better understanding of service design, design ops and other topical terms. I hope that the podcast will be just as helpful for listeners who feel as bamboozled as I do.

Ben Holliday recently said:

The secret of design being useful in many places is not talking about design too much and just getting on with it. I sometimes think we create significant language barriers with job titles, design theory and making people learn a new language for the privilege of working with us.

I think there’s some truth to that. Andy disagrees. Strongly.

In our chat, Andy and I had what politicians would describe as “a robust discussion.” I certainly got some great material for the podcast (though some of the more contentious bits remain on the cutting room floor).

Calling on Andy for this episode was definitely the right call. I definitely got the added oomph I was looking for. In fact, this ended up being one of my favourite episodes.

There’s a lot of snappy editing, all in service of crafting a compelling narrative. First, there’s the origin story of design ops. Then there’s an explanation of what it entails. From around the 13 minute mark, there’s a pivot—via design systems—into asking whether introducing a new term is exclusionary. That’s when the sparks start to fly. Finally, I pull it back to talking about how Clearleft can help in providing design ops as a service.

The whole episode comes out at 21 minutes, which feels just right to me.

I’m really pleased with how this episode turned out, and I hope you’ll like it too. Have a listen and decide for yourself.

I think a lot about Danielle’s talk at Patterns Day last year.

Around about the six minute mark she starts talking about gaps and overlaps.

Gaps are where hidden complexity live. If we don’t have a category to cover it, in effect it becomes invisible. But that doesn’t mean it’s not there. Unidentified gaps cause inconsistency and confusion.

Overlaps occur when two separate categories encompass some of the same areas of responsibility. They cause conflict, duplication of effort, and unnecessary friction.

This is the bit I keep thinking about. It’s such an insightful lens to view things through. On just about any project, tensions are almost due to either gaps (“I thought someone else was doing that”) or overlaps (“Oh, you’re doing that? I thought we were doing that”).

When I was talking to Gerry on his new podcast recently, we were trying to figure out why web performance is in such a woeful state. I mused that there may be a gap. Perhaps designers think it’s a technical problem and developers think it’s a design problem. I guess you could try to bridge this gap by having someone whose job is to focus entirely on performance. But I suspect the better—but harder—solution is to create a shared culture of performance, of the kind Lara wrote about in her book:

Performance is truly everyone’s responsibility. Anyone who affects the user experience of a site has a relationship to how it performs. While it’s possible for you to single-handedly build and maintain an incredibly fast experience, you’d be constantly fighting an uphill battle when other contributors touch the site and make changes, or as the Web continues to evolve.

I suspect there’s a similar ownership gap at play when it comes to the ubiquitous obtrusive overlays that are plastered on so many websites these days.

Kirill Grouchnikov recently published a gallery of screenshots showcasing the beauty of modern mobile websites:

There are two things common between the websites in these screenshots that I took yesterday.

1. They are beautifully designed, with great typography, clear branding, all optimized for readability.
2. I had to install Firefox, Adblock Plus and uBlock Origin, as well as manually select and remove additional elements such as subscription overlays.

The web can be beautiful. Except it’s not right now.

How is this dissonance possible? How can designers and developers who clearly care about the user experience be responsible for unleashing such user-hostile interfaces?

PM/Legal/Marketing made me do it

I get that. But surely the solution can’t be to shrug our shoulders, pass the buck, and say “not my job.” Somebody designed each one of those obtrusive overlays. Somebody coded up each one and pushed them into production.

It’s clear that this is a problem of communication and understanding, rather than a technical problem. As always. We like to talk about how hard and complex our technical work is, but frankly, it’s a lot easier to get a computer to do what you want than to convince a human. Not least because you also need to understand what that other human wants. As Danielle says:

Recognising the gaps and overlaps is only half the battle. If we apply tools to a people problem, we will only end up moving the problem somewhere else.

Some issues can be solved with better tools or better processes. In most of our workplaces, we tend to reach for tools and processes by default, because they feel easier to implement. But as often as not, it’s not a technology problem. It’s a people problem. And the solution actually involves communication skills, or effective dialogue.

So let’s say it is someone in the marketing department who is pushing to have an obtrusive newsletter sign-up form get shoved in the user’s face. Talk to them. Figure out what their goals are—what outcome are they hoping to get to. If they don’t seem to understand the user-experience implications, talk to them about that. But it needs to be a two-way conversation. You need to understand what they need before you start telling them what you want.

I realise that makes it sound patronisingly simple, and I know that in actuality it’s a sisyphean task. It may be that genuine understanding between people is the wickedest of design problems. But even if this problem seems insurmoutable, at least you’d be tackling the right problem.

Because the web can’t survive like this.