The Hackathon Mentality
(or how collaboration and prototyping can improve the interactive storytelling ecosystem)
At Racontr - a code-free interactive storytelling software used by many interactive content producers and media outlets - and Storycode Paris - a series of monthly transmedia conferences and workshops - we constantly find ourselves involved with other people’s projects, helping them conceive, build and publish their interactive experiences. Project after project, we’ve been trying to refine an agile interactive production process that I wish to share with you.
Interactive and transmedia storytelling is and has to remain a great experimentation field. One quote by Pierre Cattan sums up what, to me, should be the ambition of any interactive and transmedia producer:
Transmedia storytelling is the name we gave to R&D in the field of content creation.
Devices are not done evolving, media are not done colliding, authors are not done transforming the way they build stories and audiences are not done embracing this “lean forward” position they are offered evermore frequently.
That being said, experimentation should not be an excuse to waste resources. Experimentation does not mean that no method or rationalization processes can be devised and applied. Rationalizing resources and workflows allows for leaner, quicker and more innovative production process, while building on continuous learning to improve quality, innovation and efficiency over time.
Rationalization does not imply that any content has to be identical to the other. It means though that any organization - from a couple of freelancers collaborating to the biggest media or production company - can find ways and tools to preserve its most valuable resources and skills for tasks providing the highest added value.
Interactivity is an investment
Few can say that their interactive storytelling works are a tremendous revenue source that can sustain their whole organization. For most, interactive pieces remain a vision, an investment towards a more user-centric future for online content. Basically, we’re doing R&D. Much as any company in any industry invests time and resources towards innovation that could create a new economic system, a new market, and new opportunities in the future.
The question then is: how do you optimize these investments and how do you get the best return on them? Surely the answer has to be different depending on the organization considered. However media, independent creators, producers have in common certain practices that generate a waste of resources, such as:
- the constant rewriting of a project’s specifications over weeks/months of imprecise conceptualization
- the lack of technical anticipation
- the absence of an interactive project manager
- the sometimes endless contemplation of an ideal but unrealistic, unfeasible or unfundable experience
- the absence of a prototype providing user feedback in the development phase
- the instability of the creative team
All those issues can be linked to three organizational defaults:
- the absence of an extensive and systematic conception and/or prototyping process
- the difficult or lack of collaboration between people with complementary skills
- the absence of an iterative process for continuous learning and innovation
What we do, developing an interactive storytelling software such as Racontr, or hosting regular hackathons, is to provide all storytellers with the methods and tools to create interactive content differently, more rationally and more efficiently.
Ideas are meant to be hacked
Interactive production is perceived by many as an experiment but too few really adopt an experimental stance. More often than not, producers settle on applying a process derived from television or cinema production. For us creative technologists, it often means that people come to us when funding has been secured, with unclear specifications, to ask us to “do it. And if you have some good ideas on how to improve the whole thing, feel free… .” This only has the allure of collaboration but it is simply a more dilettante form of subcontracting.
True collaboration should start way upstream the production process. It is definitely more demanding and disruptive of the way things have been done for decades but this new mindset will greatly reduce the risk of unforeseen problems during the production process.
Basically, I find that the best time to do this “story hacking” is pretty soon after the concept emerged, before the author or producer develops it to much in a single direction and gets too emotionally attached to it. The point is, the more you work on your own, on your very first idea, the more difficult it will be to welcome new ideas or even a complete creative destruction process.
Because if you build a team, they will be eager to provide new ideas, to strengthen your project with their unique and valuable point of view and skill set. If you are not open to that collaboration, you don’t need a team—you need a workforce.
We’ve experimented a lot on how, when, where is it best to set up those story hackathons. Each time we rearranged our method, trying to refine it into a series of guidelines we feel confident in sharing as good practices that can serve all of you interactive storytellers, wherever you are and whatever your project.
Here are a few of those:
Do not wait. As I said, timing is key. A mere concept will soon become someone's “baby” you won’t be able to change without a great expense of time, negotiation and emotions. Assemble a team quickly to workshop all the possible developments of that original idea before you get stuck in a one-way street.
Find the right team. This is one of the greatest challenges of interactive production so ideally you should not look for collaborators when they are urgently needed to produce something you want. This collaborative effort must be engaged as early as possible to build personal bonds, a common language and trust between each member of a creative ecosystem.
Adapt your mindset. Members of the team might have to adapt their habits to work in that somewhat disruptive way. Authors have to make peace with losing some creative control for the good of their story. Technologists and designers should see themselves and also be considered as authors. Producers could benefit from taking a step back from the creative process and focus on producing: protecting the creative team, giving it the necessary tools and resources, fostering a creative work environment, finding funding for the project.
Ask all the right questions. Now that you have an idea and a team, go into full hackathon mode and challenge everything. You thought it should be an interactive documentary, well now imagine all the forms it could take on other platforms. You figured your audience would be everyone on the Internet, take a step back and do some audience design, find existing communities you can reach or partner. Etc.
During our Storycode Paris two-days workshops we usually do 3 brainstorming sessions where each project is asked a series of questions about format, audience, user experience, business model, partnerships, etc. At the beginning, the point is to come up with as many ideas possible, pin them on the wall and then vote collectively to determine the most important ones. Others brainstorming sessions are meant to narrow down those multiple possibilities to find the essence of the project: what content and interactions are absolutely necessary for the story and the user experiencing it.
Preserve that hackathon mentality. We feel that this process can be adapted to any organization and should not be limited to a weekend experience during special events. We put a lot of effort into making our method as agile and easily adaptable in-house, with your team or your regular collaborators. After all, aside from the post-it and caffeine-based two-days method, it is mainly a mindset, a reflex you can adopt to generate more innovative ideas and foster a most efficient team dynamic.
Agility is key
Now that you’ve had all those brilliant ideas, and you’ve made the conscious effort to determine what is the core of your experience, you can go forward and make stuff. Too often, interactive projects try to seek funding and partnerships with a video trailer and carefully chosen words. This is important for sure, but how much energy is wasted explaining with words, pitches, meetings what makes the strength of the project: the user experience.
Too many projects go straight from a concept on paper to actual production of the final product. Which means that funders and partners will never actually see anything live until it’s way too late to change anything without costs.
It also means no user feedback was collected and acted upon during production development. I’ve never heard of a software company releasing a product without user testing and multiple alpha and beta versions. Why would interactive experiences be any different?
This is why I think agile software development methods such as SCRUM or Lean Startup can inspire us. Hugely popular among tech companies, they provide some very interesting insight for interactive producers, especially on the value of prototyping and iteration.
Prototyping might appear financially challenging for producers evolving in a field where funding is scarce. But start with low-tech prototypes and slowly build towards more functional ones. You might want to use Twine or Scrivener as interactive writing tools, you won’t spend much. Or paper if you want. During this phase, I feel that three experiences must be designed: the Prototype; the Minimum Viable Experience; the Most Valuable Experience.
The Most Valuable Experience is your ideal project if all goes well. The issue here is to be ambitious but keeping the perimeter of the project credible and feasible.
The Minimum Viable Experience is your ideal project reduced to its acceptable minimum to tell your story and give users a satisfying experience in spite of the lack of resources that forced you to go to plan B. Imagining this minimal experience enables you to identify what is the core of your project, and also where you draw the line under which doing it becomes unacceptable.
And finally, design the Prototype you will use to test your concept, gather user feedback and make the necessary changes to your project during the development phase. Sure this will cost more resources that just writing a detailed file with some mockups. But what is the real cost for a producer or a author of month of imprecise conception, of unanticipated technical issues, of not being able to convince backers and partners because they can’t really “touch and feel” the experience you’re trying to sell them…?
Many tools enable you to build these prototypes for a more than reasonable cost. Obviously, you guessed it, I will recommend you use Racontr, like the participants of the Tribeca Hacks
Failure is cool
If interactive storytelling is R&D, it implies that sometimes you will fail. Whether you fail to push a project further than a concept on paper, fail to make a satisfying prototype to validate your idea, fail to get enough funding for your ideal project, fail to reach your target audience, you can still find a way to make it a worthy investment, provided that you’ve set up a continuous learning process.
Innovation can only be an iterative process. You won’t learn every lesson from one project, whether it succeeded or failed. But if you make a point of documenting a feedback on your creative experience, on your production process, on the tools you used, you will be building a knowledge base on which you can rely for your next project. And if everyone in your organization does the same, or if you share it with a global community such as Storycode, you can make sure that failure becomes a pretty cool thing where everyone contributes to reduce the risk of reproducing the same mistakes.
During every Storycode Paris events we host, we invite majors interactive producers and creatives to come and share the mistakes and failures and the way they overcome all of them to achieve their goal, how they impacted the project, for better or worse.
If we keep sharing resources and practical lessons as a community, we can identify more and more of these best practices and refine this collaborative production process that I feel is absolutely necessary to make our interactive storytelling experimentation field into a full-fledged industry where we can all thrive telling the stories we love.
Innovation & Collaboration
The two key elements to Hackathon success are innovation and collaboration. Projects need to be novel, but they also need to draw on the talents, experience, and unique perspectives of every member of the hackathon team. This is especially true since the teams are interdisciplinary. And while it may be tempting to have the technologist worry about implementation while the storyteller worries about narrative, it’s in fact imperative to do the opposite. Each player needs to step outside her or his comfort zone and provide feedback on the challenges that other teammates are facing in the other disciplines. These outside views within the hackathon group not only test the projects as they develop, but also bring fresh, unexpected, and sometimes revolutionary input to every aspect of the hackathon creation.
Every team member should also be treated as an equal contributor. The designer doesn’t work for the storyteller, even if her or his designs need to serve the story to be successful. Every member should be thought of as“working with”every other member of the team. This makes everyone feel invested, improves the outcome, and will provide that extra bit of motivation when no one has slept for days and the deadline is looming near.
This is the kind of collaborative approach we apply at CERN, from small computing projects to building the world’s largest particle detectors, which rival the Eiffel Tower. Most teams have just a coordinator and no “boss”. In fact, it’s often impossible to fire people or change team members, so everyone works within their ability, asks for help when they need it, and tries to offer help when it’s apparent someone else is having trouble. That’s not to say that everything is rosy all of the time. There are plenty of conflicts in any collaboration, but at CERN they are resolved through roundtable discussion and compromise. One team member’s weakness can be seen as another team member’s opportunity to step up and fill the gap. In this way, the teams organically, gradually, and peacefully morph until they take on their most efficient form, with team members in their most suited positions.
This process is identical to that which creates a great hackathon team. In fact, innovation of any sort benefits from this collaborative structure. By its definition, innovation is pattern-breaking, spontaneous, and unpredictable. Only a flexible, tolerant, and multi-functional team can be truly innovative. And because innovation can come from anywhere, just like inspiration, working towards it can seem wasteful or inefficient until that breakthrough moment. But if we think of that inefficient work that comes early on as investing towards that future, eureka moment, then we see that we just have to be a little patient, believe that the hard work will pay off, and pull together. If the team believes in its goal, and is open to whatever developments may come, the end result will be better realized and more truly groundbreaking than anyone at the outset could have imagined.
Happy collaborative hacking!