Applying Human-Centered Design

in the development of digital

products for disaster response

Rosa Janna Jager

Master Thesis
Msc. Strategic Product Design
Delft University of Technology

Chair: Dr. ir. Diehl, J.C.

Mentor: Dr. Comes, T.
Company supervisor: Canavan, O

14-08-2020

1 
 Visual research summary
Applying Human-Centered Design in the development of
digital products for disaster response

The context of disaster response is incredibly complex due to its chaotic nature and the large number of variabilities per
disaster. This complexity makes it difficult for developers of digital tools for disaster response to understand the context of the
products they develop. However, a lack of understanding of the use context can result in the development of ill-suited
products that do not fulfill the user needs. Human-Centered Design (HCD) is a method to generate a better understanding of
the user and the use context through the perspective of the user. It is an approach that is rooted in the belief that the people
who face the problems are the starting point when developing a solution.

510 is a Netherlands Red Cross initiative that develops accessible digital tools for humanitarian response across the world. 510
has as a goal to: “improve the speed, quality and cost-effectiveness of humanitarian aid by using and creating data and digital
products.” 510 products, which can be databases, models or software tools, are developed for different types of disasters in
different countries across the world. In order to ensure that the products are solving user needs and in order to ensure that the
products are suited for the context in which they will be employed, 510 aims to incorporate a Human-Centered Design (HCD)
approach to their product development. However, the HCD methods are not yet structurally employed across all projects.

The aim of this thesis is to understand how Human-Centered Design can be applied in the development of data and digital
tools for humanitarian response. In order to achieve this, the reseach aims to (1) understand the factors that enable and hinder
the implementation of HCD, to (2) translate these into required elements for HCD implementation, to (3) understand the needs
for HCD in the development of response technology and to (4) make a proposal for the implementation of a human-centered
product development process for 510.

The factors that enable and hinder the The three lessons are translated into three
implementation of HCD are clustered into three elements of embedded HCD. These three
lessons on the implementation of HCD: elements are developed into the proposal.
1. HCD is already practiced in many ways 1. A clearly defined role for HCD within 510
It is found that HCD is already practiced HCD is not starting from scratch but rather
throughout the product development in many finding what is already done and what is still
ways. A lot of information on the user, their needed for the organization. This is why the
tasks and their context is already available first element of embedded HCD is defining a
within the projects and stakeholders are clear role for the HCD team.
involved throughout product development.
2. An embedded HCD workflow
2. Embedded HCD is interactive with the In order to be structurally included in product
existing development development, HCD needs to provide overview
HCD is applied in varying ways across projects. for the rest of the 510 team. A workflow is
Whereas the HCD team has worked on proposed of HCD methodologies that is linked
developing methodologies, there was limited to the larger 510 development process.
room for documentation. Because of this, it is
unclear to 510 staff when the methods should 3. A communication plan that helps the HCD
be applied and how they will bring value to the team guide 510 in implementing HCD
project. The HCD team is not only responsible for
performing HCD activities but is also
3. Everyone within 510 has a role in the responsible for guiding the rest of 510 in the
implementation of HCD implementation of HCD. To support this, a
Whereas applying HCD methods is the communication plan for the HCD team is
responsibility of the HCD team, implementing proposed.
an HCD approach requires a shift within the
entire team.

2
Identified needs for HCD in the
development of digital tools for
humanitarian response are supporting the
formulation of human-centered project
goals, generating an understanding of the
user and their direct context and the
design of usable and suitable products.

Implementation
HCD HCD Project Proposal Feasibility Database/ Product
support
role method exploration writing study model building development
evaluation
Human-centered
project goals

Strategy
sheets
understanding

Persona
journey
User

Codesign
Interface design

User
testing

Prototyping

3 
 Abstract

In the development of digital tools for use during disaster response, often referred to as ‘response technology’, generating
an understanding of the user and the context of use is challenging. The context of disaster response is incredibly complex
due to its size, its chaotic nature and the variabilities per disaster. This complexity makes it difficult for developers of
response technology to understand the context of the products they develop. However, a lack of understanding of the
context of use can result in the development of ill-suited products that do not fulfill the user needs. Human-Centered
Design (HCD) is a method to generate a better understanding of the user and the context of use through the perspective
of the user. It is an approach that is rooted in the belief that the people who face the problems are the starting point
when developing a solution. HCD is seen as a possible approach to improve the development of response technology.

The aim of this thesis project is to understand how Human-Centered Design can be applied in the development of
digital tools for disaster response. In order to explore this, a case study is done together with the Netherlands Red Cross
data team, also known as 510. 510 works together with a core team of around 15 staff members and a large number of
volunteers to develop data and digital products for disaster response. The team started implementing HCD into their
product development process in 2018. To do so, two staff members dedicate part of their time to the development and
employment of HCD methods and a number of ‘HCD volunteers’ have been taken on to support in these HCD activities.
However, HCD has not yet been fully implemented into all of 510 projects. This research aims to understand what is
needed in order to apply HCD in 510.

For this research, firstly the enablers and challenges towards implementing HCD in 510 are analyzed (chapter Discover).
These insights are summarized into three lessons about the implementation of HCD. These three lessons are translated
into three elements of embedded HCD (chapter Define). Next, further research is done in order to gather more detailed
insights needed to develop these three elements for the 510 case (chapter Develop). Lastly, the three elements of
embedded HCD are developed for 510 (chapter Deliver).

Part 1: Discover – Enablers and challenges towards implementing HCD in 510

The enablers and challenges towards implementing HCD in 510 product development are identified through an
organizational analysis of 510, an analysis of the current implementation of HCD and through interviews with 510 (non-
HCD) staff and HCD volunteers.

Part 2: Define – 3 lessons and 3 elements of embedded implementation of HCD

From the case study analysis, three lessons in implementing HCD for 510 become clear:

Firstly, HCD is already practiced in many ways in 510. From communicating with the client and stakeholder engagement,
to implementation and support after implementation, there are many ways in which parts of an HCD approach are already
utilized. Implementing HCD is therefore not starting from zero, but rather finding what is already done and what is still
needed for the organization.

Next, embedded HCD is interactive with the existing workflow. Implementing HCD does not only consist of selecting
suited HCD methodologies; the most important part is embedding them in the product development in such a way that
they are used effectively. In order to be integral to product development, HCD needs a structured plan in which the links
between HCD activities and the rest of the product developmment process are clear.

Lastly, everyone within 510 has a role in the implementation of HCD. An HCD approach can be practiced and also
hampered by almost every person within the organization. This means that the HCD team is not only responsible for
performing HCD activities but also for guiding the rest of the staff in implementing HCD.

These lessons can be translated into three elements of embedded implementation of HCD; (1) a clearly defined role
for HCD within the organization, (2) an embedded workflow of HCD methodologies that is linked to the larger product
workflow and (3) a communication plan that guides the implementation of HCD across the organization. It should be
noted that the three elements are interlinked; The role and responsibilities largely determine the methodologies and
workflow. Both the role and the workflow are used as means of communication in order to guide implementation. These
three elements will form the structure of the final proposal for HCD.

Part 3: Develop – HCD in response technology development

In order to develop the three elements of embedded implementation of HCD, additional research is performed: Through
a literature review, the current application of HCD across different domains is assessed. Through interviews with 510 staff
and stakeholders from a 510 project (consisting of staff of National Societies Red Cross of project countries) three needs
for the application of HCD within the 510 case are identified:

1. The first need is ensuring that the project is solving the right problem for the right person. 510 aims to
improve the speed, quality and cost-effectiveness of humanitarian aid by using data- and digital products.
Even scientific projects aim to solve human problems. However, the research goal might not be formulated
in order to reflect that.

4
2. The second need for HCD of 510 is to create an understanding of the user and their context from a user
perspective throughout the project. Literature research shows that in the development of response technology,
often an oversimplified definition of the user and the context is used. This is reflected in 510 through their
broad user-definition; the wide variety of possible users included in the broad user-definition makes it even
more difficult to get a clear understanding of the user and the context in which they act.

3. The third need for HCD is the development of a suited and usable user-interface for software products.
Currently, assumptions are built up throughout the interface design with limited iteration or feedback
throughout development. By iteratively prototyping and gathering feedback from users, the product is more
likely to suit the many contexts it will be applied in.

Part 4: Deliver – 510 HCD proposal

The three elements for embedded HCD are developed into a proposal for the case of 510 through incorporating the
challenges, the insights from literature and the needs as expressed by 510.

Element 1: Role
The found needs are translated into a summarized role for HCD: (1) supporting the formulation of human-centered
project goals, (2) generating an understanding of the user and their direct context and (3) the design of usable and
suitable products. The HCD team will fulfill these roles by applying 3 main HCD principles: gathering user insights and
feedback through participatory methods in order to continuously and iteratively improve on all three responsibilities.

Element 2: Embedded workflow

An embedded workflow of HCD activities is proposed. The workflow gives an overview of the selected HCD methods,
in which project phase they should be applied and their output for the project. The workflow is based on current HCD
activities while changes are proposed based on the defined HCD role, examples from literature and the needs for HCD as
found through interviews.

Element 3: Communication
The third lesson in implementing HCD is that it should be implemented by everyone in the organization. 510 staff need
to understand HCD in order to include it in their project. HCD volunteers need to understand the methodologies in order
to perform HCD activities. In order to help the HCD team guide all of 510 staff towards embedded implementation of
HCD, the HCD role and workflow need to be communicated in a way that is actionable for 510 staff and HCD volunteers.

First of all, communication is already taken into account in the development of the role as well as in the development of
the workflow: the HCD goals are formulated in order to have clear relevance to 510 product development activities and
the HCD workflow is made more transparent for 510 staff through participatory HCD activities.

In addition to this, 4 communication materials are proposed:

1. A general introduction slide-deck to be presented to 510 staff and to be viewed by all incoming 510 volunteers
2. An HCD workflow overview to generate an understanding for the HCD activities in relation to 510 projects
3. An overview explaining when HCD should be involved in 510 projects and how HCD will benefit the project
4. Modules explaining the HCD methods in order for HCD volunteers get familiar with the activities autonomously

Concluding
The case study presents several insights in the implementation of HCD for digital tools for disaster response within
humanitarian organizations like the Netherlands Red Cross. Three lessons about implementing HCD are: (1) HCD is
already done in many ways, (2) HCD covers all aspects of the organization and (3) should be implemented by everyone
in the organization.

Three elements for successful implementation of HCD are found to include: a clearly defined role and scope for HCD
activities, an embedded workflow that complements existing product development and a communication plan that
guides HCD throughout the organization and promotes participation and transparency.

Identified suitable roles for HCD in the development of response technology are: (1) supporting the formulation of
human-centered project goals, (2) generating an understanding of the user and their direct context and (3) the design of
usable and suitable products.

5 
 Table of contents

1. Introduction and problem definition 8

1.1 Human focus in humanitarian response 8
1.2 510 case introduction 9
1.3 Research questions 9

2. Methodology 10
2.1 Discover - Challenges in the implementation of HCD in 510 11
2.2 Define - Lessons and 3 elements of embedded implementation of HCD 12
2.3 Develop - Insights in the needs for HCD in 510 and the application of HCD across fields 12
2.4 Deliver - Proposal for embedded HCD in 510 13

Part 1: Discover 15
3. Literature review on HCD 16
3.1 An introduction to the HCD approach 16
3.2 A review of the implementation of HCD in organizations 17
4. Organizational analysis 510 19
4.1 Understanding the 510 team 19
4.2 Conclusion 510 organizational analysis 22
5. Maturity analysis HCD in 510 23
5.1 People and resources 23
5.2 Tools and capabilities 24
5.3 Organizational structure and systems 25
5.4 Metrics and deliverables 26
5.5 Maturity scores 26
5.6 Conclusion maturity analysis of HCD 27
6. Interviews on HCD in 510 28
6.1 510 staff interviews 28
6.2 510 HCD volunteer interviews 32

Part 2: Define 35
7. Define 36
7.1 Clustering insights on the implementation of HCD 36
7.2 Element 1: A clear role for the HCD team 37
7.3 Element 2: An embedded HCD workflow 38
7.4 Element 3: A communication plan that guides 510 in implementing HCD 39

Part 3: Develop 41
8. Literature review on applications of an HCD approach 42
8.1 HCD applied in software development 42
8.2 HCD applied in humanitarian action 44
8.3 HCD applied in humanitarian software development 44
8.4 Literature review conclusion 45
9. Interviews on needs for HCD in 510 46
9.1 Project stakeholder interviews 46
9.2 510 staff interviews 47

6
Part 4: Deliver 51
10. Element 1: Role 52
10.1 Clustered needs from needs analysis interview 52
10.2 Scope 53
10.3 Role of HCD in 510 product development 54
11. Element 2: Workflow 55
11.1 Step 1. Mapping the 510 workflow 55
11.2 Step 2. Selecting HCD methods 56
11.3 Step 3. Integrated development process 57
12. Element 3: Communication 59
12.1 Responsibilities of staff members across project stages 59
12.2 Design: Communication materials 60

13. Conclusions 65
13.1 Implementation of results in 510 66
13.2 Scientific relevance 67
13.3 Limitations 67
13.4 Recommendations  68

14. References 69

Appendix
Appendix A. Interview setup 71
Appendix B. Wordcloud 510 HCD 72
Appendix C. Worldcloud literature 73
Appendix D. Complete insights overview table 74
Appendix E. Value propositions for HCD in 510 76
Appendix F. HCD general introduction modules 77
Appendix G. HCD methodology modules 79
Appendix H. Project brief 84

7 
 1. Introduction and problem definition

1.1 Human focus in humanitarian response

1.1.1 Disaster response innovation
The society we live in is rapidly changing due to technological advancement and digitalization. In humanitarian action,
digitalization is identified as a key driver of change as well. Technological advancements provide opportunities to advance
disaster response activities such as data gathering, data analysis, logistics and donation (Brophy-Williams et al., 2013).
There are already many examples of the use of innovative technologies for disaster response, for example the prediction
of natural disasters in order to take preventative measures, the use of unmanned aerial vehicles to provide relief aid in
remote areas and the use of chatbots to monitor food-security in hard to reach areas (Melamed, 2017).

Technical advancements, while they are the basis, are only one part in the development of well-functioning response
technology (Jul, 2007). The innovative products might be employed in numerous situations by a wide variety of people.
In order to develop these tools, it is crucial to gain understanding of these users, their activities and the context in which
the technology will be employed.

To better understand the user and their context, local communities are increasingly included in the development of
disaster response (Brophy-Williams et al., 2013). The 2015 World Disasters Report (IFRC, 2015) emphasizes the crucial
role of local actors in disaster response, not only because they are always the first responders in case of disaster, but
also because of their broader understanding of local circumstances. At the World Humanitarian Summit in 2016 aid
organizations agreed to more and more include recipients in the design of the programs. Additionally, in their humanity
agenda, OCHA promotes an inclusive and bottom up approach in order to succeed in their agenda for change (UN OCHA,
2017).

“Local actors are uniquely placed to find solutions that reduce underlying risks because
of their understanding of local contexts – of weather patterns, of community leaders, of
vulnerabilities and of sources of strength.” - IFRC, (2015)

Although there is an increased attention and an increased intent to include a local perspective, building awareness of the
local context in the development of response technology remains a challenge. The context of humanitarian response is
complex due to the large variety of people and organizations involved in the inherently chaotic and unstable situation of a
disaster (Jul, 2007) (Brophy-Williams et al., 2013). This is very different from most design contexts, where the deployment
of the technology and the requirements are relatively straightforward (Brophy-Williams et al., 2013). The complex context
of disaster response often results in assumptions regarding the user, their action and the context of use, leading to less
effective products (Jul, 2007).

1.1.2 A human focus in humanitarian response

One way to systematically gain understanding on the user, their activities and their context is through Human-Centered
Design (HCD). HCD is an innovation approach that centers around empathy with the user. It is described by Junginger
(2005) as: “the task of developing products that people find useful, usable and desirable”.

In practice, HCD is a design method that is based on interaction with the people who are intended to benefit from
the design. It is a participatory approach and therefor asks for a collaboration between the developer and the user.
Additionally, HCD is an iterative approach that iterates between development and testing.

“Embracing human-centered design means believing that all problems, even the seemingly
intractable ones like poverty, gender equality, and clean water, are solvable. Moreover,
it means believing that the people who face those problems every day are the ones who
hold the key to their answer. Human-centered design offers problem solvers of any stripe
a chance to design with communities, to deeply understand the people they’re looking
to serve, to dream up scores of ideas, and to create innovative new solutions rooted in
people’s actual needs.” - IDEO.org, (2015)

HCD is proposed as a suitable methodology for use in the development of digital tools for disaster response because
of two reasons. Firstly, it deals with the complex nature of disaster response by looking from a user perspective and
constantly interacting with the user in order to create a better understanding of their context (De Leoni et al., 2007).
Secondly, HCD is in line with the increasing inclusion of local actors in the development of disaster response. The HCD
approach recognizes the essential role of local communities in finding solutions for the problems they face.

8
1.2 510 case introduction
Shape the future of humanitarian aid by converting data into understanding, put it in
the hands of aid workers, decision-makers and people affected, so that they can better
prepare for and cope with disasters and crises. – 510 mission statement

This thesis focuses on the case of 510, who aim to implement HCD in their response technology development. 510 is
a Netherlands Red Cross (NLRC) initiative that was started in 2016 and is part of the movement to develop accessible
data and digital tools for humanitarian response across the world. 510 works together with a core team of around 15
staff members and a large number of volunteers to develop data and digital products for disaster response. 510 has as
a goal to: “improve the speed, quality and cost-effectiveness of humanitarian aid by using and creating data and digital
products.” They make digital products that support numerous people involved in disaster response, from the people
affected, to the national Red Cross or other emergency aid providers, to hydrometeorological centers, local governments
and donors. 510 products, which can be databases, models or software tools, are developed for different types of disasters
in different countries across the world.

Whereas 510 is situated in the Netherlands, their products are implemented globally, targeting a wide variety of people
in a wide variety of contexts. These varying locations and the dynamic context of humanitarian action make it difficult to
gain understanding for the contexts in which the product will be used (Brophy-Williams et al., 2013). In order to ensure
that the products are based on user needs and in order to ensure that the products are suited for the context in which
they will be employed, 510 aims to incorporate a Human-Centered Design (HCD) approach to their product development.
To do so, two staff members have taken on the development and practice of HCD methods and a number of HCD
volunteers have been taken on for support in these activities.

The implementation of HCD is still in process. Since the end of 2018 HCD methods have been applied on an ad-hoc
basis in some of the 510 projects. However, the HCD methodologies are not yet fully developed and are currently not
structurally employed across all projects. Therefore, the aim of this thesis is (1) to understand the challenges in applying
a human-centered approach and (2) to translate these lessons into required elements for HCD implementation, (3) to
make an analysis of the needs for a human-centered approach in the case of 510 and (4) to make a proposal for applying
a human-centered product development process within 510 product development.

1.3 Research questions

How can Human-Centered Design be applied in the development of data and digital tools for
humanitarian response?
This research question is explored through the following sub-research questions:

Sub-Research question Discover:

What are challenges towards applying HCD in the development of data and digital tools for humanitarian
response?

Sub-Research question Define:

What are the required elements of successful implementation of HCD in the development of data and
digital tools for humanitarian response?

From the required elements of HCD, new sub-research questions emerge for the development of the final proposal for
510;

Sub-Research question Develop:

What are the needs for HCD within 510 in the development of data and digital tools for humanitarian
response?

Sub-Research question Deliver:

How can Human-Centered Design be applied in the development of data and digital tools for humanitarian
response in the case of 510?

9 
 2. Methodology

To understand how HCD can be applied in the development of response technology, the double diamond method
(Design Council, n.d.) is used. The double diamond is a design methodology developed by the British Design Council in
2005. The double diamond has four phases: Discover, Define, Develop, Deliver. The first diamond, including the Discover
and Define phases, is about understanding the challenge and the underlying problems. The second diamond, including
the Develop and Deliver phases, is about generating solutions to these problems. The double diamond works with a
divergence-convergence method. Discover and Develop are the diverging phases in which knowledge is expanded upon
by doing research or generating new ideas. Define and Deliver are converging phases in which the existing knowledge is
used to formulate challenges and concepts. The method allows to iterate not only on the design outcomes, but on the
problem as well. The method is chosen because of this focus on iteration in the explorative phase of the project. For the
case of 510, the challenges in implementing HCD are quite unclear at the beginning of the project and understanding
these challenges is equally important as the design of the solutions. The following paragraphs explain in more detail the
activities done within the four double diamond phases (as is illustrated in Figure 1)

Figure 1. The double diamond (image adapted from Design Council, n.d.)

10
2.1 Discover - Challenges in the implementation of HCD in 510
The first diamond helps people understand, rather than simply assume, what the problem is.
- Design Council (n.d.)

