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