SlideShare a Scribd company logo
1 of 6
Download to read offline
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <

1

Crafting Infrastructures.
Requirements, scenarios and evaluation
in the SPICE project
Luca Galli, Neos, Lukasz Nalaskowski, Telekomunikacja Polska,
Jordi Rovira Simón, Telefonica, Tomasz Koloszczyk, Telekomunikacja Polska

Abstract—The evaluation of infrastructures in large and
collaborative R&D projects pose novel challenges to UCD
methods. The lower level of these technologies if compared with
applications meant for direct user interaction brings a level of
indirectness to the activities. This paper examines some previous
research on the subject and then reports about the ways in
which the SPICE project faced this challenge, with special
regard to the scenario and requirements design process and how
focus groups-based evaluation had on impact on it. Concluding
remarks on the experienced collaborative dynamics discusses
the possible role of craft-inspired styles of working.
Index Terms: User centered design, Research and
development management, Scenarios, Requirements, Focus
groups
I.

A

INTRODUCTION

PPLYING UCD-User Centered Design methods usually
requires more than a disciplinary grounded, cultural and
ethical commitment to user centricity. In fact, every design
effort is specifically situated in a certain setting, which calls
for interpretation and adaptation from the professionals
involved. Design at the R&D stage is even more challenging,
given the future orientation, risk-bounded, exploratory nature
of the work. Doing R&D in multiple organizations,
international, collaborative initiatives – as typically are
European IST projects [1] – brings yet another wave of
complexity. Finally, scope and nature of what has to be
researched and designed are obviously of outmost importance:
one thing is to specify and evaluate an application aimed at a
well defined task, a very different one is dealing with
technology infrastructures not meant for end-users’ direct
manipulation and interaction.
The latter is the case of SPICE [2], which is the reference
case of this paper. The project aims at building a platform
that will enable and ease service creation and execution,
integrating advanced features based on complex roaming,
discovery, awareness, matching and delivery mechanism.
Methods and techniques such as requirements analysis and
definition, or scenario building and evaluation, had to be

applied taking into account these specificities. The issue as
such is not relevant only for SPICE, since several R&D
projects share the same characteristics. This paper will briefly
review some of these previous experiences and then will
illustrate how SPICE researchers dealt with the issue outlined
above; the ensuing discussion will reflect on some possible
broader aspects concerning UCD and design methodology in
general.
II. PREVIOUS RESEARCH
As anticipated, SPICE tackles with user-centricity in a
quite complex setting. Two major aspects are relevant here:
first and foremost, the fact that the researched and developed
technology is at the infrastructure level; second, the
distinctive attributes of large and collaborative projects. Both
of them pose important challenges to traditional UCD process
and methods [3][4], that are often used and has proved to be
fruitful in well defined domains, with a single organization
targeting specific users for a set of tasks and activities (the
occurrence of two-tier organizational structures, including
design consultants and their customer, does not appear
overtly different).
A. UCD “extra-large”
Generalising from the MobiLife project experience on the
adaptation of UCD in the context of large and distributed
projects, [5] proposes an “extra-large” specific UCD style to
cope
with
the
critical
mass,
abstraction
and
compartmentalization of these collaborative efforts; special
attention to the difficulties of researching technology social
acceptance is also given. A number of practical
recommendations have been formulated there: they include
the opportunity to conduct early test of the functional parts of
what it is still under development (“Break out of the big
loop”); concretization of abstract ideas (even though this is
“not always feasible with enabling technologies”, as discussed
below); maintenance of an empiric orientation (scenarios are
useful for developers but might be unrealistic for people out
there); prioritization; frequent interaction among developers
and user researchers, making user research a collaborative
activity and UCD an “integrating perspective” located at an
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <
higher level or external point of view, somewhat independent
of specific technology agendas.
Besides these managerial and organizational issues, there
are other critical aspects more related to the research subject,
especially with regard to enabling technologies. In fact, [5]
highlights as well some inherent difficulties of bringing
software components or “enablers” to the field for direct
experimentation with end-users.
B. UCD challenges in evaluating infrastructures
As noted by [6], the issue of evaluating lower level
components or technology enablers is an important and still
not really explored terrain. In general, little research is
available on the evaluation of software infrastructure
according to user-centred methodologies: once applications
with some clear intended scope and user access are not at the
centre stage, criteria for designing and evaluating the features
of the infrastructure itself are less certain. User-visible
applications have long traditions of user-centred design and
evaluation, if compared with infrastructures. In the latter
case, issues regarding the development of fully working
prototypes with acceptable usability or small scale prototypes
are to be considered carefully, because they could not generate
expected results. The same goes for the usage of fake features
or simulations for components that will have some interaction
in the future with the infrastructure, but are not strictly
related to that. Developing applications with the desirable
quality level might be not possible at all or only at the risk of
big delays and wasted resources. By going trough the
evaluation of several applications enabled by an underlying
infrastructure, and reflecting on some major pitfalls, [6]
comes to the point of consolidating several “lessons learned”.
Interestingly, some of them are pretty much in line with those
put forward by [5].
Prioritize core infrastructure features is then lesson number
one. As before, the aim is to test practically “core design
ideas” and build additional features once evaluation results
are available. To really achieve this, researchers might have
to play with a “minimalist” infrastructure, or, in other words,
prototypes with very limited scope but that can effectively
convey some of the core ideas. All other work, namely what
does not leverage directly on the infrastructure, should be
deferred. Have e.g. a prototype that it is robust and secure
enough for use in real conditions is often a sensible objective,
but since the application layer as such is not the focus, the
effort needed to get there might be wasted. Yet test
application “must also satisfy the criteria of usability and
usefulness”, a criteria that the authors recognize as “difficult
to satisfy”, even though the challenge is somewhat lessened
by the recommendation that initial proof-of-concept
applications should be lightweight.

2

III. SCENARIOS & REQUIREMENTS
A. Overview of the SPICE project
The SPICE project addresses the problem of designing,
developing and putting into operation efficient and innovative
mobile service creation and execution platforms for networks
beyond 3G [7].
With the growing diversity of services, devices and
connectivity means, service platforms such as the SPICE
platform intend to provide end-users with communication
means and tailored applications anywhere, anytime and on
any device. This goal is sought by supplying service providers
with service enablers that ease and quicken (context-aware)
application development. End-users are not only considered
as consumers of those applications, since they can be service
creators at the same time. In this view, operators will take the
role of service platform provider and, if such it is the case,
service provider. The strategic role played by the platform in
this vision explains why the project strives to combine a socalled “platform-centric” approach with an end-user
orientation [7].
B. Design process
As many other R&D endeavors, SPICE started with a
technology vision articulated in a number of specific
objectives and embodied by a set of short scenarios, expressed
by brief textual narratives. This happened already at the
research proposal phase; user-centricity was not greatly
emphasized there, but the workplan included explicitly users,
i.e. external people not involved with the project, for two
iterative evaluation activities, the first at the beginning and
the second at the end of the project. Focus groups are
mentioned as the method of choice.
The proper design process began with a very detailed
requirements specification activity, in partial overlap with the
actual scenarios definition and in reciprocal influence with
other research activities, namely architecture work, initial
analysis of business models and legal issues.

Fig. 1: interactions between requirements, scenarios, architecture, business
models and legal issues.
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <

The requirements work produced an output of 48 use cases,
considering four types of requirements: user requirements,
enterprise requirements, technical requirements and open
market requirements.
The ensuing work on scenarios took into account the
updated architectural view, the related functions, and once
again the parallel work on business and legal aspects to
consolidate the first complete version of the project scenarios.
These scenarios provided the basis for the first evaluation
round with end-users and professional users, conducted
through a number of focus groups, reported below.
The user feedback generated in the focus groups, as well as
the parallel work in business models and the technical
progress of the workpackages, has then been fed into a
scenario revision, reported below too with more details.
Starting again from this revision, currently yet another
iteration is ongoing, aiming at consolidate the different
scenarios into a unique and streamlined storyline, as well as a
more compact set of requirements, prioritized against the
most distinctive objectives and outcomes of the project.
C. Scenarios
The scenario work in SPICE is focused on the development
and refinement of a series of demonstration textual and visual
narratives that illustrate the main features and the potential
impacts of the service platform on European citizens, as well
as on service providers and telecommunication operators.
Given the necessity to communicate both with end-users and
professionals (included semi-professionals and talented
amateurs), a wide spectrum of diversified situations is
represented in these scenarios, ranging from context-aware
personal navigation for tourist groups to natural language,
semantically-enabled searches in components repositories
accessed by technical developers.
As said above, scenarios have been shaped early in the
project lifecycle, and have been initially consolidated in a set
of four stories, named respectively I-Portal, e-Tourism, eEmergency and Service Creation [8]. The first two, I-Portal
and e-Tourism depict different groups of end-users, mostly
families, in various service settings. The SPICE platform as
such does not appear in the foreground; the specific
experiences made possible by the platform are described
instead, mentioning SPICE as the enabling technology.

3

The last scenario, Service Creation, has an explicit
orientation to business and technical users: it describes all the
service lifecycle from the ideation phase down to each
development step (shortly: design, implementation,
deployment, management and termination) and makes
explicit all the related interactions between various parties
(e.g. a sponsoring company, a developer partner, an
operator).
The e-Emergency scenario includes both aspects, with
some scenes closer to the end-user point of view and other
scenes dedicated to the involved organizations and their usage
of the technology.

Fig. 3: scenes visuals from the Service Creation and e-Emergency scenarios,
describing prototyping processes, service announcement and personalized alerts.

D. The indirectness issue
Despite some differences in the emphasis and point of
view, a common aspect across the four scenarios is that many
scenes - if not all - are about an infrastructure that is not
directly accessible by end-users: in fact, they will use services
enabled by this platform. Even the case of professional users,
which will have indeed access to the platform functionalities,
is not entirely straightforward, as the disciplinary and
technical backgrounds of the professionals will likely be
varied: business and creative people will have to cooperate
with engineers; for them, the processes enabled by the
platform will be of outmost importance, more than its direct
manipulation.
The platform influence embraces also some key aspects of
the terminal capabilities, but also in that case the relevant
software layers might lie behind the users’ level. Indeed, they
enable several application features that are in the users reach,
from the capability to find a service suitable in a given
context to the possibility to use it while roaming abroad, but
are not directly visible per se. The most notable exception in
the project is perhaps the Dynamic Desktop, which provides
an interface to let the user interact with the platform, but
actually this is part of a broader work about technological
issues and features that again are well behind users’ visibility
[9].
IV. EVALUATION AND REWORK

