Big Fish Games
TackleBox Messaging is an online tool created to provide marketers with a way to schedule Push Notification and Interstitial marketing campaigns. It replaces other SaaS we were previously reliant on by being faster, easier, and more robust than its competitors. It’s also a more cost-effective solution.
Research existing tools, define user needs and expectations, create and iterate on designs that worked within technical limitations, conduct various types of usability tests, determine style guides and design patterns and their usage, and train junior designers.
TackleBox Messaging is an online tool created to:
Provide marketers with a way to schedule marketing campaigns
Replaces other SaaS we were previously reliant on
Improves upon competitor’s tools by being faster, easier, and more robust
Bonus, it’s saved the company loads of money (more on that later)
The first released version allowed marketers to schedule Push Notifications and Interstitial ads with the tool. A robust roadmap of additional features has been developed to expand upon this, and many new features have already been implemented. I managed two other designers who contributed a variety of design deliverables for the product. I created consistency by reviewing their outputs, providing feedback, and owning the overall vision of the product. I also collaborated with product managers, engineers, and an assortment of people who work on the games side of the business to ensure cohesion across the board.
When I was first asked to help with designing what is now called TackleBox Messaging, the scope of the product was vague at best. The steps I took to refine the product description down included:
Discussing the Director of PM’s vision and roadmap
Finding a product manager to collaborate with
Understanding the technical capabilities and constraints
Conducting a whiteboarding exercise with engineering
The PM helped by defining the business requirements of the project and getting in touch with game studios contacts. Her involvement was instrumental in the success of this entire project, and I am incredibly thankful for her guidance.
Research & Analysis
Research activities included:
Auditing existing tools from our competitors
Observing users perform day-to-day tasks with those tools
Identifying core user paths and existing friction points and frustrations
Interviewing groups to understand how they worked independently and how they collaborated
Aggregating findings and surveying users to validate our assumptions
The results were quite mixed. Each team had its own set of challenges that made it difficult to decide on product requirements. One team, for example, had a high volume of games they maintained. Yet they were delivering the same messaging campaigns in their entire catalog. Another team worked with third party developers and often had issues with their partners not adhering to naming conventions.
To nail down the finalized scope of the project:
The PM & I aggregated and reviewed the feature requests stakeholders provided
I lead a content strategy meeting with stakeholders to determine required features
From that, we created a backlog of features for future iterations
We defined the vocabulary to describe common design patterns
The PM drafted a Business Requirements document (BRD)
The results of the content strategy meeting gave us a very concise feature list for our first version of the tool. We also gained a bonus backlog of features to add in future iterations. The best part was everyone felt like we took their needs into consideration. UX win!
I should mention that this process is slightly different than how my team does things now. At that time, I proofread the BRD to ensure alignment in understanding before giving feedback to the PM. Now my team also uses a template I created to define our own product vision, and we use that to ensure alignment. Read more about my current design process.
Once the BRD was created, it was time to design. Next steps included:
Talking through user flows with another designer to work out issues
Creating low fidelity wireframes to pinpoint required elements
Meeting with the PM, engineers, and future users to elicit feedback
Revising designs based on stakeholder input
Creating full color comps
Wireframes were reviewed first by future users, project stakeholders, and engineering before the next iteration. After a few iteration cycles, the basic layout and functionality was agreed upon. Leveraging the Bootstrap framework enabled us to focus on perfecting the UX and UI without spending time on extraneous details. That said, we need to make decisions such as what classes and elements to use. This evolved into what is now the TackleBox style guides and conventions document.
Validating the Work
One of the biggest challenges we had with this product is testing. It had a lot of complexity and detail that would have made it a massive undertaking to create interactive prototypes. After this project, we decided to use Axure to build our interactive prototypes moving forward. But at the time, we had neither a license nor the luxury of time.
I suggested to the PM that we test the designs with paper prototypes. I had first been introduced to this technique while teaching, and it proved to be exactly what we needed. Using the existing comps, I created a few additional assets to represent the UI in various states. I then printed the comps, cut them up, and organized them in folders.
When I first walked into a meeting with a paper prototype in hand, I’m fairly certain everyone in the room was indulging me. Yet, sure enough, both myself and the PM were pleased with the quality of feedback we were able to gather when using this testing method. Our users also enjoyed the process, which made the whole testing phase more fun.
Up & Through Development
After usability testing, we review the designs with the front-end services and game services teams. We helped both teams define their own project requirements by explaining the intended functionality of the tool and backend services needed to support it.
Following this, we did the following:
The PM and I drafted a technical specifications document
I created assets to supplement the document
I co-supported the dev team while training a junior designer
One phase of the development cycle I’ve introduced to the team is what I call a design audit. Once the build is ready for the QA team, I review the build to ensure parity between the designs and execution. It’s a habit I picked up while working at Intrepid Learning that holds me accountable for releasing a high-quality product, and it has served me well.
With all the bugs ironed out, we successfully launched the product. Some highlights include:
TackleBox Messaging has been lauded as a vast improvement compared to competitors’ tools
We cut all erroneous features and introduced new features to address our users’ needs
We also reduced complexity and eliminated our users’ most dreaded pain points
Since launch, TackleBox Messaging has undergone multiple revisions and versions
Over 20 Big Fish games have implemented TackleBox Messaging Interstitials
And (drum roll, please) average marketing costs have gone down approximately $1.2 million per month company-wide after adopting TackleBox Messaging
This first version has a special place in my heart as it was an opportunity for me to learn new tools and techniques. I have since then passed on many of these learnings to my team as they began to pick up TackleBox projects of their own.
The biggest lesson learned was the importance of a great partner. My designs would have been dead in the water had I not involved a product manager early on. I couldn’t provide a better example of why it’s so vital for a designer to work in tandem with their product manager!