4Pawz - Treat Subscription Service

Bringing a concept to life, as an UX Designer with PM vision

Case Study

In-depth Process

How it all started - context

Got approached by an entrepreneur to bring an idea to life, for a service to order custom pet meals. The concept should be fit to present in pitching competitions, and not yet stand on its own.

Competitor Analysis

First things first - see what else is out there and what works for them.

Two direct competitors emerged for the service, and special attention was given to the the gaps existing in their service (eg. CTA, overwhelming with info, lack of treat only offering) and opportunities in terms of features.

User Research - Empathize Interviews

App expectations


  1. Can you describe your current schedule and how you balance your responsibilities with entertaining your dog or keeping him active?

  2. How do you order special treats for your dog? When you do, what is your motivation? 

  3. What challenges do you have when using the service? How do they make you feel?

  4. Is there any way in which you feel these challenges could be resolved?


User and their pet


  1. Breed

  2. Age of dog

  3. Special needs (allergies, intolerance, heavy chewer, training)

  4. Age, gender, location owner

  5. Budget


Result #1

Initial assumption not confirmed. A need of a treat-only service emerged: not planned meals, should also include special occasion treats


Result #2

Focus only on dogs to remove some of the initial complexities. Ability to add later

Personas

Two personas were built based on secondary research together with primary interviews. As always, personas need to be revalidated in time, as they are a conglomerate of attributes, and they represent a close-to-reality fiction.


#1

The pain points of this persona will be addressed. The main user flow shall be derived from here as well.

Persona

Persona

Persona

Persona


#2

In testing, the second persona proved to be too complex to tackle at this stage, as it would introduce more complexity points in the product.

This is a good ground for a later stage development.

User Flow

A core user flow of the first persona was created based on interactions from competitor websites.

Branding

Seeing what worked for competitors, as well as some of the words people were using when describing the interaction with their pet, a friendly-casual vibe was decided for color, typography, and copywriting.

Task Flows

While more tasks flows can be added, these were seen as the initial ones to create a working prototype.

A problem emerged that the onboarding was important if we are to solve the 2nd persona pain points, but of no clear value if not.

Wiresframes

Being easier at first, I played around with some wires, adding annotations to know what to discuss and solve down the line.

For example, the primary and secondary CTA's were not yet clear, some features were good but were not priority 0, some copywriting needed to be sprinkled on top to make sure it presents well.

Sticker components

To make life easier - I started from a sticker sheet (components).

Lessons for another day - build as you go or try and estimate better from the beginning. Not put too much effort into something that won't make itself into the app

Lo-fi Prototype

Lo-fi was mostly wasted effort, as using a better design system (components) from the beginning would save more time and give birth to more natural discussions around the product.

Usability

A first round of user usability tests were carried, but without much actionable insight.

A lot of discussion was derailled by the lack of images, functionality etc. Either more thought needs to be put into what should be shown to users, or decide to include them only on later stages of product.

However, some insights did emerge: (lack of) onboarding utility, boxes category differentiation, filter importance.

Hi-fi Prototype & Dev Remarks

After many iterations the hi-fi was ready to go.

Below you can see:
1. in red - actions which needed more work or validation
2. in yellow - to do and
3. in green - explanation for future devs


The solution was created to be deployed as a a web app, being more affordable and requiring lower effort.

After it would go live a reassessment would be needed in order to see if it would work best to be remade as an iOS or Android app.

Remaining Questions

The biggest remaining macro questions, outside those at micro level present in annotations, would be 1. if in the current state the app could evoke enough value or if more features needed to be added and 2. accessibility was not fully checked which needs more attention from the beginning

Lessons

Quite a few, the most important being:

• in terms of product: always test hypothesis with users, even if you did indirect research

• keep wires & lo-fi's for devs/PM's only - users will get more confused and you will not extract useful information. Especially in cases where you already have a design system in place

• build as you go. Scope components as much as you can from the start, but don't waste unneccesary time in creating 1000 shades of blue, and 100 button states. 3 are probably enough … whatever the question might be