Fig. 2: scenes visuals from the I-Portal and e-Tourism scenarios, describing
usage of local navigation services and context-aware push mechanisms.

It is now obvious that the UCD challenge of evaluating
technology infrastructures has been met and is being faced in
SPICE. Furthermore, SPICE is experiencing the same
“extra-large” characteristics described above, similarly to
many other cooperative projects.
As anticipated, the project workplan included focus groups
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <
as the evaluation method of choice, especially for the initial
project phase. The results of this evaluation and their impact
in the design process will be discussed in the following
paragraphs.
A. Focus groups
The evaluation has taken place in three countries: Poland,
Spain and Italy. It has involved both individuals with an enduser profile (8 focus groups) and professionals (2 mini focus
groups). End-user oriented meetings have been mostly
dedicated to the discussion of SPICE-enabled services from a
consumer / citizen point of view, trying to elicit respondents’
opinion about potential benefits and disadvantages of what
was shown in the stories. Professionals-oriented meetings
were concentrated instead on the process of creating,
delivering and managing these services, with special attention
to design, development and prototyping issues; potential
benefits and disadvantages were examined in this case too.
Among various preparatory tasks, it is important to
remember here that scenarios had to be adapted for the focus
group discussion settings. The number of scenes had been
reduced, as well as the narrative text, giving more emphasis
to the pictures and the SPICE feature main ideas. This way,
the translation effort of conveying the SPICE main features
through the scenario description has gone one step further as
the communication needs for which the scenarios had been
conceived moved from the experts to the general public.
Once the focus groups had been held, the analysis of the
related reports has gone through the following steps: first,
complete country reports have been produced, highlighting
the key benefits on one side and major disadvantages and
dislikes from the other side, for each scenario; second,
common results and variations have been spotted, with
special attention to the impact of country perspectives.
Finally, a set of actionable recommendations has been
elaborated, as a tool for the upcoming scenario revision [10]
[11].
Starting with the general results, some clear directions are
evident. Regarding the key benefits, across all countries and
profiles there was strong appreciation of everything related to
“convenience”, such as service international roaming, session
transfer, possibility to swap devices while using the same
service and personalize public devices, personalization in
general, access to protected content and content adaptation to
various terminals. Professionals appreciated very much the
possibility of having a support for faster and more effective
prototyping and service creation capabilities (but gave a
warning about the organizational challenges of prototyping
processes). Proactive context-aware recommendations
sparked instead lively discussions, usually prone to stark
criticism. Most of the cited disadvantages and dislikes were
mentioned in relation to that, especially regarding possible
misuse from companies, marketers and public organizations
as well. People feared that the tracking and profiles features

4

that enable these recommendations would trap them into a too
powerful system. Moreover, the usefulness of such
recommendations was questioned. Still, through the debates,
a number of potentially promising usage settings were spotted
and anticipated -- some alternative to the ones presented.
Notably, people seemed remarkably positive about personal
navigation features and the application of SPICE technologies
in working environments especially in comparison with
leisure traveling and other spare time situations.
Not surprisingly, the indirectness effect discussed above did
have an impact on the focus groups’ participants
understanding of the depicted features. Quite often end-users
seemed puzzled by the nature of SPICE itself, given its
apparent influence on so many realms (devices, services at
home and abroad, general tasks and very special events like
an emergency). Professionals too debated a lot about the
possible scope of the platform and its applicability to their
own environments; those with a non-technical background
were ready to pinpoint organizational and cultural challenges
related to the presented ideas. Yet such indirectness did not
hinder the discussion substance, articulation and richness. As
seen, focus groups actually generated much valuable feedback
about what was perceived as desirable or less so at the
scenario scenes level. Notable distinctions and subtleties
emerged as well, mainly dependent on the country and age
group of the focus group participants.
As outlined above, the user feedback has then been
translated into a set of recommendations for scenario
improvement. Some of them were quite high level (such as
“the general direction for further scenario development is to
build them around an active SPICE user that searches and
chooses then receives and accepts”), while most of the others
sounded more as practical hints, as the ones below (they are
related to different scenarios):
• Decrease to a few scenes the explicit reference to
proactive mechanism altogether
• Link clearly the delivery of proactive suggestions to
some user action or previous declaration
• Explain more about the Semantic Language
• Clarify what the emergency service is
• […]
Taken as a whole, such recommendations have provided a
body of suggestions that clearly called for a scenario revision,
actually already envisaged in the original workplan.
B. Enhanced scenarios
The user feedback coming from the focus groups was not
the only source to be taken into account. Parallel work in
business modelling and updated mock-ups features required
too some scenario updates. As a consequence, the project had
to complete an extremely detailed mapping of old scenes, user
feedback, modified requirements and new scenes [12].
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <
First of all, this started by identifying so-called “scene
requirements”, i.e. requirements regarding the scenes to be
modified according to the mentioned input sources. Second, a
controlled three-stage, step-by-step procedure had to be
defined:
1) Mapping the users’ concerns/comments on each of the
scenario slides adapted for the focus group discussions.
2) Identifying the correspondence between the focus groups’
scenes and the initial ones in order to put the right
“scenes requirements” into the original scenes.
3) Taking the original scenarios and applying on them the
scenes requirements.
Moreover, special care had to be used in applying such
scenes requirements. Given the different sources, the
enhancement process has followed a sequential approach,
beginning with the users’ enhancement and ending with the
business one; each of these steps has included an
enhancement and revision iteration.

Fig. 4: Excerpt from the mapping work; focus groups users’ inputs are codified
into detailed “scenes requirements” that are then mapped to the original
scenarios.

5

been given:
…The family is notified because they all selected this
option in their service preferences. As they do not know much
about Valencia, they value any information they can get.
Moreover, they trust the SPICE platform because it is
internationally well known for using fair recommendations
based on users’ preferences and ratings.
With regard to the service provider side, professionals that
attended the focus groups made a lot of questions about the
prototyping process and capabilities of the SPICE platform.
Hence, e.g. the scene depicting what is happening when a
developer wish to build a mock-up has been better précised:
…The service description is used as input to a Mock-up
builder (Mock-up generator). The Mock-up builder is a
graphical tool which enables Paul and his team to put
components together by drag and drop. In a couple of hours
the mock-up is done. The mock-up is non-functional, but it
can be displayed on any standard mobile terminal as well as
on PC or TV-based interfaces.
As said above, this set of refined scenarios is currently used
as a basis for yet another major iteration aimed at consolidate
them into a unique and all encompassing story, in which both
the parallel updated needs of the technical developments and
the users’ evaluation are combined, providing a global
framework for the project final demos and prototypes (to be
used again in the concluding evaluation phase).
V. METHODOLOGICAL DISCUSSION

The mapping exercise and scenes requirements formulation
has resulted in improved narratives, with focused hints and
pinpoints at the identified user concerns. To achieve that,
some scenes had to be removed altogether, other split in
different parts, others just modified.
If we consider e.g. the issue of personal identity and
context information matching (a frequent occurrence in the IPortal and e-Tourism scenarios), explicit reassurances have
been added to address the users’ concerns emerged in the
focus groups:
…it is impossible that the service makes use of users’
sensitive information in a malicious way since the local
SPICE Operator guarantees that user’s personal data (e.g.
name, address, mail, telephone…) are never matched with his
context information (e.g. position, mood, availability). Before
the service can use sensitive information, the user’s consent
must always be given.
Push mechanisms raised a lot of discussions in the focus
groups (with special regard to the e-Tourism scenario);
stronger rationale and clearer behaviours explanation have so

Scenarios, requirements and focus groups are definitively
no new tools for the designers, especially for those attentive to
user centricity. Yet they are not simple ones; if we consider
e.g. scenarios, they have a quite complex and long history,
spread among different disciplines and environments, from
software engineering to business strategy and futures studies;
much attention has been spent already on how to use them in
designing forthcoming technologies [13] [14]; the same holds
true for requirements and focus groups, with different
specificities.
Hence, SPICE could hopefully be useful to reflect on the
ways in which these methods or research tools have been
used; furthermore, we realized that researchers’ attitudes and
group dynamics were not less important than the methods per
se – quite understandably, given the situated nature of design
processes evocated at the beginning of this paper.
To start with, scenarios usefulness came out reinforced
from this experience, despite their limitations (concerning
e.g. the fact that they are so often technology biased and
prone to generate skepticism). In fact, given the difficulties
identified in previous research with regard to the development
of applications meant to demonstrate underlying
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <
infrastructure capabilities, scenarios proved to be a flexible
and cost-effective way to represent that capabilities; scenariobased evaluations are indeed less substantial than prototype
based ones – and for sure they can not just substitute them –
but allow at least to get timely feedback from the users and
push it back into the project. In order to do that, several
iterations might be needed: scenes descriptions and sequences
will have to be changed repeatedly, carving texts and visuals
until they express a good balance of the various interests and
viewpoints. It is much more than polishing: scenarios seem to
work better as a dynamic tool, in which rework has to be
taken for granted.
A similar approach has to be used to manage a consistent
and precise matching of scenarios and requirements;
technical and users requirements typically change over time
according to the technical progress or evaluations. A
successful reciprocal update is not less important than an
original complete formulation – which too often risks
becoming obsolete.
There are some aspects related to how the activities have
been performed, or, in other words, regarding individual and
group dynamics. Considering the entire scenario and
requirements design and evaluation, it is evident that the
process as a whole has been indeed a painstakingly
collaborative effort. More than a clearly pre-determined and
smooth cycle, the all thing resembled pretty much a craft
exercise, as it recalls the slow, cumulative, collective, patient
and prone to details work stile of craft. With a reduced
interest in focusing on just one or two well-limited
application domains, this sort of lower level type of work
might actually pay off in shaping the infrastructure features
against user inputs.
The metaphor of craft might appear a bit distant, but
perhaps less so looking back at the very early stages of userorientation in design and architecture, way before than by
“bringing design to software” [15] UCD started to gain its
stance in the IT field. Shaping the designer profile in the face
of novel challenges raised by then emerging interaction
between humans and machines, complex systems and
multidisciplinarity, John Chris Jones seminal reflections on
methodology called for a partial return of craft skills in
contemporary design practice [16] [17]. From a professional
and educational standpoint, some of the best qualities of the
ancient craft work might turn out to be still valid – above all,
a humble and patient attitude to listen people needs and
desires, as well the distinctive capability of the craftsman in
shaping his own tools.
In this respect, the lesson learned from SPICE is not one of
a method, or a set of specific actions, like an immediately
actionable answer, but more one of an approach or a way to
apply well-known design strategies and methods, forcing
their adaptation to the ever more important issue of
anticipating the future consequences of pervasive and
extended technology infrastructures.

