Portrait (Early stage)

TLDR

Portrait is a working case study rather than a polished launch story since I am still working on it. It records how the product changed whilst I designed and built it, including the ideas I reversed, the features I removed and the questions that still do not have a final answer.

The flow itself is kept simple, because why complicate it more than necessary? Upload photos, choose clothing and backgrounds, review the setup and then generate the portraits. The user can also apply company templates to skip parts of the setup and generate more quickly.

The complexity appears when an account owner needs to create portraits for an entire team. Now there are several people, shared company choices, individual exceptions, credits and sensitive reference photos that may belong to the employees rather than the person controlling the account. The current product is my attempt to make those parts understandable before it is tested with customers, engineering constraints, image output, legal review and production security requirements.

Role

I am leading Portrait across product strategy, UX, interaction design, the design system, prototyping, technical direction, testing and frontend implementation.

The product is still in early development, so my current focus is not presenting it as a finished launch. I am defining how it should work, implementing the ideas and then challenging them when the result reveals another problem. Sometimes this means improving a flow. Other times it means removing it completely.

Where the product is now

Portrait allows an account owner to create consistent AI portraits for one person or an entire team. The flow has five connected steps:

1. References
2. Outfits
3. Backgrounds
4. Review
5. Results

The account owner controls the shoot and pays for the generation. Participants provide their own reference photos, but they do not choose the final settings or spend credits.

The same structure appears throughout the product. People are shown in rows, their current state remains visible and group choices can still be changed for an individual. Before any credits are spent, the account owner sees what will be generated and how much it will cost.

This is the current idea. It is not an answer that can never change.

Where I started

Most AI portrait products are designed for one person uploading photos of themselves. This works until a company wants portraits for ten people.

Now someone needs to add the participants, collect their photos, apply a company style, make exceptions and understand who is ready. The employees may want to provide their own reference photos, whilst the account owner still needs to control the credits and final output.

The earlier versions showed too much at once. Explanatory text, controls, thumbnails, states and actions were all competing for attention. Could a user still complete the flow? Indeed, but it felt more like moving through a collection of forms than using one product.

So I began removing the parts that did not need to be there. Longer status descriptions became thumbnails, badges and a completion indicator. Repeated actions were brought together, and the review became closer to a receipt where the account owner could understand what they were about to buy.

Current product idea

The account owner adds people, applies templates, chooses outfits and backgrounds, spends credits, generates the results and downloads them.

Participants only provide the reference photos required for their portrait. They do not enter the configuration or generation flow.

The main object in the product is a person. Their references, outfit choices, backgrounds, review information and results remain connected to them. Group controls provide a default, whilst individual controls allow exceptions.

How the design changed

The product changed several times as the flow became clearer:

• Participant generation was removed when it became unclear who should control the account owner's credits.
• The default person became a real empty state so removing everyone behaved honestly.
• Separate upload actions became one stable Photos menu.
• Longer status descriptions became thumbnails, compact badges and a completion indicator.
• A separate Apply to everyone toggle was removed because the Everyone card already communicated the same action.
• Exact garments and gender categories became broader outfit directions.
• Backgrounds were allowed across categories when each choice became another generation setup.
• Configurable quantities became one result for each outfit and background pairing so the cost remained understandable.
• Results returned to the five step flow instead of becoming a second dashboard.
• Fragile shared styles became dedicated composition classes with a clear purpose.

The recurring pattern was not removing things simply to make the interface look clean. It was removing them when the extra control created more questions than value for the main flow.

Product decisions

1. The account owner controls generation

I initially designed a way for participants to generate the images themselves. This could create a smoother experience because they would choose exactly what they wanted and the admin would not need to generate for everyone.

But the issue is that they would be using the admin's credits. What happens if someone generates twenty portraits without understanding who is paying? Limits, permissions and approval states could solve parts of it, but now the product needs more settings to support something that is not necessary for the main flow.

So I removed it. Participants provide their photos, whilst the account owner controls the settings and decides when credits are spent. The tradeoff is that participants have less control over the final image, but the responsibility is at least clear.

2. References is organised around people

References uses one row for each person. The row combines their identity, photo state, optional company template, upload action and removal action.

The workspace can contain zero people. This sounds obvious, but the earlier version always kept a default person in the interface. Removing that person did not truly remove them, which made the state dishonest. Now the account owner can remove everyone and cannot continue until a person has actually been added.

3. Show progress instead of explaining it repeatedly

Long status sentences made each person row heavier than necessary. So states such as Awaiting upload and In progress are supported by image previews, compact badges and a completion indicator.

Color is not the only signal. A user should not need to interpret green or orange correctly in order to understand whether someone is ready.

4. Keep photo actions in one place

The available photo actions change depending on whether images already exist, but the location of those actions should not move around. One Photos menu contains importing images, taking photos with a phone, managing photos and hiding them when those actions are relevant.

The menu keeps a reserved place in the row and closes when the final image is removed. The state changes, but the user does not have to search for a new control every time.

5. Participant upload is still unresolved

The participant upload needs to be practical. Sending a link is useful, and a QR code could make it quicker to open the same flow on a phone. But the simple part ends once identity, consent and deletion are considered.

I initially planned to require the employee's email when the admin added them. This could be used for verification and might give the employee a way to contact the service later if they wanted their photos deleted. For example, if they left the company or simply became concerned about their privacy.

However, this would also require the admin to enter someone else's email into a third party service, which could create another privacy problem. So I have removed the earlier flow from the current case study as a decided solution. I am still researching how verification, consent and deletion requests could work without making the upload unnecessarily long or disruptive.

