eindhoven university of technology master install base ...kumar, k.b. award date: 2018 link to...
TRANSCRIPT
Eindhoven University of Technology
MASTER
Install base visualization for service marketing
Kumar, K.B.
Award date:2018
Link to publication
DisclaimerThis document contains a student thesis (bachelor's or master's), as authored by a student at Eindhoven University of Technology. Studenttheses are made available in the TU/e repository upon obtaining the required degree. The grade received is not published on the documentas presented in the repository. The required complexity or quality of research of student theses may vary by program, and the requiredminimum study period may vary in duration.
General rightsCopyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright ownersand it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.
• Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain
DEPARTMENT OF MATHEMATICS AND COMPUTER SCIENCE
Master of Business Information Systems
INSTALL BASE VISUALIZATION FOR
SERVICES MARKETING
Karthik B. Kumar
Supervisors:
Dr. Michel Westenberg, TU/e
Mr. Robert Belien, Philips
Committee:
Dr. Michel Westenberg
Mr. Robert Belien
Dr. Remco Dijkman
Eindhoven, December 2017
ii
Abstract
Modern-day technology companies strive to increase their revenue by tapping
into their existing customer base. Formulating new service propositions for sales of
service contracts or spare parts or accessories or upgrades to newer versions of the
same product or sales of a newer better product are some of the ways by which
companies increase their revenues. In any of these cases, it is essential for these
companies to have a comprehensive information about the customer and the product
being used by that customer in order to make the best service propositions possible.
At Royal Philips’ Image Guided Therapy (IGT) division, the services marketing
team is one group that is interested in exploiting its install-base data – a collective
term comprising of customer and product information – for defining new service
propositions. As with any other large amounts of complex datasets, the process of
deriving insights from such data is diminished when exploring raw data. This is where
IGT is looking to use a data visualization tool for analyzing the install base data. While
there are several tools available in the market for such visual analytics, the particular
business requirements at IGT pose a challenge in using any of these tools as-is.
Hence, a structured nine-stage design study was executed in order to design,
develop and evaluate a visualization tool that helps the domain expert to explore
install base data in terms of the geographic spread and profitability. The tool not only
provides an overview of the install base, but also helps to pick out a single installed
product at a particular location and analyze its profitability by displaying how the
service costs of the product have accumulated over time. This study aims to
contribute not just to Philips but also to the larger information visualization design
by presenting a method on how to design and implement a visualization for install
base profitability using different visual encodings. The study also discusses in detail
the results of the evaluation based on the seven guiding scenarios for information
visualization evaluation. The evaluation results showed that the tool was perceived
as useful and that it helps to explore the data faster. The study concludes with a
discussion on the limitations of the tool and scope for further research.
iii
Acknowledgements
This is the culmination of a fight against all odds. I would not have made it until this
point without the constant support all those who stood by my side.
Professor Westenberg, a big thank you for agreeing to be my supervisor for the
second time during my study. Thank you for your supervision and support, especially
for keeping faith and being extremely patient. Robert, heartfelt thanks for your
undaunted support and being such a kind supervisor at work. Professor Dijkman,
thank you very much for kindly agreeing to be on the defense committee.
Appa, Amma – thank you for letting me go after my dream thousands of miles away
from you; I know it was one of the hardest decisions of your life. Special thanks to you
Appa, for trusting me with your lifetime savings; this wouldn’t have been possible
without you taking that risk. Maarten, thank you for pointing me towards this dream,
for your undoubted belief and unshaken support; thanks for being my brother.
Praveena, thanks for making the financial matters easier than it would have been.
Subhash and Kavitha, thank you for your moral support and helping to lower Appa
Amma’s worries about me. Darshan, thank you for helping me carry the final loads.
And Karolina, a super special thank you for being with me at every moment during
the final phases, for constantly providing love and support – you kept me going.
To Heribert, thank you so much for understanding and helping me to balance my
work and studies. Thanks to my program managers Erik, René and Jac for taking some
weight off my shoulders when really needed. Thanks Beunders, for the rides and
conversations during my thesis. Thanks to all my friends from GEWIS and especially
from SCIFI – Anja, Jeroen, Tim, Kagan – for sharing some memorable times together.
Plenty of friends at the university and at Philips have been there for me through thick
and thin times – Anna, Irina, Emma, Frank, Shayo, Ewa, Daphne, Nikola, Dylan, Astrid –
thank you all for the help and the great times. If I forgot to name someone here, it’s
only because of the deadlines.
iv
TABLE OF CONTENTS
ABSTRACT ................................................................................................................................... II
ACKNOWLEDGEMENTS......................................................................................................... III
LIST OF FIGURES .................................................................................................................... VII
LIST OF TABLES ..................................................................................................................... VIII
ACRONYMS ................................................................................................................................. IX
INTRODUCTION ................................................................................................. 1
1.1 Thesis Structure ........................................................................................................................... 1
1.2 Background .................................................................................................................................... 1
1.2.1 About Royal Philips ........................................................................................................ 2
1.2.2 What is Install Base ........................................................................................................ 2
1.3 Motivation ...................................................................................................................................... 2
1.4 Problem Statement ..................................................................................................................... 3
RELATED WORK ................................................................................................ 5
2.1 Applications within Philips ..................................................................................................... 5
2.1.1 SmartPath Tool................................................................................................................. 5
2.1.2 Profitability Tool .............................................................................................................. 6
2.2 Other data visualization tools ................................................................................................. 7
2.2.1 Tableau ................................................................................................................................ 7
2.2.2 Qliksense ............................................................................................................................. 8
2.2.3 Microsoft Power BI ......................................................................................................... 8
2.2.4 More data visualization tools...................................................................................... 9
v
DESIGN STUDY METHODOLOGY ................................................................ 10
3.1 Design study suitability ......................................................................................................... 10
3.2 The nine-stage framework ................................................................................................... 11
3.2.1 Precondition phase ...................................................................................................... 12
3.2.2 Core phase ....................................................................................................................... 13
3.2.3 Analysis phase ............................................................................................................... 15
3.3 Pitfalls in a design study ........................................................................................................ 16
DESIGN STUDY EXECUTION......................................................................... 17
4.1 Precondition phase: Learn .................................................................................................... 17
4.2 Precondition phase: Winnow .............................................................................................. 17
4.3 Precondition phase: Cast ....................................................................................................... 18
4.4 Core phase: Discover ............................................................................................................... 18
4.5 Core phase: Design ................................................................................................................... 20
4.5.1 Data abstraction ............................................................................................................ 20
4.5.2 Encoding .......................................................................................................................... 22
4.6 Core phase: Implement .......................................................................................................... 30
4.6.1 Early prototypes ........................................................................................................... 30
4.6.2 Final application ........................................................................................................... 33
4.7 Core phase: Deploy .................................................................................................................. 33
4.8 Analysis phase: Reflect & Write .......................................................................................... 33
WALKTHROUGH OF THE APPLICATION ................................................. 34
5.1 Overview of installed base .................................................................................................... 34
vi
5.1.1 The map ........................................................................................................................... 34
5.2 Profitability of an individual installed product ............................................................ 39
5.2.1 Profitability in various colors .................................................................................. 41
EVALUATION AND RESULTS ....................................................................... 43
6.1 Evaluation approach: The Seven Guiding Scenarios .................................................. 43
6.2 Discussion of the results ........................................................................................................ 47
CONCLUSIONS .................................................................................................. 49
7.1 Summary ...................................................................................................................................... 49
7.2 Limitations .................................................................................................................................. 50
7.2.1 Limitations in features ............................................................................................... 50
7.2.2 Limitations in evaluation .......................................................................................... 51
7.3 Further research ....................................................................................................................... 52
BIBLIOGRAPHY ....................................................................................................................... 53
APPENDIX A DESIGN STUDY PITFALLS ........................................................................... 57
APPENDIX B PROPERTIES OF OBJECTS IN THE DATA MODEL ............................... 58
APPENDIX C EVALUATION QUESTIONNAIRE AND RESPONSES .............................. 62
APPENDIX D TECHNICAL DETAILS OF TOOL................................................................. 63
vii
List of Figures
Figure 2.1 Tableau mapping capabilities ....................................................................................... 7
Figure 2.2 A dashboard using QlikSense ....................................................................................... 8
Figure 2.3 Power BI cartogram ......................................................................................................... 9
Figure 3.1 Design study suitability axes ..................................................................................... 11
Figure 3.2 The nine-stage framework classified into three phases ................................. 12
Figure 4.1 Data Model – Installed Product ................................................................................. 21
Figure 4.2 Data model: Service Work Order ............................................................................. 22
Figure 4.3 GlottoVis: an example of a graduated symbol map ........................................... 23
Figure 4.4 Example of a hue circle (A Field Guide to Digital Color, Maureen Stone, A
K Peters, Ltd.) ............................................................................................................................... 25
Figure 4.5 Stacked Graph of Unemployed U.S. Workers by Industry .............................. 28
Figure 4.6 Prototype 1: Overview of installed base – dashboard view .......................... 31
Figure 4.7 Service touchpoints – a static visualization ......................................................... 32
Figure 5.1 Overview of install base ............................................................................................... 34
Figure 5.2 Overview of install base - filters collapsed ........................................................... 35
Figure 5.3 Filter on end of life ......................................................................................................... 36
Figure 5.4 Overview of install base filtered on end of life ................................................... 36
Figure 5.5 Filter on age ...................................................................................................................... 37
Figure 5.6 Overview of installed product filtered on age ..................................................... 37
Figure 5.7 Filter on end year ........................................................................................................... 38
Figure 5.8 Overview of install base filtered on contract end date .................................... 38
Figure 5.9 Filter on end month ....................................................................................................... 39
Figure 5.10 Service work order costs .......................................................................................... 40
Figure 5.11 Contract costs zoomed in ......................................................................................... 40
Figure 5.12 Contract profitability: Green ................................................................................... 41
Figure 5.13 Contract profitability: Orange ................................................................................. 42
Figure 5.14 Contract profitability: Red ....................................................................................... 42
List of Tables
Table 1 User story: Analyze install base ..................................................................................... 19
Table 2 User story: Analyze service activities .......................................................................... 19
Table 3 Data objects and their source applications ............................................................... 20
Table 4 Cluster symbol color design logic .................................................................................. 26
ix
Acronyms
BI: Business Intelligence
IB: Install Base
IGT: Image Guided Therapy
BPMN: Business Process Modelling Notation
1
Introduction
This thesis is the result of the graduation project for the Master’s program in
Business Information Systems, a combined program by the Department of
Mathematics & Computer Science and the Department of Industrial Engineering &
Innovation sciences at the Eindhoven University of Technology (TU/e). The
graduation project was carried out under the supervision of the Visualization
research group at the department of Mathematics & Computer Science and was
executed in a company setting at Royal Philips N.V. within the Image Guided Therapy
(IGT) business unit.
1.1 Thesis Structure
This thesis study is split into several chapters. CHAPTER 1 provides an
introduction to this thesis study, the background, motivation and the problem
statement. CHAPTER 2 describes related data visualization tools available publicly as
well those that are existing within Philips. CHAPTER 3 describes the problem-driven
visualization research methodology applied in this thesis study. CHAPTER 4
describes the development of the prototype application including the data model that
is used for visualization. CHAPTER 5 presents a walkthrough of the prototype
application by going through its functionalities. CHAPTER 6 describes the evaluation
process and a discussion of the results. Finally, CHAPTER 7 will conclude this thesis
with a summary of the thesis study, limitations of the current work and scope for
further research.
1.2 Background
Every modern-day technology company strives to increase its revenue by
tapping into its existing customer base. There are several ways of doing this - sale of
service contracts or spare parts or accessories, or upgrades to newer versions of the
same product or sale of a newer better product. In any of these cases, it is essential
for these companies to have a comprehensive information about the customer and
the product being used by that customer in order to make the best sales/service
propositions. Royal Philips is one such organization that collects and maintains
“install base data”– a collective term comprising of customer and product information
– as an input for its services marketing.
2
1.2.1 About Royal Philips
Royal Philips N.V. (henceforth referred to as “Philips” or simply as “company”)
is a leading health technology company focused on improving people's health and
enabling better outcomes across the health continuum. From healthy living and
prevention, to diagnosis, treatment and home care, Philips leverages advanced
technology and deep clinical and consumer insights to deliver integrated solutions.
Headquartered in the Netherlands, the company is a leader in diagnostic imaging,
image-guided therapy, patient monitoring and health informatics, as well as in
consumer health and home care. Philips' health technology portfolio generated sales
of EUR 17.4 billion in 2016 with sales and services in more than 100 countries [1].
1.2.2 What is Install Base
Install base, also known as installed base, user base or install(ed) user base, is a
measure of the number of units of a product or a service that are actually in use. This
is not the same as the market share, which only refers to the sales or a product or
service over a particular period of time. Install base is also not the same as the total
number of units of a product or service sold at a given moment in time, termed as
cumulative sales numbers, since some of those units could be out of use due to a
breakdown, or being obsolete or having gone missing. [1]
Install base data at Philips comprises of data that describes what products are
being used by which customers, where these products are located, what kind of
hardware and software configuration are they on and the whether these systems are
in operation or not. In addition there are details such as the list of spare parts that are
being used in these systems.
1.3 Motivation
The worldwide customer base of Philips also consists of hospitals, which
among other installed Philips products, have Image Guided Therapy (IGT) systems -
complex systems that use X-ray and other imaging techniques to perform minimally
invasive operations [3]. These systems remain in operation for several years and
require a range of service actions throughout their lifetime. This is where Philips
installed base data comes into play a major role.
Some of this data is maintained for a number of years as mandated by
regulatory bodies. Thus, given the complex configurations of these products, the
various processes attached to the service delivery and the need to maintain historical
data, this installed base data tends to grow immensely in volume and complexity over
3
a few years. The challenge, as with any huge dataset, is how to extract information
that is useful for the business to achieve its goals. There are several ways to analyze
a given data set and an information visualization is one such tool that helps to explore
the data for deriving meaningful insights.
However, when there is a precise question to be answered, an information
visualization system may not be the best tool to be used. Instead, a query can be
formulated and dispatched to a database or to a search engine, which could provide
the answer to that specific question quickly and accurately. On the other hand, an
information visualization system appears to be most useful when a person simply
does not know what questions to ask about the data or when the person wants to ask
better, more meaningful questions. A visualization helps people to rapidly narrow in
from a large space and find parts of the data to study more carefully. [The Value of
Information Visualization, page 2]
1.4 Problem Statement
As with any other commercial organization, Philips strives to maximize its
revenues with new service offerings and to minimize its operating costs while
delivering service. As a first step, Philips tries to leverage on its install base data and
derive insights to optimize its current service delivery processes. The next level of
deriving insights into the install base data would be for the purpose of approaching
existing customers with newer and better service propositions.
The outcomes of such analyses is particularly interesting for the Service
Marketing group at the IGT business unit which develops new service strategies that
are taken up for implementation by the customer-facing marketing teams. The
traditional way of doing such analyses would be to download all the relevant data into
spreadsheet tools like Microsoft Excel and create table summaries and visualizations
that are built in. But this poses two challenges that seriously limit such an analysis.
Firstly that install base data is huge, with thousands of records and secondly, that the
visual analytics capabilities provided by spreadsheet tools is very limited in terms of
the interactions that can be performed for exploring the data. Hence there is a clear
need for a custom visualization dashboard, which brings us to our research question:
How to design a visualization tool that helps to analyze install base data
for formulating better service propositions to existing customers?
In order to make better service propositions to existing customers, the data
analyst needs to have access to two kinds of information. One, an overview of the
entire install base in order to decide which existing customers should be approached.
4
And two, an overview of the service history of each installed product that the
customer is using. Thus, the goal of this thesis study is to design and implement a
visualization based on specific business requirements using a standard methodology.
This goal is split into two objectives: to develop a visualization that provides an
overview of install base and to develop a visualization that summarizes the service
activities performed on an individual system.
5
Related Work
This chapter describes installed base related business analytics tools within
Philips. It also presents publicly available business intelligence tools that support
data analysis through visualizations and the extent to which they could support the
current visualization requirement.
2.1 Applications within Philips
Like any other modern technology company, Philips makes use of several
information systems in order to enable efficient functioning of both inward-facing1
business processes such as product lifecycle management, production planning,
install base management, etc. and outward-facing2 business processes such as
customer relationship management, supplier relationship management, etc. Out of
these myriad number of information systems there are also business intelligence
applications that aid in performing various analytics including those that use install
base as their source.
A brief review of information systems within Philips was performed to identify
which systems make use of install base data for analytics. Although there were more
than five applications that were found to use install base data for various purposes,
there were exactly only two applications of interest, which used install base data for
assisting in making decisions for services marketing. Due to confidentiality reasons,
screenshots of either of these applications and in-depth details are omitted in this
thesis. Instead, the important functionalities and the unsatisfied business needs are
highlighted in the following sections.
2.1.1 SmartPath Tool
The SmartPath tool is a software application used for install base data
analytics. It consists of two parts – the IB Viewer and the IB Tool – of which the IB
Tool is a decision-tree based suggestion software to list the possible upgrades for
products in the install base. For example, if the tool finds a particular Philips Magnetic
Resonance Imaging system at a specific customer site to be running an older software
1 Used only by authorized employees of the company 2 Used also by authorized users outside the company such as customers and suppliers
6
application suite with fewer features than a newer software application that is more
advanced, the IB tool will list this installed product as a potential “lead”. The sales or
account manager assigned to that region or customer will pick this up as an
opportunity to approach the customer with a sales proposition to upgrade the
application suite on the installed product.
The IB Tool is devoid of any information visualization and instead consists of
a tabular report-like interface. The IB Viewer, on the other hand, is an exploratory
information visualization tool that tries to answer several direct questions about the
install base. The IB viewer contains several (12 to be exact) visualizations that could
help a domain expert to explore the install base data. Some examples of these
visualizations are –
1. A column chart of new installations per year that shows the number of new
systems that were installed in a particular year
2. A column chart of new installations per month, which shows the count of
new systems that were installed in a particular month of a particular year
3. A column chart of End of life per year, which shows the number of systems
reaching end of life in a particular year
4. A column chart of the age of systems, which shows the total number of
systems of a particular age
All of the visualizations on the SmartPath IB Viewer use the product
configuration data and none of the visualization take into consideration financial
aspects of the installed products such as the revenues earned and costs incurred on
the associated service contract. There is also no visualization to depict the service
history of the system to consider before making a new sales proposal for upgrades.
For getting these details, the domain expert needs to look into another application,
the Profitability tool described in the following section.
2.1.2 Profitability Tool
Profitability tool is another software application within Philips’ customer
analytics platform. It provides several visualizations that provide different kinds of
information. This information includes profitability per country, per market, per
business unit, with options to filter on other parameters such as product type.
However, all these visualizations are presented as a bubble chart [4] and not on a map
(so not cartograms).
7
While the tool does a good job at providing an overview of the profitability at
a high level, it fails to do so at an individual product level since none of these
visualizations provide an overview of the service activities. In fact, service work order
data is displayed in tabular format and no visualization is available for the same.
When a user drills down to a particular product, she needs to go through the service
work order data in order to inspect the service history.
2.2 Other data visualization tools
Several data visualization tools that focus on data analytics and which offer
easy configurability are publicly available in the market. While some are web-based,
there are also desktop applications that could be used to visualize and analyze a wide
variety of datasets. Upon searching for the top data visualization tools used for
analytics, three tools often appear in the search results [4]. Although several other
tools were looked at, only these three tools – Tableau, Qlik and Microsoft Power BI –
were selected for further analysis since these were the only three companies listed as
Leaders in Gartner’s 2016 Magic Quadrant for Business Intelligence and Analytics
Platforms [9]. These applications were also selected due to their ability to visualize a
variety of datasets including geographic maps and the ease of building and
customizing a visualization without the need for any programming scripts.
2.2.1 Tableau
Tableau is an award winning [5] software that is also perhaps the best known
platform for data visualization [4]. Tableau provides several built-in visualizations
that can used to produce interactive visualizations. It also provides map data
visualization capabilities that could be leveraged to visualize geographic data [6].
Tableau is also well suited to handle large amounts of data.
A study of the map visualization features available in Tableau revealed that it
could display a specific set of symbols [7] as well as certain graphs [8] on the map as
shown in the Figure 2.1 below.
Figure 2.1 Tableau mapping capabilities
8
Color coding based on a specific scale was available. However, Tableau misses out
features of displaying custom icons (or symbols) and the capability to cluster them
or separate them based on the zoom level. Also, the ability to overlay different kinds
of visualizations such as an area and bar chart although present are limited in terms
of interactivity.
2.2.2 Qliksense
Qliksense, a software developed by Qlik, provides drag-and-drop creation of
interactive data visualizations that help in data discovery and is available in desktop,
server and cloud versions. The June 2017 version of Qliksense offered a mapping
capability but the advanced features were available for those who have to knowledge
of developing applications on the Qlik platform [10].
However, as with Tableau,
the visualizations do not provide
advanced cluster/split icons in its
map views. Also, the tool does not
provide options of combining
multiple visualizations into one. A
point to be noted is that the
mapping capabilities of Qliksense
requires buying of an extra value
added product named Qlik
GeoAnalytics [11].
2.2.3 Microsoft Power BI
Power BI is a suite of business analytics tools by Microsoft. It enables business
users to analyze data and build dashboards using customizable visualizations that can
be based on various data sources. Power BI desktop also helps to author reports and
combine data from several data sources. Power BI provides around 85 visualizations
out-of-the-box that can be customized extent by business users in order to meet their
information or analytics needs.
Figure 2.2 A dashboard using QlikSense
9
Although Microsoft Power
BI has support for map
visualizations such as a drill-down
cartogram [12], it fails at providing
features such as clustering of map
icons and their splitting up based
on the zoom level. Its visualization
capabilities are also limited in
terms of overlaying multiple types
of visualizations in order to get
different insights about a given
dataset.
2.2.4 More data visualization tools
Apart from detailed exploration of the three visual analytics tools, other tools
such as plotly [13], DataHero [14], Chart.js [15], FusionCharts [16] and Google Charts
[17] which provide customizable visualization functionalities were considered. At the
time of the project, none of these offered any advanced visualization capabilities that
were being looked at as in case of Tableau or Qliksense.
When it was certain that none of these tools provided all the features that we
were looking for, JavaScript libraries that could be used to develop new visualizations
from scratch were explored. These included Processing.js [18], Leaflet [19], D3.js [20]
and C3.js [21].
Figure 2.3 Power BI cartogram
10
Design Study Methodology
The objectives established for this thesis study demand a structured
methodology for developing an information visualization tool. As a matter of fact,
there exists a well-defined framework, namely the Design Study Methodology, for
conducting problem-driven visualization research and has become increasingly
popular over the last decade. Design study papers are also explicitly welcome at
visualization venues such as InfoVis [23]. Hence, this thesis study will adopt the stated
framework and this chapter describes in brief the theory of the said methodology,
while CHAPTER 4 describes how the design study for this thesis was carried out.
Design study is defined as a project in which visualization researchers analyze
a specific real-world problem faced by domain experts, design a visualization system
that supports solving this problem, validate the design, and reflect about the lessons
learnt in order to refine visualization design guidelines. The nine-stage framework is
a methodological framework that provides practical guidance for conducting design
studies. The framework characterizes two axes to reason the suitability of the design
study and provides practical guidance highlighting potential pitfalls for each stage.
3.1 Design study suitability
In order to assess the suitability of the design study, the nine-stage framework
defines two axes. The task clarity axis depicts how precisely a task is defined with
fuzzy on side and crisp on the other [23]. An example of a crisp task is “get the count
of installed products that are reaching their end of life in the year 2019”. For such a
crisp task, it is relatively straight forward to design and evaluate solutions. However,
most domain tasks are often complex and fuzzy. For example a data analyst might
want to look at the correlation of the number of repairs done to the rate of increase
in costs incurred on an installed product. Such domain tasks are inherently not well
defined and are exploratory by default. The challenge of designing and evaluating
solutions against such tasks is well-understood in the information visualization
community [24].
In addition to the task clarity, there are two other factors to be considered –
the scope of the task and the stability of the task. The goal of a design study is to
decompose high-level domain tasks of a broader scope to a set of low-level abstract
tasks of a narrower scope. With regards to stability, it is considered as a sign of success
if the tasks change after the introduction of the visualization tool or after new
11
abstractions that cause a re-conceptualization of the work. However, changes from
other factors such as change of strategy in a company setting or change of research
focus in an academic setting could have adverse effects on the design study. The
information location axis characterizes how much of the information remains as
implicit knowledge the head of the domain expert versus how much of the data is
available is stored in a digital form on a computer. It is noteworthy to mention that
movement along one axis often results in movement along the other, i.e., increased
task clarity can facilitate a better understanding of the derived data needs [24].
Figure 3.1 shows how design studies fall along the two dimensional space
spanned by the two axes. The red and the blue areas at the periphery indicate
situations in which a design study may be the wrong methodological choice. The red
area represents a scenario where an effective visualization is not possible due to lack
of enough data and the blue area represents the situation where the task clarity is so
crisply defined and enough information is computerized that a complete automation
should be possible through algorithms. Since many real world analysis problems are
not so well defined, design studies could be a useful step towards achieving this full
automation.
3.2 The nine-stage framework
The nine-stage framework is a methodological framework that provides
practical guidance for carrying a design study. As the name suggests, it consists of
nine stages that are grouped into three categories – precondition, core and analysis
Figure 3.1 Design study suitability axes
12
phases. This is a linear framework in which one stage follows another and each stage
depends on another creating a network of interdependent stages.
As depicted in Figure 3.2, the nine-stage framework works in linearity.
However, it doesn’t mean that one has to follow/complete each stage before going to
the next one. The process is iterative, meaning that the stages often overlap and work
together and hence allows the visualization researchers to go backwards for refining
the project.
3.2.1 Precondition phase
This phase consists of learning visualization techniques, and then finding and
filtering potential collaborations. This phase focuses on adapting the visualization
researcher for the project and finding the collaborations with experts who fit the
project and comprises of 3 stages
3.2.1.1 Learn
Developing a good information visualization requires a good knowledge of the
visualization literature, including visual encoding, interaction techniques, design
guidelines and evaluation methods. Solid knowledge of a background is good for
effective design study and can be useful in every stage. It can help to choose good
solutions over the bad ones in a design stage and can accelerate the process of finding
the right visualization toolkits and algorithms in the implement stage. In the deploy
stage, it can help how to correctly evaluate the tool in the field, and in the reflect stage
for comparing findings. Lack of knowledge of the visualization literature could lead
to mistakes in design study.
Figure 3.2 The nine-stage framework classified into three phases
13
3.2.1.2 Winnow
The goal of winnow stage is to select the most promising collaborations for the
project. It involves a process of separating the good collaborations from the bad ones,
because careful selection is required for finding a good match. It is good to find more
potential collaborators and further narrow down the potential collaborators based
on the considerations and after discussing the main goals and prototyping etc. The
main strategy here is to talk with many, stay with few and start early, and always keep
looking.
3.2.1.3 Cast
In every collaboration there are different roles, two critical roles in a design
study collaboration is the front-line analyst and the gatekeeper. The front-line analyst
is the expert doing the actual data analysis and will use the new visualization tool.
The gatekeeper is the one with the power of decision about the project. Whether to
approve or block the project, to release the data, to authorize people who will spend
time on this project.
It is possible that a single person might hold multiple roles at once, but the
allocation of the roles to people can differ from project to project. Several additional
roles are useful, but not crucial, and thus do not need to be filled before starting
project. Connectors are people who connect the visualization researcher to other
interesting people, usually front-line analysts. Translators are people who are very
good in abstracting their domain problems into a more generic form, and relating
them to larger-context domain goals. Co-authors are part of the paper writing process;
often it is not obvious until the very end of the project which, if any, collaborators
might be appropriate for this role.
Role of fellow tool builders should be treated with a very good care, they often
want to extend a tool that they have designed with their visualization capabilities. We
can encounter cases of premature selection of collaboration with a fellow tool builder,
which can lead into misleading information or waiting for fellow tool builder to
handover data to front-line analysts.
3.2.2 Core phase
This phase involves the design and development of the visualization tool. This
phase consists of four stages and ends with the finished tool.
14
3.2.2.1 Discover
The concept of requirements analysis in software engineering is analogous to
the discovery stage. This concept is linked to talking directly with the domain experts
in which the expert speaks and the researcher documents the information needs of
the expert. The ability to quickly and effectively characterize and abstract a problem
is a key skill for design study researcher. It is better to work with experts in many
different domains than just one. Then it allows us to gain more experiences and more
knowledge in design study.
One of the problems of the discovery stage is talking to the users, which is
necessary but sometimes it is not sufficient. The standard practice in a user-centered
design is a combination of methods, because the users are not usually responding
fully. Most users do not accurately introspect about their own data analysis and
visualization needs. That is why the practice is based on combination of interviewing
and observations. Fly-on-the-wall is a commonly used passive observation method in
which the researcher is silently observing and analyzing a user to gain an objective
picture of the normal activities. But one cannot rely on just one method – that could
be a pitfall. It is better to have more background information and try different
methods.
3.2.2.2 Design
After summary of data abstraction and shared understanding with a domain
experts in the discovery phase, the visualization researcher can begin designing a
visualization solution. This does not mean that the discovery phase is finished, but on
the contrary the discovery phase and the design phase complement one another as
work continues.
This stage generates and validates the data abstractions, visual encodings
and interaction mechanism. The basic design cycle, as articulated in fields such as
industrial design, includes identifying requirements, generating multiple solutions,
and selecting the best one. The previous discover stage of our framework covered the
identifying requirements step. This design stage covers the generation and selection
parts of the cycle. A common pitfall is to consider too few solutions and to
prematurely commit to selected solution [24].
In order to avoid this pitfall it is recommended for researcher to have a
broad consideration space of possible solutions, which consists of a set of valid visual
encodings, data abstractions etc. It is important to think broadly and then the
researcher can narrow the proposal space based on design principles and guidelines.
15
The feedback from the experts is important to filter the proposal space to a selection
of one or several design solutions that can be execute further. Hence, it is good to
discuss with the domain experts and show them examples in a form of paper or data
sketches to get the feedback. It is better aim for a few good and okay ideas than to just
go for one perfect idea.
3.2.2.3 Implement
The implement stage mutually interacts with the design process. It is crucial
to choose the right algorithms, which are compatible with all the requirements. The
key in design studies is fast software prototyping by quickly developing a throw-away
code. Tactics for the implementation stage of a design study: start simply, ideally with
paper prototypes; quickly write code that can be thrown away; and close user
feedback loops with methods such as design interviews and workshops, or deploying
early versions of a tool as technology probes. It is good to focus on usability but we
should avoid pitfalls such as focusing on usability too much or too little.
3.2.2.4 Deploy
The deploy stage is the final stage of the core phase and is about gathering
feedback about its use and deploying the tool. Gathering feedback is one of the ways
to evaluate a visualization tool. The challenge of evaluating solutions against fuzzy
tasks is well-understood in the information visualization community. The reports of
such evaluations, be it through usability studies or controlled experiments or
feedback interviews or any such means, are helpful to understand not only the
potential but also the limitations of visualization tools. [24]
3.2.3 Analysis phase
In this phase the visualization researchers reflect and write about the design
study.
“The measure of success is not that a different visualization
researcher would design the same system, but it is that this
particular researcher has created something useful.” [24]
16
3.2.3.1 Reflect
Reflection on how a specific design study relates to the larger research area of
visualization is crucial for adding to the body of knowledge and allowing other
researchers to benefit from the work. It is particularly informative for improving
currently available design guidelines: based on new findings, previously proposed
guidelines can be either confirmed, by substantiating further evidence of their
usefulness; refined or extended with new insights; rejected when they are applied but
do not work; or new guidelines might be proposed.
3.2.3.2 Write
Writing can be started at any point. Writing is the difficult part in terms of the
time required and of summarizing the whole project. It is known that for writing few
weeks is usually not enough so it is better to count in at least a couple of months. The
writing phase is the time when the review of abstractions takes place. In retrospective
the researcher(s) look at abstractions and taking them as a rule. The researcher
should be able to describe the events of a design study in interesting and useful story
and the writing should contain everything important that matters in the project. The
main pitfall is rushing to publish the work that can lead into a submission that is
shallow and lacks in depth.
3.3 Pitfalls in a design study
The nine-stage framework identifies in total 32 possible pitfalls that could
occur while carrying out a design study. Some of these pitfalls have already been
mentioned while describing the nine stages in the previous sections. A table of the
complete list of pitfalls is provided in APPENDIX A for reference.
17
Design Study Execution
This chapter describes how the design study project was executed – the design
decisions made and the various tasks that were performed during the project – based
on the nine-stage framework.
4.1 Precondition phase: Learn
A course in data visualization [4] is offered by the Department of Mathematics
and Computer Science at the Technical University of Eindhoven. This course requires
the students to go through an extensive set of literature to gain theoretical knowledge
and then submit practical assignments to apply the knowledge gained through
classroom study and literature reading. The researcher conducting this thesis study
underwent this course as a part of the curriculum thus acquiring the knowledge
required to conduct a design study in information visualization.
4.2 Precondition phase: Winnow
The winnowing phase consisted of connecting with several people from
various groups within Philips in order to find potential collaborators. The first set of
people to be connected with were teams that owned applications which use install
base data for some kind of analytics. A total of eight people, spanning across four
applications including SmartPath and Profitability tools mentioned in CHAPTER 2,
were identified as potential collaborators.
In addition, four account managers were also identified as people who could
provide useful insights for the project. These account managers spanned three
markets – Benelux (Belgium, Netherlands and Luxembourg), Indian subcontinent and
Latin America – and regularly used install base profitability information for making
business decisions.
After connecting with all these people, an analysis was made as to who could
be the collaborators for this design study. Since the services marketing manager at
IGT is a part of the central customer services marketing team and is knowledgeable
of the domain, it was decided that he be the main collaborator of this design study.
However, it is not the case that looking for other collaborators was stopped at this
stage. The conclusion was that one domain expert as the main front-line analyst was
enough to start with, and if needed, inputs from other collaborators could be received
18
during the course of the project. This is in line with the strategy of a design study
mentioned earlier (3.2.1.2) – talk with many, and stay with a few and start early, and
always keep looking.
4.3 Precondition phase: Cast
The services marketing Manager at IGT, the group in which this visualization
project was carried out, took on the roles of the Front-line analyst providing inputs to
the researcher throughout the period of project execution. The role of the Gate-
keeper, who makes the decisions regarding the project, was performed by the line-
manager of our Front-line analyst, i.e., the Head of the Customer Services Marketing
group. Several co-workers performed the role of Connectors, while there were no
specific Translators assigned to the project. Lack of a Translator did not prove to be a
hindrance since our Front-line analyst pitched in whenever that was necessary. There
was also no fellow Tool builder assigned to the project. The researcher was the sole
developer and made technical implementation decisions such as development tools,
programming language, etc. based on prior experience in software development.
4.4 Core phase: Discover
Although formal requirements gathering and analysis was performed in
discussions with our front line analyst, some requirements gathering was already
started informally while looking for potential collaborators. The interviews
conducted with the account managers during the winnowing stage yielded some high
level business needs that provided valuable inputs for the design study. During the
interviews, the account managers demonstrated how the analyses are done currently
using a combination of in-house analytics applications and other tools like Microsoft
Excel, Tableau, etc. The challenge of collating the information scattered across various
applications and the difficulty of visualizing that information afterwards were
explicitly highlighted during these interviews.
19
With the inputs from the domain experts and after discussions with our main
collaborator, a set of user stories and underlying use cases were developed.
Requirements were gathered based on the principles of software requirements
analysis and use cases were documented as given below –
User Story US1: Overview of the install base data
Use case Id Statement
UC1 As a domain expert, I would like to analyze the spread of the install base across geographies and properties of the installed product and the associated contracts
UC2 As a domain expert, I would like to filter out installed products based on system properties such as end of life and age
UC3 As a domain expert, I would like to filter out installed products based on contract properties such as end date and profitability
User Story US2: Overview of the service activities performed on a specific installed product
Use case Id Statement
UC4 As a domain expert, I would like to analyze the service activities carried out on an installed product
UC5 As a domain expert, I would like to analyze the financials of the service activities carried out on an installed product
Table 1 User story: Analyze install base
Table 2 User story: Analyze service activities
20
4.5 Core phase: Design
This section describes the design choices and the reasoning behind them. As
stated earlier (3.2.2.2), this stage generates and validates the data abstractions, visual
encodings and interaction mechanism based on the requirements gathered in the
Discover phase. The design of the tool is largely driven by Shneiderman’s mantra [27]:
Overview first, zoom and filter, then details-on-demand. The tool would be designed to
provide a high level overview of the installed base, then allow the user to zoom in and
filter down to locate a single installed product, and then show the detailed
profitability information of that installed product.
4.5.1 Data abstraction
Based on the requirements established, it is clear that we need at least three
data objects in order to build a visualization. These objects are – Installed Product,
Service Work Order and Location. Since we would need to also show some product
and customer related details to make the analysis easier, objects from which the
Installed Product and Service Work Order data have been derived are also included
in the data to be fetched. Table 3 below lists the data objects and their source
applications. The Profitability tool was the data source of choice for three reasons.
One, it uses data collated from different databases. Two, it provides the collated data
in the form of downloadable reports. And three, the accuracy of data is of an
acceptable level at >90% for any given month. The only missing piece was the
geographical location data which was received from an application development
team in Germany that used geographical coordinates for displaying real-time
information about an installed products’ uptime.
Data Source
Product Profitability tool
Customer Profitability tool
Installed Product Profitability tool
Contract Profitability tool
Service Work Order Profitability tool
Location Service activities dashboard
Table 3 Data objects and their source applications
21
4.5.1.1 The data model
This section describes the entities and attributes in the data that are used for
visualization in this thesis study. A detailed description of the properties can be found
in APPENDIX B. Figure 4.1 depicts the conceptual data model of an installed product
which is the fundamental unit of the install base.
A product is a device manufactured by Philips. It could be hardware only,
software only or as in most cases within IGT, it is a system that comprises of both
hardware and software components. A product has several attributes depending on
the lifecycle stage, but here only those that are relevant to the installed base are
depicted in this model.
A customer is a company or a hospital that Philips sells its products to. Since
Philips Image Guided Therapy Systems are only sold to other businesses, this
Customer entity never represents an individual person. The latitude and longitude
are used for identifying the exact geographical location of the Customer, which is
required for some processes such as planning of an engineer’s visit to the hospital for
a service activity.
An installed product is a derived entity from product and customer data with
some extra information relevant for service processes. It represents the product that
is actually installed at a customer location. Naturally, the Product and the Customer
linked to the installed product are stored as attributes on the Installed Product.
A contract or a service contract is a legally valid agreement made between
Philips and the customer to deliver service for some amount of money over a period
of time for a specific installed product. Under this agreement, Philips guarantees to
perform maintenance activities such as upgrades and repairs for as long as the terms
and conditions of the contract are applicable.
Figure 4.1 Data Model – Installed Product
22
A service work order (SWO) is a data entity to track the service delivery. It
represents a maintenance activity such as a repair, a part replacement, an upgrade or
a system health check performed to ensure the proper functioning of the installed
product. A work order consists of two types of costs. The cost of manual labor and the
cost of the parts replaced. The manual labor could be remote - where a service
engineer is located in a different location other than the hospital and connects to the
installed product over a secure network in order diagnose and/or fix the problem
with the installed product. The manual labor could also be onsite, which is a term for
the service engineer being at the actual location of the installed product to carry out
service activities in cases where a remote diagnosis or service activity is not possible
- for example replacing a part in the system.
A service work order maybe carried out on an installed product that is covered
by a contract or not. In case the service work order is executed on an installed product
covered by a service contract, the service work order will have a reference to the
contract so that the costs can be booked under that contract. If the service order is
executed on an installed product that is not covered by a service contract, then the
costs of the service work order will be booked directly to the customer who will make
the payment.
4.5.2 Encoding
Encoding is the use of visual display elements such as color, shape, size and
position to convey information about the objects being represented. The challenge is
that for any given data set the number of visual encodings and the space of possible
visualization designs is extremely large. In order to guide this process, psychologists,
statisticians and computer scientists have studied how well different encodings
facilitate the comprehension of data types such as tabular data, numbers, categories,
networks, etc. This section explains the design choices for encoding install base data.
Figure 4.2 Data model: Service Work Order
23
4.5.2.1 Overview of the installed base
A map is a natural choice to visualize the geographical spread of data elements.
For the use case UC1, a 3D map could be considered as a nice idea as compared with
a 2D map. But a 3D map offers no added advantage to our domain expert over a 2D
map in terms of visual exploration. Displaying the location of an installed product on
a map using an icon, is a simple straightforward encoding. However, looking at the
map from a zoomed out perspective will result in an unpleasant clutter of overlapping
icons that makes it harder for the user to derive meaningful information. This
problem can be solved easily by clustering several data points, installed product
locations in the current case, into one variable. Out of many possible ways of showing
aggregated statistical data on a map, there are two options that clearly stick out – a
choropleth map and a graduated symbol map.
A choropleth map, often used in geographic information systems (GIS), is a
way to represent a statistical variable whose value or range on each area of the map
is encoded by a color. For example, a value of 100 installed products on a region could
be given a darker shade of red compared to a value of 10 installed products on
another region. A choropleth map is good for a comparative analysis, but can provide
no more information. A given color scale used for a choropleth map can only encode
one variable – say number of installed product or types or installed products for
example – and nothing more. This is where a graduated symbol map provides an
advantage over a choropleth map.
Unlike a choropleth map, a graduated symbol map that uses symbols over an
underlying map. The
advantage of this approach
is that it allows for more
dimensions to be visualized,
for example, size, shape and
color of the symbol. Apart
from simple shapes such as
circles, a graduated symbol
map can also be constructed
using more complicated
glyphs such as pie charts.
GlottoVis, a visualization
built on the GlamMap [28]
geo-spatial visualization tool, is a premium example of a graduated symbol map
(Figure 4.3).
Figure 4.3 GlottoVis: an example of a graduated symbol map
24
In both these cases, it is required that a proper clustering algorithm be
developed in order to group the icons. This is where the first challenge of encoding
was encountered since there was not enough data for meaningful clustering at all
zoom levels – meaning it was possible to group the icons based on country or market
(a group of countries) but not on any other level. The only other level that the domain
expert was interested in was the state/province or region and due to the lack of data
for that level of grouping a decision was made to ignore that level of clustering for
this project. However, it was decided to make a provision in the code for such a
clustering in the future if and when the data becomes available.
Hence, graduated symbols, albeit in a simpler form of circles, is the current
choice to display clusters of installed products for an overview of the install base.
4.5.2.2 Visualization as a filter
The next two use cases UC2 and UC3 demand filtering of installed products.
Filtering is a technique applied to narrow down the data points of interest by
excluding those data points that the domain expert does not wish to see. In this case,
filtering corresponds to the selection of fewer installed products than what is shown
in the overview.
A simple straightforward way to implement this is through the use of standard
form elements such as dropdown lists or range sliders or radio buttons. But this
misses out on the requirements stated in UC2 and UC3, which would then require
additional visual encoding for the domain expert seeking to know how the installed
products are distributed across the filter parameters, in this case – end of life, age of
system and the associated contract end date.
Hence it is better to combine the visual encoding and filtering technique into
one interaction technique – using one visualization as a filter element to alter another
visualization. This is neither a novel technique, nor is very rare. Many dashboard
applications that display several visualizations built over the same datasets, employ
this technique. In fact, the IB Viewer in SmartPath tool and some visualizations in the
Profitability tool discussed in section CHAPTER 2 have such interaction-linked
visualizations.
This design decision is important in two ways. It not only addresses UC2 and
UC3 – the ability to filter out installed products not of interest – but also addresses
the latter part of UC1 – overview based on system and contract properties, which was
not discussed in the previous section.
25
4.5.2.3 Encoding profitability on the map
The design decision of using a visualization as a filter, introduced in the
previous section still leaves out a part of UC3 – the ability to filter based on the
contract profitability. Profitability is a calculation that decides whether a contract is
profitable or not, based on the revenue and costs of the contract. A contract is said to
be profitable if its costs are less than its revenue and to be under a loss otherwise.
Hence, encoding profitability seems to be a binary choice and plotting installed
products on the map with two different icons should do the trick – an installed
product that is still profitable is encoded with a green icon and an installed product
that is under a loss is encoded with a red icon.
This encoding now poses a challenge. When the user is looking at a “zoomed
out” view, that is, when several closely located icons of different colors are replaced
with a graduated symbol, how do we encode the symbol which is a circle? The domain
expert was consulted as to what is more
important to see during analysis – whether
installed products that are profitable or installed
products that are under loss? The answer to the
question was unambiguous and that installed
products under a loss always have more priority
for analysis. Hence the problem of encoding the
symbol is tackled by filling the circle with the
color red if there is at least one red icon in the
cluster represented by the circle. Otherwise, the
circle is filled with the color green.
This scheme of color coding also conforms
to the principles of color design [29] based on
contrast and analogy. Red and green are on the
opposite ends of the hue circle (Figure 4.4)
representing loss and profit which are on the
opposite ends of profitability. Hence, this choice is exactly in line with the contrast
aspect of color design. And in the zoomed out view, a red circle implies there is least
one red icon, that is in the cluster underneath and a green circle implies that all the
icons in the cluster underneath are green. This is in line with the analogy aspect of the
principles of color design.
After this color scheme was finalized, it was expressed by the domain expert
that it would be of great interest to the business if a contract on the path to a loss
Figure 4.4 Example of a hue circle (A Field Guide to Digital
Color, Maureen Stone, A K Peters, Ltd.)
26
could be identified before the cumulative service costs exceed the contract revenues.
At this stage it was discovered that a new property, named stop price needed to be
introduced to the data model. The stop price is defined as the price below which the
cumulative service work order costs should stay in order for the contract to be of the
desired profit margin. For example, if a contract price (revenue) is $10,000 and
Philips wishes to have a 30% profit margin on the contract, then the total of all service
work order costs at any point in the contract duration should remain under $7,000.
Hence, $7,000 becomes the stop price of this contract.
This stop price data however, was not available in the data sources that were
chosen for this project. Extracting this data out of different sources was deemed to be
a considerable effort and hence it was decided to assume a percentage of the contract
price in order to make a provision in the visualization’s data model for future
implementation.
So now there is a need to encode another possible color for profitability of
contracts which are not under a loss, but are potentially on the path to loss. The costs
of these contracts are below the contract price but have already exceeded the stop
price. Hence, for the icons and symbols that represent these contracts we need to
choose a color that lies in between the colors red and green. Traffic lights give a good
analogy of choosing something in between red and green. Referring back to the hue
circle (Figure 4.4), it can also be deduced that the color yellow or orange or something
in between would be a good choice to draw the attention of the user. Hence a shade
of yellowish-orange is chosen for the icons representing the installed products on the
map.
For the graduated symbols that represent a cluster of icons, a similar logic as
used for determining whether the circle color should be red or green is used; where
there is at least one yellow/orange icon, but there is no red icon, the circle will be
colored with yellow/orange. Following table gives the logic of choosing the color for
the cluster of icons represented by a symbol:
Color of icons on map Color of cluster symbol on map
All green Green
At least one yellow, but no red Yellow
At least one red Red
Table 4 Cluster symbol color design logic
27
4.5.2.4 Overview of service activities
The next user story, US2, pertains to the encoding of an individual installed
product’s service activities. This requires bringing together three information
elements – the revenues of the contract, the costs and types of service work orders
and the lifetime information of the system. Following sections discuss how each of
these are encoded and the design principles behind them.
4.5.2.5 Encoding service touchpoints
While the design phase was ongoing, it was expressed by other domain experts
that it could be interesting to visualize other service touchpoints with the customer.
Service touchpoints are events at which non-service related activities are carried by
Philips in connection with the installed product. Examples of such activities are
education services, wherein a clinical or technical training is delivered to the hospital
staff on how to use the Philips product, and business services wherein information
services such as reports on utilization of the installed product are provided to the
management of the hospital. Depending on the type of installed product, there could
be other kinds of services as well. It was clear what all information was useful for the
domain expert if visualized. However, it was not clear how much of those service
touchpoints could be visualized, as in, how much of the data was available, and then
how useful the visualization would be even if the data was made available. Hence,
applying the tactics for implementation as mentioned in section 3.2.2.3, it was
decided to develop a quick prototype, get feedback and then proceed with the further
development.
Encoding service touchpoints required to represent temporal and categorical
elements on the same two dimensional. This kind of challenge has been tackled in
visualizations such as stacked area graphs and horizon graphs as shown in examples
beside, in which multiple time-varying data variables are represented on the same
graph. However, the challenge with the current data set was that the density of events
across categories were extremely difficult. To quote an example, a system that is in
operation for 10 years, would have several maintenance activities such as repairs and
upgrades, but probably only one clinical and technical training conducted since the
same set of doctors and radiologists were using the system. To represent these two
categories of service touchpoints – maintenance and training services – on the same
axis and scale, would pose a challenge for the user to even locate these events on the
visualization. But this was an accepted risk for the development of the prototype.
28
It is clear that the different categories of service touchpoints are linked to
different processes in service delivery. Drawing inspiration from Shostack’s Service
Blueprinting and Business Process Modelling Notation (BPMN)’s idea of swim-lanes,
these different categories of service touchpoints could be encoded with different
columns or rows on a two dimensional space. Since the lifetime of a system was
encoded as a horizontal row, for no particular reason, the rest of the “swim-lanes”
representing different service touchpoint categories was also encoded horizontally.
The choice of color for each lane was from the color palette of Microsoft’s
Office PowerPoint program which is a presentation tool well-known and commonly
used by our domain expert. The choice of color for the touch points, i.e., the exact
events was just a contrasting color against each of the lanes. The shape of each of the
different kinds of touch points posed a challenge since there were many such rows
and it could become difficult for the user to see significant difference between the
many shapes if the screen size was smaller.
4.5.2.6 Encoding profitability of an installed product
Service activities of different types – repairs, upgrades, planned maintenance,
etc. – all contribute to profitability of a contract by recording labor and/or material
cost logged against the corresponding service work orders. It could be of interest to
see how these costs are changing over a period of time, but from a profitability point
of view, it is more important for our domain expert to see how these costs are
accumulating against the revenues from the associated contracts. Hence, the
cumulative costs logged against service work orders could be encoded as a time-
series data – a set of values changing over time.
A simple way to encode
time-series data is through a line
graph that shows time on one axis
and the value of the changing
variable on the other. If more
variables to be displayed, more
advanced techniques such as a
stacked graph, as shown in Figure
4.5 beside, could be used.
Drawing ideas from
stacked charts, we encode the
contract revenue and the Figure 4.5 Stacked Graph of Unemployed U.S.
Workers by Industry
29
cumulative contract cost as two different colored regions on a time axis that
represents the lifetime of a contract. In the dataset obtained for the thesis study, the
contract revenue was a constant across the number of years. However, it was
discovered that some multi-year contracts are paid on a yearly basis and hence the
revenues for such contracts are also a time-series whose values vary (increase) over
a period of time. Another point to be noted here is that this encoding scheme assumes
one contract per system. This limitation and the case of multiple contracts for a
system are discussed in the future scope for research under CHAPTER 7.
This encoding still does not help to analyze why the costs have grown the way
they have grown over the time period in relation to the individual service activities.
In the current dataset, this requires displaying of service work orders on the same
time axis which gives an idea of how a particular service work order contributed to
the “jump” in the total costs incurred on a contract. This visual multiplexing is
essentially a technique of overlaying multiple pieces of visual information while
allowing the users to recover occluded information [30]. However, this poses a new
challenge that the cumulative costs and the revenues over a long duration could be
several magnitudes higher than the individual service work order costs, thus
rendering the “columns” of service work orders so small that it makes it difficult to
spot for our domain expert.
The challenge of different ranges of these costs is tackled by introducing
another vertical axis which covers only the range of values of a service work order’s
costs. Hence, there will be one horizontal time axis x, and two vertical cost axes y1 and
y2, where y1 on the left scales the individual service work order costs and y2 on the
right scales the cumulative costs. The position for y2 on the right hand side is also a
conscious choice based on the fact that the horizontal time axis runs from left to right
which result in the costs building up from left to right.
Cumulative costs represented by the stacked area graph, decide whether a
contract is profitable or not depending on whether the highest peak in the graph (the
current total cost) exceeds the contract revenue height or not. Continuing the
maintenance of consistency for the choice of colors, as with icons and cluster symbols
(4.5.2.3) encoded for profitability, the area of the cumulative costs is colored either
green or red depending on whether the contract is profitable or not respectively. Thus
we have what can be called as either a green contract or a red contract based on the
color of the area that represents the cumulative costs.
Again, in line with the color design principle of analogy, the overlaid graph of
service work order costs represented by columns, are also color coded with the same
30
color as the cumulative costs. However, a slightly darker/lighter shade of the same
color needs to be used in order to provide the contrast and enable distinguishability.
It can be argued that this changing of column colors based on service contracts might
not be necessary since an individual service work order’s costs will not affect the
profitability on its own and as such it is enough to choose a color coding for the
cumulative costs that is consistent with the color coding of profitability. While it is a
valid argument, the effort involved in choosing one color that contrasts well with both
red and green colors of the background is more than going with the color coding that
we already know works based on color coding theory as stated in section 4.5.2.3.
4.6 Core phase: Implement
The design choices made in the previous section were the result of feedback
on quick prototypes that were developed. This section discusses what prototypes
were shown to the domain expert and what subsequent updates to the design choices
that were made before the prototype application was finalized for evaluation.
4.6.1 Early prototypes
In line with the tactic of implementation (3.2.2.3), prototypes were developed
in order to quickly validate the design choices.
4.6.1.1 Overview of install base: the dashboard view
The initial version of the overview of install base took into consideration the
domain expert’s interest in checking if it would be possible to encode more colors
onto the icons than just based on profitability. An example of such a case is when there
is an opportunity to sell a new upgrade to a customer using an old version of the
installed product. The early prototypes developed did demonstrate that this was
possible, but since the requirements was not clearly elicited and it was unclear
whether all the data required to show such information was available, this idea was
parked for a future implementation. Figure 4.6 shows the screenshot of a dashboard
view that was developed in the first version of the prototype in order to provide an
overview of the install base.
31
As can be observed in the figure above, the screen consists of two rows – an
infographic row that displays items of interest using large icons on the top and a
bottom row with geographical map accompanied by two other visualizations that
serve as filters. The bottom row is split into three columns in which the map is on the
left. The center column is contains visualizations that allow the domain expert to filter
on either the system age or the contract profitability. A point to note, this prototype
did not yet have the color coding for contract profitability on the filter visualization
on the bottom center. The third column on the right was to give the user an overview
of the recent activities that were a part of service delivery.
A quick feedback session with the domain expert resulted in the opinion that
the map is preferred to be full screen to provide a larger view of the geographical area
and that the filters be displayed using a floating menu area that could be collapsed
into a button or a bar on one of the sides.
Figure 4.6 Prototype 1: Overview of installed base – dashboard view
32
4.6.1.2 Service touchpoints: a static visualization
A prototype for visualizing service touchpoints was developed as shown in
Figure 4.7. The top most row displayed the time period of the lifetime of the installed
product along with the period of the contracts encoded as bars. The five different
categories of service touchpoints are displayed as five swim-lanes of different colors
in which each type of service touch point gets its own row. In each row, the exact
occurrence of the corresponding event is marked with a particular shape in a color
that contrasts the background.
The horizontal x axis is a time scale spanning the lifetime of an installed
product while the vertical y axis is a named scaled with of each values on the scale
representing a specific service activity.
After trying out the prototype on a few installed products in the data set, it was
discovered that the data was consistent and available only in case of touchpoints that
were recorded as a service work order, for example, a corrective maintenance (CM)
activity or a planned maintenance (PM) activity. Other data such as training or
utilization had data spread in different data sources and posed a big challenge to
gather such data and in turn difficulties in evaluating the visualization if
implemented. After discussion with our domain expert, it was decided to park this
approach for a future implementation and concentrate only on the financials of
Figure 4.7 Service touchpoints – a static visualization
33
service work order data that was available and was possible to evaluate. This decision
resulted in the use case UC4 not being implemented in this project.
4.6.2 Final application
After another iteration of prototype development and feedback by the domain
expert, a working application as per the needs stated was developed. CHAPTER 5
provides a detailed walkthrough of the application.
4.7 Core phase: Deploy
The application was deployed on a development server (a local desktop) that
was accessible to a selected set of users including our domain expert. This was used
to demonstrate the application and evaluate the visualizations based on the feedback
provided by our domain expert. CHAPTER 6 discusses in detail the evaluation
methodology and the results of the evaluation.
4.8 Analysis phase: Reflect & Write
Reflection on how this design study project relates to the larger research area
of install base visualization for services marketing is discussed in CHAPTER 7.
This thesis report can be viewed as a contribution to the writing that looks at
the design study project in retrospection and analyzes its stages once again. As
predicted in 3.2.3.2, this phase did consume more than a couple of months of effort
since our researcher had moved on to other projects. However, this thesis report does
present the details of the project using a good storyline and discussing all the main
topics in sufficient depth.
34
Walkthrough of the application
This section explains the various features of the prototype application with
screenshots of the same and goes through the various interaction steps.
5.1 Overview of installed base
5.1.1 The map
The application opens up with a high level view of the installed base, see Figure
5.1 above, that depicts the geographical spread of the installed products using
location markers and graduated symbols. The symbols are circles with a number on
a color coded background of either red, green or yellow colors. The color coding is as
explained in the previous section. Each marker represents the geographical location
of an installed product and each symbol represents a set of installed products in and
around the region in which the symbol is present. The number within the symbol
depicts the exact number of markers around the region of the symbol.
Figure 5.1 Overview of install base
35
5.1.1.1 The filters
There are no traditional form controls such as drop-down lists or radio
buttons used in the application for filter controls. Instead, another set of
visualizations - column charts - are implemented for the user to narrow down on the
number of systems shown on the geographical map. This filter section which is
present on the right hand side of the screen is a vertical column of visualizations that
is displayed by default when the application opens up. The entire filter section can be
collapsed to the right, see Figure 5.2 below, if the user wishes to see more of the map
that shows the installed product markers and symbols.
As can be observed in Figure 5.2, there is enough space to implement more
filter controls if the need for the same arises in the future.
5.1.1.2 The filter section visualizations
The filter section currently houses 3 kinds of filters which by themselves are
visualizations. Two of the filters, grouped under “Filter on installed products”, are
based on the installed products lifetime and the third, placed under “Filter on expiring
contracts”, is based on the end date of the contract associated with the installed
products. These visualizations are explained in the next section.
Figure 5.2 Overview of install base - filters collapsed
36
5.1.1.2.1 Filter on installed products
This set of filters allow the user to narrow down on the number of installed
products based on some of properties of the installed products. Of particular interest
for the business, as stated in the requirements, is the ability to filter on systems that
are approaching their end of life. The other filter, on the age of the system, enables
the user to narrow down systems that have been in operation for a certain period of
time.
Filter on installed product end of life
This visualization, depicted
in Figure 5.3, is a column chart that
gives an overview of the number of
installed products that will reach
their end of life on a given year.
Clicking on one of the
columns selects the corresponding
year and displays on the map only
those installed products that are
reaching end of life in the selected
year as shown in Figure 5.4 below. For example, clicking on the column labeled 2019
will display on the map only those installed products that are reaching their end of
life in the calendar year 2019.
Figure 5.4 Overview of install base filtered on end of life
Figure 5.3 Filter on end of life
37
Filter on installed product age
This visualization (Figure 5.5)
is a column chart that gives an
overview of the number of installed
products that are of a particular age,
i.e., the calculated difference in the
number years between the present
day and the installation date of the
installed product.
Clicking on one of the columns
selects the corresponding age and displays on the map only those installed products
that are of the selected age (Figure 5.6). For example, clicking on the column labeled
1 will display on the map only those installed products that have been installed in the
last year.
5.1.1.2.2 Filter on contracts
This filter on contract is a visualization that enables the user to narrow down
on the number of installed products based on the contract end date. Of course, other
filters such ones based on contract revenue were also possible, but they were not in
the scope as per the requirements.
Figure 5.6 Overview of installed product filtered on age
Figure 5.5 Filter on age
38
Filter on contract end year
This visualization (Figure
5.7) is a column chart that gives an
overview of the number of
contracts that are going to expire
in a particular year, i.e., the end
date of those contracts fall in a
particular year.
Clicking on one of the columns
selects the corresponding year and displays on the map only those installed products
whose contracts are ending in the selected year (Figure 5.8). For example, clicking on
the column labeled 2018 will display on the map only those installed products whose
contracts are ending in the calendar year 2018.
Figure 5.8 Overview of install base filtered on contract end date
Figure 5.7 Filter on end year
39
Filter on month
This is a filter implemented
using the same column chart used for
filtering by years, except that it
provides one more level of narrowing
down to installed products based on
the month of the contracts’ end dates.
The visualization (Figure 5.9) is still a
column chart that gives an overview of
the number of contracts that are going
to expire in a particular year of a
particular month as opposed to the
previous filter that only filters based
on the year.
Clicking on one of the columns selects the corresponding month and displays
on the map only those installed products whose contracts are ending in the selected
month of the selected year. For example, clicking on the column labeled 2018 will
display on the map only those installed products whose contracts are ending in the
calendar year 2018. The title of the visualization displays the selected year and an
option to switch back to the yearly view.
5.2 Profitability of an individual installed product
This section presents the visualization of the revenues and costs of an
individual installed product under a service contract. When a user has narrowed
down on an installed product of which (s)he would like to see the revenues and costs,
the user clicks on the marker corresponding to that installed product shown on the
map view. This brings a pop up, which displays the multiplexed visualization - column
chart over two semitransparent area charts - showing how the costs of the contract
have grown between its start and end period. The title of the pop up clearly shows
the customer name, contract type and other descriptive text that could be of interest
to the user.
The multiplexed visualization consists of the contract price as an area chart
that serves as the background, on which an area chart of the cumulative service costs
is overlaid, and on which the column chart of individual service work order costs is
plotted. As per the design, the color of the cumulative costs and of the service work
Figure 5.9 Filter on end month
40
order costs correspond to the color of the marker clicked by the user. The labels
pertaining to these two graphs also follow the same color coding.
The x axis shows the time period of the contract period while the two y axes
show the costs. As stated in the design, the y axes have different scales - one
corresponding to the contract’s financials and the other corresponding to the service
work order costs. The prices corresponding to the contract i.e., the realization price,
contract sale price and the stop price are all aligned closer to the y axis on the right
hand side that corresponds to the contract prices.
The prices corresponding
to the service work order can be
viewed when the user hovers
over an individual service work
order in order to examine the
split between the labor and
material costs logged on the
service work order as shown in
the Figure 5.10 beside.
In case there are many service work orders within a shorter period of time,
the columns of the service work order costs would overlap each other and create
clutter and confusion for the user. In such cases, the user is able to zoom into the x
axis using the mouse scroll wheel and also pan to the left or right to bring into sight a
particular period of the contract. Figure 5.11 below shows an example of a zoomed in
x axis on the profitability chart.
Figure 5.11 Contract costs zoomed in
Figure 5.10 Service work order costs
41
5.2.1 Profitability in various colors
This section shows examples of the different types of contracts, based on their
financials and hence their depicted color on the profitability chart - green, orange,
red.
5.2.1.1 The green contract
A contract whose total costs are less than the stop price is depicted with the
costs in green color. An example of this type of profitability chart appears when the
user clicks on a green colored marker on the overview map, is shown in Figure 5.12.
5.2.1.2 The orange contract
A contract whose total cost is more than the stop price but less than the
contract price is depicted with the costs in orange color. An example of this type of
profitability chart appears when the user clicks on a yellow colored marker on the
overview map, is shown in Figure 5.13.
Figure 5.12 Contract profitability: Green
42
5.2.1.3 The red contract
A contract whose total cost is more than the contract price is depicted with the
costs in red color. An example of this type of profitability chart appears when the user
clicks on a yellow colored marker on the overview map, is shown in Figure 5.14.
Figure 5.13 Contract profitability: Orange
Figure 5.14 Contract profitability: Red
43
Evaluation and Results
6.1 Evaluation approach: The Seven Guiding Scenarios
This thesis study derives its evaluation approach from the seven guiding
scenarios for information visualization evaluation [31] for assessing the potential and
the limitations of the design study project. This chapter details the evaluation
performed for each scenario that was applicable.
6.1.1.1 Evaluation goals
It is recommended to determine clear evaluation goals before diving into the
evaluation methods [31]. Evaluation is performed at different stages of the project
and hence the goals are based on the stage of the project that’s under execution.
In the pre-design stage, i.e., winnow and discover stages in our design study
project, the evaluation goal is to understand the potential users’ work environment
and information needs. In the design stage, the evaluation goal is to scope the visual
encoding and interaction design based on the design principles that provide
guidelines for human perception and cognition. In the prototype stage, i.e., the
implement stage, the goal is to check if the visualization has achieved its design goals.
And in the deploy stage, the goal is to see the effectiveness and uses of the visualization
tool in the field. With these goals in mind, the following sections discuss different
evaluation scenarios and the methods employed for each applicable scenario.
6.1.1.2 Evaluating Environments and Work Practices (EWP)
This scenario aims at evaluating problem characterization. Questions in this
scenario usually are driven by the need to identify a set of features that the potential
visualization tool should have. Examples of questions for evaluating environments
and work practices include:
What is the context of use of visualizations?
What types of analyses should the visualization tool support?
What data is currently used?
44
What kinds of visualizations are currently in use? How do they help to solve
current tasks?
Examples of suggested methods for conducting evaluation under this scenario
are field observations, interviews and laboratory observations. This thesis study
adopted the method of field observations and interviews for answering the questions
listed above. The answers have already been discussed in detail in the previous
chapters, specifically CHAPTER 1, CHAPTER 2 and CHAPTER 4 hence performing a
detailed evaluation of the environments and work practices along with the
visualization needs of the business. CHAPTER 1 provided the answered questions
about the work environment and practices while CHAPTER 2 explained the currently
used visualizations and section 4.5.1 in CHAPTER 4 answered questions about the
data in use.
6.1.1.3 Evaluating Visual Data Analysis and Reasoning (VDAR)
Evaluations in visual data analysis and reasoning study if and how the
visualization tool supports in generating relevant actionable knowledge for domain
experts. In general, the questions pertain to data exploration, knowledge discovery
and decision making for example. Methods for evaluation include case studies and
controlled experiments. This thesis study performed a controlled experiment in
which a detailed demonstration of all the features and interaction techniques
implemented in the visualization was provided to the domain expert, who was then
asked a set of questionnaires to evaluate how the tool assisted in data exploration.
The exact questionnaire and the responses are listed in APPENDIX C and a discussion
of the results are presented in section 0.
6.1.1.4 Evaluating Communication through Visualization (CTV)
Evaluations in this scenario study if and how the visualization tool supports
communication of concepts with respect to learnability, idea presentation, casual
consumption of visual information, etc. CTV evaluations often are aimed at measuring
the tool’s quality through quantitative metrics. CTV evaluation methods may include
controlled experiments, field observations and interviews and aim to answer
questions like
Do people learn better and/or faster using the visualization tool?
Is the tool helpful in explaining and communicating concepts to third parties?
Can useful information be extracted from a casual information visualization?
45
This thesis study performed a controlled experiment in which a detailed walkthrough
of all the features and interaction techniques implemented in the visualization was
provided and the domain expert was asked a set of questionnaires to evaluate how
the tool assisted in communication through visualization. The questionnaire and the
responses are listed in APPENDIX C and a discussion of the results are presented in
section 0.
6.1.1.5 Evaluating Collaborative Data Analysis (CDA)
Evaluations in this scenario study whether a tool allows for collaboration,
collaborative analysis and/or collaborative decision making processes. Since our
visualization tool is designed for a single-user scenario, i.e., not more than one user at
a time is needed to perform the data analysis, evaluation in the CDA scenario was not
applicable to our visualization tool. Hence, this evaluation was skipped.
6.1.1.6 Evaluating User Performance (UP)
Evaluations in this scenario study how objectively measurable user
performance is affected by specific features of the visualization too. Although user
performance can be measured in terms of objectively measurable metrics such as
time and error rate, it can also be measured subjectively on parameters such as work
quality as long as the metrics can be objectively assessed. The most commonly used
metrics are task completion and task accuracy. Commonly used methods include
controlled experiments and analysis of usage logs.
Due to lack of time and resources, this quantitative measurements were
parked to be a part of future development and hence was skipped in our design study.
This however does not discount the effectiveness of our evaluation approach since
many subjective measures, such as perceived effectiveness and perceived usefulness
for example, that are gathered for evaluating user experience (see section 6.1.1.7)
simply mirror the measures used for evaluating user performance [31].
6.1.1.7 Evaluating User Experience (UE)
User experience evaluations examine people’s subjective feedback in written
and/or spoken form. The goal here is to understand how people react to a
visualization and to collect user reactions to improve the design. UE tends to be
specific to the design problem at hand in contrast to UP (6.1.1.6), which aims to
produce more generalizable and reproducible results. UE also differs from VDAR
46
(6.1.1.3) in that it looks at a more personal experience while VDAR focuses on the
output generated through the data analysis and reasoning process. Also, while UE
focuses on a specific visualization, EWP (6.1.1.2) focuses on studying users and their
environment. Examples of questions from a user experience evaluation would be:
What features are seen as useful?
What features are missing?
How can features be reworked to improve the supported work processes?
Are there limitations of the current system which would hinder its adoption?
Is the tool understandable and can it be learned?
This thesis study performed a controlled experiment in which a detailed walkthrough
of all the features and interaction techniques implemented in the visualization was
provided and the domain expert was asked a set of questionnaires to gather feedback
on the tool. The question formulation was influenced by the Technology Acceptance
Model (TAM)’s approach of measuring perceived usefulness, perceived ease of use
and attitude towards using novel technological tools. The questionnaire and the
responses are listed in APPENDIX C and a discussion of the results are presented in
section 0.
6.1.1.8 Automated Evaluation of Visualizations (AEV)
Evaluations in this scenario study aspects of visualization, which can be
measured by automatic computer-based methods. Questions related to this scenario
usually target measuring the visual effectiveness or computational efficiency with
which the ddata is represented on the screen. Features such as algorithmic
performance and ordering of visual items to speed up search are typically measured
using other computer software. Due to lack of time and resources, such automated
evaluations were not implemented and hence this type of evaluation was skipped in
the current design study.
-o-
The questionnaire prepared for the applicable scenarios were of four types.
The first type consisted of multiple choice answers in which the respondent would
agree or disagree to a statement. The possible choices were from the set – Strongly
disagree, Disagree, Neutral, Agree, Strongly agree. The second type of questions
expected the user to rate a particular feature on a linear scale of 1 to 5. It could be
argued that both of the response types are essentially the same since they both have
47
5 options to choose from. But the responses had to be worded differently based on
the question statements which otherwise would cause confusion to the respondent.
For example, asking the user how useful a particular feature was and giving the
options of agree/disagree does not make sense. The third type of question carried a
binary yes/no choice of response. And finally, the fourth type of questions were open
ended questions in order to provide a freedom to the respondent to answer however
they chose to.
6.2 Discussion of the results
APPENDIX C lists the evaluation questionnaire and the responses received the
domain expert. This section presents a discussion of the results of the evaluation.
Overall, the visualization tool was received positively, even by other domain
experts to whom the tool was demonstrated but who did not participate in the formal
evaluation. Our main domain expert, who did participate in the formal evaluation,
provided the highest score for many of the features. The usefulness of the tool,
pertaining to the UE evaluation scenario (section 6.1.1.7), received an average score
of 4.7 on a scale of 5. While the color design, the map and profitability encodings
received a full score of 5, the system age visualization and the labor and material costs
popup received a 4. This could mean that the system age visualization and the
individual service work order costs were not perceived as useful or effective as other
features that received a full score.
Our domain expert strongly agreed that the tool helps to explore data faster,
thus responding to the VDAR (section 6.1.1.3) evaluation scenario. For the CTV
(section 6.1.1.4) evaluation scenario, it was strongly agreed that useful information
can be extracted from the tool and that the tool is easy to learn or understand. The
helpfulness of the tool in communicating concepts to third parties was also agreed to,
but not strongly, which could mean that the tool needs some enhancements before it
can be used for communicating concepts to third parties. However, it was indicated
that the tool was not missing any essential features that would hinder its usage.
For the open-ended questions, which expected response in a free text format,
our domain responded to the first question that he did not see any current features
that needed to be enhanced. This could imply that the speculations made in the
previous paragraphs about enhancements might not be fully valid. This can only be
confirmed by making such enhancements and asking the same questions to check if
48
the domain expert’s feedback would change. But this could be an option for future
research.
On the other question about missing features in the tool, the domain expert’s
feedback were not related to visualization in particular. The feedback was to have
user authorization in order to restrict the amount of data seen by other domain
experts specific to a particular region or business unit. The second point was to have
a report or download functionality. Since both of these were not in the scope for this
project already, they can be documented to be taken up for further development in a
future project.
49
Conclusions
This chapter concludes the thesis study by summarizing the goal, the approach
and the steps executed during its course. It also discusses about the limitations of the
research carried out and based on that provides a direction for scope of future
research.
7.1 Summary
This project started with the goal of researching solutions to the business
problem faced at the services marketing group of Philips IGT systems division. The
need for an information visualization for analyzing the existing install base was
recognized and a research question, “How to visualize install base data in order to
formulate better service propositions to existing customers?” was formulated project.
The research question led to the defining of the goal for the project based on
which a field study was conducted to discover any existing visualization tools that can
already be used instead of developing a new one. This study of related work was
performed on widely available business intelligence tools as well as analytics tools
available within Philips. The findings concluded that none of these applications have
neither out-of-the-box solutions nor easily customizable features with which the
required visualizations could be developed. Hence, a decision was made to develop a
new visualization which would not only satisfy Philips’ business needs but could also
contribute to wider research in the field of information visualization.
The goal of the project provided a clear direction for the research approach
that a design study needed to be carried out and as a result the nine-stage framework,
which provides a detailed set of guidelines to execute design studies, was chosen as
the methodology for the research.
The design study began by setting up possible collaborations with key people
from the business. The wide set of collaborators was narrowed down and their roles
were set early in the project. Then the detailed requirements were discovered and
gathered using the use-case documentation methodology borrowed from software
requirements engineering. In the following design stage, abstractions and encodings
were developed in line with the use cases. Quick prototypes were implemented in
order to validate the design decisions and updates to the design were made as per
50
feedback received along the process. The visualization was completed by setting one
use case – visualizing service touchpoints – out of scope and by leaving it open for
future development. The final implementation was evaluated using various methods
as directed by the seven guiding scenarios of information visualization. The results of
the evaluation were discussed in detail concluding that the domain expert who
evaluated the visualization was satisfied with the tool. The writing of this report
marks the end of this thesis study with a reflection on the design study project that
was carried out.
The implementation contributes to broader research as being a pioneer
attempt at information visualizations of install base the helps in analytics for services
marketing. The findings of this design study for obtaining an overview of the entire
install base down to an individual installed product’s lifetime could be extended to
beyond Philips imaging systems as well. Essentially, any device that is installed at a
customer location and whose maintenance is covered by a service contract could
utilize such a visualization to analyze its profitability. Although there are some
limitations for this design study as will be discussed in the following sections, the
scope and direction for further research is exciting from a broader information
visualization perspective.
7.2 Limitations
This section lists the limitations of this design study project. For the sake of
clarity, it is split into two areas, features and evaluation, as follows.
7.2.1 Limitations in features
Limitations as a result of partial or no implementation of certain features that
could aid in better analysis of the data are listed in this section.
7.2.1.1 Full system lifetime
The visualization currently supports only a certain period in the full lifetime
of an installed product. That is the period of start and end date of the latest contract
that covered the installed product. Although it could be argued that this is the most
relevant information, it would be interesting for the business to see the entire service
history and the profitability over the lifetime of the system in order to formulate
newer service propositions. It would also help to identify how much of labor and
51
material costs were consumed during the time when the installed product was not
covered by a contract, if that was the case.
7.2.1.2 Installed products not covered by contracts
The visualization currently supports only installed products covered by a
contract. There are also products sold by Philips that are not covered by a service
contract. The labor and material costs are invoiced directly to the customer and are
paid by the customer every time a service work order is executed on the installed
product. It would be interesting for the domain expert to show such installed
products and how the cumulative costs of service work orders have grown over the
lifetime of the product. This would help the business to formulate a service contract
specifically tailored based on the installed product’s service history.
7.2.1.3 Multiple contracts
The implemented visualization takes into account only the last active contract
covering the installed product. Although this is the most relevant information for the
domain expert to identify new service opportunities, in some cases it would be helpful
to know the entire service history spanning all the contracts that covered the installed
product. Such a visualization would also help in identifying the contract-less periods
in the installed product’s life. This kind of gap is a missed revenue opportunity and
hence would point the business towards identifying why there was such a gap, which
could help in formulating better marketing strategies for future service contract sales.
Such a visualization could also help in identifying data anomalies such as overlapping
contract periods, if any, in the installed product’s life. Although this is never a real
business case, it might be possible that the data entered into the system was in error
and the visualization helps in identifying such errors.
7.2.2 Limitations in evaluation
Although the evaluation results were positive, there were certain limitations
in the evaluation methodology. One of the evaluation scenarios was not fully covered
and the other was not executed at all. Also, the user experience evaluation was done
with only one domain expert. A larger sample set of users could provide a diverse set
of personal experiences that could help in improving the design.
52
7.2.2.1 User performance evaluation
The user performance evaluation was based on a question that asked the user
to state whether the tool helps to explore the data faster, to which the domain expert
strongly agreed that the tool does help. However, this aspect of the tool is not
quantified by this type of evaluation. It is a qualitative evaluation while usually user
performance evaluations are expected to result in quantitative measures in terms of
task completion time or other measurable parameters. Such a quantitative evaluation
would also help in comparing these parameters against other methods. Of course, in
this case the only other method is analysis through raw data analysis using
spreadsheets and hence visual encoding is way faster to analyze. But in case, multiple
visual encodings were developed, a quantitative evaluation would be helpful in
objectively comparing the different encodings.
7.2.2.2 Automated evaluation
Automated evaluations were not performed in this design study due to lack of
time and resources. This leaves questions such as, “How does the layout algorithm
perform with different volumes of data?” unanswered. It would be interesting to know
answers to such questions when the tool is deployed for more users. Hence, this is a
limitation as well.
7.3 Further research
It is clear from the limitations that visualizing profitability of an installed
product that had multiple contracts over its lifetime is a useful feature to have.
However, this opens up a new challenge for visual encoding of such a scenario giving
rise to questions such as How do we stack the cost graphs of all these contracts –
horizontally or vertically? Do we use small multiples or horizon graphs or some novel
way of visual encoding? What kind of data analyses will each of these encodings
support? - so on and so forth. Apart from that, evaluating the visualization with
different evaluation methods and many domain experts for a stronger evaluation is
also a good direction for future research. Hence the scope for future research is broad
as well as deep enough to carry out at least another design study.
53
BIBLIOGRAPHY
[1] "About Royal Philips," 2017. [Online]. Available:
https://www.usa.philips.com/a-w/about-philips/company-profile.html.
[2] "Installed base, From Wikipedia, the free encyclopedia," 03 01 2017. [Online].
Available: https://en.wikipedia.org/wiki/Installed_base.
[3] "Philips Interventional Devices & Therapies," 2017. [Online]. Available:
https://www.usa.philips.com/healthcare/solutions/interventional-devices-
and-therapies.
[4] "Bubble chart," [Online]. Available:
https://en.wikipedia.org/wiki/Bubble_chart.
[5] J. Davis, "10 Data Visualization Tools To Bring Analytics Into Focus," 06 01
2016. [Online]. Available: https://www.informationweek.com/big-
data/software-platforms/10-data-visualization-tools-to-bring-analytics-into-
focus/d/d-id/1325679?.
[6] "Magic Quadrant for Business Intelligence and Analytics Platforms," [Online].
Available: https://www.gartner.com/doc/3611117/magic-quadrant-
business-intelligence-analytics.
[7] "Tableau Software, From Wikipedia," [Online]. Available:
https://en.wikipedia.org/wiki/Tableau_Software.
[8] "Get Started Mapping with Tableau," [Online]. Available:
https://onlinehelp.tableau.com/current/pro/desktop/en-
us/buildexamples_maps.html.
[9] "Tableau help documentation: Create Maps that Show Quantitative Values in
Tableau," [Online]. Available:
https://onlinehelp.tableau.com/current/pro/desktop/en-
us/maps_howto_symbol.html.
[10] "Create Filled Maps with Pie Charts in Tableau," [Online]. Available:
https://onlinehelp.tableau.com/current/pro/desktop/en-
us/maps_howto_filledpiechart.html.
[11] "Qliksense help documentation: Map properties," [Online]. Available:
https://help.qlik.com/en-
US/sense/June2017/Subsystems/Hub/Content/Visualizations/Map/map-
properties-panel.htm.
54
[12] "Qlik GeoAnalytics," [Online]. Available:
https://www.qlik.com/us/products/qlik-geoanalytics.
[13] "Drilldown Cartogram, Microsoft Power BI," [Online]. Available:
https://appsource.microsoft.com/en-us/product/power-bi-
visuals/WA104381045?src=office&tab=Overview.
[14] "Plotly - Modern Visualization for the Data Era," [Online]. Available:
https://plot.ly/.
[15] "DataHero - The fastest easiest way to understand your data," [Online].
Available: https://datahero.com/.
[16] "Chart.js - Simple yet flexible JavaScript charting for designers & developers,"
[Online]. Available: http://www.chartjs.org/.
[17] "Fusion Charts - JavaScript charts for web & mobile," [Online]. Available:
https://www.fusioncharts.com/.
[18] "Google Charts," [Online]. Available:
https://developers.google.com/chart/interactive/docs/.
[19] "Processing.js - a port of the Processing Visualization Language," [Online].
Available: http://processingjs.org/.
[20] "Leaflet - an open-source JavaScript library for mobile-friendly interactive
maps," [Online]. Available: http://leafletjs.com/.
[21] "Data Driven Documents," [Online]. Available: https://d3js.org/.
[22] "C3.js D3-based reusable chart library," [Online]. Available: http://c3js.org/.
[23] T. Munzner and S. North, "InfoVis 2003 Call for Participation: Papers,"
[Online]. Available: http://www.infovis.org/infovis/2003/CFP/#papers..
[24] M. Sedlmair, M. Meyer and T. Munzner, "Design study methodology:
Reflections from the trenches and the stacks," IEEE transactions on
visualization and computer graphics, vol. 18, no. 12, pp. 2431-2440, 2012.
[25] C. Plaisant, "The challenge of information visualization evaluation," in
Proceedings of the working conference on Advanced visual interfaces, 2004.
[26] "Visualization (2IVM20)," 01 08 2017. [Online]. Available:
https://www.tue.nl/en/university/departments/mathematics-and-computer-
science/research/research-programs-computer-science/section-algorithms-
and-visualization-av/visualization-vis/courses/visualization-2ivm20/.
55
[27] B. Shneiderman, "The eyes have it: A task by data type taxonomy for
information visualizations," in Visual Languages, 1996. Proceedings., IEEE
Symposium on, 1996.
[28] T. Castermans, B. Speckmann, K. Verbeek, M. Westenberg, A. Betti and H. van
den Berg, "GlamMap: geovisualization for e-humanities," in Workshop on
Visualization for the Digital Humanities (Vis4DH), 2016.
[29] M. Stone, "A field guide to digital color," 2016.
[30] M. Chen, S. Walton, K. Berger, J. Thiyagalingam, B. Duffy, H. Fang, C. Holloway
and A. E. Trefethen, "Visual multiplexing," Computer Graphics Forum, vol. 33,
no. 3, pp. 241-250, 2014.
[31] H. Lam, E. Bertini, P. Isenberg, C. Plaisant and S. Carpendale, "Seven guiding
scenarios for information visualization evaluation," UNIVERSITY OF CALGARY,
2011.
[32] "Farlex Dictionary of Idioms. S.v. "Installed base."," 03 01 2017. [Online].
Available: https://idioms.thefreedictionary.com/Installed+base.
[33] "Stacked Graph of Unemployed U.S. Workers by Industry," 01 09 2017.
[Online]. Available:
https://homes.cs.washington.edu/~jheer//files/zoo/ex/time/stack.html.
[34] S. P. Dow, A. Glassco, J. Kass, M. Schwarz, D. L. Schwartz and S. R. Klemmer,
"Parallel prototyping leads to better design results, more divergence, and
increased self-efficacy," Design Thinking Research, pp. 127-153, 2012.
[35] A. Dix, "Human-computer interaction," Encyclopedia of database systems, pp.
1327-1331, 2009.
[36] C. Ware, "Information visualization: perception for design," 2012.
[37] J. Heer, M. Bostock and V. Ogievetsky, "A tour through the visualization zoo,"
Queue, vol. 8, no. 5, p. 20, 2010.
[38] H.-J. Schulz, T. Nocke, M. Heitzler and H. Schumann, "A design space of
visualization tasks," IEEE Transactions on Visualization and Computer Graphics,
vol. 19, no. 12, pp. 2366-2375, 2013.
[39] P. Lake and P. Crowther, "Data, an Organisational Asset," Concise Guide to
Databases, 2013.
[40] S. Liu, W. Cui, Y. Wu and M. Liu, "A survey on information visualization: recent
advances and challenges," in The Visual Computer, Springer, 2014, pp. 1373-
1393.
56
[41] J.-D. Fekete, J. J. Van Wijk, J. T. Stasko and C. North, "The value of information
visualization," in Information visualization, Springer, 2008.
[42] L. Nowell, R. Schulman and D. Hix, "Graphical encoding for information
visualization: an empirical study," in Information Visualization, 2002. INFOVIS
2002. IEEE Symposium on, 2002.
[43] F. D. Davis, R. P. Bagozzi and P. R. Warshaw, "User acceptance of computer
technology: a comparison of two theoretical models," Management science, vol.
35, no. 8, pp. 982-1003, 1989.
57
APPENDIX A
Design study pitfalls
ID Pitfall Stage PF-1 premature advance: jumping forward over stages general PF-2 premature start: insufficient knowledge of vis literature learn PF-3 premature commitment: collaboration with wrong people winnow PF-4 no real data available (yet) winnow PF-5 insufficient time available from potential collaborators winnow PF-6 no need for visualization: problem can be automated winnow PF-7 researcher expertise does not match domain problem winnow PF-8 no need for research: engineering vs. research project winnow PF-9 no need for change: existing tools are good enough winnow PF-10 no real/important/recurring task winnow PF-11 no rapport with collaborators winnow PF-12 not identifying front line analyst and gatekeeper before start cast PF-13 assuming every project will have the same role distribution cast PF-14 mistaking fellow tool builders for real end users cast PF-15 ignoring practices that currently work well discover PF-16 expecting just talking or fly on wall to work discover PF-17 experts focusing on visualization design vs. domain problem discover PF-18 learning their problems/language: too little / too much discover PF-19 abstraction: too little design PF-20 premature design commitment: consideration space too small design PF-21 mistaking technique-driven for problem-driven work design PF-22 non-rapid prototyping implement PF-23 usability: too little / too much implement PF-24 premature end: insufficient deploy time built into schedule deploy PF-25 usage scenario not case study: non-real task/data/user deploy PF-26 liking necessary but not sufficient for validation deploy PF-27 failing to improve guidelines: confirm, refine, reject, propose reflect PF-28 insufficient writing time built into schedule write PF-29 no technique contribution 6=good design study write PF-30 too much domain background in paper write PF-31 story told chronologically vs. focus on final results write PF-32 premature end: win race vs. practice music for debut write
Ref: (Design Study Methodology: Reflections from the Trenches and the Stacks, Sedlmair et. al. 2012)
58
APPENDIX B
Properties of objects in the data model
Properties of Product
Product Id: is a unique identifier given to a specific type of product. For example, the
Philips Azurion product family consists of different products such as Azurion
3 F15 and Azurion 3 F12. The internal unique Ids given to these could be
AZU00315 and AZU00312 respectively. These Product Ids are also useful for
grouping products into families of products as stated in the example.
Product Name: is the commercial name of the product, e.g., Azurion 3 F12.
Product Type: is a grouping of the product based on its characteristics. For example
Philips BV Pulsera of type Mobile System3 while Philips Allura Xper FD20 is of
type Fixed System4
Properties of Customer
Customer Id: is an identifier given to uniquely identify a customer record in the
database. This could be an alphanumeric value and may sometimes have a
meaningful encoding. For example C002232 would refer to a company and
H983778 could refer to a hospital.
Name: is the customer name as it appears on official documents.
Address: is the postal address of the customer as per the rules set for each
geographical region. This is a free text field that helps in postal communication
with the customer and is also used on official documents.
Latitude: is the geographic coordinate that specifies the north–south position of the
Customer Address on the Earth's surface. It is a floating point number ranging
3 A system that can be transported from one location to another 4 A system that is fixed in a building room and cannot be moved around
59
from 0 at the earth’s Equator to +90 at the North Pole and −90 at the South
Pole.
Longitude: is the geographic coordinate that specifies the east–west position of the
Customer Address on the Earth's surface. It is a floating point number ranging
from 0 at the Prime Meridian to +180 eastward and −180 westward.
The latitude and longitude are used for identifying the exact geographical location of
the Customer, which is required for some processes such as planning of an engineer’s
visit to the hospital for a service activity.
Properties of Installed Product
Installed Product Id: is the global (within Philips’ information systems) unique
identifier for an installed product. This could be a meaningless running
number or a meaningful combination of a product number and a serial number
- a production identifier.
Installation date: is the date on which the installed product began its operation. For
large systems such as IGT systems, this is typically a few weeks after the
product has been shipped to the customer location. Since these are complex
systems made of several huge components that are shipped separately, the
assembly and configuration of these systems as per the customer’s needs takes
a few weeks.
End of Life date: is the expected or recommended date of the system being out of
operation. This is not the warranty date, which is usually a year or two after
the installation date. This is the date when the research and development team
expects the production to be stopped and can no longer guarantee spare parts
supply. This date depends on the type of products and the availability of spare
parts in the warehouses.
Properties of Contract
Contract Id: is a unique alphanumeric string that can be to identify a specific contract.
It could be used to for reference by other data elements.
Contract Type: is the type of the contract which describes what kind of agreements
are applicable. For example, a Value contract could provide remote
60
maintenance service within 4 hours and onsite support within 2 working days
whereas a Gold contract could provide immediate remote support and onsite
support within a few hours on the same day. There are of course many more
terms and conditions attached to a contract type, such as how many parts can
be replaced for free and such, but it is out of scope of this thesis report to
explain all of that.
Customer: is the company or hospital that is using a Philips product and is paying for
a service contract.
Covered Product: is the installed product that is covered by the contract. This is the
product that Philips guarantees through the contract that service activities
shall be executed on this product based on the terms and conditions laid out
in the contract.
Start Date: is the date from which the contract comes into effect. Philips’ guarantee of
service begins from this days onwards.
End Date: is the date until which the contract is valid. After this date onwards, Philips
is no longer bound to adhere to the service delivery as per the terms laid out
in the contract. However, this does not mean that if the system breaks down
after this date, Philips will no longer provide service. Philips will still perform
maintenance activities but the amount charged to the customer and the hours
of service delivery could be different from what was mentioned in the contract.
Contract Price: is the total value of the contract in terms of money. For example, a five
year contract for onsite support and a fixed number of free part replacements
could cost 50.000 euros. A point to be noted is that this amount may
sometimes be paid in instalments on a periodic basis such as once in a year.
Revenue: is amount of money Philips has received till date on the contract. This could
be equal to the contract price if the payment is made at once or it could be from
the total contract price if the payment is in installments. From the previous
example, in Contract Price, if the contract is sold for example 5 years for 50.000
dollars with a yearly payment basis, the installment per year would be 10.000
dollars. In the third year of the contract, the Revenue from the contract would
be 30.000 dollars.
Cost: is the amount of money Philips has spent on the maintenance activities on the
covered product till date. Philips incurs costs from the service parts replaced
and the manual labor involved in the repairs and upgrades. If the system being
61
serviced is covered by a contract, these charges are booked against the
contract in order to track how much Philips has spent for service delivery on
the covered product. This could later be used to calculate the profit margin
which is the difference between the Revenue and the Cost. It is very much
possible that the contract cost exceeds its revenue, in which case Philips is
making a loss instead of profit.
Properties of Service Work Order
Order Number: is a unique identifier assigned to a service work order that could
consist of manual labor and parts replacements.
Date: is the date on which the maintenance activities were carried out on an installed
product.
Installed Product: is the installed product on which the maintenance activities like a
repair or upgrade were executed.
Contract: A contract that has the labor and/or part coverage is registered in this field.
The costs incurred on the service work order are booked against the contract
as long as the terms and conditions of the contract cover the labor and the
parts involved.
Labor Cost: is the cost of manual labor for carrying out the service work order. This
is always in terms of money and is expressed in local currency.
Material Cost: is the cost of the parts replaced5 while carrying out the service work
order. This field is also always in terms of money and the currency depends on
from where the part was ordered. If no parts are replaced while carrying out
the service activity, this field will contain zero.
5 A Philips engineer almost never attempts to repair a defective part. (S)he always removes it from the system and replaces it with a new one. The old parts are sent back to the factory where they are refurbished or disposed in a controlled manner.
62
APPENDIX C
Evaluation questionnaire and responses
# Questions Response
1 The tool helps to explore data faster Strongly agree
2 Useful information can be extracted from the tool Strongly agree
3 The tool is helpful in communicating concepts to third parties
Agree
4 The tool is easy to understand or learn Strongly agree
5 Please rate the usefulness of the "map" overview 5
6 Please rate the usefulness of different colored icons on the map based on profitability
5
7 Please rate the usefulness of the "End of life" visualization 5
8 Please rate the usefulness of the "System age" visualization 4
9 Please rate the usefulness of the "Expiring contracts" visualization
5
10 Please rate the usefulness of the "Contract profitability" visualization
5
11 Please rate the usefulness of the SWO labor and material costs popup
4
12 Are there any must-have features missing in the tool that will hinder its adoption?
No
Responses to open ended questions:
Question #13: What current features can be enhanced to make the tool immediately
usable?
Response: I do not see a need to enhance any of the current features.
Question #14: What features are missing in the tool?
Response: What would have to be added is a user management control to limit views
for users to their area of concern (e.g. a country/market/zone/region view) but this is
not related to the visualization of the tool. What could also be a future enhancement is
a report/download function of the customers concerned that can be printed to take
along to a customer or emailed, etc.
63
APPENDIX D
Technical details of tool
List of plugins used
Twitter bootstrap (https://getbootstrap.com/)
Leaflet JavaScript library and plugins (http://leafletjs.com/)
c3js (http://c3js.org/)