Bringing playable production in-house can result in greater control, speed, and affordability - so finding ways to improve efficiency and enjoy all of these advantages should be a priority. Unlike video or static creative production, the workflow for designing playable ads includes handing off responsibility to a developer and incorporating them into the feedback loop. With this in mind, it’s important to know the best practices for communicating with your playable developers to make production more efficient, accurate, and easy.
Here, Ori Ben-Moshe, Creative Manager at Luna, sheds some light on what you should be sharing with developers before starting to build your playable ads. Even if you’re running a lean team (or just a team of one), this detailed walk-through can help keep you organized and take your playable concept to the next level.
1. Create a storyboard
Once you’ve got your playable concept, design a storyboard of the creative that explains the idea on a high level. This will help you visualize the flow of the playable and address questions before they arise.
Looking at the example above, users can upgrade their character to run faster by pressing the button on-screen before taking them to an actual race against others. Including a specific explanation and visual mockup of this upgrade in the storyboard clarifies this feature for developers - they can then build an accurate version from the start.
2. Write a game design document
Game design documents (GDD) are the foundation of the entire design and development process - they describe playable production and expectations at each step in a clear and concise way. Whether you’re part of a large or small studio - or even a one-person show - at least one part of a GDD can work for you. Having to explain your playable often leads to useful questions, can help improve the production process for current and future creatives, and lead to a better-performing final product.
Now let’s talk through each part of the GDD so you know what’s important to highlight at each stage.
Highlight the hook of the tutorial
The tutorial of a playable is the crucial moment where you can catch the attention of users and encourage them to engage. From this introduction, they need to know how to play and why - what’s the hook that compels them to interact?
From the tutorial of your playable, users need to know how to play and why - this is your chance to catch their attention and encourage them to engage.
The GDD is your chance to explain clearly and simply what should be included in the tutorial and how to show the hook. For example, playables for hyper-casual games often use a “ghost” of the action in the tutorial that shows users what’ll happen when they start interacting. Explain this in your GDD by showing a quick mockup or example of a ghost in a tutorial and describing the action and instructions to appear on-screen.
Looking at the example of the playable below from Join Numbers, we can say how you shouldn’t and should describe the tutorial in your GDD:
Don’t: Only say “show the numbers 0 and 5 on the screen”
Do: Describe the tutorial screen as “show the number 0 in yellow in the center of the track and a gray ghost number further up the screen. Have a gray ghost of the number 0 slide up to meet the number 5 so it creates the number 50 and highlights it in yellow”. Alternatively some teams that have an animator prefer to enlist them to create a video that shows - instead of tells - developers how they want their playable to look.
Be specific in describing the visuals and mechanics of gameplay
Providing exact descriptions of each part of gameplay can help both one-person teams and studios with dedicated developers build a playable more quickly and accurately. We suggest covering the following details in this part of your GDD:
- Number of interactions
- Distances
- Speed and timing
Decide on in-ad events and A/B testing setup
While describing gameplay in the GDD, also mention the in-ad events you want to track, like clicking on the end card or completing the tutorial. In-ad events are snippets of code developers can set up that give you unique insights into the user journey and how they interact with your playable so you can make data-driven optimizations. They’re a crucial tool for improving your entire UA strategy, so consider which are likely to provide the most valuable insights then inform your developers.
In-ad events are a crucial tool for improving your entire UA strategy, so consider which are likely to provide the most valuable insights then inform your developers
You don’t need to have every single detail figured out as you work on the GDD, but make note of what you haven’t thought through or want input on during the kickoff meeting. The Luna team built this template for you to use as a starting point - adapt it for your needs by using only some of the slides or opting for a more visual approach.
Also use this section to describe the A/B tests you want to run for each part of your playable’s gameplay, like trying a new object for a match-3 game or increasing the speed of play in a runner game.
Confirm how users win or lose your playable
Describing the different scenarios you want to try in your playable ahead of production encourages you to think about user motivations and streamlines the process of building the playable. Each game genre attracts different audiences that tend to prefer either easier or more challenging gameplay. Gathering information by testing different versions, following user behavior in your game, and previous marketing efforts can tell you the type of gameplay your users prefer - then you can apply this to your playable.
Maybe you run test campaigns and discover that CTR is higher when users win your playable - so you make gameplay easier to encourage more win scenarios. As is the case with the other parts of the GDD, the more specifically and clearly you can describe the criteria for win/lose scenarios, the better for your developers:
Don’t: Be vague and say “users need to reach the finish line first”
Do: Describe the scenario as “to win 1st place, users must reach the finish line while getting past all obstacles, like swimming and climbing, before all other players”
3. Put your playable into production
After you’ve completed the GDD, it’s time to put it to the test and start building the actual playable. To improve speed and efficiency at this stage, there are three actions we recommend taking:
- Schedule a kickoff with the developer
- Get a version from the developer halfway through production
- Improve operations with best practices, tools, and resources
Get aligned on a kickoff meeting
Scheduling a kickoff with team leaders like the UA manager, creative manager, and lead developer ensures your entire organization is aligned on expectations for the project and is the best opportunity to confirm milestones together. Even if you’re a lean operation, this is the chance to take a step back and consider the timeline and project as a whole.
Scheduling a kickoff ensures your entire organization is aligned on expectations for the project and is your chance to take a step back and consider the timeline as a whole.
In the meeting, review the GDD and discuss any details that you didn’t include - maybe you weren’t sure of the animation to show in the tutorial or you were choosing between a few A/B tests and wanted to get the feedback from other team members. Other people in the kickoff could offer new ideas and suggestions that fill in the blanks or improve upon your concept. As you make decisions, update the GDD - this is a working document that you can (and should) adapt as production moves forward.
Check in halfway
We suggest requesting a version of the playable in the middle of production - what’s known as a mid-version - to review the progress and provide feedback before the final result. This helps improve accuracy and ensure production is on the right track and can be handled as easily as in a short meeting with a shared screen. At this stage you’re able to make any tweaks that could improve the final product and correct mistakes before they get bigger.
For teams of all sizes, once you have a working version of your playable, hand it off to a test group of users to play through it and collect their feedback. We’ve found that getting an objective perspective can reveal parts of your playable that should be improved - then addressing these earlier on in the production process saves time and resources later.
Optimize the workflow
Reviewing your operations and introducing new tools and practices can help optimize the production process so it’s more efficient:
- Open a dedicated channel: We’ve seen that using a tool to communicate with the stakeholders involved in the playable saves time instead of coordinating calls or sending endless email threads
- Stay on track with deadlines: When we ask for deadline estimates for each milestone, we’re able to keep production on track and hold each other accountable
- Keep updating the GDD: As you make changes like altering the game flow and changing due dates, update the GDD
Creating a process for playable production
A game design document (GDD) is like a product requirement document (PRD) for product managers - you’d never design a successful product without one. Similarly, a GDD goes into the details and explanations needed to end up with a high-performing playable. Developing playables using a GDD and the tips above lets you build a knowledge base of best practices that turns production into a standardized and efficient process - this is key for building more creatives faster and improving performance. Standardizing playable production is a win-win - you get high-impact playables and your developers get clear instructions and understand expectations.
Developing playables using a GDD and the tips above lets you build a knowledge base of best practices that turns production into a standardized and efficient process.
The goal is making playables more accurately, efficiently, and easily. The best way to do this is aligning expectations at every step with all those involved in whatever way works best for you.
