Managing User Digital Product Baseline Expectations with Physical Variable Dynamism

Summary

• Do not assume that users are aware of their current expectation baseline and how that can vary when using your application in different contexts, devices, countries or when other variables are changed. This is particularly important to remember when those variable changes are not user initiated.
• Consequences of assuming that users will anticipate and recognize that their expectations should change based on the operational context can include customer dissatisfaction, app uninstallation, and elevated support ticket volume.
• Applications can provide massive additional value to users with smarter deductive logic that considers human skillsets, expectation baselines and aptitudes, all at a lower cost than support tickets and refunds.

Example #1 - User Personas for a Pizza Delivery Application

During product design, user personas are customarily generated according to a set of specific criteria:

• For example, assume I am building an international mobile-based pizza ordering application, where I deliver pizza in the United States, South America and European countries. The company has physical stores and delivery personnel, but mobile ordering and delivery has started to become more popular.

A user persona summary table with key differences might look like this:

In this admittedly contrived, but delicious, example above, we can see that we share a single persona across regions, and that there exists a single persona unique to each region.

Assume for the sake of discussion that your application personas are completely accurate and the application is functionally perfect from a software standpoint.

These personas unfortunately do not take into account the educational component required to ensure that a “Hank” ordering in the United States is prepared to order in Europe or South America. Even if the ordering flow, language, and app experience are identical and properly localized, Hank will still likely be surprised by the physical pizza itself given the different underlying ingredient makeup, the delivery method and speed (bikes deliveries are potentially faster or slower than vehicles), and the language for error resolution (Hank wanted to order Pepperoni, not Sopressata, which is popular in Italy. How does he resolve that if he can’t speak Italian?).

Bottom Line – Even though the personas have been localized and the user order flow has been nailed, user expectations for the product were still disappointed because the application failed to educate the user that their baseline expectations for the pizza “product” should be different. There should be an additional row in the table above for user expectation adjustment that delineates potential points of difference.

Example #2 – Uber in Foreign Countries

Ride hailing applications are incredibly convenient, particularly in foreign countries where language/payment differences can make hailing a taxi difficult. On a recent trip to Panama and Colombia, where Uber has a presence, I was able to use Uber to great success, but my baseline expectations for the product should have been adjusted before I ordered my first car.

While the software experience is largely identical to ordering a ride in the United States, there are some significant user experience differences:

• The cars are typically of lower physical quality (Ex – A black car in the United States is typically a Lincoln Towncar, in Colombia it could be a Black Honda Civic w/out A/C. Yet, it is still marketed in the app as a “black car”.).
• Drivers that are delineated as speaking English actually speak English with varying degrees of fluency.
• Ride prices are quoted in the local currency and no estimate for my home currency is provided, even upon ride finalization.
• Drivers will frequently ask you to have at least one passenger in the front seat due to Police/Taxi dislike of ride hailing services, and the chance they will pull them over.

To be clear, all of these issues are completely reasonable and warranted given the circumstances and context. However, I, as the user, had to recognize and readjust my expectations of the physical manifestation that a digital application produced. If your initial response to this is that users aren’t that difficult, Uber riders frequently rate their driver poorly for the traffic, which is entirely beyond the drivers control.

Bottom Line - Your typical user will not be as forgiving, and even if they can manage the differences, support ticket and complaint volume will be elevated. Even if you can’t control the physical variables your application may interact with, you can attempt to readjust the users baseline expectation before they are altered by those variables.  This reeducation is largely free and scalable, support tickets and refunds are not.

Example #3 – Google Maps in Adverse Weather Conditions

As a consequence of my prior roles, I have done a significant amount of driving in the United States, some unfortunately in adverse weather conditions.

While Google Maps is an incredible application, it necessarily has to interact with the physical world.

Along the lines of readjusting user expectation baselines, Google Maps does not take into account where the user spends the majority of their time in their route / traffic descriptions.

For example, this can be dangerous or fatal when road conditions worsen and Google continues to optimize for shortest/fastest/lowest traffic route.

As someone who has spent 99% of their time driving in California and Arizona, states with minimal snow and rain, routing me through a blizzard on the East Coast despite it being the fastest route is a bad idea. Google already knows where I’m from, my location history, and could extrapolate that it should warn me both (A) about the weather conditions I’m about to drive into and (B) that I might need snow chains or adverse weather equipment to drive safely.

A response to this might be “My application is never going to have as much data as Google’s will” or “It could even feel like an intrusion of privacy to make those recommendations.”

These are both largely insufficient: even if you don’t have the relevant data, it is still a worthwhile exercise to think about how your users’ expectations could/should change and make proactive suggestions, where the frequency is based on your confidence in your prediction and the potential consequences of not warning the user.

Another response to this could be “Well just use Waze, it warns you about weather and a ton of other road condition variables.” That is true, however, it doesn’t take into account where I’ve spent the majority of my time driving and adjust its prompts accordingly. For example, if you are from the East Coast, and are driving from Phoenix to the Grand Canyon in the summer, it will not warn you that you should turn off your air conditioning to avoid overheating when it is 125° outside.

Bottom Line – It is worth thinking about user baseline expectations and how your application might provide massive value with a marginal amount of additional data and deductive logic.