Mortality in the Digital Age
“At some point, there will be more dead Facebook users than living ones – and for those left behind, it is transforming how we experience the death of those around us.” – BBC
By 2012, just eight years after Facebook was launched, 30 million users with Facebook accounts had died. Some estimates claim more than 8,000 users die each day. Many Facebook profiles announce their owners have passed; they are “memorialized”. The profile is emblazoned with the word “remembering”, and they stop appearing in public spaces, like People You May Know or birthday reminders. But not all Facebook users who have passed away are memorialized.
The concept of user-centered design is very simple: Take the user into account every step of the way as you develop your product (Garrett, 2011), but how come almost none of our online platforms deal with the inevitably of the death of their users? It is definitely an odd feeling seeing one of the old posts of a friend who has passed away pop up on your Facebook home page. For HCI, death leaves open a range of technological applications that, when interrupted by death, become a problematic part “of” the user.
A post-death digital asset management app, iClone keep tracks of all of your digital footprint, and allows you to decide ahead of time as to what should happen to them upon your death. iClone offers a wide range of premium services that can re-simulate some of your digital actions on your behalf. From sending Birthday Messages to immortalizing your online presence, iClone is the next step in keeping your legacy.
iClone can be divided into two distinct product categories that have to merge into one; product as information, and product as functionality. iClone as a post-death digital asset management platform has to convey a lot of difficult and complex information to its users. Creating an information-rich user experience is about enabling people to find, absorb, and make sense of the information that is being provided (Garrett, 2011). What is challenging is that iclone has to make complex information accessible to the average Joe user. Have you ever taken a stab at reading a service agreement? Even if you have, how much of it did you understand? How long did it take before you gave up on it? As you have already guessed, the answers to these questions point to an ineffective user-centered design.
How will iClone actually achieve makingcomplex and hard to understand information accessible?
I think first we have to know what platforms we will be including on iClone. We can gather this kind of data by conducting surveys. Once we know which platforms we are thinking of then we can dig deeper into their terms and services and go from there. That seems like a good start.
iClone doesn’t just convey information. Users have to ultimately do something with that information. So what are the steps that the users have to take from the point they comprehend the given information to completing an action? The neat, tidy experience actually results from a whole set of decisions – some small, some large – about how iClone looks, how it behaves, and what it allows you to do. These decisions build upon each other, informing and influencing all aspects of the user experience (Garrett, 2011).
When you were initially designing iClone howdid you incorporate the elements of user-experiencedesign, the Surface Plane, the Skeleton Plane, theStructure Plane, the Scope Plane, and the StrategyPlane?
What is kind of tricky for instance is the Strategy Plane. When you are selling something that you know your users want is a complete different thing, than when you are selling something that users need but not necessarily want. I mean you are making people and the young generations at that to think about their death. Humans unless dealing with existential crisis, or an unfortunate illness don’t do that. At this point I’m thinking if I refine the Strategy Plane as I design the Scope Plane and the Structure Plane I might be able to arrive at a better solution. It is a much a better approach regardless of what App you are designing to have work on each plane finish before work on the next can finish rather than requiring each plane to finish before work on the next can start (Garrett, 2011).