Streamtime
2025
12 months
Sole Product Designer
A 2019 codebase and fixed release windows
Our Gantt chart hadn't been touched since 2019. In that time, user expectations shifted, competitors raised the bar, and a backlog of pain grew. By the time this project landed, the feature had become a liability: outdated UI, confusing UX, and a codebase affecting performance. Studios rebuilt their larger projects by hand in Smartsheet and Google Sheets rather than use ours, and one customer was weighing a move to a competitor over it. An agency director told me in person that the timeline was “the worst part of the entirety of Streamtime.” My brief was to research it, design it, ship it with engineering, and make sure the launch meant something.
I reviewed six years of CS-logged feedback before opening Figma, and grouped it by the most frequent pain points:
I began with low-fidelity sketches to quickly explore layout options, focusing on label readability, inline editing in the table, and the time switcher. Rapid sketching let me test ideas with engineering before developing high-fidelity designs.
The 2019 codebase decided a lot for me. Streamtime has no company-level concept of a weekend (working days sit on individual profiles), so “avoid weekends” became a visual treatment, not a scheduling rule. I cut the duration column rather than ship it wrong. I parked milestone completion ticks once it was clear they pulled overdue logic into scope, and held back full milestone dependencies: attaching milestones to items covered the real use case for a fraction of the build. I logged every cut. The ones with demand behind them came back, and PDF date ranges shipped in the first hotfix, six days after release.
The shipped table and chart in high fidelity: inline editing in the sidebar, two density settings, weekends as a visual layer only.
Milestones attached to items on their own rows, with dependencies drawn between items: the scoped-down model that shipped.
Most of the pain points cost users time inside the product. One sent them out of it: with no way to share a client-facing version, teams rebuilt their timelines by hand in another tool. The fix was the Client View. Users enter a separate client edit mode, hide any items, phases or milestones they don't want shown, and publish. The client gets a read-only timeline they can scroll and zoom. Prior to testing, I suspected the mental model was unclear but couldn't pinpoint where it broke down, so I built the test sessions specifically to find out.
I ran six research sessions with creative studios in a demo environment loaded with each participant's own account data. Every participant saw the value of the client app straight away. The problems were all in how they reached it.
Users were unable to distinguish between modes.
Several edited the client version, believing it was their main timeline and not realising they had switched modes.
A publish modal appeared immediately on entering client edit mode.
It arrived before users were ready to publish, and left them disoriented about where they were in the workflow.
One caveat from the synthesis: every participant previewed the client app before returning, so I couldn't isolate whether the preview flow or the visual hierarchy caused the confusion. The rework addressed both. I validated the changes through internal testing rounds and two weeks of whole-team release testing, then watched them hold up in session replays after launch.
The fix was targeted, not a redesign:
Removed the publish modal on entry. Users land in client edit mode and nothing interrupts them before they are ready to publish.
Added strong visual distinction between internal and client edit modes. The mode switch stays legible, including after following the generated link.
Rewrote the microcopy throughout the flow. Every screen names which timeline you are looking at, internal or client-facing.
Given the significance of this feature, I helped organise a formal launch rather than a silent deployment. I ran a webinar walking through the redesign, and sat down with the lead developer for a blog post Q&A about how it was built.
These efforts created valuable re-engagement opportunities with both current and inactive users, which a simple production release would not have achieved.
I made the launch video in After Effects. Two minutes, built to show the Client View rather than describe it.
Adoption was immediate — studios started publishing client links in the first fortnight, the exact workflow they'd been rebuilding by hand in Sheets and Smartsheet.
users in the first fortnight
went straight to the share flow
“We have tried out the new timeline feature and we are obsessed! We haven't been able to build out timelines in Streamtime in the past, but now with the updates we will be using Streamtime.”
— Customer message, two weeks post-release
“Can I tell you again how much I love the new timeline functionality — sharing and exporting. Magic!”
— Customer feedback, six months post-release
If I had tested the Client View earlier, during the lo-fi stage, I might have noticed the mental model issue sooner. Now, I always add mode-switching flows to my early testing checklist. Next time, I'll also document the tech review process more clearly as a design artefact. With so many conversations happening, it was easy to lose track of decisions, which made it hard to backtrack or give others outside the main project group a clear decision log.
