February 25, 2016 5:32 pm



The Problem

Making the process to book an appointment and checkout a breeze, accounting for 'guests', split payments, and rebooking.

The Solution

Maximizing the efficiency of checking out by making it simple to duplicate a current or previous appointment. We also explored new technologies for mobile payments to make it possible for one person to book an appointment for multiple people and still allow separate payment.

The Process

This project had a tight deadline. A week was dedicated to wireframing every step of the booking and checkout processes, with occasional input from the client. I began with whiteboard and moved to pen and paper to sketch out as many screens as I could. While another UI Designer brought the wireframes to life, I refined wireframes and bridged the communication between the client, designer, and developer to make sure everyone was on the same page at all times.

The Impact

Official data isn't available, but the app has been downloaded over 1,000 times (on Android) and well received on Android and iOS. Both versions have been praised for the painless experience provided.

Project Details

Back in early March, a class friend of mine asked me about finding her a designer who would be interested in taking on a project to help redesign a mobile application. The role needed to be filled quick to hit an approaching deadline of April 3rd, opening weekend of the Coachella Music Festival. We couldn’t really find anyone we knew personally and could trust, so I settled for taking the role myself. Initially, my role for the project was to develop the user experience, create wireframes to hand to a designer, and finally translate the designer’s mockups into CSS for a developer to implement. All this remained true, with the added task of fully fleshing out the front-end in a way that the other developer would integrate it with his current system.

Before getting into the details of the project it’s probably a little important to know our client. They are a startup that send hairstylists and makeup artists to their customer’s location to “be glammed” (ha). This we-come-to-you mentality removes the burden of the customer having to take time out of their day to make a trip to a beautician and gives the convenience back to the customer.

For a couple of days, I toyed with the existing app and did a full teardown of what worked and what didn’t. Work on the new app began promptly on Saturday, March 7th and carried through March 8th. Three of us – Amanda, Fei, and myself – met up and filled whiteboards with the faults of the pre-existing app, the client’s desired features for the new app, and fleshed out wireframes of the ideas that were tossed around.

Our designer, Fei, took all of the approved wireframes and designed stunning mockups of every page. After review, I set to work and developed them exactly as she designed them, taking note of every pixel.

The most prevalent issue was our lack of time. We had a tight deadline: design and develop an HTML application from March 7th to April 3rd in time for the Coachella Music Festival.

The most important part of designing the user experience was developing a better process for booking services and checking out. An important factor that we had to be careful with was the order in which the user was prompted to choose a location, set an appointment time, and select the services. Prices, available stylists, and other options were dependent on the order in which those things were selected. We revised the order several times for two weeks and had to revise the design 4 times to make it work.

One issue I hadn’t considered and prepared for was the fact even though I’m fairly balanced in design and development, Fei was not familiar with development and our developer was not very familiar with design (both aesthetic and technical). This resulted in Fei underestimating our capabilities in development as well as overestimating what we could achieve within our timeline. When the mockups were returned to me for development, I was forced to sacrifice some design choices in favor of rapid development.

In contrast, I had a high expectation of our second developer, or at least expected them to have a basic understanding of things that I knew. When I developed our designer’s interface mockups, I made conscious decisions on how things were named or would be handled in the back-end because the developer reassured me he would be able to read through it and make sense out of it. As it turned out, I developed the front-end under the presuming that the back-end would be data-driven and handled in an object-oriented way. It was not. Additionally, my use of some frameworks and libraries, like SCSS and jQuery, were a out of the developers scope of knowledge.

Check out the images below to see a little bit of the process and final product. You can also check out the app on Android and iOS.