A scalable solution for localized legalese and price formatting

Time frame: 2018–2019

Role

As Principal UX Designer, my role was to lead the creative process, collaborate closely with product, dev, and other cross-functional partners, frame the project goals and perspective, audit and document our current experience, define and document detailed specs for the solution, and ensure we met the dynamic requirements of the project to learn and improve upon the calendar experience for the user.

Problems to solve

As a user,

The content in the calendar experience collides, overlaps, and breaks because of the limitations of the formatting.
It is challenging to quickly compare prices across days and weeks in the calendar.
What does the price I am looking at represent? Per person? Per roundtrip?
What currency are these prices in? Is it accurate based on my POS?

Legacy issues

Localization, specifically price and legalese use cases and formatting, was not properly considered, explored, or defined from a systems level.

Observations

Analytics

Sensitive.

How do we manage currency localization on Expedia today?

We get our currency localization formatting from a db loosely based on the i18n library. Below is an enhanced version of that library. However, there are still a few outstanding questions that need to be answered:

By what standard are we basing this formatting?
Which POS’s numerical price strings can be abbreviated? Example: The United States of American dollar: $12,300 can be abbreviated to $12.3k.
If a POS’s numerical price string can be abbreviated, then how do those abbreviations work exactly? Can we also have a 1,000 and 10,000 example for reference of each POS that can be abbreviated?
For clarity and consistency, could we include the relevant ISO-4217 code in the legalese at the module-level and/or page-level?
Making any edit or addition to both legalese and currency formatting will have widespread impacts globally so how should be manage a solution rollout?

Competitor audits | Google flights example

A comprehensive collection of competitor audits was conducted. Below is an example from that audit:

Google has an inconsistent localization pricing format experience at both mobile and desktop that serves a singular purpose: Showing prices/numbers in the date picker for any currency regardless of localization issues and the inherent user problems that will be created from doing so. While we share the same goal of showing prices for any currency in the date picker and we can learn a lot from Google, their approach lacks coherence and simply falls short of a global design system solution.

They use the following formatting at mobile:

Currency symbol + numerical price string.
Currency symbol + abbreviated numerical price string.
Numerical price string.
Abbreviated numerical price string.

They use the following formatting at desktop:

Currency symbol + numerical price string with a from price which includes a currency symbol + numerical price string.
Currency symbol + numerical price string with a from price which includes an ISO-4217 code + currency symbol + numerical price string.
Currency symbol + numerical price string with a from price which includes an ISO-4217 code + numerical price string.
Currency symbol + abbreviated numerical price string with a from price which includes a currency symbol + numerical price string.
Currency symbol + abbreviated numerical price string with a from price which includes an ISO-4217 code + currency symbol + numerical price string.
Currency symbol + abbreviated numerical price string with a from price which includes an ISO-4217 code + numerical price string.
Numerical price string with a from price which includes a currency symbol + numerical price string.
Numerical price string with a from price which includes a ISO-4217 code + currency symbol + numerical price string.
Numerical price string with a from price which includes a ISO-4217 code + numerical price string.

United States of America (English) in USD

At mobile, they are using a currency symbol + numerical price string, but lack any other context as to what currency the user is seeing.
At desktop, they are using a currency symbol + numerical price string and also include a from price and supporting pricing context for one way just left of the “Done” CTA. But, like at mobile they lack any other context as to what currency the user is seeing.

Japan (Japanese) in JPY

At mobile, they are using a currency symbol + an abbreviated numerical price string, but lack any other context as to what currency the user is seeing.
At desktop, they are using a currency symbol + an abbreviated numerical price string and also include an unabbreviated from price and supporting pricing context for one way just left of the “Done” CTA. But, like at mobile they lack any other context as to what currency the user is seeing.

Indonesia (Indonesian) in IDR

At mobile, they are using an abbreviated numerical price string with no currency symbol and lack any context as to what currency the user is seeing.
At desktop, they are using an abbreviated numerical price string with no currency symbol and also include an ISO-4217 code + unabbreviated from price and supporting pricing context for one way just left of the “Done”CTA.

Denmark (Danish) in DKK

At mobile, they are using an abbreviated numerical price string with no currency symbol and lack any context as to what currency the user is seeing.
At desktop, they are using a currency symbol + an abbreviated numerical price string and also include an unabbreviated from price and supporting pricing context for one way just left of the “Done” CTA. But, like at mobile they lack any other context as to what currency the user is seeing.