6

ACKNOWLEDGMENT
This work has been performed in the framework of the
European project IST-2005-027617 SPICE, which is partly
funded by the European Union.
The authors would like to acknowledge the contributions of
their colleagues from France Telecom R&D, Alcatel CIT,
DoCoMo Communication Laboratories Europe GmbH,
Telecom Italia, Telenor ASA, Siemens, Siemens AG
Osterreich, Ericsson Telecommunicative BV, Nokia
Corporation, Stichting Telematica Instituut, NEC Europe Ltd,
Bull, Fraunhofer Gesellschatf zur Forderung der
angewandten Forschung, University of Kassel, Alma
Consulting Group, Vrije University Brussel, IRIS, Neos, The
University of Surrey, Norwegian University of Science and
Technology, Politechnico di Torino, Telekomunikacja Polska
SA, Telefonica.
REFERENCES
[1]
[2]
[3]

[4]
[5]
[6]

[7]

[8]

[9]
[10]

[11]

[12]

[13]
[14]
[15]
[16]
[17]

IST program web site: http://cordis.europa.eu/ist
SPICE project web site: http://www.ist-spice.org
D. Norman and S.W. Draper (Eds.), User Centered System Design. New
Perspectives on Human-Computer Interaction, London, Lawrence Erlbaum
Associates, 1986
J.D. Gould, C. Lewis, Designing for Usability: Key Principles and What
Designers Think, Communications of the ACM, vol. 28, No 3, 1995
E. Kurvinen, A. Aftelak, A.Hayrynen, User-Centered Design in the
Context of Large and Distributed Projects, CHI 2006
W.K. Edwards, V. Bellotti, A.K. Dey, M.W. Newman, Stuck in the
Middle: the Challenges of User-Centered Design and Evaluation for
Infrastructure, CHI 2003
C. Cordier, F. Carrez, H. Van Kranenburg, C. Licciardi, J. Van der Meer,
J. Zoric, A. Spedalieri and J-P. Le Rouzic, Advanced Beyond 3G service
delivery environment: the SPICE service platform design principles,
WWRF16, 2006
SPICE project deliverable D1.2 “Scenarios for the representative next
generation information and communication services”, edited by V.
Boutroux, 2006
M. Brosssard, SPICE. Best-Configured Communication Environment,
Helsinki WWI Symposium, 2006
SPICE project deliverable D8.1 “Pioneering SPICE project, a view by
focus groups from the fields of I-Portal, e-Tourism and e-Emergency
Services”, edited by L. Galli, 2006
Ł. Nalaskowski, L. Galli, J. Rovira Simon, Pioneering SPICE Project. A
View by Focus Groups from the Fields of I-Portal and e-Tourism,
WWRF18, 2007
SPICE project deliverable D8.2 “An in-depth view on SPICE project,
using Intelligent Portal, e-Tourism and e-Emergency scenarios”, edited by
J. Rovira Simon, 2007
K. Go, J.M. Carroll, The Blind Men and the Elephant: Views of ScenarioBased System Design, Interactions, 2004
L. Galli, Scenario methodologies, MobiLife Oulu Summer School, 2004,
available at http://www.ist-mobilife.org
T. Winograd (Ed.), Bringing design to software, ACM Press, Ney York,
1996
J.C. Jones, Design Methods, Wiley, London 1970. Third edition: Wiley,
1992.
J.C. Jones, Essays in Design, Chichester, Wiley, 1984.

More Related Content

What's hot

04 designing architectures
04 designing architectures04 designing architectures
04 designing architecturesMajong DevJfu
 
Information Technology Project Management - part 05
Information Technology Project Management - part 05Information Technology Project Management - part 05
Information Technology Project Management - part 05Rizwan Khurram
 
User Research and Scenarios
User Research and ScenariosUser Research and Scenarios
User Research and ScenariosItamar Medeiros
 
Hci in-the-software-process-1
Hci in-the-software-process-1Hci in-the-software-process-1
Hci in-the-software-process-1Ali javed
 
Activities Oriented Design Environments
Activities Oriented Design EnvironmentsActivities Oriented Design Environments
Activities Oriented Design EnvironmentsFarid Mokhtar Noriega
 
A Software System Development Life Cycle Model for Improved Students Communic...
A Software System Development Life Cycle Model for Improved Students Communic...A Software System Development Life Cycle Model for Improved Students Communic...
A Software System Development Life Cycle Model for Improved Students Communic...IJCSES Journal
 
A MAPPING MODEL FOR TRANSFORMING TRADITIONAL SOFTWARE DEVELOPMENT METHODS TO ...
A MAPPING MODEL FOR TRANSFORMING TRADITIONAL SOFTWARE DEVELOPMENT METHODS TO ...A MAPPING MODEL FOR TRANSFORMING TRADITIONAL SOFTWARE DEVELOPMENT METHODS TO ...
A MAPPING MODEL FOR TRANSFORMING TRADITIONAL SOFTWARE DEVELOPMENT METHODS TO ...ijseajournal
 
Usability For Business Analysts - 24 June 2009
Usability For Business Analysts -  24 June 2009Usability For Business Analysts -  24 June 2009
Usability For Business Analysts - 24 June 2009Optimal Usability
 
A HEURISTIC-BASED APPROACH FOR USABILITY EVALUATION OF ACADEMIC PORTALS
A HEURISTIC-BASED APPROACH FOR USABILITY EVALUATION OF ACADEMIC PORTALSA HEURISTIC-BASED APPROACH FOR USABILITY EVALUATION OF ACADEMIC PORTALS
A HEURISTIC-BASED APPROACH FOR USABILITY EVALUATION OF ACADEMIC PORTALSijcsit
 
Collaborative 3D Modelling and Printing: What you See is not Directly What Yo...
Collaborative 3D Modelling and Printing: What you See is not Directly What Yo...Collaborative 3D Modelling and Printing: What you See is not Directly What Yo...
Collaborative 3D Modelling and Printing: What you See is not Directly What Yo...Farid Mokhtar Noriega
 
Open Engineering Framework
Open Engineering FrameworkOpen Engineering Framework
Open Engineering FrameworkJohn Vogel
 
Project Mangement Planning and Risk Analysis
Project Mangement Planning and Risk AnalysisProject Mangement Planning and Risk Analysis
Project Mangement Planning and Risk AnalysisPramod Parajuli
 
Needs challenges and_opportunites_in_architectural_languages (bolzano_dec2013)
Needs challenges and_opportunites_in_architectural_languages (bolzano_dec2013)Needs challenges and_opportunites_in_architectural_languages (bolzano_dec2013)
Needs challenges and_opportunites_in_architectural_languages (bolzano_dec2013)Henry Muccini
 
Interact2011 - Designing Inter-usable Systems
Interact2011 - Designing Inter-usable SystemsInteract2011 - Designing Inter-usable Systems
Interact2011 - Designing Inter-usable SystemsVille Antila
 

What's hot (20)

04 designing architectures
04 designing architectures04 designing architectures
04 designing architectures
 
Information Technology Project Management - part 05
Information Technology Project Management - part 05Information Technology Project Management - part 05
Information Technology Project Management - part 05
 
User Research and Scenarios
User Research and ScenariosUser Research and Scenarios
User Research and Scenarios
 
Hci in-the-software-process-1
Hci in-the-software-process-1Hci in-the-software-process-1
Hci in-the-software-process-1
 
Software Engineering
Software EngineeringSoftware Engineering
Software Engineering
 
John Sorflaten Usability Resume
John Sorflaten Usability ResumeJohn Sorflaten Usability Resume
John Sorflaten Usability Resume
 
Vb ch 1-introduction
Vb ch 1-introductionVb ch 1-introduction
Vb ch 1-introduction
 
Activities Oriented Design Environments
Activities Oriented Design EnvironmentsActivities Oriented Design Environments
Activities Oriented Design Environments
 
A Software System Development Life Cycle Model for Improved Students Communic...
A Software System Development Life Cycle Model for Improved Students Communic...A Software System Development Life Cycle Model for Improved Students Communic...
A Software System Development Life Cycle Model for Improved Students Communic...
 
A MAPPING MODEL FOR TRANSFORMING TRADITIONAL SOFTWARE DEVELOPMENT METHODS TO ...
A MAPPING MODEL FOR TRANSFORMING TRADITIONAL SOFTWARE DEVELOPMENT METHODS TO ...A MAPPING MODEL FOR TRANSFORMING TRADITIONAL SOFTWARE DEVELOPMENT METHODS TO ...
A MAPPING MODEL FOR TRANSFORMING TRADITIONAL SOFTWARE DEVELOPMENT METHODS TO ...
 
Unit1
Unit1Unit1
Unit1
 
Hci practices-in-agile-software-development
Hci practices-in-agile-software-developmentHci practices-in-agile-software-development
Hci practices-in-agile-software-development
 
Usability For Business Analysts - 24 June 2009
Usability For Business Analysts -  24 June 2009Usability For Business Analysts -  24 June 2009
Usability For Business Analysts - 24 June 2009
 
