Communications of the ACM

Designing for the mobile device: experiences, challenges, and methods

Applying -ser-Centered Design to Mobile Application Development

By Eeva Kangas, Timo Kinnunen
Communications of the ACM, July 2005, Vol. 48 No. 7, Pages 55-59
10.1145/1070838.1070866
Comments

Digia was among the first companies to develop third-party software applications that can be installed in Symbian smart phones by service providers or end users [3]. In 2001, Digia was searching for new product ideas for the nascent smart phone market. At the same time, the User Experience (UE) Group was established in the company and we began to work together with software engineers to transform product ideas into final products. The first product we worked on was the navigation software for Nokia Communicators known as Genimap Navigator, which utilized a Global Positioning System connection and a map database on a network server.

When mobile phones started to include cameras and Multimedia Messaging (MMS) capabilities, we discovered in a Contextual Design (CD) study [1] that users would also like to edit the images on their mobile phones. For example, they would prefer to send their digital images via MMS rather than using another method. The second product we designed was an application called ImagePlus, where users can, for example, add a text balloon with a message to the picture and send it directly from their mobile phones.

In this article, we discuss the User-Centered Design (UCD) process we used for the Genimap Navigator and ImagePlus products (see Figure 1). Genimap Navigator is presented here due to its mobile context of use and ImagePlus due to its direct manipulation interaction that was new to the phones at the time it was introduced. Both products have been adopted by the market. Genimap Navigator was licensed by Genimap, which is selling and distributing the product under its own brand. ImagePlus is licensed by several mobile phone manufacturers and also sold directly to end users via the Web.

For each project we used a slightly different process (see Figures 2 and 3). For Genimap Navigator, technology development was performed first and UCD came to the process after the concept and initial requirements were already determined by product management and the customer. In the ImagePlus development process, we were able to start at an early phase making a Contextual Inquiry (CI) study on end-user needs before setting the product targets and requirements. Both projects had major time and cost constraints, which affected the selection of the methods and the willingness to make changes, based on the usability recommendations. These projects were the first UCD projects in the company, so we sometimes faced organizational resistance against our usability design activities. We use these two examples to examine what worked, what did not work, and what we would do differently in retrospect.

Back to Top

Case 1: Genimap Navigator

Technology development for the Genimap Navigator started several months before Digia's UE group was established and brought into the project. Product management had set the high-level requirements with the customer (licensee) and technological partners. There was no chance to conduct any user needs study. We were expected to create the user interface (UI) specification for a pilot product running on the Communicator. This pilot product would be used by the customer organization and field test users before committing to a commercial product.

Since the pilot implementation project had already started, we had to create the UI specifications as quickly as possible. To guide our designs, we had feature requirements from the customer and the UI style guide for the Nokia Communicator. We decided to have a three-day UI design workshop with engineers and make a quick paper prototype test with co-workers at the office. The design seemed to work for co-workers so we documented it in the UI specification document. This design was not completely followed by the project engineers because they had already started implementation while we were still working on the document.

At this point, our feeling was that we and our customer did not know enough about the real needs of the end users. We decided to use pilot testing to get real user-needs data. After the pilot product was ready for testing, 20 participants used the pilot version for three weeks and kept a diary of their experiences [7]. After the test period, the diaries were analyzed and our usability specialist interviewed the users. This provided us with the facts about the importance of the features during actual use as well as the usability problems in the product.

The pilot study revealed the needs that arise from the mobile context of use were not supported by the product. For example, Genimap Navigator has a "yellow pages" service search for locating services based on a text string. In the pilot test we discovered that users wanted to know about the location of the nearest taxi station, but the service search provided the location of the taxi owner's home or office. The service was not context-aware at all. It was also discovered that the limited context of services was one of the main reasons why users considered the services not useful. Information and service needs vary, not only according to the location but also according the user and the usage situation [6].

Based on the pilot test results, we revised the UI of the commercial version. We provided access to the three most frequently used features from the application command buttons, and moved the less-used features to the menu, since we were not able to convince the customer to omit them. To confirm the design changes, we conducted a one-day paper prototype test with three end users. We also reported the service-related usability problems to the customer.

