My Role

This project took place from the fourth quarter of 2017 until the first quarter of 2018 at Index Exchange. During that time I served as the sole Product Designer on the product collaborating with a product manager and team of six engineers to execute and deliver on the product.

I was responsible for executing on all stages of the product design process. This included delivery of all product design deliverables, research, best practices, wireframes, testing, and high-fidelity artifacts. Additionally, I worked closely with key stakeholders to validate product-market fit, and develop novel design solutions based on insights derived from user needs and testing.

The Problem

Private marketplace deals are an important component of Index Exchange’s real-time bidding system representing a 10% (and growing) share of revenue at the time of this project. Growth is a result of considerable interest from both media publishers and buyers in having the ability to negotiate terms based on price, inventory, audience, and other targeting options for premium impressions and advertising dollars. At the time of this project 60% of deals on Index Exchange’s platform never transact resulting in a high operational cost due to the multiple potential points of transactional failure.

The purpose of this project was to create a visual indicator of a deals transaction status, as well as multiple pass/fail tests that would cover the vast majority of deal failure points to assist in debugging . These tests and their results were to be made available to customers and their account managers via an existing page in the Index Exchange web application. While the tool can be used to diagnose any deal it is important to note that this product was designed to diagnose the high number deals that are not transacting.

The Approach

We were handed a clear challenge to develop a tool that could diagnose points of transactional failure in a deal. The business value of this objective was clear but the immediate benefit for the user was still unclear. Additionally, technological constraints on the back-end of the advertising exchange made it unclear whether or not it would even be possible to create tests capable of accounting for all the points of transactional failure. As a designer, I had some tough problems to solve and so did the rest of my team. We needed to identify why deals fail to transact so we could assess if we can test those cases, and so I could figure out how to reveal this information to our users in a useful way. In collaboration with my product manager, Patrick Cool, we set out to uncover why deals fail to transact. This meant talking to users and experts alike to gain as much insight as we could into deals and how our users interact with them.

The Discovery

After sitting down and conducting face-to-face interviews with our customers and stakeholders from across the company we were able to discover a number of insights that would guide the direction of the project:

1. Clients have begun choosing competitor platforms to run their deals. There have been instances where publishers and demand-side partners have told us that they will not run a deal through the Index Exchange platform because we have been slow to resolve deal transaction problems.
2. The Support and Ad Quality teams were responsible for diagnosing deal transaction failure points through a labour-intensive manual process. By introducing deal test automation they would be able to spend more time on higher-value tasks.
3. A broken non-transacting deal is not helpful to any of our customers or partners and results in lost revenue potential for Index Exchange.
4. A solution for non-transacting deals is in high demand across the industry and by our customers.
5. There’s are MANY reasons a deal could fail to transact but there are four main categories that present clear tests cases:
   • No bid requests from Index Exchange.
   • The buyer doesn’t respond, no bid responses.
   • The buyer bids and doesn’t win.
   • Deals not scaling or winning.

The Vision

Equipped with these insights we developed a vision to transform the experience of private marketplace deals on the Index Exchange platform into a staple of the business that would become well regarded by publishers and buyers. Not only would we uncover why a deal is failing to transact but we would also provide users with potential solutions that they could act on themselves, all in a simple and easy to use tool built into the existing deals management screen of the Index Exchange web application.

The Requirements

Our product team had very specific requirements for the capabilities of this product. Although most of these were mandatory, many would prove to be technically impossible within the timeframe allotted to the project. They were as follows:

• Know how much traffic my carved out deal section inventory receives so that I can understand how often deals have the opportunity to transact.
• Know why Index Exchange is not sending bid requests for my deal
• Know why a DSP that is being sent bid requests for my deal is never responding
• Know why a DSP that is responding to bid requests for my deal is never winning the impression
• Know how much traffic my carved out deal section inventory receives so that I can understand how often deals have the opportunity to transact.
• I want to know why Index Exchange is not sending bid requests for my active deal.
  • Pass/fail test for:
    • Publisher site tag setup
    • Publisher segment targeting setup
    • DSP controlled publisher whitelists
    • Deal flight time expiration
