It’s 2016- new resolutions, new projects, new ideas!! Maybe this is the year to make that idea of yours into an actual thing!! GDL is running Design Thinking Workshop with yours truly on Jan 16th and 17th at Lesley University in Cambridge and if you live anywhere in the New England area, you should come! But even if you’re not in New England, here are some steps you can take to get from pipe-dream to prototype. Read on, brave builder!!
STEP 1:
Q: What do you build?
A: Whatever you CAN build.
You have an idea!! HUZZAAAAH!! It will be perfect!! Or … alternatively… it will actually exist. Sadly, those are often your options. You can have a perfect thing that will stay locked in your mind forever- or you will have an imperfect thing that will get to a prototype stage and you’ll poke at it and make improvements until someday, it actually is perfect, or perfect enough. This stage one is known as an MVP or a Minimum Viable Product.
I see many, many projects get stopped at step 1. We want to build Angry Birds. Wait, we don’t have a massive budget. Nevermind. I think that’s a mistake. Even Angry Birds’ company, Rovio, had a staggering 51 fails before their success with Angry Birds. Better an (angry) bird in the hand, right? So give it a shot- build whatever you can. And hopefully that scruffy prototype will inspire people to give you the resources you need to make it bigger, badder and closer to your original idea.
So what’s the first thing you do? Take a piece of paper and write down your design parameters. What do you want? What do you have? What can you absolutely not do?
Goals
Resources
Restrictions
These three lovely categories will help you set up your design parameters. And you’ll want that before you start building anything at all. Here’s a breakdown:
Goals
What do I want? What am I trying to get out of this project?
There are two parts of this. What do I want for myself or my organization? And then what do I want my audience to get out of it? I can’t stress enough that these are two different sets of goals- what you want your player to get out of the project and what you want your organization to get out of the project.
For instance, you and your organization may want:
- A way to incorporate mobile technology (because we want to look more modern, we want to test it out or our bosses/parents/visitors/board are asking for it)
- A way to collect responses from our students/visitors/coworkers
- More people engaging with X
- More attention paid to X content
- Something that brings attention to our wifi/exhibit/initiative
But your audience probably doesn’t care at all about these things. The key with player goals is to get nice and specific. What do you want your audience to walk away with? What message? What pieces of information? What actions do you want them to take? Bad player goals can be things like:
- Connect with 18-34 year olds
- Build something fun and engaging
- Have fun
- Create 21st century learning
This is all awesome language when you’re writing a grant proposal and yes, you probably DO want to do all of these things, but it’s not going to help you drill down to what you want your product to actually do. That needs to be granular and repeatable so you can use it to eliminate design options. For instance:
- We want a project a teacher and class can engage with (this holds a whole truckload or restrictions: connection to common core, ability to handle up to 50 kids at a time, can’t assume the kids have devices etc…)
- After playing this game, we want people to know that Asia is not a country, it is a continent with unique countries and cultures. (Clear learning goal- YAY!)
- After 60 minutes, we want freshmen to understand these 5 aspects of the University Library
- We want parents to talk to their kids in the museum for 30 minutes or longer
- We want people to be able to remember the name of at least one historical figure here and tell us something about them- we want a personal connection.
These are the types of goals you can really build for. Now moving on to restrictions.
Restrictions
What can you not do? This is really important. First, you want to get it out of the way right up front. There’s nothing worse than spending hours and hours building a game that won’t work because of X. Think of all the potential restrictions- even the ones that might never come up. Some restrictions might be:
- You have sensitive content, people will be upset if you include humor or fiction
- Your space is dark, has no wifi or connectivity so location-based projects will be difficult
- You can’t assume that people will have mobile devices or computers to play with
- You’re working with families who have younger children so you can’t have small, breakable parts or give directions that are very verbal or reading-centric
- You’re dealing with older people who won’t want to walk for hours- or maybe even use technology at all
- You have time restrictions: your project has to be done in 2 months or people can only engage with it for 10 minutes or less.
- Budget. Always budget.
Restrictions may sound like a bore but in fact they. are. GREAT! By listing your restrictions you can eliminate a whole slew of options. For instance, some of my own projects:
Murder at the Met: We had only a few months to produce this- that meant it had to be built off of an existing platform, we couldn’t build from scratch, which limits what the storyline can do.
SquirreLee University: They didn’t have connectivity so we couldn’t build any live-response project, everything had to be offline. This made us create a digital/analog hybrid by using their existing off-line app to deliver directions and a notebook to collect observations.
League of Extraordinary Bloggers: We had content from 5 participating museums, which meant it couldn’t be a 2D (what I like to call a “sprite”) game that just consisted of animated images. We needed to make it text or audio based to include the content.
Resources
This is the best part- the part that will really truly make or break your project and decide everything else you do. The best thing you can possibly do is use what you have. Do you have a person who loves to write stories? Use them. Have an intern who loves to draw? Use them. Know how to build on Unity? This will magically be a unity prototype. You can even find resources in places that you never expected. Some of the resources I’ve been able to use for projects have been:
- Squirrels
- A donation of old smartphones
- Walkie Talkies
- A pin-making machine
- The popularity of buzzfeed personality tests
- A strong network of family museum members
- Interns who write/draw/love social media
- Friends who know how to do video
Luckily, you’re building something that’s intended to be interactive and fun, so you’ve probably got a lot of people who will be excited about it. Abuse them all! It’s more fun when more people participate and your project will be better for the use of resources.
Resources can also come in the form of existing platforms that can build what you need. The Edventure Builder has been used for things that I never expected: to take polls, to teach classes. It’s a technical resource and good designers make do with what they have. Just remember that incredible moment from Apollo 13: “We need to make this… fit into this… with nothing but this….” This is one of my all time favorite movie scenes because it makes me remember that you can build anything with anything!
So these three guidelines will get you started. I’ll follow up soon with part 2: throwing everything at the wall and finding models for what you want and don’t want. And I know I’m often slow with part 2 of a series but this one i’ll get out by the end of the week.
Remember
- Build the thing! Don’t just think about it!
- You can pretty much build anything with anything… and
- Come to my Design Thinking workshop next week if you really want to get your hands dirty!
Leave a Reply