SteelHouse University

A game-based learning app

Expand SteelHouse's influence by setting the bar for educating the audience their software was built for.

I was brought on to the SteelHouse team to lead the charge in education for the marketing industry. Through my research and prototyping, I was convinced that a game-based learning (GBL) application would get the job done.

Pre-Production

When the big bosses at SteelHouse came to me with the idea for an education app for marketers, I was instantly sold. I'd always wanted to create an educational tool, and this was the chance to make a difference in a fragmented market where every professional had a different view on what best practices were for the industry.

The idea was simple: make SteelHouse the go-to resource for learning best practices in the marketing industry. That was a tall order, so where could we start?

Discovery

We had the "why" and the "who". But to find out what to build, we had to get to know the audience more intimately and uncover what they actually needed. Alongside the in-house Head of Learning, Jodie Beals, I dove headfirst into learning about marketers.

We polled our own internal marketing team at multiple career levels, studied industry news and popular blogs, and interacted with various marketing forums. We also gathered everything we could find on the current educational resources for marketers at the time.

This led to discussions surrounding the method of delivery. How could we support a springboard for effective learning? What did marketers use to learn effective industry techniques at the time? What challenges were entry level marketers encountering? What was holding them back from promotions or excelling in their role? What was causing friction and preventing them from feeling confident in their decision-making?

I ended up proposing multiple ways we could solve this at different levels of development effort. From skinning existing tools to hiring an external team, I carefully considered the development team's availability and current workload. I determined that whatever the method we used for development, we needed to bring in an external team to help build out our initial product, as the core team was occupied on other projects.

Defining Product Requirements

Once I had the go-ahead from the executive team (we called them the Jedi council), I set out organizing a plan for development. While Jodie hired a writer to help her define the educational requirements, I documented the high-level vision for the product and laid out a rough development timeline. I also defined the scope for the initial buildout and created a backlog of potential features that mapped back to the business goal, which I then prioritized into proposed sprints.

Mapping the User's Journey

When it comes to making apps, I'm not afraid of heights - I love defining the high-level view. When it came time to describe the activity loop we thought would be conducive to learning, I made a simple user journey to show where we could start. Using this map, Jodie and I went through a few iterations, then immediately jumped into building content we could test our ideas with.

Early Prototyping

Once we had a plan in place, I moved into prototyping alongside our content writer, Luke Renner. The quickest way to test the educational value of the app was to start prototyping it. I discovered Twine during my research into GBL apps and familiarized myself with it in a couple days, then showed Luke how he could use it to make decision points for the user to navigate through the story and encounter lasting consequences in his narrative.

Using Twine, a game engine for creating branching narratives (or "choose your own adventure" stories), we created a story that followed the educational goals Jodie had defined. We then took the prototype to any marketers we could get access to to see how they reacted. It turned out we needed a bit more to make it a compelling experience - a simple branching storyline wasn't keeping them hooked.

Pivoting

A few iterations later, we added three key elements: Activities (mini-games), Daily Challenges, and Personal Progress. What started as a branching narrative turned into an accessible story-driven RPG disguised as enterprise software.

Every time the player made a choice in the narrative, finished an activity, or completed a daily challenge, they would earn points in five practical soft skills. As we continued iterating, it became clear that combining these three elements with a social aspect was crucial.

Not only would the user be able to see their personal progress and record valuable insights about their career goals, there was the potential to see how they stacked up against other marketers using the app. This competitive angle played perfectly with our personas and provided the stickiness we needed.

Designing while Prototyping

Our prototype served a dual purpose: it gave us valuable insights into what users needed to be able to secure new knowledge, and it showed the Jedi council a vertical slice of SteelHouse University's potential as an important product in its arsenal. As we iterated on the prototype, I went straight into visual design targets.

This was still early in the process, so once we agreed on a general direction for the design I tasked the team to developing the first wireframes using the learnings from the prototype.

Roadblocks

A few weeks before our first major production sprint was planned, SteelHouse hit some major hurdles on the business end. This had a huge impact on our project since it wasn't a core product and was still in the exploratory phases. With our finances frozen, we had to put the dev team on hold while the company sorted the issue out.

Bouncing Back

Despite a major roadblock that surely meant doom for the project, Jodie, Luke, and myself continued working on the prototype. We added activities, content, and polish so we could make the case for the necessity of the project. By the end of Luke's contract term, we had a solid bed of content and faux functionality on which to demo the product.

I even pitched additional concepts for smaller projects we could do, including an educational VR experience for CES. All I wanted was to get the product into the hands of consumers so we could learn what we needed to make the product great.

Dealing With Disappointment

After a couple months wondering about the future of the project - and still working on the prototype - SteelHouse University was officially shelved as the company shifted focus to other priorities. We had done what we could, and it was time to work with the team on other pressing initiatives.

What I Learned

This project was a great opportunity for me to combine all the skills I had acquired up to that point to build something I really believed in. I dove headfirst into product management; I got to lead an external team; I learned a new game engine (Twine); I documented and organized the entire project; I expanded my coding skills to make the prototype; and I designed high-fidelity mocks of the potential app, which I then implemented into the prototype.

While the product hasn't been released to the public, in the end, it was a tremendous learning experience and I'm a better rounded designer for it.

If you're an employer and you want to see more designs or try out the prototype, feel free to email me and set up a meeting.