I started PetMorph with a familiar AI-product problem: the system could create many kinds of pet images, but the interface was asking people to understand the model instead of their own goal.
The better product was not a bigger style selector. It was four plain-language paths inside PetMorph:
- Pet Human for the curiosity of seeing a pet reimagined as a person;
- Pet Portrait for avatars, keepsakes, and shareable artwork;
- Pet ID Photo for a clean, centered passport-style result;
- Pet Holiday Card for birthdays, Christmas, Halloween, and New Year.
Each path starts from the same thing — one clear pet photo — but leads to a different job.
The problem with a generic generator
A single prompt box looks flexible, but it moves the hard work to the user.
People have to decide which words to use, which style controls matter, and whether the result is meant for fun, a profile picture, a document-style image, or a celebration. A wall of presets does not remove that uncertainty; it only gives it more buttons.
So the product question became:
What is the user trying to make right now?
That question produced a much clearer information architecture than asking users to choose a model or prompt recipe.
Use cases, not just styles
The four paths are intentionally treated as stable use cases rather than four unrelated generators.
They share the same product foundation, but each route has its own:
- promise and examples;
- upload guidance;
- result framing;
- safety or expectation notes;
- direct creation entry point.
This lets the homepage explain the whole brand while each product page can focus on one task. It also avoids forcing search visitors into a generic dashboard before they understand what the tool does.
One product framework
The implementation keeps those four use cases in a shared product configuration. Navigation, homepage cards, landing pages, and creation links read from the same source of truth.
That small decision matters more than it sounds. Without it, labels and routes drift: one page says “pet avatar,” another says “portrait,” and a third sends users to a generic create screen with the wrong preset.
The current web stack uses Next.js, React, TypeScript, and Tailwind CSS. The shared framework is deliberately simple: stable IDs, localized text keys, explanation URLs, and creation URLs.
Designing for trust
AI image products often hide important boundaries behind a friendly upload box. PetMorph keeps the most relevant ones close to the task:
- use a clear, well-lit photo;
- uploads are validated before generation;
- images are sent to an AI service to create the result;
- generated images may be stored temporarily for downloads and account history;
- an ID-style pet image is creative output, not an official document;
- usage still depends on the source-photo rights, terms, and applicable law.
The goal is not to make the interface feel legalistic. It is to make the product promise match what the system can actually do.
What changed in the experience
The homepage now answers three questions in order:
- What can I make from one pet photo?
- Which path fits my goal?
- What do I need to know before I upload?
Real before-and-after examples sit beside the four use cases. Free everyday tools — such as pet-name and pet-age helpers — live in a separate layer so they do not compete with the core creative workflow.
New users can try two creations after signing in, and the product uses one-time credit packs instead of requiring a subscription.
What I learned
The hard part of an AI product is often not adding capability. It is reducing interpretation work for the user.
“Generate a pet image” is a system capability. “Make a portrait I can keep,” “show me my pet as a person,” and “create a birthday card” are user goals.
Once those goals became the product structure, the copy, routes, examples, and calls to action became easier to keep consistent.
You can explore the live product at petmorph.app. I would be especially interested in feedback on whether the four paths feel distinct before you upload a photo.
Top comments (0)