NanoClip — Maayan Kedem-Bhonker

Overview

The short version

LettheAIdotheboringpart.Keepthechoosinghuman.

The problemFour to six hours per episode, and taste comes into it the whole way through — which moment to take, where to cut it, how it is framed, what the caption says.
The moveThe AI suggests the clips. You spend your time choosing and refining them, not cutting from scratch.
The resultA working product where nothing posts by itself, and a person signs off on every clip.

The AI finds the clips. You decide which ones are any good.

The full product, at a glance

The problem

Four hours of work to make six decisions that each take a second.

By hand

4–6 hours

The target

~20 minutes

A design target taken from the annotated task flow, not a measured result.

How can the path from a long-form episode to publishable social clips get shorter, while the person stays informed, in control, and responsible for the final editorial decision?

Mapping the experience

I mapped what breaks before drawing any screens.

User flow diagram — User flow — the full decision tree from landing page to publication, including the sign-up branch, the input-method fork, and the processing error and retry path.

01Upload~30 sec

02Configure~1 min

03Process2–5 min

04Review5–15 min

05Edit2–10 min

06Export~1 min

The decision tree above maps every branch and failure state; this maps the single path a person takes when nothing goes wrong — which is the path the interface has to make fast. Times are the budget it was designed against.

Primary task flow — the path from upload to export, annotated with the actions available at each step and the time each step should take.

I storyboarded it as a narrative too — starting from the dread after a recording session, not from the moment someone opens the app.

Key UX decisions

Same clips, two questions — switch between the views:

Processing episode

~2 min remaining

Listen — transcribe the audio
Watch — read the frame
Search — find the moments
Cut — build the clips

Start with the drop zone

The dashboard leads with the drop zone, not a list of past projects.

It also accepts a YouTube URL as well as a file. Many podcasters publish to YouTube first, and asking them to download a two-hour video in order to re-upload it adds twenty minutes of waiting to a thirty-second task.

Start with the drop zone — The drop zone leads — a new episode is the usual reason to open this.

Fill the settings in

Language, clip detection and time range arrive already answered, and the one free-text control — the prompt — is marked optional. A first-time user can press the button without making a single decision about a system they have not seen work yet.

Nothing is hidden: every setting is right there, and the run cost sits next to the button rather than in a billing page. Filling the fields in and letting people change them teaches the product far better than asking five questions up front — and the prompt earns its place precisely because it is the one thing a default cannot guess.

Name what is running

Rather than a spinner, the screen names each stage as it runs — Listen, Watch, Search, Cut — and says outright that the project will be waiting if you leave.

A named stage makes a wait of a few minutes feel like something is happening rather than something is stuck. It also shows people what the tool actually does — so when a clip comes back badly cropped, they know it was Watch that got it wrong and which workspace to reach for.

Fixing, not editing

The editor deliberately does not try to be a video editor. It splits into four workspaces and no more: Clean, Captions, Reframe, Exports — one per thing the generated clip is likely to need.

Fixing inside those four is quicker than opening a timeline. Anything bigger than that belongs in the editing tool people already own.

Decide once, apply to all

I designed this as named brand kits: a look saved under a name and applied per episode. What got built solves the same problem one level down — colour, weight and casing live in the Captions workspace, with a single Apply to all clips action.

Both remove the same decision, which is the point: nobody should be choosing a caption colour again on every episode. The shipped version is the cheaper half of the idea, and it is the half that earns saved kits later — once there is evidence people run more than one look.

nanoclip.ai

What I designed — named kits, saved and reused.

Decide once, apply to all — What shipped — colour, weight and casing set once, then applied across the project.

End with what you got

Export confirms what was produced, then offers the two things a user actually wants next: download the batch, or schedule the posts.

The last screen asks one question about clip quality. Asking once, right after something worked, gets a far more honest answer than a survey next week.

End with what you got — Export confirms what was produced, per clip and per format.

What I’d test next

Open questions

Ithasnothadenoughrealpeopleontheirownepisodesyet.

Where people actually get stuckNot where the flow predicts they will — where they hesitate, back out, or repeat a step. Those are the points the design missed.
Whether the scores are used at allThey earn their place only if people read them as a signal of how a clip is likely to travel. If everyone opens every clip regardless, the score is decoration.
Time saved, output still goodBoth halves matter. Faster with worse clips is not a win, and neither is a beautiful clip that took as long as doing it by hand.
What frustrates people I did not predictThe states I designed for are the ones I could imagine. Session recordings and support messages are where the rest show up.

Project created in collaboration with the NanoClip team. Claude Design and Claude Code were used as prototyping and implementation tools.