I spent the Summer of 2017 as a Product Design Intern through the KPCB Design Fellowship program. During these 12 months, I worked on the monetization team, working on two projects - the first being the internal ads manager tool, while the latter half of my internship was focused on early designs and concepts for Nextdoor Interests.
While designing the ads manager tool wasn't the sexiest task, nor was it consumer facing, it was an extremely complex tool that served as the foundation for the Nextdoor sales team which drove all of Nextdoor's revenue. Furthermore, for consumers/users, do you ever wonder how ads (below) that seem scarily relevant, appear in your newsfeed?
One of Nextdoor's primary sources of revenue is through selling native ad spots in the newsfeed of Nextdoor's 27 million+ users. The actual process of how these ads appear there is quite complicated, and I created a tool for the internal sales and ad ops team to use to help reduce friction in the process.
I led the design of the desktop based ads manager tool for our sales team, working closely with the principal engineer and monetization PM to ensure the product designs fell within the boundaries of the constraints.
Designing a tool for the ad sales team at Nextdoor that can sell, track and update available inventory based on targeting parameters desired by advertisers.
It's difficult to explain how the entire process works, and if I tried to explain the entire thing on here, it would probably bore you to death - but basically, as the monetization team all sat together, I had the opportunity to chat with individuals who'd be using the tool to understand the points of friction, the features and abilities they wished they could have that would make life easier, etc.
The default view for the salesperson provides them with a high level view of their own insertion orders, or IO's. Each of these IO's they create can have three possible states: a) Draft state b) Held state, where the inventory is reserved but not yet officially filled, and c) Book state, where it's both reserved and is ready for content to be filled by the ad operations team. Let's walk through a basic IO creation flow (user clicks "create new IO" button in above screen):
Once the two required fields are filled (advertiser and IO name), the salesperson creates a new line item, which is the core of the entire sales system.
Users create a line item by selecting the button below the required field, which creates a sliding side panel for lightweight access.
The parameter selection panel has quite a few options. Below are just a few of the possible combinations a salesperson can select from.
Once parameters have been selected, users can save the line item, which then the system checks the parameters with an algorithm that returns a result in up to 10 minutes due to the complexity of the database. To mitigate this latenct the user's end, line items have a "checking" state, and users can continue to create line items while waiting.
Below is an example of what an IO might look like once it's been completed. Advertisers can create different IOs - usually their differences are between the DMA's. Not all line items, however, are available. If a line item is unavailable, it's visually separated from the available ones. Users can then hold a line item if they are ready to send it off to be signed by the advertiser.
While I'm only showing the user flow of creating a line item, this tool has many other flows, including editing existing line items, saving, deleting, etc. However, it's really only worth showing the core functionality of what covers 80% of how sales people are using its features.
My Summer spent working with the monetization team at Nextdoor was a great learning and growing experience. Working with a ~200 person company building for 27+ million users around the world is no easy feat. I look forward to experiencing the future of Nextdoor myself!
Designed and coded with ❤. Copyright © Jeff Wang 2018.