Sever ties to an expensive and inadequate SaaS.
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, design tools that work within technical limitations, conduct various types of usability tests, 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
- Improve upon competitor’s tools by being faster, easier, and more robust
- Bonus, it’s saved the company loads of money (more on that later)
Currently marketers can schedule Push Notifications and Interstitial ads with the tool. We’re beginning the process of expanding it to include email campaigns as well. I manage two other designers who contribute a variety of design deliverables for the product. I create consistency by reviewing their outputs, providing feedback, and owning the overall vision of the product. I also collaborate with product managers, engineers, and an assortment of people who work on our games to ensure cohesion across the board.
In the beginning, our Director of Product had a vision to develop a suite of tools and services intended reduce the number of one-off solutions being created for games. He saw value in creating modular solutions that could be accessible to all our games through the SDK. But 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 included:
- Conducting a whiteboarding exercise with engineering
- Understanding the technical capabilities and constraints
- Inviting a product manager to collaborate with me on the project
- Discussing the Director of PM’s vision and roadmap
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
While we were able to gather a lot of helpful information, it became clear that it wasn’t going to be easy to agree on how to prioritize features. Each team had its own set of challenges that made it difficult to decide on product requirements.
One team, for example, worked on a game studio that 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 games. They often had issues getting developers to adhere to consistent naming conventions.
Clearly, we had issues.
To nail down the finalized scope of the project:
- We aggregated the feature requests stakeholders provided
- I lead a content strategy meeting 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
After several iteration cycles of wireframing, the basic layout and functionality met the needs of the project. To be honest, this project required a fairly minimal amount of visual design work. The engineers had been creating similar tools using the Bootstrap framework already. As they say, if ain’t broke, don’t fix it.
Leveraging a 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 our style guides and conventions document, which is now owned by another designer.
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. These days, we use Axure to build our interactive prototypes. 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.
After usability testing, the product manager scheduled a meeting to review the designs with the front-end development and game services teams. The FES team provided us with some insights on how they had built similar tools. This allowed us to simplify and reduce the development effort. 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 created a technical specifications document
- I reviewed, revised, and created assets for the document
- I assigned a junior designer to work with eng when issues arose
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
- Not only did we maintain parity in features, we introduced additional features
- We also reduced complexity and eliminated our users’ most dreaded pain points
- Since launch, TackleBox Messaging has been revised (Learn more about moving beyond the MVP)
- At least 16 games have fully implemented TackleBox Messaging Interstitials
- At least 5 more games have partially implemented
- One game alone has reported it saves about $12k per month by using our tool
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!