Storylane

Defining the scope

A full video editor could support dozens of tools: transitions, overlays, color grading. We didn't need any of that. As a team, we focused the editor around four capabilities that were useful for demo creation: zoom, blur, crop, and split.

Keeping editing focused

Most video editors put their controls in a persistent side panel next to the canvas. Storylane isn't selling a video editor. It's selling a demo-building tool, and video is one part of a canvas that already has chapters and steps competing for space. A permanent panel would have made editing feel like the main event instead of a supporting feature. So every tool opens in its own focused pop-up instead.

You never leave the demo for a separate editor. Pick an effect, set it in the pop-up, save, and it becomes a layer. The canvas stays a demo the whole time.

The main timeline only ever shows what's been applied and where: a small marker per effect, never the controls themselves.

From reference to fit

Existing editing tools gave us familiar interaction patterns to work from. We adapted those patterns to fit Storylane's lighter-weight demo editing experience.

Designing the effect flow

The controls inside each pop-up (position, level, speed, duration) were designed after looking at existing video editors to see which patterns were easiest to pick up for someone who'd never edited video before. The values are deliberately unoriginal; familiarity mattered more than originality here.

Handling layered effects

Because overlapping blur layers couldn't be freely stacked, we kept a predictable ordering and made the layers visually distinct.

Supporting states

The four tools needed a small set of supporting states: playback speed, split, trim, and the empty and error screens. Enough to make the editor feel finished, not a second product.

Result

The toolset shipped and stayed live in Storylane's editor for the rest of my time there. Storylane has since simplified the editor in a later update. What's shown here reflects what I designed and helped ship.

Starting from a familiar model

We didn't want to invent a new mental model. Gmail gave us the basic shape (create a label, name it, choose a color, apply it), which meant people already understood what a label was before they touched Storylane's version of it.

Linear gave us a second reference: labels there can be changed directly from the chip, without navigating anywhere else.

We kept the mental model familiar and focused the actual design work on making the interaction faster inside Storylane's library.

The one decision that mattered most

Opening a menu every time someone wanted to tag a demo was too much friction for something meant to happen constantly. So applying a label and managing a demo's labels became two separate, deliberately different interactions. Drag a label onto a demo to apply it: no menu, no picker. Click an existing label chip on a demo to open the picker and add, change, or remove.

1. 01

   Create label

2. 02

   Name + color

3. 03

   Save

4. 04

   Apply to demo

5. 05

   Change / remove

1. 01

   Create label

2. 02

   Name + color

3. 03

   Save

4. 04

   Apply to demo

5. 05

   Change / remove

This kept the common action lightweight, while giving more deliberate changes (swapping a label, removing one, adding a second) their own contained space to happen in.

Making labels consistent across the library

A demo can carry multiple labels, and they can be changed or cleared straight from its card. A dedicated sidebar lets someone filter the whole library by label, and it all works the same whether they're browsing in grid or list view.

The concept was intentionally simple. A visitor could start with a suggested question, talk to an agent (Lily, in Storylane's case), and ask follow-ups. When a question was better shown than explained, Lily could offer a demo and continue answering questions while the visitor explored it. A company could also create multiple agents, each with its own knowledge and persona.

I designed the UI for this direction, including the agent interface and the states needed to move from conversation to demo and back.

A direction that didn't ship

The concept didn't move into production. As the team prioritized speed, RepX moved toward a lighter implementation rather than building out this full interaction model.

Supporting UI

Alongside the agent exploration, I designed the UI for Product Knowledge, Persona, Embed, and Integrations. Some of these started from product direction or prototypes from my PM, with my work focused on translating those requirements into the interface. Parts were later reviewed and refined with the senior designer as the product direction evolved.