Deals & Packages
Fostering relationships through negotiated deals in a storefront
About the Project
“Deal ID” is the adtech industry's way for Sellers to bundle up their premium inventory and data to sell to Buyers. They can do this privately through negotiations or open them up to a marketplace for any buyer to then target the deal ID in their campaigns. Throughout this year-long project, there were several design challenges that I was faced with.
  • Facilitated conversations while protecting the Seller’s private information.
  • Created a marketplace and shopping experience for Buyers.
  • Organized the information architecture of all the functionality from both the Buyer and the Seller’s perspective.
My Role
At the start of the project, I was a contributing designer and was quickly promoted to the UX lead role. I lead the direction of the design, puting together mocks, prototypes, and conceptual diagrams for the team of developers, product managers, and documentation writers to understand my thoughts.
Tools
  • Maps & Flows
  • Wireframes
  • Prototypes
  • Usability Testing
The Challenge
AppNexus wanted to invest in this highly requested functionality. Rather than just achieving parity with competitors, the team wanted to dig deeper and understand how the functionality fit within users’ process. We set out to make the UI even better and more efficient for users.
Before I joined the team, a pilot of the initial functionality was conducted. The team had done a lot of discovery research and learned that Deal ID worked, but there were many opportunities to make the process more streamlined.
  • Buyers didn’t know how to find deals and Sellers didn’t know how to find Buyers who were interested in their deals.
  • Sellers wanted to make sure their proprietary information was kept private.
  • Buyers needed help when troubleshooting campaigns that target deals.
Helping Buyers and Sellers Find Each Other
The first problem we wanted to solve was to help Buyers and Sellers find each other. Along with two Product Managers, we hashed out all of the goals a user might have from both the Buying and the Selling perspectives. For each goal we determined how that user might set out to achieve it. We made assumptions about the insights they would look for and the action they might take.
Objective
As a Buyer, I want to cultivate stronger relationships with existing partners for better privileges. Who do I buy the most from? Which Sellers have I recently spent more or less on?
Insight
Research spend trends by Seller, country, or brand.
Action
If spend is increasing: Reach out for more privileges.

If spend is declining: Adjust campaigns Re-evaluate partnership & request more volume from seller.
This exercise got the stakeholders on the same page and helped me understand what I needed to design. The initial pilot was designed for a small number of approved participants. In the next phase, we wanted to scale the design to work for all of the members on the AppNexus platform. Because of this, I knew the design needed to accommodate a lot of data and an easy way to parse through all of that data. I started by sketching out a few different ideas.
Because users will already have an idea of the kind of partner they’d be looking for, I knew it was really important for them to be able to search and filter the list by different characteristics. I conducted a card sort to group similar characterstics and included a way for users to see the filters they’ve already applied.
In addition, users will need to quickly access the partners they are already building a relationship with or are interested in. I accomplished this by adding a tabbular view to the grid so users can control the list of partners they are filtering by.
Negotiating and Striking Deals
Several key features were already built out during the initial pilot so users can take action once they find a specific partner they might be interested in striking a deal with. This included a chat feature so potential partners could discuss goals, a dashboard to see how the user is transacting with the partner, privilege settings for the partner, and a way to specify overall spending goals. We called this the “Relationship Page” because it was a page focused on the relationship you have with a specific partner.
For this iteration, we wanted to build out the Deal ID functionality which the pilot did not support. After the user identifies a potential partner, they will likely begin negotiating the deal stipulations and ultimately generate the Deal ID on the Relationship Page.
Because partners could potentially strike hundreds of deals, the interaction that was designed for the pilot, inline edit and creation within the grid, wouldn’t scale very well. I explored a couple of different layouts that would solve for this. After getting feedback from stakeholders, I decided to move the creation of deals into a drawer that slides up from the bottom of the page after the user clicks a “create new” button. This solves for several things:
  • It focuses the user when creating deals and removes unnecessary information when not needed.
  • The drawer provides more flexibility for future enhancements to deals.
  • Users can see more rows in the grid at a time when reviewing existing deals and analyzing its data.
