Background remover

Creating Shutterstock Editor’s most requested feature

www.shutterstock.com/editor

To comply with my non-disclosure agreement, I have omitted confidential information.

MY ROLE

I was the UX lead on this project. I defined the product and experience through research, working in an agile process with developers to scope and evolve the feature. Since the core algorithm was being built in parallel, I worked closely with my product owner to align customer needs and business goals — using differentiation analysis and story mapping to pitch my recommended product strategy.

impact

Shipped the feature covering 24% of our customers' most-requested asks.

How might we ship Editor's most-requested feature in one quarter?

I was tasked with delivering Shutterstock Editor's single most-requested feature within one quarter. I started by digging into customer insights — reading through every request to understand the actual use case behind it.

The Discovery

Research

I ran a competitive analysis alongside user interviews, and mined our global customer care reports. Three findings shaped the direction:

Output quality was the deciding factor. Users' satisfaction hinged almost entirely on how clean the final cutout looked.
It wasn't just about backgrounds. Many users were using the tool to isolate parts of an image, not only strip the background out.
Two use cases dominated. Most requests centered on producing either a plain white background or a checkered (transparent) one.

Flow

Most users arrived with images sourced from Shutterstock itself, so the flow needed to check whether an image was a licensed Shutterstock asset before processing it.

Design Sprint

Working with 6 stakeholders, we landed on two key decisions: include a live preview, and collect two distinct types of user input — areas to remove, and areas to protect.

Design iterations

I split the design work into two tracks — interaction and layout — and prioritized rapid testing on anything dependent on the engineering team's parallel algorithm work.

Rapid prototyping

Because the underlying algorithm directly shaped how users could mark areas for removal, I worked in tight loops with engineering — prototyping fast so design and algorithm development could inform each other in real time.

interaction

I structured the interaction model into two layers:

Main tool — user input (areas to remove / areas to protect) and results (selection state, live preview)
Supporting tools — zoom, brush adjustments, undo/redo

Designing for iterative edits

First iteration had the users indicate areas to be removed and contained before applying the change.

Final design allows user to make iterative edits and gain faster feedback of the result.

Designing for mode-switching

Letting users move seamlessly between marking input and using supporting tools mattered a lot. The first iteration had three brush/cursor types, which user testing showed was confusing.

[Cursor confusion] The rightmost cursor state was especially unclear, particularly to the novice designers who make up most of Editor's user base.

[Simplified cursor states] I simplified this to two brush modes in a toggle, with the cursor switching to a standard pointer automatically based on hover context — communicating the two-mode system without extra UI.

Right most cursor was very unclear to users, especially those who were novice designers, who are the users Shutterstock Editor is targeting. — *[Cursor confusion]*

Instead cursors switch from brush to the normal selector depending on the hover area. — *[Simplified cursor states]*

Layout

Layout iteration 1: First pass followed the layout conventions most competitors used.

Layout iteration 2: Next, I adapted those components to match Shutterstock Editor's existing visual system for consistency.

Layout iteration 3: Giving the preview and the work area equal real estate didn't make sense, so I moved the preview below the work area, within the same field of view.

Final layout: Given the range of browser window sizes, I moved the preview into the right panel to maximize workspace. I also tested whether the preview was even necessary, since it seemed to duplicate the yellow-highlighted selection area — but research showed the two served different purposes: the highlighted area shows what's selected, while the preview helps users confirm the result matches what they pictured.

First time user experience

Dark overlay along with action call out help users learn about the new tool — *[FTUE overlay]* A dark overlay with a contextual callout introduces the new tool on first use.

Unobstrusive nonmodal overlay help users learn how to use the tool with context. — *[Non-modal tutorial]* A lightweight, non-modal overlay teaches the tool in context, without blocking the workspace.

Final design