Designing better mobile apps - learning from SMS’s stickiness

The last couple of weeks I have been thinking about the most sticky mobile application and I could not think of anything more powerful than SMS. The sheer numbers of users and the volume is truly astounding.

Why did this mobile application stick where many others have failed?

I believe, that a number of factors in the design of this technology have led to its great adoption rate:

• It’s Always ON! - you cannot NOT recieve an SMS message, well, you could turn your mobile device off but the minute you turn it back on - beep-beep - message icon on your phone!
• It provides near instantaneous feedback on sending a message: “Your message was delivered”
• You do not have to worry about content segregation such as in an email - no subject, no body, just plain simple text - which means you think less while typing out short hand messages to your buddies about meeting at the Perth for beer! Perfect!
• The content sent and received is small - a maximum of 140/160 characters which needs less attention and is perfect when you are mobile and away from a traditional connection
• Your social context is maintained - why is it easier for you to write a text message - because in most cases the messages you reply to and receive are from friends and acquaintances who expect short replies and maybe a joke or two from you and with whom your social context is already set. You do not waste time setting the context with them - you just get to the point - this is a big plus while one is mobile
• SMS messages are definitely intrusive and many users turn their notification to vibrate-mode on their phones so as not to get disturbed, but they are not invasive ie. your focus is not jarred by an sms as it is sometimes with an email. The reason I think this is true is because of the small amount of content contained in an SMS - if its important - you use some other mechanism deliver the message.

Now, what does this mean for content developers? What lessons can we learn from SMS to better design our applications on mobile devices so as to increase their stickiness?

First up, I think we have to be cognizant of usage scenarios for mobile applications - consider a normal 10 hour day when a regular user (not a traveling salesman) is potentially using a mobile device - this time can be segregated into:

• commute (25mins national average for the US in 2003) - lets assume all of this time is available,
• work (9 hrs on average - this is downtime for mobile devices for most users - I am not counting the countless hours spent in meetings by management types fiddling with their bberries),
• at home and responding to social connections using mobile devices (2 hours - this includes email, calls, sms’s etc) - assume another 25 mins is available directly on the mobile device

That is 50 mins of mobile device usage in our current world without seamless mobility (more on that here…). This would mean that we can either create applications that completely capture the users attention while they are mobile, which is difficult to do, given the form factor of the devices and their current user interfaces (gaming devices like the DS and the PSP do succeed here but their
interface is far superior to the regular phones we see around us); that leaves us with an interesting alternative - build mobile apps that are event driven and ping the user though the use of some widget-based mechanism to deliver pre-configured content as and when the content becomes available. Ajit has written some interesting stuff around widgets on mobile apps.

This event driven focus will allow the user to remain in control - small pieces of focused content will get through to the user on the mobile device and the user has the ultimate choice as to delve deeper into that content which may be triggered from the widget and available in a more complete form on the mobile web - rendered on the device’s browser.

imho, All the stickiness aspects of SMS are preserved in this experience and would increase the rate of adoption for your apps.

powered by performancing firefox