Portfolio

Two Native Apps

I planned to create two mobile apps, one for Customers and one for drivers. In between, I have added key interactions with the aim to delight users beyond the basic requirements of managing deliveries.

Low-Fi Wireframes

Then we started wireframing the process which helped us in making things more tangible. For early testing, we converted our wireframes into clickable prototypes and gathered feedback from few users.

User Interface Design

I turned the wireframes from low-fidelity to high-fidelity screens. We also made a clickable prototype and gathered feedback from targeted users.
We involved our users in every step. We iterated quickly, focusing purely on interactions and process flows.
Interface Design Tool: Adobe XD
Version Control: XD
Clickable Prototype: Invisionapp

Bringing It to life :
Our objective became what we’re trying to solve. Our personas became for whom we're solving the problem. Our design principles became how we are going to solve the problem for real people.

Design Principles :
Based on our user data, we constructed the following design principles to guide our work. If Logistics is truly to "come alive," then every design decision must be made in fidelity to the design principles.

Visual Design

Visual Languages :
Our research lead us to pioneer a self-driving truck service. We knew that the visual representation of Fleet had to follow suit in its uniqueness.

Visual Competitive Analysis :
Our competitor’s visual brands neither aligned to our user research nor represented the sensation of actually driving. Porter touts itself as “making a difference” with its trademark blue and photos of the environment. Our research indicated that this is a moot point among Wowtruck’s target users. Lynk and Porter’s branding represents the lifestyle created by using the service—not by driving. This created a prime opportunity to create a visual language both fresh to our domain and grounded in research.


Improving Visual Hierarchy :
Iteration 1 limited choice, by pre-selecting the cheapest, closet vehicle for the user with equal weight given to the cancel and booking options. Iteration 2 wrongfully created more options and therefore created more steps with the poorly received "book for later" option. Iteration 3 cleaned up the interface and prioritized what users wanted to see: the truck. However, the CTAs aren't given affordance as clickable items. The final iteration improves upon the UX of #3 in that it displays more information for the self hiring truck, providing an "exit strategy." The UI is stronger in #4 than in the previous iteration because #4 uses sensible, purposeful placement of shapes to create affordance of action.


Crowded But Clean :
Our user research affirmed that users expect to see a map with the self hiring truck arriving. This visual cue helped bridge the gap between what users are accustomed to and what new technology wowtruck brings forth. Iterations 1-3 mistakenly took "minimalism" too far by removing information users felt important such as arrival time, license plate #, and payment meter. Iteration 3 lacked necessary information that users found essential such as fare and drop-off details. The final UI polish in screen 4, sought to display a lot of pertinent information while showing a more elegant look with rounded corners, more white space, and translucent overlays.

User Testing

Our team facilitated three rounds of testing with our paper and then our Invison prototypes over two weeks. We gave users a the task of booking a Truck, encouraged him/her to think aloud, and we recorded how the user interacted with the prototypes. Each round helped us find "ah-ha!" and "why didn't I think of that" moments along the the way. It doesn't really matter how good of an idea I think it is; if it fails with users, it needs to change.

We found that users desire :
Clearer directions. Users expressed higher levels of confidence with using the Truck prototype when given regular and intermittent confirmations and directions.

Predictive destinations.
As a designer, I became obsessed with limiting the number of clicks a user had to complete. Users desired my low-fi prototype because it just felt “so simple.” Fewer options meant less clicks and a lighter cognitive load. Given that we needed to create “ease” into our product, this idea stuck with me. If wowtruck lives by the design principles Neighborly and Populist, then wowtruck ought to know and remember the behavior set of its user. wowtruck should store and predict where drivers might need to go. This lead to the creation of populating destinations and automating the keyboard pop up.

Multiple use cases :
Originally we designed wowtruck applications as a point-to-point truck service. A user enters in the destination, drives, and never looks away. This concept tested well.. until it didn’t. While reflecting on the prototypes after a concept test, a user unearthed a series of potential use cases to which we had been completely oblivious

Solutions

• Made the login process easier. Just enter your mobile no, verify through OTP. Done! Login via social/email
• Integrated google maps & made location selection easier.
• We noticed that ports were being used frequently in location but ports were not easily recognizable from google map address. So we made a separate port selection for easy access
• Customers can save addresses & can see recently used addresses
• Multiple stop locations
• 3D truck images with proper details so that even a new user can easily select a truck
• Hire a truck in fixed-rate pricing
• Hire a truck for the Whole day
• Book Round Trip (Updown trips)
• The shipper can select additional services according to their needs (Labor, extra weight, etc.)
• Prioritize favorite driver
• Block Driver
• A new user interface
• Reduced the learnability curve
• bidding

Reviews

The reviews are good so far. There are still a lot of things to do.

• 👨‍💻 Downloads: 50000+
• 🏆 Reviews: 500+
• 🌟 Rating: 4.1

Measure/Impact

Coming up with a solution isn't enough. We had to show its success with data/matrics. But as I mentioned earlier: To comply with my non-disclosure agreement, I have omitted and obfuscated confidential data/matrics in this case study. Here are some example metrics we used to measure the success of the redesign

• Task completion rate — Percentage of the correctly completed task
• Task completion time — the time it takes for the user to complete a task
• Engagement — How often users are interacting
• Retention — Persuading the user to use again
• Revenue — Is the product making money?

Reflections

My Proud Moments:
While this project only exists in the academic and conceptual space, we treated it as the 'real deal.' Our realistic lens didn't curb our creativity; it enhanced it. Our team was the only one in my cohort to take a leap beyond what was typical. We wanted to follow our research faithfully. So when a real case could be made for hiring a truck, we took advantage of that opportunity. We weren't afraid to venture into unknown territory. Our goal was to provide our prospective users with the best experience possible. Fleet turned out to be quite bold, both in appearance and concept.

Lessons Learned:
Divorcing yourself from being a user is crucial. Had I navigated through this design project assuming that my goals, motivations, and intuitions were the same as the target users', Wowtruck would have turned out to be a product undesirable to many. As a millennial who uses Lynk and Porter, I would have prioritized design decisions that ended up conflicting with our UX research and usability tests. Lesson learned. User data is king. Asking the right questions of the data can transform the usability of a product. During UX research, we acquired a massive amount of data. When we reached an impasse, we looked back at our user interviews and usability test reports to confirm hypotheses, refute assumptions, and chart our course. Behavioral data over attitudinal data. In our first concept test, what users said they wanted versus what they actually used was markedly different. Had we overcompensated based on what people said they desired, our product would have ultimately decreased in usability and desirability. For example, users said they liked having lots of vehicle options. Through a behavior-based survey, users consistently chose the closest and most affordable option. We, as designers, decided to address this discrepancy. Design patterns exist for a reason. Innovation is cool, but venturing into new waters must be done with light strokes. The purpose of this project wasn't to 'show off' creativity, but rather to design a solution in full consideration of constraints and reflective of user data. When we mistakenly tried to design 'outside-of-the-box' a bit too much, it caused user confusion during testing.

If I Were to Continue:
While we were proud of our final concepts, there's always more work to be done. If we were to continue working on the project, we would have added another round or two of user testing. Each time we completed a round of testing, we uncovered user insights that were previously unseen. The final polish of the UI took a few leaps from its previous iterations that went untested by users. I would have liked to confirm or refute UI decisions. We were set on creating an MVP of Wowtruck in consideration of our time constraints. Given more time, I would have liked to ideate and test more UX features, aiming to solve more experiential-based problems that users face when hiring a truck.