Content uploaded by Adam Widera
Author content
All content in this area was uploaded by Adam Widera on Jan 03, 2018
Content may be subject to copyright.
Bringing Technology and Humanitarian Values
Together: A Framework to Design and Assess
Humanitarian Information Systems
Gino S. Coletti P.
Dept. of Information Systems
University of Münster
Münster, Germany
g_cole01@uni-muenster.de
Robin E. Mays
Dept. of Human-Centered Design &
Engineering
University of Washington
Seattle, USA
rmays@uw.edu
Adam Widera
Dept. of Information Systems
University of Münster
Münster, Germany
adam.widera@wi.uni-muenster.de
Abstract— Designing information systems (IS) in support of
humanitarian work has been a challenge widely pursued for
decades. How ever, one aspect that has been undervalued within
systems design is the role of the underpinning humanitarian
values and culture as part of system effectiveness. Further, it
remains understudied how we might incorporate those values
into the information system design process. We address both
these aspects by 1) analyzing humanitarian values of effectiveness
as they impact information systems design, and 2) incorporating
humanitarian values as part of the design criteria. In this paper,
we present the idea that the “maturity” of an IS design to be
effective for the humanitarian context is assessed by how well it
incorporates humanitarian values. Therefore, we move away
from a product-centered design towards an approach, which
features the socio-technical relationship. We present a maturity
matrix, which aims to translate and communicate humanitarian
effectiveness into the design and development terminology used
by technology designers. This matrix is housed within a
participatory framework that allows for the development of trust
and shared understanding between these two domains. The
framework serves as a road-map for designers and humanitarian
agencies to adapt the IS design and development process to better
accommodate the IS needs of the humanitarian mission, its
values, and culture.
Keywords—humanitarian technology, human-centered design,
sociomaterality, ICT4D, IS design, humanitarian values, hidden
work, effective design, complex systems design.
I.
I
NTRODUCTION
Humanitarian organizations are in the need of Information
Systems (IS) that allow them to do their work in a more
efficient and effective way. These terms, however, have
contrasting and sometimes conflicting meanings in the field of
humanitarian operations than within the traditional engineering
and business domains in which the art of designing of IS has
been established. These unresolved interpretations of effective
work stand as one possible cause for repeated failing of
information systems implementations, and lack of expected
progress toward sustainable IS designs within the humanitarian
domain.
The challenge of connecting domains with different value-
systems for the purpose of designing effective IS first requires
an awareness of philosophical assumptions we have in design
and development of technology and what we perceive as
effective work.
Designing IS that better meets the needs of humanitarian
agencies (HA) requires an evidence-based understanding of the
successful work within its domain. Therefore, we use the
success factors (SF) and success driven behaviors (SDB)
identified in the grounded, ethnographic work of Mays,
Walton, Lemos and Haselkorn on the information needs of
successful practitioners as our model [1]. These behaviors and
the information needs they support are facilitative over
directive, highly relational, dynamic, and participatory. This
model presents a different sort of challenge to IS design: that of
considering how humanitarian values change the traditional
assumptions and methods of IS design and development.
Design and development of technology has excelled at the
creation of IS for organizations with well-defined and
predictable decision-making structures. This paper represents a
call, however, to go further into socio-technical domains and
the development of new methods that can be more
accommodating of the less fixed decision-making of
distributed organizations. This paper reveals technical themes
that emerged when considering the more socially-driven values
of humanitarian work, providing a starting point to build upon.
It proposes a framework for enabling the design of IS that fit
the needs of humanitarian organizations and communities
involved in the work. The proposed solution is an effort to
translate factors that make humanitarian work by practitioners
in the field successful for IS designers and connect it to aspects
of IS design that can potentially support these factors, when
being incorporated into the design process.
It sets a precedent in this unexplored area, with our effort to
bridge a communication gap identified between designers and
humanitarian organizations. The findings contribute an initial
road map for designers and humanitarian agencies to better
adapt the IS design and development process for
accommodating the IS needs of the humanitarian values and
culture.
II. R
ELATED
W
ORK
A. IS Design Foundations into Socio-technical Advances
Ubiquitous to current day software design and development
is an entrapment in the paradigms of the time. IS design was
primarily born out of military initiatives [2], grew into
adulthood under the computerization of government and for-
profit corporate communication systems, and decades of
iteration rooted in these types of work systems [3]. Therefore,
IS design and development methods are aligned with certain
assumptions of how organizations conduct work congruent
these work-systems (e.g., closed systems, top-down decision
making, control as a form of optimization, and product/service
delivery oriented goals).
Examples of these traditional methodologies include:
structured programming techniques used in the last 40 years [4,
5, 6] which have been replaced by object-oriented approaches
[4, 7]. In the former example, the system is conceptualized as a
flow of functions and processes with inputs and outputs,
whereas the second one depicts a system as objects, methods,
and inheritances [4]. As well, the requirements document – the
ever-persistent starting point of all IS design – reflects this
history. IS design has been summarized as “some variant of the
following phases of: requirements determination, design,
construction, implementation and operation.” [2, p.43].
Increasingly, context-aware socio-technical system
communities, such as Computer-Supported Collaborative
Work (CSCW), have exposed the risks of adopting such
methods for highly complex contexts. Beginning in 1993,
Orlikowski was already talking about the importance of
recognizing cognitive, organizational, and structural elements
as part of the design process of new technologies as well as
their implementation in organizations [8]. Her focus lied in
acknowledging the importance of the role and relationship
between technology and human interaction, and understanding
how it influenced the way people reflect and assess the value of
technology [9]. Feenberg in his Critical Theory of Technology,
observes society and technology “communicate constantly
through the realization of values in design and the impact of
design on values” [10, p.68]. Moreover, he criticizes the
existing bias present through the interpretation of a social
requirement into a technical specification, defined as technical
codes, but carrying the values of the dominant technical actors
[10].
Today, human-centered design (HCD) approaches are
addressing the reality that technical solutions are part of a
larger social system that requires holistic analysis [11]. Socio-
material methods such as seamless cognitive systems
engineering and contextual design are advancing – and
challenging – technology design and development to innovate a
long history of tradition in this area.
B. The Need for New Approaches
Although the technical research is limited in its sharing of
stories of failed technology, there are ubiquitous testimonies of
humanitarian technology initiatives that fail to achieve their
desired purpose; to adapt to the needs of the humanitarian
community; or to be adopted or achieve adequate scale [12, 13,
14]. The UNHCR Innovation unit has concluded such
phenomena with: “In many cases, well-intended developers
find themselves confronted with the realities of operating in an
unfamiliar and challenging context.” [13]. Thus, as Baxter and
Sommerville observe, while systems might “work” from a
technical perspective, they still do not succeed in delivering the
needed support to the core work of the organization. [15]. In
particular, there are three underlying barriers in design and
development that Baxter and Sommerville have named in their
problem classification for lack of accepting socio-technical
methodologies in software engineering, that we also found
highly relevant in our research. Those are: inconsistent
terminology, conflicting value systems, and lack of agreed
success criteria [15].
1) Terminology
There is a terminology gap which occurs when
humanitarian organizations and technology designers come to
work together towards the development of IS. The process can
easily fail due to the lack of shared meaning among the parties
even when using similar language. Technical communication’s
historic focus in “for-profit” and “top-down” business-related
environments, has fostered a lack of robust research in broader
sectors such as non-profit work and therefore, its different
characteristics and terminology [14, 16]. Because humanitarian
operations is a hidden form of work, without specific exposure,
it is common for outsiders to overlook assumptions in the
terminology made about the work [17].
Inconsistent meanings in the use of terminology present the
problem of translation and thus, a need for development of a
shared-understanding. One importance of socio-technical
approaches with the intent for understanding work practices via
HCD methods aim at offering representations and details of
how technology influences the work in relationship to the
humans making use of it [9, 18]. The representations of work
created from HCD approaches
1
can then serve as a starting
point for designers and involved stakeholders to begin a
conversation for developing common meaning.
2) Value Systems
Moving forward towards what comprises one of the main
problems for adopting technologies that affect humanitarian
organizations, is a difference between humanitarian values and
the historical aspiration of technology development. Changes
in technology have been rooted in the growth of economy, with
the engine of change ignited by the motivation to keep on
making profits [3]. Nonetheless, even though not all
individuals might be driven by market incentives, the larger
part of technological change comes behind the “intentional
actions taken by people who respond to market incentives” [3,
p.72]. Thus, technology, itself, is “value-laden, invested with
and aiming at values in both genesis and execution” with the
value equations of an economic work system [19, p.41].
Whereas, humanitarian work is driven by the motivation to
assist individuals who are in need [14].
The legal framework under which these two types domains
are constituted reflects their culture and sets boundaries and
freedoms on the way they behave and operate [14]. This is
1
Such as ethnographic work, action research and participatory design
reflected and derived into how the work is constituted. On one
side, for-profit organizations are required to maximize profits.
Quantifying success has a long and broad tradition in the
economics [20] and manifold measures are derived via e.g.
productivity efficiencies and optimization of costs, where the
design works towards profit targets. Qualitative measures are
also incorporated, yet the priority will remain under achieving
a positive quantitative bottom-line. This is what we call in our
study an “optimization” for control and sustainable markets.
On the other side, non-profit organizations are legally obliged
to uphold and be respectful of their missions. This translates
into being successful under moral codes. For example, the
Code of Conduct of the Red Cross and Red Crescent Societies
include the humanitarian imperative
2
to provide humanitarian
assistance above all else, and the humanitarian principles of
humanity, neutrality, impartiality and independence [21, 22,
23].
3) Agreed Success Criteria
There is a lack of agreed upon specific operational success
criteria for humanitarian success. With differing missions and
legal obligation to their missions, the definition of success in
the daily operations differs from agency to agency, and from
unit to unit. The goal of meeting needs is highly contextual.
Widera and Hellingrath [24] note that the manifold existing
performance measurement approaches in the area of logistics
are hardly applied by humanitarians. They illustrate the reason
for this is that most available approaches neglect to discover
and design measures appropriate for the practitioner realities.
Therefore, this research builds on the grounded study of
Mays, Walton, Lemos, and Haselkorn which identifies the
work model and information needs of successful humanitarian
practitioners [1]. Thus, this definition of success is based on the
work practices or behaviors which are developed in the field
when interacting and collaborating with communities in need.
III. M
ETHODOLOGY
A team of seven IS students and four supervisors took on a
nine-month project that consisted of an extensive initial
discovery phase. Discovery included domain learning via
literature, interactive workshops, and interviews with
humanitarian practice and HCD experts. This was followed by
a four-month iterative design process with a humanitarian
practitioner for developing a solution for humanitarian
agencies to help guide technology designers in their
humanitarian technology needs, and hold them accountable to
those needs [24]
A. Discovery
Students first individually reflected on current personal
views in order to recognize their own assumption around
humanitarian effectiveness and IS design. This was followed
by analysis and reflection of relevant literature for the
2
“that action should be taken to prevent or alleviate human suffering arising
out of disaster or conflict, and that nothing should override this principle.” [22,
p.20]
humanitarian context. Next, the team familiarized themselves
with the success driven behaviors of humanitarian practices
identified in Mays, et al. [1]. The student team then conducted
one-hour, inquiry interviews with six experts within
humanitarian practice and five IS design experts to gain deeper
insight into the challenges and realities of the humanitarian
domain. This also included a combined review of 34 actual
interviews conducted with successful practitioners in Mays’
original study.
B. Iterative Coding, Analysis, and Design
From the discovery phase, a holistic, participatory and
iterative analysis of the data was conducted. Iterative scoping
and analysis of the problem space and problem definition was
conducted over 16 weeks which included iterative validation
from an experienced humanitarian practitioner. The team
would consult previous interviews and conduct additional
interviews when areas emerged that needed greater
clarification. After a validated identification of the problem
space, and analysis of the key needs, barriers, and gaps the
team proceeded to explore appropriate solutions.
The next phase of research followed two conceptual
streams a) development of a communication process for shared
learning and creation between stakeholders, and b)
development of a translation tool between the two domains.
1) Conceptualization of a Framework:
The first stream of analysis conceptualized a solution to bring
communication, co-learning, trust and co-creation between
humanitarian and IT professionals. This followed the same
HCD principles of holistic analysis and stakeholder
participation in design decision-making using iterative
representations [11, 15]. Beginning with brainstorming, the
solution ideation was narrowed and iterated within
participatory design sessions that incorporated a validation by a
humanitarian practitioner as part of the iterative decision-
making. The resulting framework concept is discussed in the
findings section below.
2) Conceptualization of a Translation Tool:
In the second stream, the team pursued creation of an artifact to
help translate humanitarian values into IS design. Based on
existing expertise in IS and the team’s new thorough
understanding of the information needs of humanitarian
practice and its domain, a comprehensive analysis of the
impact of design approaches on each of the thirty SDBs was
conducted. These SDBs were systematically analyzed for both
the IS development and design needs as well as IS design and
development conflicts through qualitative open coding on an
online platform. There were at least two coders for each SDB.
From this large-scale matrix a second level of open-coding
was conducted. Team members divided the SDBs, providing
at least two open-coders per SDB and systematically analyzed
the SDB matrix for the repeating technical themes that
emerged. Affinity diagramming of the individual codes in a
joint session created joint themes. These technical themes
make up the Y axis of the final matrix and described in the
findings below.
IV. F
INDINGS
A. Humanitarian-IS Designer Communication Gap
Our analysis identified a critical gap in shared meaning and
understanding of terminology, values, and successful work
between humanitarian and information systems domains. The
gap of understanding comes from both sides: the designer
lacking humanitarian values and work operations expertise, and
HAs lacking IS/technological development expertise.
Fig. 1. A tool to bridge the communication gap
We further identified that the most important role of our
solution would be to bridge the communication gap and work
towards a shared understanding between humanitarian
organizations and designers (regardless of their background).
Our findings are that the two domains lack the necessary
awareness and expertise of the different languages and values
of the other, and thus how these moderate the way they each do
their work. There exists a critical need to translate meaning
across entities in order to move toward successful design in the
humanitarian context (fig. 1). Therefore, we envisioned i) a
space or framework for negotiating meaning among the
different parties involved and ii) a translation tool to bridge the
terminology and domain gaps. The devised solution of a
Guidance and Assessment Tool at its base is a negotiation
framework that allows for meaning translation across entities
involved in a design process in order to align the potential IS to
the humanitarian SDBs
B. Guidance and Assessment Tool
The Guidance and Assessment Tool (GAT) is envisioned as
solution to support the translation of humanitarian effectiveness
for IS designers, who intend to develop an intervention into a
complex system by designing IS for the humanitarian space.
We sought to communicate appropriately to designers what is
most important for humanitarian technology design by
incorporating humanitarian values into the language of design
and development. This also provides a starting point for
humanitarians to develop an understanding of how the
technology design domain operates and its particular values.
The GAT consists of two components: (1) A Maturity
Matrix for Humanitarian Technology Design and (2) A
Guidance Framework for Humanitarian Technology Design
and which houses the use of the Maturity Matrix.
1) Maturity Matrix for Humanitarian IS Design
The matrix serves as facilitative as well as stand-alone
artifact acting as a tool for translation and/or assessment of IS
regarding its alignment with humanitarian effectiveness. Along
the Y axis we share the critical technical themes that emerged
in our analysis (explained in the following section). Across the
X axis is listed a spectrum of compatibility for HA needs for IS
design and development approaches. We classified this as
maturity levels, where the first column begins with the current
beginning state of each technical theme as: first column = not
aligned with SDBs, progressing onward to increasing
alignment, with the 4
th
representing a more optimal alignment
(fig. 2). We discovered there was a progression of maturity that
aligned with methods. The lower spectrum reflected an
alignment with more traditional, strict, technical-driven design
method. Higher on the spectrum, design principles aligned
better with synergistic approaches which combine the
technological and sociological elements of a complex context.
The 4
th
and final level, is futuristic in practice –taking elements
of cutting edge, early methods that are moving in that
direction– to imagine a greater socio-technical relationship for
which pragmatic methodology still needs to be found.
The five major technical themes that emerged as most
relevant for the alignment for humanitarian effectiveness
(along the Y axis) are:
Stakeholder-Driven Design: The theme focuses in the
relevance of having stakeholders (and not only direct users) as
principal decision-makers of the design process. It aims at
facilitating mutual understanding from the different parties,
minimizing the unintended consequences of an IS deployment,
derived from the omission of relevant parties.
This, for example, relates to meeting the operational aims
to accommodate the human rights law of self-determination
and the principle #7 of the ICRC Code of Conduct to “involve
programme beneficiaries in the management of relief aid” [21,
p.4]. The designer is required to act beyond a traditional
designer role which transfers a client’s requirements into a
technical solution determined by the designers himself. In this
case, stakeholders act as the solution’s co-designers, and the IS
designer is called to act as mediator among the several
stakeholder groups.
Moreover, a consequence from not involving a sufficient
number of stakeholders ends up in having systems designed in
a way which do not reinforce or motivate the participation of
those who possess the most valuable information at the lowest
levels. Therefore, a significant challenge that must be
accounted for with this approach is the required time it
accounts for considering the involvement of stakeholders and
group decision-making. It is more time-consuming every time
a new individual joins the process.
Accountability and Transparency: This theme highlights
the level of access a stakeholder has, as well as its
understanding of how the system operates. For this theme, it
was found that the concept of transparency, a central ingredient
of many of the success driven behaviors, was linked to several
other terms like: roles, information sources, information flows,
and workflows. A method for achieving this is through the
recording and storing of documentation. Having records of the
whole process, documentation of system transition and co-
creation of it with all stakeholders supports SDBs such as
Facilitating Discovery (SDB11), Formalizing Trusted Spaces
(SDB15), and enabling Mutual Authority (SDB7).
The information needs of success driven behaviors are bi-
directional, relying on the expertise of those working in the
field. If coded in the opposite way (e.g. one-way, or top-down
direction imposition), a breach in community trust might be
provoked, ending up in a lack of community information
sharing and collaborative work with practitioners in field.
Context-Reflecting Roles: Systems typically offer
functionalities for the administration of user rights and roles in
order to assign access to functionalities and information within
the system. With context-reflecting roles management, roles in
a system are determined by the stakeholders intimately
connected to this context. In the case of humanitarian
organizations, the design should be thought of as enhancing the
degree of participation of communities and aid workers in all
phases of disaster preparedness and response. Where effective
IS rely on these actors to be consciously acknowledged as the
key stakeholders, community agency in the decisions is critical
for driving effectiveness. Thus, there is a need to be dynamic in
the sense of configurability and flexible assignment according
to mutually agreed roles and responsibilities in the deployment
context (e.g. decided by practitioners and community, not
fixed). The conflict arises if the roles and access is not being
determined by those at the field level who need to have the
information available, but being imposed by an external party
whose assumptions may be misaligned with the effective
practices of humanitarian work
Sociomateriality: As part of the design process, this theme
highlights the characteristics of a complex context and
considers the ability of technology to more deeply adapt with
the ever-changing needs of the environment, such as individual
technical literacy, culture, and language. The theme accounts
for how the technological artifact will, in turn, influence and
shape different organizational realities, both positive and
negative. System flexibility stood out constantly as an
important element as it mediates the way field workers operate
with certain tools. In this sense, systems which have limited
flexibility to adapt some of their functions per context fail to
lighten up the burden of the field work.
Including the role of the designer, itself, being elevated to
that of a negotiator and translator of the different needs from
the several stakeholders (each with their own value-system),
the malleability of the technology to flow at the bequest of the
social drivers is imperative. Awareness of contextual factors
enable one to balance the conflicting interests and align the
negotiations to what is best for those in need. The designer in
this environment is situated as a mutual co-creator; and needs a
tool that can absorb, accommodate and adapt to the practices
and particularities of a specific context, diverse stakeholders
and their dynamic nature.
IS technology currently lacks the ability to iterate at this
deeper level to accommodate this context. Methods such as
task-oriented programming and modeling dynamic workflows
are making inroads into merging the work of design and
development through different coding languages (e.g. TOP
3
),
as well as leaving the design open enough to be able to change
in highly dynamic settings [25].
3 Task-oriented programming. A coding language recognizing audience
terminology and merging the role of designer and developer – originally
developed out of system design work with coast guard duty officers [25]
Accessibility: Successfully meeting information needs of
the work in the field relies heavily on trust and social
interaction between humanitarian practitioners and
communities and giving voice and agency to communities. The
diversity in technical literacy, culture, education and language
within communities requires major efforts to bridge the social
and technical. Tailoring a system specifically to the context and
making it accessible and understandable for all stakeholders is
a major challenge of systems design in the humanitarian
context. These practices refer to SDBs such as Speaking with
Cultural Competency (SDB3), Following Community
Structure (SDB1), and Creating Clarity of Roles (SDB9). It is
necessary to consider the technical environment of the
deployment context, e.g. stakeholder proficiency with
computers or smartphones. Supported input and output formats
have to be adjusted accordingly, e.g. by offering paper-based
alternatives to digital formats if technical literacy is limited, or
if the context calls for an alternative system to cope with
frequent power grid failures.
As humanitarians tend to work with communities who have
different levels of literacy and ways for communicating,
systems which are designed to input single data formats (e.g.
Latin alphabet characters) can limit the way practitioners
record data or communicate with communities as they might be
in the need of doing the translation work from the language of
the community (e.g. special characters or pictographic
language) into the fixed format of the communication system
they are given. In addition to it, this poses a barrier for the
humanitarian organization, field workers, and aid recipients as
they might feel an external form of communication alien to
their own as being imposed to them.
This matrix serves as a form of thesaurus to translate the
impact of technical design solutions on successful practice. It
aims to align meaning from successful practices into a
technical understanding and to reduce the gaps between these
two domains. It identifies what is important in design from the
humanitarian perspective, only this time using a technical
language which can be understood in a simpler manner by
those who are not familiar to humanitarian operations. As a
tool in the greater framework process, it serves as a critical
bridge in negotiation, so that a common understanding is
derived.
2) Guidance Framework for Humanitarian IS Design:
While the Maturity Matrix provides a capacity to better
assess if an IS or a design is aligned to the successful practices
of humanitarian work, the Guidance Framework aims to
address the need of effective communication between the
technical community of IS designers and actors in the
humanitarian domain to bring more helpful design solutions. In
addition to it, it enables HAs a form of a screening process for
identifying technology designers who have the will to engage
in a design process which challenges embedded professional
and personal assumptions that might not be valid and
applicable to other domains.
The Maturity Matrix serves as a companion to the
Guidance Framework, serving as a translation and mediation
artifact for navigating the humanitarian practice-IT design
conversation. We believe this artifact enables communication
of these two distant domains and attempts to draw them closer
by highlighting the importance of what matters and is effective
in terms of practice.
The Guidance Framework has been organized in three
phases i) Recognition Phase, ii) Orientation Phase, and iii)
Negotiation Phase. Each of these address capacities needed for
negotiation between parties to happen. They move away from
imposing directions or isolated decision-making processes and
move towards facilitating co-learning among stakeholders.
This way, the proposed technical solution will be an outcome
of a co-design process among IS designers and humanitarian
actors, which is adjusted to the applied domain needs and
which promotes participation and involvement of practitioners
and communities in a broader scale for making decisions.
Recognition Phase:
This is the first step of the designer’s journey before
entering into the domain. Prior to gaining a deeper knowledge
of the terminology or effective practices, it is essential that the
designer realizes the gap between his/her own working
assumptions and those which might be part of a humanitarian
context. It is this cognitive dissonance caused by conflicting
realities and underlying values, which should drive the
designer into stepping through the additional phases of this
learning process.
To facilitate this, the Matrix might initially serve as a
starting point to make the designer aware of the unique
considerations of designing for the humanitarian domain. The
conflicting paradigms can enable recognition of gaps in
understanding and priorities. The Matrix’s content is aimed to
inspire designers to take a closer look at the criteria and
concepts emphasized in the humanitarian domain; or to self-
select out recognizing if their design methods are not aligned
with the needs of humanitarian work.
The next phase will rely on the designer’s initiative and
motivation for learning about the humanitarian domain. If the
designer shows willingness to mold his/her current design
paradigms and adjust them to what the domain is requiring, he
or she may choose to go deeper in understanding the
humanitarian work environment.
Orientation Phase:
The Orientation Phase aims at orienting a designer to the
humanitarian organization’s existing value-system and basic
understanding of effectiveness. The designer is provided
literature on the domain, reflection exercises, a sample case
study, and a test.
Through self-discovery, in this phase, the designer receives
the opportunity to reflect on his/her own assumption about
humanitarian effectiveness, and re-orient from phase one. After
having acknowledged the existence of a more complex reality
with different work practices and values (e.g. in comparison to
those of a commerce environment), they increase their ability
to properly recognize where principles of humanitarian
effectiveness might be violated in designs of technical
solutions. In this case, designers play a more active role to
show their willingness and initiative towards the expected
change through an acknowledgement of the socio-technical
relationship. And thus, show their ability to consider contextual
factors as part of their design process.
The phase is structured in three sub-steps (Self-Learning,
Orientation Workshops, and Designer Test), each with
literature and methods engaging designers in the learning
process of the humanitarian domain. Ending with a practical
case study to assess if the designer has reached the threshold to
continue with the co-designing process of a technical solution
for the context.
If the designer shows self-learning, they could move to
working with a humanitarian practitioner on a case (possibly a
problem they need a solution for). Such a step is envisioned as
to begin a collaboration relationship with HAs to build trust
and co-learning. It is opportunity to show if they can present
their skills not as a strict design and development process, but
as an adaptable toolset of technical knowledge to be used in a
different way to design an artifact which impacts positively in
the work of the HA.
Negotiation Phase:
This last phase highlights the importance for listening and
understanding what the stakeholders need and the acceptance
of the designer in a facilitation role vs. sole-decision-maker
role. The designer is further on the development of a common
language and engaging trust, for which he/she enters this phase
as a mutual partner of the HA.
Through the incorporation of participatory methods that
promote discussion and negotiation, designers and stakeholders
work together towards a co-created solution which can operate
within a complex context as it acknowledges the socio-
technical relationship and their agents within this system. The
nature of a participatory approach will make sure that the
decision-making process stays within the stakeholders and is
not reliant on the designer in isolation.
During this phase, the Matrix facilitates the design of an
effective intervention into the complex context, by translating
humanitarian effectiveness in a language shared with designers.
This will allow the designed artifact achieves a high level of
context fitness. For example, that it is adaptable to language,
organizational culture, or situation.
Fig. 2 - Representation of the Maturity Matrix
As a consequence, the designer is able to communicate and
facilitate the IS design to HAs. The latter will make use of the
Matrix to assess the design and screen for the appropriate
elements of the technological solution which do not hinder the
practices they consider to be effective. Moreover, HAs will be
enabled to negotiate with designers on the socio-technical
elements which are needed to achieve their mission of
delivering help to those in need.
V. D
ISCUSSION
A. Limitations
The presented findings are grounded in broad and
representative qualitative data, but the construction of the GAT
has only been formatively iterated within the project team. An
application and dedicated evaluation with project-external
practitioners is missing so far. The appropriateness of the GF
facilitating the process of IS design between the designers and
humanitarians has to be executed, observed and analyzed in
one or more real case scenarios. Depending on the experiences
with the GF evaluation, the application of the Matrix will
reveal its limitations and benefits for a collaborative co-design
process between the involved stakeholders. Results need to be
incorporated in further iterations of the Matrix.
B. The need for socio-technical maturity of system design
methods
Based on the research, it was curious that as we mapped the
technical approaches, we found that our four levels were
aligned with some similar elements of the existing modelling
paradigms:
(1) Level 0: Characteristics of Object-driven design
founded on requirements emerged as the lowest level of
maturity as basically the designer is the one making decisions
and commanding the way a technical solution might look like
(2) Level 1: User-centered design elements which
incorporate human interaction with devices could be seen at
this level. Here the user has a role in influencing the way a
technological product or service is being designed [26].
(3) Level 2: Human-centered design characteristics are
introduced, incorporating a participatory approach of involved
parties in the design solution. Here, we could consider that any
solution would be an intervention in a system of systems. In the
case of a technology solution, not only is the user being
included as part of the process, but as design decision-maker,
as well as including other individuals which might by
indirectly linked to or affected by the final solution. Moreover,
this approach focuses in reaching some degree of alignment
between the stakeholders through an iterative design process
[15].
(4) Level 3: is not entirely defined as it might represent an
ideal state of complete stakeholder involvement with design,
acknowledging the symbiosis of the socio-technical
relationship in all its extensions. This level emerged in
consideration of advancing methods – that there is still an
opportunity (and need) for the existing socio-technical
approaches (e.g. HCD) to take a step beyond in the
acknowledgement of the complex context.
The first iteration of analyzing IS development through the
lens of the thirty SDBs revealed that there were key recurring
areas across the board that conflicted with the needs of the
practice. Several design practices or IS elements were
identified from what is considered as the traditional approach
and which challenge the role of the designer as to whether this
working mindset would be effective if applied to IS solutions
in the humanitarian domain. For example, the way successful
field workers make decisions with the communities they work
includes an openness and involvement that requires complete
transparency to what is recorded, how it is recorded, at the time
it is recorded.
This is not currently part of what our design and
development processes see as necessary and for that reason
may not even be realistically possible with today’s methods.
The embedded lack of transparency in IS design creates as an
obstacle to the access of practitioners to the relevant
information owned and contributed by communities and most
critical to successful outcomes.
These design or system elements and others like
transparency of decision-making, data management or
participation space came as recurring topics during the coding
process. It is because designers normally operate under another
value-system which proves to work in other contexts, and
raises the need for increased discovery and application of
socio-technical methods
VI. C
ONCLUSION
Design and development of technology has excelled in a
particular types of work domains. This paper is a call to go
further into the socio-technical domains. The relevant
technical themes that emerged provide a starting point to build
upon. As we advance and validate the GAT, designers and
humanitarian agencies now have an initial road map to better
adapt the IS design and development process for
accommodating the IS needs of the humanitarian values and
culture. We believe the matrix and framework offer strong
contributions to the field.
A. The humanitarian-IT rosetta stone
Our major intended contribution of this research is that it
represents the first effort for a translation of meaning within
these two different domains of IS design and humanitarian
operations. The “rosetta stone” between these two domains
lies in our effort to define technical processes as main design
characteristics which considers, in their essence, those practices
which proved to be effective in humanitarian work. A major
takeaway from this work is that the framework can be used as a
basis for future research. Most importantly, it has set a
precedent on this unexplored field, contributing with an effort
to start bridging the communication gap identified between
designers and humanitarian organizations.
B. A framework for conducting human-centered design with
humanitarians.
Three distinct components of HCD are system-focused vs.
product focused, holistic approaches with multiple
stakeholders, and including stakeholders as designers [27]. For
it to be done successfully, it ultimately requires a shift in
mentality for a designer. The steps and phases within the
framework represent the learning journey of the technology
designer through the development process of an effective
humanitarian IS artifact while becoming familiar with the work
and practices of the domain. In this experience, the designer
recognizes the different working environment. The designer is
presented with the choice to contribute in the domain not by
providing a solution developed on his own, but to adapt his/her
toolset of technical knowledge into a co-designing process
which acknowledges the values and work practices of those
with whom he/she is designing. Moreover, through the
framework, use of HCD facilitates understanding of what is
valuable for HAs and developing a trust relationship, where
success of design, at its essence, is based on shared-
understanding and negotiation.
Following an approach of learning through the experience
of others and challenging the traditional paradigms of design,
this paper aimed at developing a framework for the design and
assessment of information systems in the humanitarian context.
This not only required diving into a completely new domain,
but also working on a problem that has hardly been addressed
by other researchers before.
C. Taking the research forward
There is no ultimate solution to the problem. The proposed
one, as a guidance approach, tries to abstract from concrete
examples and give a general guidance as to how the design of
IS for the humanitarian context needs to be approached
differently than conventional software development projects in
a business context.
The framework proposed is a first approach to enabling the
design of IS that fit the needs of humanitarian organizations
and communities involved in the work. The proposed solution
is an effort to translate factors that make humanitarian work by
practitioners in the field successful to IS designers and connect
it to aspects of IS design that can potentially support these
factors, when being incorporated into the design process.
Greater iteration and validation is needed to deliver a usable
tool.
Further, taking the research forward in the future, we would
expect to include advancing knowledge and tools to involve
co-creation and support of community input.
Practitioner/Community-centered design is the ultimate goal of
humanitarians in support of their mission. To best support the
mission, providing technology that enables a high level of
community involvement is needed.
D. Beyond humanitarian impact
Going beyond the humanitarian domain, these concepts
might offer advances for other contexts, as the human-centered
approach that was taken can potentially enable a more effective
design of IS in other scenarios as well. This expansion of the
Maturity Matrix to other fields comes from the discussion of
whether the communication gap is exclusive to the
humanitarian domain, or a more general problem. As expected,
even though the humanitarian domain possesses very particular
characteristics that sets it apart from other domains (e.g.
commerce), the problem of translating meaning is present in
several other fields. Mainly because of the already mentioned
underlying value systems and difference in priorities for
considering what is relevant and successful within the structure
of an organization. All of this provides us enough argument
and opportunity for thinking of such an expansion.
A
CKNOWLEDGEMENTS
This work is the outcome of the committed and innovative
efforts of the project team of Anastasia Boftsi, Gino Coletti,
Robert Heidekrüger, Daniel Hetterle, Benedikt Hoffmeister,
Lindsey VanDeBrook, and Matthias Witt, as part of the
Department of Information Systems at the University of
Münster. Our gratitude goes to our Department and our Chair,
Prof. Dr.-Ing. Bernd Hellingrath, in addition to Prof. Mark
Haselkorn and the Dept. of HCDE at the University of
Washington. We further thank Prof. Mark Haselkorn, Meg
Drouhard and Dr. Bas Lijnse for their ongoing instruction,
advisement and consultation throughout the life of our project.
Finally, we like to acknowledge and thank the many other
experts who are too many to be named, and who provided their
time to participate in our project interviews, exercises and
reviews. Part of the research was supported by the Marie Curie
Actions (ITN) program under the European Union’s Seventh
Framework Programme FP7/2007-2013/ under REA agreement
number 317382.
R
EFERENCES
[1]. Mays, R. E., Walton, R., Lemos, M., and Haselkorn, M. 2014.
“Valuing What Works: Success Factors in Disaster
Preparedness An Independent Analysis of Red Cross/Red
Crescent Practitioner Needs.”
http://preparecenter.org/resources/valuing-what-works-succes-
factors-disaster-preparedness.
[2].
Walls, Joseph G., George R. Widmeyer, and Omar A. El
Sawy. 1992. “Building an Information System Design Theory
for Vigilant EIS.” Information Systems Research 3 (1): 36–59.
[3].
Romer, Paul M. 1990. “Endogenous Technological Change.”
Journal of Political Economy 98 (5, Part 2): S71–102.
[4].
Castro, Jaelson, Manuel Kolp, and John Mylopoulos. 2002.
“Towards Requirements-Driven Information Systems
Engineering: The Tropos Project.” Information Systems 27 (6):
365–89
[5].
Davis, Gordon B. 2000. “Information Systems Conceptual
Foundations: Looking Backward and Forward.” In
Organizational and Social Perspectives on Information
Technology: IFIP TC9 WG9.3 International Working
Conference on Home Oriented Informatics and Telematics:
Information, Technology, and Society, 61–82.
[6]. Yourdon, Edward, and Larry L Constantine. 1979. Structured
Design: Fundamentals of a Discipline of Computer Program
and Systems Design. 1st ed. Upper Saddle River, NJ, USA:
Prentice-Hall, Inc.
[7].
Stefik, Mark, and Daniel G. Bobrow. 1985. “Object-Oriented
Programming: Themes and Variations.” AI Magazine 6 (4):
40.
[8]. Orlikowski, Wanda. 1993. “Learning from Notes:
Organizational Issues in Groupware Implementation.” The
Information Society 9 (3): 237–50.
[9]. Dysart-Gale, Deborah, Kristina Pitula, and Thiruvengadam
Radhakrishnan. 2011. “Culture, Communication, and ICT for
Development: A Caribbean Study.” IEEE Transactions on
Professional Communication 54 (1): 43–55.
[10]. Feenberg, A. 1991. Critical Theory of Technology. Oxford:
Oxford University Press.
[11]. Kling, Rob, and Susan Leigh Star. 1998. “Human Centered
Systems in the Perspective of Organizational and Social
Informatics.” SIGCAS Comput. Soc. 28 (1). New York, NY,
USA: ACM: 22–29.
[12].
McClure, Dan, and Ian Gray. 2015. “Scaling: Innovation’s
Missing Middle.” Submitted for the Transformation Through
Innovation Theme for the World Humanitarian A Landscape
Review 65.
[13]. UNHCR. 2016. “Is Your App the Best Way to Help Refugees?
Improving the Collaboration between Humanitarian Actors
and the Tech Industry.” http://www.unhcr.org/innovation/app-
best-way-help-refugees-improving-collaboration-
humanitarian-actors-tech-industry/.
[14]. Walton, Rebecca, Robin E Mays, and Mark Haselkorn. 2016.
“Enacting Humanitarian Culture: How Technical
Communication Facilitates Successful Humanitarian Work”
63 (2): 85–100.
[15]. Baxter, Gordon, and Ian Sommerville. 2011. “Socio-Technical
Systems: From Design Methods to Systems Engineering.”
Interacting with Computers 23 (1). Elsevier B.V.: 4–17.
[16]. Kumar, Ajay, and Simeon Vidolov. 2016. “Humanitarian
Effectiveness: Reconsidering the Ethics of Community
Engagement and the Role of Technology.” In Conference
Proceedings – 13th International Conference on Information
Systems for Crisis Response and Management, 7.
[17]. Mays, Robin E., Robert Racadio, and Mary Kay Gugerty.
2012. “Competing Constraints: The Operational Mismatch
between Business Logistics and Humanitarian Effectiveness.”
In 2012 IEEE Global Humanitarian Technology Conference,
132–37. IEEE.
[18]. Suchman, Lucy. 1995. “Making Work Visible.”
Communications of the ACM 38 (9): 56–64.
[19]. Sundström, P. 1998. “Interpreting the Notion That Technology
Is Value-Neutral.” Medicine, Health Care, and Philosophy 1
(1): 41–45.
[20]. Van Looy, Amy, and Aygun Shafagatova. 2016. “Business
Process Performance Measurement: A Structured Literature
Review of Indicators, Measures and Metrics.” SpringerPlus 5
(1): 1797.
[21]. ICRC. 2004. “The ICRC Code of Conduct; Humantiarian
Principles in Practice.”
http://www.icrc.org/eng/resources/documents/misc/64zahh.ht
m.
[22]. The Sphere Project. 1998. The Sphere Handbook:
Humanitarian Charter and Minimum Standards in
Humanitarian Response. 2011. Southampton: The Sphere
Project.
[23]. Tomasini, Rolando, and Luk Van Wassenhove. 2009.
Humanitarian Logistics. London: Palgrave Macmillan UK.
[24]. Widera, Adam, and Hellingrath, Bernd. 2016. “Making
Performance Measurement Work in Humanitarian Logistics.
The Case of an IT-supported Balanced Scorecard”. In
Haavisto, I., Kovacs, G., & Spens, K. M. (Eds.), Supply Chain
Management for Humanitarians. Tools for Practice (1st ed.,
pp. 339–352). KoganPage.
[25]. Lijnse, Bas, and Jan Martin Jansen. 2012. “Incidone : A Task-
Oriented Incident Coordination Tool.” In Proceedings of the
9th International Conference on Information Systems for
Crisis Response and Management, 1–5.
[26]. Abras, Chadia, Diane Maloney-krichmar, and Jenny Preece.
2004. “User-Centered Design.” In Bainbridge, W.
Encyclopedia of Human-Computer Interaction. Thousand
Oaks: Sage Publications.
[27].
Kling, Rob, and Susan Leigh Star. 1998. “Human Centered
Systems in the Perspective of Organizational and Social
Informatics.” ACM SIGCAS Computers and Society 28 (1).
New York, NY, USA: ACM: 22–29.
