Big Fish Games


Project Name

TackleBox Tool Suite


Project Summary

TackleBox is a suite of online tools created to ease the burden of game operations for many of the employees of Big Fish Games. The tool replaces other SaaS we were previously reliant on by being faster, easier, and more robust than its competitors as well as offering new features and capabilities.


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

My Role

Research existing tools, define user needs and expectations, design tools that solved user needs, understand and work within technical limitations, conduct various types of usability tests, and support developers through integration.

Project Details

Warning: this is not a traditional UX case study. So often in our field, we present our work as though each project has its own full, complete story that has neatly measurable outcomes and outputs. However, the reality is a lot of the work we do day in and day out has a marked impact on the success of future work and how the work we do is thought of by powers that be.

This case study is intended to show how to grow a MVP (minimum viable product) into a larger, sustainable product. You won’t find a single project here, but rather a summary of many miniature initiatives and side projects that contributed to a greater whole. So, yes, I’ve broken format. But was it really a great format if it didn’t allow me to show you these steps? Something to ponder.

The success of the first iteration of TackleBox Messaging increased demand for similar solutions from our team. TB Messaging was originally created to provide a homogenous solution for all BFG games, but there were many other problems that likewise needed to be addressed. Other online tools were therefore created to:

  • Ease the burden of game operations for Big Fish Games employees

  • Replace other SaaS we were previously reliant on

  • Provide new features and capabilities not available in other tools

  • Automate a number of processes and services

These tools became part of TackleBox, which is the name for our online tool suite. I was responsible for much of the design work for this product line, but I also managed other designers who contributed to TackleBox. I created consistency in design by reviewing their outputs, providing feedback, and owning the overall vision of the product. I also collaborated with VPs, directors, product managers, engineers, researchers, and an assortment of people who work on our games to ensure cohesion across the board.

The Vision

After successfully launching our first product, the product design and product management teams had proved that we could revolutionize the way Big Fish Games internal tools were created and used. We were allocated resources and tasked with defining the long term vision and intended trajectory of the newly approved product line and its dependencies.

We wanted the disparate tools to feel cohesive, consistent, and unified. Some of the actions the team and I took to accomplish this included:

  • Review & prioritize the roadmap of proposed project

  • Consider permissions and access restrictions

  • Redesign global navigation & IA to be scalable and flexible

  • Inform design with user testing

Laying the Foundation

As is often the case in our industry, the project steps are sometimes shifted a bit in order to accommodate developer schedules. In this case, we prioritized the design work for a universal navigation that would be the UI chrome for the tool suite because it was a dependency for future projects, it was a small effort for design to create, and our developers had time to do it quickly. The primary goals were to provide a clear path for users to explore all of the tools available to them and to clearly communicate the permissions levels granted to them for each tool.

Below are some rough wireframes of the initial concepts for the project. I like to use Balsamiq when I want something just one step cleaner than sketches, but loose enough that contributors feel like no part of the design can’t be changed or removed if it’s not the right direction for the project.


Research & Analysis

Some of the tools that were being brought under the TackleBox umbrella had already been created. Many of these tools that could theoretically address the issues our users had were so difficult to use, sometimes the team that owned them couldn’t fully explain how to use those tools. In addition to poor usability, there were a number of inconsistencies in functionality.

We began unraveling the problem by using multiple research techniques to identify issues and determine users’ preferences and expectations within the tools. Research activities conducted for TackleBox to date include:

  • Surveys

  • Focus Groups

  • User Personas

  • Rapid Prototyping

  • Card sorting

  • Tree tests


A sample of some of the outputs of our research for TackleBox.


This was another opportunity for me to mentor my teammates. I introduced most of these techniques to the people I worked with because we had limited access to the internal research team at that time. One of the best parts about testing internal products is the flexibility and availability of our users being coworkers. They were comfortable with experimenting with new processes and techniques because they knew that it was helping us build better tools for them.


The process of updating and unifying experiences across multiple tools necessitated an extensive amount of documentation. The primary goals were to create consistency between the existing tools, but that groundwork made the process of creating new tools much easier moving forward. Documentation deliverables for TackleBox includes:

  • Tool Style Guide & Conventions

  • Help Guides (wiki)

  • UX Debt Catalog