Finally, when the commercial version was completed and delivered to customer, we organized a usability test with the real product to get feedback for potential future product versions. Again, we did not have a large budget for an as-yet unclear business case, so the test was conducted in a laboratory setting, not in mobile environment. The usability test revealed several problems in the product, but improvement recommendations were too late for the delivered product.

---

The most important aspect of the design process is to provide the user with the real usage context. For mobile phones this means users need to be able to touch the buttons and see software that feels like it is actually working.

---

Back to Top

Case 2: ImagePlus

Parallel with the Genimap Navigator development we convinced company management there is a process very suitable for undertaking front-end research for product ideas. We conducted a two-month CD study, in which eight persons from UE, engineering, and marketing participated. The study focused on mobile messaging among professionals and teenagers and included both CI and concept design for several applications.

One of the concepts from the study was an integrated image or multimedia message editor in the phone. The visual and emotional communication between teenagers prompted this idea. When the first Series 60 camera phone with MMS (the Nokia 7650 model) was introduced, it did not have image editing capabilities, so the company considered the concept an idea worth developing.

In addition to inquiry findings, we examined various PC image editing software to gain more understanding of the features and interaction. We easily created a long feature list by compiling the basic image editing features of the PC software. Then we focused on designing the basic user interaction using the Series 60 UI style. We decided to apply the direct manipulation concept of a PC-based mouse to the phone's joystick key. We tested the design proposal with a paper prototype and iterated the basic menu structure and editing tool selection to improve the UI. After the paper prototype test we documented the functional and UI specification using User Environment Design (UED) notation [1], which also included interaction design proposals for all the required features.

Project management used the UED overview to estimate implementation effort for each feature. Business and time-to-market calculations required that the project was completed within half a year, therefore we had to eliminate some features. Based on the findings of the earlier CD study, we decided to create a simple PowerPoint-like application for informal multimedia messaging rather than a full-featured Photoshop-like application for serious image editing.

We defined usability requirements for the main tasks and used these to create a usability verification plan. Due to the small budget, we decided not to develop a UI prototype for usability verification, but instead used the actual software implemented in each increment. During the development period, the UE team concentrated on refining the interaction details especially for direct manipulation tasks—resizing, rotating, or moving—of inserted icons, text boxes, and frames. Soon we noticed that interaction copied from the PC mouse did not work with the phone's joystick. One of the project engineers invented a better way for resizing and rotating, which proved to be successful in usability tests.

We organized two usability test rounds that caused several change requests to bring direct manipulation to the required usability level. A lot of effort and iterations were required to get a what-you-see-is-what-you-get experience when creating a cartoon-like text box on top of the image. It was also determined by Ketola that many rounds of iteration are often needed to get the UI details right in mobile phone design [8]. In addition, one of our competitors launched their product before us, and we were able to reuse one interaction idea that made direct manipulation finally acceptable. The project was completed three months later than the initial schedule. This delay was caused by both a lack of engineering resources and the change requests from the usability tests.

Back to Top

Lessons Learned

The Genimap Navigator and ImagePlus projects taught us a lot about how to apply UCD within tight budgets and schedules. After the projects, we developed our software engineering process so that we could apply UCD more effectively to the upcoming projects. Here, we discuss the UCD activities we consider especially useful in mobile application development.

Focused CI studies. Even though ImagePlus is a successful product, we have not used such large CI studies in every development project. For a small company or customer, it seems quite challenging to invest in user-needs research, since the budget is often planned to cover only the implementation costs. If we have had a design case where we lack user-needs understanding, we have made a focused CI study by two or three UE designers instead of a large user needs study conducted by a cross-organizational team. We have conducted the study in a light way, interviewing only 6–8 people and analyzing the data by creating affinity diagram, sequence models, and personas [2]. Often when a budget has been extremely small, we only use the contextual paper prototype tests in the specification phase of the project to get the necessary insight on user needs. Users are interviewed in the beginning of the session before presenting the prototype and when going through the mock-up, test tasks are created based on the interview. Hurst calls this method of getting the test tasks from users a listening lab [4].