• Know why a DSP that is being sent bid requests for my active deal is never responding.
  • Pass/fail test for:
    • Buyer filters out the bid request due to…
      • SSL/HTTPS links
    • Video:
      • VPAID vs VAST improper fields
      • Skippable inventory is not signalled
      • A field is missing e.g. “playback method”
    • Expandable direction missing
    • CPM exceeds campaign ceiling
    • Mobile web inventory is being signalled
    • Site ID is not in the DSP console
    • DSP size ID filtering
    • The publisher is on the agency blacklist or not on a whitelist
    • Deal contention at the DSP level
    • DSP uses optional open RTB fields for targeting
    • DSP geography (country) filtering
• Know why a DSP that is responding to bid requests for my active deal is never winning the impression
  • Pass/fail test for:
    • Deal campaign creation
    • Deal campaign approval
    • Publisher block(s)
    • Successful impressions tied to the deal sections (to confirm site tags are active)

Detailed Design

White Boarding & Paper Prototypes

I started by sketching out ideas on paper and white-boarding to explore and understand how this information might be laid out and the implications it would have on functionality.

Wireframes

After receiving feedback from our stakeholders and my team I converged on a few of the ideas from the early design phase. I used this feedback to diverge, converge, and continually refine the design over the course of five major iterations. Throughout the design process the focus always remained on providing the user with scannable high level insights that would allow them to quickly and easily assess problems with the deal. I extensively explored a combination of progressive disclosure techniques such as expansion panels, and modal overlays to provide the user with additional information where needed. The evolution of each major test section can be seen below.

Deal Setup Designs

DSP Designs

Campaigns Designs

Double Click for Publishers (DFP) Designs

For the full DFP connect workflow check out the InVision Prototype.

Testing

Although resourcing was limited I did my best to supplement qualitative user research with quantitative data. I designed and created a first click test using Optimal Workshop to see which design was more effective for completing our users tasks. You can take the test yourself if you'd like.

Production Implementation

I worked closely with engineering team members on the implementation and QA of the product. Although the production version does not exactly reflect the final designs due to time constraints and limited resourcing, the product still reflects the overall design direction and provided significant value to our users.

The Impact

More Deals Spending Sooner and Fewer Deals Never Spending

Over the course of three quarters and multiple iterations, this project resulted in a 52% increase in deals spending within the first week of a deal’s start date, a 35% decrease in deals that never spend, and a 27% decrease in time to spend. Building on the momentum of the UX quick wins I designed to improve Index Exchange’s deals interface we were able to design and develop a tool that has had a significant impact on Index Exchange’s private market business and overall customer satisfaction.

Challenges

As one of the first user focused products Index Exchange chose to invest in this was a major opportunity for the product design team to demonstrate the value of a user-centred approach to product development. The project was given limited resourcing and a short timeline to execute. As a result I was required to move quickly and be highly adaptable to product requirements, more specifically technical constraints, and skillset limitations. This meant adapting my designs to the simplest technical implementation (eg. The use of expansion panels instead of cards) and resulted in a number of features being abandoned altogether or only partially implemented.

What I Learned

Sometimes Your Worst Product is Your Best Design Opportunity

In less mature organizations it can often be difficult to develop any political capital for design. This project taught me that sometimes a companies worst product offering and the project you least expect is also the best opportunity for designers to demonstrate the value of our craft to the business. This proved to be true as we began to design and develop a product to address the problems with our private market product offering that was previously driving users to competitors. I also learned that a design compromise that results from a technical limitation doesn’t necessarily have to be an experience compromise for our users. If you communicate clearly, think outside the box, and don’t mind getting your hands dirty you can often develop an alternative solution that still serves the needs of your user. To date this was still one of most successful and collaborative projects I had the opportunity to work on at Index Exchange and continues to serve as a success story internally.