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.
Welcome to the world of poka-yoke (poh-kah yo-kay).
Previously on “Game Planning With Science!”: Part 1 Part 2 Part 3 Part 4 Part 5 Part 6 Part 7 Part 8 Part 9
By Reading This Post, You Will Learn
- What poka-yoke is
- How contributes to lean’s central goal of eliminating waste
- How you can apply it to game development
- The benefits of poka-yoke in terms of the seven forms of muda from Part 9
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?
Resources That Informed And Influenced This Post
If you have ad blockers turned on, you may not see the above links. Breaking The Wheel is part of Amazon’s Affiliate Program. If you purchase products using the above links, the blog will get a portion of the sale (at no cost to you).
The Impact Of Poka-Yoke On Muda
Further Reading If You Enjoyed This Post
- Poka-yoke (literally, “mistake-proofing”) is the practice of designing products and components so as to eliminate the potential for human error from the end-user
- User stories are a form of poke-yoke: they attempt to constrain interpretation in order to ensure that the outcome of development suits the needs and requirements of the project
- An effective user story has three elements: the story itself, technical requirements, and acceptance criteria
- Poka-yoke targets four forms of muda: defects, over-production, excess work in progress, and over-design/over-engineering
If You Enjoyed This Post, Please Share It!
*Originally it was “baka-yoke”, or “idiot-proofing”. But Toyota decided to tone that down a bit, I suppose.
**Okay, this is hand wavvy I admit. Sue me. I’m a producer, not a coder.
“Lean Development for Games – Game Planning With Science! Part 9” by Justin Fischer is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.