Content discovery is a natural starting point for Stackla administrators joining a new Stack. This was an opportunity to redefine the first time user experience and also reconsider the user flow for existing administrators.

As the lead designer on this project, I was responsible for redefining the new Content Discovery experience for Stackla customers. The project ran between November 2018 to July 2019. I worked alongside the Product Director, a Back-end Developer, two Front-end Developers, and one QA Lead. The new Content Discovery feature launched in June 2019.

The Content Discovery entry point for first time users

The Content Discovery entry point for first time users


Due to rapid development in other areas of the Stackla product, the Content Discovery feature had fallen out of alignment with the overall product experience. Since content discovery is a natural starting point for all Stackla administrators who join a new Stack, this was an opportunity to reconsider the first time user experience for new Stackla administrators and reposition the advanced capabilities of content discovery for existing Stackla administrators.

The Challenge

Streamline. Showcase. Success

The goal for the project was to simplify the on-boarding process for all Stackla administrators who join a new Stack and effectively set new customers up for success.

High-level requirements

  1. Streamline the first time user experience around the setup of a new Stack and the creation of discovery terms.

  2. Showcase the advanced features around the discovery of more targeted content for existing users.

  3. Promote customer success via the discovery of smaller quantities of better quality user generated content.

Kick off

Mapping the journey

At the outset of the project I engaged the in-house Customer Success team to get a snapshot of the current customer onboarding process. This allowed me better understand how new Stackla administrators joined their Stack, their immediate goals, the actions that they typically perform to achieve them, and to also identify any patterns of behaviour for continued success.

I documented some of this information in a Customer Journey map that illustrated the core functions of the Stackla platform. Then I overlayed this with key customer motivations and sentiment at each step in the journey. This gave me a big-picture view of the customer journey and also allowed me to identify potential opportunities to better support the customer on their journey.

Some observations

  • A key requirement for setting up a new Stack, was for the Stack administrator to connect their social accounts to Stackla.

  • Many customer Stacks were setup by the Customer Success team (not by the customers themselves).

  • If a Stack was setup by the Customer Success team, the customer would subsequently need to disconnect the accounts connected by Stackla staff, then reconnect their own brand accounts.

  • A Stack administrator’s immediate goal upon joining a new Stack is often to aggregate their own brand’s content.


Asking questions and digging deeper

After a series of face to face interviews and remote conversations with existing customers and in-house teams, I was surprised to discover that Customer Success managers had often completed the entire on-boarding process on behalf of their customers. The general sentiment from the Customer Success team was that their customers would find it too difficult to do it themselves.

I discovered that the Stack setup process was highly repetitive, somewhat disjointed (bouncing between term creation and connecting social accounts) and required a reasonably steep learning curve in terms of understanding key concepts that are unique to Stackla.

Also, social account connection was a critical requirement, not just for initial content discovery, but also for leveraging other product features within Stackla.

The Problem

In order to understand the extent of some of the issues identified in the discovery phase, I questioned the data.

  • What was the average number of terms created per Stack? How big was this term creation problem?

  • How many different term types get created per Stack? How complex are customer’s discovery campaigns?

  • How many times was the same hashtag or keyword search used across different networks on a single Stack? How much repetition was there?

And to better understand customer behavior and potential markers for success, I asked:

  • What actions do the most successful customers perform during their initial onboarding? And how can we bake these actions into the first time user experience to setup new customers for success?

The Data

The data illustrated a strong case for enabling Stackla administrators to create multiple term types from multiple social networks all at once (effectively reducing current repetition around the first time user experience).

Querying the data to validate concerns around repetition and complexity

Querying the data to validate concerns around repetition and complexity

Also, after looking at success metrics in historical customer behaviour, it was evident that customers who went on to use additional product features throughout their lifecycle (including Rights management, browser plugins and team collaboration) were more likely to renew their annual subscription with Stackla.

And finally, existing Stackla administrators experience the same repetitive experience as first time users when launching subsequent content discovery campaigns.

The approach

A journey of a thousand miles…

A pipeline of over 80 existing product lifecycle tickets relating to the content discovery function in Stackla gave us a strong starting point for this project. I split these 80 tickets into 6 categories (including user experience, new feature requests, enterprise settings etc). Then I led a series of workshops involving the Product Director, Product Manager and CTO to plot each product lifecycle ticket on an "Effort vs Impact” matrix. This allowed us to identify the “low” to “medium” effort items that would deliver the highest impact to the customer.

Plotting existing feature requests on an Effort vs Impact matrix

Plotting existing feature requests on an Effort vs Impact matrix

In a follow up workshop, we merged the product lifecycle tickets plus the new product requirements into several user stories to form the basis of the overall project. Next, we brought the wider Product and Tech team together to use the “MoSCoW" method to prioritize each delivery requirement before using "Planning Poker” to estimate the scope of the project. Then it was time to start developing user flows based upon the user stories.

A sample of user stories that shaped the project scope

A sample of user stories that shaped the project scope

The Redesign

Armed with the knowledge and evidence that Stackla administrators wanted to quickly set up multiple content discovery terms and term types, for multiple social networks, for their brand accounts and related campaign hashtags - I began wireframing paths to facilitate this flow with minimal user input . At the same time I was also developing a seamless path to allow more advanced content discovery techniques for more mature customers.

The key goal was to set customers up for immediate success, but also give them the ability to ramp-up their usage of the Stackla product at the first appropriate opportunity. To achieve this, I proposed that we embed the Rights Management setup, plus calls to action to instal browser plugins, and the ability to invite team members into a Stack as part of the first time user experience.

Next, I kicked off the design phase

  • Refining the Quick-Start flow for first time users based on customer success measures

  • Defining the repeat-flow for existing users to create additional discovery terms

  • Continuing to flesh out the wireframes to cater for the full UI stack

  • Walking through the proposed customer flow with internal teams for buy-in

  • Transitioning to creating high-fidelity interface designs

  • Building clickable prototypes to facilitate internal and external testing

The Launch

A two-phase launch

The launch was split into two phases. The first time user experience, followed by the existing user experience. Many of the design patterns were intentionally re-used across both experiences. So releasing the new feature to first time users allowed us to drip release the new functionality into production while development continued on the functionality for existing users. And at the same time, monitor product usage.

After development of the second phase of the release came to an end, and a high level of confidence was reached for the new functionality, the remaining pieces were pushed into production.

The Results

Learnings and takeaways

General sentiment from the Customer Success team and customers alike was vastly positive. Furthermore, feedback from sales managers demonstrating the product in sales pitches was also positive. We are yet to query the data to analyze the new customer behaviour, however I’ll be looking to understand metrics such as:

  • Completion rate on the first-time user experience quick-start guide

  • Number of discovery terms created on initial Stack setup

  • Any shift in Customer Success behaviour around manually configuring customer Stacks

  • Any increase in installation (and usage) of the Chrome browser plugin

  • Any increase in Rights Management usage

  • And more long-term, any noteworthy changes to customer retention


Thanks for sticking it out to the end of this case study! If there are any other aspects of the Product Design process that you’d like to know more about please feel free to reach out to me. Distilling a 9 month project down to a single web page is a challenge - I’d much rather jump on a call or meet face to face to dive into the finer details that are relevant to you. Let’s talk!