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.

I’m working on a project in government that requires users to fill in an online form and make payment for the service online, but that’s not the end — users then have to do some stuff in the real world, including downloading and printing some now-finalised documents, and taking them to the appointment they’ve booked as part of the online application process.

The problem: in online transactions (most typically shopping), payment is almost always the last thing you do, to the point where the research participants we’ve tested with tend to switch off when they see that their (pretend) payment has been successful. It’s vital that we retain users: while they might think the ‘conversation’ is over after payment, we know it isn’t, and there’s some important information after payment that we don’t want them to miss.

(NB: it would be inappropriate to put the information before payment, because (a) it’s not relevant yet, being about what they need to do next, and (b) users can change their form details at anytime up to making payment successfully, so we don’t want them to download any documents until the details they’ve given can no longer be changed)

Are there any examples out there (ideally good ones, but I’ll take what I can get) of online processes where payment is not the last thing? Or any tricks to stop people from dropping out? This isn’t e-commerce in its usual sense; the experience will be worse for everyone (customers and government) if customers pay but don’t see the information after that about what they need to do next.

Thanks in advance 🙂