UX Case Study 001: Direct to Consumer App Broadcasting

The app says it lets users watch sports on their phones.

However, the government controls where the phone is allowed to be for streaming to work. As a result, users end up missing their games.

This was only triggered when the user chose to not allow their location, and appeared in the form of one ZipCode input field per page, alongside teams available to that ZipCode.

Seen above are detailed handoffs extending existing design systems for a feature to solve for legal requirements: "Users need to be watching from the Same ZipCode as their Registered Home Zip Code location" (as per United States legislature) in order to watch the streams they paid for.

Here are some accompanying images contextualising dev handoff. This highlights SHOWING users what their Zip Code ALLOWS them to see.

The legal thinking behind this is basically to enforce users be viewing solely from the location they call home. This is a bit contradictory as the application itself presents itself in the context of a direct-to-consumer mobile sports viewing app that promises live content. If I put my Santa Monica home address in, I wouldn't be able to watch the Lakers from my phone if I was in Mid-City, Downtown, Koreatown, etc.

Additionally, this limits users' purchasing selections to only a limited range of content based on the ZipCode that their home is in. The reality for the United States is that (1) ZipCodes are very gerrymandered and (2) people's loves for their sports teams aren't decided by how legislature turns a map into puzzle pieces.

Such confusion came about many times in discovery, prompting a two-pronged onboarding zone that would allow users two instances where they might be able to input their home zip code, in order to overcome existing limitations.