A HEURISTIC-BASED APPROACH FOR USABILITY EVALUATION OF ACADEMIC PORTALS
A HEURISTIC-BASED APPROACH FOR USABILITY EVALUATION OF ACADEMIC PORTALSA HEURISTIC-BASED APPROACH FOR USABILITY EVALUATION OF ACADEMIC PORTALS
A HEURISTIC-BASED APPROACH FOR USABILITY EVALUATION OF ACADEMIC PORTALS
 
Epics qt application peer reviews
Epics qt application peer reviewsEpics qt application peer reviews
Epics qt application peer reviews
 
Collaborative 3D Modelling and Printing: What you See is not Directly What Yo...
Collaborative 3D Modelling and Printing: What you See is not Directly What Yo...Collaborative 3D Modelling and Printing: What you See is not Directly What Yo...
Collaborative 3D Modelling and Printing: What you See is not Directly What Yo...
 
Open Engineering Framework
Open Engineering FrameworkOpen Engineering Framework
Open Engineering Framework
 
Project Mangement Planning and Risk Analysis
Project Mangement Planning and Risk AnalysisProject Mangement Planning and Risk Analysis
Project Mangement Planning and Risk Analysis
 
Needs challenges and_opportunites_in_architectural_languages (bolzano_dec2013)
Needs challenges and_opportunites_in_architectural_languages (bolzano_dec2013)Needs challenges and_opportunites_in_architectural_languages (bolzano_dec2013)
Needs challenges and_opportunites_in_architectural_languages (bolzano_dec2013)
 
Interact2011 - Designing Inter-usable Systems
Interact2011 - Designing Inter-usable SystemsInteract2011 - Designing Inter-usable Systems
Interact2011 - Designing Inter-usable Systems
 

Viewers also liked

L. Galli - Audience, Users and People (2010) with presenter notes
L. Galli - Audience, Users and People (2010) with presenter notesL. Galli - Audience, Users and People (2010) with presenter notes
L. Galli - Audience, Users and People (2010) with presenter notesLuca Galli
 
Builders with a conscience
Builders with a conscienceBuilders with a conscience
Builders with a conscienceLuca Galli
 
J.C: Jones - Design Methods. Introduzione e note - c/di L.Galli
J.C: Jones - Design Methods. Introduzione e note - c/di L.GalliJ.C: Jones - Design Methods. Introduzione e note - c/di L.Galli
J.C: Jones - Design Methods. Introduzione e note - c/di L.GalliLuca Galli
 
J.C. Jones quotes
J.C. Jones quotesJ.C. Jones quotes
J.C. Jones quotesLuca Galli
 
20091203 Design Emergente Più Cambiamenti Più Profitti @UxConference2009 Luga...
20091203 Design Emergente Più Cambiamenti Più Profitti @UxConference2009 Luga...20091203 Design Emergente Più Cambiamenti Più Profitti @UxConference2009 Luga...
20091203 Design Emergente Più Cambiamenti Più Profitti @UxConference2009 Luga...Francesco Cirillo
 
Metodologia Galli 2008 Parte2
Metodologia Galli 2008 Parte2Metodologia Galli 2008 Parte2
Metodologia Galli 2008 Parte2Luca Galli
 
Using Interaction Design Methods for Creating AR and VR Interfaces
Using Interaction Design Methods for Creating AR and VR InterfacesUsing Interaction Design Methods for Creating AR and VR Interfaces
Using Interaction Design Methods for Creating AR and VR InterfacesMark Billinghurst
 

Viewers also liked (7)

L. Galli - Audience, Users and People (2010) with presenter notes
L. Galli - Audience, Users and People (2010) with presenter notesL. Galli - Audience, Users and People (2010) with presenter notes
L. Galli - Audience, Users and People (2010) with presenter notes
 
Builders with a conscience
Builders with a conscienceBuilders with a conscience
Builders with a conscience
 
J.C: Jones - Design Methods. Introduzione e note - c/di L.Galli
J.C: Jones - Design Methods. Introduzione e note - c/di L.GalliJ.C: Jones - Design Methods. Introduzione e note - c/di L.Galli
J.C: Jones - Design Methods. Introduzione e note - c/di L.Galli
 
J.C. Jones quotes
J.C. Jones quotesJ.C. Jones quotes
J.C. Jones quotes
 
20091203 Design Emergente Più Cambiamenti Più Profitti @UxConference2009 Luga...
20091203 Design Emergente Più Cambiamenti Più Profitti @UxConference2009 Luga...20091203 Design Emergente Più Cambiamenti Più Profitti @UxConference2009 Luga...
20091203 Design Emergente Più Cambiamenti Più Profitti @UxConference2009 Luga...
 
Metodologia Galli 2008 Parte2
Metodologia Galli 2008 Parte2Metodologia Galli 2008 Parte2
Metodologia Galli 2008 Parte2
 
Using Interaction Design Methods for Creating AR and VR Interfaces
Using Interaction Design Methods for Creating AR and VR InterfacesUsing Interaction Design Methods for Creating AR and VR Interfaces
Using Interaction Design Methods for Creating AR and VR Interfaces
 

Similar to Crafting Infrastructures. Requirements, scenarios and evaluation in the SPICE project

An Exploratory Study of Usability Practice from User-Centered Design View: M...
An Exploratory Study of Usability Practice from  User-Centered Design View: M...An Exploratory Study of Usability Practice from  User-Centered Design View: M...
An Exploratory Study of Usability Practice from User-Centered Design View: M...Ruby Kuo
 
Using Evolutionary Prototypes To Formalize Product Requirements
Using Evolutionary Prototypes To Formalize Product RequirementsUsing Evolutionary Prototypes To Formalize Product Requirements
Using Evolutionary Prototypes To Formalize Product RequirementsArnold Rudorfer
 
Research on Architecting Microservices: Trends, Focus, and Potential for Indu...
Research on Architecting Microservices: Trends, Focus, and Potential for Indu...Research on Architecting Microservices: Trends, Focus, and Potential for Indu...
Research on Architecting Microservices: Trends, Focus, and Potential for Indu...Paolo Di Francesco
 
An Enhanced Wiki For Requirements Engineering
An Enhanced Wiki For Requirements EngineeringAn Enhanced Wiki For Requirements Engineering
An Enhanced Wiki For Requirements EngineeringJim Jimenez
 
THE UNIFIED APPROACH FOR ORGANIZATIONAL NETWORK VULNERABILITY ASSESSMENT
THE UNIFIED APPROACH FOR ORGANIZATIONAL NETWORK VULNERABILITY ASSESSMENTTHE UNIFIED APPROACH FOR ORGANIZATIONAL NETWORK VULNERABILITY ASSESSMENT
THE UNIFIED APPROACH FOR ORGANIZATIONAL NETWORK VULNERABILITY ASSESSMENTijseajournal
 
Best Practices for Improving User Interface Design
Best Practices for Improving User Interface DesignBest Practices for Improving User Interface Design
Best Practices for Improving User Interface Designijseajournal
 
J.S. Daniel paper of fast tracking design in megaproject construction
J.S. Daniel paper of fast tracking design in megaproject constructionJ.S. Daniel paper of fast tracking design in megaproject construction
J.S. Daniel paper of fast tracking design in megaproject constructionJ.S. Daniel
 
The impact of usability in information technology projects
The impact of usability in information technology projectsThe impact of usability in information technology projects
The impact of usability in information technology projectsCSITiaesprime
 
IRJET- A Study on Project Management Techniques to Avoid Project Failure
IRJET- A Study on Project Management Techniques to Avoid Project FailureIRJET- A Study on Project Management Techniques to Avoid Project Failure
IRJET- A Study on Project Management Techniques to Avoid Project FailureIRJET Journal
 
Unit iii-Architecture in the lifecycle
Unit iii-Architecture in the lifecycleUnit iii-Architecture in the lifecycle
Unit iii-Architecture in the lifecycleDhivyaa C.R
 
Methodology, Metrics And Measures For Testing And...
Methodology, Metrics And Measures For Testing And...Methodology, Metrics And Measures For Testing And...
Methodology, Metrics And Measures For Testing And...Trina Jackson
 
Interaction Room - Creating Space for Developments (Software Projects)
Interaction Room - Creating Space for Developments (Software Projects)Interaction Room - Creating Space for Developments (Software Projects)
Interaction Room - Creating Space for Developments (Software Projects)adesso Turkey
 
Scr Position Paper For Chi 04 Workshop
Scr Position Paper For Chi 04 WorkshopScr Position Paper For Chi 04 Workshop
Scr Position Paper For Chi 04 WorkshopArnold Rudorfer
 
London Ambulance Services (LAS) In a state of Emergency
London Ambulance Services (LAS) In a state of EmergencyLondon Ambulance Services (LAS) In a state of Emergency
London Ambulance Services (LAS) In a state of EmergencyMonzer Osama Alchikh WARAK
 
IT PROJECT SHOWSTOPPER FRAMEWORK: THE VIEW OF PRACTITIONERS
IT PROJECT SHOWSTOPPER FRAMEWORK: THE VIEW OF PRACTITIONERSIT PROJECT SHOWSTOPPER FRAMEWORK: THE VIEW OF PRACTITIONERS
IT PROJECT SHOWSTOPPER FRAMEWORK: THE VIEW OF PRACTITIONERSijseajournal
 
A Methodology For Large-Scale E-Business Project Management
A Methodology For Large-Scale E-Business Project ManagementA Methodology For Large-Scale E-Business Project Management
A Methodology For Large-Scale E-Business Project ManagementApril Smith
 

Similar to Crafting Infrastructures. Requirements, scenarios and evaluation in the SPICE project (20)

An Exploratory Study of Usability Practice from User-Centered Design View: M...
An Exploratory Study of Usability Practice from  User-Centered Design View: M...An Exploratory Study of Usability Practice from  User-Centered Design View: M...
An Exploratory Study of Usability Practice from User-Centered Design View: M...
 