The first phase consists of discovering the issue through interviewing and observing those who face the problem (Design
Council, n.d.). In this thesis project, the challenges towards implementing HCD in 510 are researched in this phase. Firstly,
a literature research is done in order to get an understanding of HCD. Next challenges and enablers of implementation of
HCD in 510 are discovered through an analysis of 510, an analysis of the current situation of HCD within 510 and through
interviews with different stakeholders.

2.1.1 Literature research

An initial literature research is done in order to define the concept Human-Centered Design and review existing knowledge
on the implementation of a Human-Centered Design approach in organisations.

2.1.2 510 analysis

A description of the 510 products and scope is given in order to get an initial understanding of this Netherlands Red
Cross (NLRC) department. To elaborate on this initial understanding, the 7S model by McKinsey is used. This is a widely
used model, developed in the 70s, in order to analyze companies based on 7 consistent factors. The model combines
more evident values such as organisational hierarchy and structure with more ambiguous values, such as shared values
and style. 510 has both a quite unusual organisational structure as well as distinct organisational values. Therefor the
7S model is considered suitable to analayze the department. The analysis is done only for 510 because the department
works quite separately from the rest of the NLRC. Information is gathered from observation in meetings and discussions,
from immersion, from the internal documentation of 510 and from collaboration with the 510 supervisor for this project.

2.1.3 HCD maturity analysis

An analysis of the HCD activities and team is made in order to understand its current maturity and possibilities for
improvement. Little is written about the application of Human-Centered Design in organizations and during the writing
of this thesis, no assessment method for HCD within organizations is known. For similar approaches such as service
design and user experience design however, several assessment models are developed by design agencies. Examples
of such maturity models are the Service-design maturity model by Koos Service Design (Corsten, 2019) or the maturity
levels by NNGroup (J. Nielsen, 2006a), (J. Nielsen, 2006b). Whereas User Experience (UX), Service Design and Human-
Centered Design differ in focus, the approaches also overlap in many ways. Because of this overlap and the lack of an
HCD assessment model, the Service Design Maturity Model by Koos is seen as relevant for the case of 510 and used in
order to assess 510 HCD maturity.

Figure 2. The stages of Service Design Maturity (adapted from Corsten, 2019)

The maturity model by Koos assesses an organization based on 4 indicators (as seen in Figure 2): ‘people and resources’,
‘tools and capabilities’, ‘organizational structure’ and ‘metrics and deliverables’. These different indicators are categorized
according to 5 possible stages: Explore, Prove, Scale, Integrate and Thrive. The classification helps identify possibilities for
improvement for HCD in the organisation.

Information is gathered through observation, immersion (by participating in HCD activities), from internal documentation
of 510 and through collaboration with the 510 supervisor from this project.

2.1.4 Interviews
Five 510 staff members are interviewed in order to understand the current application of HCD in 510, in order to find
enablers and challenges to implementing HCD. HCD volunteers are the biggest workforce of the HCD team in 510.
Two HCD volunteers are interviewed in order to understand their work for 510 and their view on HCD work at 510.
The interview guides can be found in Appendix A. Both interviews are semi-structured in order to give participants the
opportunity to guide the conversation to the topics they find important.

11 
2.2 Define - Lessons and 3 elements of embedded implementation of HCD
In the Define phase, the findings from the discover phase are turned into a problem definition.
- Design Council (n.d.)

2.2.1 Clustering insights

The insights from interviews are analyzed and clustered in order to form groups of insights that belong to a similar theme
(Figure 3). This is done partly individually and partly in a group. The group analysis is done with the HCD team (volunteers
and staff). In the group analysis, every participant is given a number of transcripts to go through in order to highlight any
relevant insights. Afterwards, the insights are discussed together and grouped into larger themes.

Figure 3. Combining transcripts or other analysis into insights and insights into clusters

Because of the number of interviews done with 510 staff and HCD volunteers, part of the interviews were clustered
individually. This consisted of going through the transcripts and recordings multiple times, “immersing” into the topic and
highlighting insightful quotes. The insights were clustered multiple times according to several themes in order to find the
final overarching lessons. Additionally, the organizational and maturity analysis were done individually and therefor also
translated into insights and clusters individually.

The clusters form the basis of the lessons in implementing HCD. These three lessons for implementing HCD are translated
into three elements for embedded HCD.

2.3 Develop - Insights in the needs for HCD in 510 and the application of HCD across fields
In the second diamond, a design is made to help solve the problem defined in the first diamond.
- Design Council (n.d.)

The application of HCD in several fields is researched through a literature review. Additionally, 510 staff members and 510
project stakeholders are interviewed in order to understand the needs for HCD. Based on these insights and the insights
from the interviews, ideation is done for solutions.

2.3.1 Literature review

In order to understand the need for HCD in the development of response technology, examples of the use of HCD in this
field are researched through a literature review. The role of HCD, the used methodologies and the challenges with the
use of the methodologies are discussed. Because the limited available research on the use of HCD in the development of
response technology, similar uses for HCD are used for as example as well:
1. HCD in software development
2. HCD in humanitarian aid
3. HCD in the development of digital tools for disaster response

2.3.2 Interviews
In order to understand the need for HCD and the niche it could fulfill within 510, 510 staff and 510 projects stakeholders
are interviewed.

Nine 510 project stakeholders, consisting of Red Cross-National Society employees from project countries, who are
involved in a project with 510, are interviewed to understand their perspective on the project. The interview focuses on
the goals they have within the project and the challenges they come across during the project.

Five 510 staff members are interviewed in order to understand their perception of need for HCD activities, their current
use of information on the user and context and their expressed needs for information on the user and the context.
The interview guides can be found in Appendix A.

Similar to the interviews in the exploration phase, the interviews are semi-structured with a small number of open-ended
questions in order to give the participant freedom to discuss the topics they found most important. However, in this case
the questions were focused on the information need during 510 projects instead of on the current experience with HCD.

12
Deliver - Proposal for embedded HCD in 510
The Deliver phase consists of iterative development towards a final design. - Design Council (n.d.)

In the Deliver phase in this report, the final proposal is explained as well as the iteration cycles.

2.3.3 Role
Based on the expressed needs, a role and scope for the HCD department is proposed. In order to formulate the added
value of HCD for 510 the value proposition sheets (Strategyzer, 2020) are used (Figure 4). These sheets help determine
the added value of the product or service (in this case, Human-Centered Design) for the user (in this case the user is 510)
by breaking them both down into 3 parts; The first part is a general description of the product and the responsibilities of
the organization. The second part is the goals of the user and how the product/service helps to achieve these goals. The
third part is the challenges the user faces and how the product/service helps mitigate these challenges.

Parts of service
that help reach
Goals

General
description Tasks
products service

Parts of service Parts of service

that help ease that help ease

Product User
Figure 4. Value proposition (adapted from Strategyzer, 2020)

2.3.4 Embedded workflow

Methodologies are chosen and an embedded activity workflow is proposed based on insights from the Discover phase,
the Develop phase and the defined role for HCD. To do so the Introduction-Establishment-Improvement (IEI) Model by
Metzker and Offergeld (2001) is used which is further explained in sub-chapter 3.2. The lessons from literature are taken
into account in the adaptation of the methodologies and the workflow. Appendix C shows the insights from literature
divided per HCD role and Appendix B shows a wordcloud that was made in order to consider the link between HCD and
510.

2.3.5 Communication plan

One of the elements of embedded HCD is found to be communication from the HCD team in order to help the HCD team
guide 510 staff and volunteers in the use of an HCD approach. To facilitate this a communication plan is made. First an
overview is made of the HCD responsibilities per staff member per project phase. Using this as a guide for the needed
knowledge, four communication materials are designed for four different user groups.

13 
14
 Part 1: Discover
The following chapters describe the exploration of the problem:

Chapter 3. Literature review on HCD (page 16)

The literature research consists of a research into the concept of HCD and research into the
implementation of HCD in organizations.

Chapter 4. Organizational analysis 510 (page 19)

The organizational analysis is done to further understand the context in which HCD is implemented.
It consists of an analysis of 510 and an analysis of the HCD team within 510.

Chapter 5. Maturity analysis HCD in 510 (page 23)

A maturity analysis on the 510 HCD team is performed in order to understand the current practices
of the HCD team and the possibilities for improvement.

Chapter 6. Interviews on HCD in 510 (page 28)

Interviews with 510 staff and 510 HCD volunteers are conducted in order to understand their
experience with implementation of HCD in 510.

The insights are further analyzed in the Define chapter

15 Part 1: Discover
 3. Literature review on HCD

This chapter discusses the basic principles of Human-Centered Design, the roles of HCD in organizations and the
implementation of HCD as discussed in literature.

3.1 An introduction to the HCD approach

In order to discuss the application of HCD in 510, an understanding of the current HCD approach is needed. This sub-
chapter provides a description of the concept of Human-Centered Design as found in literature.

3.1.1 The term Human-Centered Design

Currently 510 uses the description of HCD as described by the design organization IDEO. IDEO has made a handbook
(IDEO.org, 2015) and tools on HCD that are widely used, mostly in social organizations (IDEO.org, 2015). However, the
definition and practices of Human-Centered Design can vary greatly across organizations (Gordon, Kramer, Moore,
Yeung, & Agogino, 2017). Additionally, the terms ‘user-centered design’, ‘design thinking’, ‘empathic design’ and ‘people
centered design’ are used for similar practices.

3.1.2 History of Human-Centered Design

The term HCD was first used to describe the design of technology in a way that incorporates human capacity and this
approach was applied mostly in the development of software (Walters, 2005). Wallach & Scholz (2012) describe User-
Centered Design as a successful and practical approach to the design of software user-interfaces. In software design,
Human- or User-Centered Design are closely linked to the usability of the designs interface. Gould and Lewis’ (1985)
describe Designing for Usability according to three principles: (1) early focus on users, (2) empirical measurement using
prototypes and (3) iterative design (through Wallach & Scholz, 2012). These principles are almost identical to the IDEO
principles for Human-Centered Design, even though the HCD method is applied to a much larger variety of products and
services.

After usability design, Human-Centered Design became more and more known for its use in social design (Nemeth, 2019).
Because of its focus on human insights and participatory approach it is considered to be a design method that enables a
dignified relationship with the user (Buchanan, 2001).

“It is true that usability plays an important role in human-centered design, but the
principles that guide our work are not exhausted when we have finished our ergonomic,
psychological, sociological and anthropological studies of what fits the human body
and mind. Human-centered design is fundamentally an affirmation of human dignity.
It is an ongoing search for what can be done to support and strengthen the dignity of
human beings as they act out their lives in varied social, economic, political, and cultural
circumstances.” - Buchanan (2001)

This social aspect of HCD was reinforced when in 2008 The Bill and Melinda Gates foundation asked design organization
IDEO to develop their currently widely used HCD toolkit, which was done in order to create more awareness of HCD as a
design method for social impact.

3.1.3 The Human-Centered Design approach

Human-Centered Design should be seen as an approach
rather than a set methodology with clearly defined steps.
The ideology behind Human-Centered Design is that it starts
with the human aspect of the problem. The initial focus is
on understanding the user’s hopes, fears, goals in order to
understand what is desirable. Allthough the activities should
start at the user, there should be an understanding of the
larger system surrounding the user. This three-part system
includes, besides desirability, business viability and the
technical feasibility of the project (Figure 5).

Every publication, video or journal provides slightly different

principles for HCD. Although the main principle is in every
case to ‘focus on the people’. Beyond this main principle, the
other principles of HCD vary. Additionally to the core “focus
on the people”, Don Norman (2018) states, HCD is “finding
the right problem to solve” and “thinking of everything as a
system”. Other principles mentioned include ‘building in multi-
disciplinary teams’ (IBM, 2020) and ‘considering the overall
consumer-experience’ (Elmansy, 2017).
Figure 5. HCD starts at Desirability, but includes Viability,
Feasibility (adapted from IDEO.org, 2015)

16
 Based on the literature review and IDEO’s Field guide to HCD (2015), HCD has three main principles:

1. HCD is, as the name suggests, human-centered. In HCD, the initial focus is on empathy with the user and
understanding the needs of the intended users (Bourne, 2019). Only after this step, the project incorporates
the viability from a business- and the feasibility from a technology perspective.
2. In HCD an iterative approach is used to get to the final result. Evaluations and iterations are made throughout
the development process by prototyping and user-testing.
3. The approach is participatory. It engages the user in the design process, from ideation to implementation.

Although there is no predefined methodology for Human-Centered Design, in the Field Guide to Human-Centered
Design (IDEO.org, 2015), the HCD approach consists of 3 phases: inspiration, ideation and implementation. In the
inspiration phase the goal is to understand the user. In the ideation phase the earlier observations are analyzed and ideas
are generated. Additionally, prototyping and testing are done in this phase. In the implementation phase, the practical
embedding of the ideas is developed and executed.

3.2 A review of the implementation of HCD in organizations

Little is written on approaches and challenges to implementing HCD in organizations, whereas more commercially used
forms of design, such as user experience design or service design, are more extensively discussed by design agencies.
The different design methodologies can be expected to have similar challenges in an organizational context and benefit
from similar approaches in implementation. Therefore, the implementation of a wide variety of design practices is taken
as an example for the implementation of Human-Centered Design in organizations that develop data-and digital tools
for humanitarian response.

One relevant example for 510 is given by NN group (2020). NN group discusses several approaches to convince
companies of the value of service blueprinting, a design methodology in service design. The strategy has three steps:
include stakeholders early and often, track success and use it as evidence and translate user needs into business impact
(NNGroup, 2020).

Metzker and Offergeld (2001) have developed a detailed method to implement Human-Centered Design in industrial
software development organizations. In this paper, the term HCD applies to usability design. The method for
implementation consists of two models: the HCD Reference Model and the Introduction-Establishment-Improvement
(IEI) Model (Figure 6). The HCD reference model is developed in order to create a collection of established HCD activities
from different HCD approaches.

The Introduction-Establishment-Improvement model provides a stepwise methodology to implement HCD activities

within software development. The methodology includes mapping out the existing software development process and
selecting HCD methodologies fitting to that current process. Step 4 and 5 are the implementation of the HCD methods,
the development of reusable artifacts, best practices and tools and the iterative improvement of these documentation
materials.

1 2 3 Select HCD activities from 4 Utilize HCD methods. 5

Elicit and organize
Analyze the the reference model. Support development team
Analyze the HCD reusable artifacts
software integrate the selected by providing reusable
activities practiced. and best practices
development activities to the software artefacts, documented best concerning HCD
process. development process in use. practices and tools. activities.

Figure 6. The Introduction-Establishment-Improvement model (adapted from Metzker & Offergeld, 2001)

The methodologies used by Metzker and Offergeld (2001) in the HCD reference model are much more limited than the
possible HCD methodologies from the IDEO toolkit (IDEO.org, 2015) and uses a much more limited definition of HCD
than IDEO. However, the implementation steps from the IEI model can be used in the case of 510.

17 Part 1: Discover
3.2.1 Challenges in implementing HCD in organizations
Several challenges in implementing design thinking in organizations are found.

Firstly, in a review on the implementation of design thinking across several organizations it became clear that the design
team needs to find a niche that is not covered in existing programs (Dunne, 2018). As a design team, naming the team the
“customer experience” team can undermine current customer experience activities. Additionally, Dunne describes how
organizations can have difficulty with the explorative and iterative nature of design practices.

“The freewheeling nature of design, with its emphasis on qualitative research, storytelling,
and iteration, can be a difficult fit in cultures that prioritize certainty, quantification, and
efficiency.” – Dunne (2018)

Another common misconception about interface design is that it is an activity that can be applied to an otherwise finished
product. However, in order to have a significant and sustainable impact with interface design, design activities need to be
embedded throughout the entire development workflow (Wallach & Scholz, 2012).

A difficulty that is often mentioned in literature is the structure of teams. The design team is often a separate entity, which
causes high autonomy but also makes it more difficult to implement ideas. Dunne (2018) describes a consideration in
the structure of teams when implementing design thinking in organizations: By integrating design methods in cross-
functional project teams and making designers part of the project team, design thinking might be applied more uniformly
throughout the project. However, designers are also more easily caught in day-to-day operating procedures and are
discouraged to think outside incremental improvements. Interesting is the clear preference in two maturity assessments:
both in the Koos Maturity model for service design (Corsten & Prick, 2019) and the NNGroup service design maturity
model (J. Nielsen, 2006b), integrated cross functional teams are one of the last steps towards reaching design maturity
in an organization.

Another challenge that is mentioned is that design teams have a tendency towards developing incremental changes in
design, such as usability, in order to generate easy wins that increase their credibility (Dunne, 2018). This incremental
tendency decreases the chance of generating disruptive innovation.  

18
 4. Organizational analysis 510

4.1 Understanding the 510 team

510 is the data team of the Netherlands Red Cross (NLRC) and supports NLRC in emergency support. However, in its
management, projects and product development, 510 works mostly independently. For its projects 510 raises funding
from external partners like the IKEA foundation. Additionally 510 has a different workflow and management style from the
rest of the NLRC. 510 can be considered a sub-organization rather than a team within the NLRC. In order to understand
510, an organizational analysis is done.

4.1.1 Description 510 products, services, customers and locations

In order to get a general understanding of 510, first a description of the products and services, the projects, the stakeholders
and the geographical scope is given.

4.1.1.1 Products and services

510 makes data and digital products that enable aid workers, decision makers and people affected to better prepare for
and cope with disasters and crises by improving the speed, quality and cost-effectiveness of humanitarian aid (taken from
the 510 purpose and mission which is further discussed in paragraph 4.1.2.2). The data- and digital products consist of
databases, models and software tools.

It should be noted that 510 has a wider range of activities next to the development of products. 510 provides services
such as building data capacity within a Red Cross-National Society and providing assistance in disaster response. This
thesis focuses on the data- and digital products that 510 develops.

Disaster aid can be divided into several phases. The phases that 510 uses are: (1) community preparedness for disasters
in disaster-prone areas, (2) early warning activities once a disaster is expected, (3) disaster response once the disaster
has happened and (4) recovery after the immediate response. The phases flow into each-other and act as a cycle where
the last phase (recovery) is continued again by the first phase (preparedness). The products of 510 are made for different
phases across the disaster cycle. Table 1 shows the products that 510 makes and their placement along the disaster
phases and the product abbreviations.

Table 1. Overview of products of 510 within the different disaster phases

Digital risk assessment Predicitve impact analytics Emergency data support Direct digital aid
Community Reforestation Impact Epidemic Impact Surge Automated Population 121 Wegwijzer
Risk Assessment Risk Based Information Damage movement (CBA)
Assessment (IA) Assessment Forecast Management Assessment (PM)
(CRA) (ERA) (IBF) (SIMS) (ADA)

4.1.1.2 Projects
510 works on a project-basis for most of its activities. For their projects, 510 works with funding from numerous partners
in order to finance the activities. A project can be either the development of a new product or the employment of an
existing product in a new country. Often projects take multiple years to complete.

In Table 2, the columns with country names represent the projects per product. For every project, agreements with the
donor are made that determine the project. Projects can have a time-span from months to years. From Table 2 it is clear
that especially the Community Risk Assessment and Impact Based Forecast product have resulted in multiple projects.

Table 2. 510 funded projects within the 510 products

Digital risk assessment Predicitve impact analytics Emergency data Direct digital aid
support
CRA Reforestation IA ERA IBF SIMS ADA PM CBA Wegwijzer
Philippines, Ecuador, Mali, Philippines, IARP (Kenya, Malawi, Netherlands
Malawi, Peru, Uganda, Mali Ethiopia, Kenya,
Zambia, Burundi, Ethiopia, Uganda) Ethiopia,
Haiti, Kenya, Mozambique, Peru, Zambia, Ukraine,
Nepal, Benin, Sri Lanka, Ecuador, Mali, Sint
Vietnam Zimbabwe Maarten

19 Part 1: Discover
4.1.1.3 Stakeholders
Most projects involve a large number of stakeholders, i.e. donors, partners that collaborate in the project, data providers,
local weather stations and universities, the Red Cross Climate Center, Red Cross-National Societies and the end-user of the
product (Figure 7). The exact stakeholders, the extent to which they are involved in the project and their responsibilities
within the project differs per project.

people affected

aid worker in aid worker in

aid worker in field 510
branch office headquarters

local Red Cross the Netherlands

National Society Red Cross

local partner partner National

NGO’s Societies

hydro-metereo- International
local universities partner NGO’s RC/RC Climate
logical stations Federation Red
Centre
Cross

local government donors

Figure 7. Stakeholder overview

4.1.1.4 Geographical scope

The products of 510 are implemented all over the world in low- and middle-income countries. Most projects are in Africa
and Asia, but there are projects in Europe and South-America as well. The market of 510 consists of Red Cross National
Societies and their local partners. Within the 4 years that the team has been setup, 510 has worked in over 30 different
countries.

4.1.2 McKinsey 7S
In order to achieve a comprehensive and structured analysis of the organization, the 7S model by McKinsey is applied.

