Poka-Yoke: The Fine Art of Mistake Proofing – Game Planning With Science! Part 10

You remember that time you plugged your HDMI cable into your PS4 upside-down and fried it’s video card? Or that time you clamped your ski-boots into your skis backwards and almost killed yourself on a black diamond slope as a result? Or that time you put a k-cup into a Keurig machine sideways an sprayed hot coffee all over the kitchen?

No, you don’t. Because you can’t do any of those things.

Those products are all designed so that they can only be used in the proper manner. The grooves on the HDMI connector, the specific clamps and catches on skis and boots, and the tapered design of Keurig k-cups mean that the proper application of the product is as obvious as its improper use is impossible.

By Reading This Post, You Will Learn

The benefits of poka-yoke in terms of the seven forms of muda from Part 9

Poka-Yoke (ポカヨケ)

Poka-yoke translates literally as “mistake-proofing*”, and it’s one of the defining characteristics of the Toyota Production System. Observing poka-yoke means designing products in order to reduce or eliminate the potential for human error by the end user. For a consumer, it means designing products so as to ensure the product is used properly. Within a production context, it means designing component parts so that workers on the assembly line can only assemble them properly.

In other words, you’re not just training people to not screw up, you’re giving them work that they literally CAN’T screw up.

And if you’re trying to rein in defects, curtailing the potential for human error is a great way to do it.

Poka-Yoke for Games: The User Story

What we do as game developers is far more complicated than assembling cars to spec. But that doesn’t mean we can’t embrace the philosophy of poka-yoke. And the best way I’ve seen to accomplish this is the user story. I covered user stories in Part 6 of “Game Planning With Science!”. Within the context of feature estimation, they represent a vector for trying to understand features before you start coding them.

But, within the context of waste elimination, they are powerful tools for greatly reducing the potential for human error.

The Elements of a Good User Story

As I mentioned in Part 6, a good User Story has three critical elements:

The story itself: who wants this feature, what do they want, and why do they want it? A user stories is a super-quick way to explain why you need to develop a feature. This is another scrum construct that happens to work well. It follows an easy template: “As _________, I _________, so that __________”. For example:

“As a player, I jump, so that I can traverse the environment”

“As a technical director, I have continuous integration, so that I can streamline the build process”

“As a combat designer, I can blend animations, so that I can develop a smooth combat experience”

Technical requirements: what does this feature need to do, with what systems does it need to touch or communicate, what limitations does it need to observe, etc.

This story needs to accept input X and return output Y

It mus have a memory footprint less than Z bytes

It needs use Object A and Class B**

Acceptance criteria: what does the person reviewing this feature need to see to consider it complete? In other words, if your creative director is the person who will sign off on a feature, what does he need to see in order to sign off on the work?

From the perspective of curtailing human error, user stories reduce the potential for problems by restricting possible interpretations. The actual user story establishes intent. Who wants something? What do they want? Why do they want it? The technical requirements provide parameters designed to protect the stability of the build and facilitate smooth integration. And the acceptance criteria provide clear provide the assigned developer a clear target.

Resources That Informed And Influenced This Post

<br />
<br />
<br />

If you have ad blockers turned on, you may not see the above links.

The Impact Of Poka-Yoke On Muda

As I pointed out in Part 6, yes it is time consuming to write user stories to this level of specfication. But as with all things lean, don’t just ask what it costs. Think about what it might save. Particularly, think about how much muda you could be reducing:

1) Defects – by reducing the potential for human error, you are reducing the potential for defects, both in terms of bugs and in terms of missed acceptance criteria.

2) Feature Creep – by taking the time to spell out the who/what/why of feature requests, you can think through the end user need for a feature. This level of inspection may reveal that some stories that seem attractive at first glance aren’t useful in the long run.

3) Excess work-in-progress – a disciplined approach to writing user stories will curtail long lists of spurious features. Simply put, each feature now has a cost in terms of time. And just that little bit of administrative friction can reduce the amount of impulse-driven design decisions, separating the wheat from the chaff.

4) Over-design/over-engineering – by focusing on the end user, you can think through what level of complexity is optimal