Assess the cost of liminality in service design - a primer on grey spaces

I’ve written previously about Liminal UX. I’ve been thinking about the ways these liminal spaces present themselves beyond interaction design and into real-world experiences. Even in government, you’ll hear people cite “front and backstage” interactions usually drawn on service blueprints or other diagrams used by service designers. The problem is, there’s a lot of stuff that happens between experiences that have no representation on those diagrams.

I envision grey spaces as the magic people perceive happens between their peer-to-peer experiences. The technology stack that exists to process their just-in-time transaction or ensures passage because their identity has been verified to perform a particular task. Ordering room service and waiting for them to cook the food isn’t a grey space because people can understand what probably needs to happen and would be able to triage the process if something goes awry. If your food takes too long, you call someone because you assume they forgot, you ordered some difficult thing to make, or some other issue. 90% of the time this process works itself out.

For service-based experiences in the public sector or the increasingly large layer of complex services that people come to rely on, with a presumption by the tech layer that these are merely “transactions between independent actors” and see themselves as merely middle-people faciliating it, has the potential to leave lasting harm on designers trying to root out harm in their designs.

**How **

For unbanked individuals, receiving money in a pinch is diffcult. Before the proliferation of apps (now connected to debit cards of their own) to make this process easier, you had to use a wire service. These wire services eventually started popping up at big box retailers around the country, making it a lot easier to receive your money in even the smallest towns on the map.

The identity proofing in received or sending a wire is a pretty high bar. You have to show ID in person, it has to be sent to a specific location (unless you’re doing it online) and there’s a several digit reference number that the person picking up the mpney needs to have. They will also need to show ID upon appearing, before the money is disbursed.

On the other hand, that same person having someone send them money through an app would need to send nothing other than their user ID. A simply alert screen popup asking if you’re sure you want to send it to this (potential stranger) person is all that separate you from your money. The bar for making a mistake wiring someone money is much greater. There’s also recourse, as within a particular set of time, a purchase might be able to be voided. In the app scenario, your money cannot be retrieved in most cases, even if you immediately catch the mistake.

In another scenario, a car accident where a ride-share driver hits someone while passengers are in the car now has several issues on their hands. They need to ensure their customers are made whole, they have to deal with the accident too. The ridesharing company bears no responsibility if they decide the driver was not riding for them, even if you could verify that they were doing so at the time.

In the past, a taxi driver would have called another cab for his passengers while he dealt with his accident. In this situation, the app layer gets to collect their fee, the passengers technically were the customer of the driver and not the platform. Surely they’ll figure it out, but these kinds of experiences exist all over our economy and for so many people, they’re simply grey spaces that happen invisibly everyday.


Built with Jekyll, Github, VSCode and served via Netlify.