4.1.2.1 Shared values

The shared values of 510 are stated in their core values. All activities done within 510 should take these core values into
account.

The core values of 510 are:

We prioritise disasters
We engage local and scale global
We design products and services based on needs
We embrace volunteerism
We build evidence
We use data responsibly
We connect digitally for sustainability

Three core values, highlighted in dark grey, can be directly linked to Human-Centered Design. ‘We engage local and scale
global’ shows that products designed for a certain context are then adapted and applied across the globe. ‘We design
products and services based on needs’ is the main value that can be linked to HCD. It means that all products should be
built from a user need rather than only from technological exploration. ‘We build evidence’ shows that assumptions need
to be tested throughout the process.

20
4.1.2.2 Strategy
The strategy can be found through the purpose statement and the mission statement of 510.
The purpose of 510 is:

Improve the speed, quality and cost-effectiveness of humanitarian aid by using data &
digital products.

The mission statement of 510 is:

Shape the future of humanitarian aid by converting data into understanding, put it in
the hands of aid workers, decision-makers and people affected, so that they can better
prepare for and cope with disasters and crises.

The purpose of 510 shows the goal (improving humanitarian aid) and the way this is done, using data and digital products.
The mission shows how 510 will fulfill their purpose. The mission statement is human-focused and explains the human
benefit aimed for by the team.

4.1.2.3 Structure
Hussey (1984) describes a number of organization structures. 510 has a combination between a project-based structure
and a team-based structure. Whereas several teams of volunteers are formed around certain activities, such as geospatial
data analysis or Human-Centered Design, interdisciplinary project teams are formed as well.

Figure 8 shows a visual overview of the organisational structure. As described in paragraph 4.1.1.2., a project is either the
development of a new product for a country, or it is the application of an existing product to a new country. Projects are
initiated by the strategic lead, who writes a proposal. Once the funding is approved, a project manager is assigned. For
products with multiple projects, a product manager is assigned. Product- and project managers get support from the
product staff in the development of the product for the specific country. Not every product has a product manager that
oversees the projects in which the product is applied. This means that projects for one product might have completely
different teams per project.

core staff

product
community engagement and staff
volunteer management
product manager IBF
communications,
relations and HCD lead
lead product manager 121

data responsibility lead

strategic lead
product manager ERA and ADA

scientific lead
operational lead
front-end and back-end developer

scrum master

project back-end developer

staff

project manager
hydrologist
IARP

Figure 8. 510 organizational structure

4.1.2.4 Skills
For an innovative data-driven initiative, 510 is in a unique situation as it is part of the Netherlands Red Cross (NLRC).
NLRC is part of the global Red Cross Red Crescent Movement and led by the International Federation Red Cross, which
is the largest humanitarian organization in the world. This provides 510 two main advantages: (1) Firstly, it means 510
is part of an international movement with 192 Red Cross and Red Crescent National Societies (NS) across the world.
510 collaborates with these NS in order to develop, test and implement their products. (2) Additionally, 510 has both
the reputation of a fast-moving technical startup and the trustworthy reputation of a large partner like NLRC. This
combination gives competitive advantage over other companies developing response technology and help engage both
partner organizations and volunteers.

21 Part 1: Discover
4.1.2.5 Staff
510 has a highly motivated staff. Most of the staff base works on several projects and have many different responsibilities.
Between the projects, the role of certain functions such as ‘project manager’ can vary. The responsibilities might depend
on the interpretation of the people involved, the project setup and the partners involved. This diversity can create unclarity
in responsibilities.

510 works with many volunteers and has a 1:5 staff-volunteer ratio. This is similar to the way of working in the entire Red
Cross movement, as the movement works with a large number of volunteers across all their National Societies. However,
because 510 is the data department of NLRC, staff and volunteers often have a background in data analysis (including GIS
analysis), hydrology and software development.

6.1.2.6 Management Style

There is very little hierarchy in 510. In the beginning of each day, all volunteers and staff members do a standup to discuss
what they are going to work on that day. Every volunteer has direct contact possibilities with every staff member and
activities like drinks are inclusive to all volunteers.

A great example of the open management style are the ideation requests for new product possibilities, posted in the
general communication channel. Everyone involved in the team has access to it and everyone is requested to post any
ideas they have for new products.

6.1.2.7 System
Many internal processes within 510 are not predefined or not strict. Between two projects for the same type of products
in two different countries, the approach, goals and documentation might be different depending on e.g. different donor’s
preferences. The team has hired a scrum-master to create more consistency in the product development. The limited
existing structure and the shift to a different product development method means that activities and responsibilities are
subjective to change.

The most important software used for communication is Microsoft teams, which holds all documentation for the different
projects and serves as a collaboration and communication tool.

4.2 Conclusion 510 organizational analysis

From the points discussed in the organizational analysis, several points can be considered to have an influence on the
implementation of an HCD approach in 510.

From the 7S analysis it is clear that enablers of HCD (factors that facilitate the use of HCD) within 510 are the organizational
values, the company strategy, the open management style and the highly flexible staff and volunteers. Understanding the
user and their context can indeed be challenging for an organization as 510: Whereas the projects are done all over the
world, the 510 staff mostly work from the Netherlands. Additionally, the projects and products cover a very wide variety
of disasters, countries, contexts, stakeholders and users. These varying topics makes it even more difficult to get familiar
with the user and the context. Perhaps because of these difficulties, 510 supports a human-centered approach in the
sense that their organizational values and company strategy underpin human-centered values. This shows openness and
provides support in the implementation of HCD. Additionally, the company culture with a very open management style
and the highly flexible staff and volunteers are likely to be open to embed HCD approaches in their product development.

Despite the open management and staff, the organizational analysis also shows possible challenges. Most of the staff,
including project leads, have a technical background and a technical focus in their job and might therefor prioritize
technical aspects. Next, the funded project structure with predefined goals and deliverables makes it difficult to pivot
within projects or to change a project to have a Human-Centered Design approach. Additionally, because of the varying
projects setups, the project workflow differs per project. On top of that, currently scrum methodology is being setup
within 510. These differences between projects make it difficult to link HCD practices to the existing workflow. However,
it also provides more possibilities in implementing HCD as there is no strict workflow in place.

22
 5. Maturity analysis HCD in 510

In order to understand the current practices of HCD at 510 an analysis of the HCD team is made. The HCD team and
methodologies of 510 are assessed using service design maturity model by Koos Service Design (Corsten, 2019). The
factors assessed are: ‘people and resources’, ‘tools and capabilities’, ‘organizational structure and roles’ and ‘metrics and
deliverables’. Although the model is about service design, for 510 we will discuss the Human-Centered Design activities.

5.1 People and resources

The extent to which people, budget, time and facilities are available and dedicated to service design
activities. - Corsten (2019)

Within 510, there are no full-time staff members for HCD. Instead, there are two 510 staff members who use part of their
time to do HCD activities next to their main responsibilities. This is not an anomaly: within 510, almost every staff member
is responsible for multiple projects or tasks (as described in paragraph 4.1.2.5).

Additional to the HCD staff members, there is a varying number of HCD volunteers available for a varying number of days
per week. An overview of HCD volunteers is shown in Table 3. These volunteers might be thesis students, intern students
or volunteering students, just-graduated students or working designers. On average volunteers are available 1 day a week
and stay for around 4 months.

Table 3. 510 Human-Centered Design volunteers overview

Name Type of Start End Days per Background Main activities

volunteer week
Vinay Student July ‘18 Jan ‘19 1 Industrial Design XD Design
Engineering
Pauline Job-searching July ‘19 Oct ‘20 1 Industrial Design Work Methodology
development
Rosa Thesis July ‘19 n.a. 2,5 Strategic Product COD, Methodology
Design development
Hardik Job-searching/ Oct ‘19 Jan ‘20 1 Strategic Product Persona journey,
working Design PESTEL
Ruth Job-searching/ Oct ‘19 June ‘20 1 Human-technology Persona journey, COD
working interaction
Shweta Job-searching Nov ‘19 Jan ‘20 0-1 everything
Priyanka Student Jan ‘20 n.a. 1 Strategic Product Wireframing
Design
Miranda Working n.a. n.a. Freelance UX copywriter UX copywriting

Because of their limited number of available hours per week and the limited timespan of involvement with 510, volunteers
do not have a lot of time to be trained in HCD activities. NNgroup describe having a capable UX team as at least adequate
coverage on interaction design, visual design, content strategy, writing, information architecture and research within the
team. Within the small team of 510 staff and the ever-changing volunteers, building up the human capabilities described
by the NNgroup is difficult. The volunteers who come in are mostly students with a relevant design background but
limited work experience and no expertise.

The budget for HCD per project is growing but still limited. For multiple year projects there might be a number of days
available for HCD activities. Because of this, the two staff members who are trying to implement HCD in 510 often work
extra hours in order to do so. This lack of hours can be partly explained by the delay of budgeted projects. A proposal for
the financial plan of a project is made before the project has received funding. During the timespan of a multiple-year
project, new activities for HCD are difficult to implement later in the financial plan. A project might be started before
HCD was started. This makes it difficult to implement HCD methods in the budget of the project and it makes it difficult
to implement the HCD methods in the suitable timing. Partly because of this, the hours that are budgeted for HCD are
sometimes planned in a way that undermines HCD methods, which will be further explained in sub-chapter 5.3.

23 Part 1: Discover
5.2 Tools and capabilities
The extent to which service design methodologies and tools are applied within the organization and
the level of required skills and capabilities that are needed to apply service design. - Corsten (2019)

There are 6 HCD methodologies that are being developed and used in 510. An overview of the methodologies and the
underlying activities is provided in Table 4.
 
Table 4. HCD methodologies and their steps

Method Step 1 Step 2 Step 3 Step 4 Step 5

Find data and

PESTEL analysis Iterate
fill in

Value Business Environment

Strategy sheets Goal sheets Ad libs
proposition model canvas map

Codesign Clustering
Codesign Transcribing
interview insights

Persona Establishing Establishing Fill in with

Fill in topline
journey timeline persona types quotes

Paper
Prototyping XD prototyping XD wireframe MVP
prototyping

Paper
XD prototype XD wireframe
User testing prototype MVP testing
testing testing
testing

The PESTEL analysis is a widely adopted methodology, used to understand the broader (in this case, country-wide)
context, considering Political, Economic, Social, Technological, Environmental and Legal aspects.

The strategy sheets are adapted from the tools by the company Strategyzer, who make materials that help organizations
understand the goal, value and the context of their product or service.

The codesigns are part interview and part ideation session. They are done with numerous people involved in 510 projects
but all have the same setup: The first part is an ice breaker and gives an understanding of the participants digital literacy.
The second part asks for a experience in disaster response (if possible, relevant to the product that is being developed)
and asks the participant to explain this experience. In the third part the participant is asked to imagine, explain and draw
out a digital tool that could help them in the disaster experience they described earlier.

The Persona journey is a combination of the Persona method and the Customer Journey method, combining the user
characteristics and their journey across time into one analysis.

Prototyping and user testing are done iteratively. The prototype starts with simple drawings and notes, then moves into
an XD prototype and later moves into a XD wireframe and finally into a Minimal Viable Product (MVP). The goal of all
these prototypes is to be used for user-testing in order to gather feedback before moving into the next step.

As is clear from Figure 9, some of the tools are quite mature and have already been used in multiple projects. These
methods include the strategy sheets and the codesign methodology. Other methodologies are still being set up and have
only been used in one or two projects, such as the Persona Journey and the user testing methodologies.

24
 Strategy Persona User
PESTEL Codesign Prototyping
Sheets Journey Testing

CRA
ERA
IBF
SIMS
ADA
POP
CBA
Wegwijzer

HCD method not completed for the product

HCD method completed for at least one
project (country) of the product

Figure 9. Overview products (as described in paragraph Table 1) and HCD activities performed

 
5.3 Organizational structure and systems
The extent to which the organizational structure allows and facilitates multidisciplinary service design
work and the assigned roles that are needed to do so. - Corsten (2019)

As described in paragraph 4.1.2.3, 510 has a combination of project based and a team-based structure. The HCD volunteers
work in a team-based structure. The most important touchpoint between the HCD team and activities and the rest of 510
is one of the HCD staff members, who divides tasks among HCD volunteers and communicates findings to the rest of 510.

The project-based structure of work of 510 generates some difficulties for HCD. Whereas there is a number of
methodologies defined, how these methodologies are applied still varies across projects. Because of the long timespan
of certain projects and the very young HCD team, HCD methodologies were applied after projects were already running
for years. This has resulted in several difficulties in the application of HCD methodologies:

Timing of strategy sheets

In many older projects the strategy sheets are being used relatively late in the project. This means that a large part of the
project might have already occurred without clear human-centered project goals.

Timing of codesigns
Codesigns were first only done once the product was already quite far in development. In a number of projects, the front-
and back-end designs had already started before codesigns were conducted and a prototype was created or tested.

Iterative workflow
User testing is starting to be implemented in the workflow. Currently, it is not clear to everyone in 510 that user tests are
supposed to be part of an iterative process. Because of this, user tests are budgeted to gather feedback when there are
no hours left for development in order to incorporate the feedback.

Documentation
The limited number of hours available for HCD activities means that the documentation is often less important than
performing the activity. For example, the HCD team might choose to do 2 extra interviews rather than transcribe one if
there are 2 days to work on HCD activities for a project. This need for prioritization of activities means that the availability
of documentation of previous work varies. Additionally, depending on the donor preferences documentation will vary
based on what is needed for communication to donors.

25 Part 1: Discover
 5.4 Metrics and deliverables
The extent to which metrics and KPIs are in place and being pushed to stimulate and facilitate
service design, next to the shape and form that deliverables of service design initiatives have.
- Corsten (2019)

The metrics vary per projects based on donor requests, and therefore do not necessarily include human-centered metrics.
Deliverables of HCD are already seen across a wide variety of projects including: codesign transcripts, persona journeys
and user-interface designs.

5.5 Maturity scores

The Koos service design maturity analysis helps classify the maturity into one of 5 stages: explore, prove, scale, integrate
or thrive. Based on the description per stage of the four maturity dimensions (Table 5 and the corresponding Figure 10),
it can be concluded that HCD within 510 is on average in between the prove and scale stages of design maturity;
• People and Resources: Two staff members are able to write some hours in order to do design as well as take on a
number of volunteers in order to support in design activities. In the flexible workspaces, rooms are booked for some
days to work with the entire HCD team. However, the HCD activities are mostly limited to the HCD team. Therefore,
people and resources can be said to be in the scale phase.
• Tools and capabilities: The tools and capabilities are somewhere in between the prove and the scale phase. As the
staff within the organization is only around 15 people, a large design department would not be feasible. Instead,
some sort of design team is formed with the 2 part-time staff members and the volunteers. However, the capabilities
are not spreading outside this initial team and the tools are not yet fully developed.
• Organizational structure: Although the organization does not have a strict hierarchy and everyone staff member
or volunteer is in direct contact with the rest of the organization, at the moment the HCD team is operating very
separately from the other departments. Additionally, there are no clear designated responsibilities for the design
department. However, as is clear from Figure 9 a lot of HCD initiatives are already taking place. Therefor, the
organizational structure is assessed to the “prove” fase.
• Metrics and deliverables: The metrics and deliverables within 510 score in between the prove and the scale phase.
Whereas quite a lot of results are already produced, the same outputs are not created for every project and there are
no predefined deliverables or human-centric KPI’s formulated for the design department.

Table 5. Elaborated Service-design maturity ranking with the maturity of HCD for 510 in yellow (Adapted from Corsten & Prick, 2019)

People and resources Tools and Capabilities Organizational Structure Metrics and Deliverables
Individual service design Service design knowledge Traditional siloed Customer centric metrics and
enthusiasts are scattered across and expertise is self-retreived structure, with no assigned deliverables are non-existent.
Explore

the organization in which no (through books / articles / responsibilities on service

budget, time and facilities are trainings), but scattered across design or customer
dedicated to service design. the organization. experience.
First project team is formed Existing (adjacent) capabilities The first multidisciplinary Deliverables of first project
by enthusiasts and / or design are brought together from team is being formed and being created, like a customer
agency. There is missing different people. Organizations the first service design journey map. First measurable
Prove

budget and management buy- tend to buy capabilities initiatives are taking place results are often lacking.
in for service design initiatives. through hiring a design agency. regardless of structure.
More people get involved and Capabilities are spreading Interference with the Project results are becoming
incidental budgets are created outside of the initial team. First existing way of working increasingly apparent. First
for service design projects. employees start to specialise is felt. Silos start to suffer customer-centric KPIs are
Scale

Rooms and facilities are getting and CX / SD departments are under the demands of set specifically for the CX
hijacked for service design. being formed. multidisciplinary teams. department.
The majority of people is Unified capabilities, The siloed structure is C-suite is committed to CX and
engaged with service design. methodology and language broken down and design- SD and may even assign a Chief
Dedicated service design around service design, led foundation is being Design Officer. Customer-centric
Integrate

budgets are now in place. as capabilities are being laid. New roles emerge and KPI’s go company wide.
decentralised within each team. are being assigned in each
team.
The entire organization is Strict methodology is set Organizational structure Each initiative is tied to
involved ins ervice design. loose and experimentation allows for close c-creation customer-centric metrics and
Everyone is aware that all is stimulated, as the design of service experience in deliverables. Customer centricity
Thrive

decisions may impact customer mindset is ingrained in the multidisciplinary teams. has become an important KPI
experience. company culture. for the entire C-suite.

26
 Figure 10. Maturity analysis of 510 adapted from Koos Service Design (Corsten & Prick, 2019) further explained in Table 5

5.6 Conclusion maturity analysis of HCD

From the analysis, it is clear that a lot has already been done for the implementation of HCD methods in a short time and
with limited budget. Several methods have been developed and applied across projects and almost every project that
was started recently has some HCD activities. However, it is also clear there still is development work to be done for HCD
for 510.

Firstly, there is a very motivated HCD staff workforce with a lot of relevant experience but very little time to spend
on HCD activities. Then there is a group of volunteers with little experience that varies in size and is inconsistent in
availability. With the varying human-resources, capabilities that can be built up are not human-resources but rather
structured methodologies that can be applied both by design volunteers and non-design staff. However, the HCD tools
are not yet fully developed. There is very limited time available outside project budget in order to develop structured
HCD methods. Instead, the hours available are taken to execute and employ the available methods. The lack of time also
limits extensive documentation, which could be used to communicate methods and results and prove the effectiveness
of the tools. Additionally, HCD methods are implemented varyingly across projects. There are no set responsibilities or
deliverables for the HCD team within a project. The varying project deliverables and deliverable formats make it difficult
to structurally document HCD activities.

From the maturity dimensions, the next steps for the 510 HCD team are to involve more people in HCD activities, further
develop the HCD methodologies and structurally apply the methodologies to 510 projects while ensuring suitable
budgets are in place. However, the size of the organization and the use of a changing volunteer base makes it difficult to
build up human resources for HCD specifically as is described in the maturity analysis table.

27 Part 1: Discover
 6. Interviews on HCD in 510

6.1 510 staff interviews

From the staff interviews, both enablers and challenges to implementing a Human-Centered Design approach in 510 are
found, which are described in the following paragraphs. In the quotes from the interviews, names of people, countries or
organisations are replaced by a description such as - name - or - country -.

6.1.1 Interview insights

6.1.1.1 Unclear distinction between scientific or practical project

“
We have a small number of projects which are the research funds, and then the question can be
more research based. That it is just a research question, that that’s why we want to work with,
for example, a PhD student. So then there is still consultation with the National Society, but less
thorough than with an operational project. – 510_Staff_P3

(so that is a research question based on the data available?) Yes, that’s right. But it also comes from
the end-user. The end-user always prefers to have the most detailed data or at the level at which
they need to do an intervention. So, it also comes from the end-user. – 510_Staff_P3

510 has a distinction between scientific (research) and product development (operational) projects. Within scientific
projects the aim is to generate knowledge regarding new data or technology. In projects with a scientific scope, there
is less contact with the users. However, the research question is often based on a need that is known from experience.

“
The problem that we are solving was given at the beginning, it was a very broad question: can we
forecast epidemics? – 510_Staff_P2

The participants example of a project goal is: can we forecast epidemics? This kind of research question allows to explore
data analysis and model building without an already pinned down user or application. The question is aimed at exploration
of the possibilities of technological innovation and not directly at development of a product.

“
We are starting HCD this week... So far, the project was more focused on the scientific part; can we
forecast epidemics, can we understand the risk of epidemics? Now we want to start to turn it into a
product. Timewise we are halfway in the project. – 510_Staff_P2

In the same project example as the previous quote, the project is later turned into a product development project. HCD
is entered into the project halfway through the project, when this change is made.

“
And then it is also the question – when do you call something research and when is it just a project.
– 510_Staff_P3

