7 semantic lenses for design

I’ve assembled a jumble of tools over my decade and a half working in UX design. Eventually, I distilled my thinking into these 7 ways of looking at design problems, and like any content designer I’m constantly editing them. (First there were 5, then 7, and then I wrote a book which holds 6, after a heroic feat of information architecture).

I’ve described these as ‘lenses’ (borrowing from Dan Brown), or semantic framing devices. Because they frame common problems, they may describe design practices you already have, even if you don’t recognise—or name—them the same way.

Naming your own tools is important. It’s helped me more quickly recognise when the need for them crops up. And, as is the way when you name things, those needs now hit me with the subtlety of a frying pan to the face. That lack of subtlety doesn’t always make the problems they address easier to resolve—for design problems are 99% communication problems, and communication is dependent on other people, so is always hard. But if you can name a thing you can know it, and therefore cope better with it.

I have a book due out this summer from A Book Apart that polishes up these lenses and turns them on their heads in different ways. I learned a lot about these tools, and myself, in writing it. But for now, here’s a brief introduction to each lens.

1. Concept definition

This is how design happens, most of the time:

• First we identify the problem
• Then we explore solutions
• But not necessarily in that order

But there is also this hidden woolly tangle of definition that winds around and between these steps. If it’s not wrangled with, once you move from the data of problem identification into the visual representation of a solution, you can easily slide past your moment to fully define what it is you’re making.

The lack of strong definition becomes obvious when you get to the stage of labeling or categorizing. I’ve seen it show up when an API has to make a product extensible for others to use, and it’s painfully clear how many similar concepts (or different concepts with similar names) a product has.

Naming is the hardest problem in computer science because the things that names define—the concepts we hold in our heads—are slippery and often not at all mutual. It’s not hard because a single name might solve that slipperiness.

We argue over names as though the right label will magically create clarity and bring many different perspectives into alignment. But that treats naming like a branding exercise: it gives you a banner to rally behind, but it just passes the buck of clarity to some other layer of your product. In the past, I’ve created glossaries for every sizeable new feature in a whole product, not just the ones that get prominent marketing. This helps, if only because it doesn’t ignore any product layer in favour of another.

If you see that concept definition step is missing, there are many ways to address it. Those ways (interviewing, diagramming, journey mapping, trying things out) can help you shake out what’s unclear until a concept is at its most lucid and simple. Only then can you move on to finding the right tupperware lid for your idea’s particular container.

2. Concept fit

This is where the real work of naming happens in an architectural sense, I think—this sorting of all the tupperware lids in the drawer.

Based on a firmer concept, you can now pin down and name the primary nouns, verbs, and organizational structure that give shape to your product or feature: the kit of parts. You can only do this if you’ve got your concept well defined from the get go—when you know what’s inside the container.

I’ve been asked to name lots of things in my working life. In my experience, there is often no rightness to a name off the bat, only a fitness and comfort with the entity it represents and the system it’s part of. There’s no objective truth here: it’s all choice. That choice is a judgement call just like any other design choice—in fact, it can vastly shape other design choices, even choices of visual pattern or visual language. This is why it’s about fitness and feel, not precision or objectivity.

Fitness is also about fitness to the namers and the audience it’s named for—it’s essential that a name fit the product and the team and the strategy it lives within, as well as the audience receiving and hearing it—without that comfortable match being catered for, the most “precise” name can feel random and jarring.

3. Narratives

The story of a product can reveal itself in different ways:

Paths and journeys: When customers take either a self-directed or guided path through a product or feature, those steps form a narrative that needs coherence, empathy and clarity.

Groups and categories: The way the product is categorised tells a story, not just by its labels but how we position and group them, creating coherence or dissonance between parts of the product.

Narrative approaches to design are a superpower because they force you to zoom out of your work linearly but also omnidirectionally. When you think about categories as a form of narrative, you suddenly see all of the storytelling effects your concept might create, intentionally or unintentionally, across a system. The way AI works is essentially a matter of narrative via categorisation: it is pattern-finding and generating linear meaning from across the mess of Internet we’ve presented it with. But that’s a topic for another post.

4. Relationships

Relationship is somewhat a subset of narrative, but it’s also a spatial consideration, so it gets its own lens (for now). It’s not specific to content-focused aspects of design, but rather is a basic requirement of designing interfaces.

