Big Fish Games


Project Name

TackleBox Messaging


Project Summary

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.


Gina Connolly (Product Manager), Daniel Monroe (UX), and Harry Chris McCorkle (UX)

My Role

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.

Project Details

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.

The Vision

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:

Whiteboard sketches for segmenting users. One of the fastest ways to convey ideas in a meeting.

  • 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.


I often seize inspiration when it hits me by sketching out ideas on how requirements might be rendered even during the early stages. Here is such a sketch of how messaging data might be displayed after a day of interviews with users.

Finalizing Scope

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)

You can see my musings about terminology near the bottom of the page.

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.

Design Iterations


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.

The original paper prototypes splayed out on a table. You can see some of the bits used to alter the page content depending on the form's state.

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

A graph showing marketing sales from the year before and the year after a game implemented TackleBox Messaging. The marketing team attributes success to the flexibility of the tool, the powerful segmentation features, and the agility in which new campaigns can be created.


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!