Desirable ‘Aftermath Targets’ in consumer experiences

We rarely design endings that are anything more than convenient for the service provider. These usually end up being a quick goodbye, and then a bombardment of emails resplendent with fake sympathy. The aftermath for the consumer - their emotions and occasionally their anger - is considered their own problem. This is actually far from that; companies should start considering endings as part of their responsibility.

The negative emotions and feelings of the user may linger after a consumer engagement and can tarnish the brand of the provider. Avoiding this with purposeful, and considered closure experiences when the consumer off-boards your product or service can alleviate that problem.

Someone recently asked me what is the best account deletion flow for an app. Which is great to hear, as many people don’t even get as far as caring. As a way of answering this question I thought I would write up some aspects which I think need to be considered when off-boarding a consumer.

Firstly, many basic UX issues still apply at off-boarding - clarity of progress, setting expectations, notifications. Secondly, some wider techniques I have outlined in earlier posts can really help - consideration of Transaction Models, understanding of what type of Closure Experience your aiming for and I certainly suggest using Post Service Personas as a method of empathy for designing Closure Experiences.

Lastly, I want to highlight a new addition to this tool set - Aftermath Targets: where is the consumer going to end up emotionally after leaving your service? 

Broadly, we retain comfortable or uncomfortable memories of a service or product. If that memory relates to a service or product of your design, you are probably hoping that it will be a positive one. Considering what type of Aftermath Target you want them to feel after leaving, and designing towards that will maximise your chances of being fondly remembered.

There are many Aftermath Targets that might be felt by the consumer after Off-Boarding, you might have specific ones in mind but, for the purpose of explaining the model I will use 3 of the most common ones: reflection, rebirth, and rest.

Reflection - Look back at a wonderful experience
Rebirth - Released to take part in another experience
Rest - Provides an opportunity to rest, a moment of silence

Some endings can be dominated by just one Aftermath Target, but most are a mix. For example, the end of a holiday will give you a sense of Rebirth, and occasionally you will think about the holiday after it has ended - Reflection. You should not require Rest after a holiday, unless the holiday was awful beyond belief.

After a particularly difficult and contested relationship with a service provider we may feel a strong opportunity for Rebirth, and a sense of Rest, but few would want to Reflect on what was a bad experience. 

When we buy a new computer to replace an ageing one, we rarely want to Reflect on it or Rest, but the desire to Rebirth in to a new relationship with new features, faster processor and increased storage will energise our new experience.

After using a car for many years and getting it scrapped we might feel many memories and subsequently end up with many Aftermath Targets.

Approaching the issue with these targets in mind we can observe certain needs that we can design for. For example, designing for Rest would not require follow-up emails, or targeted adverts to the user. A service that ends with the user requiring Reflection might be easier to view or share. And a user who is leaving a bank service we can assume will need to Rebirth in to another service, so information that will help that rebirth happen would be useful for the departing user and give good brand value to your service, increasing the likelihood of them considering your brand again.

Using Aftermath Targets can’t guarantee your departed user likes your service or product forever, but they can drastically reduce the possibility of you losing control and overlooking their emotions when off-boarding.