The design and implementation of the purely theoretical "self destruct" button

Question

I had an Adobe Flash instructor in college who told me a story about getting bored at work. He had some downtime and was looking for a way to pass the time. While looking at some Flash code, he discovered that if you created an executable file with a couple of lines of code you could create a program that would perpetually reboot the users computer. So, armed with his new found knowledge, that's exactly what he did and promptly asked one of his friends to try out this new program he created. My response was, “You created a self destruct button.”

Now, he did this just for fun. Just like I'm asking this question just for fun.

Ever since, and quite often, when I'm working with developers I ask them if they included a self destruct button. I will then get one of two responses, either a blank stare or a simple "No". So I'm convinced the only people I can turn to are UX professionals. Which brings me to my question, which I'll phrase from a UX standpoint.

What user scenario(s) could prompt the inclusion of self destruct button? How would you as a UX professional go about designing/implementing the self destruct button? Finally, and most importantly, what would it do? If you wanted to take it a step farther, how would you calculate conversions/success?

Remember this is purely theoretical and just for fun, so the answers can follow suit, but they should still have some basis in reality (just a little is good).

If we use the story as an example, the scenario that prompted the self destruct button was a developer with too much time on his hands. The design process was simple: create an executable with a line of code. We all know by this point what the executable file did. If you're curious, according to the story the implementation was a complete success and rebooted the machine over a 100 times before being unplugged and summoning IT. So, the 100 reboots would be the conversions and the calling of IT would be the success metric.

Answer 1

What is the business goal of the Self-Destruct button? UX is all about balancing business needs with user goals. So, let's say the business goal is to sell more computers. The user goal is to disable their computer so that they can open an IT ticket, have IT investigate, and eventually replace their computer, having found nothing wrong. Let's talk to some users and validate our hypothesis!

What is their biggest pain point when it comes to constant uptime and reliability of their computer? How have they tried to fix the problem themselves? We call 180 users, interview 40, and learn that their biggest pain point is that their company has increased the length of time a computer is expected to be in service from 2 years to an agonizingly lengthy 5 years. Johnny won't get a new computer for 5 years. Or if he inherited an old computer from a recently-departed employee, he may be saddled with the crusty thing for a long time. Meanwhile, technology marches on, and tools get cooler, lighter, faster, shinier. Johnny is sad. He tries dropping his laptop, but it continues to function! He needs a stealthy self-destruct button, and we are going to make it for him. We create a set of Personas based on the 40 people we spoke with.

Let's design a prototype of the self-destruct button! We need some requirements. We surmise from our interviews that the self-destruct button must be hidden and difficult to invoke accidentally. Once invoked, it must disappear without a trace so that IT cannot detect the reason for the outage. We also learned that some users said they might want to hit the button to take an unplanned half-day off, because having a disabled computer would mean they are unable to work. In this case, being able to recover from the self-destruct mode would be a desired feature. The product owner feels this feature is not part of Minimum Viable Product, and pushes back hard, calling us The Scope Creep. The first release of the Self Destruct button will be completely unrecoverable and untraceable. So saith the Product Owner.

As UXers, we wonder, how would Johnny find out about this feature without IT also learning about it. We need to figure out how to provision this feature selectively, only to the end-user, not the corporate IT person.

We study the workflow for provisioning new users at major companies and learn that many IT folks sign in as Admin users, while end-users are denied admin rights unless they are developers. We recommend launching the self-destruct button only on end-user logins, not admin.

Then we prototype the provisioning workflow and prepare for user testing. We design a slick little Coach Marks treatment that walks the user through the self-destruction process.

Then we test on users who fit the Johnny persona.

We find that users are dismayed that there is no way to recover from self-destruction.

We use our negotiating and presentation skills to make the product owner aware that the first release must be recoverable or the product will fail.

I could go on... but enough fun for one day.

Answer 2

It's already been done on a vast scale. Since the success metric is

rebooted the machine over a 100 times before being unplugged and summoning IT. So the 100 reboots would be the conversions and the calling of IT

I nominate Windows update from Microsoft because

• every Tuesday is causes at least one reboot, last time was 5 reboots
• the patches often enough break something necessitating a call to IT

The business case is a technical STOCKHOLM SYNDROME - the IT world could be even scarier if you weren't dependant :)

Answer 3

There seems to be a heated debate about business goal of the self-destruct button in question. So, I will try to contribute to this side of the argument. I am currently working on an MDM (**M**obile **D**evice **M**anagement) project and we have a requirement that enables the administrator to create a device-wipe rule based on a status or event. (i.e device leaves a user-specified geofence) But, this is (1) being done by all the MDM products on the market and (2) requires the device to be connected to the internet for the wipe to take place. We were trying to find an alternative and your question has given me a great idea (by the way many thanks, Johnny) and here is a solid, real-life business goal of the self-destruct button/switch/sequence:

-the mobile device under management could be stolen, compromised, or fallen victim to corporate espionage

-the captor might be clever enough so that s/he could cut the internet connection or worse shut down the device immediately, so there could be no way of getting in touch with the device