(talking about a scientific project that has moved into a practical project :) So far, there was a total
disregard for the user perspective. So far it was very much top down (from 510). We are going to
forecast epidemic; we are going to do it in this way. – 510_Staff_P2

There is no clear distinction between a scientific and a product development project. Instead, scientific projects can
later turn into practical projects. HCD is introduced once an initial model has been developed and is being turned into
a product. This means that the objectives set at the start of the project focus on scientific exploration (“can we forecast
epidemics?”). Because the objectives at the start of a project are scientific, there is a focus on the technical possibilities
rather than the human-need within the development of the technology. However, the technology is intended to serve as
the basis for a product which does intend to fulfill a human need.

6.1.1.2 Aim to sell the current products

“
If they (the National Society) indicate that they want- or don’t want a dashboard. If they don’t want
a dashboard then we take it out of the proposition. – 510_Staff_P3

I think the project was initially more we are going to do what we want and then we are going to sell
it. We are going to see who is interested. 510_Staff_P2

That is what we already have to offer and so we start with that. – 510_Staff_P3

510 has products that are developed for certain countries from which the basis is a suitable product for other countries
as well. Developing these existing products for new countries is desirable from an organizational perspective as this will
take less time and effort to develop and has lower risk.

28
“
But we are not going to, like in – Country Y -, make a dashboard for -Country X- . There was no
budget for that at the moment. And that is not a request from – Country X – Red Cross. Of course,
in a while I might try to show them the dashboard, and ask if it would be useful for them. But that
is also a bit of a technology-push, of course.
– 510-Staff_P3

The participant has described understanding and discussing with users before writing the proposal, and iteratively
collaborating with National Societies. However, in practice often the communication methods can hinder a human-
centered approach. The above described method of presenting a possible technology to the end-user without a need
for it being expressed might, as the participant mentions himself, create a bias towards this technology. This can make it
more difficult to find out the real needs of the users.

6.1.1.3 Time and budget contraint

“
But at the same time, because of the time limit right before tenders, sometimes only a short week,
you can’t ask questions in a scientific way about their decision-making processes. So you need to do
it more quickly. – 510_Staff_P3

Because we of course also have, the fourth option, is more the codesign sessions. But that is often if
we already have a project running and then we build it into the budget to do the codesign sessions.
So, then you actually postpone it a bit, so to say. Or we do some assumptions, and based on that
we write the project-proposal. And then if we are doing the project, we are going to start with a
codesign session to really elaborate on things, so that is also possible. – 510_Staff_P3

One of the most common challenges to implementing additional research methodologies are time and budget constraints.
In the beginning of a project, there is limited time and budget so there is no possibility to do extensive interviews or
codesigns. Therefore, these are only applied after the project proposal is already made and serves as a contract between
the donors and 510 that determines objectives and deliverables.

“
I think, for example, with – hydrometeorological center X- I’d rather they started collaborating with
them in a very early stadium so they could have seen from the beginning how we built our model
and then perhaps they had shared more with us as well. But that is also a budget question, because
it also includes having a budget for such a stakeholder. Because a stakeholder is not going to say:
‘O, yes I’ll work together with you’. If we don’t have a budget they won’t, so in the begin phase if
there are limited budgets then we have to give up some budget, as well as – partner National Society
Red Cross- in order to include such a stakeholder. So, then you can’t only say: ‘let’s do codesigns’,
if there isn’t a budget for such stakeholders. – 510_Staff_P3

Budget constraints do not only influence the internal development, but additionally can limit collaboration options.
Some partners have such high interest in the project that they want to be involved without monetary compensation,
for example because they are interested in the model, or because they are willing to share data if they get other data in
return. However, for most partners a monetary contribution is needed in order to engage them in the project. This means
that including additional partners requires cutting parts of the budget of the current project partners.

6.1.1.4 Broad definition of the user

“
(who is the end-user?) One is just the donor, the one who pays us. We need to justify what we are
doing to them. Next to that end-user for us is, depending a bit on the project, most of the time
the National Society Red Cross of a country. They then serve beneficiaries, or the people who are
affected by disaster. But the most direct end-user is a Red Cross-National Society. Because we hope
that they will use our tools and methods. – 510_Staff_P3

There are very wide descriptions of user groups, such as ‘aid workers in field’ or ‘aid worker in headquarters’. Many of
the products made by 510 could be potentially be used by a very wide variety of people involved in humanitarian action.
The products are often made for the potential use of many of these user groups. Because of this, most of the product
development process is done with very broad user definitions.

“
(when in the project do you want this information?) For the adoption of the tool we noticed that, yes,
we try to have the end-user there from an as early as possible stadium. Still, we also noticed that
sometimes we get resistance from, in this case, our – National Society Red Cross – contact person
who is in-country. Because they say that if we involve the end-user too early, then you need to
think about people in an operational center who are the ones behind big screens and see typhoons
coming in, they are deep in operation. So, if we come too early with our innovation then it can also
give resistance, or they might not have any time. Or it could be that they want to start using it right
away, even though it is not ready yet. So, we need to find some kind of middle ground in that, at
which moment do we involve them. – 510_Staff_P3

The above quote shows a more detailed description of the user (the people working in the operational center) which could
be an example of a more suitable user definition for an HCD approach. However, even if the end-user is determined, they

29 Part 1: Discover
might not be included in development from the start. Whereas it can be positive for adoption of the tool, it would also
be a large request to make as it will take a lot of time, which might result in negative opinion. Additionally, the proposed
end-user might get high-expectations regarding functionalities and when the product might be available for use.

6.1.1.5 Many (indirect) sources of human-centered information

“
There is also indirect feedback, from partners who have experience with humanitarian action in the
field and have things to say. – 510_Staff_P1

You also get this information from the stakeholders that you collaborate with - National Society Red
Cross X - and - National Society Red Cross Y – 510_Staff_P4

For these kinds of problems, the external NGO’s are very useful – they already have the local people.
In that sense there are partners of ours who research for us what we want to know when we make
such products. – 510_Staff_P1

(participant with years of experience): In that sense I also have some feeling of what might be useful
to people. So that is another way to understand the context. – 510_Staff_P3

From these quotes it is clear that there already are many sources used to gather information about the user, stakeholders,
needs, tasks and the context. These include partner NGO’s, local NGO’s, collaborative NS, the local NS, local NLRC
delegates or partner NS delegates and personal experience in disaster response.

“
I hear about this in meetings, discussions. I took notes but we don’t really have a document. Also,
because -country- is a sensitive political landscape, so you get lots of information over the phone
and very little in formal documents. – 510_Staff_P2

The above quote shows that the indirect sources of information do not always provide information in a document format
that can be used and further communicated. The information might not be documented or there might be other reasons
why the information is not shared. Political sensitivity can for example hinder the documentation of accurate disaster
response activities, if these differ from the official protocol.

“
I am thinking if we ever got a real sort of surprise out of an HCD session in the sense of: ‘ooh yeah
we did not think that at all’. I can’t remember it that extreme. But perhaps with 121 it was like that.
Because it is more of a real product. – 510_Staff_P3

It already happens a lot, so it thinks we need to assess for ourselves what exactly we mean with
Human-Centered Design. Because for example, the climate center organizes stakeholder groups and
brings many parties together. So, a part of the HCD is already done by other stakeholders outside
of 510 so we don’t have to do that ourselves. So, I think we need to find the right moment in which
we can do our part HCD that aligns with, mostly, what the climate center already did, or another
partner National Society. – 510_Staff_P3

It is not yet clear what the exact contribution of HCD is within this large number of information sources. In order to
allocate resources effectively, the role of HCD should be complementary to the current information sources.

6.1.1.6 The start of an iterative approach

“
-National Society Red Cross- also has a delegate there who is forecast-based financing advisor. He
has been working on 3 years to get FbF starting there, so he has been doing some kind of ongoing
codesign every day for 3 years. – 510_Staff_P3

In addition, we have continuous discussion. So, in the project we are doing in – Country -, we
discuss with the people in – Country – every two weeks to discuss what we did. They also often get
new insights. So, then we change our deliverable a bit. So, that is really a very iterative process.
– 510_Staff_P3

(talking about what type of information he gets from project partners): That is basically a continual
codesign session. They say, we need a list to go to communities with that can be printed. (...) The
communities just work like that. That is information that could come from a codesign but in this case
it comes from there. – 510_Staff_P5

Practical projects mostly have a close collaboration with the local National Society that is intended to implement the
developed product. In some cases, even delegates are located in project countries in order to facilitate the process. So,
an collaborative approach between the different project partners (those who contribute to the project) is an embedded
part of the process.

30
6.1.1.7 Unclarity regarding HCD

“
At the moment I still feel that one on hand, I say and -staff member- says we should really put HCD
systematically, but then it is still run a bit as an experiment. A yeah, we can do ... Yeah it would be
cool to do it there. But that is not... You know what I mean? – 510_Staff_P2

The participant above expresses an understanding of the need for HCD. The participant is positive about embedding
HCD into 510 projects. However, the participant does not have a clear overview of the HCD activities, their goals, or
their outputs. From the analysis in sub-chapter 5.2 it is clear that this is partly true: HCD does not have a completely
developed workflow. However, what is already developed is not completely clear to 510 staff. This can make HCD feel as
an experiment rather than one of the building blocks of successful design.

“
I do believe that HCD should be an important ingredient in every project that we do. But we have
many projects. (…) So, if you really put HCD in each project, those are many hours of volunteer time
or student time or -staff member-s time or -staff member-s time, or whoever does it (…) but this is
time. So, we need more structure we need to allocate this time more systematically. – 510_Staff_P2

Additionally, there is no clear hour allocation for HCD activities which again hinders the incorporation of HCD in 510
product development. It also currently means that there is a lot of time not accounted for in project planning that does
go into HCD activities.

“
I think the HCD part should be more structured. So, at the moment the dynamics is: all the project
managers drop a message to -staff member-. (…) -staff member- talks to all of you guys and
volunteers and organizes things. – 510_Staff_P2

Often it comes more from the initiative of -staff member-. – 510_Staff_P2

Currently, one staff member acts as the connection between project staff and the HCD volunteers. This one person often
initiates HCD activities into projects, communicates the tasks to the HCD volunteers and presents all findings from HCD
activities to the project staff. This shows that the HCD approach is not yet truly embedded.’

6.1.1.8 HCD for intangible products

“
What perhaps is an important difference- I can imagine – you are really from design. Some of the
projects we do don’t deliver physical products, such as a dashboard or a tool. A product could also
just be a model. Or an analysis of a dataset. That is ofcourse less... You would still need some user
requirements, but not user requirements of how it should look. – 510_Staff_P3

It needs to be clear that Human-Centered Design, although it is called design, can cover a range of different products and
services. Products do not have to be visual in order to benefit from design activities. Examples need to be given in order
to understand what kind of user requirements can be made for a model.

6.1.2 Conclusion 510 staff interviews

The interviews show that the 510 staff supports the implementation of HCD; they are open to bringing in new approaches
and see the importance of incorporating human insights into the projects. However, not every aspect of design, such as
that it is not limited to tangible products, is understood as the participants do not have a design background.

In 510 projects, a lot of HCD activities are already done by non-HCD project staff or stakeholders; stakeholders are
engaged in the project through meetings and calls, information on the user, stakeholders and context is received through
several sources and work is reviewed continuously.

However, a human-centered approach is not implemented consistently because it is not always instinctively the most
sensible choice for 510 staff. For example, when a product is already produced for one country, it is a logical idea to
apply it in a new country as well and therefor show an example product during a visit. Additionally, when a product can
potentially be used by many stakeholders, it seems sensible not to choose a specific user. However, in practice, these
logical decisions counteract an HCD approach.

Additionally, the human-centered activities done by the project staff might not always feed into the HCD methods of the
HCD team. The information that is already gathered on users, stakeholders and context (e.g. through meetings and calls
with stakeholders or partners) is not always documented in a structured way, or documented at all. This makes it difficult
for HCD to be applied in an effective way as there is no clarity on the information that is already available.

Additionally, the setup of 510 projects can prevent a structural implementation of HCD. The scientific focus at the start
of some projects can result in a late involvement of HCD. Because of this, a lot of work is done before HCD research
is done in order to understand human-needs. Because of the funding method there is limited budget available for the
exploration of human needs at the initial phase of a project and many agreements are made in this phase, e.g. on the
goals of the project.

31 Part 1: Discover
Whereas the HCD analysis found that the HCD maturity is in between the prove and scale phase, to 510 staff it can seem
as if HCD is still in exploration phase. To 510 staff, it is not completely clear what the exact goal is of HCD, what HCD
methods are applied, how they should be implemented and how the outcome can be used.
 
6.2 510 HCD volunteer interviews
From the HCD volunteer interviews, several enablers and challenges are defined to the execution of HCD activities.

6.2.1 Interview insights

6.2.1.1 Project and HCD addition to project unclear

“
I couldn’t understand some of the things because it was... Forecast based .... How do you say. A lot
of the lingo and terminologies was really new for me, but I had an assumption – HCD_Volunteer_P1

I did not really understand what -Project Z- was and what – Project Y- was. In the beginning it
would have been nice to sit for a bit and just discuss that very broadly. We are HCD, these are the
projects that we do, we are going to set you in this project, and you are going to work on this part.
– HCD_Volunteer_P2

For a volunteer coming into 510, there is a lot of new information to take in. The projects are quite complex for someone
without a background in disaster response.

“
the COD questions where very specific. So that is why we thought all the insights are directing to
creating a digital interaction. – HCD_Volunteer_P1

It was still a bit difficult because they did not know yet how I worked and get to know each other.
There wasn’t a program of how they are going to get me familiar with the work. And I noticed that.
You could do this, and at the end of the day we have this. That was fine, but you did not really
understand the overall picture and then you don’t know what you are doing it for. I missed that a bit
in the beginning. – HCD_Volunteer_P2

The goal of the activity that the volunteer is working on is not always completely clear. In the first example, the volunteer
thinks they understand the goal of the activity, but that is not the case.

What is not clear in the second example is the link of the performed HCD activity and the project. There is no structured
way for new volunteers to get informed on the HCD methods and the projects, so there is no clear overview on how the
output of the volunteers’ work will be used.

7.2.1.2 Help from other volunteers

“
When I came here it was nice that I had – Volunteer X – and - Volunteer Y -. So that you have people
who are also volunteers and can explain things to you. They also did not know everything but then
you figure it out together. – HCD_Volunteer_P2

Although HCD staff is available for questions and discussion, they are also often in meetings. For a volunteer it is nice to
work together with other volunteers, especially in the beginning of volunteering at 510. Other volunteers are available all
day in order to discuss questions and work together on tasks when you first come into 510.

7.2.1.3 Clarity and motivation from talking to users

“
Because we were in -City X-, for -Project Y-, you really get a feel, because you are talking to the
people. Then you know, we do the user tests, from there comes the persona journey and from that
we can improve the – Product X -, for these people. That really gives an idea of what you are working
on and it gives motivation. (18:50) – HCD_Volunteer_P2

When being involved in multiple steps of a process and talking to the users, this enables the volunteer to get an
understanding of both the HCD steps and the project aim. Additionally, being involved in user-research helps create
motivation for a project as it is clear who you are helping with your work.

6.2.1.2 Choosing roles

“
There are multiple things of which I think:” Oh that seems interesting, that seems interesting”. -
HCD staff- tries to give me one role, with maybe one additional role, but not that I have 3 several
projects and if I stop 3 people need to take over from me. – HCD_Volunteer_P2

Volunteers are able to express what they want to work on; however, they are not asked to do many tasks at once as they
don’t have much time in the week and they might stop volunteering as it is often done temporarily but without a clear
end-date.

32
6.2.2 Conclusion HCD volunteer interviews
For an HCD volunteer coming into 510 there is a lot of information to take in in a very short period of time. This includes
information on the HCD methods employed as well as understanding the larger 510 projects for which they are working.
HCD volunteers get this information through explanation by HCD staff, which is challenging for the staff members with
the already limited time available. Volunteers are given specific roles (for example one HCD task for one project) in order
for them to limit the amount of learning they need to do at each moment. Additionally, working together with other
volunteers can help in the overwhelming initial days. However, not only for 510 staff, as described in paragraph 6.1.1.7,
but also for the HCD volunteers, the structure of HCD and the goal of the activities is unclear at times. The volunteer
interviews show that being involved in several steps of a project and being present during user-research helps understand
the project, the challenges the users are facing and the HCD activities.

33 Part 1: Discover
34
 Part 2: Define
The following chapter analyzes the insights from the previous Discover chapters and summarizes
them into 3 main lessons in the implementation of HCD in disaster response technology development.
From these main lessons, three elements of embedded HCD are determined.

Chapter 7. Define (page 36)

35 Part 2: Define
 7. Define

In this chapter, the challenges found in the previous chapter are clustered into three main lessons in the implementation
of HCD (Figure 11). These three lesson clusters are translated into the three elements for embedded HCD, which are used
to develop the final proposal for 510.

7.1 Clustering insights on the implementation of HCD

In order to examine the insights, an overview of all factors in the implementation of HCD for 510 was made (Appendix D).
In order to create an understanding of the connections between the insights described in the previous chapters, clusters
were made of the insights of which the final product can be seen in Figure 11. These clusters are considered the lessons
in the implementation of HCD. They are translated the three elements of embedded HCD.

volunteer interview
A lot of HCD is already done insights

510 staff interview

wide variety of projects:
open management style insights
geographical, disaster,
technology, stakeholders, users 510 organisational
analysis insights

responsibilities HCD unclear staff finds HCD important HCD maturity analysis
insights

human-centered organizational many HCD activities already

values partly done by others
HCD has to be embedded
into the existing workflow
varying 510 project workflow funded project setup basis for HCD methods
developed, some fully finished

no clear distinction between HCD not structurally applied 2 HCD staff with many extra
scientific and practical projects hours invested

some HCD applied in every new limited hours to develop and

projects document methodologies

documentation both on results unclear structure in HCD

and process missing activities for project staff

HCD insights known by 510 staff

flexible staff broad user definition
are not always documented

technological background volunteers need to understand no clarity on link HCD with 510
a lot in a short time projects for volunteers

volunteers need a lot of quickly rotating HCD team built

guidance up out of volunteers

Everyone within 510 has a role in

the implementation of HCD

Figure 11. Overview of insights from Discover phase case study research and their connections

36
 7.2 Element 1: A clear role for the HCD team

Lesson 1: A lot of HCD is already done Element 1: A clear role for the HCD team
Contrary to challenges discussed in literature, HCD is From the first lesson, it is clear that implementing HCD
supported by 510 management: The 510 organizational is not starting from scratch but rather finding what is
analysis shows that the organization has human-centered already done and what is still needed for the organization.
organizational values and a human-centered strategy. This is why the first element of embedded HCD is defining
Additionally, the 510 staff expresses an understanding of a clear role for the HCD team.
the need for a human-centered approach.
Defining a clear role for the HCD team can help in several
Taking the description of HCD as an approach that is ways: it helps 510 staff understand the use of HCD and
based on human-insights, participatory and iterative, engage HCD in their projects, it helps limit overlap in
indeed a lot of HCD activities are already done within activities and it can help HCD limit their activities to be
510: manageable with the resources available.
• Information is gathered on the user and their
context In order to develop a role of HCD within 510, the needs
• Many people are involved in stakeholder for HCD in 510 are analyzed.
engagement
• There is continuous interaction with the To do so, firstly interviews are performed in order to
National Society Red Cross of the project country understand the current information available on the user,
• Implementation plans are already developed stakeholders and context and what information is still
even though this might not be done deliberately needed.

Whereas these activities show that it there already is a lot Next, value propositions are filled in to link the HCD
of consideration for the user within 510, they also make approach to the found needs. These value propositions
that the role of the HCD team within 510 less apparent. are translated into a role for the HCD team that can be
As is seen in literature, it is important to find a niche communicated to the rest of 510.
within the organization. However, from the 510 staff
interviews it is clear that the staff is not exactly sure what
the role of HCD within 510 is.

The varying human resources in the HCD team and the

limited budget in 510 make for an additional urgency in
finding a niche in order to work efficiently.

37 Part 2: Define
 7.3 Element 2: An embedded HCD workflow

