Your on-demand friend with a truck,
UX Case Study
Ever tried to move a couch with a car? How about a bed? What if you don't even have a car? What if you don't even have a license? What if you just broke up with someone and need to get your stuff out ASAP?
You mentally scroll through your contacts list trying to think of anyone who has a truck that may be willing to help you. You may even throw out a post into the social universe promising something like "pizza and beer" in exchange for hard labor AND the use of a truck. I've discovered through multiple interviews this groundbreaking, and universal truth:
User Research - Needs/Goals
I conducted a Facebook search for posts containing the words, "help me move," and as suspected, this gap in service is widespread and ongoing, affecting users of almost every demographic. The motivations for a user to need a truck can be broken down into 5 basic scenarios:
1) Buying - A user is buying an item from a seller that does not offer an acceptable method of delivery for the item.
2) Selling - A user is selling an item but does not have access to or want to be responsible for the delivery of said item.
3) Moving - A user is moving to a new location.
4) Storage - A user needs to transport all or some items from one location into storage.
5) Trash - A user is purging the item(s).
People move. We are not trees. Along with ourselves, we move our stuff. We need a better solution for this than what currently exists.
See for yourself. Check out some of the results of the "help me move," search.
Occupation: Customer Service Representative
1) A truck or way to transport large items.
2) A friend to help her with moving large items.
3) Needs to move quickly and doesn't have time to schedule or coordinate help in advance.
4) A way to transport large items she buys used/online.
1) Cannot always plan moves in advance. Her needs are sometimes reactive instead of proactive.
2) She is strong but she's only one person. She needs at least one other person to help her lift large items.
2) Does not have a large budget.
3) Often only needs one or two items moved so a full-size truck rental does not fit her needs.
In any of these 5 possible scenarios, a user that does not own or have immediate access to a truck is faced with the following options:
Borrow a truck - User could have a friend, family member, or colleague that they ask to borrow from.
Problems with this solution:
- User is at the mercy of someone else's schedule
- Inconvenience to friend/family member/colleague
- Difficult to find someone both willing and able to assist or loan out vehicle
- User has little to no say in when, where, or how of logistics. ie. "Beggars can't be choosers."
Rent Truck / Hire Movers - User could alternatively hire a moving company to assist with the job, or rent a truck from a rental agency and facilitate the loading/unloading themselves.
Problems with this solution:
- Need to schedule or reserve in advance
- Online booking is either difficult or does not give pricing
- Quotes are often inaccurate or there are hidden costs
- Having a reservation does not even guarantee truck availability
- Truck rental does not provide assistance with load/unload of items
- Requires a large deposit to reserve
- Requires a credit card
- Requires a drivers license and additional insurance if not already provided
- U-Haul forces the user to rent a truck for a full day, even if only an hour is used
- Home Depot charges by the minute and uses complex algorithms to calculate costs instead of just using a flat per minute fee
Truck Rental Costs
Let's say Carrie purchases a couch and recliner from a Facebook Marketplace Seller. She needs to pick up her items and bring them to her apartment, but her new boyfriend and her brother are going to help with the heavy lifting. The distance between her and the seller is 4.9 miles and a 13-minute drive. This is what the costs would be across different platforms for the exact same job:
|Home Depot||$74.00||33.07% +|
Hiring a Moving Service
Per the suggestion of Budget.com during their online truck reservation process, I was directed to a partner site called Movelift to reserve additional assistance with my move. The pricing for 2 hours of moving services on a Wednesday afternoon, provided by a local, two-person crew are as follows:
|Campus Pit Stop||$473.57||149.54% +|
|King Staff Movers||$449.83|
|Moving Ahead Services||$320.90|
|Mount Up Moving||$245.25|
|MSG MOVING LLC||$238.60|
The Muber pricing algorithm will make it the highest paying ride-share service for drivers, and the lowest costing moving / truck rental option for users.
Team and My Role
Product Owner/Creator: Dana Shelton (me), User Research, (UI) User Interface Design, (IXD) Interaction Design, (UX) User Experience Design, Database Design and SQL coding, Pricing algorithm, Wireframe, Prototype, Coding for Authentication and Payment Components (Auth0, Braintree), Front End Development
Partner: Joe Burnett, Backend Developer, Too much to list
First product version: Matt Frey, Mapbox Developer, Catherine Levengood, Admin
"There are no bad ideas on the whiteboard"
The first thing I did to begin planning was to use design thinking to define the minimum viable product (MVP) and a strategy on how to get there. This is the part where the user's needs are translated into a product that is beneficial to both the user and the business. It's the proverbial prize that we will be keeping eyes on for the rest of the sprint, so it is crucial that everyone is on board with what we are doing and why.
This is probably one of my favorite things to do because I allow myself and anyone else that may be participating the freedom to come up with anything in the world without judgement or questioning.
I made a list of all the features and options I could think of on the whiteboard. Then I talked to people. I tried to understand what they imagine to be important in an app like this. I had not considered adding a 'Ride History' link in the account navigation, but it was brought to my attention through in these conversations.
Next, I do some card sorting to see where each piece would make sense and fit into the bigger puzzle with the others. At every stage of the process, I am comparing what I have with my definition of the minimum viable product. "Is this meeting the requirements for what I'm building?" "Is it a 'need to have' or 'nice to have' feature?" "How will this benefit the user?" These are the questions I constantly ask myself throughout the entire project.
I usually start the early stages of the design process with low fidelity prototypes. I also think that calling them 'low fidelity prototypes' is ridiculous, for the record, but to appease the site crawlers here, I'll use the proper terminology.
This is the way I iterate through many design options quickly and stay on track solving a big picture user flow without getting too hung up on small details.
The sketches bridge the gap between design and development with a roadmap.
Being both a designer and a developer is great. It gives me a unique advantage in being able to understand and communicate in terms that are respectful to both departments. However, I cannot speak any two languages at the same time. The plan I develop in this phase is what will prevent me from going too far down rabbit holes like debugging functions or perfecting gradients in the design system. It is vital to be thorough in this stage.
Mom: "Is your friend with the truck going to help you move on Saturday?"
Annoyed 18-25-year-old: "No Mom. That's what Muber is for, obviously."
Mom: *Sends thank you card to Muber for getting her bratty kid out of her house.*
You're welcome, Mom. 👍
In the case of Muber, I did not wireframe a low fidelity mockup for several reasons. Turnaround time for the project delivery, only working with a small team, and a lack of a good argument for adding an additional step to the development process were all factors in my decision to skip this step for this project.
Instead, I designed and prototyped the high fidelity mockup concurrently. This resulted in a truly interactive demo piece that could be iterated on throughout the product lifecycle, while at the same time provided a design system and usable assets for production and development. Without luxuries like time or people, this was the only viable approach to meet the deadline.
In any case, we built a completely new marketplace out of thin air in about 9 days and it looks great. We can label it "Operation: Bandaid, Moonpie, Pop Tarts," if you want. All that matters is that the minimum viable product was completed on time, with zero budget, and phase two was started ahead of schedule. I just wouldn't EVER recommend this as a standard operating procedure.
As you can see from my random tire backgrounds and font selections, I did not get the design perfect on my first try. Honestly, it is never perfect but that's what we call "emergent design." Design should evolve over time and grow through the product life cycle.
In this case, I used Android Design guidelines as a basic foundation, but only because I personally have an Android phone so that's what I was testing on.
The reason that the platform was not my main focus is that I know the application will adapt to the environment it is natively deployed in because of the language it's built with.
React Native is awesome. The "Native" part of it takes one code base and adapts it across both iOS and Android platforms. So when you see a permissions request that looks Android in the prototype, it looks completely different on iOS. The same is true for keyboards, clocks, etc. Knowing this prevents me from getting hung up on trivial considerations about GUI's in the wireframing phase.
I developed and conducted user surveys to evaluate the project in its current state.
I deployed a heuristic survey that would record users interacting with the prototype and ask them some simple questions along the way.
1) Understand the most used or preferred third-party login options
2) To identify the most popular online marketplaces or additional unknown potential applications for targeted marketing strategies
3) To determine the overall usability of the application
4) To identify any unknown possible competitors
5) To survey users on alternative Names for the application
Source: Userlytics provided
Location: United States and Canada
Social Networking: Any
Preferred Platform: Any
Number of questions: 13