Creatives
Redesigning a complex workflow for uploading creatives
About the Project
Creatives in the AdTech industry refer to the actual advertisement that is shown to internet users. They can come in many different formats such as images, videos, mini websites, and others. The original creative upload workflow on the AppNexus platform was designed to support only simple image creative types. As the industry became more sophisticated, the workflow didn't scale with it. I was asked to lead the redesign and improve the workflow. To do this I:
  • Observed users uploading many different types of creatives.
  • Worked with engineers to understand the complicated mechanics of how a creative is served.
  • Paid attention to animations and transitions to create an emotional experience.
  • Ran an anlytics study to gather data and learn how users were behaving.
  • Ran a project to gather qualitative feedback during a beta phase.
My Role
As the lead designer on the project my responsibilities included gathering product requirements, understanding the technical background, leading user research projects, and owning the design of the interface.
Tools
  • Discovery Studies
  • Maps & Flows
  • Wireframes
  • Prototypes
  • Usability Testing
  • Analytics
Background
Creatives, the advertisement that the end user see's and interacts with, tell the message that the brand is trying to communicate to consumers. Advertisers use this as a way to experiement and test various messages in different formats to learn what converts the most users at an optimal price. This makes the workflow a very important part of the platform, where AppNexus users spend a lot of time managing and uploading creatives.
The platform's initial patterns consisted of grids with panels and modal overlays for creating objects. Users were used to this, appreciated the quickness, and liked that they could see everything all on one screen at once. However, with the increasing demands of creative formats, the modal pattern became complex and filled with logic for the creative upload workflow. Specific issues I identified:
  • Making a simple selection in begining of the workflow caused subsequent important settings to hide or more settings to appear.
  • Similar fields weren't grouped together and the order of fields wasn't logical because they were added in later and not integrated properly.
  • The two-column layout and navigational tabs across the top made it difficult to know when the task was completed. The user would have to scan down the first column, then back to the top to the next column, and back to the top again to navigate to the next set of tasks.
Observational Studies
To get a good understanding of the many use cases that exist with creatives a Product Manager, an Engineer, a UX Researcher and I decided to conduct some observational studies. We sat next to the user and watched as they uploaded creatives into the existing UI. We discussed their painpoints and learned about their workflows including how they outsource some of this process to third-party vendors.
Painpoints
Uploading
  • Errors are difficult to troubleshoot.
  • There is a sense from users that their time could be better employed.
Outsourcing
  • Outsourcing services save time and relieves them of the mental bandwidth and burden placed on Traders.
  • Some Traders have a hard time trusting the outsourced service because it takes time to ramp them up.
Associating Creatives
  • Associateing creatives to campaigns is manual and tedious.
  • Takes too much time for what you're accomplishing.
Management
  • No bulk search capability
  • Resubmiting to audit takes to much time.
Workflows
Breaking Things Down
We knew we needed to break down the project into managable phases to design and build. Working with the Product Manager and an Engineering lead, we discussed the desired outcome of the project from each perspective.
Engineering Needs
  • Clean, readable code
  • Scalability
Product Needs
  • Enticing features to ensure adoption
  • Feature parity with competitors
User Needs
  • Quick time to complete task
  • Seamless integration with the rest of the workflow