Using Evolutionary Prototypes To Formalize Product Requirements
Using Evolutionary Prototypes To Formalize Product RequirementsUsing Evolutionary Prototypes To Formalize Product Requirements
Using Evolutionary Prototypes To Formalize Product Requirements
 
Research on Architecting Microservices: Trends, Focus, and Potential for Indu...
Research on Architecting Microservices: Trends, Focus, and Potential for Indu...Research on Architecting Microservices: Trends, Focus, and Potential for Indu...
Research on Architecting Microservices: Trends, Focus, and Potential for Indu...
 
Report
ReportReport
Report
 
An Enhanced Wiki For Requirements Engineering
An Enhanced Wiki For Requirements EngineeringAn Enhanced Wiki For Requirements Engineering
An Enhanced Wiki For Requirements Engineering
 
7 13
7 137 13
7 13
 
THE UNIFIED APPROACH FOR ORGANIZATIONAL NETWORK VULNERABILITY ASSESSMENT
THE UNIFIED APPROACH FOR ORGANIZATIONAL NETWORK VULNERABILITY ASSESSMENTTHE UNIFIED APPROACH FOR ORGANIZATIONAL NETWORK VULNERABILITY ASSESSMENT
THE UNIFIED APPROACH FOR ORGANIZATIONAL NETWORK VULNERABILITY ASSESSMENT
 
Best Practices for Improving User Interface Design
Best Practices for Improving User Interface DesignBest Practices for Improving User Interface Design
Best Practices for Improving User Interface Design
 
J.S. Daniel paper of fast tracking design in megaproject construction
J.S. Daniel paper of fast tracking design in megaproject constructionJ.S. Daniel paper of fast tracking design in megaproject construction
J.S. Daniel paper of fast tracking design in megaproject construction
 
Project Scheduling
Project SchedulingProject Scheduling
Project Scheduling
 
The impact of usability in information technology projects
The impact of usability in information technology projectsThe impact of usability in information technology projects
The impact of usability in information technology projects
 
IRJET- A Study on Project Management Techniques to Avoid Project Failure
IRJET- A Study on Project Management Techniques to Avoid Project FailureIRJET- A Study on Project Management Techniques to Avoid Project Failure
IRJET- A Study on Project Management Techniques to Avoid Project Failure
 
Unit iii-Architecture in the lifecycle
Unit iii-Architecture in the lifecycleUnit iii-Architecture in the lifecycle
Unit iii-Architecture in the lifecycle
 
Methodology, Metrics And Measures For Testing And...
Methodology, Metrics And Measures For Testing And...Methodology, Metrics And Measures For Testing And...
Methodology, Metrics And Measures For Testing And...
 
Interaction Room - Creating Space for Developments (Software Projects)
Interaction Room - Creating Space for Developments (Software Projects)Interaction Room - Creating Space for Developments (Software Projects)
Interaction Room - Creating Space for Developments (Software Projects)
 
Requirements engineering
Requirements engineeringRequirements engineering
Requirements engineering
 
Scr Position Paper For Chi 04 Workshop
Scr Position Paper For Chi 04 WorkshopScr Position Paper For Chi 04 Workshop
Scr Position Paper For Chi 04 Workshop
 
London Ambulance Services (LAS) In a state of Emergency
London Ambulance Services (LAS) In a state of EmergencyLondon Ambulance Services (LAS) In a state of Emergency
London Ambulance Services (LAS) In a state of Emergency
 
IT PROJECT SHOWSTOPPER FRAMEWORK: THE VIEW OF PRACTITIONERS
IT PROJECT SHOWSTOPPER FRAMEWORK: THE VIEW OF PRACTITIONERSIT PROJECT SHOWSTOPPER FRAMEWORK: THE VIEW OF PRACTITIONERS
IT PROJECT SHOWSTOPPER FRAMEWORK: THE VIEW OF PRACTITIONERS
 
A Methodology For Large-Scale E-Business Project Management
A Methodology For Large-Scale E-Business Project ManagementA Methodology For Large-Scale E-Business Project Management
A Methodology For Large-Scale E-Business Project Management
 

More from Luca Galli

Unfreezing thoughts. Philosophy, design studies and role-playing games in a f...
Unfreezing thoughts. Philosophy, design studies and role-playing games in a f...Unfreezing thoughts. Philosophy, design studies and role-playing games in a f...
Unfreezing thoughts. Philosophy, design studies and role-playing games in a f...Luca Galli
 
Retrocomputing. Le macchine del torto. 1998
Retrocomputing. Le macchine del torto. 1998Retrocomputing. Le macchine del torto. 1998
Retrocomputing. Le macchine del torto. 1998Luca Galli
 
Navigare sul Divano 1997
Navigare sul Divano 1997Navigare sul Divano 1997
Navigare sul Divano 1997Luca Galli
 
Luca Galli 1996 Recensione di Bruno Latour, Non siamo mai stati moderni
Luca Galli 1996 Recensione di Bruno Latour, Non siamo mai stati moderniLuca Galli 1996 Recensione di Bruno Latour, Non siamo mai stati moderni
Luca Galli 1996 Recensione di Bruno Latour, Non siamo mai stati moderniLuca Galli
 
Galli Guarneri Huhtamaki - Vertigo (2009)
Galli Guarneri Huhtamaki - Vertigo (2009)Galli Guarneri Huhtamaki - Vertigo (2009)
Galli Guarneri Huhtamaki - Vertigo (2009)Luca Galli
 
Net Forum, LBi. Oltre le applicazioni, strategie a tutto tondo
Net Forum, LBi. Oltre le applicazioni, strategie a tutto tondoNet Forum, LBi. Oltre le applicazioni, strategie a tutto tondo
Net Forum, LBi. Oltre le applicazioni, strategie a tutto tondoLuca Galli
 
012011 mark up_mobile_barcode_soccol_galli
012011 mark up_mobile_barcode_soccol_galli012011 mark up_mobile_barcode_soccol_galli
012011 mark up_mobile_barcode_soccol_galliLuca Galli
 
Programma Cultura del Progetto anno accademico 2012-2013
Programma Cultura del Progetto anno accademico 2012-2013Programma Cultura del Progetto anno accademico 2012-2013
Programma Cultura del Progetto anno accademico 2012-2013Luca Galli
 
Design studies research quotes
Design studies research quotesDesign studies research quotes
Design studies research quotesLuca Galli
 
Design & Technology
Design & TechnologyDesign & Technology
Design & TechnologyLuca Galli
 
Design process & methods
Design process & methodsDesign process & methods
Design process & methodsLuca Galli
 
The Design Funnel
The Design FunnelThe Design Funnel
The Design FunnelLuca Galli
 
B.J. Fogg - Conceptual design template - edited by L.Galli
B.J. Fogg - Conceptual design template - edited by L.GalliB.J. Fogg - Conceptual design template - edited by L.Galli
B.J. Fogg - Conceptual design template - edited by L.GalliLuca Galli
 
Cross - 40 years of design research (trad. italiana)
Cross - 40 years of design research (trad. italiana)Cross - 40 years of design research (trad. italiana)
Cross - 40 years of design research (trad. italiana)Luca Galli
 
Metodologia Galli 2008 Parte1
Metodologia Galli 2008 Parte1Metodologia Galli 2008 Parte1
Metodologia Galli 2008 Parte1Luca Galli
 
Galli Design Methodology course
Galli Design Methodology courseGalli Design Methodology course
Galli Design Methodology courseLuca Galli
 
Galli Work Life Balance
Galli Work Life BalanceGalli Work Life Balance
Galli Work Life BalanceLuca Galli
 
Galli Ricerca E Sviluppo Beyond 3 G Il Progetto Mobi Life
Galli Ricerca E Sviluppo Beyond 3 G Il Progetto Mobi LifeGalli Ricerca E Sviluppo Beyond 3 G Il Progetto Mobi Life
Galli Ricerca E Sviluppo Beyond 3 G Il Progetto Mobi LifeLuca Galli
 
Galli Scenarios Methodologies
Galli Scenarios MethodologiesGalli Scenarios Methodologies
Galli Scenarios MethodologiesLuca Galli
 

More from Luca Galli (20)

Unfreezing thoughts. Philosophy, design studies and role-playing games in a f...
Unfreezing thoughts. Philosophy, design studies and role-playing games in a f...Unfreezing thoughts. Philosophy, design studies and role-playing games in a f...
Unfreezing thoughts. Philosophy, design studies and role-playing games in a f...
 
Retrocomputing. Le macchine del torto. 1998
Retrocomputing. Le macchine del torto. 1998Retrocomputing. Le macchine del torto. 1998
Retrocomputing. Le macchine del torto. 1998
 
Navigare sul Divano 1997
Navigare sul Divano 1997Navigare sul Divano 1997
Navigare sul Divano 1997
 
Luca Galli 1996 Recensione di Bruno Latour, Non siamo mai stati moderni
Luca Galli 1996 Recensione di Bruno Latour, Non siamo mai stati moderniLuca Galli 1996 Recensione di Bruno Latour, Non siamo mai stati moderni
Luca Galli 1996 Recensione di Bruno Latour, Non siamo mai stati moderni
 
Galli Guarneri Huhtamaki - Vertigo (2009)
Galli Guarneri Huhtamaki - Vertigo (2009)Galli Guarneri Huhtamaki - Vertigo (2009)
Galli Guarneri Huhtamaki - Vertigo (2009)
 
Net Forum, LBi. Oltre le applicazioni, strategie a tutto tondo
Net Forum, LBi. Oltre le applicazioni, strategie a tutto tondoNet Forum, LBi. Oltre le applicazioni, strategie a tutto tondo
Net Forum, LBi. Oltre le applicazioni, strategie a tutto tondo
 
012011 mark up_mobile_barcode_soccol_galli
012011 mark up_mobile_barcode_soccol_galli012011 mark up_mobile_barcode_soccol_galli
012011 mark up_mobile_barcode_soccol_galli
 
Programma Cultura del Progetto anno accademico 2012-2013
Programma Cultura del Progetto anno accademico 2012-2013Programma Cultura del Progetto anno accademico 2012-2013
Programma Cultura del Progetto anno accademico 2012-2013
 
