Vision Management

The UI creation process starts with a vision, the discovery of undetected user needs, a foreseeable change in the industry, or simply a spark of inspiration. The initiative can come from anyone. UI management is responsible for recognizing fruitful initiatives and arranging for ways to nurture them. Getting started doesn't depend on piles of reports; a few presentation slides with sketches or text notes, or even a forceful sentence or two, may be good enough.

What is paramount is that the message is presented in person to the right audience. The challenge is to find the people who see the value of the idea, who have a demand for that kind of innovation, who have the power to drive the idea, and who have the expertise to turn the ghost of an idea into a tangible concept. Personal presentation of the initial ideas enables instant adaptation and modification of the vision in order to increase the stakeholders' commitment and interest.

Vision-driven design is not based on comprehensive analysis of background information. It aims at recognizing an attractive goal for development, and then the goal guides the project's progress, putting details into their appropriate places and giving them the weight they deserve. The vision, even though its origin cannot be defined in a completely satisfactory manner, is typically based partly on professional understanding and ideals, and partly on the task-related criteria. It is possible and necessary to continue gathering more and more task-related information during the process, but if the original direction is not the right one, no amount of effort will help.

In introducing a vision, it is not important to paint a complete picture. A vision has to leave ample room for imagination. If there is nothing to spark the imagination, how can one get the audience excited? The vision has to provide the spine, the goal or beacon to guide the design team throughout the development process. The vision can and should evolve as more data and knowledge is discovered. But if the vision collapses then the project should be terminated. There is no point in continuing without a target, without something to give the work its gratification.

Metaphors are good tools to use in visioning. A good metaphor clarifies a vision with just a few words. The beauty of a metaphor is that it is often easy to remember, and it communicates across professional and even cultural borders. It should be rugged, yet adaptive to the situation and the audience. No metaphor is bulletproof, but then again it doesn't have to be.

start sidebar
Product Substitutes

Think of a car, shoes, a bicycle, and a scooter. All of these serve the same basic need to transport humans from one place to another; hence these products are all in the human transportation business. Nokia is in the communication business, and our objective is thus to create communication products; and these will be as different as a car is from a bicycle and a bicycle from a shoe, and so on. These products will become both product substitutes, as cars are to motorcycles, and product complements, as shoes are to scooters.

We do not know if a phone is a car or a motorcycle or just a pair of communication shoes. By the time we find out, we already have devices profiled to communicate some or all of these.

end sidebar

Product segmentation means creating focused products for specific customer segments. The individual product usually cannot be good at all things, and it is even acceptable for a product to be bad at something. In fact, the existence of a weakness can reinforce the observer's recognition of strengths. One of Nokia's senior UI design experts once used a motorcycle metaphor. He said that if you buy a motorcycle, it starts raining when you take it for a spin, and you get wet, is it a bad motorcycle? Of course not. If rain protection had been a key concern, maybe motorcycles would never have been created.

A more concrete way to describe a vision is to create a scenario. A scenario of an everyday situation encourages the audience to relate their own insights to the vision. The scenario is a story about the use of a product. It describes the people using a product, the environment in which they use it, their procedures for using it, the product's features, and the benefits it provides to users. Scenarios used in presenting visions must be elaborated to the point where a usage context can be linked with the idea. Sometimes this is very obvious from the very beginning, but in other cases scenario building may require additional efforts. Concerning the presentation of the product itself-its physical appearance and the user interface-scenarios are flexible. The product can be clearly illustrated or hidden, and we can express what needs to be expressed through the created context.

Construction plans of information society are often presented as scenarios-they can present very imaginative worlds of technology visions. It is relatively easy to create stories where the technology is perfect and all limitations and problems related to the acceptability and usability of new solutions are omitted. What makes scenario building interesting, though, is incomplete technology and a commitment to the concrete requirements set by human behavior. There's no fear of getting lost in utopia if you stay with stories where people as they are around us right now consume novel technologies.

The best scenarios, like the best metaphors, are simple, so that they can be remembered and passed on to a third party. A scenario has to progress in a straightforward manner. Information is given out as small, logically progressing steps. This is necessary to make services that are often complicated, easy and understandable to follow. A single scenario can combine in a flexible manner what is already known by research or past experience, and what is the innovative created content. The credibility of new ideas is often tried for the first time when writing scripts for a scenario. For some product ideas, it is extremely difficult to write a scenario; this recalcitrance may indicate problems with the ideas themselves. A technically interesting idea may face problems in finding its place in a realistic context of use.

In addition to metaphors and scenarios, a third conceptual tool for vision-driven user interface creation is a design driver. A design driver may be defined as a design objective that (1) has a very high priority in concept creation; (2) characterizes the concept in a way that underlines its distinctive properties; (3) is comprehensive by nature, affecting several aspects of the design; and (4) can be presented with one simple, clear sentence or phrase.

A good example of a design driver is one-hand use. The driver is easy to understand and communicate with. The decision to adhere to single-hand use has a profound effect on several aspects of the user interface design, such as the terminal's form factor, key layout, key press sequences, and the implementation of shortcuts.

Design drivers are more explicit definitions of the design objectives than metaphors or scenarios. They closely resemble design requirements but, as opposed to requirements, do not ascribe certain values to individual objectives. Instead they identify the most important dimensions that need to be optimized in a concept. A design must be driven as far as possible with reference to its drivers. Other design objectives of lesser importance will later be matched to the overall concept that the drivers have introduced.

To summarize, vision-driven user interface design is a way to direct development by highlighting desirable goals for stakeholder commitment and by giving a 'soul' to the design from the very beginning. Vision guides the process and gives meaning to the details. Vision can be explicated and managed by metaphors, scenarios, and design drivers. However, visions are never fixed, but always open enough to nurture the design team's imagination.



Mobile Usability(c) How Nokia Changed the Face of the Mobile Phone
Mobile Usability: How Nokia Changed the Face of the Mobile Phone
ISBN: 0071385142
EAN: 2147483647
Year: 2005
Pages: 142

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net