Troubleshooting Deal Campaigns
A major source of pain for Buyers happen when targeting deals with campaigns. While another team was responsible for the buying workflow, I provided feedback and advised the team on issues that Buyers might come up against. Many of the issues were around the deal’s price. Because of additional fees, Buyers weren’t bidding high enough to actually win the auction for the inventory they were targeting through the deal. To alleviate this confusion, we re-labeled the cost of the deal to an “ask price”. This makes it clear, that this is the price the Seller is asking for and the definite price that the Buyer should bid. In addition I recommended that we provide the Buyer with a “suggested price” while setting up campaigns.
For Sellers, it’s difficult to know when a deal is being used by the Buyer. To make this more transparent, I created user stories which gave me insight into how this could be solved.
As a Seller, I’d like to know which partners I have deals with and which partners I don’t have deals with so that I can better understanding my relationship status.
As a Seller, I’d like to know when a Buyer is not utilizing the deals I provided them so that I can reach out to them and find out why.
As a Buyer or a Seller, I want to know when a deal was targeted so that I can better troubleshoot when delivery issues arise.
Scaling Deals
Real-time bidding was successful at scaling advertising transactions but it did not provide enough transparency for the transacting parties. Deals were the industry's answer to this problem but it reversed its success at scaling transactions. Deals required individuals to go back and forth negotiating terms. There were a lot of steps in this process which involved many different people and tools.
After conducting interviews with users, we discovered that Sellers would set up similar deals for different Buyers. They had a list of deals offline in an Excel spreadsheet that they would send to potential Buyers. Once a Buyer accepts a deal, the Seller would create the deal in the UI on the specific Buyer’s relationship page. This meant the user was discovering partners through the UI, negotiating deals offline, and then creating deals back again in the UI.
To streamline this process for both sides of the deal, Sellers could upload their spreadsheets into the UI for Buyers to peruse and choose the deal of their choice. This solution would remove a lot of unnecessary back and forth not only between each party, but between the various tools they used. To visualize this, the product manager created a flow that laid out the steps that would be unnecessary with this solution.
From Deals to Packages
The new streamlined workflow required additional functionality to the Deals feature. I needed to ensure that:
  • Sellers can create deals that are not associated to specific Buyers.
  • Buyers can browse Seller’s available deals.
  • Buyers can execute on desired deals.
Sellers can create deals that are not associated to specific Buyers.
Buyer-less deals needed a new identity that stood out from standard deals. We called it Packages. Packages are new objects that deals can inherit values from. Because they have the same values, I was challenged to create an experience that made it clear which object is which. One obvious way to do this is to use a different layout for creating, editing, and managing Packages. I was inspired by an email inbox layout with a list of items to the left that serve as navigation to click through each to see its details on the right side of the screen. This made it easy for users to see all of their packages at once while quickly drilling into a package to make edits or see its settings.
Buyers can browse Seller’s available deals.
Now that Sellers have a way to upload their offerings, Buyers needed a way to view them. For the initial phase, I utilized the Relationship page. When a Buyer views a specific Seller, they’re able to also see the Packages the Seller is offering. Eventually we created a standalone page with filters to search by specific Sellers and deal details. Since there could be a lot of Packages, I explored a Pinterest style layout which makes browsing easy. Each package was laid out in a grid with columns and flexible vertical heights based on the description length.
After running a usability test with a UX Researcher, I discovered that users found this layout to be overwhelming. Users responded that they didn’t understand what the package included even though there was description text to explain it. It was obvious to me that users were glossing over the text because there was so much of it with no identifiable pattern. This made me realize that the strength of the Pinterest layout are the images. There aren’t really descriptive images for packages unless the Seller has a very well known brand so I couldn’t rely on images to grab the user’s attention. For the next iteration, I explored a stacked card layout. This tested much better so I moved forward with it.
Relationship Page Packages
Buyers can navigate to a specific Seller's relationship page and see all the packages they have on offer.
Cross-seller Packages
A stand-alone page that shows all packages available on the AppNexus platform. This view also include a filter functionality to search for a specific package.
Deals have enough information for Buyers to understand while still protecting Seller’s data.
Seller are very protective of their premium inventory and valuable data. Because they are packaging it up and exposing it to buyers, they can potentially be taken advantage of. If they reveal too many details about their information in a marketplace for anyone to see, they may end up arming their competitors with the information or worse, expose their information to be stolen. On the other hand, for a buyer to know which package to purchase, they need enough information about the inventory and data to make a decision. To solve for this, I explored several different designs.
A preview of the buyer view for the seller to see would give them confidence that their information isn’t being compromised while still including it in the package.
A toggle to set settings as visible or not during the package creation workflow would give the seller control over what information they want to appear in the details of the package.
A description field for the seller to explain what’s included in the package while tags gave a general spec of the package contents. Tags also gave buyers a quick way to filter and browse packages.
With the help of a UX Researcher, I conducted several usability tests with each of these approaches. The buyer preview had positive results but would only be used as a confirmation of what was being shown. It would be preferable if the seller could understand what would be revealed as they were creating the package. The visibility toggle approach would solve for this except it hid too much information for the buyer to understand the contents of the package. Tags helped with this however I wanted to take it a step further
Fitting it All Together
The new packages and marketplace had to fit seamlessly into the already existing product and the deals workflow. I initially wanted to keep the workflow simple and reusing the marketplace as a way for Sellers to view their own packages. To edit, create, or manage packages, they would be taken to a different experience. To communicate my thoughts, I put together a diagram to show the access and transition points for both buyers and sellers.
After running a usability test on this workflow, I learned that users who do both buying and selling were really confused by this workflow. They were unsure if they were looking at their own packages in a public view or if they were seeing something private.
I searched around for other products that use the marketplace concept and became inspired by iTunes and how it’s designed where a user’s personal library has a different experience from the iTunes store. I reimagined a Seller’s package offerings as a parallel to an iTune user’s personal collection. When the user switches into buying mode, they could go to the marketplace similar to the iTunes store. I fleshed out the idea and got a feel for it by building a prototype using FramerJS. After retesting this concept with good results, the workflow made sense and all the pieces fit together intuitively.
see prototype(expected to only work in Safari)

Case Studies

Please enter a password to access all of my UX work

Please enter the correct password

Don't have a password? Email me to get access!