How do I design apps for pet owners and vets?

Pet owners and vets use technology very differently, and they need very different things from it. A pet owner opens an app in a moment of worry, often at night, often with a sick animal nearby. A vet opens the same app mid-consultation, needing fast access to records, dosing references, and clinical notes. One user is emotional and uncertain. The other is trained, time-pressured, and looking for specific information fast. Designing one product that serves both of them well is one of the harder audience problems in digital product design.

The failure mode is consistent: designed for one audience and then extended awkwardly to cover the other.

The pet care sector is growing, and the appetite for apps that connect owners with veterinary services is real. But the failure mode is consistent: products get designed for one audience and then extended, awkwardly, to cover the other. Vets end up with interfaces that feel designed for anxious parents. Owners end up with clinical dashboards that feel cold and impenetrable. Neither audience gets what they need, and the product sits between two groups without belonging to either.

What follows is our thinking on how to approach this properly: how to map the two audiences, understand where they pull against each other, and build an architecture that gives each group what they need without making the other group feel like an afterthought.

Why One App Serving Two Audiences Is a Design Problem, Not a Development One

The instinct, when a product needs to serve multiple user types, is to frame it as a technical challenge. Give vets a separate login, route them to different screens, and consider the problem solved. But the real challenge sits earlier than that, at the level of product logic, information architecture, and the emotional register of the experience itself.

A vet and a pet owner interacting with the same underlying data have fundamentally different relationships with that data. A vaccination record to a vet is a clinical reference point. To an owner it is evidence that they are doing right by their animal. Those are not the same thing, and they do not want the same presentation. One needs density and accuracy. The other needs clarity and reassurance.

Getting this wrong at the design level means no amount of development sophistication fixes it. We have seen products that correctly separated user journeys at a routing level but still felt wrong in each lane, because the underlying language, hierarchy, and visual logic had been built around one audience and then modified for the other. The modifications never quite land. They feel bolted on, because they are.

The design problem is this: two audiences sharing a product need different screens and a different underlying logic for how information is structured, prioritised, and expressed. That logic needs to be established at the start, not retrofitted.

Mapping What Pet Owners Actually Need From a Vet App

Pet owners arrive at a vet app in a range of emotional states, and the design needs to account for all of them. Some are in active worry, dealing with a sick animal and looking for guidance fast. Others are in routine management mode, booking appointments, checking vaccination records, reordering preventative treatments. A few are in research mode, trying to understand a diagnosis or a treatment plan they have just received.

Across all of those states, the common thread is that they are not clinically trained. They do not read ICD codes or drug names with confidence. They need translation, context, and enough explanation to feel informed without feeling overwhelmed. On a genetics product we worked on, we found that plain language and real-world analogies were the right primary layer, with medical detail available for those who wanted to explore it. User testing on that project supported this structure decisively over the client's preference for full medical detail as the default, and it produced higher comprehension and lower anxiety among participants. The same principle applies here.

Beyond information needs, pet owners also need emotional reassurance built into the design itself. The choice of colour, the warmth of copy, the pacing of onboarding, all of it communicates whether the product takes their worry seriously. On a healthcare product we designed for African markets, we chose a dark UI with green undertones specifically because green carries associations of calm, safety, and medical support, and we stripped the language back to reduce anxiety rather than compound it. A pet health app carries similar emotional stakes and wants similar care.

Mapping What Vets and Veterinary Staff Actually Need

Vets work under time pressure in a way that most app users do not. A consultation slot is short, the animal is often stressed, the owner is often stressed, and the vet needs to find information, record observations, and make decisions quickly. An interface that asks them to navigate through warm, reassuring onboarding copy to reach a dosing table is not just annoying. It costs them time they do not have, and that cost compounds across a full day of appointments.

What veterinary professionals need from an interface sits at the opposite end of the spectrum from what an anxious owner needs.

Veterinary professionals need density and speed, not reassurance and hand-holding copy.

They need density, speed, and confidence that the information is accurate. They are comfortable with clinical terminology and actually rely on it for precision. Simplifying medical language for a vet does not make the product friendlier, it makes it less useful and harder to trust. On one project we ran, we found that if language is too simplified, users with domain expertise distrust the product, they suspect the underlying data is also simplified, which matters enormously in a clinical context.

Veterinary staff also need features that owners do not: the ability to add clinical notes, flag cases for follow-up, access the full treatment history across multiple animals in a practice, and in some cases communicate findings back to the owner through the same platform. These are professional workflows, and they need designing as such.

The Time Pressure Variable