The modal design in the original page meant the code to upload creatives was intertwined with the code to manage creatives. To start detangling this, we knew we needed to start with the upload workflow by building out a separate app.
Video ads were becoming a popular trend in advertising and were complicated in themselves. We knew we couldn't introduce their complexity into the current state of the UI but we could build them out in the new app.
Our plan, to start by redesigning the workflow to upload video ads that are hosted right on the AppNexus platform, meets the engineering, product, and user needs. To visualize how this would work, I diagramed out the functionality for video ads against the two apps we'd be working with.
To understand the bigger picture, I expanded the diagram to include all creative types (new and existing) that we want to support in the new workflow.
Layout Exploration
During the time of this redesign, the UX team was really focused on creating a consistent experience across all pages and tasks on the platform. I wanted to use our standard object creation pattern but realized it didn't accommodate all of the nuances that came with uploading creatives.
Using the requirements for video creatives, I first explored an iteration that matched our standard pattern. A single page with expandable and collapsable containers similar to the campaign creation page.
I continued exploring and sketched out a few different layouts and ideas that were consistent but accomodated the nuances of the creative workflow.
Requiring the user to upload their image or file first.
Vertical tabs for each section.
A file upload component at the top of the page.
An inbox style layout with existing creatives listed to the left while specific settings for a selected creative appears to the right.
A two column layout with a preview panel to the left.
The solution I decided to move forward with consisted of a combination of a few of these ideas for the following reasons:
  1. Having the user tell us what kind of creative they're uploading upfront keeps the IA intuitive and provides the user with only the specific settings that are necessary.
  2. Letting the user upload the asset first helps to guide the user and the workflow.
  3. The preview panel allows the user to always view information about the creative that the system generates.
  4. The pattern of containers with expandables for each section would be consistent and familiar to users.
    Validation
    To ensure the new workflow was intuitive, I created a prototype that included functionality that all creative types would require, the audit and tracking pixel sections. My goals for the test were to ensure that users:
    • understood why they should upload a file as the first action.
    • could easily reselect an image or video to upload.
    • could successfully save the creative.
    • noticed if there was an issue after uploading the file.

    see prototype (expected to only work on Chrome desktop)
    After running the test, I left with several take aways.
    • Uploading the file first was clear that it would tailor the workflow
    • Users had trouble editing the asset because of the location of the edit button.
    • Users immediately started filling out the form on the right, dismissing anything that was happening on the left.
    • Moving the save button to the bottom right instead of the standard bottom left for create patterns was still discoverable.
    Using these takeaways, I updated the designs and the team began building the UI while I began preparing to design for each specific creative type.
    Migrating Creative Types
    Video
    Native
    AppNexus wanted to start supporting hosted video creatives (where users can upload a video file and host it on the platform) while continuing to support the existing method (where users enter a URL that points to a video file hosted on another platform). My challenge was to support both use cases with their own nuances while keeping the UI simple and to help guide the user to succesfully traffic a video creative.
    My plan, after the user specifies their creative type, is to split the workflow into two paths; whether they are uploading a file, or entering a URL. For this I explored several ways to control the input method and ultimately decided to move forward with a toggle approach because of its flexibility for future creative type needs.
    The hosted video creative type was fairly straight forward but the third-party hosted creatives had several challenges. Video creatives are traficked through an XML file which specifies details such as the landing page URL, tracking information, additional video sizes and file types, and many other things. Several of these are required for the video to serve properly so users who host the files in one platform and traffic it in another have a lot of troubleshooting issues. Users hosting the file in the same platform can update their settings in one place while those hosting separately will have to request the fix to the person they received the creative from.
    I had designed a validator in the previous UI that allows the user to parse the XML file for the required or recommended attributes. We had recieved positive feedback on this so I knew this would be included in the new UI. I had set up the new workflow to show a preview on the left with settings for the creative on the right. I wanted to use this as an opportunity to set up a pattern where information about the asset appears on the left preview panel while settings the user must provide a value for appears on the right. This means the validator would be placed in the preview panel.
    Publishers who want to have the most control over what goes on their site will use Native creatives. They specify the look and feel of the advertisement so it blends in with the page's content. Advertisers just need to provide assets like the image and text that goes along with it. In the programatic world, this gets tricky for the following reasons:
    • Advertiser must upload all of the appropriate assets and meet the publisher's requirements.
    • Advertisers looking to buy as much as they can may not know or understand the requirements for all publishers.
    • Some users may only care about one specific publisher's requirements or none at all if they are the publisher themselves, uploading advertisements to serve on their own site.
    The product manager set one main goal for this redesign.
    Guide users to upload the right assets to serve on as many publishers as possible while keeping it flexible for users who know what they are serving on.
    I started by looking at the requirements for the sellers that AppNexus supported at the time. I put together a matrix to see where they overlapped and began sketching ideas.
    An early on idea I had was to guide users to include assets that meet the overlap of seller requirements. Similar to a password strength indicator, this indicates how likely a seller will accept the asset. In addition to this indicator, I explored a seller validation design similar to the XML validator I mentioned above. This would tell the user if they are meeting specific seller requirements.
    Another idea I had was to let the user enter multiple values for one asset. This way, for any given seller, there is a value that will meet their requirement. For example, the title field can accept a small, medium, and/or large version.
    After sketching a bit, I realized I didn't understand how users recieved or executed native creatives so I decided to conduct user research to find out. Working with a User Researcher, we put together a list of questions like "What format do you receive native assets in?", "How do you know which seller you want to serve on?", and "How often do you upload native creatives?". The learnings were enlightening.
    • They created many different combinations of text and image to determine which one performed best.
    • They may receive assets as a zip file or as an attachment in an email. Text could be found in a spreadsheet or directly as the body text in an email.
    • They generally knew which seller requirements they needed to meet but would like to be able to serve on more if the upload process was easier.
    • They craved more validation to help them understand what they should be doing.
    Using this information I was able to find a solution that included aspects of both directions. Providing immediate validation as the user types into the field with information about what seller they're meeting. If the user is not meeting a desired seller's requirements, they have the option to add an additional field.
    After designing more the interaction details, the layout changed quite a bit in the next iteration. I moved the validations into a panel on the right so that users can still see it when they're previewing the creative and more easily scan the requirements in an expected location.
    Tracking Metrics
    I wanted to make sure the investment we were putting in to redsigning the workflow was worth it and that we were actually making improvements. I came up with a plan to utilize event tracking and Intercom (a new system the UX team started using which lets us communicate with users based on their activity. I broke it down into 3 objectives:
    Objective 1: Establish benchmarked metrics and measure it over time
    Establish consistent metrics to understand whether designs are improving (or not improving) over time. Using the SUM calculation, gather task completion, task efficiency (errors), task time, and user satisfaction metrics.
    Objective 2: Understand specific user behavior in the new UI'
    Understand how users work through the new UI, what areas are confusing and what trips the most errors.
    Objective 3: Recruit actual users for Allies and contextual inquiry interviews.
    After specific events triggered, ask users to opt into the research program for further learnings.
    Some of the events could be utilized for multiple objectives so I had to list out all of the events that we would need to track and where the data should be sent to. At the time, we were using two different systems that could ingest this data: Intercom (a way to communicate with users based on a specified event) and New Relic (a data visualization platform). I tought myself both systems with New Relic requiring the knowledge of SQL language.
    Events
    Time from users loading UI to successfully saving creative
    • Broken out by creative type.
    API error appears after saving creative
    • Error reason
    • Creative type
    UI errors
    • Error reason & field
    • Creative type
    • # per pageload
    When user clicks on input
    • Field name
    When users cancel out of the workflow
    • Interaction time from page load.
    • Broken out by creative type
    • Last input clicked
    • If any error appeared (UI and API)
    When user successfully saves a creative
    After launching the events and turning on the messaging in Intercom for the old UI, we began seeing results. We learned that users were generally happy with the old workflow but were tripping a lot of errors. Their task times were relatively low but at this point, we could not directly compare the task time from the old UI to the new UI since a lot of features were not built yet. The old UI would inevitably take longer.

    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!