Mobile interaction design case study

A piece of consultancy work from June 2001, written up as it happened. Jack Schulze, Adi Nachman and I designed the interaction architecture for Mamjam, an early SMS-based location-chat service by Pollen Mobile. Technical architecture was by John Gillespie at Pollen; information design was by Jack.

To understand what Mamjam was, and why it was hard: in June 2001 there were no smartphones, no apps, no mobile web to speak of. The iPhone was six years away. Phones were feature phones. Nokia 3310, Sony Ericsson T68, Motorola StarTAC. Monochrome displays, T9 text input, no GPS, no cameras, no address-book integration for anything other than voice calls. SMS was the only universal messaging channel, capped at 160 characters per message, billed per message, delivered through cell networks that routinely held messages for ten minutes or more. The handset could not tell you where it was. The network could triangulate position, but that data wasn’t exposed to apps or services. There were no sessions, no cookies, no state. Every incoming message arrived at the server as an orphan, carrying only its timestamp, the sender’s number, and 160 characters of content.

Mamjam SMS interface: user-matching screen showing a list of people present at the same venue
Mamjam SMS interface: user-matching screen showing a list of people present at the same venue

On top of that, Mamjam set out to do something that looks entirely ordinary now and was not possible at all at the time: let two strangers in the same bar, the same gig, the same neighbourhood, find each other and start chatting by text. Every assumption a modern location-based messaging app rests on, including GPS, persistent identity, session state, push notifications and app stores, had to be either worked around or built from nothing out of SMS primitives. The interaction design problem was how to make two people trust a handshake they couldn’t see, over a channel that might lose their reply for ten minutes, on devices that couldn’t tell them where they were.

What follows is the case study as written in 2001, lightly tidied but otherwise intact.

Pollen Mobile develops location-based services for the consumer and business markets. Mamjam is their first product: a location-based social entertainment service built on SMS, letting people in the same venue chat with each other by text. This is the story of how we designed the interaction for it.

[two screenshots of the Mamjam match interface]

Brief

Pollen approached us with a broad intention: use SMS to drive social interaction and entertainment in new ways.

We opened with three quirky directions based on playground games, internet chat, and community storytelling, partly to flush out business goals and user-needs. After that brainstorm we moved into a proper user-centred design process.

Handsets and networks

Several pivotal constraints shaped the design from the beginning. SMS offers extremely limited functionality, with few opportunities to build rich, engaging, extended interactions.

Handsets

Mobile phone handsets in 2001 offer no navigation between multiple messages, no indication of user status or location, and no practical way to view session history. Users are accustomed to SMS for quick functional communication and for keeping in touch with friends. They certainly do not rely on messages for any kind of complex interaction.

Every transaction between user and server on a mobile phone is a sessionless operation. Each message contains only the time it was sent, the number it was sent from, and the content of the message [1].

Unlike HTTP systems, the server cannot rely on location and session information being stored in the message address. From a user-experience perspective this matters, because people are used to responses from systems that do carry session information and behave quite differently [2].

Networks

SMS messages are managed by the networks using cells; each cell carries messages particular to its region. Cells are notoriously unreliable. It was common to find messages hanging in the system for over ten minutes. This caused serious design problems: satisfying communication relies on a high level of continuity, and the timing between messages is a critical indicator of the emotional state of your chatting partner.

Mamjam’s service is location-based, users are put in contact with others in the same area. But existing (second-generation) handsets cannot determine location. Although networks triangulate positions, this information is not publicly available. Location has to be provided manually by the user, in a form the server can interpret.

Designing a reliable language for users to identify their location became central to the interaction design problem.

Most competing SMS services at this point are internet-based, requiring users to sign up at a website before using the service. Mamjam should work directly from the handset.

Modes

A system like this could conceivably be built without modes [3]. From the user’s perspective a modeless system would be overly complex and exhausting, every message would need to include exact commands and instructions for the server. But a modeless system is very attractive from a technical perspective, since the server is more likely to correctly interpret instructions.

Process

Requirements

We worked with Pollen and a selection of SMS users to draw up personas and scenarios, through contextual enquiry and user-requirements gathering. The requirements that emerged:

First iteration

First iteration of the Mamjam interaction architecture: a flow diagram of the SMS chat-room model adapted from internet chat
First iteration of the Mamjam interaction architecture: a flow diagram of the SMS chat-room model adapted from internet chat

The initial interaction architecture outlines our first intentions for the system. (We can’t include the full-size diagram for legal reasons.)

[interaction architecture diagram, v1]

The system works in a similar way to internet-based chat rooms, connecting users who are ‘online’ at the same time, with the extra dimension that they are in the same physical place. Mamjam supports private one-to-one communication only, no group shouting, no broadcast. Once a user has found a chatting partner, the system directs text traffic between them until one party decides to pursue someone else or signs off.

This structure required users to enter a lot of information about themselves before they could initiate contact. We felt this was valuable in order to reduce the interaction load while chatting. It was also, in retrospect, a perhaps misguided adherence to the ‘internet chat room’ model.