Lesson 2: Embedded HCD is interactive with the Element 2: An embedded HCD workflow
existing development In order to integrate the HCD activities within the 510
As found in literature, HCD can often be seen an addition development process, an embedded HCD workflow is
to complement an otherwise already finished product. made. This workflow can help in structurally incorporating
However, HCD activities should be done all throughout HCD and creating overview.
the project.
A clear workflow is made with an overview of the HCD
This challenge is partly reflected in 510; HCD is methods, the outputs of the methods and how the
implemented variably across 510 projects. Additionally, outputs contribute to the rest of the project. It can help
from the HCD analysis it is clear that sometimes HCD 510 staff understand when to engage the HCD team and
methods are applied in a way that does not support the what they can expect from the HCD activities. It will also
aim of method. help HCD volunteers to get an understanding of how their
work links to the larger project.
An explanation for the inconsistent involvement of HCD
can be explained through several causes: In order to develop the embedded HCD workflow for 510,
• The HCD tools have to be developed with a lot the first 3 steps of the IEI model (Metzker & Offergeld,
of thought and consideration for the difficult context. 2001) can be used in an adapted manner:
However, the young HCD team has had limited hours 1. First, the workflow of 510 is analyzed.
available to develop and document the methods. 2. Next, the possible HCD activities are retrieved
Therefore, the methods are not all finished and what is from literature (instead of the predefined usability
done already is not all documented. methodologies used by Metzker and Offergeld).
• There is no clear link between the methods and 3. Next, the HCD methodologies are chosen and an
the project. There is unclarity on the activities performed, integrated workflow is developed.
the hours needed, the output from design activities
and how they could be used. This is further emphasized In order to choose the HCD methodologies, the role of
in interviews with HCD volunteers, who do not have a HCD as defined in the previous ‘element of embedded
clear overview of how their activities will be used in the HCD’ is used. Because of this, the activities in the workflow
project. do not overlap with activities already done by 510 staff or
• Because of the variety of projects and the project stakeholders.
funded project setup within 510, the workflow and the
available budget for HCD activities varies per project.

38
 7.4 Element 3: A communication plan that guides 510 in implementing HCD

Lesson 3: Everyone within 510 has a role in the Element 3: A communication plan that guides 510 in
implementation of HCD implementing HCD
From the analysis it is clear that the HCD team is not the In order to ensure implementation of HCD across an
single actor in the implementation of HCD. Instead, the organization with a technical focus, the HCD team has
entire 510 department needs to be activated in order to guide the organization. As responsibilities in applying
to achieve a human-centered approach to product an HCD approach are dispersed across all activities in a
development. project, HCD implementation cannot be dependent on
the HCD team alone. Instead, the HCD team needs to
As discussed in the first lesson of implementation of communicate why and how everyone in 510 can use an
HCD, it is clear that the application of a human-insights HCD approach.
based, participatory and iterative development process
is not limited to the HCD methodologies but instead can In order to do so, communication materials are developed
be applied across many activities in the organization. that help HCD guide the organization in implementing an
HCD approach where needed.
This shows that people outside the HCD team are
responsible for a human-centered approach in different Additionally, the HCD staff is in the unique situation of
parts of the project. During contact with stakeholders, working with volunteers to perform HCD methodologies.
project exploration in country and the definition of the Therefore, the HCD staff has the responsibility to guide
project goals, there are many considerations regarding the HCD volunteers in performing HCD activities.
the HCD approach to take into account. Additionally the
responsibilities of project staff include engaging the HCD The communication is developed by first making an
team in the project at the right moment and creating overview of the HCD responsibilities of the different
budget for HCD activities. staff members and volunteers. From this overview,
communication materials are developed or proposed
However, it is not obvious to apply an HCD approach in that help 510 staff and volunteers implement an HCD
every activity. This can be caused by a conflict in interest approach and the HCD methods.
(selling current products against understanding the
user needs) or activities not being adapted yet to the
integration of an HCD team (gathering information on
users in a way that is later not available for HCD activities
or a very broad user definition that makes it difficult to
understand the user) or just a different focus (the 510
staff members mostly have a technical background and
their main activities and considerations regard technical
aspects of the product). Furthermore, as is discussed
in the second lesson, the lack of documented and
communicated structure makes it difficult for 510 staff to
engage HCD correctly.

Additionally, the HCD team is not necessarily shifted

toward an HCD approach internally. Because of the quick
rotation of human resources within the volunteer-based
HCD team, there are constantly people within the HCD
team who are not aligned with the HCD values and who
are not familiar with the HCD methods even though they
are responsible for many HCD activities.

39 Part 2: Define
40
 Part 3: Develop

The following Develop chapters describe the further research needed in order to develop the three
elements of embedded HCD which were defined in the previous chapter.

Chapter 8. Literature review on applications of an HCD approach (page 42)

Literature research is done in order to understand current applications of HCD in software
development, disaster response design and response technology development.

Chapter 9. Interviews on needs for HCD in 510 (page 46)

Interviews with 510 project stakeholders and 510 staff are conducted in order to gain insights into
the human-centered information needs in 510 projects.

The insights are used in the Deliver chapter in order to propose a role, workflow and communication
plan for 510.

41 Part 3: Develop
 8. Literature Methodology
review on applications of an HCD
approach

IDEO explains a large number of methodologies in their HCD toolkit (IDEO.org, 2015). However, HCD is considered an
approach or a philosophy rather than as a strict methodology. Therefore, the range of methods IDEO provides is diverse.
The toolkit includes ‘building your team’, ‘doing secondary research’, ‘expert interviews’, ‘collaging’, ‘role-playing’, ‘the
business model canvas’, ‘building partnerships’, ‘creating a pitch’ and ‘making a funding strategy’. It is clear that not all
methodologies from this toolkit are necessarily suited for every application of HCD, and some of the methodologies
might not be appropriate for use in response technology development.

In order to find the best application of HCD in the case of 510 a more in-depth research is done regarding the current use
of HCD within the field of data and digital tools for disaster response. This chapter will therefore describe the application
of the HCD approach in humanitarian software development. As literature on the use of design methods in response
technology development is limited, the research includes the use of HCD in adjacent fields. The research discusses the
use of HCD methods in the field of software development, in the area of humanitarian action and development aid and
finally in response technology development.

8.1 HCD applied in software development

Within software development, an HCD approach often focuses on interface design and usability design. These are two
accomplished design domains with wide research coverage that has expanded over a long time period; Methods for
achieving high usability of interactive devices were already discussed by Gould and Lewis in 1985 (through Wallach &
Scholz, 2012). Wallach & Scholz, (2012) describe user-centered design (UCD) as “a successful and practical approach to
the design of software user interfaces” and provide an overview of activities done in a UCD methodology.

Usability design in software development is said to have a number of advantages. Maguire (2001) defined the three most
common usability requirements that are improved through usability design:
• Effectiveness: the degree of success with which users achieve their task goals
• Efficiency: the time it takes to complete tasks
• Satisfaction: user comfort and acceptability
Other requirements include understandability, learnability, operability, flexibility and attractiveness.

A common misconception of user-interface design is that it is an individual activity in which designers generate visions
and ideas and develop these into an interface (Wallach & Scholz, 2012). This suggests that interface design is a very
subjective activity in which one person’s view determines the outcome. However, in practice, well-performed user-
interface design is a series of processes that produces suitable outcome while leaving limited possibility for personal
creativity (Wallach & Scholz, 2012).

Wallach & Scholz (2012) and Maguire (2001) both describe an overview of design activities for use in software development.
Figure 12 shows an overview of activities mentioned in both papers and the 510 HCD methodologies as described in sub-
chapter 5.2. The division of activities into categories (evaluation, planning, etc.) is taken from Maguire (2001).

Possible design activities as mentioned by Wallach & Scholz (2012) include: goal and scope setting, analysis without the
end-user, analysis with the end-user (including job shadowing and contextual interviews), synthesis (including affinity
diagrams, personas, mental models, scenarios), conceptual design (including scribbles, wireframes and prototypes) visual
design, usability testing and usability goals. These activities are very similar to many of the 510 HCD methods.

Methods for HCD as summarized by Maguire (2001) are also shown in Figure 12. This range of activities is broader than
the one mentioned by Wallach & Scholz (2012), although many activities overlap. One of the HCD principles mentioned
by Maguire which is less apparent from the 510 HCD methodologies (as described in sub-chapter 5.2) is the appropriate
allocation of function between the user and the system which is explained by the following quote:

“It is important to determine which aspects of a job or task should be handled by people
and which can be handled by software and hardware. This division of labor should be
based on an appreciation of human capabilities, their limitations and a thorough grasp of
the particular demands of the task.” - Maguire, (2001)

The allocation of function between user and systems consists of understanding the user tasks and understanding which
of these tasks are going to be taken over by the system. An HCD approach can help in determining this allocation of
function.

In a study by Kifle, Dittrich, & Teka (2017), adaptations to UCD methods are proposed in order to deal with culturally
diverse settings of users. Firstly, they suggest the use of different users’ personas in order to get a better understanding,
as well as to update those personas based on user tests. Secondly, they propose to do user testing in pairs as in some
cultures it might be inappropriate to express critique. Pairing up the participants could help in easing them to give
critique on the prototype or product.

42
 task/function stakeholder
mapping analysis
user cost-benefit
allocation of analysis analysis without end
user
function

user requirements user, usability and

interview requirements organizational analysis

existing system /
focus groups competitor analysis

context of use scenarios

analysis

identify
task analysis persona
stakeholders

survey of existing
context of use
users mental models

field study / user

observation

PESTEL
Job shadowing analysis
codesigning

contextual
interviews affinity diagram
constraints

goals scribbles
scope

brainstorming
usability cost-benefit
planning
analysis
design parallel design

usability planning and

scoping
deliver guidelines and
standards

usability goals
storyboarding

controlled user
testing card sorting

critical incidents visual design

paper prototyping
heuristic or expert evaluation
evaluation software
prototyping
prototyping
assisted
evaluation
organisational
wireframing prototyping
satisfaction
questionnaires
wizard-of-oz
prototyping
assessing participatory
cognitive workload evaluation

mentioned by Maguire (2001)

post experience mentioned by Wallach and Scholz (2012)
interviews (part of a) method used in 510 HCD

Figure 12. HCD methods mentioned in literature and done in 510

43 Part 3: Develop
8.2 HCD applied in humanitarian action
From the early 1990’s, a human-centered approach to humanitarian response has been promoted (Konyndyk & Worden,
2019). Research on design methods for human-centered development started as early as 2004, but has gained interest in
current years (Gordon et al., 2017). The Bill and Melinda Gates Foundation gave IDEO the task to develop the HCD Toolkit
in 2008, creating more attention for HCD as a design method for social impact (Gordon et al., 2017).

An example of the use of HCD in humanitarian action design is the study by B. F. Nielsen (2017). In the study, design
thinking is used in order to overcome challenges in the design for humanitarian emergencies. B. F. Nielsen (2017) uses
human-centered approaches for several parts of the project; to determine the problem, for project goal and scope setting
and for combining donor and beneficiary views. Collaborative sessions are done using methods such as storytelling,
in which participants can explain their experience, and back casting, in which groups of participants analyze the goals
expressed in the stories and the steps to get there.

However, applying HCD in this context demands an understanding of the differences between design in the humanitarian
field and design for commercial goods. Most design methods need to be adapted in order to be suitable for use in
humanitarian response (Gordon et al., 2017). For example, disaster response activities do not always follow the designed
processes (Fahland & Woith, 2009). Instead, designed protocols might change in a disaster event depending on the
situation. Therefore, design practices such as scenario formulation applied for disaster response activities should take into
account this changing context. Similarly, the final products or systems designed for the disaster response context have to
take into account this variability.

An overview of critiques on the use of HCD for development mentioned by Gordon et al. (2017) is; (1) research on the
context of the problem is under-emphasized and oversimplified; (2) prior to implementation, there is little to no emphasis
on ensuring that solutions are appropriate or contextualized and (3) the designer and the designer’s freedom of creativity
are prioritized over the end-users empowerment. The research concludes that further research is necessary on the effect
of remote design and the level of inclusion of the designer in the target community. The third critique is similar to the
misconception about user-interface design and seems to be based on a notion that design activities are subjective
activities based on designers’ vision rather than predefined processes.

8.3 HCD applied in humanitarian software development

“The most effective way to design a system matching users’ needs is to perform a User-
Centered Design; it relies on continuous interactions with end-users in order to understand
better and better how organizations are arranged during emergencies, which data are
exchanged and which steps are performed by organizations to face disastrous events.”
- De Leoni et al. (2007)

Coletti, Mays, & Widera (2018) describe HCD

as an approach that can be used in order to
include humanitarian values into the design
of response-technologies. However, data- and
digital tool development for humanitarian
aid is a niche field and the development of
such tools through an HCD approach is not
elaborately covered in literature. Nonetheless, a
number of examples in which HCD is applied in
humanitarian software development are found.

One example is the practice described by De

Leoni et al. (2007). In their study, HCD methods
are used in order to understand software system
requirements for disaster response and short-
term recovery. De Leoni et al. (2007) describe
their way to collect user insights in order to
develop user-interface designs, as is illustrated
in Figure 13.

Firstly, interviews are done with potential users

in order to understand the tasks they perform.
This phase results in a clear definition of the user
groups and an overview of the current working
situation, responsibilities and tasks of the
potential users. Next, scenario’s are built using
a storytelling technique that allows the users
to share their workflow without much guiding
structure. This is done in order to better identify
the various user groups and to understand the
Figure 13. The WORKPAD methodology adapted from De Leoni et al. (2007)
differences in workflow between the different

44
user groups. Then, a hierarchical task analysis is done, which separates high-level tasks and identifies the sub-tasks that
belong to those high-level tasks. These sub-tasks are then again divided until the required level of detail is achieved. In the
following step, user requirements are analyzed by dividing them into (1) challenges for the user, (2) proposed solutions
and (3) user needs. User requirements can then be divided into functional and non-functional system requirements.
Functional requirements are those that need to function within the designed system, such as the ability to download the
data used. Non-functional system requirements are context constraints that the software design needs to account to,
such as limited access to the internet. Functional requirements are made using use-cases. Non-functional requirements
are added to the use cases. These insights are the basis for the user-interface design.

The method described by (De Leoni et al., 2007) is similar to HCD methods used by 510 as discussed in sub-chapter 5.2.
In particular, the codesign setup shows many similarities to the storytelling technique and the user scenarios. The 510
HCD Persona Journey method is still in development but is similar to the user scenario, the task analysis and the use cases
although the Persona Journey steps are less defined.

Next, in a study examining characteristics of disaster response and their impacts on design practices for response
technology, several challenges to applying HCD in disaster response were found (Jul, 2007).

“In the area of user interface research and design, the lack of theory is evident in widely
disparate conceptions of who “the users” are, what they are doing, and where they are
working. Many research and design efforts are based on idiosyncratic conceptions of “user,”
“task,” and “context,” that are often hypothetic, and sometimes, myopic. Such efforts fail
to consider the fluid ambiguous nature of disaster, and the diversity of individuals who
participate in disaster management. The resulting technologies may appear promising,
but limitations imposed by underlying assumptions will ultimately hamper their usability
and utility.” - Jul (2007)

The simplification of the definition of user, tasks and context is found to be a recurring problem in design for response
technologies (Jul, 2007). The three disaster response characteristics - scale, kind and predictability – had several
implications to the characterization of user, task and context. For example, the scale of the disaster might affect the
expertise of responders, as the relative number of untrained responders increases as the scale of the disaster increases.

8.4 Literature review conclusion

It is clear that most of the methods described in literature are in part included in the 510 HCD activities. For software
development and usability design, much research has been done and a lot of information on methodologies is available.
However, less knowledge is available for HCD methods for application in the field of humanitarian response and response
technology development and not all tools developed for other context might be suitable for use in humanitarian
response. Therefore, the HCD team needs to take into account that methods might need to be adapted for application
in the humanitarian field.

From the literature review a number of important topics for HCD are clear. Firstly, the lack of a defined user in interface
design, as described by Jul (2007), is in line with the findings from the initial problem exploration of 510. Additionally,
within humanitarian response it is quite difficult to get a good understanding of the tasks or activities and the context
in case of disaster. In addition to the topic ‘tasks’, another focus of HCD methodologies for software development is the
allocation of function as described by Maguire (2001). Whereas currently allocation of function is an implicit process in
the 510 HCD prototyping method, making this process more explicit can help evaluate the appropriate allocation of
tasks between user and system. Lastly, Gordon et al., (2017) describe as one of the problems of design for humanitarian
response the lack of understanding of suitability of the solution before implementation. According to the IDEO description
of HCD, the iterative and engaging nature of HCD is in fact a suitable approach to test the appropriateness of the solution
before implementation.

Some challenges in the implementation HCD in response technology development become clear. Firstly, the complex
and adaptive nature of disaster response should be taken into account in both the design methods and the design
results. Next, HCD can be seen as a proposed solution to the oversimplification of the user, task and context. However,
if not performed correctly, HCD methods could in fact contribute to this simplification of the user, task and context.
Additionally, if HCD is practiced without structured methodologies, individual creativity of the designer could be leading
rather than the user needs.

Concluding, HCD can benefit from including user, task, context and allocation of function in their focus topics. Additionally,
HCD can help understand suitability of the proposed solution before implementation. However, it is clear a structured
methodology is needed in order to ensure that human insights are guiding and not individual visions of the designer.
Additionally, it is clear that the HCD team needs to adapt methodologies in order to apply them in a humanitarian context.

45 Part 3: Develop
 Methodology
9. Interviews on needs for HCD in 510

9.1 Project stakeholder interviews

9.1.1 Stakeholder interview insights
Interviews are done with local project partners from Red Cross National Societies involved in a project with 510. The
projects were all part of the IARP project which is an Impact Based Forecasting (IBF), also called a Forecast-Based Financing
(FBF) project for Uganda, Kenya and Ethiopia. From the interviews, several needs for a human-centered approach are
found:

9.1.1.1 User definition

“
I do not know at what point these people come on board, the people who are at branch level or district
level. I don’t know whether the system will really be used by them, or if it is at a national level. The
lower levels, the district information management officers in charge of disaster management, I don’t
know whether this system will be accessed by them. And if it is accessed by them. I am still not
clear whether this information is useful for them. – Project_Stakeholder_P5

After a year of the project, it is not yet clear who the final user of the digital tool will be. There are many possible users;
the government disaster response unit, the NS data team, the NS disaster response department, forecast providers.
Additionally, these descriptions of possible users are very broad. Every group mentioned consists of a large number of
people doing very different tasks and needing very different information.

9.1.1.2 Stakeholder engagement

“
I am not sure if we have the right person from the right level engaged. – Project_Stakeholder_P1

Still the challenging part continues to be having the critical stakeholders on board. We have some,
but the ones that we have I think are not enough to take action. It would take action but I think
the demand would outweigh the supply. So, I think getting more partners on board. I also think, so
getting more partners on board would still be a challenge. – Project_Stakeholder_P2

Within the Red Cross project team, multiple people are in charge of stakeholder involvement in several ways. Some are
focused on the government agencies involved, others are focused on the forecast providers, others are more closely
connected to the people in universities.

Stakeholder engagement is initiated from the beginning of the project. Stakeholders might be involved because they are
partly responsible for disaster response and thus influence product implementation, or because they can provide models
or data that are needed for the project. However, it remains difficult to know if all necessary stakeholders are involved in
order to ensure successful implementation.

9.1.1.3 Stakeholder understanding

“
The number one challenge from my side is building a system that is understood by the national
stakeholders. Because up to this point, we are trying to bring home this idea of FBF firstly and the
idea of using the FBF system. Getting these National stakeholders to appreciate what is being built
and also to understand and appreciate that this system is not a magical system, it is a system that
is very good being built. But it is also a system that has its limitations that can be worked upon to
improve it. It is something that is a great challenge we are facing and we will definitely face it in the
future. - Project_Stakeholder_P5

They are the very people who were not understanding what we are doing. They had misunderstood
us that we are creating a parallel system to the government system. – Project_Stakeholder_P5

Ensuring that all stakeholders understand the product across the disaster response system in a country is challenging.
On the one hand, the stakeholders need to understand the value of the project in order to cooperate and successfully
implement the product. On the other hand, the stakeholders should understand the limitations of the system.

For most participants, the goal of this particular project is to make a product that is implemented in disaster response
nation-wide. So, the end product should not become a Red Cross product, but a product that is owned by the country
and everyone involved in disaster risk. However, from the interviews it is clear that engaging the right stakeholders at the
right time in order to ensure successful implementation is the most challenging part of the project.

46
9.1.1.4 Stakeholder data sharing

“
The other issue is with regards to data sharing, information sharing. You find that there is a lot of
information that you need to develop these approaches and that information is not readily available.
There are so many issues to do with data, you find you don’t have access to certain data sets. Policy
issues. You find it information you need to develop the methodologies for your approach.
- Project_Stakeholder_P7

Even when the right stakeholders are found and they are introduced to the project in a way they understand, there is no
certainty that they are willing to share the data they have. The projects do not always have funding available to pay for
this information, so mostly other data and models are offered in return.

9.1.1.5 Multiple project goals

“
I believe it can act as a benchmark for many other initiatives that will come up in the country. To
improve the system of how things are done.” … “Already, as we speak now there are many projects
that are coming up that are looking at the IARP project and trying to improve what they do. So,
I am looking at the IARP project, achieving its goal and also setting a benchmark for many other
initiatives that are coming. – Project_Stakeholder_P2

Whereas the official project goal is building and implementing an Early Warning Early Action protocol, the Forecast-
based-Financing work also serves a goal that goes beyond the project. The underlying goal for the FbF project was
getting decision-makers to act based upon forecast models and to set a standard for future data-driven decision-making
tools for humanitarian aid.

