Designing trust for a user who cannot speak for itself, across a product that changed category halfway through.

Furr Baby began with an ambitious premise: a matchmaking experience for pets. Owners would help their animals find compatible companions. The product later pivoted toward healthcare, because of funding and shifting business priorities.

The interesting part is not that the direction changed. It is what survived the change. Everything the first phase taught me about verification, owner confidence, identity and progressive trust turned out to matter more in healthcare than it had in matchmaking, because in healthcare the cost of misplaced trust is not a bad afternoon. It is an animal that does not get treated.

Positioning it in one line: designing a connected pet care ecosystem by carrying trust, context and human centered thinking from a pet matchmaking concept into digital pet healthcare.

The client was a startup founder still exploring whether the business should be an application, a website, a doctor facing portal, or a broader ecosystem. That ambiguity meant the design role extended well past screen design. The work involved helping decide what the product could be, what users might need, and which problems were worth solving at all.

The first phase asked whether a dating model could work for pets. I researched Tinder, Bumble, Hinge and other established products, looking at onboarding, identity, verification, discovery, matching, trust signals, safety, how conversations begin, and what a product insists on knowing before two people meet.

The goal was never visual imitation. It was understanding why those interaction models work, so I could tell which parts would transfer and which would quietly break.

So the profile had to change underneath, not just above. It moved from a conventional dating profile toward a paired identity: the owner establishes who they are, and the pet profile explains who the animal is. Pet name and identity, animal type, relevant characteristics, behaviour, owner information, a pet specific questionnaire, compatibility context, verification status.

That is the difference between a reskin and a redesign. The information model changed, which means the discovery, matching and safety systems built on top of it all had to change too.

An owner considering a meeting faces uncertainty at several levels at once. Who is this person? Is the pet real? Is any of this information accurate? Is the meeting safe? Is the whole interaction appropriate?

The obvious answer is a verification wall. Ask for everything up front, prove everyone is genuine, then let people in. The obvious answer is also the one that empties the product, because nobody completes a long identity check for a service they have not experienced yet.

Onboarding therefore had to do two contradictory things. Collect enough information to build a profile credible enough to be useful, and stay short enough that people finish it. The resolution was to spread the collection across the journey and give every request a reason, so that each step reads as the product being careful rather than the product being nosy.

A broader survey explored how people reacted to the idea of pet matchmaking. The reaction divided: some found the concept unfamiliar or faintly taboo, others were genuinely excited by it.

The useful finding was not the split. It was what moved people across it. The question worth designing against turned out to be not would you use this, but what would make you comfortable enough to consider it.

The business moved toward healthcare because of funding and evolving startup priorities. There is a weak way to tell this part, which is that the client changed the requirement. There is a truer way, which is that the product direction changed and the research turned out to be reusable.

Every row in that table is a piece of work that would otherwise have been thrown away. That is the argument for doing research at the level of the problem rather than the level of the feature. Findings tied to a matching algorithm die with the matching algorithm. Findings about how a person builds confidence in a stranger they are about to trust with something they love do not.

Pet owners need a convenient and trustworthy way to reach veterinary support and to communicate what they are seeing. Veterinarians need structured context about the animal, so a remote interaction can start with useful information instead of a blank conversation.

Practo and Tata 1mg were useful benchmarks for what people already expect from digital healthcare: find a professional, describe a problem, read reliable information, talk to a doctor, get support without a journey. What none of them had to solve is the thing that defines this product.

The first interaction had to do more than create an account. It had to explain what Furr Baby was, establish the pet's identity, collect information a veterinarian could use, and make a healthcare service feel approachable to someone who is probably worried about their animal.

Progressive disclosure was the guiding approach, carried over intact from phase 0. Do not ask everything on the first screen. Ask in a sequence that makes sense to the owner, and give every request a reason.

A generic messaging interface assumes both people already have enough context to begin. Veterinary support does not work that way, so chat was positioned on top of structured pet information rather than beside it. Before the message, the doctor can already see the animal's context. During it, the owner explains what they are observing and gets guidance. When text runs out, the experience escalates to video.

Video consultation exists because a veterinarian may need to see behaviour or physical context that no description captures. The transition from chat should read as support escalating, not as a different product opening. It is also the place where the case study has to be careful: this is remote care with real limits, and it does not replace a physical examination.

The doctor side introduced a completely different adoption problem. We spoke with veterinarians including Mr. Ramesh, Swati and Mr. Pankaj, and their varying levels of digital confidence made something obvious that is easy to forget: professional expertise and digital fluency are not the same thing.

So the portal could not be designed for an imagined power user. It had to work for the least digitally confident professional without becoming tedious for the most experienced one. That meant guided onboarding, predictable actions, clear labels, strong hierarchy, visible progress and as few unnecessary steps as the workflow allowed.

The distinction that shaped it: a doctor may need to see who needs attention, understand a patient's context, respond to a message, review records and manage service information. Those are tasks. An analytics dashboard answers a different question, and answering it at equal visual weight to the tasks would make the tool slower to use rather than more informative.

The patient record sits underneath all of it, and it does something a chat transcript cannot. It reduces repeated questions, preserves history, supports continuity across interactions and gives both sides one reference to point at.

The two structures overlap in the middle and diverge at the edges, which is correct. An owner navigates by their animal. A veterinarian navigates by their workload. Forcing one navigation model onto both would have made one of them worse to serve a consistency nobody experiences, since no single person uses both products.

I designed the brand direction alongside the product, and it had to occupy an unusual position. Too playful and a healthcare service stops being believable. Too clinical and it stops feeling like it is about an animal somebody loves. It also had to survive being used in three places at once: a consumer app, a website, and a professional portal where a veterinarian is doing their job.

The resolution visible in the shipped screens is a warm neutral base with a single grounded brown accent, geometric type, and a mark built from two shapes that read as an animal and a heart at the same time. It sits closer to credible than to cute, and it lets the professional portal use the identical palette without looking like a toy.

Beyond the design file, the real product has constraints a Figma frame does not: responsive behaviour, component states, content that changes length, performance, accessibility, and technical limits discovered during implementation. Loading, empty and error states are where most design systems quietly fail, because they are the states nobody presents in a review.

Documenting that properly needs the development artifacts, and I would rather say that than imply a handoff process I cannot evidence.

The first phase taught me that a familiar interaction model becomes a very different product when the relationship between user and subject changes. A pet matchmaking app is not a dating app with animals in the photography. The owner becomes a proxy decision maker, and that reshapes identity, trust, safety and information architecture all at once.

The pivot made those lessons more consequential. In healthcare, trust is not a decorative layer. Context matters, the person entering the information is not the patient, and technology should support professional judgement rather than replace it.

It also taught me that simplicity is not one thing. A worried pet owner needs reassurance and clarity. A veterinarian working through a queue needs speed and context. Designing one interface that serves both would have served neither.