Ignite: The Amazon Advertising Manager
Ignite is a platform like Google Adwords for Amazon. It helps you grasp your campaign data and optimize your advertising through advanced filtering and a machine learning suggestion engine.
Site to Sign Up for the App
(must have an Amazon Seller Account)
NOTE: I have omitted and obfuscated confidential information on this page to comply with my non-disclosure agreement, and the content does not necessarily reflect the views of Seller Labs.
Please do not share this password with anyone outside of the hiring process.
THE CONTEXT
Jumping into a moving vehicle.
This project had a bumpy journey, and I got to wear many hats. This case study is the story of a successful MVP and a misguided redesign, and all that I learned in between.
MY ROLE
Design hand on MVP
After it was decided that we would do a redesign of the project, I assisted a lead designer on the project for a few months, and then I became design lead and sole designer of this product for the remaining 6 months. I functioned as part-product manager and part-designer on a Scrum team that then changed ownership 3 times as the scope and nature of the project changed. I work on everything from user stories, to detailed product designs, QA, and user testing.
We validated the concept with a messy Minimum Viable Product roughly 1 year ago.
The technical founder of Seller Labs built a messy Minimum Viable Product to test his ideas for an advertising platform using a bootstrap template and an Amazon API in just a month. I assisted him by creating patterns, user flows, and researching competitor software. We personally onboarded the first batch of customers and had feedback sessions to see they were using the tool. He released features weekly, and supported the small group of beta testers himself.
THE INITIAL CHALLENGE
How might we help sellers make sense of their Amazon advertising data?
Mastering advertising is critical to a seller's survival, yet many are new to online advertising.
Amazon's internal advertising platform is lacking in two ways.
1. The interface is limiting, requiring users to create and download reports in order to slice data -- making changes and strategies a series of downloads and uploads and a lot of data to keep track of over time.
2. Sellers do not trust Amazon (their main competitor) to use machine learning and automation to optimize their campaigns and prefer to use third-party software to manage more sensitive parts of their businesses.
Our first version of the product focused on three major features:
-
Consolidated data,
rather than multiple report downloads
-
Campaign optimization suggestions
fueled by machine learning algorithms that create
-
Historical Performance charts
for projections and strategy improvements
It was in good enough shape to learn a great deal from -- our early adopters were sold on it and our customer base readily received it, even though its confusing interface and lack of educational materials created a steep learning curve. Over the past year, the successful market reception led us to ask questions about what needed to change in order to create a more sustainable application that could scale to fit into our product offering.
We wanted to answer questions like:
Do sellers care more about seeing all their campaign data in one place.... or help creating campaigns in the first place?
Are sellers willing to trust us and take optimization suggestions...or do they want the flexibility to execute their own strategies?
What types of seller is actively looking for advertising software? Beginners who desparately need help or experts who want to automate their strategies?
We even began selling managed services where one of our employees acted as a conceirge, testing out the concept of completely automating the software. This too was met with open arms and created a great learning opportunity and a direct channel to a potential target customer.
Based on this reception, we knew we needed to make our tool more flexible, user-friendly, and sustainable so that we could offer a trustworthy, intuitive experience to larger advertisers.
We set out to rebuild the tool as an app that agency advertisers could use to create and manage their campaigns at scale. We chose a complete front-end redesign primarily because of tech debt, developer resources, and limitations of the front-end template used to test the concept.
In summary, we validated a lot of assumptions and were able to distill the main problems we could solve and a target customer for each:
-
Beginner-to-Intermediate Sellers wanted suggestions.
Turns out, they were completely open to trusting our software to make recommendations to their campaigns and were eager for more assistance.
-
Experts and multi-brand managers wanted Bulk Actions. Seeing their data in one place exacerbated the need to execute a strategy at scale.
Additionally, we had several agencies and consultants struggling to manage multiple brands, seeking us out to build an enterprise-supported tool.
THE OPPORTUNITY TO REDESIGN
How might we help Amazon advertising agencies run more effective ads more efficiently?
OUR LONG TERM GOAL
Simplify the steps to minimize the time it takes for consultancies and agencies to execute their strategies at scale.
Goals of the Redesign:
The redesign would involve us going through every single pattern in all the consoles, understand the current use cases and also the future use cases. As such, we had multiple small goals to achieve:
-
Define the types of patterns for the future
-
Build a backlog of UI components to be updated
-
Recommendations for projects that need components before they're developed
DISCOVERY
Customer & Market Insights
We built our software specifically for the advanced PPC expert who feels overwhelmed by the time spent micro-managing advertising campaigns and reports need to automate their bid adjustments and keyword workflows but is limited by Amazon's advertising platform.
What did we need to learn?
What the MVP told us
-
The ability to see real-time data and stop downloading in reports was drastically speeding up campaign optimization.
-
The majority of our beta testers relied on suggestions and our recommendations rather than trying to become PPC experts.
What we assumed
-
Making the interface more intuitive was the highest impact change we could make.
-
Bulk Actions and consolidated data views would be the best way to assist our sellers with educating their strategies quickly.
What we didn't know
-
Was an interface inspired by AdWords & Excel going to alienate true beginners and less tech-savvy customers?
-
Which features could we cut from the old application for the redesign?
(We had done a poor job with metrics & tracking)
GATHERING INFORMATION
Analyzing Competition & Common Tasks
About 5 main competitors, serving different customer types. Looked at how our offering stacked up, noted weaknesses in onboarding, features, etc.
Conducting User Interviews
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam.
Reading Support Tickets
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam.
KEY THEMES
The customers who weren't finding value in our product were depending on our Suggestions feature.
Our MVP set out to help advertising newbies understand their data more, but it might have made it more complicated. We were displaying more data, with more controls than Amazon.
If a seller didn't know anything about Amazon ads,
our software wasn't making it easier.
Our MVP set out to help advertising newbies understand their data more, but it might have made it more complicated. We were displaying more data, with more controls than Amazon.
AGENCIES
Our primary customer type was agencies managing multiple vendor accounts. The redesign would allow them to view their accounts data all together
BEGINNERS
Our advanced suggestions and automation would be even simpler to use and apply.
POWER ADVERTISERS
Our bulk actions would make applying tried-and-true strategies easy to save time for other parts of their businesses.
WRITING REQUIREMENTS & USER STORIES
Reverting to Waterfall and Fixed Deadlines
Detailed requirements were the center of our project, mostly spelled out by our first agency contract. For the first time, we had a client dictating needs on paper and we had promised to deliver. This was new territory for us as we suddenly had an outside party defining (and re-defining) what features and requirements meant and deadlines that put pressure on the team to deliver.
I was able to help narrow the scope by providing visuals to our ideas and to figure out which things we could put off until a second release and complete manually for the first few agency customers, allowing us to prioritize actual features they could start using.
This is a sketch I created while working with the project manager as he described a new account tenancy structure to fit what the client wanted.
By visualizing all of the actions needed to complete the process of adding a new account, we were able to decide to cut costs and time by creating only the backend and manually doing the rest by asking for a list of their accounts and users to onboard them ourselves.
This way we could wait until we knew this was worth building before adding all of the many flows and modals necessary for them to add new accounts themselves.
Credit: User Story Mapping
"Working backward from a fixed launch date meant that design was subsumed into an engineering‐driven process. Sign‐off milestones were driven by engineering estimates and time to create the right design was the time left over. The combination of a fixed launch date and aggressive scope created an intense environment with many coordination and time challenges."
DESIGNING USER FLOWS
Telling Stories with Requirements
At its most fundamental level, our product allows you to:
1. View a lot of data at once.
2. Use filters and visual charts to make decisions.
3. Take a set of actions either on a single item or in bulk.
It was key to understand all of the different actions users could take on table data and create a seamless, expected experience each time. The flow shown above applies to almost every bulk action a user can take in our app, and creating templates for this flow saved me and developers a lot of time.
Prototyping with wireframes for each of these steps helped us understand if the steps make sense and feel right together. With limited resources to do external user testing, low-fidelity prototypes with employees in the office often gave us enough information to move forward.
FEATURE PRIORITIZATION FOR THE REDESIGN
What is the minimum we can launch without disrupting the productivity of existing users?
Now that the concept had been validated through the MVP, we had to juggle (1) validated concepts and pages that customers were using, (2) New feature requests, and (3) design and tech debt. There were some pieces of the old application that didn't need to be built into the new one, and we had a ton of feedback from customers to prioritize. I use Cardboard.it and user story mapping exercises to visualize with a product manager what we'd built for the first release, constantly re-evaluating whether more needs to be taken out.
Our redesign of the product focused on three major features:
-
Even more data all in one place, streamlining workflows and strategies applied across campaigns at scale.
-
Campaign Suggestions algorithms for improving campaign strategies
-
Historical Performance charts for projections and strategy improvements
EXPLORATION
Using Wireframes to Groom Stories
I created low-fidelity wireframes that I used when planning sprints or firming up the details of user stories with the product manager. I'd sit down with a customer, engineer, or marketing to get feedback on the wireframes, iterating on the wireframes during our discussion.
After the collection has been created, and the collaborator has been
After the collection has been created, and the collaborator has been invited, the collaborator receives an email invitation that provides a link to get their account setup and provides them access to the collection.
THE FRAMEWORK
Creating reusable components and establishing patterns
Our redesign was essentially a second MVP. We validated the concept, but the redesigned product still had to go through rigorous prioritizing and take a very finite amount of time to build. One of the important design deicsions on my plate was to limit the work our front-end devlopers were doing. This meant creating page templates that looked and interacted very similarly. I basically created two page types:
1. a Dashboard - for looking at top level stats and clicking into the main categories.
2. a Datatable - for looking at a lot of data at once and taking action on it.
We build a reusable React table component and a simple card-based dashboard layout that allowed us to create the skeleton of our app quickly.