9.1.2 Conclusion
A clear finding is that not only the 510 staff members, but even project partners within the National Society Red Cross
for which the product is made, are unsure of who the user should be. A very wide range of possible users is discussed
without a definite conclusion.

Additionally, even though a lot is done already, engaging external stakeholder seems to be the most significant challenge.
This task includes knowing who the right stakeholders are to have on board, knowing how to communicate the project
to them in a way that they understand its importance and engaging them in such a way that they want to communicate
to the project.

9.2 510 staff interviews

9.2.1 510 Staff interview insights
From interviews with 510 Staff, several needs for of HCD were identified:

9.2.1.1 Understanding what problem is solved for whom

“
What problem am I really solving for most people? With that I can make an as effective/nice/useful
as possible product for most people. - 510_Staff_P1

Somehow it would help to only focus on 3 problems and to solve those as well as possible and leave
the rest for what it is. But we can never definitely say that, that these are the 3 most important
problems. (…) We can’t say that so we need to focus on many things at the same time because we
are trying to make three products that solve everything for everyone. - 510_Staff_P1

In the example, there is unclarity on the problem the project is intended to solve for most people. Because of a large
number of stakeholders, there is a corresponding large number of project goals without clear priorities. The participant
expresses a need for a clear practical goal that is limited in such a way that it eases decision making.

9.2.1.2 Clear user definition

“
One is just the donor, the one who pays us. We need to justify to them what we do. Next to that
the end-user is a bit dependent on the project. Most of the time for a National Society Red Cross
in a country. They serve the beneficiaries, or the people affected by disaster. But the most direct
end-user is such a Red Cross National Society. Because we hope that they will use our tools and
methods. - 510_Staff_P3

One of the users identified is the donor, the one who funds the project. Then, the people who are intended to gain from
the product in the end, are the people affected by disaster. However, the most direct user is the Red Cross-National
Society, in most projects they are the end-user of the product developed by 510.

As mentioned in the problem analysis in paragraph 6.1.1.4 and in the 510 project stakeholder interviews in 9.1.1.1, the
user definition is very broad. This broad-user definition makes it difficult to get a better understanding of the user and
their context, as there is a wide variety of users and context within the defined user groups.

47 Part 3: Develop
9.2.1.3 Understanding of the user and their context
(answers to the question: What information on the user would you like to have that you do not have?)

“
Focused on the aid workers; from them I would like to know what they do in daily life and how such
a project looks like for them and what problems do they encounter? – 510_Staff_P1

what does the end-user base their decision on? – 510_Staff_P4

who has the skills that are needed? - 510_Staff_P4

Eventually the best thing is if we can find out how they do – as they call that in scientific terms –
sense-making and decision making. How are decision made. How do they take information in. If you
know that, you can add innovation and ideas of value. - 510_Staff_P3

One of the most mentioned information needs is a general understanding of the workflow of the end-user. Several
mentioned aspects are: How do they make decisions? What information do they have? What information do they need?
What challenges do they run into?

“
I am pushing towards narrowing down the scope to a very specific context. I see less as a priority to
understand the whole context of the -Country- - what is the micro context of this specific thing that
we are working towards. – 510_Staff_P2

In this quote, the participant describes the wish for a very specific context description of the product rather than a nation-
wide context description. In the HCD methods described in the literature research in chapter 8, user scenarios are used
to understand the use-context.

9.2.1.4 Usable product-user interface design

“
(What information on the user do you use?) What I use comes from, if you see HCD as UX user
research, then codesign is the execution of it and it informs the wireframe or in information that the
designer translates into product design. We use that, or I try to steer towards that. - 510_Staff_P1

Currently, the most important responsibility of the HCD staff is the development of wireframes and a user-interface for
the product.

“
WhatsApp is very common, but Facebook is less used. The last 20 years they have a huge advancement
with mobile phone usage without ever having had a landline phone. Nobody has a computer but they
do have a smartphone available. That affects what people expect from technology - 510_Staff_P1

The participant describes the need for country-specific usability design. Different user groups from different countries
have very different experience using digital tools. Whereas some user groups might have experience with landline phones
and computers, others might have skipped both those steps and have first used internet using their smartphones. Different
user groups have experience with very different applications and programs on their digital devices.

9.2.1.5 Implementation plan

“
No, it is not yet a real dashboard. It is an email and then they get in -country- a kind of map. (…)
This is, I must say, a bit of a make-do implementation. It is not completely – it does not get used
yet by the operational center of the Red Cross, only by the -NS- Forecast based Financing advisor,
they use this. (…) The next step would be that it is integrated in the operational center and their
dashboards. But before that it needs to be a few times …. It is now first used for -disaster-, of which
we have a blog on the website. Now, it first needs to be used another 2, 3, times, lessons learned,
evaluate, improve, etc. And then, perhaps in a few years, we can truly integrate it in their tool suite.
That would be an example of an ideal form of adoption. – 510_Staff_P3

The above example describes an ad-hoc implementation design. Whereas in project plans implementation is often seen
as training sessions, from this actual implementation it is clear that in order to gain trust, a multiple year implementation
plan that starts very basic through an email is set up.

9.2.1.6 Iteration
(answer on the question: What do you see to be the most important role of HCD?)

“
That you build something that people want to use. That it helps people. Testing as much as possible
and getting feedback from users. You never know for sure of course, (...) but in any case, to get a
feeling that we are in the right direction. - 510_Staff_P1

48
From this description it is clear that in order to gain familiarity with the product, a multiple year implementation trajectory
is carried out. The implementation starts with a non-committal email to an external advisor, in order to be able to provide
a proof of concept. Later however, the product is intended to be embedded into the existing procedure used by the
National Society and integrated into the disaster response system including the operational center.

9.2.2 Conclusion
Most needs expressed by 510 staff correspond with the design of the HCD methods as described in the HCD maturity
analysis in paragraph 5.2. Stakeholder engagement is partly done through codesigns with the stakeholders. Project goal
setting is done through strategy sheets. Generating understanding of the user and their context is achieved through
codesigns and persona journeys. Iterative testing is done through user testing.

A number of needs for information on the user and their context that are mentioned are still missing from the current
HCD methodologies: The strategy sheets and persona journeys do not require a clear definition of the user. Next, HCD is
not involved in the development of an implementation plan. Additionally, the codesign questions and the structure of the
persona journey do not explicitly include information requested by 510 staff such as on the end-user’s decision making.
 

49 Part 3: Develop
50
 Part 4: Deliver
The following chapters describe the proposal for the three elements of embedded HCD for 510.

Chapter 10. Element 1: Role (page 52)

The chapter on the role of HCD describes how the insights from the previous chapter are combined
and selected in order to find the information niche that HCD fulfills within 510.

Chapter 11. Element 2: Workflow (page 55)

In the chapter on the workflow for HCD, the suitable HCD methodologies for HCD are selected
based on the role of HCD as determined in the previous chapter. Additionally, these HCD activities
are placed within the 510 product development workflow.

Chapter 12. Element 3: Communication (page 59)

The communication plan highlights which part of the developed role, scope and workflow are
important to communicate to whom.

In addition to the explanation in the Deliver chapters, an overview of the insights contributing to
the development of the proposal elements is provided in Appendix D.
 

51 Part 4: Deliver
 10. Element 1: Role

This chapter will discuss the proposed role and scope of the HCD team. This role and scope will help focus the HCD
activities to where they are most needed in the development of the second element of the embedded HCD; the workflow
(chapter 11). Additionally, it wil help in communicating the value of HCD for 510 in the third element of embedded HCD;
the communication plan (chapter 12).

10.1 Clustered needs from needs analysis interview

To find the role and scope for the HCD team of 510, the insights from the Develop phase are analyzed. In order to
understand the value of the different responsibilities of HCD within 510, value propositions are made (which can be
found in Appendix E) based on the needs expressed in the interviews. Through iteratively filling in the value proposition
after different 510 staff interviews, three different roles for HCD are defined that are catered to three different groups
within 510. In the overview in Table 5 an additional group is added based on the expressed user needs in the stakeholder
interviews.

Information need Quote Value to:

User activities (decision “What does the end-user base their decision on?” - 510_Staff_P4 510 General
making, sense making,
tasks)
Context of use “I see less as a priority to understand the whole context of the -Country-
but more what is the micro context of this specific thing that we are
working towards. “ - 510_Staff_P2
Digital literacy/technical “Who has the skills that are needed?” - 510_Staff_P4
capacity
Who the user is “I do not know at what point these people come on board, the people Project
who are at branch level or district level. I don't know whether the system management
will really be used by them, or if it is at a national level. The lower levels,
the district information management officers in charge of disaster
management, I don't know whether this system will be accessed by
them. And if it is accessed by them. I am still not clear whether this
information is useful for them.” – Project_Stakeholder_P5
What problem is solved “what problem am I actually solving for most people?” – 510_Staff_P1
for the user
Usable user-interface “to make sure that our products are used and useful” – 510_Staff_P3 Product staff
Implementation plan No, it is not yet a real dashboard. It is an email and then they get in
-country- a kind of map. (…) This is, I must say, a bit of a make-do
implementation. – 510_Staff_P2
Stakeholders selection “I am not sure if we have the right person from the right level engaged.” Engage
– Project_Stakeholder_P1
Stakeholder engaging “Still the challenging part continues to be having the critical
stakeholders on board. We have some, but the ones that we have are
not I think are not enough to take action.” – Project_Stakeholder_P2
Stakeholder “The number one challenge from my side is building a system that is
understanding understood by the national stakeholders” – Project_Stakeholder_P2

Table 6. Overview of information needs with corresponding quotes and 510 group

The first need for HCD of 510 is to create an understanding of the user and their context. Literature research shows that
in the development of response technology, often an oversimplified definition of the user and the context is used. This
difficulty can be seen in 510 projects. Although a lot of information on stakeholders and context is available through
a variety of sources, there is a clear need for a better understanding of the user, how they make decisions and what
challenges they face. This difficulty in user understanding can be partly linked to the broad user-definition; the wide
variety of possible users included in the broad user-definition makes it difficult to get a clear understanding of the user
and the context in which they act.

The second need is to ensure that the project is solving the right problem for the right person by deciding on project
goals. 510 aims to improve the speed, quality and cost-effectiveness of humanitarian aid by using data- and digital
products. The practical projects aim to solve human problems. However, the research goal is not always formulated in
order to reflect that, for example because it is a research-goal inherited from the underlying scientific project. The problem
definition might also become unclear because additional project goals are added by project stakeholders. Additionally,
an abstract problem definition makes it more difficult to find the right end-user for the product. As mentioned in the
previous paragraph it is difficult to understand the problems the end-user is facing with a non-specific user definition
such as a department or an organization.

52
The third need for HCD is to translate this understanding and these project goals into the design of a suited and usable
user-interface for software products and an implementation plan. The user-interface is currently the largest output and
responsibility of the HCD team and also the most important use of the other HCD activities (codesigns and analysis are
fed into interface-design). Additionally, the need for a well thought out implementation plan becomes clear from the
make-do implementation described in the interviews.

The last need is stakeholder engagement. As the context of disaster response is very complex, gaining an understanding
of the system is quite difficult. Many people are involved in stakeholder engagement; however, it is not always clear if
all necessary stakeholders are involved. Additionally, making sure all stakeholders understand the project and want to
participate is an even bigger challenge.

10.2 Scope
Because of the limited resources for HCD and the need for a clearly defined niche for HCD activities in projects, an HCD
scope has been developed for 510. The HCD scope includes a focus on the end-user and excludes scientific projects,
stakeholder engagement and implementation. The following paragraphs further describe the choice for this scope.

10.2.1 Focus on the user rather than the stakeholders

Whereas currently codesigns are done with many types of stakeholders involved in the project, the proposed niche
of HCD consists only of data gathering from (possible) end-users. There is a very large number of stakeholders with
potentially relevant information. However, there is also already a very large number of people working on stakeholder
engagement who gather relevant data from different stakeholders. It is proposed the HCD team focuses on the end-user
rather than on all stakeholders in the project. This is also in line with the HCD philosophy as described in sub-chapter 3.1,
which states that the ones facing the problem are the ones holding the key to the solution. As there currently is no one
focusing on the end-user, this creates a clear niche for the HCD team.

10.2.2 Practical projects, not scientific projects

The focus on the end-user means that HCD is mostly involved with practical projects, rather than scientific projects. HCD
activities are better suited for projects that aim to solve a human problem rather than projects that focus on scientific
exploration.

10.2.3 Implementation not included

It is proposed that, although identified as a need, the HCD team is not yet involved in the development of an implementation
plan. As implementation for disaster response systems is very complex and involves many stakeholders, the small HCD
team with a limited budget is proposed to focus on activities regarding the user and the product development within
510. Additionally, the current HCD methodologies developed do not yet cover implementation and so this would require
development of a new methodology. However, the user understanding generated by the HCD activities can inform
the implementation plan. Additionally, as it is seen as a clear need and as it is largely concerned with the end-user,
implementation is a topic that could be included in HCD once the team is more established.
 

53 Part 4: Deliver
10.3 Role of HCD in 510 product development
The main needs for HCD within 510 product development are: (1) generating user understanding through a user, task and
use-context analysis, and through this user understanding (2) formulating clear human-centered project goals and user
definition, and (3) designing a suited user-interface. As can be seen from Table 5, these are the HCD needs separated by
activity type (understand, decide or design) excluding the activities that are proposed to be out of the scope of HCD for
510. These 3 points are considered the responsibilities of HCD in 510 product development.

Figure 14. 510 needs for HCD, HCD responsibilities and HCD approach

10.3.1 Generate understanding of user and context

From the interviews it is clear that there is a wish to better understand the user and their context, including their activities,
how they make decisions and what challenges they face. These information needs fit within the persona journey method
that is being developed within HCD. The literature research provides several examples of a task and context analysis which
can be used in order to help develop the persona journey. The following chapter discusses proposed methodologies for
the HCD workflow.

10.3.2 Support in defining problem definition and user

Based on the interviews a need for a clearly defined problem and user is determined. Therefore, it is proposed that the
HCD team assists both in the formulation of human-centered project goals as well as in the definition of a specific user.

10.3.3 Iterative and participatory design of product interfaces

User-interface design is already the most important output of the HCD team. Literature shows that a lot of response
technology design does not sufficiently take into account the user, their tasks and the context. In order to make sure
that the user-interface is designed to be suitable for its application, the HCD team designs the product user-interface for
510 in an iterative manner. This is done by first making rough prototypes and slowly developing these towards detailed
designs.

54
 11. Element 2: Workflow

For this step the Introduction-Establishment-Improvement model (Metzker & Offergeld, 2001) is used. First, the general
steps in 510 product development are mapped. Next, the HCD activities are chosen, using the current HCD portfolio
(as described in 5.2), the expressed HCD needs (from chapter 9) and the defined role (from chapter 10) as a guide. The
mapped 510 workflow and the selected HCD methods are used to develop an embedded HCD workflow for 510.

11.1 Step 1. Mapping the 510 workflow

Figure 15 shows a simplification of the project phases of a 510 product development project. As mentioned in 4.1.1.2, 510
works on many diverse projects, with Red Cross-National Societies of varying data maturity, different project partners and
with a focus on different aspects of response. Because of this diversity, the steps differ depending on project.

Following is an elaboration of the project phases identified;

11.1.1 Phase 1. Project exploration

The low level of hierarchy becomes really clear when the new project opportunities are
project discussed. A message in teams (the documentation and communication tool of 510),
exploration available to see and respond to for every staff member and volunteer, is posted by the
strategic lead. To determine the best directions, voting is done (although this is not a
definite result). The strategic lead of 510 then turns the most promising ideas into proposals.

11.1.2 Phase 2. Proposal writing

The best ideas are turned into a project proposal based on the required format for the
proposal writing
donors. After this, a team is formed to work on the project.

11.1.3 Phase 3. Product Initiation Document

The Project Initiation document (PID) is a long document in word format (15 pages A4)
which serves to explain the goals and project overview to anyone who joins the project.
product initiation This can either be part of the proposal writing or the start of the project.
document
11.1.4 Phase 4. Feasibility study for project
The first phase of a project is a research and in-depth feasibility study. This includes
mapping and finding stakeholders, finding the available data and models and evaluating
the capacity of the Red Cross National Societies.
feasibility study
11.1.5 Phase 5. Data gathering/analysis/model building
The main activity of 510 is transforming data into understanding, whether it is gathering
data or creating predictive models using weather forecasts to predict floods, droughts
or typhoons, or combining data into a community risk score. This is done by the data
scientists, hydrologists, and GIS experts that are working and volunteering within 510.
database/model
building 11.1.6 Phase 6. Product development
Next, the data or model has to be made into a product that can be used. Depending on
the type of product and the intended user, this step might be quite exstensive or very
limited. A dataset made for use by data scientist does not necessarily need a lot of product
development. However, if a model is made into a software tool for use by a wider audience
product
with limited digital literacy or limited technical knowledge, the product development phase
development
is often quite exstensive. As previously mentioned, 510 products can be databases, models
or software products.

11.1.7 Phase 7. Implementation

The final goal is for the user to be able to use the product autonomously. The products are
implementation meant to be used by those who act and make decisions during disaster, such as government
officials working in disaster management and aid organizations employees in office and in
field. To be able to have such ownership, product implementation is extremely important.

11.1.8 Phase 8. Evaluation and support

evaluation and As funding is provided per project and each donor asks for a specific evaluation, evaluation
support is done per project and the structure is based on the requirements of the donor. This leaves
little room for product evaluation.

The implementation described as the goal in phase 7, is an ideal situation. In case of

disaster there is no official support embedded in the project, however it is expected that
either an in-country delegate or 510 employees can remotely provide support once the
Figure 15. 510 workflow product is in use.
 

55 Part 4: Deliver
11.2 Step 2. Selecting HCD methods
In this step, the changes to the current HCD methods (as described in sub-chapter 5.2) are proposed based on the
found challenges, the literature research and the needs analysis. These adapted methods are then applied in step 3. As
mentioned in the HCD analysis, the original HCD activities consist of PESTEL analysis, strategy sheets, codesign, persona
journeys, prototyping and user testing. The needs and roles of HCD, as discussed in chapter 10, mostly correspond with
these methods. In order to give an overview of the changes made in the HCD workflow, a comparison between the old
and the new workflow is made. In Table 7, the old HCD methodologies are combined with additional or changed steps in
blue. The corresponding HCD roles from the first element of embedded HCD are shown in the first column.

Table 7. Renewed HCD methods with changed steps in blue

HCD Role Method Step 1 Step 2 Step 3 Step 4 Step 5
deleted: PESTEL analysis

Determine
Goal sheets Other Iterate using
Strategy unknowns
and value Define user strategy codesign
sheets and codesign
proposition sheets insights
questions

Fill in into
Gather Codesign
Develop persona
insights from interview Clustering
Codesign interview journey and
previous and insights
questions Strategy
projects transcribing
sheets
Determine
Establishing Iterate using
Persona Establishing Fill in unknowns
persona codesign
journey timeline topline and codesign
types insights
questions

XD
Iterative Paper XD
wireframe MVP design
prototyping prototyping prototyping
design

Paper XD XD
MVP user
User testing prototype prototype wireframe
testing
user testing user testing user testing

1. PESTEL analysis not included.

In the proposal for HCD, the PESTEL analysis is not part of HCD methodology as it is not based on user insights and
therefore does not fit the scope set for the HCD team. Additionally, the nation-wide scope of the PESTEL analysis does
not fall within the focus on the user. Instead, it is proposed project management or other involved stakeholders perform
this analysis instead of the HCD team.

2. Define user is added as part of the strategy sheets.

A crucial step for HCD within 510 is found to be the selecting of the intended user. This is not an activity that the HCD
team can do by themselves. Instead, the HCD team will, just as is currently done with the strategy sheets, guide the project
management in defining a clear end-user. The HCD-team is involved in this step as an understanding of the possible users
and their responsibilities is the basis of the selection of the user. Additionally, many other HCD activities are dependent
on a clearly defined user. The step is facilitated by an HCD team-member through the strategy sheets while using insights
from the persona journey and codesigns.

3. Partly predefined structure for persona journey.

From the interviews, several information needs that are relevant for almost all 510 staff became clear: information flow,
decision making flow, responsibilities and tasks. These information needs can be used to build a basic structure for the
persona journeys. Additionally, literature research shows examples in which task analysis is linked to system requirements
formulation. Therefore, it is proposed that the persona journey method would not only be a combination of a persona
and a user journey but also of more structured methods such as the task analysis and system requirement formulation.

4. A more specified codesign.

Whereas codesigns currently are very open and can be done with all stakeholders, once codesigns are only done with
possible users the questioning can be more specific. The basic structure is proposed to stay with the three parts: digital
experience – relevant disaster experience – ideation. However, as it is also one of the main principles of HCD to gather
feedback iteratively based on progress in the project, the codesigns are proposed to include specific questions on
information identified as unknowns and assumptions during the development of the strategy sheets and persona journeys.
These more specified questions can be added at the end of the codesign in order to let the participant determine the
direction of the conversation in the beginning and only later give more direction.

