Shikake: Designing the Trigger, Not the Mandate

If you are reading this, you probably just spent a few minutes inside a slide deck that — by its own admission — was running on you the entire time. A glowing dot you could not help clicking. A progress bar that pulled you to the end. Eight cards you flipped because a counter said 0/8. That deck was a small demonstration of shikake, and I built it that way on purpose. Now I want to tell you why the idea matters to me, and why I think it is badly misunderstood.

Shikake (仕掛け) is a Japanese concept — coined by Naohiro Matsumura at Osaka University — for a small physical or digital cue that triggers a behavior people are glad to perform. The basketball-hoop bin that makes you want to score. The piano staircase you take instead of the escalator. No mandate, no penalty, no lecture. Just an invitation that curiosity or play makes hard to refuse.

It is easy to fall in love with the mechanism. And that, exactly, is the trap.

The mechanism is the easy part

When most teams encounter shikake, they reach straight for the trick. They want the basketball hoop. They want the confetti, the streak, the badge, the clever little animation. I have sat in dozens of workshops where a team gets excited about a solution — usually an app, lately an AI feature — and spends the rest of the day decorating it with engagement mechanics. The mechanism feels like the innovation. It almost never is.

Here is what is actually true: the basketball-hoop bin does not work because someone thought of a basketball hoop. It works because someone understood that people already carry a small, latent urge to aim and score — and that a bin, of all things, usually gives that urge nowhere to go. The hoop did not create the behavior. It released one that was already there. The genius is not the hoop. The genius is the observation that came before it.

Shikake is really a design thinking story

This is why I treat shikake not as a bag of tricks but as a discipline that sits squarely inside design thinking. Every shikake that works is downstream of someone deeply understanding a human being: what they already want, what they are already doing, where the friction lives, what the context allows. That is the empathy and observation work — the part design thinking puts first, and the part organizations are most tempted to skip.

The order matters more than anything else. You cannot design a good trigger for a behavior you have not understood. If you start from the solution — "let us gamify it," "let us add a nudge," "let us put an AI assistant on it" — you will produce something that looks like a shikake and works like noise. People feel manipulated, or they simply ignore it. The cue only lands when it is aimed at a need that was already there, waiting.

Matsumura's own test for a true shikake captures this beautifully. He asks whether it is Fair (no one is tricked or harmed), Attractive (you genuinely want to do it), and Dual-purpose (your reason and the designer's goal can differ, but both are served). I read FAD as a humility test. You can only pass it if you understood the person well enough to know what they would find fair, what they would find attractive, and what they were quietly trying to do anyway. Fail to understand them, and you fail FAD by definition.

Where it goes wrong — and why that is instructive

The sharpest lesson in shikake is what happens when you keep the mechanism but skip the understanding. The same burst of confetti that feels delightful when you complete a task in a project app felt sinister when a trading app fired it after a risky trade — and it was pulled after the backlash. Identical mechanic. Opposite ethics. The difference was not the animation; it was whether the design respected what was actually in the person's interest.

That is the part I want every team I work with to internalize. The mechanism is ethically neutral and creatively cheap — in software you can copy any trigger in an afternoon. The hard, valuable, non-copyable work is understanding the human well enough to know whether you are serving them or exploiting them. Design thinking's insistence on empathy is not a soft warm-up exercise. It is the thing that keeps a clever solution from quietly becoming a harmful one.

Start with the behavior, not the idea

So my takeaway, after years of building these things with clients across very different cultures and industries, is almost embarrassingly simple: start with the behavior you want, and the human who will perform it — never with the solution you are excited about.

Find the behavior you keep asking for and keep not getting. Understand, honestly, why people do not do it today — not the reason you assume, the reason they would actually give. Only then design the invitation: swap the instruction for curiosity, play, feedback, a goal small enough to accept. And before you ship it, run it through FAD. Fair, attractive, dual-purpose — or back to the drawing board.

The best solutions do not tell people what to do. They make people want to. But you only earn the right to design that kind of solution by doing the unglamorous work first: understanding the need and the behavior before you fall in love with the answer. The deck you just clicked through was the trigger. This is the part that actually matters.