We implemented this on Pollen’s test servers and ran user-testing sessions. Several problems surfaced.

The sign-up process was off-putting. User motivation for this product is entertainment and social contact; people weren’t willing to tolerate a lengthy sign-up process. This architecture required four messages for a new user to sign up, in some cases, a user would spend the equivalent of a 10-minute voice call before they’d connected with anyone to chat. It was clear that the service needed a quick path in, perhaps at the expense of more advanced features.

In trying to optimise for both new and advanced users, signing up for the first time required a different interaction process from signing up for a second time. There were also several different methods of identifying your location, to anticipate every possible user-interaction. We ended up with four or five possible entry points into the system. This caused more modal problems than we anticipated: the SMS server had to process language and match patterns across an almost infinite realm of possibilities.

Second iteration

Second iteration of the Mamjam interaction architecture: a revised flow diagram addressing message storage and navigation constraints of feature phones
Second iteration of the Mamjam interaction architecture: a revised flow diagram addressing message storage and navigation constraints of feature phones

It became clear that the three biggest problems for the social interaction process were:

This discrepancy between user perception and system perception is something we started calling ‘slippage’. Slippage is most problematic during the initial handshake, when the user is most insecure about their request and about the system itself.

Text messages to and from SMS servers rarely arrive as punctually as they seem to in normal use. This meant it was possible for one of two users, both having agreed to start chatting, to reject the other on the basis that they had failed to reply to the confirmation. In fact the rejected user had replied with confirmation, their message had been delayed. That reply would then arrive with the first user, who had since moved to a new part of the interaction. Their reply could potentially interrupt another process or get lost in the system, confusing and infuriating both users. Serious slippage.

We also found, as predicted, that users did not read back through their old messages. Some phones have very limited capacity for storing messages, and no phone facilitates simple navigation of previous ones. The current message was the only one we could usefully rely on for users to react to.

[interaction architecture diagram, v2]

The second interaction architecture was developed with the problems above in mind. Some further changes have been made since, mostly around modal issues and the commands through which users communicate with the server. There are still issues around slippage, but the second iteration makes this much less of a problem. The system is basically modeless, except for the first transaction. All users, new and existing, enter the system the same way. New users are chatting within two messages. Existing users are potentially chatting after their first.

For an overview of the commands and interactions possible, see the Mamjam How To and Advanced Features.

In use

Mamjam is now fully operational, and is spinning off other services based on the basic interaction architecture we designed for the initial chat service.

Extended services

In a recent, typical promotion at the Mood Bar in Carlisle, Mamjam sent a message to people who had Mamjamed there, offering them a discounted drink if they showed their mobile at the bar. The conversion rate from message sent to offer redeemed was 30%.

Building relationships, community and storytelling

Having heard that a large number of people were texting their ex-partners late at night under the influence, Mamjam sent a message asking for dating disasters. 13% of people responded with their own story by SMS, 50% of them within the first hour.

These users were given no promotional incentive, and the call to action was not a simple generic mechanic like “reply YES or NO”. It was much more involved: users had to read and understand the message, then conceive and craft a response to fit into 160 characters. The response was high and the quality of response excellent.

Stimulating usage

Reminding BT users of a free messaging offer, to stimulate Mamjaming outside of the locations where they’d first used the service:

Spice up your text life for FREE! Mamjam is still FREE to receive for BT users. To chat now just reply with mamjam and your location eg MAMJAM LONDON.

7% of the BT user database read the message and decided to log on to Mamjam. Between them on that day they sent 3,400 chat messages.

Usage statistics

Conclusions

We think the best solution to this particular service has been found, given the constraints. The most notable of those constraints are the handsets continuing to rely on short messaging rather than a more advanced chat service, and the network operators’ inability to develop services and platforms outside of their own internal structures.

This research and product development has generated a lot of further ideas for asynchronous communication structures, and for communication solutions on packet-switched networks for mobile devices.

Footnotes

[1] Some phones support greater functionality than others. Mamjam needed to support a broad demographic, so only the most bottom-line functionality was available to us. When sending a message from a server it can be set to “Flash” mode, causing the message to open on the user’s phone immediately. Some cells also support a “broadcast to cell” function, by which a single message can be sent to all phones within that cell. This is expensive and only available to phones on a given network.

[2] Information transferred with HTTP is also sessionless, but browsers and servers are afforded functionality to help overcome modal issues, cookies, history bars, links. There are other interface restrictions around manipulating text, no cut and paste, for example.

[3] The most comprehensive discussion of modes I’ve come across is in The Humane Interface by Jef Raskin, pp. 37.

References and links

At the time of writing the Mamjam numbers are 82888 (BT/Vodafone) or 07970 158 158 (all other networks). Just send any text message to sign up and test it for yourself.

Professional credits

Interaction design: Jack Schulze, Adi Nachman, Timo Arnall
Technical architecture: John Gillespie
Information design: Jack Schulze