-...(for the sake of the argument)

With the above conditions, the device must emit an SOS message to the internet immediately after it has booted (if shutdown) or sensed an anomaly. If this SOS message is not responded properly, the device must initiate the self destruct process.

I might have got a little bit out of topic by introducing the automation to self-destruction but it is a real-life answer to a hypothetical question so please don't come at me with sticks and stones.

Answer 4

What user scenario(s) could prompt the inclusion of self destruct button?

Well from a users point of view - bad, slow, inefficient, time wasting, buggy software. Software that never receives updates or fixes because the developer is in denial that their software has bugs in the first place. This piece of software constantly loses the users work, corrupts files, but realistically is the only available piece of software on the market that this user can make use of - either due to there being no competition, file type compatibility between other users, etc.

Now this self destruct button could be a legal requirement for software developers to include. After a certain amount of frustration (crashes, lost work, lack of fixes in the required time, or other criteria defined by the legal body that lay this law down) this feature i.e. self destruction, could present itself and become available to the user. The user now has the legal right to use this based on the fact it only appears after all the above criteria is met by the software.

And finally, and most importantly, what would it do?

Now what could it do? Well it could completely wipe all traces of this software from the users computer, automatically refund all costs of the software to the user and also log that this software was given the self destruction treatment on some kind of governmental website that tracks which software has had the most self destructions. A name and shame type list. The downside to the user would be they would never be able to install this software on their machine again (to prevent multiple self destructions) - but why would they want to if they nuked it in the first place?

How would you as a UX professional go about designing/implementing the self destruct button?

I haven't thought about this yet but it would be fun to have a stab at some workflows and designs :). Also I like the idea of a physical button! not sure how this would work. maybe a peripheral that comes with new pc's that flashes saying "you now have the right to nuke Ad**e Pho****0p"

Answer 5

First, you should start of talking to some users, getting a feel for their personal destruction needs. Doing some background research on self destruct systems online should also be informative.

Once you've got some basic background info, you can move onto system architecture. What kind of self destruction is the most efficient? How can we maximize destruction for a given effort? Should your solution be software or hardware based? (possibly explosive/flammable/acidic/nuclear)

Finally, we can cover some UI design. What kind of interaction is best? A button? A switch? Should the artifact be physical or virtual? Should it have any kind of indicators and feedback system? Is safety a concern? What color and shape is the most indicative of self destruct functionality? Are there any confirmation steps to prevent accidental activation?

Then we can move onto usability testing. What are the success criteria for testing? Does the feature summon IT/police/army? What kind of user pool is needed? Are testing user losses expected? You will likely need to make everyone sign waivers abjuring you of any fault.

(I had fun.)

Answer 6

The self destruct button should be available in both software and hardware formats. I will focus on the software side for this answer, perhaps someone else more proficient in nuclear reactor meltdowns can fill in the hardware side.

The self destruct button need to balance the functionality with the urgent need for speed of deletion - something that deletes too much too fast or in an obvious way can be undesirable at times, but at the same time if the wrong person enters the office, it needs to be able to be executed quickly.

The self destruct button should be able to delete any incriminating data, regardless of if the user has access to it or not, because the proper user may already have been arrested.

The self destruct button should allow for selective deletion of data, in order to maximize the amount of "wild-goose-chases" caused by incomplete or inaccurate dummy data.

The self destruct button should be completely anonymous, such that the person who destroyed the data can never be found nor held accountable for such an act.

The self destruct needs to have an "emergency" mode that deletes all the data in case a user does not have the time to configure what to delete, but also allow surgical precision as to which records should be removed.

The self destruct needs to be able to remove data without alerting anyone, such that it can finish its work without arousing any suspicions.

This button is needed by the NSA so that they can destroy more evidence before a court asks for it - a perfectly reasonable (if not legal) business requirement.

Taking all the above into account, I believe that the best way would be to have an "emergency" switch on the underside of each keyboard that wipes all the data, and also a more fine-grained "purge" that is based off of a regex match saved as a "draft" email, which is then promptly scanned, read, and deleted by the mail server, and causing the missing data to be delete. This could then be applied to individual computers by specifying their machine name, and support replacing critical files with malicious files that can cripple the device.

Answer 7

What user scenario(s) could prompt the inclusion of self destruct button?

An orbiting research facility, housing an extra-terrestrial contagion capable of wiping out every living species on the planet loses power. Airlocks on containment cells are losing pressure, all staff aboard are infected. As routine maintenance slows to a halt, the station begins to fall out of orbit, threatening all life on Earth.

How would you as a UX professional go about designing/implementing the self destruct button?

Knowing the risks far outweigh the benefit of researching this alien strain, self-destruct terminals are placed in every hallway, and can be accessed remotely from Earth. The on-station user would have to provide a pinprick of blood to test for intoxication and neural damage, along with an air sample that would analyze the potency of the airborne infection throughout the station to assess threat level and eliminate the possibility of sabotage. A blood-test would also be required before escape-pod entry. From Earth, a user can administer an air-test silently without alerting on-board scientists, and lock escape pods if necessary.

