Empathetic Design for the Digital End of Life
The concept of design for disassembly blew my mind the first time my software designer-self really thought about it.
Its focus is traditionally on physical product design; what happens to a product after it is finished being used? How do we proactively design for its exit from this world, whether that be through recycling, refurbishing, or disposal? Design for disassembly requires foresight and planning in the initial stages of the product’s creation, accounting for material diversity and fastening methods (among other things) that might enable the product to be broken down easily at the end of its useful life. As a software designer, I’m interested in exploring how this concept relates to the digital world; consider this my first brain dump into the ether as I aspire to dive into this topic further.
My hypothesis is that as software designers, we are often stuck primarily thinking of the actual usage of a product as we design it. The need for design for disassembly is obvious in physical product design, but should we be thinking about it in the digital space as well? We have a concept in the IBM Design Language called the Six Experiences, which helps to frame a product’s user experience through microcosms of interaction, consisting of:
- Discover, Try, Buy
- Get Started
- Everyday Use
- Manage and Upgrade
- Leverage and Extend
- Get Support
The only portion of the product experience that is not explicitly covered is that of the product’s afterlife: its phasing out of use, its own method of disassembly in a digital world. What would this 7th experience look like?
To be fair, we may not put as much emphasis on designing for the software “afterlife” as it is probably not where the margins are going to be hit. There is an obvious element of sustainability that we should be keeping in mind as we create software in regards to the obvious carbon footprint of the assets themselves taking up space on a server somewhere. Otherwise, here are some other parallels of design for disassembly in the software space that a team of researchers and I brainstormed at the latest IBM Design Research Lunch and Learn.
Are there ways to assuage a user’s hang up when your system fails them? How can error handling be carried out so as to mitigate any unnecessary frustration and prevent the user from giving up?
Think about all those times you did whatever you could so that you could still access that old copy of Photoshop you bought in college… How might we, as designers, think of ways to prolong the usability of software to enable access to data after the software’s obvious useful life? There is a strong business case to move customers between various versions of software in order to maintain revenue streams, but there is also a necessity to maintain data access and integrity of older files.
Similar to the point above about elegant transitions between various versions of software, how might we design for smooth transitions from competitors’ products to your designed software product? Sustainability of a user’s behaviors between competitive products is obviously important for adoption, but also simply for enabling a user to continue their normal behavior and meet them in a relevant space.
How long should user access be supported after a piece of software is discontinued, or what transition plan should be in place preemptively in order to help users gracefully migrate away? Is there a list of suggested competing services that could be suggested? What happens to their user data in your service?
This topic is particularly interesting due to the nature of how not only the user themselves is affected, but also any other loved ones and related users in a software service that might suffer additional grievances after a loved one passes away, and the deceased’s data is still present and consumable. There is an increasing interest in the human computer interaction field regarding the process of designing for the End of Life (EoL), also known as thanatosensitive design.
There are even entire companies surfacing now that address these EoL needs by offering ways for users to protect and sunset their data, such as Entrustet and LegacyLocker. But are many of the companies we know as tech industry leaders (such as Google, Facebook, Microsoft, etc.) actually practicing any means of thanatosensitive design as they create consumer products?
Dead or alive, the way companies handle user data has huge ramifications for all software consumers. What rights does a user have to their digital footprint and the right to be completely forgotten by digital services they once used? This is a hot topic in the EU currently with the introduction of the General Data Protection Regulation (GDPR) Law, which requires companies to be in compliance with stricter data privacy regulation by May 2018 (after a two-year transition period).
Let’s Discuss
As designers, when is the appropriate time to account for all of these types of design for disassembly practices and what is the business case for doing so? How might you incorporate these practices into your own workflow? How do you feel about it as a frequent user of software products? Who consumes your data as you go about your day-to-day? How do all of the exercises above help a designer build empathy? Each of the scenarios have huge ramifications for not only your users, but also for yourself.
Stefanie Owens is a software designer at IBM based in Austin, Texas. The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.
At IBM in Austin, a group of design researchers meet for lunch a few times a month to discuss research topics of interest. Afterwards, the researchers in IBM Power Systems, the primary conversation facilitators, collect and note the highlights of the conversation. This is one of the series of posts about the lunches from IBM Power Systems researchers.