The single biggest factor shaping the vet-side design is time. Every extra tap, every unnecessary confirmation screen, every piece of information buried behind a second scroll, costs a vet something they cannot recover in a consultation. The design for veterinary users wants to sit closer to a professional tool than a consumer app, because that is what it functionally is.

Where the Two Audiences Conflict, and Where They Overlap

The tensions between these two user groups are real and worth naming plainly, because pretending they do not exist leads to compromised design on both sides.

The overlaps are equally worth noting. Both audiences want the information to be accurate. Both want the product to be fast when they need it. Both want communication between them to be clear and undistorted. The record of what was said, prescribed, and recommended matters to an owner trying to follow a treatment plan, and it matters to a vet trying to maintain continuity of care. That shared record is where the two experiences genuinely connect.

Designing around the overlaps while protecting each audience's distinct needs is the core structural challenge. The mistake is treating the overlaps as the whole brief, and assuming that one clean shared interface will satisfy everyone. It will satisfy neither properly.

Vocabulary and Language: Writing for Both Without Condescending to Either

Language is where dual-audience products most visibly fail. Copy written for owners feels patronising to vets. Copy written for vets is impenetrable to owners. The usual response is to split the copy entirely between the two experiences, which works but misses an opportunity.

The more considered approach is tiered language: a plain-language layer that any user can follow, with clinical terminology available as a secondary layer for those who need it. On the genetics product we worked on, this was the decision that testing validated. Users without a science background trusted the product more when plain language was the default, and users who wanted to explore the clinical detail could do so without that detail being forced on everyone. The approach worked because it respected both audiences without requiring them to share the same reading experience.

Write owner-facing copy as if you are explaining to someone who is worried and not sleeping well. Write vet-facing copy as if the reader has thirty seconds and no patience for filler. Both are acts of respect, not simplification.

For a pet health product, this means drug names carry plain-language descriptions alongside them, not instead of them. A diagnosis label sits next to a one-sentence explanation of what it means for the animal's day-to-day life. A vet can read the label and move on. An owner can read the explanation and feel informed. Neither audience has to compromise.

Avoiding Condescension in Both Directions

The risk with tiered language is that the plain layer feels dumbed down to anyone who notices it. The fix is to keep the plain layer genuinely informative rather than vague. "Your dog's liver is producing too much of a particular enzyme" tells an owner something real. "Hepatic function elevated" tells them nothing. Informative plain language and clinical shorthand are not opposites, they serve different reading modes, and a well-designed product makes room for both.

Tiered Information Architecture: Giving Each User What They Need Without Hiding It From the Other

Information architecture for a dual-audience product needs to do something most IA does not: it needs to present the same underlying data at two different depths simultaneously, without making either depth feel like the wrong default. The question is which layer surfaces first.

A useful model is to think of the interface as having a surface layer and a depth layer for every piece of clinical content. The surface layer contains what an owner needs to understand what is happening and what to do next. The depth layer contains the full clinical picture a vet needs. Both layers contain accurate information. The difference is in what is visible without tapping.

On the concierge app project we ran for a premium property development, we made the deliberate decision not to surface all information at once. A resident who had just moved in was not mentally receptive to the full building directory on day one. We drip-fed content over time, matching it to when users would actually need it. The same principle applies here. An owner who has just received a diagnosis does not need the full pharmacological breakdown of the treatment in the first screen. They need to know what happens next, what to watch for, and when to come back. The depth is there when they are ready for it.

Think of every clinical data point as having two labels: the vet label and the owner label. Build your content model around both from the start, not as an afterthought.

Onboarding and Role Detection: Getting Users Into the Right Experience From the Start

The moment a user opens the app for the first time, the product needs to understand who it is talking to. Getting this wrong is expensive. A vet who has to sit through consumer onboarding designed for an anxious pet owner will form an immediate negative impression of the product's quality. An owner dropped into a clinical interface without guidance will feel lost and likely abandon the app.

Role detection needs to happen early, clearly, and without friction. The simplest version is an explicit choice at the start: a clean screen that asks whether the user is a pet owner or a veterinary professional, and routes them accordingly. This is not especially elegant, but it works, and clarity at this moment is more valuable than sophistication.

A more considered version uses the onboarding itself to shape the experience progressively. A veterinary professional registering with a practice licence number gets routed through a different setup flow than an owner registering a pet. The route itself signals that the product understands who it is dealing with.

Handling Edge Cases

Some users will fall into both categories. A vet who is also a pet owner may want to switch between modes depending on what they are doing. A vet nurse may need a different permission level than a senior vet. The onboarding needs to account for these cases without making the standard flows more complex for everyone else. A secondary profile option or a mode toggle within settings handles this without forcing it into the primary flow.

