Recent Blog Posts

Making mobile payments work

Most of us are aware of DoCoMo's mobile wallet, and there has long been keen interest in using the mobile phone as a wallet. Companies beyond DoCoMo are doing it: a Swiss bank, PostFinance, is using a SMS bar code solution, which should work as long as people want to pay directly from their PostFinance account.

There are several issues that need to be addressed to make mobile payments work in practice. In short, if the user can not rely on the phone to make a payment, there has to be a large incentive to risk having to try the transaction twice: once with phone, once with the physical wallet. Ideally, of course, the wallet is unnecessary but that will take a while.

  1. Point of sale - The technique for reading the payment mechanism must be common at merchants' point of sale. Good bets include bar code scanning. RFID will work fine with large retailers but not at small retailers. Very small retailers may not have an internet connection, so a connection to the existing credit card acceptance process would be nice.
  2. Payment instrument selection - Many people have multiple accounts, and would want to choose from them when making a purchase. Don't forget that gift cards are a method of payment; these should be included in any solution.
  3. Wireless network connectivity - At least in the U.S., connectivity can be somewhat unreliable in many stores. A retailer installing this solution should check for carrier connectivity before investing. This means that relying on SMS introduces potential delays in certain locations.
  4. Security - A stolen phone must not even seem like it might risk financial account data. Relying on PIN entry on the phone is good. Storage of account data on the device is a security risk.
  5. Ease of use - The wallet should be a fast-loading (or even native) application on the phone, with the initial screen showing available payment methods. If only one method is available, the bar code should be displayed immediately. The user should be able to access the wallet with at most two keypresses.

I haven't run across a proposed solution that addresses all of the above, but I certainly haven't seen all the solutions. It should be possible.

Imagine a user experience like this: Joan approaches the point of sale with her items for purchase. Rather than pull out a wallet, she pulls out her phone. She enters, at the standby screen, a four to six digit number that unlocks and launches the payment application. She selects her Visa card, types the amount of the sale, and the phone displays a two-dimensional bar code. She shows the bar code to the clerk, who scans it. Payment is authorized and Joan leaves the store. She receives an SMS receipt of the transaction.

What's going on behind the scenes: the PIN opens the payment application, allowing the "what you know" component of security to be paired with the "what you have" (i.e., the phone) component. No financial account data is stored on the phone, but a pointer to a wireless financial service, perhaps owned by a carrier. The user can manage all the credit cards and other financial instruments from a web site.

The bar code would be generated from a hash of the phone number attached to the device, the wallet service account ID, the amount of sale authorized, a pointer to which payment instrument is selected, device or SIM ID, and the current time stamp. The code would be good for only ten minutes or so, and would also be usable exactly once.

