Redesigning the Advertiser’s Toolbox

Strategizing a new design theory for Boost Media

What is Boost?

Boost’s platform is a two-sided marketplace, where online advertisers pay to source ad copy and designs for Google AdWords, Bing Ads, and Facebook’s Ad Platform, and writers/designers get paid to create the ad collateral (similar to Fiverr or Upwork).

Advertisers can then A/B test these new ads against their existing ads, to better understand what their audience responds to.

Boost’s Advertiser Platform, as it looks today.


Over the course of two months, I redesigned and helped develop an MVP of a new platform for Boost. The redesign was rolled out to a majority of their user base in that time, and is now used exclusively by all customers.


As their only designer, I was effectively responsible for designing the whole platform, and collaborated with their engineering team to develop the front-end, using the Angular framework.

I also worked with their lead project manager, Greg, on how to structure user interviews, collect research on user activity, and advocate for more design thinking within the company.

The dream

To move all of their existing clients onto a brand new web application, that could be used without the handholding of Boost’s account executives.

Greg and I spent many an afternoon mapping out how to restructure the Advertiser Platform, and discussing ways to update the language used throughout.

On research

Boost Classic, as the original platform was named, was built almost a decade earlier, and was showing heavy signs of feature creep.

Transitioning to a more self-serve model, Greg and I wanted to focus the platform to its most critical and most clear features, to ensure that advertisers had an empowering experience.

As Greg spoke with a handful of clients weekly, we reached out to them to set up user interviews. We would observe their interactions with the platform over one hour periods, to better understand what to prioritize for the redesign.

The interview process

We structured the interviews to have users go through regular tasks: approving or rejecting new ads, managing A/B tests, and generating historical reports. Throughout our interviews, we asked our users to narrate their thoughts and explain any obstacles they faced, as they faced them.

We also put InVision prototypes of the new platform in front of users at the end of interviews, to get early feedback for the platform as we were building it. This early feedback loop was vital to discovering user needs, as well as the gaps in our assumptions. It also gave us a fun way to excite customers and motivate ourselves to build faster.

Being able to prototype ideas in Principle (left) and InVision (right) made it easy to get feedback and test out new ideas with customers early on in the design process.


One of the biggest things we learned was how much trouble users had specifically with the terminology Boost used. Since Boost’s Customer Success Managers (or CSMs) were the ones most often interfacing with the platform, internal lingo had propagated its way into the application itself.

We began a running document of all the jargon we heard the CSMs use, and started mapping out ways to simplify it for an external audience.

As part of an audit on the language used in the platform, Greg and I generated simpler terminology and iconography for Boost’s many products and features.

After running sessions for a four weeks, we had narrowed down the features we were planning on building and thrown out many more.

Building the new platform

Greg and the other project managers would start each sprint by grooming the developers’ backlog, and once prioritized, it was off to me to design individual features and interface elements.

Collaborating with engineers

Trying to be mindful of technical constraints, I mocked up my prototypes in Sketch and InVision, and demoed them to engineers early and often. Once my sketches were in a good state, I exported my artboards to Zeplin, where the engineers could extract design and layout directly, without any guesswork on their part.

Getting to share my designs in an engineering-friendly way made design handoffs a breeze.

Even with this foresight, features often turned out vastly different than Greg and I had in mind, due to time constraints.

On becoming an engineer

As the MVP came closer to being finished, I switched gears and began building the features I had been designing.

Being able to prototype with real data meant Greg and I could resolve issues as they came up, instead of waiting until after they were implemented by another engineer.

Meeting our KPIs

The target Greg and the PMs originally set was to have 20 users on the new platform one month after the project’s start, with a general release to follow sometime in the following quarter.

After two months, we managed to build a whole new Angular app and roll it out to their entire user base. User engagement skyrocketed, and CSMs could better focus on what their title entailed: helping customers succeed, instead of holding their hands while using the platform.

Some higher-fidelity mockups of the MVP just before release, showing an analytical dashboard (left), and a way to manage ongoing A/B tests (right).
I designed everything from low-fidelity wireframes in Sketch (on the left) to richer animations in Principle (right).

Design leadership

Throughout our process, Greg and I both advocated for more design thinking, and helped educate people internally on how to implement it in their own processes.

A month after starting our project, I helped recruit Boost’s community manager, Sophie, to become their first full-time user researcher.

Originally in charge of managing the network of writers and designers, Sophie began observing us observing customers, and proposed we do similar research on the writer network. Sophie and I began weekly interviews with writers to better understand the problems they faced, and how to increase the positive experiences they had using Boost.

With Sophie’s help, we began researching writer’s and redesigning the writer’s platform, focusing on the needs and wants of the people most responsible for the success of Boost’s services. Above, a mockup we created after getting feedback from a dozen writers.

After a few weeks, we had created a revolving door of over a dozen writers, who gave us feedback regularly. We tested mockups and prototypes with them, and quickly found ways to make their experience better.

With my front-end experience, I was able to build first passes of the interfaces we needed, and handed them off to engineering to polish and sihp after we finished the Advertiser Platform MVP.

Looking back

Because I joined the effort after they had began developing the new application, we were unable to affect structural changes in a lot of places that needed it.

I would’ve loved a chance to sit down with the engineers and work through creating more reusable components for their Angular application.

One of the biggest problems we faced was reinventing the wheel interface-wise, as almost every feature was built independently, and by different engineers.

On feature creep

Though what we had built was lightyears ahead of Boost Classic, we often fell in the trap of building more to gain parity with it.

Thanks to Greg and Andy for bringing me on, and Ben and Michael for tirelessly coaching me through their massive codebase.