Switzerland (German) in CHF

At mobile, they are using an abbreviated numerical price string with no currency symbol and lack any context as to what currency the user is seeing.
At desktop, they are using an abbreviated numerical price string with no currency symbol and also include an ISO-4217 code + unabbreviated from price and supporting pricing context for one way just left of the “Done”CTA.

Hypothesis

If we can create a solution for concise legalese, currency formatting, and lengthy currency + numerical strings in the calendar, then going forward we will have a consistent, usable, accessible, and scalable pattern that will result in an optimized and reliable customer experience.

Metrics for success

Increase in engagement/interaction.
Increase in usability and accessibility.
Increase in progression from storefront → FSR.
Increase in progression from FSR → UDS.
No negative impact to overall conversion.

Scope and considerations

This is phase 1 of a 2 phase product release.
Brand/POS.
Platforms and devices.
UITKv2 styles and components → UDS styles and components.
One-way flights with consideration for all trip types.
Usability.
Accessibility.
Scalability.
Performance.
Localization.
Interaction patterns.

Design solution

Our solution was twofold: Legalese at the module-level and/or page-level to help clarify what the price means as well as a perspective and solution on localized currency symbol + numerical price strings (complete & abbreviated when applicable).

This work would have it's limitations though. I was constrained to the guardrails of the UITKv2 calendar component. However, I could bend its limitations, just as long as it was justified and didn't add too much time for dev post-design. And, due to limited usage and restrictive constraints, SEK, NOK, DKK, and CHF currencies were solved for but descoped from this project.

Legalese

For clarity and consistency the [currency], which equals the relative ISO-4217 code per POS, should be included in the legalese at either the module-level and/or page-level.

Date picker (module-level legalese):

“Prices are one-way per person in [currency].”
“Prices are roundtrip per person in [currency].”
“Prices are per person in [currency].”

FSR (page-level legalese):

“Prices are one-way per person in [currency], includes all taxes and fees, but does not include baggage fees.”
“Prices are roundtrip per person in [currency], includes all taxes and fees, but does not include baggage fees.”
“Prices are per person in [currency], includes all taxes and fees, but does not include baggage fees.”
At mobile, in some localization instances the legalese string may extend beyond the limited and require wrapping.

At mobile, in some localization instances the legalese string may extend beyond the limited width of the container and require wrapping.

Localized currency symbol + numerical price value

Below is the comprehensive solution matrix for all POS.

Localized symbol + numerical price value matrix

What works, creates collisions, or breaks the experience at mobile (320px)in UITKv2 and UDS?

22 out of 46 POS work in the experience with abbreviations.
24 out of 46 POS create collisions in the experience with and/or without abbreviations.
17 out of 46 POS break the experience.

The mobile experience

At the Mobile breakpoint (320-491px) the calendar will,

Display one month at a time.
Be horizontally centered for scaling.
And the width will be set to 100% viewport-width up to a max-width of 479px.

Each table cell should always retain a minimum of 3px padding-left and padding-right to reduce content density thereby making the experience more scannable and usable. Text should never overflow or wrap.

Mobile (320-491px)

At 320px (min-width), the following supported POS will display prices:

Mobile 320px

At 375-491px (max-width), all POS will display prices in their unabbreviated complete form:

Mobile 375-491px

The tablet experience

At the S Tablet (492-725px) and L Tablet (725-959px) breakpoints the calendar will,

Display one month at a time.
Be horizontally centered for scaling.
And the width will be set to a fixed width of 479px.

Tablet (492-959px)

The tablet experience

The desktop experience

At the Desktop (960px+) breakpoint the calendar will,

Display one month at a time.
Be horizontally centered for scaling.
And the width will be set to a fixed width of 947px.

Desktop (960px+)

The desktop experience

What did we learn?

Increase in functionality, usability, reliability, accessibility, and performance.
Inconclusive impact (∓) in engagement/interaction during the test period.
Inconclusive impact (∓) in progression from Storefront → FSR.
~4% increase in progression from FSR → UDS.
~.1% increase in overall conversion.

This work was baselined across Brands/POS.

You can easily access and use this feature today if you're booking a flight on Expedia and want to quickly compare prices across dates.