Validation and Iteration in Games - Martyn Jones


Published on

Martyn Jones a product manager and game designer from Mind Candy discusses using validation and iteration in games design

1 Comment
1 Like
  • Download Here Free Setup 2014
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Validation and Iteration in Games - Martyn Jones

  1. 1. Introduction I have been making games and eLearning products for kids for 13 years. Been at Mind Candy for 4 years as Game Design & Product Manager. Going to run through the Discovery Process of Game Design as I see at Mind Candy and how I think it relates to Product Management. Personally I have the found the tenants of Product Management (making relevant; valuable; feasible stuff ) to be very useful when approaching Game Design.
  2. 2. Agenda - Mind Candy from Hunches to Heuristics - Company & Product Discovery - Finding Fun is an Adventure - Seek Mastery: Types of User & Fun - Lightweight Toolbox - Discovery Part I: Ideation - Discovery Part II: Validation - Iterate - Summary
  3. 3. Mind Candy from Hunches to Heuristics Mind Candy has achieved success in multiple industries with a relatively small team - No. 1 Kids Print Mag - No. 1 Toy Brand in UK - No.1 Kids web game in UK and strong in ROW Agile & Product Management allows us to be very effective with small teams. Very fortunate now to have a good Product Management function (including 1 week Marty Cagan master class which helped to educate the whole company)
  4. 4. Mind Candy from Hunches to Heuristics Didn't always used to be like this: Started with a skilled core team who ran on gut instinct and hunches. Made awkward design decisions and couldn't always maintain integrity of design across our whole product (as I'm sure any Agile Game Designer has unfortunately experienced) However, we executed a lot faster than our competition and got to the fabled tipping point. When we had a winner on our hands, we started to double down on the science of success as we obviously wanted to repeat this frequently as possible.
  5. 5. Company & Product Discovery As we grew, two things happened simultaneously: Company-wide Discovery & Product/ Feature Discovery Company Discovery: Business wanted to know where we would be in 3, 6, 12 months from now. We introduced OKRs to chart our direction and to align all departments. The 3 month heartbeat of OKRs work well for a modern fast moving company.
  6. 6. Company & Product Discovery OKRs also imposed some necessary deadlines for features and whole products. Whilst it's tempting to say that the product will ready when its ready, it is necessary to impose some constraints on resource and time. It was time for the product teams to work out how to reliably deliver value within certain timeframes
  7. 7. Company & Product Discovery Product teams reacted by improving our Discovery process. (i.e. Finding something valuable to do and validating it before you start formal implementation) The diamond represent the standard ‘Double Diamond’ of the design and discovery process. The yellow diamond represents that you have to do enough Discovery and start out informed before you can entertain the idea of deadlines.
  8. 8. Discovery for Games Discovery for games is all about finding fun. Finding Fun is NOT a journey that can be easily planned upfront. Especially for games. Especially for kid's games. Its an inexact science. Party unknowable because you discover Fun as you create. Can we always Find Fun? ANS: Yes, if we look hard enough. BUT, time is of the essence!
  9. 9. Mastery You Shall Seek Understanding and respecting your environment gives you a head start and saves time (doesn’t have to cost lots of money). Understand and study other games: - Nintendo games are a good place to start - Loads of great physical & board games out there too Understand your user: - Kids on Chris Evans Breakfast Show; Diary of a Wimpy Kid - Read psychology papers, books and blogs - Run focus groups & surveys
  10. 10. Mastery You Shall Seek Example of what can go on inside a kid’s head. Letter from boy to a weatherman who visited his school. The more glimpses we collect of our users, the better we can understand and serve them.
  11. 11. Master Types of User Knowing your user will help you meet their needs and expectations which saves you time. So much variation with gender and age. There are as many different play styles as there are different models to describe personas. Find models that work for you Previous slide is based on research by Lizzie Jackson and David Gauntlett:
  12. 12. Master Types of Fun Knowing about different types of fun will help you engage kids on different levels in the short, medium and long-term. Nicole Lazzaro's 4 types of Fun: - Hard Fun: Goals, Obstacles, Strategies - People Fun: Communicate, Cooperate, Compete - Easy Fun: Exploration; Fantasy; Creativity - Serious Fun: Repetition, Rhythm; Collection Easy Fun is really important for kids. Especially silly, whimsy, slapstick - crude humour Find models that work for you
  13. 13. Toolbox Set yourself up to move quickly. Must move quickly because the more ideas we play with, the more fun we will find. Quick: Paper & pencil; post-its and sharpies - Paper app Precise: Omnigraffle, Google Docs Low-Fidelity: Flash; Construct; Stencyl, HTML + jquery Clearly communicate that you're prototyping; use rough visuals while prototyping behaviour - otherwise you will become frustrated when people start trying to ship your un-validated work!
  14. 14. Discovery Part I: Ideation Discovery is a 2 step process. First start with Ideation . (This is where we open up the Discovery Diamond) Collect & welcome ideas from everywhere. Don't kill ideas too early; don’t edit yourself. Be concerned if you don't end up with several alternative ideas. Use your Toolbox to Prototype and test quickly by any means.
  15. 15. Discovery Part I: Ideation This was an example of using lightweight tools to prototype and explore ideas quickly. I wanted a persistent cumulative highscore, but didn't have time to program it, so we just recorded kid's score on the wall using post-it notes. When they hit milestones we gave them some Moshi Cards.
  16. 16. Discovery Part II: Validation The second step in Discovery is Validation. (This is where we begin filtering ideas and close the Discovery Diamond) Check if you've found the fun. Use Mastery, Prototyping and Tests to reduce options. Know when something's wrong - sometimes we become too attached, but Validation should show us what’s simply not working. We are NOT children. You won't really know if you're Found some Fun until you put it in front of kids.
  17. 17. Discovery Part II: Validation This picture is obviously wrong! Sometimes we invest in products too emotionally and we can’t see that what we’re building is wrong.
  18. 18. Moshi Example I wanted to add a puzzle game to Moshi and started to research and play all the puzzle games we could. We soon found and fell in love with Puzzli and started prototyping something similar. We then fell in love with the prototype. In truth, we prototyped too long without validating with users. We had to go through a couple of rounds of play testing and major tweaks before we held our hands up and said it wasn’t working. However, we learnt a lot about NodeJS (and have adopted it) and learnt a lot about of users and went on to build something more relevant and valuable.
  19. 19. Iterate Iterate on Ideation and Validation. (This is essentially the Double Diamond approach to design) We don't do big design upfront (we might spend too much effort going in the wrong direction). We do quick slices because it helps us validate if we've found the fun more quickly. After you have proved your core idea, do some more discovery. (but know when something's wrong)
  20. 20. "Startups that don't have a product/ market fit don't need growth hackers." Andrew Chen, Sep 2012
  21. 21. "Games that haven't found fun, don't need optimisation." Martyn Jones, just now
  22. 22. Summary When trying to Find the Fun for a kid's game, it is extremely risky to execute a single idea. To mitigate risk, start out informed, spread your bets, then build and validate your ideas as frequently as possible. Decent games need a decent discovery process - and I think a chunk of that needs to be done before anyone commits to any deadlines. If Product Management is about knowing the user and the market and discovering the most relevant, valuable and feasible thing to do, then a Product Manager's best friend is the Product Designer. For games, that's the Game Designer.