Often late-stage problems in product or feature design can be offset by:

• Analysing topics and relationships (perhaps creating a model or taxonomy)
• Grouping like topics together
• Understanding topic hierarchy and priority for your audience and use case

Finding relationships — intentional, unintentional, beneficial and toxic—is a very satisfying part of the design process when you have control of it. Encountering unexpected relationships is a shock to any delicate design sensibility and is best avoided.

5. Modularity

Modularity is a fancy way of saying “blocks”, and by blocks I mean elements — even sub-sentence-level text elements — that can be taken apart and reused in different formations.

As a progression from the previous lenses, you can begin thinking in blocks in order to address the content that expresses your idea at the sentence or string level. But this does not mean you are now embarking on a fun exercise in creative writing. No: you are now working in clay. Or Lego, if you like. You are building things out of the pieces of your concept: the kit of parts you put together.

All text is material, and there are still chunks of reusable meaning to be understood in the smallest phrase. (If there aren’t, it’s simply filler).

Modularity, then, is about finding patterns in text as you create it. There are several ways to start thinking of text in this way—here are just two:

• Parts of speech: By understanding the structure of sentences (verbs, nouns, objects) you can see how those parts can become markers or signposts in an experience, however they are visually presented. You’ll find them crop up in obvious components—buttons and page titles—and in less obvious ways in modal dialogs and help text. Every word on the screen has the power to form patterns, basically—and you can use that as a design tool.
• Blocks of text: A squint test will show you the macro effect of text pattern variation or consistency within an experience. For example, you can easily tell that list items should follow a consistent length, while paragraph text might benefit from variation. In this way, you can think about text as a visual element that adds pace and rhythm to the page, as well as (hopefully) meaning. This is the dance-like balance between the visual and semantic in design that is, also hopefully, fun to get right.

6. Expression

Now, twinned with Modularity, we get closer to crafting the precise words in the interface, the real writing. But wait! There are still layers here. There are always layers.

Well-crafted UX writing needs solid principles and guidelines to be executed consistently, and it needs to be applied with a clear understanding of the design concept. That’s a matter of:

• Focus: cutting away irrelevant topics.
• Consistency: Setting and following content guidelines.
• Ruthless editing: Minimising text in the interface (sometimes to zero).

Getting at clarity of expression is, for my money, the most fun part of design work. It’s the editing task, the taking off of accessories, the standing back and looking at the painting. It’s the part that gives you the biggest dopamine rush, if your brain happens to be organized in a particular way.

7. Style

This is what’s often called “voice and tone”, but I think style is a more elastic and broadly applicable word to use for the job we’re talking about, especially in these days when a thin wash of “tone” can be reasonably delivered by AI. Anyone can match colours in an outfit. Not everyone has style.

To have style, a product needs to:

• Have an opinion about itself. This is the most immediately perceptible thing about good product writing, and absolutely the hardest thing to achieve in a design. It needs to know why it has the style it has, and what it is fundamentally ‘about’ (concept definition again).
• Feel as baked in and organic as possible — as though it were the individual mind of someone highly intelligent speaking to you, but in words and phrases that feel natural and as though they could be read aloud.
• Understand its reader’s language level and vocabulary—even if it doesn’t exactly match it. It’s fine for style to overtake basic accessibility in some cases.

These are the elements that style brings to the table—just as the words you use to speak define the shape and feel of your own vernacular. Try to divorce any podcast you listen to from the host’s voice. It’s impossible.

Style is not necessarily heightened. It’s impossible not to have tone (though very possible for it to be jarring if it’s not created intentionally)—but it is possible, and sometimes advisable, not to have much style, or to have a style that is minimalist as a fashion designer’s black-on-black uniform. Sometimes the right style is the one that fades into the background.

At its best, style isn’t simply pushed outward, it arises and matures in conversation with an audience. All design is a conversation between what the product needs to do; what the business wants to communicate; and what the user needs to understand. A thoughtfully crafted writing style means having empathy with the end user even down to the level of syntax, and using language as a tool to show that their needs are being addressed.

All of these lenses are ways of breaking down design problems into problems of meaning. Words, meaning and definitions are powerful tools—tools we need to manage, or they’ll manage us.

You can read more in Design by Definition, available for pre-order now.