Welcome to this mini-series on ideation within a MILE setting!
The well-known saying goes that ideas are cheap, execution is everything—an alternative reading here is that it is better to spend more time trying to work at the idea-generation stages than it is to spend time in the far more expensive building stage.
Specifically, in this context, we want to look at ideation in the context of an unknown, developing or blue ocean style field, such as MILEs.
We should note that this concerns situations with long development times, as is typical in gaming, MILEs and shows. A game jam or live vlog would be examples of where it is correct to focus more on trial and building rapidly rather than spending too much time on ideation (with a grain of salt, here’s an entertaining point on this – Build a Tower, Build a Team).
When working in a field with experience, ideation is going to look different – if I build a first-person shooter and have people on the team with decades experience in building first-person shooters, chances are that good solutions are going to appear very rapidly from a number of people.
MILEs though, are new. You cannot rely on people to know best practices and have ready-made solutions because the field is not known – there are, truthfully, no real experts.
But developers are very good at identifying opportunities and motivations.
Which one is easier to address?
- Find a mechanic to engage people in a live interactive streaming event.
- Why does someone want to take part in a live interactive streaming event?
Most people seek to answer by going with the first approach, which may or may not be suitable as diving directly into adding interactivity risks shifting the focus away from viewer motivations, and more on to the intricacies of interactive content implementation. The second approach is about user motivations and as a consequence, it creates better building blocks in order to solve as well – we can split the motivations and try to develop towards solutions that are within these motivations.
To place Ideation, a rough example timeline of product development might look like this (it’s well worth noting that this is a simplified portrayal and that many of these steps can go back and forth, such as testing the product being present in multiple intervals and not just post-production).
Typically, ideation is placed before this timeline, completed and not looked again. While this is a possible path, it masks that ideation is a process separate from the timeline that may need to be called at various stages in parallel.
|Production Step||Ideation Process Parallel|
|Not started||What to build first prototypes of?|
|Prototyping||Discovering additional prototype options based on feedback and new information from this stage.|
|Validation||Check back to ensure it solves the core premise set in ideation OR last improvements.|
|Scoping||Sometimes used to find alternatives that might make production cheaper / easier.|
|Production||Might be for additional development components.|
|Testing||Check that the core premise is addressed with internal user-testing.|
|Release||Check that the core premise is addressed with external users.|
|Support||Use new data to place new key phrases / sub-problems OR start a process in a new space.|
The above table implies that you should re-check the ideation process at multiple steps along the way. While true, it’s not feasible realistically – it’s often best to remember that the process can be called upon as needed, referenced and used once again as a supporting tool that isn’t just limited to before the prototype.
MILEs and interactive streaming are squarely in the camp of “blue ocean” ideation. As a result, it becomes critical to think more in terms of essential participant motivations and having an open mind on what users will react to. The next article will dive into how ideation can work with MILEs. We highly recommend reading these resources before then if you have not:
- Spectrum of Interactivity & Levels of Commitment
- Bottom-Up / Top-Down Approach Mini-Series
Notably missing from the above is the testing process. We will mention it a few times in this article series but won’t address how to do said testing. Our aim is to provide a framework in the future as we keep exploring.
Feel free to chat to us on our Discord Server. Until next time, happy reading!