Realistic UI prototypes for mobile applications. With both Genimap Navigator and ImagePlus, paper prototyping helped to get end-user feedback before anything was implemented. It was easy to add and remove features—even halfway through a test. It is a method that every interaction designer at Digia uses when designing the first proposal of a new software application before writing the UI specifications. When the application is simple and interaction is based on standard UI style components, a paper prototype test is a sufficient method for verifying usability before the actual implementation. However, whenever we create new, more sophisticated interaction without a clear design reference, such as map zooming in Genimap Navigator or direct manipulation in ImagePlus, a more realistic UI prototype is needed.

In the ImagePlus project we were able to iterate the UI details by making the changes to the actual code. Even though the final usability of the product was good, the constant change requests caused delays and frustration in the project. We have not calculated the money spent on iterations, but our current understanding is that we should find the usability problems in interaction design earlier—before the implementation—to avoid unnecessary change requests. In PC and Web environments, UI prototypes can be created and quickly modified with current tools parallel to specification work. PC demos can also be created for mobile applications faster and with less effort than actual coding in the phone, but they cannot be used very well for getting the real feeling from the keypad and display interaction. PC demos are more useful for visual UI testing, or when testing devices involving stylus interaction.

After ImagePlus we made a UI prototype for one project just by "hacking" a demo into the actual phone with C++ code. The demo focused on the usability issues identified in paper prototype phase so it did not include all the features. Even though the development of the demo took six person-weeks to implement, it helped us to define the detailed interaction during the specification phase. Our biggest concern is finding better tools to make quick UI prototypes with less cost than actual coding. Mobile device manufacturers have worked in this area as well [9–11].

Usability testing in the mobile context. In the ImagePlus project, usability testing of the product was conducted in the meeting room (usability lab) environment. The tests and results were useful and suited to this application because the end-user tasks were not related to a specific mobile context.

For Genimap Navigator, traditional usability tests were not very useful because simulating the relevant use cases was not possible in the office. We conducted a large pilot study in the middle of development, which gave us a large amount of information that was missing at the start. However, a large pilot study is too expensive and occurs too late to get end-user requirements for the product. The diary method was good for gathering information about the usage of the functions, but not very efficient for gathering the detailed usability issues on the go. We were missing the important insight from the ongoing tasks that is useful in traditional usability tests. In future projects that have a mobile context, we will also include an observational part during field testing. Replacing the video cameras used in a usability lab with something more portable is one area that needs to be developed. For example, Isomursu et al. [5] have studied using camera phones to support observations in a mobile context.

Back to Top

Conclusion

When designing any product, mobile or not, good UCD practices help to ensure the product works. No feature should be added to the product only because it is easy and cheap to implement, or because you think it is a good idea. The most important aspect of the design process is to provide the user with the real usage context. For mobile phones this means users need to be able to touch the buttons and see software that feels like it is actually working. Paper prototypes are good because they can be used for verifying the product requirements without any investments in technology or development. They can also be used in a real context to get a relevant testing environment, but they are not sufficient for solving the usability issues of the final product, especially detailed interaction or performance.

We are planning to work on practices that speed up the construction of realistic prototypes for mobile phones [12]. This will allow us to test as if we had the final product, but the prototype can be provided earlier and less expensively. In addition, methods and tools for observing and testing in the mobile context needs to be developed further. Our experience shows that realistic prototypes are even more important for understanding the detailed requirements of mobile software when compared to traditional software. Even though we have had mobile phones and other mobile devices for some time, there will be an increasing number of opportunities for application developers. We are confident we can continue to use traditional proven design practices as we improve them and increase their flexibility for a more mobile environment.

Back to Top

Back to Top

Back to Top

Back to Top

Back to top

The Digital Library is published by the Association for Computing Machinery. Copyright © 2005 ACM, Inc.

---

No entries found