Building an API-based product distribution platform

Team

Year

2020

Founding Product Designer

Julien Nguyen

Head of Engineering

Brian Presley

Lead Engineer

Chandler Thompson

Duration

6 Months

Front-End Engineer

Chelsea Lura

Back-End Engineer

Marco Pineda

CEO

Ayman Abdullah

Overview

AppSumo is a dual sided SaaS-based marketplace based in Austin, TX that provides entrepreneurs and small to medium-sized companies discounted software deals to help them grow their business.

As the sole designer at the company, my challenge for this project was to provide a complimentary user experience for a new product distribution platform that would support the company's transition from flash sales to a true SaaS-based marketplace.

The outcome of this new design was successful on multiple fronts: customers appreciated the simplicity, speed, and ease of use of quickly activating and managing their purchased product; internal staff spent significant less time resolving product management issues; and partners appreciated the security, speed, and transparency that the improved distribution model provided.

Background

AppSumo's core business involved partnering with software makers to resell their products on the AppSumo website. Product distribution involved partners sending alphanumeric codes to AppSumo via email. We then tested and validated each code, creating activation instructions for customers. Approved codes were entered into our inventory database, and customers received both a code and activation instructions upon purchase for access on the partner's website.

As this was a very manual and multi-step process, the cracks of this distribution model and process quickly began to show when launching and selling multiple products.

Existing challenges

  • The activation process could vary greatly between one product to another (especially in consideration to a company's resources and/or method of implementation), creating confusion and frustration for customers.

  • Testing and validating product codes was time intensive to validate between AppSumo and its partners. Initial delivery of codes were often found to be 25-33% defective due to incorrect formatting.

  • Fraudulent individuals could "refund and resell" products purchased via codes due to lack of auditing active and inactive codebases, creating corruption and confusion within the market.

  • The only way to provide more features for a given product (e.g. basic, standard, deluxe editions) involved purchasing multiple codes of the same product, called stacking, which was complicated for new customers to understand.

  • Since activation was a separate process between the customer and partner, AppSumo had no confirmation or digital breadcrumb as to whether customers actually activated their purchases, hindering our ability to provide relevant product management options.

  • Select actions (such as upgrading and downgrading) were not currently available on the product management page. These types of requests or refunds were resolved through lengthy customer email exchanges with our support teams.

During a company retreat, I had a discussion with the Head of Engineering about the challenges we were facing with using a code-based distribution model coupled with an ambitious revenue forecast for the following year. We knew that given the problems we faced, using codes was unscalable for our needs and improvements on the existing distribution model were moot.

Despite our unique business of selling business/SaaS software, our conversation quickly gravitated to comparative marketplace examples like Steam and Epic Games that shared many common themes and requested features.

What if we could leverage APIs as a distribution platform to accommodate scale and growth for the company?

Goals

While the Head of Engineering was busy determining the feasibility of implementing APIs from our end, I worked on creating some concepts to help illustrate a world with APIs and the benefits that our business could quickly capitalize on with this platform.

Proposals included: a restructured PDP page that supports content segmentation, including a pricing section; more robust account managing experience with simpler IA with embedded search, filter, and actions. Concept UI elements, colors, fonts, and graphics were also utilized to help delineate concept work from "day-to-day deliverables" for stakeholders.

Once we discovered that it was within our reach to build out an API framework that could directly "talk" to our partners, we pitch our proposal to our CEO which was immediately embraced.

We then laid out the groundwork of what we wanted to achieve for this first release. The design goals to support this API initiative was broken down as the following top priority items:

What we focused on
What we measured

  • Lower customer success tickets regarding activation

Contributions

Information Architecture

I then took the next step to outline all the permutations and flows that would encompass these layouts. I also had to keep in mind that these flows had to co-exist with code-based processes, as the API framework would be gradually introduced on the partner end over time.

1. Products Actions Journey-user flows based on each product-based action;2. Products Actions Eligibility-customer action eligibility;3. Figma Deliverables-broad overview of variations, states, and flows created for this project

My Products

I decided to rehaul our existing "My Products" dashboard to better align with our API intiatives. Actions for each product (ex: Activate, refund, etc.) would be determined and shown by eligibility, rather than requiring customers to contact staff for additional actions. I also made sure that our designs were responsive, especially as the existing solution lacked a mobile-friendly experience.

We had several internal discussions as to what information we wanted to expose on the table. Through multiple iterations, we decided to focus on activation status, product type (ex: API or code-based), and refund date. The refund date is particularly important to note, as this date was directly correlated to whether or a user could upgrade and downgrade. As we didn't have any site-wide notification system in place it was incumbent on the customer to be aware of this deadline.

Additional pages such as checkout were also revised to support product differentiation between API and legacy products.

1. My Products Dashboard: Desktop2. Select Dropdown Variations-(left to right) API-based selections, code-based selections, transferred API-based selections, hover state;3. My Products Dashboard: Mobile;4. My Cart Variations

Activation

AppSumo required all customers to "redeem" or "activate" their purchased products before usage. For code-based activations, a customer had to: navigate to the "My Products" dashboard, select their given product, and navigate to the product profile page. The product profile page hosted the code, activation link to the partner, and any activation instructions needed to complete this task.

For this API initiative, I wanted all product-related actions (including activation) to be available and completed on the 'My Products' page. The product profile page primarily contained activation and refund instructions, and by pulling those actions out made the page feel rather empty. By implementing these actions on the dashboard page the process for customers to make their selection should feel quick, dynamic, and seamless.

Unfortunately, significant back-end constraints limited this intended direction for this release. As all current task-based actions (activating, refunding, etc.) resided on the product profile page, we decided instead to redirect the available selections from the 'My Products' dashboard to the specific section within the product profile page via anchor links. This compromise allowed users to still view and access the requested action from the intended "My Products" page while also allowing our dev teams to successfully release a working user flow.

1. Activation Variations-(left to right) API, Code-based;2. Activation Modals3. Activation-Mobile flow

Actions

Additional actions such as refund, upgrade/downgrade, and transferring were also productized in simple-to-follow flows, reducing the need for customers to engage with AppSumo's support teams.

1. Overview2. Change Plans-selecting a tier;3. Change Plans-selecting a payment;4. Refund Product5. Actions Overview Variations

Results

Despite limited research opportunities I did succeed in collaborating with several of AppSumo's top customers (via Zoom/Slack sessions) to gauge preliminary feedback and reactions. Although these customers were biased, it was good to see if our existing customers could notice any improvement on the activation process.

“ Wow! That was it? ”

Activation flow customer feedback

Coordinating a strategic roll out (i.e. drip release vs. control) using several top rated products , we were able to quickly identify an approximate 70% reduction in customer activation support tickets for API products compared to code-based products within the first month of release.

For partners, we also saw a considerable decrease in efforts to get them properly onboarded and ready for product launch on our website.

Reflections

We felt that this was a great first step forward towards accomplishing this wider intiative, especially since many of the earlier deliverables for this project were revised based on scope, bandwidth, and back-end constraints. We also identified many other challenges to focus on for later, such as:

  • How we could leverage this API model for partners that do not have bandwidth, expertise, or resources to implement this on their back-end.

  • Providing a templatized framework for activations that require additional account setup by the customer on the partner website.

  • Navigating through the gradual transition between a code-based and API delivery model.

  • Incorporate required registration information within the activation flow to reduce need to redirect customers to the partner's website to complete setup.