BackgroundPublishing_Banner.png
 

Power Editor Background Publishing (Facebook) | 2016

How might we reduce the pain of publishing new and changed ads for Facebook’s advertisers who have thousands of ads to manage?

Power Editor was Facebook’s ads creation and management surface for the largest advertisers. Its most powerful features were a draft state for edited or new ads and the ability to do bulk actions. However, because publishing drafts was also a bulk action, advertisers were spending 2.7% of their time on Power Editor waiting for a publish to finish. This was a legacy feature from old versions of Power Editor that were not browser-based and required uploading and downloading spreadsheets of ads. To get out of people’s way, we made publishing a background process.

Project Length

6 months

People

1 designer (that’s me), 2 engineers, 1 product manager, 1 content strategist, and 1 researcher

 

The Problem

The people spending the most time in Power Editor were typically people within a large company whose entire job was running ads. They weren’t always making the images and video or writing copy for the ads, and so relied on being able to save their work to wait on assets from their creative counterparts or approvals from a manager.

 

2.7% of these advertisers’ time was waiting for their items to publish. Facebook used to prevent them from working during an upload, and at the point we started the project, the largest 10% of advertisers took more than a minute for each publish. Advertisers managing the items considered it their coffee break, and besides the frustrating wait, it was especially annoying if there were errors or failures.

The screen people would see while publishing items… for a long, long time

The screen people would see while publishing items… for a long, long time

 

Exploration

There were several solution directions we could have headed in, including removing draft functionality and therefore the friction of publishing. Because publishing is how advertisers spend money and because of the utility of drafts, we wanted to change their flow as little as possible. I chose to rely on clear status and actionable messaging to make sure they knew

  • That the publish was happening

  • What they could and couldn't click (to prevent back-end errors)

  • When the publish finished, what happened, and what they could do about it

 

I designed the affordances for this, adding

  • A lock item on the checkbox so they’d not be able to edit while publishing

  • An animation in the status column telling advertisers what was publishing or finished publishing

  • A notification for different states of success or failure with actionable next steps

bgPub_Original_noQueueing.gif
 

Findings

In doing research, we found the signals and model were intuitive for people and they quickly forgot what it was like to publish the old way. The model still allowed them to retain the Q/A step of review they relied so heavily on.

Error reporting was especially important because of publishing stability issues, especially in large batches. There was a 98% success rate on the back end, but that still meant 20 items in 1000 fail for a reasons that weren’t the advertiser’s fault.

They were suspicious of doing anything to cause failure of a large publish because they would have to track down the errors and fix them. Making sure they knew what went well and what went poorly in one place and then sharing steps they could take next made error handling much easier and clear for advertisers.

However, we weren’t completely meeting the need to get Power Editor out of its own way. If advertisers made another set of changes while one set was still publishing, they were unable to publish that set of changes, which was a remaining point of friction.

Because of this good feedback, we shipped this version to our 5 million advertisers to good reviews and stable metrics.

 
ToastPost.png
 
 

The Solution

In the end, we built on our successful starting also introduced queued publishing, meaning that an advertiser could create or edit ads while they were publishing other new or changed ads, and the ads would join a publishing queue.

We also enabled viewing ad item details while they were publishing, instead of locking any clicks on the item as in the first version.

Each item was also unlocked as it finished publishing, reducing out-of-commission UI even more.

bgPub_Queueing.gif
 

I designed and animated an onboarding experience in case people were alarmed by not seeing their changes publishing as they did before. It turned out that we didn’t need it because when we launched people didn't seem to notice the change.

Creation of new items and edits are up, and advertisers publish in smaller batches of items as well. It seems like we’ve reduced friction so that advertisers can treat publishing like a save button, and the smaller batches lead to fewer and easier-to-fix errors.

bgPub_NUX.gif
 

Learnings and Next Steps

Some challenges we faced were the tradeoffs in preventing error states and having the most open interface possible. I collaborated closely with the engineers to find the best compromise between effort expended and user experience. Learning these skills is something they don’t teach in school, and it was great to start with such excellent engineers.

Additionally, this project ended up being instrumental in being able to merge Power Editor and our other ads surface, Ads Manager, into a single product. This set the stage for thinking about how Ads Manager and Power Editor could have similar publishing models. You can check out that project here as well.