Selling in the gaps with Playlists, Consensus’s first multi-demo experience.

role

platform

Lead Designer

Desktop / Mobile

Research

Usability testing

Prototyping

company

timeline

Consensus

Q4 2022 - Q4 2023

overview

Consensus helps sales teams share product demos with potential buyers. However, sales reps were limited to sending one demo link at a time and had no good way to manage who watched what, which made tracking engagement a real bummer.

The goal of our solution was to give reps a way to bundle demos into a single sharable link that buyers could explore at their own pace and eventually sharing demos with others in the buying group. I led research and design initiatives for the buyer-facing demo player experience.

highlights

Led research and discovery initiatives

Identified gaps between how sales teams worked and how the platform supported them.

Designed a cohesive buyer journey

Delivered a scalable demo experience adaptive to real-world sales conversations.

Balanced analytics with flexibility

Maintained engagement visibility while enabling multi-demo workflows.

research & discovery

To understand the full scope of the problem, I collaborated with our CS and sales teams and examined how demos were created, shared, and experienced across three perspectives: the seller, the buyer and the data.

The Seller

Sales reps were limited to one shareable link per demo. Throughout the sales cycle, demo content needed to be adjusted as deals evolve and new stakeholders get involved. Keeping track of who watched what demo and when they watched it quickly caused cognitive overload.

The Buyer

Buyers and stakeholders engaged with demos at different stages of the evaluation process. When multiple links are shared around the buying group, it often became the burden of the champion to relay feedback from from stakeholders back to the seller.

The Data

Engagement data was captured at the individual demo level but not across the full buyer journey. As multiple demos were shared, insights became harder to interpret, limiting their usefulness for guiding sales conversations.

Stuck on stand-by

Reps were losing momentum waiting for a demo to get passed between champion and stakeholders, stalling conversations.

Lost in the noise

As demos were shared, conversations became scattered and were harder for stakeholders to keep track.

Disconnected data

Key viewer insights were tied to individual demos, making it difficult to know how prospects engaged across the full buying journey.

How might we support sales conversations as they evolve across stakeholders, workflows, and stages of the buying process?

so, we asked ourselves…

design approach

I mapped out the parts of the app that the Playlist feature would affect—demo creation, email, analytics and the demo player. It had two distinct users: the seller creating, tracking and sharing the playlist, and the buyer watching and sharing content within the buying group.

The design solution had to support how sellers create and share a playlist, how engagement is tracked across multiple demos, and how buyers view and share the content

With a clearer picture of the product scope, I mapped the end-to-end workflow from when a seller starts building a playlist to the moment a buyer finishes watching it. The goal was to identify every point in the process where a design decision would need to be made, and where the experience could break down if we weren't careful.

key decisions

One link, not many

Before, sending multiple demos meant multiple links, and multiple links meant lost context for buyers and fragmented tracking data. Consolidating everything into a single shareable experience was the clearest way to minimize the changes for how reps already sent demos.

Working within the existing player

The demo player had recently been redesigned, leaving little room for new UI. That constraint focused the solution on the right panel, the one area of the player with room to work within.

To keep scope down even more, I only used front end, dev ready UI components to reduce the time developers would need to add them to their front end repository.

Preserving analytics

Demolytics was originally built around individual demos, tracking engagement per recipient, per feature, per view. Tracking multiple demos under one experience meant the solution had to keep individual demo analytics intact while giving sellers a view to easily understand how a buyer engaged across the full playlist.

Build once, reuse often

Sellers could simply add new or existing demos to a playlist that’s already circulating around the buying group, removing the need for sellers to create methods of tracking links outside of the Consensus app.

final solution

Demo Player

Up Next

Invite

outcome

The Playlists feature shipped and adoption was strong, now with 87% of all DemoBoards sent using the multi-demo Playlist feature.

But post-release feedback showed view rates started dropping as new stakeholders brought into the buying group weren’t discovering the “Now Playing” and “All Demos” tab.

Visually, the tab didn’t stand out enough in the top right corner of the screen. This contradicted the insights we got from user tests ran through usertesting.com. As a result, stakeholders weren’t discovering all the content in the playlist.

following up

The PM and I followed up on the feedback and put together a low cost design solution to the discoverability issue. I removed the “Now Playing” and “All Demos” tab at the top right and added them as similarly organized sections in the playlist and maintained the visual focus with highlighted features.

Unfortunately, we were unsuccessful in getting the improvement developed and released. Other projects for important clients had already been prioritized and it never made it on the road map—a story as old as time, as far as product development goes anyway.

reflection

We were surprised to learn the tabs' discoverability issue because we felt like we did our due diligence with standard research and discovery methods—consulting with internal users and validating designs and workflows with user tests (I used the app UserTesting). Naturally, we had some theories.

The obvious one is that internal users would notice any small change in the Demo Player UI because they spend a lot of time in that environment, making edits and reviewing a demo before sending it out.

Another theory is that the tasks and prompts for participants in the user test led them too much. Although, I got feedback from the Principle Designer and Director of Design prior to submitting the test. Plus, like most user tests, the first one usually reveals gaps and requires some tweaks. But maybe it was changes that caused a UX “butterfly effect” of sorts.

Most likely, it’s probably a bit of column A and a bit of column B. Product development is often a complicated and messy balancing act between users and business needs (and wants), and diplomacy doesn’t always win in your favor. Not being able follow through with a quick-fix, if even a temporary one, was a tough pill to swallow. But we moved on, wiser from the lessons learned, and continued to add value to the users experience with meaningful features.