The biggest security hole that I see (of course, I'm not a security expert) is if a pre-paid phone is stolen or lost, since such phones may not be disabled upon loss. To address that issue, the application would lock if five consecutive incorrect attempts were made for the PIN. The phone would send a message to the mobile wallet organization, who would call the user and get further security information before re-enabling the application and PIN.

This solution eliminates the need for the phone to have connectivity, while preserving the security associated with the phone. The bar code can be scanned by a bar code reader or even a camera phone, enabling person-to-person payments.

Tags: BusinessDesignDesign Tips, Permalink | Comments Off May 23, 2006

Types of information appliances

I was recently asked about the information appliances (specialized devices) in the device taxonomy. I'm not certain that this classification would be more than an intellectual exercise, as the nature of an information appliance is to fit a precise niche in the market, which can happen anywhere.

Regardless, I started thinking about it and found that a simple hierarchy did not adequately describe the space because there are varying degrees of mobility involved. Thus a first pass at the classification has use types as well as degree of mobility:



Environmental Wearable Pocketable Baggable
Entertainment In-flight entertainment iPod Nano? iPod, GameBoy DVD Player
Information Clock, flight status display Watch Heart rate monitor, GPS Professional digital camera?
Transactional ATM Market opportunity? Bar code scanner UPS Diad
Communications In-flight phone; TTY system Star Trek communicator Text pager Satellite phone

Baggable means that you can lug it around in a backpack, tote, or briefcase. The Information row has devices that present or capture information, with little interactivity with the user. Feel free to argue about cameras, which are certain information appliances but may not fit in the information subcategory.

Tags: DesignDevicesTheory, Permalink | Comment (1) May 18, 2006

Mobile Cash Control

Paypal does it, why can't the banks? (answers: slow, regulated, lack of vision)

Send an SMS each time money is added to or removed from my bank account. Include the balance. There are people who will pay for the priviledge.

A New Device Taxonomy

The current mobile device market uses ill-defined and irrelevant market segments. The difference between "phone," "smart phone," and "PDA" is arbitrary and useless, as a smart phone is a phone with PDA capabilities, and a PDA can readily have phone capabilities. This distinction appears to be based on the evolution of the device types rather than actual market segmentation.

The whole concept of "phone" is becoming less relevant; voice communications are a service that can be tacked onto any of a wide variety of devices. Similarly, personal information such as contacts and calendar can also be tacked onto a wide variety of devices.

A better device classification scheme is based on user needs and behaviors. Note that hardware and even function can be shared across these categories; the difference is in data stores, device configuration and optimization.

  • General purpose work devices, currently dominated by desktop computers, tablets, laptops, and the like. These devices can do a wide variety of information-centered tasks. Contrast these with special-purpose work devices, such as the UPS Diad delivery driver device. Users are likely to have a general purpose work device available or carried while working, but not while outside of work hours.
  • General purpose entertainment devices, such as the iPod video and Sony Playstation Portable. These devices might be game-centric, book-centric, or media-centric, but are intended to readily support the use of other entertainment media. They may even have communications service.
  • Communications and control devices, which include phones, desktop phones, PDA, Blackberries, and a plethora of future devices. These devices that allow the user to communicate with others via voice, text, and other methods.
  • Specialized devices, or information appliances. These include watches, iPods, ATMs, GameBoys, and so forth. These devices are focused on delivering a specific experience to the user, and if they do other things, those secondary items are very secondary. An iPod has a calendar on it, but it in no way interferes with the use of the device as a music player.

While each of these device categories is its own industry (more for the specialized devices), I find the most interesting one to be the communications and control device, which becomes interesting when you consider the mobile version. I find this category so important that I refer to such a device as a Personal Communications Device (PCD).

A PCD is our personal companion and will serve a larger and larger role in our lives. Left the oven on? Use your PCD to turn it off. Somebody at your front door? Talk with them using your PCD. Need a bit of information for that meeting, or to post a blog entry from the road? Use your PCD to do it. Spend a little down time with a bit of music or Bejeweled on your PCD.

A PCD is always carried, and is thus described by The Carry Principle. It is multi-purpose, but will be configured to market segments' needs. Like some drivers need small efficient cars and others need large trucks for farm work, some PCD users need a messaging-centric device and others need a voice-centric device. Still others, such as doctors, may actually need an information-centric device. The Danger Sidekick is as much a PCD as is a Nokia Communicator or even a Motorola RAZR.

PCDs do not replace work devices: few people would want to carry a device with a full-sized screen or keyboard, regardless of the form of the screen. PCDs do not replace entertainment devices: providing game controls on a phone is likely to be unwieldy as a phone or unsatisfying as a gaming device, as the N-Gage illustrates. These broad categories have overlap of features and data stores, but not overlap of purpose.

So my consultancy actually has a simple statement of purpose, but only if you understand the definitions: Little Springs Design designs the user experience of products and services related to PCDs, and helps companies with their process for doing the same.

Tags: BusinessDesignDevices, Permalink | Comments Off May 10, 2006

Sometimes the best user interface is no user interface

We were recently discussing the best possible user experience for phones found in airplanes, both commercial and executive jets. Our first round of observations were standard device usability observations - the devices should work more like cellular or landline phones, and so forth.

We stepped out of the box a bit when we focused exclusively on phones in solely owned and timeshared executive jets. We assume that the standard user interaction involves pulling out a phone, waiting several seconds to be able to dial, dialing a phone number (from memory or from a second device), and talking. We're assuming that the account is tied to the device or airplane identification. AirCell, a major phone manufacturer, says they use Iridium, so account information is important for billing.

But would an executive ever do that? Would an executive ever bother learning a new phone system, or instead ask somebody else to dial for him? We believe the answer to be "no, not really".

So what should an executive phone look like? From a physical perspective, it is simply an old-style handpiece, allowing comfortable and private conversations, with integration into the cabin's sound system for conference calls. When the user picks up the phone, she is immediately connected to an on-ground concierge who can make calls as well as do other concierge services. This concierge could connect to various messaging systems, allowing the exec the best use of her time. For example, recording a voice sms rather than attempting to contact the recipient can increase efficiency. Ideally, the concierge has access to the executive's address book, but this is not strictly necessary.

This concierge service suggests that the entire system could be less expensively operated with some other type of ground-to-air radio system. After all, Iridium calls are quite expensive. The executive's time is even more expensive - otherwise, she wouldn't be on a private jet in the first place, making expensive calls.

Benefits of this system to the phone provider include increased usage of the phone. A jet timesharing company could bundle a number of customer support services into the concierge services, providing superb user experience and signficant differentiation.

Tags: DesignProduct Ideas, Permalink | Comments (2) May 4, 2006