(This is a repost from http://www.hilmyworks.com/how-design-students-are-taught-to-prototype-on-their-own/)
I am a lecturer teaching Game Design in KDU UC Malaysia, and about four years ago I undertook the task to train game design students. While the School provided various forms of training for the design students - student projects with artists and programmers, classes on various aspects such as World Creation, Level Design and Systems Analysis - there was an issue regarding training designers I had to address.
The Problem Statement
There are three problems I found with training design students:
Group projects could fail in ways that a designer couldn't control. The designer could do good work and the game could still fail due to ineffective management, lack of resources or team conflict. The opposite could also be true: a good game may not be the result of a good designer, but intervention from the other members. The success of a team game project is not a reliable way to measure the ability of the designer.
Regardless of what a University student studies, a Degree graduate is supposed to graduate alone. It simply will not do to have a design graduate that says 'I'll need a programmer and an artist to prove my design will work'. As a former IGDA Chapter Coordinator, I have met designers who cite that exact statement as a reason for why they couldn't find work. That's not an acceptable situation for a game design graduate.
I have noticed that our local game dev students I've had generally are inexperienced presenters. Richard Carrillo in his GDC2015 talk on designing design teams clarified what I realized over time: only a subset of game designers - termed by Carillo as Salespersons - can sell ideas to others. The rest will struggle. Designers are required to be articulate - they have to explain their work to their fellow developers - thus design students have to learn to communicate on a higher level than their fellow classmates. Obviously, they'll have to learn to communicate on that level, but it is possible to have students who have a good design in mind but could not communicate it properly, thus being unable to prove their design works.
In summary, I will have students who have to graduate alone, show expertise in creating work that can only be proven by others working on it, and may be unable to communicate what he and she can do.
I noted this issue since 2012, and thus went looking for solutions.
Two Possible Solutions
There were two implementation paths that seemed potentially useful: 1) Prototyping + Analyzing Feedback and 2) A More Efficient GDD Process.
1) Prototyping and analyzing feedback. The simplest approach is the "design-test-iterate" mantra mentioned by Kim Swift of Portal's fame. Ideally, design ideas need to be tested and improved based on test analysis. The keyword here is validation: confirming what was conceived actually works. So the question is: what is the most effective way for a designer to validate his or her design?
One developer I posed my problem to back in 2013 was Chris Natsuume of Boomzap. His answer was simple: any designer who'd want to design a game would have tried to make it. It doesn't matter whether it's done on a simple game engine or a paper prototype; they should have taken the step to see whether or not the design works. This fits his company's approach (see "Quick and Dirty Prototyping: A Success Story" by Paraluman Cruz) and he has cited on Reddit that his approach to ideas is to prototype them.
One useful example from this was Blizzard's development process in creating Hearthstone ("Pen, Paper and Envelopes: The Making of Hearthstone" by Mark Serrels). There was a clear example of designers working alone as they had no artists and programmers available for a time, and they generated a working, playable prototype on their own.
But the newest members of Team 5 weren't prepared for what came next; no idea how far Eric and Ben had taken it. It subverted almost every idea Team 5 had about the traditional process of game design.
Eric pointed to a computer in the corner of the room, running a flash version of Hearthstone. In everyone's absence Eric and Ben Brode had been busy. They had essentially prototyped and then built everything Hearthstone was going to be in Flash.
In short: the game was already finished.
"We pretty much pointed at the computer and said — 'the game is done'," laughs Eric. "Just remake that game over there."
It was the end result of that rapid, brutally efficient iteration process.
This was a strong indicator to me that a good ability for a designer to have is to be able to implement their own designs to demonstrate to others. Handily, it also solved the communication problem: the best way to convince others your game design works is to show it working.
Another key element I was advised to implement was feedback analysis. Again, while asking around in 2013 in Casual Connect Asia - a game dev conference held in Singapore - I was given advice that another good ability companies seek in designers is the ability to adapt a design to feedback. That means collecting feedback, analyzing what the feedback meant, devising a design solution and implementing it in the game.
