Hello everyone! I hope all is well.

?

This is an early case study about my dog walking application's UI and UX design. This application has two primary use cases that are either:

1. Sign up to be a dog walker and earn money or

2. Sign up to be a dog owner and pay for dog walking services.

Defining the Problem

Every product on this planet has been created as a way to fix a problem. This problem might have been a concious one or not but either way defining a problem is a foundational stepping stone for creating an awesome product!

Without a problem on the horizon you don't really have a clear sight about what you are doing, how you are doing it and have you really done it (i.e., designed a good product).

The primary problem that lead to this dog walking application design was that the dog owners themselves found it difficult to find dog walkers. Additionally, the other spectrum, the dog walkers, found it difficult to earn money because of the same kind of problem.

Well, now we have found at least one problem - low discoverability within the dog walking community. We could now make the assumption that one way to fix this could be to make it easier for both dog walkers and dog owners to find and communicate with each other, right? This was my way of defining the problem.

Foundational Research

After having a clear sight of at least one problem, we had to validate our assumptions with our users. Is low discoverability really the problem? Is it the most painful? Is there something else that hurts both the dog owners and dog walkers?

In-depth user interview:

I started with interviewing at least one dog walker who said that he would potentially use our dog walking application if certain pain points were solved. I created a bunch of open-ended questions and got the proceeding results.

So, previously we had one high-level problem in mind, which was low-discoverability between dog walkers and dog owners. Now alongside low-discoverability we found out a bunch of other pain points: low trust, low security and feature requirements (criterias and/or briefs).

Now it seems like the most painful painpoints are low trust and security.

User research, of course, could have been done more thoroughly. I only interviewed a dog owner and should have additionally interviewed a dog walker.

Market research:

After interviewing the user I started doing market research (or competitor analysis). I wanted to know how they have solved those pain points. This was also a way for me to know more pain points and hard requirements for the minimum-viable-product (MVP).

And I learned a lot. Pawshake has a bunch of other services and not only for dog walking. Pawshake also has a guarantee for the end user. On top of all this, Pawshake uses social proof as a way of psychologically increase the conversions. I also validated that trust was indeed the most crushing pain point.

This foundational research made me realize an outcome: design a safe, secure and discoverable application for both the dog walkers and dog owners to use.

There was no need to pay attention to requirements and deliverables. What I had to do was to focus in the possible outcome. The outcome is what matters and the outcome creates impact.

Ideation & Trim

I hopped staight into designing user flows. As this is an early case study I didn't really put that much time into designing and building the information architecture (IA). I wanted to first brainstorm and create the required flows (sign up and login) and compare those against our competitors.

User flow brainstorming:

The brainstorm got me thinking that we should really just focus into creating a minimum-viable-product (MVP). Comparing against competitors is very good and a must but you shouldn't create what your competitory has. I had to keep the problems and pain points in the horizon.

Sign up flow:

Login flow:

Both the login and sign up flows are pretty basic. In most applications and websites they are a hard requirement to have. But in this case they have the ability to increase the trust and security that our dog application will have. We could create the sign up process in a way that prevents dog-abusers and thieves from getting into our system. The login flow might seem self-explanatory but the sign up flow might not.

My flows vs the competitors:

I noticed that I should not compare my flows against competitors. They are way out of my league and their UX maturity is beyond mine. I have no idea why they have designed something like they have. I have enough of assumptions already at this point.

But what I noticed was that improvements could be made in the user interface (UI) side. On top of having a better UI, another potential way of winning our competitors would be to make our product more available worldwide.

User persona:

I created a user persona that was going to be my point-of-reference during the design process. This persona was made to be like the one dog owner I interviewed.

From this point onwards everything I designed was made with Eddie Marsden in mind.

Sign up wireflow:

I created a wireflow out of the sign up flow. This was done as a way to validate the functionality of the flow rather than the visuality. I wanted to get a primitive overview of how the flow would go functionally.

The functionality stayed about the same during my design process but the UI changed a lot.

Sign up screenflow/mockup:

As you can see, the functionality stayed about the same. What I learned was that you should use wireframes as a way to validate your functionality and only then move into the visual aspect of it.

This was the first screenflow/mockup I had created and it had a bunch of problems (described in some of the yellow notes).

I then brainstormed and thought about this screenflow more and designed the following:

I fixed some of the problems in this design. Though, everything is an assumption and this should have been tested. Additionally, I had some question marks about the home page still.

Prototype

I created a simple prototype from the newest sign up screenflow. This would have been the ultimate functionality/usability stress test had I time to test this with my users.

Conclusion

As I mentioned above, this was meant to be an early case study, which naturally means that there is much to do and improve.

Though I must say that I learned a lot! I now have a clear outcome in which to focus on. I also have clear-ish sign up and login flows. But I still need to solve the trust and security pain points. I also need to make the home page more structurally and visually sound.