56
11.3 Step 3. Integrated development process
The last step from the IEI model that is done within this project is the development of an integrated HCD workflow. In
this step, the selected HCD methodologies are linked to the development phases of 510. The changes within the HCD
workflow are explained as well as their relation to the larger project.

11.3.1 Changes to HCD workflow

Two changes are proposed for the timing and use of the HCD methods;

1. Use of database of user insights in project exploration and project initiation

The HCD team is to take a proactive role in the development of new projects. Codesigns are setup in such an open
manner that participants are free to express many different types of challenges and opportunities. Therefore, challenges
expressed in one project might also be relevant for another. These can be used as insights for new product development
by documenting them during codesign analysis.

2. First fill on both strategy sheets and persona journeys

As found in literature, HCD is initially based on human insights, participatory and iterative. Ideally, this approach
should be present in all of HCD’s activities. Whereas currently the strategy sheets are initially filled in based on 510
staff knowledge in order to understand what information is already available, what assumptions are present and what
is unknown. When knowns, assumptions and unknowns are first filled in into the persona journeys, the focus of the
codesigns can be determined based on those two initial-fills. This does three things. First, it gives the HCD interviewer
an initial understanding of the user, stakeholders and the context. This can help in the preparing and executing the
interview. Second, it ensures that the participant’s time will be used in order to gain new information, rather than the find
information that is not relevant to the project or already known within the project team. Third, it engages the 510 staff in
the setup of the codesign which ensures higher visibility of HCD methods and generates trust.

57 Part 4: Deliver
 11.3.2 Design: Embedded HCD workflow
The changes in methods and the changes to the HCD workflow result in the following embedded HCD
workflow (Figure 16). The 510 project phases used in this overview are slightly different from the earlier
defined phases; a number of phases are combined as they were closely linked and they required the same
HCD activities.

In the project exploration phase, HCD documented transcripts and persona journeys from earlier projects can
be used to get an initial understanding of the context and the needs of possible users.

During the writing of the proposal there is no budget for extensive HCD activities, as the project has not
received funding yet. Using the user insights from previous projects and a lot of assumptions, the project
team can already use strategy sheets in this phase in order to formulate human-centered project goals.
Additionally, using the information from previous projects and knowledge or assumptions from 510 staff, an
initial persona journey can be set up by HCD volunteers.

Once funding is raised, codesigns can be done in order to iterate on both the persona journey and the
strategy sheets. However, both of these documents are “living documents” and they can continuously be
iterated upon throughout the project.

The insights from the codesigns, the strategy sheets and the structured information in the persona journey
form the basis of the 1st prototype. The goal of the first prototype is to test the initial ideas with the user early
on. This is done continuously throughout the development. Additionally, the user test insights might lead to
adaptations in the persona journey, the definition of the user and even the project goal.

Insights from the strategy sheets, the persona journey and the user test feedback can be used in the design
of an implementation plan, in predicting the need for support in the use of the product and in evaluation of
the product. 

Implementation
HCD HCD Project Proposal Feasibility Database/ Product
support
role method exploration writing study model building development
evaluation
Human-centered
project goals

Strategy
sheets
understanding

Persona
journey
User

Codesign
Interface design

User
testing

Prototyping

Figure 16. Overview HCD workflow integrated in 510 projects

58
 12. Element 3: Communication

From the initial problem analysis in the Discover phase it is clear that HCD is not only done by the HCD team. Therefore,
the responsibility to apply an HCD approach does not only lie with the HCD team. Because of this, the HCD staff needs to
guide not only the HCD volunteers in applying an HCD approach where needed, but everyone in 510. To do so, first the
HCD-responsibilities of the different staff members are identified. Next, communication materials are developed in order
to guide the staff members in their responsibilities.

12.1 Responsibilities of staff members across project stages

In order to understand who in 510 needs to understand what of HCD, the responsibilities of the different staff members in
applying HCD need to be analyzed. For this, the 510 staff roles (as described in paragraph 4.1.2.3) and their responsibilities
in using an HCD approach (as taken from the interviews and the organizational analysis) are summarized in Table 8. The
responsibilities are mapped along the different 510 project phases as defined in the previous sub-chapter.

Table 8. 510 division HCD responsibilities

Role within Project phase and corresponding HCD responsibilities

510 Exploration Proposal writing Feasibility Database Product Implementation
+ PID study / model development Support
building Evaluation
Strategic Take into Include human
lead account needs in
Scientific human needs proposal
lead in project
exploration Start with
defining a
Start with the problem, not a
problem, not solution
with a solution
Project Include human Identify and Identify and Having an Understand
manager needs in document document understanding barriers in
Product proposal knowns, unknowns of the user implementation
manager unknowns and and and use
Create budget assumptions assumptions Document
for HCD with HCD unknowns and Make realistic
activities team in order assumptions implementation
to incorporate plan
into codesigns
Use human-
metrics in
evaluation
Scientists
Software
developers
HCD staff Help Help Codesigns Codesigns Prototyping
formulating formulating and user
human- human-centered Transcription Transcription testing
centered project goals
project goals and human Analyzing Analyzing
and human metrics results results
metrics into persona into persona
Help refine end- journey journey
Help define users
end-users Prototyping Prototyping
HCD Review Provide clarity
volunteers documentation on options and
(existing hours based
knowledge) on existing
knowledge
Everyone Take into account the human needs
always Document assumptions and unknowns
Document human insights

59 Part 4: Deliver
12.1.1 Exploration
The strategic lead and the scientific lead need to include an HCD approach in the setup of new projects. In order to
explore project opportunities in an HCD approach, they need to start from problems addressed by local stakeholders and
possible end-users.

12.1.2 Proposal writing + PID

Additionally, the project goals should be formulated in a way that reflects this human-focus; explaining the human-needs
that the project is solving. The HCD team can help in this phase by providing insights from previous interaction with local
stakeholders. Additionally, the HCD team can help in formulating both the project goals and the proposed end-user.
While doing so, unknowns and assumptions are documented for future codesigns.

In this phase, there will be communication with the National Society/Group for which the product is intended. During this
contact, the strategic/scientific lead has the responsibility not to start by presenting possible solutions (existing products)
as this creates a bias and makes it more difficult to understand the need.

Throughout the process of applying for funding, a budget has to be made for the project and its activities. The strategic/
scientific lead and the project/product manager are responsible for this. In order to ensure an HCD approach, budget
needs to be available for participatory approaches with the user such as codesigns and user-testing. Budget and planning
also needs to take into account iteration cycles based on insights from codesigns and user testing.

12.1.3 Feasibility study

Once funding is secured, the definition of the project goals and end-user is continued by the project and/or product
manager. The HCD team can now help by gathering new information through codesigns. This information gathered by
the HCD team is also analyzed and turned into a persona journey. These insights help sharpen the project goals and the
user definition and are input for prototyping.

12.1.4 Model building

In the following phase, the product/project manager and the development team together work on developing the model.
While doing so, they have to document any assumptions they use or any information they miss from the user. The HCD
team can discuss these points during their ongoing codesigns.

12.1.5 Product development

The project/product manager is responsible for defining the system requirements. This is done in an HCD manner by
basing the system requirements on the human-centered project goals. Additionally, the persona journey helps them
understand the user activities and responsibilities, which will help in defining an allocation of function between the
product and the user. Before the front- and back-end developers start working on the product, the HCD team has gone
through a number of iterations of designs and user testing in order to minimize assumptions in design.

12.1.6 Implementation, support, evaluation

The product/project manager is responsible for creating an implementation and support plan for the product. They can
use the codesign and persona journey insights in order to understand the need for implementation support and support
during use. The strategic/scientific lead and the product/project manager is responsible for making an evaluation plan. By
using the human-centered project goals they can measure the human-value of the product.

12.1.7 Throughout the project

Throughout the project, it is important that everyone involved actively documents any unknowns and assumptions used
in the project. Everyone involved has to understand why they are doing their activities from a human perspective which
problem is solved for whom?

12.2 Design: Communication materials

Based on the responsibilities as described four types of HCD responsibility groups can be defined that need guidance in
implementing HCD.

The first group consists of everyone within 510, including both the staff members and the volunteers. Everyone in the
team should have a basic understanding of an HCD approach and why it is used in 510. Additionally, everyone can help a
human-centered approach by taking into accounts human needs and understanding when assumptions are made in their
development in order to communciate them to the HCD team for testing.

The second group are 510 staff and HCD volunteers. This is the group that needs to have an overview of the HCD
methods and their link to the project. 510 staff needs this as they will be part of project meetings in which HCD work will
be discussed and because they will directly see how HCD results nfluences their work. Additionally, HCD volunteers want
to understand how their work is linked to other HCD methods and how their work is being used in the larger 510 project.

The third group consists of leads and project management. They need to understand not only why HCD is important and
what HCD does but also when they have to engage the HCD team within the project.

60
The last group are the HCD volunteers. They need to not only understand HCD in general, and how HCD is linked to the
project but also how they can perform the HCD methodologies. Whereas they are currently guided in this by the HCD
staff members, having communication materials on the methodologies will not only help the volunteers become more
autonomous and the results become more consistent but it will also serve as documentation for the methods developed
by the HCD team.
Table 9. Overview of designed communication materials and their uses

Communication Target It will help Why is it needed In what

material audience situation will it
help?
Why HCD? Everyone Provide an understanding of In order to have a basic Throughout all
within 510 the philosophy of HCD and understanding of the goal of the activities
HCD introduction (staff and the role of HCD within 510 HCD team, and the meaning of
slides volunteers) an HCD approach in projects – it
can help everyone apply this
way of thinking and it can help
conversation with the HCD team
What does HCD Project staff Provide an overview of all It can help gain trust in HCD When
do? and HCD HCD activities within the methods, create overview communicating
volunteers project structure and the regarding HCD activities and with
HCD Workflow output of the HCD activities provide clarity when working stakeholders
overview and how they will be used in together with the HCD team and users,
the rest of the project when working
together with
HCD
When to do Leads, Provides an understanding Help understand when to When involving
HCD? project of the goal of the HCD involve HCD in the project HCD in a
manager activities and how the results project
Explanation on and product can benefit the project
how to use HCD manager
in your project
How to do HCD? HCD Gives a detailed explanation Supports the HCD staff When a
volunteers of how to perform HCD in explaining the HCD volunteer
HCD volunteer activities methodologies to the HCD starts at 510
modules volunteers or is being
trained in a new
methodology

Based on these groups and their HCD responsibilities, four types of communication materials are designed for 510 (Table
9 and Figure 18);

1. A slide-deck to understand HCD in 510, which is aimed at all staff and all volunteers.
2. An overview of the workflow of HCD within 510, which is aimed at all staff and HCD volunteers.
3. An explanation of how to engage HCD within a 510 project. This is catered to project leads, such as strategic
and scientific leads or project and product managers.
4. A proposal for HCD methodology modules, which is meant for HCD volunteers in order to get a first
understanding of an HCD methodology that they want to employ.

Figure 17 shows how the previous two elements (role and workflow) are used in the communication materials.

roles of HCD in
why HCD?
510

embedded what does HCD

workflow do?

when to use HCD?

HCD methods how to do HCD?

Figure 17. A visual overview of how the different elements are embedded into the communication plan for 510 HCD

61 Part 4: Deliver
 Introduction to HCD
All of 510

Explanation of HCD methodologies Explanation of HCD work

HCD volunteers 510 project staff and HCD volunteers

Explanation: how to involve HCD

Leads and management staff

Figure 18. The 4 communication materials

12.2.1 General introduction of HCD in 510

Target audience: All 510 staff and 510 volunteers

Firstly, everyone in 510 needs to understand the HCD approach and the philosophy in order to understand the meaning
of HCD and how applying an HCD approach can be of value to 510.

For volunteers starting at 510 an introduction module is already being used. This is a slideshow that can be viewed
and gone through autonomously in order to get a basic understanding of 510. A similar introduction module has been
developed as an introduction to HCD, which can be found in Appendix F. These same introduction slides can be used
during HCD lunch presentations.

12.2.2 An overview of the HCD workflow in 510

Target audience: 510 project staff and HCD volunteers

Next, 510 staff and HCD volunteers need to gain an understanding of what activities are done by HCD and how they are
integrated into the 510 projects. It should be clear what will come out of the HCD activities and how this will help the
product development. In order to communicate this, the visualization of the embedded workflow design can be used
(Figure 16).

12.2.3 How to use HCD in a project

Target audience: Strategic and scientific lead a project or product management

For 510 leads and project staff, it has to be clear when they need to involve the HCD team in the project. To be able to do
so, they should understand which HCD activities are relevant to them and how they will benefit from the HCD method.
This should be done by not only discussing in which phase the method should be employed (as is clear from the overview
of HCD activities) but also how the output of the HCD activity can help them. An overview for this target audience can
be seen in Figure 19. In this overview, the HCD activities are shown as linked to the 510 projects and the responsibilities
of the project managers (such as setting project goals and understanding the user workflow). In order to communicate
that user testing and prototyping need to be applied together, these two activities are shown as one element of HCD to
involve in the project in order to ensure that budget is only released for both activities at the same time.

Additionally, during the activities, more collaboration with the 510 staff is set up (e.g. by a first fill of the persona journey
and the collaborative setup of the codesign questions and information goals) in order to ensure the needed information
is gathered and in order to create understanding and trust among 510 staff members. By getting an initial understanding
of HCD methods and by being involved in the setup of the codesigns, it is more apparent what information is relevant
for the HCD team and thus what information (e.g. gathered in calls or meetings) is important to document for use by the
HCD team. This is especially important (first) for the strategic/scientific leads and (later) for project/product managers as
they are most involved in the project. 

62
 Communication material: When to do HCD? How to involve HCD in your project.
An overview for 510 leads, project and product managers.

510 project activity HCD support

Exploring a new project opportunity Review HCD database
Would you like to know what the people you want to help are During codesigns for previous projects, challenges that
exploration

doing, what challenges they are facing and what they see as might be insightfull for a new project might have come to
opportunities for improvement? light. By checking the HCD database when starting a new
Project

project, projects are Human-Centered from the beginning.

Additionally, before you ask the same person again, make
sure you check with HCD who they have talked to already!

Do you have a clear human-centered project goal? Strategyzer sheets

Proposal writing

Who are you going to help do what? And how are you going Strategyzer sheets help writing a proposal by creating
to do that? overview and formulating goals for the entire project in a
structured manner. Additionally, they help you pinpoint the
Have you defined the user? (A person, not a department end-user you are designing for. The HCD team can help you
or a National Society!) use these strategyzer sheets. The first round of filling this in
Have you defined a user group that is specific enough so that is not only to gain insights, but also to understand what is
you could implement it right now with your current contacts? known and what is unknown. This helps in the development
/ PID

of the codesign interview guide.

What do you know about the user’s workflow you will Codesign
add to? Codesigns are the way in which data is gathered in a Human-
What digital tools do your users use? What information do Centered way. This can then be used both to refine the
they have? When do they trust information? How do users previous steps and to base designs on. Codesigns are done in
make decisions? a way to minimize bias and to get the most realistic insights.

Persona journey
Throughout

A persona journey does two things. First, it maps aspects of

a user- such as digital literacy and responsibilities in case of
project

a disaster. It also gives an understanding of the workflow, for

example what information is available at what time and what
decisions are made.

Are you going to develop a user-interface? (email/alarm/ Iterative development and user testing
development

dashboard) Development is an iterative process. It starts with a paper

How would the user like to get the new information prototype in order to get feedback from users on the
presented? When? Through what platform? How should it functionalities. Then a XD prototype is made in order to test
Throughout Product

look like? the interface and visual elements with users. With the XD
wireframe a final user test can be done and the developers
can use this as a guide in their work.

Have you made any assumptions you want to check? Codesigns, User-testing
Are there any unknowns or assumptions made in the previous Codesigns and User-testing are two ways to test assumptions
steps? about the user and their context.
project

Figure 19. An explanation of how to engage HCD in a project for 510 leads and management

63 Part 4: Deliver
12.2.4 HCD method modules
Target audience: HCD volunteers

In addition to the previous communication materials, a more elaborate explanation on the separate methodologies is
needed in order to enable the volunteer to work autonomously on tasks. These method modules are made to limit the
time spent by HCD staff explaining the methodologies to new volunteers. This more in-depth information for the HCD
volunteers can be incorporated into additional introduction modules, for which a template has been developed. The
module template can be found in Appendix G.

The modules are made in order for the volunteer to understand the goal of the methodology, the output of the
methodology, how it will be used in the larger development process, the steps of the methodology and how to document
the work.

The HCD team will develop their methods and tools further. When a new method is added, the volunteer developing the
workflow of the method can document this into the module template and create a slideshow, so that future volunteers
who want to use that method get an initial understanding of the method autonomously.

64
 13. Conclusions

Several conclusions can be drawn regarding the application of HCD in response technology development from the 510
case study. They are discussed below based on the sub-research questions from the Discover, Define, Develop and Deliver
phase and the main research question of the report.

Discover: What are challenges towards applying HCD in the development of data and digital tools for
humanitarian response?

Define: What are the required elements of successful implementation of HCD in the development of data
and digital tools for humanitarian response?

From the Discover analysis, a number of enablers and challenges is found in the application of HCD in humanitarian
software development for the case of 510. The challenges are clustered into three main lessons in implementing HCD in
humanitarian software development (a, b and c). In the Define chapter these lessons are translated into three required
elements of embedded implementation of HCD in humanitarian software development (1,2,3);

Firstly, (a) HCD is already practiced in many ways within current projects outside of the HCD team, so there is a need for
(1) a clearly defined role for HCD within the organization. Secondly, (b) an HCD approach needs to be interactive with the
existing development workflow. Therefore (2) an embedded workflow of HCD methodologies that is linked to the larger
product workflow is required. Thirdly, (c) the embedded application of HCD in all projects relies on the inclusion of the
HCD approach and the HCD team in numerous parts of the project and by numerous people involved. Therefore (3) a
communication plan is required that helps guide the 510 team in the implementation of HCD across the organization. It
should be noted that the three elements are interlinked; The defined HCD role largely determines the methodologies and
workflow and both the role and the workflow are used as means of communication in order to guide implementation.

Develop: What are the needs for HCD within 510 in the development of data and digital tools for
humanitarian response?

In order to Develop the three elements of embedded implementation of HCD for 510, three needs for the application
of HCD in response technology development are identified. The first need is ensuring that the project is solving the right
problem for the right person. The HCD team can facilitate this through the formulation of human-centered project goals.
The second need for HCD of 510 is to create an understanding of the user and their context. The HCD team can facilitate
this through participatory methods with the user and analyzing these human insights. The third need for HCD is iterative
development of a suited and usable user-interface for software products. By iteratively prototyping and gathering
feedback from users, the HCD team can help increase the suitability of the product for the context in which it will be used.

Deliver: How can Human-Centered Design be applied in the development of data and digital tools for
humanitarian response in the case of 510?

In the Deliver phase, the needs are translated into the role of HCD for 510 and an embedded workflow for HCD within
the 510 product development. Finally, a communication plan is proposed based on an analysis of the 510 team and their
responsibilities for the application of an HCD approach in order to guide the HCD team in embedding the HCD approach
across the organisation.

Main Research Question: How can Human-Centered Design be applied in the development of data and
digital tools for humanitarian response?

The research confirms that HCD can support response technology development and identifies actions to take in order to
implement HCD as well as the role HCD can fulfill within the development process.

The required elements of embedded HCD show the necessary components in order to implement HCD in a response
technology development process (a defined role, a structured workflow and a communication plan). These elements are
in line with the IEI model (Metzker & Offergeld, 2001) but elaborate on it as is further explained in sub-chapter 13.2.

The needs of HCD in response technology development identify three possible roles of HCD (project goal formulation,
generating user understanding and iterative product development). Whereas the application of HCD found in literature
differed per example, the described role of HCD for 510 is in line with elements of the examples.

65 Part 4: Deliver
 .

Figure 20. The updated HCD maturity assessment for the new proposal

13.1 Implementation of results in 510

13.1.1 Improvement HCD maturity
By analyzing the Koos Service design maturity score before (chapter 5) and after the possible implementation of the
design interventions (Figure 20 and Table 10), an assessment of their effect can be made. In the initial analysis, the most
important points of improvement were found to be to involve more people in HCD activities, further develop the HCD
methodologies and consistently apply the methodologies to 510 projects. The proposal partially helps achieve this;

Table 10. Elaborated Service-design maturity ranking with yellow marking showing the original score and blue fill showing the score if
all design propositions are applied (Adapted from Corsten, 2019)

