Get Me iOS App

Rides and deliveries at the touch of a button.

Get Me is a ride and delivery service initially serving Dallas, Austin, and Houston, Texas but quickly expanding to other locations. Users can request a ride or to have a driver go purchase & deliver something to them.

Get Me iOS screens Get Me iOS screens Get Me iOS screens

Get Me iOS screens Get Me iOS screens Get Me iOS screens

Defining the concept

Prior to my involvement on this project, the founders and our agency’s leadership team got together for a strategic workshop. The original business idea was discussed, expanded, and otherwise viewed from a lot of angles and some persona types (not as refined as personas, but usable) were generated. In the end, the team felt confident in pursuing the original idea: an app-based ride/delivery service that would compete based on the “get anything from anywhere” service mantra.

Concept development

I was brought on to the project to visualize some variations of the business concept and assist in testing these ideas with users. The client had elected to hand over product owner responsibilities to one of our team members, and so he and I reviewed the primary features of the service and some of the different ways those features could vary. We then constructed 3 concepts to test, varying the feature attributes between the concepts so that we could get a better idea of what was going to work for customers.

Get Me concept matrix

Concept testing

To test our concepts, I made 3 landing page designs, each using a header image that embodied the “spirit” of the concept. The body of the page described how the service worked, and the bottom area listed features. We had participants digest these pages in random order and voice their thoughts. Using an activity in which participants put $100 of investment money on one or more concepts, we were able to assess the value of each concept as a whole and hear users explain their decision. We also had participants choose one variant of each feature as they constructed their “perfect app”. These exercises and the discussion they prompted helped us see what was appealing and unappealing to our persona types, particularly around the physical presentation of the driver and immediacy of service expected (ASAP vs. scheduled, for example).

Get Me concept 1 mockup Get Me concept 2 mockup Get Me concept 3 mockup

The outcome of the testing was a hybrid of concepts 1 and 2. Participants liked the high level of access and specificity depicted in Concept 1, but not the very upper-class concierge feeling. And they liked the more blue-collar feeling of Concept 2, but didn’t like being limited to one store—even one as comprehensive as Walmart. Concept 3 fell flat, as participants’ ill feelings about taxis kind of overshadowed everything else.

Designing the experience

With the feature set figured out and the general brand direction clear, it was time to get a clearer picture of how many screens the app would require and how they chained together. For my Sprint 0 time, I focused on creating a diagram of all the screens and the experience a user would have as they moved through the app.

Get Me app flow diagram

This diagram did change a little bit over time, but for the most part I was able to capture the entire experience before development and interface design began. Having a map like this allowed the team to make high-level architecture decisions and have productive conversations around big-picture UX and development topics.

Agile development

As I worked on the app flow diagram, the project manager was writing user stories with tasks for both design and development which the team would then review weekly and prioritize. I was able to get a head start on interface design in Sprint 1, as most of development’s stories were around setting up environments and frameworks.

For the duration of the next 6 months, I uploaded completed screen designs to InVision where I could organize them and create a clickable prototype. InVision screen names were referenced in user stories to give developers quicker reference to the corresponding visual design.

What I learned

This product has a lot of moving parts; literally, people are moving and the app needs to keep track of where they are, what stage of the order process they’re in, and when it’s over. There were lots and lots of state changes to think about and document, not to mention designing the triggers that move the states forward.

This product also has so many moving parts outside of the designer’s jurisdiction. Driver recruitment, driver training/onboarding, quality of service, servers, software services, marketing, and performance in general (just to name a few) were all areas where I was not given access, and yet these things and more directly influence the UI and experience of using the product. I see this happening more and more with projects; clients hire a UX professional for the product design but leave all of these other connected experiences untouched. Service design has definitely become of greater interest to me.

I also learned that the Agile method of software development is executed differently by everyone, and design has to be ready to put its foot down and make unpopular demands when it is not being prioritized in the building process. There’s a concept called “Design Acceptance Criteria” that you can bet I will never be unaware of again.

And of course it’s always hard to launch a product that is not perfectly polished, but I’ve left enough work in the backlog to keep the product improving for quite a while, even in my absence. :)