CASE STUDY

CASE STUDY

Stage TEN Live Player

Stage TEN Live Player

Stage TEN Live Player

B2B2C

B2B2C

eCommerce

eCommerce

Redesign

Redesign

/CONTEXT

/CONTEXT

/CONTEXT

redefining the Live Player

When I joined the team, Stage TEN’s browser-based live player for Shopify storefront visitors was scoped as a small fix, even though the experience itself lacked clarity, trust, and immersion for livestream viewers deciding whether to keep watching or buy. I aligned with a PM and engineers, using product audit, analytics review, and competitor analysis to show that viewers struggled to understand context mid-stream, which made the existing player feel fragmented and hard to trust. By the end of the project, from a patchwork player with unclear focus, it became a content-first live player foundation, enabling stronger engagement and increasing checkout entry from about 8% to about 14%.

50

100

150

200

250

300

350

400

450

500

50

100

150

200

250

300

350

400

450

500

/SOLUTION

/SOLUTION

/SOLUTION

01

a more immersive, flexible Live Player

The original player assumed viewers would watch, chat, and shop all at once, which fragmented attention and left large parts of the interface feeling empty or distracting. Through research and audits, I realized viewers rarely multitask intentionally. I redesigned the layout to make video the clear focal point and turned chat and shopping into focused, switchable modes, creating a more immersive experience that builds clarity and trust instead of cognitive overload.

02

full-screen entry with persistent mini-player

We introduced full-screen entry on desktop and mobile to remove storefront distractions and help viewers fully engage with live content. In parallel, we implemented a mini-player mode so the stream remains visible while users continue browsing the page.

This dual-state design acknowledges that viewers do not consume live commerce in a linear way. They move between focus and exploration, and the experience now supports both without breaking continuity.

03

trust over control: leveraging Shopify checkout

Early in the redesign, we recognized that trust was a major drop-off point in the purchase funnel. Rather than investing limited engineering bandwidth into building and maintaining our own checkout flow, we made a deliberate decision to redirect viewers to the merchant’s native Shopify checkout.

This allowed us to reduce perceived risk immediately, align with familiar purchasing patterns, and focus our resources on strengthening the live experience itself. Instead of reinventing infrastructure, we leaned into an existing ecosystem users already trusted.

/PROJECT HIGHLIGHT

Why Reinventing Checkout Was the Real Risk

I’ll never forget proposing we stop building our own checkout - something that felt like quitting halfway, until the data and constraints made it obvious.

Midway through the live-player redesign, analytics showed checkout entry was only ~8%, and I worried our custom flow was eroding trust at the exact decision point. Instead of polishing another in-house stepper, I proposed routing buyers into the merchant’s native Shopify checkout, arguing we’d gain credibility and move faster while staying inside existing APIs and components. After launch, checkout entry rose from ~8% to ~14%, and stakeholders called it a healthier lift because it removed hesitation rather than nudging clicks; it reinforced my rule: when user trust is the bottleneck, simplify the mechanism before you decorate the interface.

I’ll never forget proposing we stop building our own checkout - something that felt like quitting halfway, until the data and constraints made it obvious.

Midway through the live-player redesign, analytics showed checkout entry was only ~8%, and I worried our custom flow was eroding trust at the exact decision point. Instead of polishing another in-house stepper, I proposed routing buyers into the merchant’s native Shopify checkout, arguing we’d gain credibility and move faster while staying inside existing APIs and components. After launch, checkout entry rose from ~8% to ~14%, and stakeholders called it a healthier lift because it removed hesitation rather than nudging clicks; it reinforced my rule: when user trust is the bottleneck, simplify the mechanism before you decorate the interface.

I’ll never forget proposing we stop building our own checkout - something that felt like quitting halfway, until the data and constraints made it obvious.

Midway through the live-player redesign, analytics showed checkout entry was only ~8%, and I worried our custom flow was eroding trust at the exact decision point. Instead of polishing another in-house stepper, I proposed routing buyers into the merchant’s native Shopify checkout, arguing we’d gain credibility and move faster while staying inside existing APIs and components. After launch, checkout entry rose from ~8% to ~14%, and stakeholders called it a healthier lift because it removed hesitation rather than nudging clicks; it reinforced my rule: when user trust is the bottleneck, simplify the mechanism before you decorate the interface.

/MY ROLE

/MY ROLE

/MY ROLE

Led the strategic reset of the live player from initial audit and problem reframing through content-first UX redesign, cross-functional alignment, engineering handoff, and post-launch validation.

DURATION

8 WEEKS

DURATION

8 WEEKS

DURATION

8 WEEKS

TEAM

2 Developers, 1 Product Manager

TEAM

2 Developers, 1 Product Manager

TEAM

2 Developers, 1 Product Manager

TOOLS

Figma, FigJam, ChatGPT, Notion

TOOLS

Figma, FigJam, ChatGPT, Notion

TOOLS

Figma, FigJam, ChatGPT, Notion

50

100

150

200

250

300

350

400

450

500

/STORYTIME

/STORYTIME

/STORYTIME

Fixing symptoms is easy.
Reframing the problem was the real work.

Scheduling was planning, not setup

01

what looked like a fix was a misdiagnosis

Kickoff meeting

PRD review

Stakeholder Alignment

Problem Reframing

When this project started, the team entered kickoff aligned on a narrow plan to patch an existing Live Player issue defined in the PRD. As I reviewed the requirements and listened to early stakeholder framing, I realized we were fixing a visible symptom rather than addressing why viewers lacked clarity and confidence while watching live shows, so I prepared and pitched an alternative direction focused on the viewer experience as the root problem. Through discussion and iteration, the team agreed to pivot toward this reframed problem, expanding the scope from a small fix to a viewer-centered Live Player redesign within the same technical and timeline constraints. I learned that reframing the problem early is a leadership act—it determines what work is even worth doing.

02

owning the direction meant owning the decisions

Cross-functional Alignment

Design Iterations

Once the team aligned on the new direction I proposed, I naturally took on responsibility for leading the work forward with my PM’s support. I drove design iterations and alignment across design, engineering, and product, making judgment calls about what the new Live Player needed to prioritize under real constraints—such as unifying desktop and mobile structures and simplifying how viewers switch between chat and products. These decisions kept the team focused on the core experience rather than expanding scope prematurely. I realized that pitching a direction is only half the job; earning trust means consistently making decisions that honor that direction.

03

design quality depends on delivery

Design Handoff

Walkthrough Meeting

Documentation

Design QA

As the project moved into handoff, I treated delivery as a continuation of ownership rather than a hand-off point. I led walkthrough meetings with engineering, clarified how to navigate the design files, and adjusted documentation so implementation could follow the intended experience without confusion. This helped reduce back-and-forth and kept execution aligned with the direction we had agreed on earlier. I learned that real impact isn’t just setting direction—it’s staying accountable for it through delivery.