People and resources Tools and Capabilities Organizational Structure Metrics and Deliverables
Individual service design Service design knowledge Traditional siloed Customer centric metrics and
enthusiasts are scattered across and expertise is self-retreived structure, with no assigned deliverables are non-existent.
Explore

the organization in which no (through books / articles / responsibilities on service

budget, time and facilities are trainings), but scattered across design or customer
dedicated to service design. the organization. experience.
First project team is formed Existing (adjacent) capabilities The first multidisciplinary Deliverables of first project
by enthusiasts and / or design are brought together from team is being formed and being created, like a customer
agency. There is missing different people. Organizations the first service design journey map. First measurable
Prove

budget and management buy- tend to buy capabilities initiatives are taking place results are often lacking.
in for service design initiatives. through hiring a design agency. regardless of structure.
More people get involved and Capabilities are spreading Interference with the Project results are becoming
incidental budgets are created outside of the initial team. First existing way of working increasingly apparent. First
for service design projects. employees start to specialise is felt. Silos start to suffer customer-centric KPIs are
Scale

Rooms and facilities are getting and CX / SD departments are under the demands of set specifically for the CX
hijacked for service desgin. being formed. multidisciplinary teams. department.
The majority of people is Unified capabilities, The siloed structure is C-suite is committed to CX and
engaged with service design. methodology and language broken down and design- SD and may even assign a Chief
Dedicated service design around service design, led foundation is being Design Officer. Customer-centric
Integrate

budgets are now in place. as capabilities are being laid. New roles emerge and KPI’s go company wide.
decentralised within each team. are being assigned in each
team.
The entire organization is Strict methodology is set Organizational structure Each initiative is tied to
involved ins ervice design. loose and experimentation allows for close c-creation customer-centric metrics and
Everyone is aware that all is stimulated, as the design of service experience in deliverables. Customer centricity
Thrive

decisions may impact customer mindset is ingrained in the multidisciplinary teams. has become an important KPI
experience. company culture. for the entire C-suite.
• People and Resources: The communication materials help people outside the HCD team to engage with HCD
activities. Additionally, a clear overview of activities can help determine the right hours for HCD and therefor the
right budget.
• Tools and capabilities: The HCD methodologies are not immediately improved because of the design. However, the
methodology modules are meant to help the HCD team unify, structure and communicate the HCD methodologies.
Additionally, the HCD communication materials help spread HCD understanding outside the initial HCD team.
• Organizational structure: The organizational structure is not changed because of the design. However, engaging
the non-HCD staff more with HCD activities can help in the shift towards more interdisciplinary teams.
• Metrics and deliverables: By involving HCD in the beginning of the project and ensuring Human-Centered project
goals from the start, human-centric project KPI’s are promoted. The clear role for the HCD team within 510 and the
communication material on when to involve HCD in projects help HCD to be structurally embedded in projects with
expected HCD deliverables.

66
13.1.2 Implementation
It is not clear yet what parts of the proposal might be implemented and what parts will not. Based on feedback received
throughout the project, it is already clear that many of the insights are relevant to the case of 510.

“
“At the moment HCD could definitely be more R&D. We have identified many products and features
that are not on any of the proposals and that also causing issues”

“Sometimes, HCD would be better to start as part of the proposals… “we will only do this project if
we know & address real needs””

The most notable example of this is that the insights about the unclarity regarding the user of the developed products in
the project stakeholder interviews have been shared when discussing the definition of users.

Some of the insights are already recognized and incorporated before the report was finished:

“
(about the missing user tests for some prototypes) “For this reason, we brought in a corporation to
allow for continual user testing. Outside of the 510 project budgets”

(about the structural documentation of user insights by staff outside the HCD team) “This is now in
azure and collected and structure by product owners (its new as is the function of a product owner
in scrum agile) they are starting to think on behalf of the end user and getting more interested in
the facts that drive the end users)”

(about the varying workforce of HCD volunteers) “We are getting two HCD interns that will work 3
days a week on specific tasks.”

Especially two communication materials; the general introduction to HCD in 510 and the methodology modules for
incoming volunteers were seen as a suitable solution by the HCD staff. Before the Covid-19 epidemic, the methodology
modules were already being developed in collaboration with one of the two HCD staff (who is also the volunteer
management). This however was put on hold once the pandemic became the first priority within the NLRC.

In some situations the responsibilities for HCD within 510 as defined in this thesis should not be performed by the HCD
team. As mentioned in the interviews, 510 works on a wide variety of projects with a wide variety of stakeholders and the
roles of 510 and other project partners vary. If 510 has a solely technical executing role in a project, HCD activities might
be done by other partners within the project consortium.

13.2 Scientific relevance

The three elements of embedded HCD can be seen as an addition to the IEI model (Metzker & Offergeld, 2001) based
on the challenges found in the implementation of HCD in 510. The adaptation makes the model suited for a broader
interpretation of the term HCD and a wider variety of products. In addition to the IEI model, in which an integrated
workflow for HCD activities is developed, two extra steps are added.

• The first step that is added at the beginning is determining the role of HCD within the organization. When
starting up HCD methodologies within an organization, it is crucial to have a clearly defined goal and scope.
The roles of HCD will vary greatly across organizations because the need for HCD varies between organizations.

• After the development of an integrated workflow, as a last step, a communication plan is added. In order to
integrate the HCD philosophy into an organization, not only HCD methodologies need to be added. In
addition to this, the entire organization has to be guided towards implementation of an HCD appraoch. The
HCD team is responsible for this and therefor a plan needs to be made to do so, the communication plan.

Additionally, the number of possible HCD activities used in the IEI method is increased by using HCD methods found in
literature.

13.3 Limitations
A number of limitations regarding the research design should be noted.

For the 510 project stakeholders interviews, the participants were selected through NLRC delegates in the specific project
country. The stakeholders consisted of Red Cross staff and therefor the needs of stakeholders in the project outside the
local Red Cross have not been taken into account.

The analysis of clustering insights and the design was done partly in collaboration with the 510 HCD staff members and
the 510 HCD volunteers and partly individually. The partial individual analysis and design and the involvement of only
design staff and volunteers might have interfered with the objectivity of the design.

The organizational analysis and maturity analysis were made based on internal documentation and collaboration with
the company supervisor for this thesis. Whereas there was a clear intention to describe both the organization and the
HCD team in an objective way, the collaboration and sourcing from internal documentation might have hampered this.

67 .
The selection of literature for the literature research was done in an explorative way rather than a structured way. The
search words were not chosen in a consistent manner and the literature was not selected according to distinct criteria.
Additionally, the lack of previous research for this specific application of HCD made for a need to branch out into other
fields which might have resulted in the use of less suitable papers.

Finally, as the study is done based on one case study, the findings and the proposed development process are not
suggested to be suited for application in all response technology development. However, the findings can serve as an
incentive for other organizations to reflect on their need for a systematic method for understanding user and context in
the development of response technology. Therefore, although the research broadens the knowledge on HCD in practice
within the field of humanitarian innovation, further research is needed in order to make conclusions regarding applicability
across the field.

13.4 Recommendations
13.4.1 Research recommendations
Based on limitations in the research design, further research can be proposed on the implementation of HCD in response
technology. First, research is needed that includes a wider range of interview participants and a larger number of
organisations in order to get a better understanding of the implementation of HCD across different organisations and
from the perspective from more stakeholders. Additionally, resarch is needed that is performed in a collaborative way
throughout in order to minimize subjectivity in the results.

Based on the limitations in literature, more research is needed for the use of HCD methods in the field of disaster
response. Many of the commercial HCD methods need adaptation before they would be suited for application in the
field of humanitarian response. Whereas IDEO (2015) provides a basis for HCD methods for social purposes, it does not
provide in-depth explanation of the methods and is often not suited for disaster response. This lack of knowledge can
be explained because of the complexity, the number of actors and users and the political sensitivities. Examples of areas
in which work could be done are methods for determining the user for response-technology as well as participatory
methods for response-analysis that take into account potential political sensitivities. This can contribute to the ability of
response-technology developers to understand the needs of the user and focus on the most important functionalities of
their products.

13.4.2 Further recommendations for the implementation of HCD in 510

A number of findings from research were not included in the final proposal. Therefore, additional recommendations can
be made for future steps in the implementation of HCD in the case of 510:

From the literature research and the maturity matrix it is clear that an HCD team can have more impact when it is not a
separate entity. Instead, project teams should be multi-disciplinary and include designers. For 510, this would mean for
HCD volunteers to be assigned to specific projects. However, this would require HCD volunteers to have quite a good
understanding of the HCD methodologies performed by 510 as well as to be certainly available for a number of hours a
week for a certain timespan. Currently, volunteers are often not familiar with all HCD activities as they start at 510 and are
not certain of their availability. In the future the HCD team could take into account a minimum availability or knowledge
of certain methods.

As we learn from the needs analysis, implementation is a crucial part of the project that does not yet have a systematic
approach. Additionally, this is a part of the project that requires a good understanding of both the user and the context.
Currently, this task is deemed too large for the very small 510 HCD team to be responsible for. However, once the HCD
team is more established and HCD methods are employed across the 510 staff, an HCD approach to implementation
could be developed.

Within the scope of this thesis it was not possible to develop structured methodologies and corresponding methodology
modules for all HCD methods. Further research into the selection and development of HCD methodologies for the
development response technology is recommended. Future HCD volunteers can develop the methodology and at the
same time develop the methodology module.

Whereas the current design includes introduction modules for HCD activities, one of the mentioned challenges for HCD
volunteers is gaining an understanding of the entire project they are working for. Introduction modules for 510 projects
can be made in order to facilitate the understanding of volunteers in at the start of their work.

68
 14. References

Bourne, S. (2019). User-Centred Design and Humanitarian Adaptiveness. Retrieved from https://www.elrha.org/
researchdatabase/user-centred-design-and-humanitarian-adaptiveness/
Brophy-Williams, S., Harman, J., Leaning, J., Meier, P., Olafsson, G., Pham, P. N., … Segaren, N. (2013). World Disasters
Report. Retrieved from https://www.ifrc.org/PageFiles/134658/WDR 2013 complete.pdf
Buchanan, R. (2001). Human Dignity and Human Rights: Thoughts on the Principles of Human-Centered Design.
Design Issues, 17(3), 35–39. https://doi.org/10.1162/074793601750357178
Coletti, P. G. S., Mays, R. E., & Widera, A. (2018). Bringing technology and humanitarian values together: A framework
to design and assess humanitarian information systems. Proceedings of the 2017 4th International Conference on
Information and Communication Technologies for Disaster Management, ICT-DM 2017, 2018-Janua, 1–9. https://doi.
org/10.1109/ICT-DM.2017.8275687
Corsten, N. (2019). The service design maturity model. Retrieved April 4, 2020, from Medium website: https://
medium.com/this-is-hcd/the-service-design-maturity-model-85935b4959eb
Corsten, N., & Prick, J. (2019). The Service Design Maturity Model. Touchpoint, 10(03). Retrieved from https://medium.
com/touchpoint/the-service-design-maturity-model-84e0b8c82cec
De Leoni, M., De Rosa, F., Marrella, A., Mecella, M., Poggi, A., Krek, A., & Manti, F. (2007). Emergency management:
From user requirements to a flexible P2P architecture. Intelligent Human Computer Systems for Crisis Response and
Management, ISCRAM 2007 Academic Proceedings Papers, (May), 271–279.
Design Council. (n.d.). What is the framework for innovation? Retrieved March 22, 2020, from Design Council website:
https://www.designcouncil.org.uk/news-opinion/what-framework-innovation-design-councils-evolved-double-
diamond
Dunne, D. (2018). Implementing design thinking in organizations: an exploratory study. Journal of Organization Design,
7(1). https://doi.org/10.1186/s41469-018-0040-7
Elmansy, R. (2017). Characteristics of Human-Centered Design. Retrieved January 12, 2020, from Designorate website:
https://www.designorate.com/characteristics-of-human-centered-design/
Fahland, D., & Woith, H. (2009). Towards process models for disaster response. Lecture Notes in Business Information
Processing, 17 LNBIP, 254–265. https://doi.org/10.1007/978-3-642-00328-8_25
Gordon, P., Kramer, J., Moore, G., Yeung, W., & Agogino, A. (2017). A Systematic Review of Human-Centered Design
for Development in Academic Research. 1–32.
Hussey, D. E. (1984). Exploring corporate strategy. Long Range Planning, 17(6), 144–145. https://doi.org/10.1016/0024-
6301(84)90230-9
IBM. (2020). Design thinking re-envisioned for the modern enterprise. Retrieved March 11, 2020, from https://www.
ibm.com/design/thinking/page/framework
IDEO.org. (2015). The Field Guide to Human-Centered Design.
IFRC. (2015). World Disasters Report. Retrieved from http://reliefweb.int/sites/reliefweb.int/files/resources/1293600-
World-Disasters-Report-2015_en.pdf
Jul, S. (2007). Who’s really on first? A domain-level user, task and context analysis for response technology. Intelligent
Human Computer Systems for Crisis Response and Management, ISCRAM 2007 Academic Proceedings Papers, 139–
148.
Junginger, S. (2005). A Different Role for Human-Centered Design within the Organization. Design System Evolution
Proceedings, (January 2015).
Kifle, M., Dittrich, Y., & Teka, D. (2017). Contextualizing user centered design with agile methods in Ethiopia. 2017
IEEE AFRICON: Science, Technology and Innovation for Africa, AFRICON 2017, 911–916. https://doi.org/10.1109/
AFRCON.2017.8095603
Konyndyk, J., & Worden, R. (2019). People-Driven Response: Power and Participation in Humanitarian Action.
Maguire, M. (2001). Methods to support human-centred design. International Journal of Human Computer Studies,
55(4), 587–634. https://doi.org/10.1006/ijhc.2001.0503
Melamed, C. (2017). The race to innovate for development should not leave foundational data systems behind. United
Nations Chronicles. Retrieved from https://www.un.org/en/chronicle/article/race-innovate-development-should-not-
leave-foundational-data-systems-behind
Metzker, E., & Offergeld, M. (2001). An interdisciplinary approach for successfully integrating human-centered design
methods into development processes practiced by industrial software development organizations. Lecture Notes in
Computer Science (Including Subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics),
2254, 19–33. https://doi.org/10.1007/3-540-45348-2_5
Nemeth, A. (2019). Introduction to Human-Centered Design. Retrieved from Movingworlds website: https://blog.
movingworlds.org/an-introduction-to-human-centered-design/
Nielsen, B. F. (2017). Framing humanitarian action through design thinking: integrating vulnerable end-users into
complex multi-stakeholder systems through “Agenda Space mapping.” J. of Design Research, 15(1), 1. https://doi.
org/10.1504/jdr.2017.084502
Nielsen, J. (2006a). Corporate UX maturity: Stages 1-4. Retrieved from NNgroup website: https://www.nngroup.com/
articles/ux-maturity-stages-1-4/

69 .
Nielsen, J. (2006b). Corporate UX Maturity: Stages 5-8. Retrieved from NNgroup website: https://www.nngroup.com/
articles/ux-maturity-stages-5-8/?lm=5-signs-low-ux-maturity&pt=youtubevideo
NNGroup. (2020). Service Blueprinting FAQ. Retrieved March 20, 2020, from https://www.nngroup.com/videos/
service-blueprinting-faq/
Norman, D. (2018). Principles of Human-Centered Design. Retrieved from https://www.youtube.com/
watch?v=rmM0kRf8Dbk
Strategyzer. (2020). The Value Proposition Canvas. Retrieved August 10, 2010, from https://www.strategyzer.com/
canvas/value-proposition-canvas
UN OCHA. (2017). OCHA on Message: Agenda for Humanity. Retrieved from https://www.unocha.org/sites/unocha/
files/OOM Agenda for Humanity.pdf
Wallach, D., & Scholz, S. C. (2012). User-Centered Design: Why and How to Put Users First in Software Development.
In A. Maedche, A. Botzenhardt, & L. Neer (Eds.), Software for people, management for professionals (p. 294). https://
doi.org/10.1007/978-3-642-31371-4
Walters, P. (2005). Knowledge in the making: Prototyping and human-centred design practice. Retrieved from http://
shura.shu.ac.uk/20492/

70
 Appendix A. Interview setup

Discover – interview questions

510 staff interview setup

Participant profile
• Could you describe shortly to me what your role is in 510 and what you are working on at the moment?
• (possible probe: When you finish your work, who do you hand it over to? Who do they hand it over to?)

End-user
• Who is the end-user of your work/the project you are working on?
• What information do you have about the end-user?
• Where do you get this information?
• When and how do you use this information?
• Is there any information that is not available but that you would like to have?

Stakeholder
• Who are the stakeholders in your work/the project you are working on?
• What information do you have about the stakeholders?
• Where do you get this information?
• When and how do you use this information?
• Is there any information that is not available but that you would like to have?

Context
• What is the context of your work/the project you are working on?
• What information do you have about the context?
• Where do you get this information?
• When and how do you use this information?
• Is there any information that is not available but that you would like to have?

510 HCD volunteer interview setup

These interviews follow the 510 HCD codesign setup, but instead used for understanding an HCD volunteers experience
at 510.

Digital literacy / ice breaker

What digital devices and software do you use?

Experience
Could you explain to me how your volunteering journey at 510 has been from the moment you heard about
510?

Ideation
Do you have an idea how your journey volunteering at 510 could have been improved?

Develop - interview questions

510 project stakeholder interview setup
These interviews follow the 510 HCD codesign setup with additional questions relevant to my research added at the end.

Digital literacy / ice breaker

• What digital devices and software do you use?
Experience

• What is your experience with disaster response? Please try to remember one event and explain what happened
and what you did.

Ideation
• Now, imagining a screen in front of you, what would you want to see on this screen to help you with the
experience you just described?

Additional questions
• When would this project be a success for you?
• What have been or do you foresee to be the biggest challenge in this project?
• Who do you see to be the user of the system? Are you one of them?

510 staff interviews - These interviews were the same as the previous 510 staff interviews.

71 .
Appendix B. Wordcloud 510 HCD

72
Appendix C. Worldcloud literature

73 .
 Appendix D. Complete insights overview table

Relevant proposal
Part Source Insight
part

Technical focus across the organization Role

Human-centered organizational values Communication
Access to many possible participants through Red Cross network Scope
Very wide product scope Role & Scope
Role & Scope
Flexible staff
Communication
Role & Scope
Open management
Communication
Role & Scope
Constant development
Workflow
Large number of stakeholders that is different per project Role & Scope
Team-based and project-based structure Recommendations
510 analysis

No clear project structure yet Workflow

Role & scope
Funding approach
Workflow
HCD methodologies not fully developed Workflow
HCD analysis

Role & Scope

HCD methodologies implemented ad hoc across projects
Workflow
Documentation missing Workflow
No clear distinction between scientific and practical projects Scope
Aim to sell current products Role
Time constraint to HCD activities Workflow
510 staff interviews

No clear definition of end-users Role

Staff sees importance of HCD Communication
Many sources of information Role
Missing structure for HCD Workflow
510 Project can be unclear Recommendations
volunteer

Role & Scope

Goal of HCD activities can be unclear
Communication
interviews
Explore

Workflow
Integration of volunteers work with projects unclear
HCD

Communication

74
 No inherent HCD role or scope Role & Scope

HCD for software development is usability design: effectiveness, efficiency and

Role & Scope
satisfaction

Disasters need flexible scenario Persona journey

Role & Scope
Human insight should be more important than design creativity Workflow
Communication
Role & Scope
Often user, tasks and complex are oversimplified in disaster response Workflow

Role & Scope

Disaster systems are often not designed appropriately for context of use Workflow

More elaborate task analysis Persona journey

Role & Scope
Better understanding of user, task and context Workflow

Include types of disaster: scale, type, predictability Persona journey

Workflow
Include stakeholders in HCD activities
Communication
Workflow
Track success
Communication
Find a niche Role & Scope
Integrated teams result in more HCD embeddedness Recommendations

Often more incremental changes than disruptive changes through HCD because Role & Scope
Literature Review

of safety Workflow
Workflow
Timing of HCD not always understood
Communication
HCD reference model Workflow
Role
Need for project goals and hierarchy of goals
Workflow
Role
General understanding of user
Workflow
510 staff interviews

Insurance of relevance project Role

Understanding of workflow Persona journey
Understanding of decision making Persona journey
Implementation unstructured Scope
Role
Stakeholder

User unclear
Workflow
Uncertainty of involvement right stakeholders Scope
interviews
Develop

Difficulty stakeholder engagement Scope

Data gathering through stakeholder engagement Scope

75 .
Appendix E. Value propositions for HCD in 510

76
Appendix F. HCD general introduction modules

77 .
78
Appendix G. HCD methodology modules

79 .
80
 Implementation
HCD HCD Project Proposal Feasibility Database/ Product
support
role method exploration writing study model building development
evaluation
Human-centered
project goals

Strategy
sheets
understanding

Persona
journey
User

Codesign
Interface design

User
testing

Prototyping

81 .
82
83 .
91 .
92