Lessons-learned in the case project and other observed projects can be expressed as engineering guidelines. The guidelines are structured following Tianfield's (2001) discussion about product development complexity. By using word guidelines I emphasise that they are engineering ideas tested in practice, and may be useful to other usability engineers. The guidelines are not mandatory for ensuring success; it is up to the practitioner to decide which, how and when guidelines are useful in the specific development setting.
9.3.1 Adjust Usability Engineering to Complex Organisation
The organisation of Nokia Mobile Phones is complex due to high number of employees, multi- site product development, cultural diversity, high degree of virtual teams and personal networks.
Due to the Law of Requisite Hierarchy, the organisation continues growing even more complex because of the need to increase the product variety. Continuous flow of new products is an opportunity for product development. It enables quick learning from recent products that are on the market and available for field studies. Flow of products also makes it possible to share resources with parallel projects.
Usability engineering methods or lifecycle descriptions do not give guidance to the organisational aspect, because the focus is mostly on describing the optimal way to design usable products in a simple organisational setting. However, there are some sources giving examples of successfully managing usability engineering in also large companies. Wiklund (1994) provides an extensive overview over several U.S. companies (Kodak, Apple, Compaq, DEC, Hewlett-Packard, Silicon Graphics, Borland, Lotus, Microsoft), mostly focusing on the software industry. Radla and Young (2001) describe lessons learned from starting usability activities in three companies:
- excellent interpersonal skills are crucial to developing relationships with development teams.
- applying the results of HFE (human factors engineering) activities to thought leadership in product development makes the company more successful and raises HFE's credibility - working directly with the customer creates high visibility with management, marketing, and
product teams.
- even when schedule pressures are intense, HFE is possible.
- expensive labs and equipment are not necessarily prerequisite for HFE.
- most resistance comes from other pressures (such as schedule) and lack of information.
- there is no substitute for observing user interactions first hand Guidelines to deal with complex organisation
1. The role and organisational position of a usability engineer needs to be clear, accepted and understood by other members in the development organisation (project).
2. A usability engineer needs to have authority to co-operate with different kind of teams in many product development sites. A usability engineer needs to co-operate and involve in the work of local and remote, natural and virtual product development teams.
3. The existence of multiple product development sites should be exploited, because they provide straightforward access to local cultures and users.
4. The continuous and parallel flow of products should be exploited in the form of continuous building of domain specific usability knowledge, in order to efficiently share product understanding and to share usability resources.
5. Formal training and education of designers should consider similarities to other design fields (Karat and Dayton 1995).
6. More members than just usability specialists in the development team needs to be involved in usability activities (Karat and Dayton 1995).
9.3.2 Adjust Usability Engineering to Product Development Process
The CE product development at Nokia Mobile Phones is well-defined process, with special emphasise in the timetable reliability and predictability, and product quality. CE process is applied by defining common milestones for parallel project activities. Parallel development activities are controlled and development risks minimised with the milestone reviews.
Milestones are useful for usability engineering because they provide predictable information about the expected advance of a project (timetable), and beforehand define what are the expected deliverables of different design areas in each milestone. Especially, the knowledge about early design phases is important because this is the most cost-efficient time for usability engineering in a project.
Guidelines to deal with product development process
7. Usability engineering should be aligned with product development milestones and processes.
In each milestone (n), the knowledge from previous milestone (n-1) is the input data. Input data can be also achieved from other development projects. The next milestone (n+1) is the next target. The usability engineering goal for the next target should be formed based on the current (n) understanding of product strengths, weaknesses and identified design risks. The transformation (n-1 → n → n+1) needs to be known for each concurrent process where usability engineering is performed.
8. The defined deliverables of milestones should be used as input information for usability engineering.
9.3.3 Adjust Usability Engineering to Complex Product Structure
Mobile phones, especially smart and innovative products have often technically complex product structure. Product usability is dependent on a number of product elements in the user interface, the external interface and the service interface. During the development process the product components are designed in parallel and integrated in the late phase. The success of integration, including accessories and services is based on well-defined specifications and deliverables of different product development process. The product testing (system testing, integration testing) is an intensive and demanding task, and must be managed in smaller units during the product development. The complexity of product structure sets many implementation risks to product development difficult to manage. It also sets many risks to user acceptance.
Examples 2 and 3 indicate that along the increase of product complexity, the need for product customer support increases.
The weaknesses in existing usability engineering process descriptions, for example ISO 13407, is that they are software oriented, are not well-adapted to mobile context (but rather office appliances and software), and they do not take into consideration product ergonomics and the three interfaces.
Guidelines to deal with complex product
9. Usability engineering should cover, in some form or another, all product elements that have an effect on usability.
10. Usability engineering needs proper coordination (planning and follow-up). Innovation and design efficiency should be maximised before M(EarlyToLate) and minimised after M(EarlyToLate).
11. Product risk management should be supported with the human-centred knowledge gained through user testing.
9.3.4 Adjust Usability Engineering to Complex User Requirements
When the new product introduces functions not familiar to users or designers, the designer often has not enough knowledge about the user requirements. Sometimes the users do not have specific needs and correspondingly requirements, towards the product or new functions, and the needs must be created by marketing activities. Especially with innovative functions, the elicitation of user requirements is a large job and may not be practically at the hands of a designer or usability engineer. In the worst case, without access to the users, the only method for identifying user needs is introspection (Järvinen 1999, 100). Due to individual differences and lack of real use context this potentially leads to design uncertainty.
Organisational memory is cumulative information about history having effect on the decision making of today. It consists of three components: the traditional knowledge bases, experts and prototypes. Information about existing solutions resides within the artefacts (prototypes) themselves (Hargadon and Sutton 1997). Walsh and Ungson (1991) conceptually analysed organisational memory, especially the three processes: acquisition, retention and retrieval. They identified five storages (bins) for organisational memory: individuals, culture, transformations, structures and ecology, but failed in capturing prototypes as storage. Organisational memory is perhaps the most powerful "tool" in dealing with complex and emerging user requirements.
Usability engineers have an important role in building and structuring those parts of organisational memory that deal with detailed information about end-users’ requirements, needs and skills.
New functions, especially in information technology products, are created by combining or restructuring existing technologies and functions, or by introducing a whole new technology or function. New functions are also often combined to larger service entities, end-to-end solutions.
User requirements for this kind of functions are complex. According to Hargadon and Sutton, designers and usability engineers need to exploit their access to a broad range of technological solutions with organisational routines for acquiring and storing knowledge in the organisation’s memory and, making analogies between current design problems and past solutions they have seen, retrieving that knowledge to generate new solutions to design problems in other industries.
Guidelines to deal with complex product requirements
12. Elicitation of user requirements should be done outside and before the product development because this part of the work is time-consuming and may not fit in the intense product development timetables.
13. At least introspection should be used for finding user requirements. However, this is recommended only when nothing else can be done in order to find out requirements.
14. Knowledge about user-requirements obtained from simulation or product prototype testing should be actively collected and shared in the organisation.
15. The design and usability testing for first use (out-of-box readiness) need to be included in the early product development.