The living document that is the TackleBox tool style guide is owned by one of the designers on my team. Together with the product manager, we worked to aggregate all of the UI elements and patterns used in the tool and decided how to uniformly apply those standards across all tools. Help guides were created by the PM team to assist new users adopt tools and to help communicate known issues and new features as they were released.

One of the most valuable initiatives I’ve implemented for TackleBox was collecting and managing what is known as UX Debt. I was originally introduced to the concept when watching a webinar presented by Jack Moffett, which you can read more about here: https://www.uxpin.com/studio/ebooks/eliminate-ux-debt-enterprise-products

You can go to the Design Process page on my website to learn more about cataloging UX debt and other aspects of my design process.

Design Iterations


Moving beyond the MVP meant providing features that were secondary, or “nice to haves”. Following a content strategy meeting I lead for v1 of TackleBox Messaging, we created a product feature backlog of such feature requests. While I was working on creating designs for brand new tools, I also coached my team members who were contributing work to TackleBox. My work included:

  • Evaluate & improve existing tools and services (discriminately)

  • Onboard and/or cross-train other designers on team on tools, services, and conventions

  • Add supplemental features to support existing functionality

The benefit of having multiple eyes on these projects was we could share findings and solutions with one another. It also meant that I had more hands to share work as demand for these projects increased, which allowed me to balance workloads more equitably. Below is a demo of an interactive prototype I used to test a redesign proposal with our users.

This video demonstrates how the user would add an interactive element to a marketing interstitial.


So, you may have noticed I have been describing the tool suite as TackleBox this whole time. Yet it wasn’t until fairly late in the process that it had a formal name. The working title was something to the effect of the “game services platform” or some version of that, depending on who was speaking. It was awkward when trying to add a label to projects, meetings, and documentation.

The project needed to be officially named and branded for several reasons. Firstly, we had created a proper product at this point with its own team of product designers, product managers, and development teams. Secondly, we needed an easy way to communicate about this product both amongst ourselves and to other Big Fish Games employees. This process involved me doing the following:

  • Leading a brainstorming workshop to generate product name guidelines and ideas

  • Surveying a wider group to vote on final selections

  • Generating a logo and redlines

  • Designing t-shirts for internal distribution

Since I have a background in visual and graphic design, it seems these sorts of projects inevitably find themselves on my to-do list. I was once asked why this part of the process made it into my portfolio. Design is about solving problems, and I don’t shy away from problem just because it’s non-traditional. And besides, leading workshops and creating surveys are key skills for a UXDer to have.

I saw the value in perpetuating a sense of pride and ownership in the work we were doing. It also provided us an opportunity to promote our products internally. This has since helped our teams increase product exposure and adoption rates as it gives us a way to start conversations with our users.

Building Out

As a manager, I like to attend project kick-off meetings for new initiatives to ensure consistency between products, adherence to priorities and roadmap, and an understanding of the complex interactions between tools and services. In this way, I was able to provide support and guidance to the PMs and designers working on TackleBox projects as needed without stepping on too many toes.

I was also a member of the team that regularly groomed and prioritized the product backlog. In these meetings, I represented the voice of the user and provided an explanation how initiatives could create a better experience for our consumers. This is especially valuable when there is pressure to produce outputs rather than outcomes. A few examples of tools our team has designed include:

  • Push Notifications

  • Profile Moderation

  • Deep Linking

  • Promo Codes

  • Measurement URLs

  • Game Setup

  • Game Configuration

  • Custom Game Data

  • A/B Testing for Interstitials


Our line of products continues to provide value to our game studios and other teams. As I mentioned in the previous case study, the average savings in marketing as reported company-wide is an estimated $1.2 million each month. One of our game teams has reported saving $12k a month by using the Push Notifications tool we have created alone.

Overall, I am very proud of the work that has been done on our products. It has been extremely rewarding transforming this vision into a cohesive and usable experience. I have learned so many new processes and procedures while working on TackleBox. Foremost, I’ve gained a much better understanding of the product management process. I now better understand the significance of creating a business case for design tasks and how to do so.

My team and process has also benefited from the formalized documentation of UX debt. More than that, I have grown as a leader by pushing myself to create these new systems and processes to deal with the complexity of these products.