Bullet proof design

Introduction

In my day job, I had to design an interface for letting people open a door using a text message.

It’s a nice example of how a design evolves over time.

Solution 1

The person sends ‘open’ to a certain number, and the door opens. Simple!

This solution was actually flawed in reality:

• People would forget the keyword. Was it ‘open’? Or ‘home’? Or ‘enter’?
• People didn’t know what feedback to expect. Would the door spring open automatically? Or did they have to push it?

Solution 2

OK, so lets try again.

The person sends a message to a certain number. The message can be blank, or have whatever contents.

The system replies with a message saying “The door will open in 10 seconds, listen for the lock click, then push the door open.”

OK, that’s better, right? Hmmm…not quite.

The problems were:

• Trust. If ever the lock failed to work, people would revert back to using keys, because they are tried and tested.

Solution 3

The fancy text message enabled locks are monitored remotely, so the system knows if they’re working or not. Which leads to our third attempt:

When the user sends the message, the system checks if the lock is working, and if not, it replies with “I’m sorry but the lock is currently not working. We’ll have this fixed as soon as possible. In the meantime ring XXXXXXXXXX.”

OK, it’s getting better now! But is there anything more we can do?

Solution 4

I started to realise this was quite a unique communications channel to exploit.

If the phone user hadn’t visited in a while, we could include his name in the text message along with “welcome back!”.

The system was starting to feel more rounded now. All of this insight only came from seeing the product used in the real world, which shows the value of user testing.