Product Development and Testing

The next few months were hectic. The concept needed polishing, UI bugs had to be ironed out, the concept had to be verified with users, and specifications had to be written for implementation. Finally it had to be programmed and tested. The software group led by Lars Bergmann and Flemming Klovborg made a tremendous effort. Flemming and his team wrote the specification in the record time of 8 weeks. The implementation path was to modify the existing software from Nokia 8110. Such a leap could not have been made if the phone had not been based on existing software. Fortunately, we had a very flexible architecture well suited to style variation. Within 5 months from project start, the first prototypes were on the bench.

Seeing the Navi-key user interface style live and working in a phone was almost like seeing new life. It was a major energy booster. The phase after specifications are frozen and the first software builds are released is a dark time of skepticism, but when the first build runs in the prototype hardware, everyone becomes intoxicated with energy.

The final detail we needed to solve was the design of shortcuts to phonebook and the redial list of recently called numbers. After considerable debate, we decided to depart from the logic used in other Nokia phones, where scrolling down from the idle screen discloses the first name in the phonebook in alphabetical order and scrolling up discloses the last one. In Navi-key UI scrolling down takes the user to phonebook as usual, but scrolling up opened the redial list. The pair of up and down arrow keys that were so visually connected that they seemed to consist of a single scroll element actually provided two different functions. The solution was not consistent with those for other phone models and was rather counterintuitive, but this was a case of the art of logic. Simply put, redial was too good a feature to remove, and with the few keys available in Navi-key UI no other options were feasible. (See Chapter 2 for the rationale behind shortcuts.)

While product development was ongoing, we still harbored uncertainties about the overall usability and acceptability of the Navi-key concept. We did not want to fall into the 'bimbo trap' again and launch a phone that looks so easy that it's insulting. Another lurking trap was the 'marketing ease-of-use trap,' where a product at first glance looks like a snap to use in the store and then becomes a bear to operate when you power it up at home. We also had concerns about whether softkey calling without a dedicated send key really worked. The first concept test clearly showed that about 30 percent of users made error calls with their phones during the initial phases of using Navi-key. This figure was a bit higher than for phones with send and end keys. And finally, some users would lack the slightest idea of how to interpret a softkey: absent that understanding, one is pretty much lost with the Navi-key. There were numerous examples of people saying 'Oh, you work for Nokia, I really like your phones, but what are the texts in the lower part of the screen used for?' We even encountered two people who, after a 30-minute test, still did not have a clue of how the phone worked.

We decided to test the possible obstacles for Navi-key UI thoroughly. We needed to create a more conventional solution for a benchmark, so we mocked up a scrolling Ringo (as it sounds, a Ringo phone with send and end keys and up and down arrows). Our tests were performed with real prototype hardware. This was a unique case, as most design is done using PC simulators or paper prototypes. In the comparative test of Navi-key UI and scrolling Ringo, we noticed that using the Navi-key phone was regarded as a more positive experience than using the scrolling Ringo. At first users were skeptical about Navi-key, but the concept's simple mental model stimulated learning. Skepticism turned into learning and even approval. Maybe we had created user delight: a positive experience beyond expectations-the ultimate goal in all our work.

While the scientists were doing solid research work, team manager Lindholm was doing some impromptu fieldwork of his own. He conducted more than 20 parallel informal usability experiments to tax the concept to be able to defend it to the inevitable raft of internal skeptics. It was necessary to learn how users reacted to calling with softkeys instead of dedicated send and end keys. Lindholm was obsessed with the rate of error calls and how quickly people realized their mistake. He selected complete cellular novices for the test subjects to see how they learned. In the mid 1990s it was still possible to find people in the company who had never made calls on mobiles. Nokia was growing quickly, and not all people joining the company were telecommunication engineers. Some outsiders with no connections to Nokia were also recruited. About 50 percent of these people called by mistake when pressing the softkey, but most of them made only one error call. In fact, most of them were able to correct their error before the call was connected.

The most decisive of acceptability tests is the 'spouse test.' The rationale is that a spouse would never give praise for the sake of praise. The author is fortunate to have a wife who is not technologically driven and who represents what could be considered to be a normal person. She breezed through all the tasks with great relish, which was a surprise as she had previously expressed no interest in mobile phones. She has been a sworn Navi-key user since the product was launched.

Knowing the users' first impressions was important, but not enough. We decided that we wanted to gather more data on how their perceptions of the interface evolved over prolonged use. Accordingly, we arranged a test where six people received Navi-key phones to use for 6 weeks. We gave them only the most basic instructions about the user interface to start with, but we also set up a help desk that they could call. The 24-hour help desk consisted of a single person-Miika Silfverberg, a psychologist and an expert in mobile user interfaces. He promised that the users could call any time, day, or night, and clearly he was betting on getting his sleep. During the entire 6 weeks, Miika got one call. The users weren't slacking; they were just happy, and they had used most of the implemented features.

These latest tests were done partly to find confirming evidence for the concept, as we had started to run a new project (a follow-up basic category phone, Nokia 5110) for which the Navi-key user interface was under consideration. The long-term test, of course, could not have affected the Nokia 3110, as we already were past the point of no return. We were in fact in the predictable 'generation trap,' where some critical parts of the next generation had to be frozen before we could collect real feedback from the previous one. This dilemma between continuity and evolution is difficult to manage in new-product creation, and unfortunately it occurs constantly. The way to solve it is to ensure that people are motivated enough to do several consecutive projects, where learning can be passed from one to another. Nothing beats the tacit knowledge of past experience.

By now we had performed lots of different tests on the phone and used this phone ourselves daily. We were feeling quite confident about its usability. What we didn't know anything about was the consumers' willingness to buy it. Generally we avoid the temptation to think that a user interface alone can sell a product. Usually the physical device characteristics, such as appearance, shape, and weight, have a more powerful impact. We therefore decided to wait for prototypes and then do a comparative preference test to acquire the statistically significant data we needed to galvanize our own salesforce.