Picture Studio
Designing more intuitive AI image editing workflows.
Designing more intuitive AI image editing workflows.
Timeline October - November 2024
Role
Product Designer
Tools
Figma
Team
Jeanelle Petrillo Sr. Designer
Ryan Hinkel CTO
OVERVIEW
Picture Studio is a pre-launch startup building an all-in-one generative AI studio for artists and creatives. As part of my internship, I conducted a comprehensive audit and redesign of the in-app image editor, improving editing workflows by addressing inconsistencies in how the AI tools behaved.
CONTEXT
Picture Studio provides an in-app image editor modeled after classic photo editor tools, but with generative AI functionality.
Users can import their images into the Photoshop-style editor. While it includes familiar editing tools like crop, select, and erase, its core functionality is centered around AI-powered features — specifically inpainting and outpainting.
PROBLEM
Generative editing tools fundamentally can’t behave like traditional tools — but users don’t know that yet.
Since inpainting is such a new capability, users don't have a clear expectation for how it should function. The app’s initial approach tried to model the generative features to work like non-AI tools, thinking it’d be easier to learn. This backfired, as generative tools have different behaviors and engineering constraints. When the AI tools looked the same but didn't follow the same rules, users got confused and frustrated, and early drop-off became an increasingly pressing issue.
Our goal was to find the right balance: abstract away the technical complexity, but surface enough of how it works so users could build the right mental model.
PREVIOUS WORKFLOW
Using a standard marquee or lasso tool, users would select a part of the image, type in a prompt, and then watch as generated options appeared.
Our image editor as of August 2024, before my redesign
RESEARCH
USER FEEDBACK
I collected feedback and compiled it into a user journey map to pinpoint specific aspects of the image editing workflow that felt confusing or surprising. I also noted down engineering constraints for each step of the workflow.
User journey map of the inpainting process
The previous inpainting workflow was all nested within a traditional selection tool.
Using a standard marquee or lasso tool, users would select a part of the image, type in a prompt, and then watch as generated options appeared.
RESEARCH
USER FEEDBACK
I collected feedback and compiled it into a user journey map to pinpoint specific aspects of the image editing workflow that felt confusing or surprising. I also noted down engineering constraints for each step of the workflow.
PAIN POINTS
I summarized our user feedback into three pain points.
UNPREDICTABLE BOUNDS
Difficult to predict or control the area that gets inpainted.
CONFUSING LAYER LOGIC
Unclear how an inpaint relates to the existing layer structure.
HIDDEN CAPABILITIES
Hard to discover what you can do with inpainting.
COMPETITOR RESEARCH
I researched other photo editing, drawing, and design platforms to learn about how our target users are accustomed to working.
I examined how these programs used layers, groups, selections, etc., and the actions that could be performed on each.
PRELIMINARY RULESET DOCUMENTATION
To lay the groundwork for the design phase, I wrote a comprehensive ruleset for how our editor should handle layers and layer operations.
I thought of this as laying out the “physics” of how everything behaves within the editor. The ruleset established a shared logic that all tools follow, addressing the problem of certain tools behaving arbitrarily differently. I also created a reference of key terms and definitions, in order to align the design and engineering teams around a shared language.
Slides from my layer ruleset (click on any slide to expand)
DESIGN PHASE
PAIN POINT #1: UNPREDICTABLE BOUNDS
The generated inpaint area wasn’t respecting the bounds of the original selection, always extending outwards.
Conventional selection tools follow the rule that any operations will stay within the strict pixel boundary of the marquee. The inpainting workflow broke this convention, as results would always feather out farther than intended.
My first instinct was to constrain inpainting strictly within the selection bounds, but this conflicted with an engineering requirement: inpainting needs to be able to feather out a bit to get good-looking results that are the right size.
For example, if a user selects a hand and wants to regenerate it, the new hand needs to be roughly the same size as the original — so the inpainted area has to extend slightly beyond the selection boundary to have enough room to generate the full result and blend it into the surrounding image.
SOLUTION: A SEPARATE INPAINTING TOOL
For example, if a user selects a hand and wants to regenerate it, the new hand needs to be roughly the same size as the original — so the inpainted area has to extend slightly beyond the selection boundary to have enough room to generate the full result and blend it into the surrounding image.
SOLUTION: A SEPARATE INPAINTING TOOL
After much research and discussion, I concluded that the best solution would be to actually decouple the selection tool from inpainting.
Inpainting became its own tool, styled like an airbrush that paints a translucent red mask with soft edges, so the tool itself visually communicates that the output will blend into the surrounding image.
This also made it possible to address another frustration with the selection-based approach. Selecting an area with a marquee or lasso was rigid, and you couldn’t revise a selection once it was drawn. With the new inpaint brush, we built in functionality of add and subtract modes where users could add or subtract from the inpainted area just by brushing over it. We added further control through an adjustable setting for feathering amount, so users could actually change the fuzziness or sharpness of the inpaint edge.
PAIN POINT #2: CONFUSING LAYER LOGIC
Selection-based inpainting also broke the rules of how layers traditionally behave.
Users were confused about where their inpainting edits ended up in the layer structure, since most creative tools follow the rule that selections belong to a single active layer, and edits made to a selection stay on that layer.
Inpainting broke both expectations. When users created a selection, all layers became unselected because the old design tried to convey the technical requirement that generating an inpaint requires the entire image context. Then, after generating, the result popped up on a brand new layer.
While the layer panel did reflect what was happening, it was subtle and hard for users to notice in the moment, leading to confusion on where their inpaints ended up.
This also made the selection tool less usable for traditional editing workflows. Users couldn’t just grab a portion of a single layer to edit or move separately like they were used to doing in other apps.
SOLUTION: EMPHASIZE INPAINTS ARE ON A NEW LAYER
Decoupling selection from inpainting solved the bulk of these issues, but we also made targeted design changes to further emphasize the new layer created when inpainting.
Because the inpaint brush is now its own distinct tool, it no longer contradicts users' mental models of selections and can follow its own layer logic without breaking expectations.
We redesigned the inpainting and outpainting tools so that switching to the tool automatically deselects all layers and introduces a “target” indicator layer in the layer panel as soon as they start brushing, outlined in a dashed border, so users can see where their result will live before it’s generated.
We also introduced a branded red-purple gradient as a visual language for AI-specific functionality across the product to signal to users when they're working with AI rather than traditional editing tools. The target indicator layer is colored with the gradient to draw more attention to the fact that something new is being created on its own layer.
PAIN POINT #3: HIDDEN CAPABILITIES
The inpainting tool felt mostly geared towards generating something new, so use cases like erasing or replacing the background weren't obvious.
Erasing part of an image was technically possible by leaving the prompt blank before generating, but nothing in the UI suggested this. Users who weren't explicitly told would often treat the prompt box like a chatbot, typing things like "remove this object" which wouldn’t work.
Background replacement was also tricky with the previous tool design. Inpainting by nature is designed to blend generated content seamlessly into the surrounding image, so trying to generate a new background behind a subject would cause the generation to bleed into the subject itself, producing strange artifacts.
SOLUTION: THREE INPAINTING MODES
Rather than expecting users to intuit the different ways inpainting could be used, we split the tool into three distinct modes: Reimagine, Remove Object, and No-Context Fill.
Reimagine is the default mode. It works the way inpainting traditionally does, blending generated content seamlessly into the surrounding image.
Remove Object allows users to remove objects in their image. In the UI, the prompt box is disabled with a note that the prompt doesn't apply, making it clear that leaving it blank is intentional.
No-Context Fill makes background replacement possible by generating into the selection without referencing the surrounding image.
CONCLUSION & TAKEAWAYS
This project pushed me to design for a tool that didn't fit existing patterns, where the right solution required understanding the technical constraints deeply enough to work with them.
It was a new challenge for me to think about how to design UX that communicates clearly what happens during inpainting without exposing too much technical complexity that it confuses users. I found myself thinking about this redesign outside of work constantly — on weekends, on the train, before bed — just because the problem was so interesting to me. The redesign was implemented after my internship ended.
CTO Ryan Hinkel, formerly an engineer at Google, reflected on my work at PictureStudio:
"I've worked with a lot of product designers who see technical constraints and just get stuck. What stood out about Kelly was her ability to work through those limitations and arrive at real solutions."