| |
4.1. Process
53
4.1.1 Choose a Compelling Problem Domain
For applying ubiquitous and wearable computing technology in practice it is impor-
tant to choose a problem domain, that on the one hand allows to build a compelling
application from the end-user’s perspective, but on the other hand allows to reflect
on the impact the application might have on the user’s daily life. The purpose of
choosing a compelling problem domain is not simply to provide a demonstration ve-
hicle for research results. It is to show how technology can serve a real or perceived
human need, because, as Weiser noted
[
Weiser 1993
]
, the whole purpose of ubiq-
uitous computing is to provide applications that serve humans. The evaluation of
population statistics can o er one way to reveal social, economic, demographic, and
consumption-related patterns that may become future shaping trends, as suggested
by
[
Oulasvirta 2004
]
. Nevertheless, reflecting on the opportunities of a problem
domain will certainly help to conduct more successful projects. Based on these
consideration the value of cooperating with certain domain experts can be judged.
However, we are aware of the fact that the freedom of choosing a problem domain
is not always given. But one should be aware of the fact that the relevance of
the problem domain has a strong influence on the relevance of the solution to be
developed.
4.1.2 Understand the Problem Domain
It is important for the developers to properly understand the domain a solution
should be developed for. Accordingly, the result of this phase should be a solid
understanding of the users’ ultimate goals, driving forces, and constraints of estab-
lished routines, and the current implementation of the work practices. As Nielsen
[
Nielsen 1993
]
pointed out, user involvement in this early phase is important: “It
is amazing how much time is wasted on discussing what users might be. [..] It is
much better to get hard facts from the users themselves”. The focus should be on
high-level concepts, such as the users’ goals1, needs, and priorities. This is di er-
ent from writing task descriptions for creating use cases as suggested by software
engineering disciplines
[
Sutcli e 1998
]
. Useful methods can be observation
[
Beyer
and Holtzblatt 1998
]
, literature reviews, or workshops and meetings. The important
point is to look behind the scenes in order to understand:
What are the users’ ultimate goals?
What are the constraints and reasons for established routines?
How could the goals be achieved in a completely di erent way?
1Referring to Leontev’s framework of activity [Leontev 1981], activities can be decomposed into
combinations of tasks, that are planned and directed towards achieving a goal.
|  |
|
| |
|
|
