Semantic Grammar, in plain language

One idea, three everyday examples. Pick the one that fits you.

Planning a trip with friends.

The old way

When someone makes an app, they usually start by drawing the screens. This screen has a button here, a list there. Then they connect the screens: tap this, go there. For a long time that worked fine, because a person drew every screen by hand.

Now apps can build parts of themselves while you're using them. They rearrange based on what you did yesterday, generate new bits on the fly, and react to your situation in ways nobody drew in advance. You can't hand-draw a screen that doesn't exist until the moment it appears. So if you can't draw the screens anymore, what do you actually design?

Design the meaning, not the screen

Underneath any app there's a layer that doesn't change when the screen changes. Think about a group chat for planning a trip with friends. The screens might look totally different on your phone vs. a friend's, or change as the trip gets closer, but some things stay true the whole time:

  • Actors: the people involved who actually want different things. The friend who wants the cheapest option, the friend who wants the nicest place, the friend who just wants it decided already. They're not "users." They're people pulling in different directions.
  • Objects: the things that stick around. The trip plan itself. It exists as a rough idea, then a booked thing, then a memory. Same object, different stages.
  • States: what those things can be. The plan can be "just an idea," "voted on," "booked," "cancelled." And here's the key part: "booked" feels like relief to the organizer and like "oh no I have to pay now" to everyone else. One fact, different meaning per person.
  • Events: moments that change everything. Someone backs out. To them it's no big deal. To the organizer it's a budget that no longer works. To the group it's a fight about to happen.
  • Conflicts: the spots where people want things that can't both be true. This is the actual hard part, and it's the part most people skip. The design problem isn't "what color is the button." It's "whose version of the truth wins, and how do we keep it fair."

That underneath part is the semantic layer, a fancy phrase for what this thing is really about.

Meaning has a tone

The same information can be delivered loud or quiet, urgent or relaxed, formal or friendly. Picking the right tone is its own job. The essay names five dials you turn:

  • Gravity: how much is at stake? "Someone reacted to your message" is low. "Confirm you're paying the €400 deposit now" is high. High stakes means make it plain, boring, hard to misread.
  • Tempo: how much time pressure? Browsing options for a trip three months out vs. "the cheap flights expire in 10 minutes" get totally different treatment.
  • Intimacy: how personal is it? How much each person can actually afford is sensitive. You wouldn't blast it to the whole group the way you'd share a hotel photo.
  • Authority: who's talking, and do they get to boss you around? A friend's nudge vs. the booking site's "non-refundable" warning speak in different voices.
  • Reversibility: can you undo it? Changing the proposed dates: whatever. Paying the non-refundable deposit: the app should make you stop and think.

These five together create the register, the right "voice" for this thing at this moment. A good app feels relaxed while you're still dreaming up the trip and serious when money is about to leave your account. Same app, different register.

The screen is the result, not the start

Once you know the meaning (semantic layer) and the tone (signal layer), the actual screen, the expression layer, is what falls out of those two. You don't draw it first. You derive it.

Example: the deposit deadline is tonight and three friends still haven't paid. Good version: a clear, calm summary of who's in, who's out, what happens at midnight, and one tap to remind the stragglers. Bad version: a cheery card with confetti and "Almost there! 🎉" that buries the deadline. The data was right. The register was wrong.

So what's the designer's job?

Not drawing every screen. It's deciding what the thing means, and refereeing the tone when different forces disagree, like when the app knows the deadline is urgent but you don't want it publicly shaming the friends who haven't paid. There's no clean answer. Someone has to make that call out loud instead of pretending the tension isn't there. That refereeing is the job.

The honest part. None of this is proven. It's a way of looking at the problem that makes the real hard parts visible earlier, before anyone wastes time drawing screens that miss the point.

The whole test

If you can name the actors and say where they conflict for an app you use every day, you've got the core. That's it.

Notice that the three versions above are the same idea. Same five things underneath (actors, objects, states, events, conflicts), same five dials, same "the screen is the result." Only the context changed, and the tone changed with it. That is the whole point of the framework, shown rather than explained.

Read the full essay →