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 (ポカヨケ)
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
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
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
Further Reading If You Enjoyed This Post
User Storeis Make For Better Consensus
What’s Next?
Okay, you have your stories in hand. The next step is to hand them off to developers to execute. It’s time to delve into the wondeful world of kanban, and to understand why excess work-in-progress items are more detrimental than they may seem.
Key Takeaways
- 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.
Return to the “Game Planning With Science” Table of Contents
“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.
Related posts:
Character Art Pipeline Capacity Charts – Game Planning With Science! Part 2
Guest Posting Like A Mofo: Volume I
Discovery Versus Process – A Preface to Game Planning With Science!
Jidoka: Putting The Robots To Work – Game Planning With Science! Part 12
The Muda of Defects, Or: Finding Freedom Through Discipline – Game Planning With Science! Part 13
Root Cause Analysis: The Five Whys – Game Planning With Science! Part 15
Leave a Reply