The production flow will need proper security, but listing possible controls is not the same as having a validated solution. This part requires technical and legal review before it can be presented as complete.

6. Mobile and desktop share the same flow

The upload experience uses the same states and information on mobile and desktop, but that does not mean every element needs to appear in exactly the same place.

The hierarchy and behavior remain consistent whilst the layout changes to fit the screen. Forcing desktop geometry onto a phone would make the experience less consistent in practice, even if the screenshots looked more similar.

7. Company templates remain optional

Company templates are meant to make setup quicker, not silently decide the final portrait. They remain visible, optional, attributed to the company, editable and reversible.

Completed shoots keep a snapshot of the template that was used. Otherwise changing the company template later could also appear to change the history of a portrait that had already been generated.

8. Use broad outfit directions

Portrait does not promise exact garments. The choices are broader directions such as Executive and formal, Business casual, Creative and modern, and Casual and approachable.

Exact clothing would suggest a level of control that the generation may not consistently provide. Gender categories could also introduce assumptions that are unnecessary for the flow. A broad direction gives the model guidance without pretending that the user is selecting a specific item from a shop.

9. Group choices still allow exceptions

An account owner might be creating portraits for ten people who all need to follow the same company style. Should they have to choose the same outfits and backgrounds ten times? Of course not.

The Everyone option applies a selection to the group. However, this does not mean every person must remain identical. Individual choices can still be changed, whilst new people inherit the choices that are already applied to everyone. Flexibility is a nice feature.

10. Backgrounds can cross categories

Backgrounds are separated into Solid colors, Real backgrounds and Uploaded. The user can move between the categories without losing choices that are currently hidden.

Selections can also cross categories because each selected background becomes another generation setup. The Review step then shows what those choices mean for the final number of portraits and credits.

11. Keep summaries visible and reversible

Outfits and backgrounds use the same summary pattern. Up to three previews are shown, whilst the rest are represented by a remaining count. A detailed view shows every selection and removal stays an explicit action.

The user should be able to understand that several choices exist without the row growing every time another one is added.

12. Review works like a receipt

Review shows one collapsed card for each person with their references, outfits, backgrounds and portrait total.

One portrait is generated for every unique pairing of an outfit and background. This makes the cost deterministic. If someone has two outfits and three backgrounds, the account owner can see that the result is six portraits before any credits are spent. Two pieces of information creating an answer that is easy to understand.

13. Results remains part of the flow

Results is the fifth step rather than a separate management dashboard. Moving it elsewhere would make the user leave the process at the exact point where the process is completed.

Skeleton states keep the future image space visible whilst generations are running. Download actions remain in the same place and change according to the result, so partially completed generations do not move the controls around.

14. Build the visual rules into the product

Repeated implementation can make a working interface slowly drift. Spacing changes, icons become inconsistent and one screen solves the same state differently from another.

So the product uses semantic tokens and dedicated composition classes for the parts where the geometry is easy to break. The interface remains flat, using borders and changes in surface rather than shadows. Motion is short and functional, with reduced motion considered from the beginning.

Supporting decisions

• Content uses sentence case and consistent product terms.
• Black represents active neutral actions.
• Orange represents waiting and something the user can act on.
• Green represents completion.
• Red is kept for destructive actions and actual errors.
• Color never communicates a state by itself.
• Controls need visible focus, accessible names, keyboard support, nearby errors and usable touch targets.
• Destructive actions explain the consequence before they happen.

These rules may sound small individually, but repeated inconsistency is how a simple flow slowly becomes harder to understand.

Privacy, retention and responsibility

Reference photos are sensitive. Using an external image model does not remove the product's responsibility for what is collected, why it is collected, how long it is kept and how someone can ask for it to be deleted.

The current direction is to keep raw references for as little time as the service genuinely needs, delete abandoned uploads sooner, retain only necessary audit information and define when results and backups expire. Deletion would also need to reach the external processors involved.

But the identity problem is not solved simply by showing someone an upload reference. A deletion request still needs defensible verification, and the participant email idea introduces its own privacy question before it solves another one.

So this section describes the concerns and current direction, not a finished legal answer. Consent, lawful basis, processor agreements, retention, regional requirements and the final upload flow need specialist review before launch.

What I deliberately did not build

• Participant controlled generation or credit spending
• Gender based outfit filtering
• Exact garment selection
• Industry uniform presets
• A random mode that generates thirty looks
• Mandatory choices beyond what generation requires
• Hidden application of company templates
• A second dashboard only for Results
• A production verification flow that exists only in the browser
• Permanent storage of raw references by default

Some of these features could be built. The question is whether they should be. Every additional option introduces another state, another explanation or another way for responsibility to become unclear.

Detailed decision register

The published case study will contain the complete decision register for the workflow, references, identity, participant uploads, templates, group choices, backgrounds, review, results, styling and motion.

The register is useful because the current interface will continue to change. Screenshots show what the product looked like at one point. The decisions explain why it looked that way and which assumptions still need to be tested.

Reflection

Portrait began as a fairly simple generation flow and became a question about responsibility. Who provides the photos? Who chooses the final style? Who spends the credits? Who can ask for the source images to be deleted later?

The interface can make these questions look clean, but that does not mean the answers are complete. The participant verification flow is a good example. I had a solution, followed the logic further and realised that it could introduce another privacy problem. So I removed it for now.

This is why the case study remains a working record. A functioning interface is not the same as a validated product, and a detailed flow is not automatically a good one. The next step is to keep testing the parts that work and remain honest about the parts that do not. Indeed, that is the actual work.