And finally, and most importantly, what would it do?

If all systems have failed critically, and there is any risk of contamination reaching Earth, the station will heat to 600 degrees Celsius, incinerating the infection.

Answer 8

If self destruction is a key requirement, I wouldn't leave it in the hands of the user. Instead, I'd go the route ala "this message will self destruct..."

Answer 9

What user scenario(s) could prompt the inclusion of self destruct button? And finally, and most importantly, what would it do?

A self destruct button sounds like a perfect candidate for once and for all leaving a social network. It's so easy to sign-up but leaving can be a real pain (ever tried leaving facebook?).

How would you as a UX professional go about designing/implementing the self destruct button?

How about a button on my profile page that reads 'Delete my account', and then without making you file a request (see above link) actually deletes all your data?

Answer 10

I imagine that the criminal community is far ahead of us all on this topic.

What user scenario(s) could prompt the inclusion of self destruct button?

Being British, I imagine that many of the issues that came up (rightly or wrongly) in the recent phone hacking trial / News Of The World enquiry

http://www.bbc.co.uk/news/uk-24894403

might be addresed here: digital copies of incriminating phone hacks, e-mails concerning and/or authorizing those hacks, and unrelated people hiding computers so the police couldn't see their collection of porn. So there are a lots of possible demands for such a button.

How would you as a UX professional go about designing/implementing the self destruct button?

The ownwers would have to adhere to a strict file-naming and filing system. As most of items stored are illegal or anti-social, it would be important for the owner or user not to be incriminated. The UX professional would therefore go about their task by making the self-destruct button look like something the clever investigator would want to click on, rather than hiding the button. A folder called "Personal emails - confidential", or "My favourite girls", or some other item that an over-eager PC (of the Plod variety) might rush in to. Of course, a phone hacker might have to use the "my favourite girls" folder and the pornmeister the "personal calls" to avoid finger-pointing and general suspicion.

The complete destruction of the files contained (or whole computer, if required) would thus lead to the investigator getting the blame and the suspect being wholly innocent.

Conversions/success would be measured by the number of days and size of the legal bills in the resulting public enquiry as to how incompetent the investigation was, and in the number of recommendations for future legal processes in the future.

Answer 11

It all depends, I think, on what 'platform' you're going to be using this self-destruct button. Is it a digital destruction interface or is it necessary to have a personal self-destruct button on your person at all times?

If you're going digital, how much does this button need to affect? To be a successful self-destruct button, it has to do what it promises to do, otherwise your users are going to go to another destruction company and set them onto you. Problem. So if I was implementing this button, I'd give it a small scope. It should only affect one computer (or one website, possibly. Or one app. Or one database. You get the point.) This way, your button can't be help liable for not causing the correct destruction. If your users want to cause widespread destruction, perhaps you should consider creating a destroyers' network - like a social network, but event-focused: people could create destruction events which other owners of this button could sign up to, thus linking their button and widening the scope for more destruction.

Why would users want this button in the first place? Simple. Users get angry. Once a user is angry, you risk them leaving your product/system - unless you can provide some internal method of venting that anger. This is where the self destruct button comes into play. So, perhaps instead of being its own application, this button should be a key component of all user interfaces - perhaps a small "Annoyed with us? Click here" at the top of every screen to take users to the main button.

Of course, if you want a physical button, there are other concerns. What are you destroying? Is it the object of a user's anger such as a computer or phone? If so, all you need is a crusher. Are you trying to take over the world? You might want a rather strong virus instead.

And then, of course, come in the implications for your company. How do you prevent your company becoming involved in all the legal ramifications of providing people with such potent gadgets without proper training? I believe that's a corporate offence here in the UK. I can't answer that in great detail because I'm not a lawyer - if you really want to investigate, there are plenty of legal communities on the Internet who might be able to help you.

So, a self-destruct button? My advice: keep it simple, make it effective.

Answer 12

Design is meant to solve problems. In order to answer your question, we need to think of some hypothetical situations where a self-distruct button is needed.

We also have to consider that a "self-distruct button" could be abused by those who want to compromise your empire. By the simple fact that you put it there, you make it easier for them to bring to the ground your entire construct. All they have to do now is find a way to push it.

Besides Star Trek's Enterprise, I am thinking of the following scenario:

In the business environment, somebody has built a very powerful institution on an ethical ground. The founder of that NGO/company/cultural institution puts a lot of emphasis on the need of preserving the moral principles that turned his vision into a worldwide success and a very influential power tool. However, s/he is aware that this institution is larger than life, while s/he is eventually going to die.

That is why s/he fears that his/her legacy might fall into the wrong hands, causing as much trouble as the good it lead to while s/he was alive.

That is why the founder of the company comes up with a contingency plan where the whole system will be destroyed by the simple push of a button when certain clauses are broken by those who will be in control after his/her demise.

I know it sounds crazy, but so was the question. Anyway, fun theoretical challenge. Thanks for asking and stimulating our imagination.