Background remover
Creating Shutterstock Editor’s most requested feature
To comply with my non-disclosure agreement, I have omitted confidential information.
MY ROLE
I am the UX lead of this project. I defined the product and experience by doing research and working in the agile method with developers to scale the scope of the project. Because our developers were working on the core algorithm in parallel, I evangelized customer goals and business goals with my product owner and used differentiation and story mapping to showcase my recommendation and product strategy.
impact
By creating this tool, we covered 24% of customers’ asks.
HOW MIGHT WE implement the most asked for feature on editor?
I was asked to Shutterstock Editor’s most asked for feature in 1 quarter. I first conducted research into customer insights, looking at each ask and understanding the use case in which they were asking for the
The Discovery
Research
I did a competitive analysis as well as some user interviews for research. I also looked into our global customer care reports and discovered the following findings:
1. Quality of output
The quality of the output determined user satisfaction.
2. Not just backgrounds
Many users were using this tool not just to remove backgrounds. Instead they were also using the tool to isolate parts of an image.
3. Top use cases
Top use cases from customer insights had a white background or a checkered one.
Flow
Most Editor users were coming in with images they found on Shutterstock, it was important us to check whether the image they were removing the background of was a Shutterstock image and if so, to make sure the image was licensed.
Design Sprint
With 6 stakeholders, we made decisions to: 1. Include a preview and 2. We would collect 2 collections of user inputs - the areas to be removed and the areas not to be.
Design iterations
I largely grouped the design of this tool to tool two parts: the interaction and the layout. Immediate testing for the interactions was important, especially for the ones that were dependent on engineering.
Rapid prototyping
The algorithm that determined what the background was, defined the way with which we allowed users to indicate the areas to be removed and vise versa. Because of this co-dependency, I had to work very closely with the engineers to develop both the design and algorithm in parallel. The way in which we achieved this was by rapid prototyping as shown above.
interaction
I grouped the interactions into two parts:
Main tool
User input
The areas to be removed
The areas NOT to be removed
Results (expectation)
Selected areas
Preview
Supporting tools
Zooming
Bush adjustments
Undo/redo
Interaction better for iterative edits
Interaction for Supporting tools
Allowing seamless context switching between marking areas for input and supporting tools such as tools was important. First iteration included 3 types of brush/cursor but with user testing I found out that this was confusing. So instead I decided that we include only 2 types of brushes in a toggle to naturally communicate to our users that there were two modes and show the basic cursor only when a user hovers over the intended area.
Layout
1. I first designed a proof of concept following how most of the competitors were laying out their tool.
2. I then applied the components to fit the layout Shutterstock Editor was using for consistency.
3. Because it was unfair to provide equal real estate to both the preview and the work area, I decided to put the preview under the work area, in the same field of view.
4. Due to many browser sizes and to maximize the work area, I decided to finally put the preview in the right panel. During, I asked if the preview was necessary because it was providing the same information as the yellow shaded area. With research I found that although the two provided the same information, the utilities the two were providing were very different. The preview helped user aligned the result the users had in their mind.