Design studies research quotes
Design studies research quotesDesign studies research quotes
Design studies research quotes
 
Design & Technology
Design & TechnologyDesign & Technology
Design & Technology
 
Design process & methods
Design process & methodsDesign process & methods
Design process & methods
 
The Design Funnel
The Design FunnelThe Design Funnel
The Design Funnel
 
B.J. Fogg - Conceptual design template - edited by L.Galli
B.J. Fogg - Conceptual design template - edited by L.GalliB.J. Fogg - Conceptual design template - edited by L.Galli
B.J. Fogg - Conceptual design template - edited by L.Galli
 
Cross - 40 years of design research (trad. italiana)
Cross - 40 years of design research (trad. italiana)Cross - 40 years of design research (trad. italiana)
Cross - 40 years of design research (trad. italiana)
 
Design quotes
Design quotesDesign quotes
Design quotes
 
Metodologia Galli 2008 Parte1
Metodologia Galli 2008 Parte1Metodologia Galli 2008 Parte1
Metodologia Galli 2008 Parte1
 
Galli Design Methodology course
Galli Design Methodology courseGalli Design Methodology course
Galli Design Methodology course
 
Galli Work Life Balance
Galli Work Life BalanceGalli Work Life Balance
Galli Work Life Balance
 
Galli Ricerca E Sviluppo Beyond 3 G Il Progetto Mobi Life
Galli Ricerca E Sviluppo Beyond 3 G Il Progetto Mobi LifeGalli Ricerca E Sviluppo Beyond 3 G Il Progetto Mobi Life
Galli Ricerca E Sviluppo Beyond 3 G Il Progetto Mobi Life
 
Galli Scenarios Methodologies
Galli Scenarios MethodologiesGalli Scenarios Methodologies
Galli Scenarios Methodologies
 

Recently uploaded

"Quest for Knowledge: An Exciting Journey Through 40 Brain-Bending Questions ...
"Quest for Knowledge: An Exciting Journey Through 40 Brain-Bending Questions ..."Quest for Knowledge: An Exciting Journey Through 40 Brain-Bending Questions ...
"Quest for Knowledge: An Exciting Journey Through 40 Brain-Bending Questions ...RAGHURAMYC
 
Making A New Friend
Making A New FriendMaking A New Friend
Making A New FriendAlexaSeidner
 
إينوياشا (InuYasha) (Arabic, Censored dub)
إينوياشا (InuYasha) (Arabic, Censored dub)إينوياشا (InuYasha) (Arabic, Censored dub)
إينوياشا (InuYasha) (Arabic, Censored dub)Olesz Sarkozi
 
Inside Look: Brooke Monk's Exclusive OnlyFans Content Production
Inside Look: Brooke Monk's Exclusive OnlyFans Content ProductionInside Look: Brooke Monk's Exclusive OnlyFans Content Production
Inside Look: Brooke Monk's Exclusive OnlyFans Content Productionget joys
 
5 Moments of Everyday Self-Loathing That Perfectly Describe Your Life
5 Moments of Everyday Self-Loathing That Perfectly Describe Your Life5 Moments of Everyday Self-Loathing That Perfectly Describe Your Life
5 Moments of Everyday Self-Loathing That Perfectly Describe Your LifeSalty Vixen Stories & More
 
Holi:: "The Festival of Colors in India"
Holi:: "The Festival of Colors in India"Holi:: "The Festival of Colors in India"
Holi:: "The Festival of Colors in India"IdolsArts
 
Top 10 Best Happy Holi Wishes to Spread.pptx
Top 10 Best Happy Holi Wishes to Spread.pptxTop 10 Best Happy Holi Wishes to Spread.pptx
Top 10 Best Happy Holi Wishes to Spread.pptxNext Mashup
 
Carowinds 2024: Thrills, Spills & Surprises
Carowinds 2024: Thrills, Spills & SurprisesCarowinds 2024: Thrills, Spills & Surprises
Carowinds 2024: Thrills, Spills & Surprisescarawinds99
 
Young adult book quiz by SJU quizzers.ppt
Young adult book quiz by SJU quizzers.pptYoung adult book quiz by SJU quizzers.ppt
Young adult book quiz by SJU quizzers.pptSJU Quizzers
 
Taylor Swift quiz( with answers) by SJU quizzers
Taylor Swift quiz( with answers) by SJU quizzersTaylor Swift quiz( with answers) by SJU quizzers
Taylor Swift quiz( with answers) by SJU quizzersSJU Quizzers
 

Recently uploaded (10)

"Quest for Knowledge: An Exciting Journey Through 40 Brain-Bending Questions ...
"Quest for Knowledge: An Exciting Journey Through 40 Brain-Bending Questions ..."Quest for Knowledge: An Exciting Journey Through 40 Brain-Bending Questions ...
"Quest for Knowledge: An Exciting Journey Through 40 Brain-Bending Questions ...
 
Making A New Friend
Making A New FriendMaking A New Friend
Making A New Friend
 
إينوياشا (InuYasha) (Arabic, Censored dub)
إينوياشا (InuYasha) (Arabic, Censored dub)إينوياشا (InuYasha) (Arabic, Censored dub)
إينوياشا (InuYasha) (Arabic, Censored dub)
 
Inside Look: Brooke Monk's Exclusive OnlyFans Content Production
Inside Look: Brooke Monk's Exclusive OnlyFans Content ProductionInside Look: Brooke Monk's Exclusive OnlyFans Content Production
Inside Look: Brooke Monk's Exclusive OnlyFans Content Production
 
5 Moments of Everyday Self-Loathing That Perfectly Describe Your Life
5 Moments of Everyday Self-Loathing That Perfectly Describe Your Life5 Moments of Everyday Self-Loathing That Perfectly Describe Your Life
5 Moments of Everyday Self-Loathing That Perfectly Describe Your Life
 
Holi:: "The Festival of Colors in India"
Holi:: "The Festival of Colors in India"Holi:: "The Festival of Colors in India"
Holi:: "The Festival of Colors in India"
 
Top 10 Best Happy Holi Wishes to Spread.pptx
Top 10 Best Happy Holi Wishes to Spread.pptxTop 10 Best Happy Holi Wishes to Spread.pptx
Top 10 Best Happy Holi Wishes to Spread.pptx
 
Carowinds 2024: Thrills, Spills & Surprises
Carowinds 2024: Thrills, Spills & SurprisesCarowinds 2024: Thrills, Spills & Surprises
Carowinds 2024: Thrills, Spills & Surprises
 
Young adult book quiz by SJU quizzers.ppt
Young adult book quiz by SJU quizzers.pptYoung adult book quiz by SJU quizzers.ppt
Young adult book quiz by SJU quizzers.ppt
 
Taylor Swift quiz( with answers) by SJU quizzers
Taylor Swift quiz( with answers) by SJU quizzersTaylor Swift quiz( with answers) by SJU quizzers
Taylor Swift quiz( with answers) by SJU quizzers
 

