Howdy, picnickers! Now that the Northeast is no longer inundated with wildfire smoke, it’s time to head out again and touch grass.

First off, announcements: catch me live this Friday (July 24, 2026) on Dan Hon’s sensational internet show How People Work (sign up here). If you think I have no filter on the socials, just wait until I’m on air. Come tune in, it’ll be great.

Now, onto the main feature.

I love analogous domain case studies. Sadly, the term is underused to the point that searching for it gets you some electrical nonsense. Fortunately — before you reach for a chatbot to explain it to you — there’s a paper for that. Unfortunately, the paper itself is from an analogous domain (in this case, whatever biomemetics is). But the idea is quite straightforward: you go look at what related fields are doing and then steal their ideas.

Software engineering (not to be confused with programming) is one of my favorite analogous domains to mine. Game design is another. But once you get off the computer, the world really opens up, because the real world is where service design lives, and almost everything is service design.

Which brings me to what you’ve been waiting for three paragraphs: the ham biscuit sign (specifically: Eric Bailey’s excellent write-up of what this is, what need it solves, and why this elegantly simple solution actually presents a myriad new problems for customers who are ravenous for a ham biscuit).

To me, the ham biscuit sign perfectly encapsulates how design is actually done in almost every organization. Someone (a non-design stakeholder) notices a problem. They draft up a solution and send it off to be implemented. The feature makes it into production (here: the ham biscuit sign is electrified) and the problem is therefore solved. Then the first actual designer to encounter the feature comes up with a dozen different ways it’s a bad solution — but it’s too late. The stakeholder pushed their requirements through faster than anyone who knew what they were doing could catch them.

Now, let’s go back to our own domain (software design) where everyone is now required to create as many ham biscuit signs as possible, as quickly as possible, on pain of layoff.

To be fair to AI, this problem has always been with us. Role responsibilities got sorted neatly into “coming up with ideas” and “executing the ideas.” This split insulated the idea-havers from any consequences of what they were doing; they could be judged solely on how novel and creative their ideas were, and leave little details like “does it actually solve the problem” or “is solving this problem even important” for the production-oriented silo downstream of them to sort out.

And sure, coming up with ideas is not easy — especially if your strategy for ideation is to stare at an empty Google Doc and think really hard. Because without being exposed to real user needs, the only place those ideas can come from is other software you’ve used. Predictably, the ideas “generated” this way are extremely boring: we will add “end of year” to our product (not because it makes sense, but because Spotify did it); we will add an FAQ page to our product (not because it makes sense — the FAQ format is just a dodge from doing real IA work — but because other websites have it); we will add dark mode (solely because Discord has it); we will add a task counter to your everyday life (solely because Jira has it).

In an effort to rationalize this, someone inevitably says “we are jamming pointless features into the product because a long feature checklist makes it easier to sell.” Which sounds neat, but is not actually true. Sales work is a narrative and every random widget Product adds makes it harder for that narrative to be coherent. The secret to selling well is to minimize the number of things you talk about:

AI’s role in all this should now be obvious: by now, every feature from every public-facing repo has been scraped into your model’s training dataset. Getting it to regurgitate the code is therefore a trivial exercise; far easier than doing the work of determining whether the feature is necessary or not.

So let us strike at the heart of the problem: that despite the appearance of completeness, the user stories being assigned for development are in fact without substance, filled with weasel terms like “users want to manage XYZ” that do not explain the expected user behavior, or its business value, in any meaningful sense. The necessity of these individual features may even be “validated” by asking users “do you want this feature?”

The title of Robin-Yann’s article sort of gives away the game here: the solution to the ham biscuit signs in your product is to think about them from a holistic point of view. Not as individual touchpoints (encountered by users who, thanks to the user story format, come pre-defined as wanting to use them) but as stages of a workflow. This is exactly what Eric does with the original ham biscuit sign in his own article, by the way: position it as a step in the user’s journey towards the ham biscuit, which enables him to think about how it is helping, and how it might actually be harming.

But frankly, the first step is not “think per workflow.” It is really just “think.” And the main cause of the ham biscuit sign is that no one did think. A stakeholder asked for “a design” (noun) without design (verb). And that is what they got.

AI, of course, is a tool for not-thinking. But there is a useful set of tools for thinking specifically about workflows that designers have come up with over the years.

First of all, the much-maligned JTBD, as it turns out, is much more than the tired “when X I want to Y” phrase. There’s a whole toolkit (actually there are many, with various organizations) that you can easily wedge into your team’s process if they are already using the phrase in Jira tickets.

To focus on key workflows rather than “wouldn’t it be cool if…” features, there’s Duncan Stephen’s very accessible write-up for how to employ the top tasks method.

And finally, a useful filter for your most critical failure cases; the ones that don’t appear in any “happy path” demo but are nevertheless something real users experience every day. Failure cases are especially interesting to me as a designer, because no features can get you out of a situation that broken features got you into in the first place. The resolution requires excellent content instead (and Amy Hupe has some tips for good error message design over on the Picalilli blog).

— Pavel at the Product Picnic