Streamly
A creator-facing dashboard rebuilt around what streamers need while live.
Role
Sole Product Designer
Platform
Web
Status
Approved for Development
Note: Streamly is a placeholder name. To respect confidentiality, the platform’s name and content have been replaced, while the layout and design decisions reflect the original work.
The Challenge
Streamers used the dashboard to go live and run their stream in real time, but the tool worked against them at both stages. Before going live, they had to click through a series of modal windows. Once live, critical actions were buried in menus, audience information was hard to read at a glance, and stats competed for space with what needed attention right away.
Streamer feedback kept pointing to the same friction, and the product team flagged it independently. The goal was to get streamers live faster and rebuild the live view around one question: what does a streamer need to see, and in what order, while live?
Starting With What Users Know
For a proactive offer to feel natural, it has to arrive inside something users already understand. A new or unusual interface would make every offer feel like an interruption.
I built the experience on a familiar messaging layout: conversations on the left, the open chat on the right, the message field at the bottom. Users don't need to learn anything new.
Offering Visuals Without Being Asked
The companion follows the conversation, and when it spots a moment where a visual would help, it creates one on its own, without waiting to be asked. The offer has to show its value without giving everything away.
Visuals arrive in the chat blurred, with a lock, a short title, and the price. The blur hides the details but keeps enough color and shape to show what's inside, so the user can decide if it's worth opening. The companion then continues the conversation naturally, without pushing for the unlock.
Clear Prices, One-Tap Unlocks
If something costs credits, users should know before they act. Hidden or surprise costs are what make an offer feel pushy.
Conversations stay free; only premium visuals cost credits, and the price is shown on every locked visual before the user taps. Unlocking takes one tap: credits are spent and the image or video opens right in the chat. The balance in the header updates right away, so users always know where they stand. If the balance is too low, a system message explains why the visual didn’t open, and the Buy Credits button stays visible in the header.
System Messages That Stay Out of the Conversation
Some messages don't come from the companion: credits being added, running out of credits, or a companion being temporarily unavailable. Mixing these into the companion's voice would take away its personality.
I designed system messages as centered bubbles with their own color and label, clearly separate from the conversation, so users can tell at a glance when it's the app talking, not the companion.
Designed for Mobile
A companion is part of someone's day, a conversation they pick up between other things. That's usually on a phone, so mobile couldn't be a scaled-down version of the desktop app.
I designed it with the same priorities as desktop: the conversation comes first, and offers arrive right in the chat, with the same locked visuals and one-tap unlock, so the experience works the same way on every device.
Where This Started
The interaction patterns in this concept come from a messaging feature I designed and shipped for a commercial platform. There, creators could only earn while they were online. Paid messages and locked media gave them a way to keep earning between sessions.
I owned the experience end to end, from the first flows to the final UI on desktop and mobile, working remotely from Prague with the developers and product owner in Los Angeles. Users adopted the feature, and it became an additional source of revenue.
Reflection
This project was about making a paid offer feel like part of a conversation, not an interruption. In the original, creators shared things when it felt right. The concept asks the AI to do the same, and to know when not to.
With more time, I’d test how often a companion can offer visuals before it starts to feel pushy, and make it easy for users to tell the companion they don’t want visual offers at all. I’d also add a Buy Credits action directly to the “not enough credits” message, so users can top up right where they hit the limit.
