After having seen many developers and partners integrate MyVox into their applications over the past year, I think it’s fair to say there are better and worse ways to help your users understand and want to use phone interactivity in a Web product. Here are a few lessons learned, both from observing others and from our own experiences over the past eight years:
1) Give users context. Say you are using the phone to do voice recording. Most users are probably used to the idea of using a microphone to record for the Web, but not the phone. If you don’t make it clear up front that the phone will be used, not only will you confuse some users who expected to use a mike, but – even worse – you’ll turn away users who don’t have or know how to use microphones, despite the fact that you could have serviced them wonderfully over the phone. Tell or show users ASAP that the phone is the medium.
2) Tell people why the phone is good for them. Remind them that they have a phone with them all the time, that they can add your app to their address book or speeddial, that the phone makes it so easy for them to participate in your application anytime, any place, that phones record better audio than most computer mikes, and so on. Tailor this to your application, of course.
3) Show users what is happening during a call within the Web app. Provide realtime updates on the call’s progress. Not only is this informative, helping users to understand what they are doing, but it’s also something of a magical experience for new users to see something they are doing on their phone tied to the Web experience. A good example of this principle in action is our VoxPix application. When you take a slideshow and add voice narration to it with VoxPix, as you record voicing for each slide, you see the slide appear on the Web app, and are told you are recording for that slide. This provides that magical fun, and also makes the process of recording audio for twelve photos much less confusing than if they were simply being told “record slide number eight after the tone” without visual feedback.
3) Iconography is good. You may not have much space to work with in your application, particularly if the phone is only one small piece of the puzzle, or if you are developing for a limited-space environment like Facebook. Here, a simple icon of a phone, handset, or touchtone keypad can convey much of what you want, in very little space.
4) Think about international callers. Not only do they want a phone number that won’t create international long distance charges, but they also need to be addressed in their home language, so you may need multiple versions of your application (or at least multiple “voice skins”). If you can, try offering access through VoIP providers as well. There are a lot of Skype users out there, and it’s becoming easier and easier to offer a direct Skype address for your users to call.
5) Customize the audio experience. The phone is a great branding and messaging opportunity; audio and voice can convey mood in a way that’s much more difficult to pull off in text on a screen. If you have a radio or TV presence, bring your voice talent or audio iconography to the phone prompts. If not, consider using hired voice talent that matches your brand and target demographic. Keep the prompts short, and make sure the voice talent enunciates.
6) If you are using menus or speech reco, be very, very clear in your prompts and menus/grammars. We’ve all been through touchtone hell; don’t contribute to the problem. If you choose speech reco, either keep things extremely simple, or go ahead and hire an expert. Otherwise, you risk users speaking words or phrases you haven’t anticipated, and creating confusion. When in doubt, choose the lower-tech (and usually cheaper) alternative of touchtone.
7) Provide readily available help. This might seem like a no-brainer, but almost nobody does it (and we are guilty of this too). A simple paragraph of mouseover help might save 10% of user experiences that will otherwise fail. 10% is a huge upside for such a minor, quick measure.