Permissions, Data Sensitivity, and Trust Across User Groups

Pet health data sits in an interesting middle ground. It is not subject to the same legal frameworks as human medical data, but it carries real emotional weight for owners and real professional responsibility for vets. The product needs to handle permissions in a way that reflects both.

Owners need to know what their vet can see, and vets need to know what owners can access in their clinical notes. A design that leaves this ambiguous creates distrust on both sides. Owners worry about what is being recorded. Vets worry about owners misinterpreting clinical shorthand. Both of those worries are legitimate, and both are addressable through clear, explicit permission communication built into the interface.

On a dating app project we ran, the client chose to skip the discovery process for the messaging component and focus only on onboarding. The result was a messaging feature that allowed automated and fake messages, directly contradicting the verified identity premise the whole product was built on. The mismatch cost approximately £15,000 in extra budget and two months of additional work to rewrite.

The lesson for a pet health product is the same: permissions and data handling cannot be scoped out of the initial design work. A clinical note that an owner can read without context, a diagnosis shared before a vet has reviewed it, a medication record accessible to the wrong user, all of these create real problems that are costly to fix after build.

Design the permission model as a visible part of the user experience, not as a back-end setting. Both audiences should be able to see clearly what is shared, with whom, and why.

Testing With Both Audiences, and Why Testing With One Is Not Enough

Testing a dual-audience product with only one audience tells you half the story at best. A pet owner testing the owner experience can tell you whether the onboarding feels clear, whether the language feels accessible, and whether the emotional tone feels right. They cannot tell you whether the clinical data available to vets is accurate enough, fast enough to access, or structured in a way that maps to how a vet actually works through a consultation.

The same applies in reverse. Vets testing the veterinary side of the product will not tell you whether the owner-facing communication is causing anxiety, whether the handoff between vet notes and owner summary is being understood correctly, or whether owners are interpreting clinical language in ways the vet did not intend.

On the concierge app we built for a high-end property development, we ran focus groups with two very different user groups: high-net-worth individuals who were the target customers, and people from social housing who would never be customers. We brought in the second group because they had what we were trying to build into the product: a genuine sense of community and neighbourliness that the target audience could not articulate. That outside group gave us design insight we could not have reached by testing with the target audience alone.

For a pet health product, testing with both vets and owners in the same research phase, and then testing with each in their own context, produces a much fuller picture than either group alone.

Common Mistakes When Designing for a Split Audience

The mistakes in dual-audience design tend to cluster around a few recurring patterns. Naming them plainly makes them easier to avoid.

1. Designing for the primary audience and patching in the secondary one. The secondary experience always feels added on because it was. Both audiences need to be in scope from the first design decision.
2. Using a single visual language for both experiences. The warmth and softness that reassures an anxious pet owner does not communicate professionalism and speed to a vet mid-consultation. The visual register needs to shift between the two lanes.
3. Assuming vets want simplicity because everyone wants simplicity. For expert users in time-pressured, high-stakes environments, stripping out depth in favour of simplicity actively reduces the product's value. Whether to simplify or to guide is a context question, and the context for veterinary professionals points strongly toward depth and speed.
4. Skipping discovery on one user group. This is the pattern we saw on the dating app project: the client scoped out the discovery work for messaging, and the result was a feature that cost £15,000 and two months to fix. Skipping research on either audience creates the same risk.
5. Treating shared data as the same experience. Owners and vets looking at the same vaccination record are in different cognitive and emotional states. The same data needs different presentation depending on who is reading it and why.

Conclusion

Designing a product that serves both pet owners and veterinary professionals is genuinely hard, and the difficulty is mostly in the framing. Once you accept that the two audiences need different logic, different language, and different information architecture, the design decisions become clearer. The challenge is not technical, though technical choices matter. The challenge is understanding each audience deeply enough to give them what they actually need, rather than a compromise that frustrates both.

The principles that hold across the work we have described here are consistent. Plain language with depth available as a secondary layer serves both audiences better than a single register pitched at neither. Role detection at onboarding prevents the wrong experience from forming a first impression. Permission transparency builds trust with both groups. Testing with both audiences separately, and together, surfaces problems that single-audience testing will miss every time.

Pet health is an emotionally charged space. Owners carry real anxiety about their animals, and vets carry real professional responsibility. A product that takes both seriously, and designs for both with the same rigour, earns loyalty from both. A product that picks one and patches in the other loses both.

If you are working on a product in this space and want to think through the architecture properly from the start, let's talk about your pet health product.

Frequently Asked Questions