Crafting Infrastructures. Requirements, scenarios and evaluation in the SPICE project

  • 1. > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 1 Crafting Infrastructures. Requirements, scenarios and evaluation in the SPICE project Luca Galli, Neos, Lukasz Nalaskowski, Telekomunikacja Polska, Jordi Rovira Simón, Telefonica, Tomasz Koloszczyk, Telekomunikacja Polska Abstract—The evaluation of infrastructures in large and collaborative R&D projects pose novel challenges to UCD methods. The lower level of these technologies if compared with applications meant for direct user interaction brings a level of indirectness to the activities. This paper examines some previous research on the subject and then reports about the ways in which the SPICE project faced this challenge, with special regard to the scenario and requirements design process and how focus groups-based evaluation had on impact on it. Concluding remarks on the experienced collaborative dynamics discusses the possible role of craft-inspired styles of working. Index Terms: User centered design, Research and development management, Scenarios, Requirements, Focus groups I. A INTRODUCTION PPLYING UCD-User Centered Design methods usually requires more than a disciplinary grounded, cultural and ethical commitment to user centricity. In fact, every design effort is specifically situated in a certain setting, which calls for interpretation and adaptation from the professionals involved. Design at the R&D stage is even more challenging, given the future orientation, risk-bounded, exploratory nature of the work. Doing R&D in multiple organizations, international, collaborative initiatives – as typically are European IST projects [1] – brings yet another wave of complexity. Finally, scope and nature of what has to be researched and designed are obviously of outmost importance: one thing is to specify and evaluate an application aimed at a well defined task, a very different one is dealing with technology infrastructures not meant for end-users’ direct manipulation and interaction. The latter is the case of SPICE [2], which is the reference case of this paper. The project aims at building a platform that will enable and ease service creation and execution, integrating advanced features based on complex roaming, discovery, awareness, matching and delivery mechanism. Methods and techniques such as requirements analysis and definition, or scenario building and evaluation, had to be applied taking into account these specificities. The issue as such is not relevant only for SPICE, since several R&D projects share the same characteristics. This paper will briefly review some of these previous experiences and then will illustrate how SPICE researchers dealt with the issue outlined above; the ensuing discussion will reflect on some possible broader aspects concerning UCD and design methodology in general. II. PREVIOUS RESEARCH As anticipated, SPICE tackles with user-centricity in a quite complex setting. Two major aspects are relevant here: first and foremost, the fact that the researched and developed technology is at the infrastructure level; second, the distinctive attributes of large and collaborative projects. Both of them pose important challenges to traditional UCD process and methods [3][4], that are often used and has proved to be fruitful in well defined domains, with a single organization targeting specific users for a set of tasks and activities (the occurrence of two-tier organizational structures, including design consultants and their customer, does not appear overtly different). A. UCD “extra-large” Generalising from the MobiLife project experience on the adaptation of UCD in the context of large and distributed projects, [5] proposes an “extra-large” specific UCD style to cope with the critical mass, abstraction and compartmentalization of these collaborative efforts; special attention to the difficulties of researching technology social acceptance is also given. A number of practical recommendations have been formulated there: they include the opportunity to conduct early test of the functional parts of what it is still under development (“Break out of the big loop”); concretization of abstract ideas (even though this is “not always feasible with enabling technologies”, as discussed below); maintenance of an empiric orientation (scenarios are useful for developers but might be unrealistic for people out there); prioritization; frequent interaction among developers and user researchers, making user research a collaborative activity and UCD an “integrating perspective” located at an
  • 2. > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < higher level or external point of view, somewhat independent of specific technology agendas. Besides these managerial and organizational issues, there are other critical aspects more related to the research subject, especially with regard to enabling technologies. In fact, [5] highlights as well some inherent difficulties of bringing software components or “enablers” to the field for direct experimentation with end-users. B. UCD challenges in evaluating infrastructures As noted by [6], the issue of evaluating lower level components or technology enablers is an important and still not really explored terrain. In general, little research is available on the evaluation of software infrastructure according to user-centred methodologies: once applications with some clear intended scope and user access are not at the centre stage, criteria for designing and evaluating the features of the infrastructure itself are less certain. User-visible applications have long traditions of user-centred design and evaluation, if compared with infrastructures. In the latter case, issues regarding the development of fully working prototypes with acceptable usability or small scale prototypes are to be considered carefully, because they could not generate expected results. The same goes for the usage of fake features or simulations for components that will have some interaction in the future with the infrastructure, but are not strictly related to that. Developing applications with the desirable quality level might be not possible at all or only at the risk of big delays and wasted resources. By going trough the evaluation of several applications enabled by an underlying infrastructure, and reflecting on some major pitfalls, [6] comes to the point of consolidating several “lessons learned”. Interestingly, some of them are pretty much in line with those put forward by [5]. Prioritize core infrastructure features is then lesson number one. As before, the aim is to test practically “core design ideas” and build additional features once evaluation results are available. To really achieve this, researchers might have to play with a “minimalist” infrastructure, or, in other words, prototypes with very limited scope but that can effectively convey some of the core ideas. All other work, namely what does not leverage directly on the infrastructure, should be deferred. Have e.g. a prototype that it is robust and secure enough for use in real conditions is often a sensible objective, but since the application layer as such is not the focus, the effort needed to get there might be wasted. Yet test application “must also satisfy the criteria of usability and usefulness”, a criteria that the authors recognize as “difficult to satisfy”, even though the challenge is somewhat lessened by the recommendation that initial proof-of-concept applications should be lightweight. 2 III. SCENARIOS & REQUIREMENTS A. Overview of the SPICE project The SPICE project addresses the problem of designing, developing and putting into operation efficient and innovative mobile service creation and execution platforms for networks beyond 3G [7]. With the growing diversity of services, devices and connectivity means, service platforms such as the SPICE platform intend to provide end-users with communication means and tailored applications anywhere, anytime and on any device. This goal is sought by supplying service providers with service enablers that ease and quicken (context-aware) application development. End-users are not only considered as consumers of those applications, since they can be service creators at the same time. In this view, operators will take the role of service platform provider and, if such it is the case, service provider. The strategic role played by the platform in this vision explains why the project strives to combine a socalled “platform-centric” approach with an end-user orientation [7]. B. Design process As many other R&D endeavors, SPICE started with a technology vision articulated in a number of specific objectives and embodied by a set of short scenarios, expressed by brief textual narratives. This happened already at the research proposal phase; user-centricity was not greatly emphasized there, but the workplan included explicitly users, i.e. external people not involved with the project, for two iterative evaluation activities, the first at the beginning and the second at the end of the project. Focus groups are mentioned as the method of choice. The proper design process began with a very detailed requirements specification activity, in partial overlap with the actual scenarios definition and in reciprocal influence with other research activities, namely architecture work, initial analysis of business models and legal issues. Fig. 1: interactions between requirements, scenarios, architecture, business models and legal issues.
  • 3. > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < The requirements work produced an output of 48 use cases, considering four types of requirements: user requirements, enterprise requirements, technical requirements and open market requirements. The ensuing work on scenarios took into account the updated architectural view, the related functions, and once again the parallel work on business and legal aspects to consolidate the first complete version of the project scenarios. These scenarios provided the basis for the first evaluation round with end-users and professional users, conducted through a number of focus groups, reported below. The user feedback generated in the focus groups, as well as the parallel work in business models and the technical progress of the workpackages, has then been fed into a scenario revision, reported below too with more details. Starting again from this revision, currently yet another iteration is ongoing, aiming at consolidate the different scenarios into a unique and streamlined storyline, as well as a more compact set of requirements, prioritized against the most distinctive objectives and outcomes of the project. C. Scenarios The scenario work in SPICE is focused on the development and refinement of a series of demonstration textual and visual narratives that illustrate the main features and the potential impacts of the service platform on European citizens, as well as on service providers and telecommunication operators. Given the necessity to communicate both with end-users and professionals (included semi-professionals and talented amateurs), a wide spectrum of diversified situations is represented in these scenarios, ranging from context-aware personal navigation for tourist groups to natural language, semantically-enabled searches in components repositories accessed by technical developers. As said above, scenarios have been shaped early in the project lifecycle, and have been initially consolidated in a set of four stories, named respectively I-Portal, e-Tourism, eEmergency and Service Creation [8]. The first two, I-Portal and e-Tourism depict different groups of end-users, mostly families, in various service settings. The SPICE platform as such does not appear in the foreground; the specific experiences made possible by the platform are described instead, mentioning SPICE as the enabling technology. 3 The last scenario, Service Creation, has an explicit orientation to business and technical users: it describes all the service lifecycle from the ideation phase down to each development step (shortly: design, implementation, deployment, management and termination) and makes explicit all the related interactions between various parties (e.g. a sponsoring company, a developer partner, an operator). The e-Emergency scenario includes both aspects, with some scenes closer to the end-user point of view and other scenes dedicated to the involved organizations and their usage of the technology. Fig. 3: scenes visuals from the Service Creation and e-Emergency scenarios, describing prototyping processes, service announcement and personalized alerts. D. The indirectness issue Despite some differences in the emphasis and point of view, a common aspect across the four scenarios is that many scenes - if not all - are about an infrastructure that is not directly accessible by end-users: in fact, they will use services enabled by this platform. Even the case of professional users, which will have indeed access to the platform functionalities, is not entirely straightforward, as the disciplinary and technical backgrounds of the professionals will likely be varied: business and creative people will have to cooperate with engineers; for them, the processes enabled by the platform will be of outmost importance, more than its direct manipulation. The platform influence embraces also some key aspects of the terminal capabilities, but also in that case the relevant software layers might lie behind the users’ level. Indeed, they enable several application features that are in the users reach, from the capability to find a service suitable in a given context to the possibility to use it while roaming abroad, but are not directly visible per se. The most notable exception in the project is perhaps the Dynamic Desktop, which provides an interface to let the user interact with the platform, but actually this is part of a broader work about technological issues and features that again are well behind users’ visibility [9]. IV. EVALUATION AND REWORK Fig. 2: scenes visuals from the I-Portal and e-Tourism scenarios, describing usage of local navigation services and context-aware push mechanisms. It is now obvious that the UCD challenge of evaluating technology infrastructures has been met and is being faced in SPICE. Furthermore, SPICE is experiencing the same “extra-large” characteristics described above, similarly to many other cooperative projects. As anticipated, the project workplan included focus groups
  • 4. > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < as the evaluation method of choice, especially for the initial project phase. The results of this evaluation and their impact in the design process will be discussed in the following paragraphs. A. Focus groups The evaluation has taken place in three countries: Poland, Spain and Italy. It has involved both individuals with an enduser profile (8 focus groups) and professionals (2 mini focus groups). End-user oriented meetings have been mostly dedicated to the discussion of SPICE-enabled services from a consumer / citizen point of view, trying to elicit respondents’ opinion about potential benefits and disadvantages of what was shown in the stories. Professionals-oriented meetings were concentrated instead on the process of creating, delivering and managing these services, with special attention to design, development and prototyping issues; potential benefits and disadvantages were examined in this case too. Among various preparatory tasks, it is important to remember here that scenarios had to be adapted for the focus group discussion settings. The number of scenes had been reduced, as well as the narrative text, giving more emphasis to the pictures and the SPICE feature main ideas. This way, the translation effort of conveying the SPICE main features through the scenario description has gone one step further as the communication needs for which the scenarios had been conceived moved from the experts to the general public. Once the focus groups had been held, the analysis of the related reports has gone through the following steps: first, complete country reports have been produced, highlighting the key benefits on one side and major disadvantages and dislikes from the other side, for each scenario; second, common results and variations have been spotted, with special attention to the impact of country perspectives. Finally, a set of actionable recommendations has been elaborated, as a tool for the upcoming scenario revision [10] [11]. Starting with the general results, some clear directions are evident. Regarding the key benefits, across all countries and profiles there was strong appreciation of everything related to “convenience”, such as service international roaming, session transfer, possibility to swap devices while using the same service and personalize public devices, personalization in general, access to protected content and content adaptation to various terminals. Professionals appreciated very much the possibility of having a support for faster and more effective prototyping and service creation capabilities (but gave a warning about the organizational challenges of prototyping processes). Proactive context-aware recommendations sparked instead lively discussions, usually prone to stark criticism. Most of the cited disadvantages and dislikes were mentioned in relation to that, especially regarding possible misuse from companies, marketers and public organizations as well. People feared that the tracking and profiles features 4 that enable these recommendations would trap them into a too powerful system. Moreover, the usefulness of such recommendations was questioned. Still, through the debates, a number of potentially promising usage settings were spotted and anticipated -- some alternative to the ones presented. Notably, people seemed remarkably positive about personal navigation features and the application of SPICE technologies in working environments especially in comparison with leisure traveling and other spare time situations. Not surprisingly, the indirectness effect discussed above did have an impact on the focus groups’ participants understanding of the depicted features. Quite often end-users seemed puzzled by the nature of SPICE itself, given its apparent influence on so many realms (devices, services at home and abroad, general tasks and very special events like an emergency). Professionals too debated a lot about the possible scope of the platform and its applicability to their own environments; those with a non-technical background were ready to pinpoint organizational and cultural challenges related to the presented ideas. Yet such indirectness did not hinder the discussion substance, articulation and richness. As seen, focus groups actually generated much valuable feedback about what was perceived as desirable or less so at the scenario scenes level. Notable distinctions and subtleties emerged as well, mainly dependent on the country and age group of the focus group participants. As outlined above, the user feedback has then been translated into a set of recommendations for scenario improvement. Some of them were quite high level (such as “the general direction for further scenario development is to build them around an active SPICE user that searches and chooses then receives and accepts”), while most of the others sounded more as practical hints, as the ones below (they are related to different scenarios): • Decrease to a few scenes the explicit reference to proactive mechanism altogether • Link clearly the delivery of proactive suggestions to some user action or previous declaration • Explain more about the Semantic Language • Clarify what the emergency service is • […] Taken as a whole, such recommendations have provided a body of suggestions that clearly called for a scenario revision, actually already envisaged in the original workplan. B. Enhanced scenarios The user feedback coming from the focus groups was not the only source to be taken into account. Parallel work in business modelling and updated mock-ups features required too some scenario updates. As a consequence, the project had to complete an extremely detailed mapping of old scenes, user feedback, modified requirements and new scenes [12].
  • 5. > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < First of all, this started by identifying so-called “scene requirements”, i.e. requirements regarding the scenes to be modified according to the mentioned input sources. Second, a controlled three-stage, step-by-step procedure had to be defined: 1) Mapping the users’ concerns/comments on each of the scenario slides adapted for the focus group discussions. 2) Identifying the correspondence between the focus groups’ scenes and the initial ones in order to put the right “scenes requirements” into the original scenes. 3) Taking the original scenarios and applying on them the scenes requirements. Moreover, special care had to be used in applying such scenes requirements. Given the different sources, the enhancement process has followed a sequential approach, beginning with the users’ enhancement and ending with the business one; each of these steps has included an enhancement and revision iteration. Fig. 4: Excerpt from the mapping work; focus groups users’ inputs are codified into detailed “scenes requirements” that are then mapped to the original scenarios. 5 been given: …The family is notified because they all selected this option in their service preferences. As they do not know much about Valencia, they value any information they can get. Moreover, they trust the SPICE platform because it is internationally well known for using fair recommendations based on users’ preferences and ratings. With regard to the service provider side, professionals that attended the focus groups made a lot of questions about the prototyping process and capabilities of the SPICE platform. Hence, e.g. the scene depicting what is happening when a developer wish to build a mock-up has been better précised: …The service description is used as input to a Mock-up builder (Mock-up generator). The Mock-up builder is a graphical tool which enables Paul and his team to put components together by drag and drop. In a couple of hours the mock-up is done. The mock-up is non-functional, but it can be displayed on any standard mobile terminal as well as on PC or TV-based interfaces. As said above, this set of refined scenarios is currently used as a basis for yet another major iteration aimed at consolidate them into a unique and all encompassing story, in which both the parallel updated needs of the technical developments and the users’ evaluation are combined, providing a global framework for the project final demos and prototypes (to be used again in the concluding evaluation phase). V. METHODOLOGICAL DISCUSSION The mapping exercise and scenes requirements formulation has resulted in improved narratives, with focused hints and pinpoints at the identified user concerns. To achieve that, some scenes had to be removed altogether, other split in different parts, others just modified. If we consider e.g. the issue of personal identity and context information matching (a frequent occurrence in the IPortal and e-Tourism scenarios), explicit reassurances have been added to address the users’ concerns emerged in the focus groups: …it is impossible that the service makes use of users’ sensitive information in a malicious way since the local SPICE Operator guarantees that user’s personal data (e.g. name, address, mail, telephone…) are never matched with his context information (e.g. position, mood, availability). Before the service can use sensitive information, the user’s consent must always be given. Push mechanisms raised a lot of discussions in the focus groups (with special regard to the e-Tourism scenario); stronger rationale and clearer behaviours explanation have so Scenarios, requirements and focus groups are definitively no new tools for the designers, especially for those attentive to user centricity. Yet they are not simple ones; if we consider e.g. scenarios, they have a quite complex and long history, spread among different disciplines and environments, from software engineering to business strategy and futures studies; much attention has been spent already on how to use them in designing forthcoming technologies [13] [14]; the same holds true for requirements and focus groups, with different specificities. Hence, SPICE could hopefully be useful to reflect on the ways in which these methods or research tools have been used; furthermore, we realized that researchers’ attitudes and group dynamics were not less important than the methods per se – quite understandably, given the situated nature of design processes evocated at the beginning of this paper. To start with, scenarios usefulness came out reinforced from this experience, despite their limitations (concerning e.g. the fact that they are so often technology biased and prone to generate skepticism). In fact, given the difficulties identified in previous research with regard to the development of applications meant to demonstrate underlying
  • 6. > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < infrastructure capabilities, scenarios proved to be a flexible and cost-effective way to represent that capabilities; scenariobased evaluations are indeed less substantial than prototype based ones – and for sure they can not just substitute them – but allow at least to get timely feedback from the users and push it back into the project. In order to do that, several iterations might be needed: scenes descriptions and sequences will have to be changed repeatedly, carving texts and visuals until they express a good balance of the various interests and viewpoints. It is much more than polishing: scenarios seem to work better as a dynamic tool, in which rework has to be taken for granted. A similar approach has to be used to manage a consistent and precise matching of scenarios and requirements; technical and users requirements typically change over time according to the technical progress or evaluations. A successful reciprocal update is not less important than an original complete formulation – which too often risks becoming obsolete. There are some aspects related to how the activities have been performed, or, in other words, regarding individual and group dynamics. Considering the entire scenario and requirements design and evaluation, it is evident that the process as a whole has been indeed a painstakingly collaborative effort. More than a clearly pre-determined and smooth cycle, the all thing resembled pretty much a craft exercise, as it recalls the slow, cumulative, collective, patient and prone to details work stile of craft. With a reduced interest in focusing on just one or two well-limited application domains, this sort of lower level type of work might actually pay off in shaping the infrastructure features against user inputs. The metaphor of craft might appear a bit distant, but perhaps less so looking back at the very early stages of userorientation in design and architecture, way before than by “bringing design to software” [15] UCD started to gain its stance in the IT field. Shaping the designer profile in the face of novel challenges raised by then emerging interaction between humans and machines, complex systems and multidisciplinarity, John Chris Jones seminal reflections on methodology called for a partial return of craft skills in contemporary design practice [16] [17]. From a professional and educational standpoint, some of the best qualities of the ancient craft work might turn out to be still valid – above all, a humble and patient attitude to listen people needs and desires, as well the distinctive capability of the craftsman in shaping his own tools. In this respect, the lesson learned from SPICE is not one of a method, or a set of specific actions, like an immediately actionable answer, but more one of an approach or a way to apply well-known design strategies and methods, forcing their adaptation to the ever more important issue of anticipating the future consequences of pervasive and extended technology infrastructures. 6 ACKNOWLEDGMENT This work has been performed in the framework of the European project IST-2005-027617 SPICE, which is partly funded by the European Union. The authors would like to acknowledge the contributions of their colleagues from France Telecom R&D, Alcatel CIT, DoCoMo Communication Laboratories Europe GmbH, Telecom Italia, Telenor ASA, Siemens, Siemens AG Osterreich, Ericsson Telecommunicative BV, Nokia Corporation, Stichting Telematica Instituut, NEC Europe Ltd, Bull, Fraunhofer Gesellschatf zur Forderung der angewandten Forschung, University of Kassel, Alma Consulting Group, Vrije University Brussel, IRIS, Neos, The University of Surrey, Norwegian University of Science and Technology, Politechnico di Torino, Telekomunikacja Polska SA, Telefonica. REFERENCES [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] IST program web site: http://cordis.europa.eu/ist SPICE project web site: http://www.ist-spice.org D. Norman and S.W. Draper (Eds.), User Centered System Design. New Perspectives on Human-Computer Interaction, London, Lawrence Erlbaum Associates, 1986 J.D. Gould, C. Lewis, Designing for Usability: Key Principles and What Designers Think, Communications of the ACM, vol. 28, No 3, 1995 E. Kurvinen, A. Aftelak, A.Hayrynen, User-Centered Design in the Context of Large and Distributed Projects, CHI 2006 W.K. Edwards, V. Bellotti, A.K. Dey, M.W. Newman, Stuck in the Middle: the Challenges of User-Centered Design and Evaluation for Infrastructure, CHI 2003 C. Cordier, F. Carrez, H. Van Kranenburg, C. Licciardi, J. Van der Meer, J. Zoric, A. Spedalieri and J-P. Le Rouzic, Advanced Beyond 3G service delivery environment: the SPICE service platform design principles, WWRF16, 2006 SPICE project deliverable D1.2 “Scenarios for the representative next generation information and communication services”, edited by V. Boutroux, 2006 M. Brosssard, SPICE. Best-Configured Communication Environment, Helsinki WWI Symposium, 2006 SPICE project deliverable D8.1 “Pioneering SPICE project, a view by focus groups from the fields of I-Portal, e-Tourism and e-Emergency Services”, edited by L. Galli, 2006 Ł. Nalaskowski, L. Galli, J. Rovira Simon, Pioneering SPICE Project. A View by Focus Groups from the Fields of I-Portal and e-Tourism, WWRF18, 2007 SPICE project deliverable D8.2 “An in-depth view on SPICE project, using Intelligent Portal, e-Tourism and e-Emergency scenarios”, edited by J. Rovira Simon, 2007 K. Go, J.M. Carroll, The Blind Men and the Elephant: Views of ScenarioBased System Design, Interactions, 2004 L. Galli, Scenario methodologies, MobiLife Oulu Summer School, 2004, available at http://www.ist-mobilife.org T. Winograd (Ed.), Bringing design to software, ACM Press, Ney York, 1996 J.C. Jones, Design Methods, Wiley, London 1970. Third edition: Wiley, 1992. J.C. Jones, Essays in Design, Chichester, Wiley, 1984.