Published on | Prototyping: From UX to Front End — Medium Pontus Persson

This project was bootstrapped and we only worked on it over evenings and weekends, on the side of our daytime jobs.

Ella Blowdry is a startup that was created by me and 4 co-founders from different backgrounds. Only 2 of us had real world experience from designing and building an app.

It was unlike any other project I have been involved in. While I’m usually part of a larger product team with clearly defined roles, I was all of a sudden covering a huge amount of responsibilities.

I will write this case study from a UX point of view but for this project I have been a stakeholder, product owner, photographer, visual designer, UX designer, frontend developer, project manager, ‘marketing guy’ and an all around hustler. Some might call it entrepreneur.

On the product side of things it was me and our iOS developer, Alejandro. Things didn’t always go as planned but I’m proud of what we achieved.

Background

The idea of the app is to allow professional London women to get a blowdry subscription at top rated salons and make instant bookings through an app. Two of our founders (who are professional London women) had the following problems:

Find a good rated salon close to their current location
The process of making a booking
Not being able to find instant availability

We found a need for an app that, similar to how uber connects taxi riders with drivers, connects blowdry clients with top rated salons.

Research

The first thing we did was defining our target group and went out to survey them. We questioned 114 working women in central London about their haircare habits, problems and wishes. We found a few interesting insights that encouraged us to start developing the app:

Over 60% shared the same pains as our 2 co-founders.
Over 90% shared at least one of their pains.
Over 70% said they would go more often if they could book the appointment “like an uber”.
Over 65% was positive to a subscription model.

An other interesting point is that we found a successful company with a similar business model in the US, which gave us even more confidence and urgency to get things moving.

Definition

By now we knew our audience, their pains and what would ease that pain. We sat down the entire team and drew up ideal user journeys until we landed in something we were all happy with. We also listed out other beneficial features and prioritised them in order of importance.

Then we sketched out ideas for the main screen on paper before I went away to turn them into a digital prototypes.

Inspired by apps like Uber and Deliveroo, we decided to make the app for both clients and salons, depending on your account type you would see a completely different interface. This would save us a lot of manual work and meant we didn’t need to approach integration partners.

(We called the app ‘Doozy’ in the early stages)

Client app

Early stage user flow, notification map and waiting list requirements. These changed slightly after validation.<a href="https://medium.com/media/f220d9556196af1f225dce8fb1fcca3c/href">https://medium.com/media/f220d9556196af1f225dce8fb1fcca3c/href</a>

Salon app

The salon application: Incoming booking flow<a href="https://medium.com/media/e61080abfe295e95cee9c7ced38ca4dd/href">https://medium.com/media/e61080abfe295e95cee9c7ced38ca4dd/href</a>

Validation

Now we had enough to validate our assumptions, so we tested the client application with over 10 participants. We found that:

Participants understood the concept and how to use the app.
They would use the service if it is same price or cheaper than booking straight with salon.
They would get a blowdry more frequently if it was this easy to book.
Most users missed the time selector or didn’t understand how it worked.
Most users didn’t instantly understand a few other components such as the salon detail view and the booking confirmation screen.

Very good feedback! We got the concept validated again and the only negative feedback was related to the interface which is easier to change than the business model.

I tried many different solutions to solve the unclear way of picking the day and time. First trying to keep the day and time selectors on the same level (first prototype below), but ended up stacking them on top of each other (second prototype). We also placed the book button under the time selector to make them look like a unit.

<a href="https://medium.com/media/f94054747024638a1317d32eac3b7901/href">https://medium.com/media/f94054747024638a1317d32eac3b7901/href</a><a href="https://medium.com/media/9e6b69746295bcc25941dd9fac1a5317/href">https://medium.com/media/9e6b69746295bcc25941dd9fac1a5317/href</a>

Since we were working evenings and weekends, taking on the other tasks of building the company and with life getting in the way, we got a little disconnected at times. This meant that the validation took longer than expected and we started building based on our assumptions.

Build

In hindsight we had overlooked to validate a couple of key assumptions:

Building the salon app before we validated if the salons would use it. At this point we had just spoken to a few salons. Further down the line when we got closer to making deals we realised there was no need for it and that we had built it, almost to completion, in vain.
We had built the custom time selector before we realised it wasn’t comprehensible in the validation testing.

Both proved to be a waste of time but we learnt from it.

Plan B

As a result of scrapping the salon app, we needed a new way to manage all incoming bookings. We started approaching the leading booking system providers and we are still in talks with them regarding an integration. It is currently on our roadmap and very feasible but we needed a backup solution that can work during the time we are working on the integration.

While we store all booking data in our database, it is not safe for anyone other than our developer to poke around in there. That’s why we decided to build a back office to manage bookings and public salon information. When a user makes a booking, we will get notified and call the closest salons on their behalf. This meant booking confirmations went from taking seconds to up to 15 minutes, which meant we had to update the client app UI to explain that.

That’s the only main issues we had on the product side of things. The other features of the app and back office went quite friction free, despite the fact that we only had one developer, one designer, tiny budget, full time daytime jobs and other commitments.

Refinement

Once we had a usable application, we started the work of tightening the bolts and refining the flow. We made sure users were invested enough to come back and worked on making sure it is always rewarding to open the application. By following a similar waiting list structure as Monzo, we’re hoping to get users socially invested in the app at an early stage and as soon as they are subscribers they would be more keen to use the service frequently.

While I’m pretty sure the end result would have been much better with a full time team on the task, I’m proud of what we achieved under the circumstances. Taking on that much responsibility taught me lessons on both a personal and professional level.

Impact

The application is now live and ready for action. Hair industry guru Hellen Ward (Owner of Richard Ward salon) has joined our team to help us set up the salon partner relationships before we can put the application and our business model to the real test.

If you are interested in the product, download the app and join the waiting list. If you own a salon and want to speak to us, get in touch!

Back to portfolio

UX Case Study: Ella Blowdry was originally published in prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

UX Case Study: Ella Blowdry

Cool stuff, every week

More Articles