Linköpings universitetSE–581 83 Linköping+46 13 28 10 00 , www.liu.se

Linköping University | Department of Computer and Information ScienceMaster thesis, 30 ECTS | Datateknik

2020 | LIU-IDA/LITH-EX-A--20/041--SE

Mobile application design forcontextual usability and oper-ability in underground minesDesign av en mobilapplikation för kontextuell användbarhet ochgenomförbarhet i en underjordsgruva

Summia Al-muftiManuela Tesanovic

Supervisor : Mattias ArvolaExaminer : Stefan Holmlid

Upphovsrätt

Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publicer-ingsdatum under förutsättning att inga extraordinära omständigheter uppstår.Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka ko-pior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervis-ning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annananvändning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säker-heten och tillgängligheten finns lösningar av teknisk och administrativ art.Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning somgod sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentetändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsman-nens litterära eller konstnärliga anseende eller egenart.För ytterligare information om Linköping University Electronic Press se förlagets hemsidahttp://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet - or its possible replacement - for aperiod of 25 years starting from the date of publication barring exceptional circumstances.The online availability of the document implies permanent permission for anyone to read, to down-load, or to print out single copies for his/hers own use and to use it unchanged for non-commercialresearch and educational purpose. Subsequent transfers of copyright cannot revoke this permission.All other uses of the document are conditional upon the consent of the copyright owner. The publisherhas taken technical and administrative measures to assure authenticity, security and accessibility.According to intellectual property law the author has the right to bementionedwhen his/her workis accessed as described above and to be protected against infringement.For additional information about the Linköping University Electronic Press and its proceduresfor publication and for assurance of document integrity, please refer to its www home page:http://www.ep.liu.se/.

© Summia Al-muftiManuela Tesanovic

Abstract

The aim of the thesis was to develop a usable mobile application prototype to be usedin the underground mining environment. In order to fulfill the aim, the research questionHow can a mobile application be designed for usability with focus on operability for an undergroundmine? was researched, analysed and answered. The main methods for driving the designprocess were ISO 9241-210, Human-centred design for interactive systems, requirement en-gineering and conceptual design. The results of the thesis were based on qualitative data,collected from semi-structured interviews from five respondents. These respondents hada background as a operator in underground mines in different countries. The qualitativedata was analysed and interpreted into functional and non-functional user requirements.The user requirements in parallel with design principles were used to produce a final con-cept that would be transformed from a low fidelity into a high fidelity prototype. The highfidelity prototype was developed using Android Studio, Java and later tested and evalu-ated using SUS questionnaire and usability heuristics to rate the overall usability of theapplication . The answer to the research question lied in the methodology used in this the-sis. This was achieved by involving the stakeholders, people affected by the future designin the entire process, with different methodology during the different phases of the designprocess.

Acknowledgments

We want to thank our supervisor Mattias Arvola and examiner Stefan Holmlid for the helpand support they have given us throughout the thesis. We also want to thank the supervisorsat Combitech to giving us the opportunity to perform the thesis.

In addition, we would like to thank our families and beloved ones for all the supportthat helped us staying motivated.

iv

Contents

Abstract iii

Acknowledgments iv

Contents v

List of Figures vii

List of Tables viii

1 Introduction 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Research question . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Theory 42.1 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Human-Centered Design Principles . . . . . . . . . . . . . . . . . . . . . . . . . 62.4 Design process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.5 Requirement engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.6 Design rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.7 Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.8 Pugh matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.9 Agile software development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.10 Usability evaluation methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.11 Theory synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3 Method 193.1 Initial phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2 Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.3 Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.4 Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Results 274.1 Initial phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.2 Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.3 Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.4 Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5 Discussion 435.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

v

5.2 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.3 Replicability, Reliability and Validity . . . . . . . . . . . . . . . . . . . . . . . . . 505.4 The work in a wider context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6 Conclusion 52

A Appendix: Interview questions 54A.1 User background and demographic information . . . . . . . . . . . . . . . . . . 54A.2 Role and responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54A.3 Communication and challenges in the domain and/or users . . . . . . . . . . . 55A.4 Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55A.5 Needs and requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

B Appendix: Requirements initial phase 57

C Appendix: Persona 59C.1 Persona 1: Sofia Eriksson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59C.2 Persona 1: Situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60C.3 Persona 1: Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60C.4 Persona 2: Kalle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61C.5 Persona 2: Situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61C.6 Persona 2: scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

D Appendix: Requirements sprint 1 63

E Appendix: Requirement validation Sprint 1 64

F Appendix: Conceptual design questions 65F.1 Design questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

G Appendix: Design concepts 66

Bibliography 69

vi

List of Figures

2.1 Human-centered design process adapted from ISO 9241-210 . . . . . . . . . . . . . 72.2 Adapted requirement elicitation and analysis process . . . . . . . . . . . . . . . . . 132.3 A state transition diagram specifying all of the legal moves within the IBIS method 152.4 Prototype process model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1 Issue-based information system diagram . . . . . . . . . . . . . . . . . . . . . . . . 294.2 Concept 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.3 Concept 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.4 Login layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.5 Main layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.6 Tasks layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.7 Tasks description layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.8 Reported errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.9 Error description layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.10 New error report layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.11 Request supply layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

C.1 Persona 1: Sofia Eriksson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59C.2 Persona 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

G.1 Wireflow concept 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67G.2 Wireflow concept 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

vii

List of Tables

2.1 Usability taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Non-functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3 Requirement validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1 Recruited respondents for the project . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2 Recruited respondents for evaluation of the High Fidelity Prototype . . . . . . . . 233.3 Tasks used in Sprint 3 for usability evaluation of the implemented mobile applica-

tion prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.4 Usability Heuristics used in Sprint 3 for heuristic evaluation of the implemented

mobile application prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.1 Initial requirement from the stakeholders . . . . . . . . . . . . . . . . . . . . . . . . 274.2 Pugh matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.3 SUS Evaluation for Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.4 Final result of the heuristic evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 42

viii

1 Introduction

This section gives an introduction to the thesis project in order to understand the motivationand aim of the study.

1.1 Motivation

After the world war two, new mechanized mining methods were introduced in the coalmines. In 1951, Eric Trist and Ken Baumforth [39] conducted and published a comparativestudy of two British coal mines where one had a high productivity and the other low per-formance and labour issues. They identified that the traditional way of working could notsurvive mechanization and that new technology exceeded workers activities and interaction,forcing the workers on the technology and leading to performance issues. They identifiedthat the best solution was a balance between technical and social factors. It was then theidea of socio-technical systems was born but not yet defined. The term socio-technical sys-tem(STS) approach was defined in 1960 by Frederick Emery and Eric Trist [11], describingtechnical systems that involved interactions between humans, machines and environmentalaspects of the work system. In the 1970s the socio-technical principles were applied by EnidMumford to office systems, when computer systems were first introduced in the workplace.Mumford realised that implementation of computer systems generally resulted in failureto produce expected outcome. She identified the cause of the failure was the inability toovercome human factors associated with the implementation and use of computers. AfterMumford’s study, more researchers became interested in the field of interaction with comput-ers and design technologies. In 1980 the term user- computer interaction or human-computerinteraction(HCI) was first used. Card et al. [14] presented a model for user performancewith interactive systems but identified another important aspect of the performance. Theyidentified that the current systems were developed for expert users and did not considerthe aspects of non expert users and non routine tasks for an error-free performance. Theystated that the current models should not be used to eliminate the design problem but tohelp the system designer to take in consideration the different aspects. The development ofsocio-technical system design has led to more acceptable systems to the end user and a bettervalue to the stakeholders.

Nowadays the human-centred design is set by the international standards organization

1

1.2. Aim

which follows the design principles explicit of the users, their task and the context they areconducted in [2]. Human-centred design aims to make an interactive system more usableand useful by focusing on the users and their needs [2]. According to J. Nielsen [28] a highusability is desirable but it does not appear magically just because we want it. Having a goodintention when developing an interactive computer system is not enough to make it usable.Therefore, usability is needed in the development process of the interactive system, by usingestablished methods to make sure that the usability is qualified enough.

The Human-Computer-Interaction has an important role when designing mobile appli-cations and creating more interactive systems. The underground mine, similar to manyother industry processes can benefit from the increased usage of the mobile applications andHCI. For most industrial plants the standard is a control room with operators, computersand screens used to keep track of equipment conditions, personnel and deviating activity.However, the studies do not take the communication and interaction between the controlroom and the personnel in the field into consideration. Today, the underground mine oper-ators are still using traditional and non-digital tools to communicate, receive the work plan,assignments and informing issues. Thus, there seems to be a need of a digitisation in formof a highly usable mobile application that can be used by the operators in the undergroundmine to improve the communication and HCI between the the control room and the field op-erators. Such computer system need to be designed based on the user’s work tasks, contextand needs to make their work more effective.

1.2 Aim

The aim of the thesis project was to develop a usable mobile application prototype that couldeasily be integrated with the platform SAFE in the underground mining environment. Thedesign of the mobile application should follow design approaches conducted to design a us-able software application in order to satisfy the requirements for usability and the systemintended for the end user. The design process was used to develop a mobile application pro-totype, focusing on the user’s needs, work tasks and context such as working conditions andenvironment. This provided a basis for evaluation and conclusion regarding the develop-ment of a mobile application for the underground mine.

1.3 Research question

The mobile application needs to be usable from the users perspective by providing the userwith the necessary functionalities and allow users with different needs to adapt and use theapplication. In terms of usability, this is called operability[4]. To fulfill the aim of the thesisproject, the following question will be discussed and answered:

How can a mobile application be designed for usability with focus on operability for an undergroundmine?

1.4 Delimitations

The mobile application functionality will be developed with the platform SAFE(SituationalAwareness for Enhanced Security). It is an open-integration software platform for mission-critical operations commonly used in command and control rooms to improve workflowsand processes. The thesis will be conducted parallel with an ongoing project at CombitechAB regarding underground mine. The design and functionality of the final prototype willbe restricted to the composed components of the parallel project. The final prototype mobile

2

1.4. Delimitations

application will be tested on an android tablet with capacitive touch screen in order to imi-tate the mobile devices used in the ongoing project. The design and evaluation of the finalprototype will only consider field operators working within production in the undergroundmine. We will assume a good and stable wireless communication due to the well establishednetwork structure in Swedish underground mines. Thus, the thesis project will not take intoconsideration bad network conditions. Due to time limitations of the master thesis the re-sulting prototype aims to serve as a base for further development rather then a completesolution.

3

2 Theory

This chapter aims to give the reader a better knowledge about the literature study and theoryused in the method, result and discussion. It also aims to gives a better understanding of theaim of the thesis project.

2.1 Related work

Process plants and industrial control rooms are constructed as a large board of technologicalcomponents where the control rooms are the center of all information exchange and output.The general idea of control rooms in process plants has for many years been associated as thecentralized main gateway to information about and control of the plant. Most applicationexamples in the literature are applied on an uniform context such as office environments.Nilsson et. al.[32] implemented a mobile device with a user centered approach on a processindustry. The paper evaluated the environment of how operators both in the control roomand in the field could operate in order to decentralise the plant and to support the interactionbetween the operators and control room. Operators main role in the control room was tomonitor the plant state via different systems. The field operators role involved physicalinspection, a data collection of the physical components. The study presented a prototype, amobile device with multiple interfaces and displayed, depending on work activities, personalinformation collection of work activities and audio notes about activities related to a specificcomponent.

Another aspect of the industrial process plant was the industrial maintenance. Indus-trial maintenance was a complex and knowledge intensive field with a big need of easyaccessible and situational relevant knowledge. Aromaa et. al. [6] emphasized the importanceof interaction and knowledge sharing. The paper identified the importance of informationsharing but also the problem of information accessibility due to many global services. Toprevent loss of knowledge they recommended that knowledge should be identified andconverted into information systems and the key to achieving this was the end user. The enduser operates at field level where situational and relevant information exist and was ideal forcollecting and utilizing this type of knowledge.

For the past few years a rise is seen in the usage of mobile application in many industry

4

2.2. Usability

fields. K.H. Moe et. al. [18] mean that much of the underlying technology for designingand developing a mobile application is nowadays available. The usability of these mobileapplications remain a serious concern. The study investigated the design of a highly usablemobile application for field data collection in the utility industry such as water, electricityand telecommunication. The authors meant that the utilities needed to capture and maintaincomprehensive information about many assets such as the network infrastructure accordingto the assets location, technical aspects and logical configuration. The study took into con-sideration the country’s infrastructure and resources. The aim of the study was to propose ausable mobile application prototype design based on a usage-centered design process whichfocused on the user’s tasks and work context not only the user’s needs. Furthermore, thestudy included a usability evaluation of the mobile application prototype conducted withthe users in the field[18].

The authors emphasized the importance of considering the usability when designing amobile application but also that the design of the application needed to be accepted by theuser before implementation. The proposed design was not necessarily applicable for everyfield but provided an understanding of the requirements needed to be considered as anuser-centered mobile application. [18]

2.2 Usability

The international organization for standardization defines usability as “degree to which a prod-uct or system can be used by specified users to achieve specified goals with effectiveness, efficiency andsatisfaction in a specified context of use” [23]. ISO/IEC 25010:2011 classified the term usability asone of the eight characteristics in the quality product model. One way to measure usabilityas a product quality characteristic is to measure its sub-characteristics or attributes. Theseattributes are appropriateness, recognizability, operability, learnability, user error protection,user interface aesthetics and accessibility [23]. ISO/IEC 25010:2011 defines operability asdegree to which a product or system has attributes that make it easy to operate and control [23].

D. Alonso-Ríos et al. presented a detailed taxonomy of usability that was organized hi-erarchically and contained exhaustive descriptions of usability attributes, see table 2.1. Theauthors performed a literature study of existing definitions and classifications of usability.New usability attributes were added to the existing ones. One of these attributes was op-erability which was inspired from ISO/IEC. Operability was defined as "the capacity of thesystem to provide users with the necessary functionalities and to permit users with different needs toadapt and use the system" [4]. D. Alonso-Ríos et al. stated that most of the existing classifica-tions did not include an attribute that was defined in equivalent terms as their operabilityattribute. They meant that ISO/IEC described operability related to aspects of suitability. [4].

J. Nielsen describes usability as a part of a large system called acceptability, which is aboutmaking the system good enough to satisfy the needs and requirements of the users and otherpotential stakeholders. The acceptability of a system is a combination of its social accept-ability and practical acceptability. When analyzing a systems practical acceptability, variouscategories such as cost, support and usefulness should be considered. Usefulness is definedas the issue of whether the system can be used to achieve some desired goal. Usability is oneof the two categories under usefulness and is the question of how well the users can use thefunctionality of the system [29]. Further, the author means that high usability is desirable,but it does not magically appear just because we want it. To ensure the usability of interactivecomputer products, usability must be actively included in the software development pro-cess. He means in order to design a usable application, established methods such as usability

5

2.3. Human-Centered Design Principles

engineering must be used, good intentions are not enough.

J. Nielsen means that usability is not a single, one dimension property but it has multi-ple components. These components are learnability, efficiency, memorability, errors andsatisfaction. Learnability means that the system should be easy to learn. Efficiency meansthat the system should be efficient to the user, so the user can achieve a high level of produc-tivity. Memorability means that the system should be easy to remember. Errors means thatthe systems should have a low error rate. Finally, satisfaction means that the system shouldbe pleasant to use [29]. According to D. Alonso-Ríos et al. [4] these component proposed by J.Nielsen are widely accepted by many researchers. Table 2.1 presents the usability taxonomyby D. Alonso-Ríos et al.[4].

Usability attribute DefinitionKnowability “The property by means of which the user can understand, learn, and

remember how to use the system”Operability “The capacity of the system to provide users with the necessary func-

tionalities and to permit users with different needs to adapt and use thesystem

Efficiency “The capacity of the system to produce appropriate results in return forthe resources that are invested”

Robustness “The capacity of the system to resist error and adverse situations”Safety “The capacity to avoid risk and damage derived from the use of the sys-

tem”Subjective satisfaction “The capacity of the system to produce feelings of pleasure and interest

in users”

Table 2.1: Usability taxonomy

2.3 Human-Centered Design Principles

Human-Centred design is an approach to interactive systems development. According to theinternational organization for standardization, the aim of this approach is to make an inter-active computer system usable and useful. This is achieved by considering the user’s needs,requirements and by applying human factors and usability techniques [2]. The approach canbe used to improve effectiveness, efficiency, user satisfaction and other usability attributes.

ISO 9241-110:2006 [1] defines seven human-centred design principles, so called dialogueprinciples that can be applied in the analysis, design and evaluation of interactive systems.These dialogue principles are useful to help prevent users of interactive systems from expe-riencing usability problems such as misleading information and unnecessary steps that arenot required as part of the task [1]. These seven dialogue principles are listed below.

• Suitability for the task: The dialog and functionality should support the user in thecompletion of the task.

• Self-descriptiveness: It should always be clear to the user which part of the systemthey are in, where they are within a dialogue, which activities are possible to take andhow these activities can be performed.

6

2.4. Design process

• Conformity with user expectation: The dialogue of the system should meet the con-textual needs of the user and correspond to commonly accepted conventions.

• Suitability for learning: The dialogue should support and guide the user to use thesystem.

• Controllability: The user should have the possibility to control the pace of the interac-tion with the dialogue until the tasks and goals are completed.

• Error tolerance: The goal should be achieved with no or minimal corrective action bythe user.

• Suitability for individualization: The system should allow the users to modify thepresentation of information to meet their individual needs.

2.4 Design process

This section presents different researches and approaches conducted to design a usable soft-ware application based on the user and the context-of-use.

Human-centered design activities

ISO 9241-210 [1], human-centred design for interactive systems, is a standard that providesa guidance for designing an interactive system with the user in focus. The ISO standardidentifies four main human-centered design activities that are iterative and aim to manage thedesign processes but does not provide detailed analysis of design methods and techniques.These four activities are listed below. Figure 2.1 from [1] shows an illustration of the human-centered design activities.

Figure 2.1: Human-centered design process adapted from ISO 9241-210

1. Understand and specify context of use: the aim of this activity is to collect informationabout the user and the environment of use in order to understand the context of thesystem to be used. It is important to understand the tasks the user wants to use theproduct for. The outputs of this activity is normally a description of the context of use.

7

2.4. Design process

2. Specify the user requirement: this activity is about identifying user needs and require-ments provided by the user and other stakeholders and should be based on the contextof use. The aim is to determine the success criteria of usability for the interactive systembased on the needs of the user and their tasks. The outputs of this activity is normallya context of use specification, a user needs description and user requirements specifica-tion.

3. Produce design solutions to meet these requirements: in this activity one should in-clude HCI knowledge and user-experience(UX) when designing and implementing theinteraction, user interface and user tasks in order to meet the requirements of the usersand stakeholders.The design should also follow the human-centered design principlespresented above. The outputs of this activity are normally user interaction specification,user interface specification and implemented user interface.

4. Evaluate the designs against requirements: in this activity, the usability of design isevaluated in order to insure that the design meets user tasks and requirements based onthe user’s perspective. The outputs of this activity are normally results of the evaluationand tests.

As mentioned earlier the user is in focus every step in human-centered design process andone effective method for applying this focus is using personas. Further information of howto create and utilize persona when designing human-centered systems will be clarified in thenext section.

Persona and scenario

Persona

When developing a new product it is important to include users everyday experience andneeds. System developers often use the definition of a user in their projects without havingmet or included any. One approach is to develop a persona. The persona does not include areal person but is a representation of the user. The method is essentially qualitative and hasa holistic perspective. The method aims to include the users in the design process of IT sys-tems and communicate an understanding of the user to all participants in the developmentprocess. Persona helps to envision the users needs in connection with their context withouttaking in considerations what they otherwise think and are interested in. The problem withthis vision is that persona is most often a stereotypical or one-dimensional version of theusers. However, the persona method aims to create a empathic description of the user. Usingthe method requires a wide understanding of the whole context [31].

One criticism of the persona model is that the concept of persona creates a distance toreal users, however L.Nielsen states that there are different ways to produce a persona butthe focus should be on the relevant attributes associated with the specific context [31]. Thenumber of personas needed for a project depends solely on how much the users variatewithin the specific area. Personas are however a tool to target design and the aim of theprocess is to comprehend data and reduce it as much as possible. One important aspect orlimitation in the human cognition is that humans find it difficult to distinguish personas ifthere are more than five [31].

According to L.Nielsen [31] there are four different perspectives in the literature on persona:goal-directed perspective, role-based perspective, engaging perspective and fiction-basedperspective. The first three perspectives are based on data and the fourth is fictive, createdfrom designers assumptions and intuition, also called ad-hoc personas. The goal-directedperspective approach focuses on one persona as the primary and the rest is used on the side.

8

2.4. Design process

Here the persona is defined by different goals such as personal, practical and organizationalas well by the relationship: emotions and goals using the product. The role-based perspectiveis also goal-oriented but uses both qualitative and quantitative data to clearly support thepersona description. In difference from the goal-directed perspective this approach can notbe used alone but is supposed to be used with other methods. The role-based approachfocuses on the users role in the organization, containing information of a typical day or weekin the life of the user, hopes and fears [31].

The engaging perspective aims to involve the designer, to go from seeing the user as astereotype and to envision the lives of the personas. The two first perspectives have beencriticized for creating a risk for stereotypical descriptions, focusing on the behaviour andnot getting a broader understanding of the whole person. The perspective demands a widerknowledge about the users with focus on the social background, characteristics and relation-ship. The fiction-based perspective is used when a designer needs to explore a design andinsight in a field. The perspective is based on the designers own intuitions and experience,creating a fictive persona [31]. Because the persona is fictitious some criticism has risenregarding the scientific value, stating that the characteristics are not based on actual peopleand not reproducible to be classified as a scientific method [31]. Further, L.Nielsen presents10 steps for producing persona. The model is a process, ensuring a user focused design inall phases of the project divided in four main parts: collection and analysis of data, descrip-tion of persona, scenarios for problem analysis and development of ideas, involvement andacceptance of the stakeholders [31]. The following ten steps are as follows:

1. Data collection: Use different sources to collect as much knowledge as possible aboutthe users.

2. Hypothesis: Form a hypothesis based on the data collection. The hypothesis is a gen-eral idea of the different users in the focus area and how they differ from each other.

3. Acceptance of the hypothesis: Presented the hypothesis to all participants in the projectand compare to existing knowledge. The participants can either support or reject thehypothesis.

4. Number of personas: Decide the final number of personas.

5. Descriptions of personas: Prepare persona descriptions. The descriptions should ex-press enough understanding and empathy for the users. The persona should presentusers needs.

6. Situations: Describe situations, basis of a scenario, that could trigger the use of theproduct.

7. Organization acceptance: Involve the participants of the project in the developmentof the persona, either by asking about their opinion or letting them participate in theprocess.

8. Disseminate knowledge: Share persona descriptions to stakeholders, internal and pos-sible external.

9. Scenario: Write scenario about how a persona uses a future product.

10. Adjustments: The persona descriptions should be revised and updated regularly, ap-proximately once a year or when new aspects could affect the description for examplenew information.

9

2.4. Design process

Scenario

In the design process, persona and the descriptions contributes to maintain the perspective ofthe user. In order to imagine how the product can and will be used, scenarios can encapsulatethe description of an user to achieve a specific outcome under specified circumstances overa certain time interval. Scenarios have two main uses. The first is used during the designprocess as a way of expressing and understanding how the users will eventually interactwith the system. The second can be used during the design evaluation to get feedback fromthe user before creating the prototype [29].

Conceptual design

Conceptual design is the idea of the intended use, e.g what the design should do and why,when, where and how it should be used. The conceptual design also includes the definitionof its users [7]. A.Parush [33] purposed a layered framework of the conceptual design start-ing from the bottom up by defining the function level and working upwards where we cansee the UI. The purpose of this framework is to define and analyse the conceptual model bydefining all the layers needed behind the UI as the outer layer and imagine there are innerand hidden layers that we need to peel of to uncover the core. The framework consists offive layers, the function level, the configuration level, the navigation and policy level, theform level and lastly the details level. The conceptual design is about what the user does andwhere but without giving any details. Thus the conceptual design spans the three bottomlevels and more details about the design and the transforming the conceptual design intodetailed UI design are given in the two upper layers, form level and details level.

The function level includes all the parameters, information items and actions that are re-lated to the domain of the application. These are then grouped into so called functionalchunks that are based on a common purpose in the given domain or meaning for the user.The functional chunks are grouped into three forms: task-oriented, object oriented andcontent-oriented chunk. The methodology presented in the book focuses primary on thetask-oriented and object-oriented chunks. The task-oriented chunks are a group of tasks thatserve a common purpose and enable the user to achieve a concrete goal. The task-orientedchunks could also be for engagement with no specific utility. The object-oriented chunksincludes actions relevant to a specific object in the application domain. Lastly, the content-oriented chunks are related to a group of information items [33].

According to A.Parush [33] the configuration layer is about the relation between the func-tional chunks and the "places" the user visits and navigates in order to perform certain actionsor tasks and accomplish goals. The configuration layer includes interactive conceptual modelelements that are used to support the user to perform at least one task and provide the userwith an interaction opportunity to interact with the application and achieve the goal. Further,the navigation and policy layer describes how the users can get from one place to another.The layer includes a navigation map that represent the routes the user can take through theconceptual model to perform all the steps needed to achieve the goal of the interaction. Theroute map include the entry and exit points in order to start and finish the interaction andalso the direction of each link between conceptual elements.

A. Parush [33] discusses five important human performance factors that need to be con-sidered while implementing the conceptual model together with the term usability. Theauthor means that there is a strong connection between the human performance factors andusability. These human performance are related to cognitive, emotional and physical factors.Usability in the other hand is related to effectiveness, efficiency and subjective experienceassociated with the user interaction of an application. These human performance factors are:

10

2.5. Requirement engineering

1. Mental models and understanding: the user interface should be easy to understandand in order to do so the developer should understand the users by being in their situ-ation or in an action they take.

2. Location awareness: the user should get a correct destination awareness in order to eas-ily find the place that contains the desired parameters and actions. It is about knowingwhich place the user visited, place the user is at and the places are yet visited.

3. Visual search effectiveness: an application have more effective visual search whenthere are less conceptual elements in the same physical place, but this can also affect thelocation awareness negatively. It is important to have an effective and efficient visualsearch in order to find the target faster.

4. Operational load: the user can perform the tasks more accurately and faster hen thereare less and easier operations in the application. It is about having less mental andphysical effort to invest when performing actions when interacting with the application.Fewer places to visit and fewer routes result in fewer actions to take to get to the correcttarget which mean reduced operational load.

5. Working memory load: the user can perform the tasks more accurately and faster if theload on the working memory is reduced. The working memory is about the psychologyof perception, attention and memory and it is limited when it comes to the amount ofinformation it can store and use. The user should have fewer steps and places to visitto find the target and to do so the application should store the information about theplaces in a memory buffer.

Similar model to the Parush’s model[33] but with incorporation of the use situation at theconcept level is presented in [25],[7],[12]. The model divides the design space into five levelsand the conceptual design is presented as one of several levels of interaction design. Otherlevels include the structural level, functional level, interaction and presentation level. Thefunctional level answers the questions of what to design and why. It concern what functionsand information content are needed to to fulfill the intended use of the designed concept,what functions should the design allow, how should it support and provide value for theusers. Structural level concerns the layout of functions and information, how they are or-ganised and arranged i form of task structures and flowcharts structured in time and space.Interaction level concerns how the user interacts with the functions and contents and makesuse of functions, access or manipulate content and fulfil the intended use. Presentation levelconcerns the look and feel of the product such as style and layout of the design. The designdecisions made on one level are not isolated to other levels and affect the user experience.

2.5 Requirement engineering

Sommerville describes requirements of a system in "Software engineering 9"[36] as the de-scriptions of what the system should do, the services it should provide and its operationalconstraints. Requirements are the basis for every project, defining and reflecting what thestakeholders, in a new system, need from it and what the system must do in order to satisfythat need. Requirements engineering (RE) is a process of discovering, analysing, checkingand documenting these needs. Stakeholders include people who will directly interact withthe system, but also other people and organisations that have other interest in its existence.Requirement descriptions are separated into different levels: user and system requirements.User requirements are statements of what services the system is expected to provide tosystem users and constraints. System requirements are more detailed descriptions of system

11

2.5. Requirement engineering

functions, services and operational constraints. The functional specification or requirementsdocument defined exactly what is to be implemented as serves as a part of the contractbetween the buyer and developers. The requirements should be written at different lev-els because the requirements are read by different stakeholders in different ways. Afterdividing the requirements at different levels, they should be divided into functional andnon-functional requirements.

Functional requirements are statements of what the system should do, how the systemshould react to particular inputs and behave in different situations. The requirements mayalso state what the system should not do. Non-functional requirements are constraints onthe system services or functions. This type of requirements applies to the system as a wholeand include-time constraints, constrains on the development process and constraints bystandards. Non- functional requirements include performance, security, availability and con-strain of the system as a whole. This type of requirements affects the overall architecture of asystem, not individual components[36]. Table 2.2 is a classification of non-functional require-ments with three main characteristics, product requirements, organizational requirements,external requirements.

Non-functional requirements DefinitionProduct requirements Specify the behaviour of the software and include con-

strains such as performance: execution time, memory, re-liability, failure rate, security and usability requirements.

Organizational requirements Requirements from policies and procedures from thestakeholder’s organization. This includes requirementsof how the system will be used, programming language,development environment, operating environment.

External requirements Requirements of what a system must do to be approvedby a regulator, operating within the law and ethical re-quirements to ensure the system will be acceptable by theusers and public

Table 2.2: Non-functional requirements

Requirement engineering sub-process

The requirement engineering process includes four sub-processes: feasibility study, require-ment elicitation and analysis, requirement specification and requirement validation. Feasi-bility study is focusing on assessing if the system is useful to the business. Elicitation andanalysis process are discovering the requirements and specification is about forming theserequirements into a standard form. When the requirements are set, the validation process isdone to check that the requirements defining the system are what the customer want.

1. Feasibility study: Feasibility study is taken place early in the RE process and shouldanswer three questions: a) Does the system contribute to the overall objectives of theorganization? b) Can the system be implemented within schedule and budget usingcurrent technology? c) Can the system be integrated with other systems that are used?If one of these answers are no, it is not recommended to proceed with the project[37].

2. Requirement elicitation and analysis: After the feasibility study the next step in theprocess is requirement elicitation and analysis. The model of elicitation and analy-sis process is shown in Figure 2.2, an iterative process with continuous feedback fromeach activity. The first step is to interact with the stakeholders, gathering informationabout the required system. The information is used to learn more about the applica-tion domain, what services the system should provide, required performance, hardware

12

2.6. Design rationale

constraints et cetera. The information source include documentation, interaction withstakeholders through interviews, observations and use of scenarios and prototypes tohelp stakeholders understand what the system will be like. Stakeholders include end-users who will interact with the system and anyone else in the organization who willbe affected by it[36]. Next step is dividing the requirements into user and system re-quirements and handling conflicting requirements by gathering the stakeholders, pri-oritizing requirements and resolving them by compromise. The last step is to specifythe requirements and to document them into formal or informal documents. Under-standing requirements from the system can be difficult because the stakeholders oftendo not know what they want from a system or find it hard to articulate or express it intheir own terms. In other words, different stakeholders have different views on the im-portance and priority of requirements B.Suranto [37]. Figure 2.2 shows the requirementelicitation and analysis process adapted from B.Suranto [37].

Figure 2.2: Adapted requirement elicitation and analysis process

3. Requirement specification: In the process of requirements specification the user andsystem requirements should be written in a requirements document. In this step thedivided requirements should be clear, complete, consistent and conflict free. Howeverin practice this is difficult to achieve due to stakeholders interpretation that often leadto inconsistencies in the requirements. The user requirements should be describes asfunctional and non-functional requirements. The requirements are supposed to be un-derstandable for users without technical knowledge and not contain details of systemarchitecture or design, written in natural language. The system requirements are moredetailed and explain how user requirements should be provided by the system[37].

4. Requirement validation: Requirement validation is the last step in the RE process. Theaim of validation process is to check if the requirements actually define the system thatthe customers want. Validation is an important part and used to find problems withthe requirements that can lead to rework and costs when these problems are discoveredduring development of after the system is set in service. The validation checks used inthe process are shown in Table 2.3[37].

2.6 Design rationale

Nowadays, software engineers create more complex technologies and process models, work-ing in distributed teams and in a faster paste. However, the technologies and the processmodels mislead the fact that software engineering is a human based activity and that theoutcome or the success of the project depends mainly on made decisions during the engi-neering[26]. Software development is characterized by its non material nature, reducing un-certainty with mutual learning and consensus building. This can be balanced by a conclusivedecision-making process, supporting all stakeholders in their decisions and convincing each

13

2.6. Design rationale

Validation check DefinitionValidity checks Perform analysis to identify additional or different functions that are

required other then user need.Consistency checks Requirements in the document should not conflict or contradict.Completeness checks The requirements document should include all functions and con-

straints intended by the system user.Realism checks Knowledge of existing technology should be used to ensure that the re-

quirements can actually be implemented. These checks should also takeaccount schedule for the system development.

Verifiability The system requirements should always be documented so that the areverifiable and to reduce potential dispute between customer and con-tractor. This means that you should be able to write a set of tests thatcan demonstrate that the delivered system meets each specified require-ment.

Table 2.3: Requirement validation

other of the value of these decisions by sharing the work of implementing these decisions[26]. Rationale management is a method for supporting explicit decision-making or the jus-tifications behind the decisions is design rationale. Rationale increases the understanding ofa system and making it easier to adapt or maintain. In software development, using designrationale is being able to explain past decisions and facilitate the training of new membersin a development team. However, according to McCall et al. the rationale is often capturedpartially and informally in design documents and communication artifacts, making it diffi-cult to access and maintain. Adapting rationale management in software engineering can betime consuming and no convenient way to express rationale [26]. Futher, McCall exploreddifferent approaches in rationale management to develop an understanding of what it meansto capture the use of software engineering rationale. two approaches of design rationale :process-based and structural approach. The process-based approach represent rationale as adecision-making step, capturing the argumentation behind designs as it occurs. Issue BasedInformation System or IBIS is such an approach. Questions, Options and Criteria(QOC) is astructural approach representing rationale after decisions are made [26].

Issue Based Information System

Issue based information system(IBIS) was first described by Horst Rittel in 1970 for use onlarge and complex design problems, a techniques known as design rationale. Rittel usedthe term “wicked problems” to describe the conversation among stakeholders in which theybring their respective expertise and viewpoints and resolution of a design issue. A designissue could be any problem, concern or question that may require discussion in order for thedesign process to proceed. Originally the method was applied in diverse situations such asarchitectural design and city planning. The IBIS model focuses on the definition of the keyissue in the design problem [17].

Rittel et al. stated in order to describe a wicked-problem in sufficient detail, one has todevelop an exhaustive inventory of all conceivable solutions ahead of time. The reason isthat every question asking for additional information depends upon the understanding ofthe problem and it resolution. In order to anticipate all questions and information requiredfor resolution ahead of time, knowledge of all conceivable solutions is required [34]. Further,the authors stated also that wicked problems have no stopping rule, due to there is no cri-teria when the solution had been found with planning problems. There are no true or falseanswers. Normally the stakeholders are judging the solutions according to their interest.There is no stopping rule, nor is there in the IBIS method a particular way of registering

14

2.7. Prototyping

that an Issue has been resolved by agreement upon some position. Rather, the goal of thediscussion is for each of the stakeholders to try to understand the specific elements of eachother’s’ proposals, and perhaps to persuade others of one’s viewpoint. The method makes itharder for involved parties to make nonconstructive rhetorical moves, such as “argument byrepetition”, seeking the central issue, asking questions as much as giving answers and beingspecific about the supporting evidence of one’s viewpoint[17].

Conklin and Begeman developed the original version of IBIS and presented a graphicalversion of the IBIS method, gIBIS. They described a hypertext-based prototype of the IBISsystem and its use in capturing design rationale. The gIBIS was intended to be used incollaborative settings, to help groups achieve a shared understanding of central issues bymapping out dialogues in real time [17]. Figure 2.3 shows a adapted state transition diagramspecifying all of the legal moves within the IBIS method from [17].

Figure 2.3: A state transition diagram specifying all of the legal moves within the IBIS method

As shown in figure 2.3 the diagram is made up of three classes. The issue class repre-sent the issues or questions needed to be addressed. The position class are the ideas orresponses to the questions or issues. This can be a set of ideas or perspectives on the issue.The argument class can be pros or cons arguments, supporting or arguing against an issue.Here the complete set of arguments that respond to an idea represents the multiplicity ofviewpoints on it. Each issue can have many positions, statements which resolve the issue.The positions of each issue can have multiple arguments supporting or arguing against thatposition to it. There are nine types of links in the IBIS. For example, a Position Responds-toan Issue, and this is the only place the Responds-to link can be used. Arguments must belinked to their Positions with either Supports or Objects-to links. Issues may Generalize orSpecialize other Issues and may also Question or Be-suggested- by other Issues, Positions,and Arguments. As an escape mechanism, Other nodes may connect to any other node typewith Other links.

The next natural step from requirement engineering and concept is prototyping. Proto-typing is used to enhance the requirements quality of a system, an initial version of a softwaresystem used to demonstrate concepts, design options and possible problems and solutions.

2.7 Prototyping

According to B.Suranto [37] software prototyping plays an essential role in user-interfacedesign process. By using prototypes and involving stakeholders, enables a more sensibleand verifiable end product. The technique can be used to elicitate and validate system re-quirements, explore alternative solutions and functionalities and test how the system would

15

2.8. Pugh matrix

work with other systems. User interface mock-ups or wireframing are used to elicit the re-quirements from stakeholders. By using the software prototypes the engineers are able to getfeedback from the stakeholders and check the usability level of the system [37]. Furthermorea general process for prototype development is presented as shown in Figure 2.4 adaptedfrom [37]. The first step of the prototype process model is establishing the objectives of theprototype e.g. functionality and fidelity of the prototype. After establishing the objectives aprototype plan is needed in order to deliver on schedule. The most common developmentprocess used in software engineering is the agile process with one week iterations. The agileprocess is used to define which functionalities are needed to develop an executable prototype.The final step of the process is prototype evaluation done together with the stakeholders.There are two different types of prototypes, low-fidelity and high-fidelity prototypes [37].

Figure 2.4: Prototype process model

Fidelity is defined as "the level of detail that content is rendered in the interface"[37] andrenders from lowest to the highest fidelity. Low fidelity prototypes are usually sketchedto present the design concept with minimal attributes with resources such as paper, pencil,post-it notes and whiteboard. Low fidelity prototypes are used to quickly demonstrate therequirements to stakeholders, test broad concepts and present the concept without goinginto details of the requirements [37]. High-fidelity prototypes are highly functional andinteractive prototypes, close to the final product with with most of the necessary designand requirements developed and integrated. High-fidelity prototypes are used in the finalstage of usability to give the stakeholders an opportunity to verify whether the prototyperepresent valid requirements. In order to get the valid requirements from the stakeholders acombination prototyping technique is required[37].

2.8 Pugh matrix

Working teams often prefer to decide important decisions through consensus and Pugh ma-trix is such a decision making tool that can help to facilitate consensus. A Pugh matrix is adecision-making tool used to compare and evaluate alternative design concepts to a referenceto determine the best possible design concept. The columns in Pugh matrix are characterisedby the different concepts. The rows in the left-most column are characterised by evaluationcriteria. Criteria is used to assess the design-concept and allows users to combine criteria withhighest score from different design concepts and to create a new hybrid solution that com-bines the best attributes. It is a qualitative design concept tool that uses weighted numericalvalues of positive, negative and same to asses ideas. The first concept in the matrix is a refer-ence concept used to compare and evaluate against other design concepts. The concept withthe highest sum is the best alternative. The Pugh matrix also indicates a potential improve-ment by creating a hybrid concept from the highest performing attributes[8]. The method issimple and allows the designer to focus on the best concepts, however the variables in designevaluation, the criteria, are often imprecise and contain much uncertainty[16].

16

2.9. Agile software development

2.9 Agile software development

Software development is an empirical or non-linear process that needs short feedback-loopsin order to achieve a desirable results. Researchers mean that agile software developmentis about feedback and change. Unlike traditional software development approaches that arebased on cost- and risk control, agile method is more based on team-work and customervalue [19]. The process in the agile method support improve product quality by improvingproject factors [15]. Agile development uses a technique called adaptive planning, a roughrequirements and design is used and elaborated in detail as the level of detail is about to beimplemented. During each iteration the requirements and implementation is reviewed beforecollecting more detailed information from the customer. By reviewing periodically the risksare controlled to a minimum. These periodically reviews require the customer to be closelyinvolved in the process[15].

Scrum

Scrum is one of the most well known agile methods based on flexibility, adaptability andproductivity. It is usually up to the developers to choose the specific software developmenttechnique and practices for the implementation process.[19] Scrum is effective for small teamsand consists of a number of phases where the first phase is called the planning phase. Dur-ing this phase the team has to identify an architecture and define the project’s goals as wellas controlling the developers roles and ensure a close communication with the developers.When the planning phase is done, a series of short development phases called sprints areused to deliver the product incrementally. One sprint is usually held between one to fourweeks and the team identifies tasks, prioritize these tasks and track them in a list called back-log. The backlog is updated before each sprint by adding more tasks, re-prioritizing and eachteam or team member signs up for a number of tasks in order to execute the sprint. Thegoal with the sprint is to complete the tasks in the backlog by the sprint’s delivery date. Thedelivery date cannot be changed but the team can reduce delivered functionality during thesprint. A Scrum meeting is also held daily where the team can reflect over their own effortand work. The Scrum master leads the daily meetings by identifying the initial backlog andensuring that everyone in the team makes progress. The idea behind the sprint and thesedaily meetings is to deliver valuable functionality. [38]

2.10 Usability evaluation methods

The following section present the definition and use of some methods used to evaluate theoverall usability of system.

Heuristic evaluation

Heuristic evaluation is a method used to evaluate the software system by usability expertswhere they judge whether each dialogue element of system follows established usabilityprinciples, called heuristics [40]. Nielsen and Molich [30] describes a list of nine usabilityheuristics, these are: simple and natural dialogue, speak the user’s language, minimize theuser’s memory load, be consistent, provide feedback, provide clearly marked exits, provideshortcuts, good error messages and prevent errors. Heuristic evaluation lets usability expertsto review the user interface in order to identify potential user experience problems for theusers, by having these heuristics as guidelines. According to M. Matera et al. [24] heuristicevaluation is valuable when time and resources are limited. Also, the evaluation is doneby usability experts which can give high quality results in short time without the need ofinvolving representative users.

17

2.11. Theory synthesis

D. Alonso-Ríos et al. [3] describe a systematic and generalized approach to heuristic eval-uation. This approach is based on using comprehensive taxonomies such as the usabilitytaxonomy described in 2.2 by Alonso-Ríos et al. [4] as a source for the heuristics. The authorsmean that usability is relative to the context of use, and the usability taxonomy they referto is completed with a context-of-use taxonomy. The main attributes of the context-of- usetaxonomy are: user, task and environment. This gives a basis for the method of heuristicevaluation that is composed into four steps:

1. Characterization of the system: the characterization of the features the system haveto perform by identifying all the elements, user tasks and system tasks needed. Thecharacterization can start by using the description of the features offered by the system.

2. Characterization of the context of use: this consist of analyzing the properties of theuser, the functionalities of the system, and the setting. This is done by using the at-tributes of the context-of-use taxonomy described above. If the characteristics of thecontext-of-use are taken into account, the result of the heuristic evaluation can be inter-preted more accurately.

3. Instantiation of the taxonomies: this mean that we have to take only relevant usabilityattributes into account, in other words we have to remove all usability attributes andsub-attributes that are not relevant to the application being developed.

4. Heuristic evaluation: this step consists in assessing the usability of the software system.The parts that have to be considered are the UI elements, tasks and the relevant usabilityattributes from the taxonomy described earlier. The aim s to see how each individualelement in the context of the system and the context of use satisfy the relevant usabilityattributes and sub-attributes. The outcome of the heuristic evaluation is a list of strongand weak usability points and how they can be improved.

These steps are presented in order but there can be some flexibility depending on the appli-cation being evaluated and how the developers prefer to evaluate it. One can for exampleperform characterization of the context of use before the characterization of the system andso on.

2.11 Theory synthesis

Previous studies have emphasized the challenges of usability when developing mobile appli-cations. Challenges to design a product that is useful and valuable to the user and at the sametime effortless and supporting the interaction. In this chapter related research and relevanttheories of use for the intended study have been presented, both in terms of techniques andmethods. Theories concerning fundamental principles of usability and human centered de-sign propose requirements and recommendations for the design process such as conceptualdesign, ISO 9241-210 and requirement engineering. By combining these methods, techniquesand applying usability, including the stakeholders in every phase of the developing designprocess, the user needs are considered and in theory the usability increased. Persona, IBISand Pugh matrix are tools presented in these theories to facilitate the decision-making andjustify the decisions during the design process. Rationalising a final design results in a con-cept and later transitioning from concept to a proof of concept, a prototype. Further readingon how these theories have been adapted and applied are clarified in the next chapter.

18

3 Method

This chapter aims to explain the method structure and the methods used to carry out thework. In order to achieve desirable results with customer in mind, agile software methodcalled Scrum was used. The three main parts of the method chapter: pre-study, implemen-tation and evaluation has been divided in the different phases of Scrum. The first phase ofScrum is the planning phase or the initial phase as presented in this method chapter. The re-maining phases are called sprints. Design, implementation and evaluation has been dividedinto different sprints were each sprint has been executed during a four week period.

3.1 Initial phase

An initial feasibility study was conducted with the stakeholders with the purpose to create ashared vision of the project by discussing the aim and direction of the project. The purposewas to maintain a well informed background and a common ground for the project by in-volving the stakeholders early in the design process[37].

ISO 9241-11 [1] provided four main procedures for how to manage a design process. Theprinciples included understanding the specific context of use, specifying the user require-ments, produce design solutions to meet these requirements and evaluate the design againstthese requirements. After the feasibility study a systematic literature study was conductedto form the theoretical foundation of the project. The systematic literature study meansthat the author systematically searches data based on empirical studies, critically reviewsand evaluates the content in order to encapsulate current research within the domain[20].In order to get the general scope of the research search strategy was used to form relevantsearch terms and to opt databases. To distinguish the most relevant research during the datacollection inclusion and exclusion selection criteria according to B. Eriksson et al. [20] wasused. Based on the inclusion selection criteria further issues were identified, scope delimitedand composed as a starting point for the literature search.

ISO 9241-210 standard provided a guidance for designing user-centric interactive systems byidentifying four activities. The first activity aimed to collect data in order to understand andspecify the context of use. Five respondents were recruited to match our end-user, miner inthe underground mine, independent of country origin. The stakeholders included now both

19

3.2. Sprint 1

IT consultants from Combitech with good insight in the underground mining project but alsoreal end users and the purposed system. Requirement elicitation in collaboration with stake-holders was performed to gather information about the required system. The requirementelicitation included brainstorming, semi-structured interviews, contact with other stakehold-ers and documents in form of business manuals and previous studies within the domain.During the requirement elicitation, brainstorming was used to get as many ideas from thestakeholders. The method was used to collect and produce new ideas, to derive them forfurther analysis and to identify possible solutions to a specific question, the research question.

Next activity according to the ISO 9241-210 standard was to specify the user requirement.The desired output of this activity was to identify the use specification, user needs and re-quirements. The semi-structured interviews were one to one with a session duration from 30to 60 minutes. The interviews were held with chosen managers and field operators based ontheir job position in the underground mine. The interview questions found under appendixA were developed with usability in mind and used to gather information about the domain,context and end users. The interview questions were based on the information from thesystematic literature study and the theories. General data about the users were gatheredfrom the literature study but according to the theories we needed more information fromthe users. To understand the environment that the users would use the application in butalso their expectations and possible requirements, we brainstormed different questions thatwould give us answers to these questions. The users are presented in table 3.1 and vary inroles and experience. Two of the respondents were interviewed in person and rest throughSkype meeting. The interviews were recorded and the outcomes was discussed and sum-marized after each interview. The questions were structured in five parts. The first part wasseeking background and demographic information about the user, the second part processedrole and responsibilities of the user, the third communication and its issues in the domainand between users, resources and needs and requests.

The information was used to identify user requirements about the services the systemshould provide, performance and hardware. From the interviews, user requirements wereidentified as functional and non-functional requirements[36]. Due to delimitations onlythe functional requirements were taken in consideration. From the requirements and theinterviews, the pattern resulted into personas, situations and scenarios, found in appendix C.Persona according L.Nielsen [31] should be used to represent the end user and is a result ofthe collected data. The persona perspective used in this report was the role-based approachdue to that the basis for the data collection to form the persona was qualitative and quanti-tative data. The persona was produced according to L. Nielsen [31] ten steps presented inthe theory chapter. L.Nielsen [31] presented the situation as one of the ten steps in order toexplain a typical situation for when a user would use the product. In order to explain howthe user will use the product a scenario was presented according to J. Nielsen [29]. Thesethree descriptions were used during the design evaluation to get feedback from the usersbefore creating the prototype to understand the goals of the end user in the specific context.

3.2 Sprint 1

The first sprint was the first step in the conceptual design process. To ensure that the endproduct would work as designed, a prototype was needed. According to the theories pre-sented in section 3.1 an initial prototype could be created quickly and with only few resources.Our goal was to create a low fidelity prototype to help and develop a clear understanding ofwhat the final product would be. Before defining the low fidelity prototype a research on theprinciples of user experience design was conducted in order to have the guidelines in mind

20

3.2. Sprint 1

when developing the different concepts. The baseline for the design principles was based onthe websites Material design [22] and Androids documentation for developers[5].

Low Fidelity Prototype

To enhance the requirements quality of the system a low fidelity prototype or wireframe wasdefined as an initial version of the system. Low fidelity prototype or wireframe is a visualrepresentation of the basic elements of a proposed design. Creating the wireframe ensuredthat both the designer and stakeholder could agree on a basic layout and functionality. Thewireframe maps and presented how the end user would interact using the end product, visu-alizing and communicating user needs and requirements facilitate users desired throughputof the system.

Design rationale represented the argument for defining a design by explaining and jus-tifying design decisions [26]. Method used for documenting design rationale was IBIS,Issue-Based information System. With requirements, persona, scenario and human-centreddesign principles in mind, IBIS was used to capture design decisions of the design process,issues, positions, arguments and relationship between positions and issues. The hierarchicalstructure started with on root issue and processed until a possible solution to a issue wasreached. According to H.Rittel and M.Webber [34] wicked problems have no stopping ruledue to that there is no criteria when the solution has been found. This issue was handled byfocusing on the questions relating to usability and user requirements.

The possible solutions were used to define different concepts using Balsamiq Wireframes.Balsamiq Wireframes is a small graphical tool used to sketch out user interfaces for websitesand mobile applications. The tool focuses on content and structure avoiding colour anddetail.

After designing different concepts, a decision-making model called Pugh matrix was usedto choose between the different concepts using a base line, the current mobile application.Choosing a final concept to prototype was an important decision that was reached throughconsensus and the Pugh matrix was such a decision making tool [8]. The first step using thePugh method was to develop a list of criteria before evaluating the different concepts. The listof criteria was specified from data collection and sorted according consensus understandingof the collected data and theory. Each criterion was given a weight value to indicate itsimportance. The weight was set from a starting value of zero, the lowest importance andincreased by one, giving the most important criteria the higher weight value. The methodwas used to decide one concept on the basis of multiple criteria, various concepts to produceone concept. The concept with the highest score was the best alternative.

Evaluation of the Low Fidelity Prototype

Low fidelity prototype was used to get a quick feedback on the designed concepts, ideasand flows from our stakeholders. The idea was to test them with our users and stakehold-ers to get feedback on the rough design concept, improve and continue iteration [37]. Thewireframe required thorough planning due to that the prototype was limited in terms oftesting interactions, transitions and other processes. According to L.Nielsen’s [37] researchrecommendations, the prototypes were tested on five users presented in the table 3.1 andvary in roles and experience. The five respondents were recruited to match our end-user,miner in the underground mine, independent of country origin.

Before conducting the usability testing, use test cases and questions for follow up weredefined. The questions were used as a short interview to collect impressions and experiences

21

3.3. Sprint 2

when using the prototype. During the usability testing the objectives and plan for the testwere explained to the users, providing the user a task to perform. A facilitator was assignedto the usability testing, interacting with the users, explaining the testing and making surethat the process ran smoothly. The other acted as observers, observing the behaviour of theusers and their actions, interaction with the prototype and not interacting with the users.

User Title Years of experienceUser 1 Mining manager 20User 2 Senior Loader Operator 12User 3 Truck operator 5User 4 Manager Underground automation 16User 5 Operator (more than one area) 7

Table 3.1: Recruited respondents for the project

3.3 Sprint 2

The main focus of the second sprint was to design a Hi-Fi design based on the conceptualdesign in the earlier sprint and the outcome of the evaluation of the Low-Fi prototype. Thesprint included a usability evaluation with stakeholders and users.

High Fidelity Prototype

Sprint 2 started with a sprint planning meeting to plan the activities and the user stories to beimplemented at that phase. A meeting with the supervisor was held to discuss what detailswere necessary but also possible to add to the design. There was a discussion regardingthe most suitable framework of development to use in order to make the application moreusable for the company and end user. There was two different options of frameworks, JavaAPI framework including XML using Android Studio and .Net framework using MicrosoftVisual Studio. After making a more detailed study of the pros and cons of each frameworkwe decided to use Android studio with Java API and XML to implement the mobile appli-cation prototype. The main reason was the good knowledge in chosen framework and toolwhich saved time and resources. The framework was also more suited and filled the criteriaof the company.

At that phase we also decided the size and measurements of the mobile device to be used.The decision was made after a discussion with the stakeholders at the company that weredeveloping a similar mobile application customized for another market. We decided to usesame measurements in order to keep the same standard.

The planning and creation of the Hi-Fi prototype was based on the human-centered de-sign activities by ISO 9242-210 presented in section 2.4. The wireframes created in Sprint 1was considered as a base for implementing the detailed design. The Hi-Fi prototype wasimplemented in Android studio in XML code without adding any functionalities on thedesign in java code.

The color schemes, typography and icons used in the application followed the colors ofother applications developed by Combitech in order to help the user to be familiar with theapplication.

22

3.4. Sprint 3

Evaluation of the High Fidelity Prototype

The evaluation of the Hi-Fi prototype was held with different stakeholders in order to findpossible improvements for the design and increase the usability. The test sessions were heldindividuality with each user and one of the test session were held through Skype. The re-quirements, scenario and persona were presented to one of the users, since the user was newto the project. Four of the users participated in the test sessions were IT-consultants involvedin projects for the underground mine. One of the users worked as an operator in an under-ground mine and had good insight in the domain. Table 3.2 shows an overview over theparticipants. Each user started with an overview of each page of the design and got sometime to reflect on the information presented, details, colors and font size. Three predefinedquestions was presented to each user as a starting point of the discussion. The questions arepresented below:

1. What do you like about this page and why?

2. What do you not like about this page and why?

3. How would you improve this page?

User Title Years of experienceUser 1 IT-consultant 15User 2 IT-consultant 10User 3 IT-consultant 4User 4 IT-consultant 5User 5 Operator 7

Table 3.2: Recruited respondents for evaluation of the High Fidelity Prototype

The discussion of each test session was documented and summarized. The design was thenimproved based on the outcome of the test sessions. The new design was then discussedwith the supervisor at Combitech in order to find more improvement points and increase theusability of the design before the actual implementation of the prototype.

3.4 Sprint 3

The main focus of sprint 3 was to add functionality to the implemented Hi-Fi design. A dis-cussion with the supervisor was held to discuss the complexity of the functionalities neededto be added. We decided to add all possible functionalities needed in order to perform a real-istic evaluation of the design with possible users and stakeholders. The functionalities wereimplemented in programming language Java using Android IDE. The outcome of this sprintwas an android mobile application prototype used to analyse the usability of the product inorder to further discuss the research questions. Different user stories with tasks were plannedin the sprint backlog. Development and test tasks was added and finished before the actualstory was marked as done.

Evaluation of the functionality

The usability evaluation of the final product was held with five different stakeholders andusability experts at Combitech. According to Nielsen at least five users for usability evalua-tion is considered enough and acceptable. Although the participants were not representativeusers, they all had worked with project related to underground mines and had knowledge ofthe user experience in that work environment.

23

3.4. Sprint 3

For the user testing the task completion rate was based on System Usability Scale (SUS)[13] evaluation in order to measure the overall usability of the final product. After theSUS questionnaire the users rated the application based on the nine heuristics proposed byNielsen and Molich [30] in order to get more reliable results. The nine heuristics appliedwas the updated version of the ten heuristics proposed by Nielsen [27] four years after theprevious one.

Two of the users were involved in the previous evaluation session in sprint 2 and threeof them were new to the application. The idea was to measure how a new user would reactto the mobile application. Three of the users were developers that had been involved insystem development and application for underground mine, but in different environmentthan the one considered in this project. One of the users was a user experience expert withlong experience in underground mine environment and the last user was a project leader inthe company.

Each layout of the mobile application had several tasks to complete and the test sessionincluding SUS questionnaire and rating the system based on the usability heuristics tookabout 20 min for each user. The tasks are shown in table 3.3. The test results were measuredusing SUS questionnaire that included 10 items to measure the overall usability of the system.The user was asked to rate the items by a given number from 1 to 5 where 1 indicated totallydisagree and 5 indicated totally agree. The SUS items are shown below.

1. I think that I would like to use this system frequently.

2. I found the system unnecessarily complex.

3. I thought the system was easy to use.

4. I think that I would need the support of a technical person to be able to use this system.

5. I found the various functions in this system were well integrated.

6. I thought there was too much inconsistency in this system.

7. I would imagine that most people would learn to use this system very quickly.

8. I found the system very cumbersome to use.

9. I felt very confident using the system.

10. I needed to learn a lot of things before I could get going with this system.

After the SUS questionnaire the users were asked to rate the application from 0 to 2 basedon ten usability heuristics for interaction design by Nielsen [27]. Grade 0 being the lowestone, meaning that the heuristic was not fulfilled and 2 being the highest and meaning thatthe heuristic was totally fulfilled. Grade 1 meant that the heuristic was partially fulfilled. Theheuristics with explanation for each are listed in table 3.4 below adapted from [27].

24

3.4. Sprint 3

TasksLogin to the application with wrong credentials. User name: safe, password:admin.Login with correct credentials. User name: admin, password: safe.Open the tasks for the current shift.Navigate to task 1 and show more information about the task.Create a request with the “request supply”Check if a request has been createdStart a taskComplete the check listFulfill the expected account and end the taskGo back the main layoutNavigate to reported errors.Filter the reported errors by using level 2 and scooper.Show the description of the reported error.Create a new error report but don’t fill all spinnersSend the new error report after filling all spinners.

Table 3.3: Tasks used in Sprint 3 for usability evaluation of the implemented mobile applica-tion prototype

25

3.4. Sprint 3

Heuristic ExplanationVisibility of system status. The system should always keep users informed

about what is going on, through appropriate feed-back within reasonable time.

Match between system and the real world. The system should speak the users’ language, werethe concepts and phrases are familiar to the enduser. The information should appear in a logical or-der.

User control and freedom. The user should be able to exit the current state orfunction without the need to go through many un-necessary extended steps. It is important to supportundo and redo.

Consistency and standards The user should not think and wonder if differentwords and functions mean the same thing.

Error prevention The system should be designed in a way that pre-vent an error from occurring.

Recognition rather than recall The user should not have to remember informationwhile navigating from one state to another. The in-structions should be visible or easily found.

Flexibility and efficiency of use The system should be flexible and efficient to useboth for experienced and non-experienced users.

Aesthetic and minimalist design The design should not include irrelevant informa-tion or rarely needed. The information in the systemshould be kept simple and minimal.

Help users recognize, diagnose, and recover fromerrors

The error messages should appear in a plain lan-guage (not error codes) and possibly suggest a so-lution.

Help and documentation The system should include user documentation andhelp that are easy to search. The documentation andhelp list should in the other hand not be too large orcomplex.

Table 3.4: Usability Heuristics used in Sprint 3 for heuristic evaluation of the implementedmobile application prototype

26

4 Results

The results chapter presents the core findings of the study based upon the methodology ap-plied in the previous chapter. The chapter presents a prototype and the results of the designand decisions of initial functionality, requirements, concepts and evaluation of these.

4.1 Initial phase

The feasibility study with the stakeholders resulted in functionality and definition as pre-sented in the table 4.1. The stakeholders were the Combitech representatives and a supervi-sor from the company. Both the writers and the stakeholders aim of the project was presentedand discussed and a common direction of the project was agreed upon. The aim of the projectis presented in the introduction chapter.

Functionality DefinitionContext adapted design Design for interaction with gloves and the environ-

ment, underground mineRun on an Android tablet Design according to android standardIntegrate against SAFE platform Retrieving and sending information from/to SAFE

platformView work order View the work order for the shift

Table 4.1: Initial requirement from the stakeholders

Requirement elicitation

The results from the interview were analysed and a common decision to focus only on onerole, operator or the mine worker was decided. This decision was made due to that themajority of the users or respondents had worked as a type of operator and was working asmanagers with several years of experience, beginning as an operator and evolving in theircarrier. The results of the requirement process is presented in a separate table in appendixB: Requirements initial phase. Here the user requirements are listed in functional and non-functional requirements in a non ordered table. The non ordered requirements cover areas

27

4.1. Initial phase

such as process control, planning and task management, service and inventory control suchas reporting, information handling and communication. The result pattern of the resultsshown in appendixes A and B are presented in appendix C. Appendix C presents two per-sonas, situation these personas operate in and scenario in which the system should fulfill forthe end-user in these situations. The two personas are results of the data collection gatheredfrom the interviews and meetings with the users.

Persona 1: Sofia Eriksson

The first persona is called Sofia Eriksson and is a representation of experienced miner used towork in a certain way during a longer time. She represents experience and is able to share amore specific details regarding typical situations, challenges and way of working. The goalsof an experienced miner is presented in Appendix C, C1 in goals. The goal of the personait to have the working orders in digital form, not on paper which can be lost during theshift. Other goals are to have and overview of the work environment,available resourcesand a communication channel to keep the social contact with co-workers. The goal of thepersona is also to reflect a miner with a well established working routines and is able toidentify possibilities that digitization could facilitate in the working routines. The personais a frequent user of smartphones, social media and has been working for a long time inthe domain. The persona is pro digital communication and believes mobile devices wouldfacilitate her everyday tasks. Persona Sofia’s situation is presented in Appendix C, C2. Thesituation is taken place both above and below ground and emphasise the challenges with timeefficiency, rough environment and limited resources to and from the destination. The shiftbegins with the persona receiving the work orders for the shift and goes through a checklist tocheck the status and condition of the equipment that will be used during the shift. The depthmine to the work destination plays a important role for planning of resources and is essentialif an unexpected situation takes place in a dark and rough environment several hundredmeters underground. The situation emphasises issues before and during a shift of a minerworking in this type of environment. Before a shift starts there are already a couple of thingsto keep track of, such as work order on paper and spare parts. On the long journey aheadmultiple issues can arise, such as forgotten spare parts, traffic, flooding, mine collapse andmaintenance. All of these issues are time consuming and a scenario is presented in AppendixC, C3 how a mobile application and device could facilitate these scenarios and help withthe synchronization. The application should provide all of the necessary information anddocuments in digital form and facilitate the necessary check of environment and equipmentthat are done continuously. The application should also support the error report during acheck and be created with only a couple of clicks. Feedback to the user is essential regardingstatus work tasks, reported errors, equipment, warnings et cetera.

Persona 2: Kalle Andersson

The second persona is called Kalle Andersson found in Appendix C, C4 and is a represen-tation of the less experienced miner. Kalle belongs to the younger group of miners and hasused technology in different forms. The goal for the persona is to have the whole processas digital as possible, having the whole day planned and digital on the mobile device. Thepersona is also social and plans his day so that he can integrate with his colleagues as muchas possible, communication with colleagues is important. Kalle likes to work efficiently andbeing informed about the task and having data relating to it is very important. The personahas a interest in having access to continuous data such as localization of vehicle, check listet cetera are essential to have access to. Kalles situation is presented in Appendix C, C5.The shit starts as for most underground workers above ground. Like for persona 1, Sofiathere are challenges in the environment and for Kalles situation the work environment andthe equipment are not prepared and the status of these are and unknown for him before the

28

4.2. Sprint 1

shift start. In these environments errors are prone to happen affects the time and planningmanagement. The scenario of how the application can be used to facilitate this situation ispresented in Appendix C, C6. The application is prepared with all of the essential informa-tion, needed to know data for Kalles specific role and work tasks. The equipment and statusof it is presented. Former checklist of both the environment and equipment are available andhe can easily keep track and be notified when work tasks, reported error, resource status arechanged.

4.2 Sprint 1

In this section the results of the conceptual design process and the two concepts composed arepresented. The persona, situation and scenario can be found in appendix C and the wireframefor the two concepts can be found in appendix D .

Conceptual design

Figure 4.1 shows the results, a diagram using the IBIS method. The figure 4.1 illustrates oneof the many questions raised during the conceptual design. The figure shows questions inyellow, for example "When can we chose a hamburger menu?". The possible answers suchas "Less navigation" are presented in blue. The pro argument "Recommendation to haveone function to handle navigation" and con argument "Can easily be lost in the design" arepresented in green and red. Each answer can be explored by raising a new question relating toit continuing the process. Other questions that was solved by using IBIS, the argumentationbased approach are presented in appendix E Conceptual design questions. The answers tothe questions in appendix E was taken in consideration when designing the concepts.

Figure 4.1: Issue-based information system diagram

29

4.2. Sprint 1

SAFE

Situational Awareness for Enhanced Security or SAFE is a platform developed by SAAB formission-critical operations[35]. The platform is used in commands and control rooms atplaces like airports, traffic control and now in underground mines to improve workflowsand efficient processes. The platform had all the functionality for a control room and de-signed to give more information for faster decision making. The system could be customizedto user specifications to match the users requirements such as communication, mapping andused for mobile devices ensuring access. The SAFE platform supported following features:

• Workflow management

• infrastructure

• Operator client

• Issue management

• Scalability

• Role based layout

• System reports

• Administration

• Logging

• Action plans

• Rule engine

• User interface

• Maps, 2D and 3D

• Resource management

• Sensors

• Dispatch

• Planning

• Communication

• Mobile

System requirement elicitation

Appendix D: Requirements sprint 1 presents the requirements in an ordered manner. The listbegins with the most important requirements and functionality decided in agreement withthe stakeholders. The most recurrent requirement during the interviews was the possibilityto view all tasks for the shift and all information related to perform them, such as taskdescription, start time, end time, location, vehicle et cetera. Location was another recurrentrequirement. In a dark work environment with different levels and sometimes no colleaguesaround and it was easy to get lost and keep track of each other. Maintenance issues wasanother requirement area with difficulties to report a problem in words or text. The ability totake a photo when reporting an error was needed. Tools to ease controlling equipment suchas checklist and accessing relevant document digitally instead in paper form were few of therequirements presented in Appendix D.

The last step in the requirement engineering process was to validate the requirements inappendix D. In requirement engineering user requirements are central but in order to fullfillthe user requirements one must evaluate the system on which the product will run on or tointegrate with. In this case the evaluation of safe platform was essential to identify opera-tional constraints and to confirm the requirements. The list of requirements was discussedwith the stakeholders regarding the possibilities and limitations of SAFE. The platform hadno positioning functionality which affected the requirement regarding localisation under-ground. This constraint excluded requirement 1.2-1.3 and 1.7 to some extent. The prototypewould not be used to view the current location nor the location of a work task on a map inthe mobile application. For requirement 1.7 "Convey and receive emergency information",there would not be functionality related to viewing this information on a map, but limitedto notifications. These requirements also affected the performance of the mobile applicationdue to the data consumption to keep the data accurate and updated for every user. Thevalidated requirements are presented in appendix E.

30

4.2. Sprint 1

Concept 1

Concept 1 as shown in figure 4.2 is a horizontal layout grid designed with accessibility andusability in mind. The layout was derived from Fitts’ law, stating the amount of time re-quired for a person to move to a target area is a function of the distance to the target dividedby the size of the target [21]. This means the longer the distance and the smaller the targetsize the longer it takes. The law highlights the importance of size and distance in UI designand influenced the design of interactive objects such as making interactive buttons large dueto smaller buttons are more difficult to click making the interaction more error prone. Like-wise, the distance to the target should be kept as short as possible. This user interaction andexperience law was applied by making interactive buttons large and keeping the distance tothe target functionality to few clicks from the overview layout. The task overview layout wasdesigned for the user to easily click on the task and its surrounding to view more details andstart a work task.

The design was a result from user requirement to facilitate the end users to handle asmall mobile device with one or both hands and using gloves. Main features were to haveinformation about current work order and easily report errors out in the field. The resultsfrom the data collection in the initial phase indicated that the users wanted the applicationto be ease of use and accessible. The concept related to an information architecture wherethe top level, the overview began after login. The overview had a familiar layout to whatthe end user was used to, the private phones and application like layout used to navigate todifferent programs and functionality. The menus or applications promoted the user to getmore specific, moving down the information hierarchy.

Concept 2

Figure 4.3 shows the second concept. Concept 2 as 1 used a horizontal layout grid, due to therequirements to have lager buttons and functional accessibility, horizontal layout maximizespace utilization. The concept divided the layout in two and has a left aligned navigation.The left side was used to navigate and the right was used to view more details related to thechosen functionality on the left side, having a fixed navigation pane compresses the detailedinformation on the right. The overview in concept 2 had a quick access button on the left halfof the layout.

Final concept

The final concept is a composite of concept one and two. The criteria and weights for thedifferent concepts are presented in the Pugh matrix table. The decision making for the finalconcept is presented in the Pugh matrix shown in table 4.2. The chosen criteria are based onthe different material design guidelines from Material Design [22]. Even though the conceptswere similar the matrix was used to decide the final set of layout into one final concept. Theweights for the different criteria had a value between 1-3, were 1 was the lowest and 3 was thehighest. A criteria received a weight depending on if the interviewed persons had mentionedthe criteria directly, indirectly or not at all, resulting in a value sequence of 3, 2 and 1. Thecriteria with no weight value are for layouts. The layouts have a non value weight due to thatboth concepts have the same layouts and the weight will not have a significant impact on thefinal score. The score presented in the table 4.2 ranks concept 1 as the final concept. The Lowfidelity concepts and prototype was designed in Balsamiq, a low fidelity wireframing tool.The tool is a fast wireframing tool focusing on structure and content avoiding discussionsabout details such as color etc.

31

4.3. Sprint 2

Figure 4.2: Concept 1

4.3 Sprint 2

In this section the results of the Hi-Fi design are presented. The Hi-Fi design was based onthe final conceptual design presented in sprint 1. The results include the outcome of the usertesting and evaluation of the design.

Sprint backlog

The result of the sprint planning were stories based on the feedback from sprint 1. The back-log was updated according to the meetings that was hold with the supervisor and the userexperience expert. The stories and tasks were refined based on the most important featuresthat should be implemented. The color theme and design details was an important part

32

4.3. Sprint 2

Figure 4.3: Concept 2

considering the amount of stories. The backlog also included new stories for testing andevaluation.

Implementation

The final conceptual design was used as a basis for the Hi-Fi design. The design theme, colorsand structure followed similar standards for other applications developed in the companybut also with the help of the design guidelines from Material Design [22]. The design includedeight layouts in total.

33

4.3. Sprint 2

Table 4.2: Pugh matrix

Criteria

Concept

Wei

ght

Base

line/

Con

cept

1

Con

cept

2

LayoutVisible elements 3 1 0Consistent 3 1 0Prioritized 2 1 1Scannable 2 1 0NavigationVisual hierarchy 2 1 1Predictable 3 1 0Consistent 1 1 0Touch and click targets 1 1 1Search 1 0 0- - - - - - - -Login - 1 0Overview - 1 0Task overview - 1 0Error reports - 1 0Request supplies - 1 0Task description - 1 0Checklist - 1 0Reported error - 0 1Score: - 24 6Ranking - 1 2

Login layout

The first layout is a login page where the user can login with a personal credentials. The ideawas to let the user have an overview of the tasks that needed to be done and get an overviewof the work progress. The user could at the end of the work shift sign out of the application.Figure 4.4 shows the login layout.

Main layout

The second layout is the main layout which includes clickable items and title under each.These items represent a shortcut to important features and functionalities, represented asapplications, in order to facilitate and minimize the number of clicks. In the conceptualdesign we had several items or categories but decided to keep only the most important three,based on the evaluation and feedback in Sprint 1. The main layout included items "Tasks","Reported errors" and "Request supply". Figure 4.5 shown in the main layout.

34

4.3. Sprint 2

Figure 4.4: Login layout

Figure 4.5: Main layout

Tasks layout

By clicking on "Tasks" on the main layout the user will be navigated to a new layout thatincludes all the assigned tasks for that shift. That layout is called "Tasks layout". The usercan also see an overview of the started and completed tasks. The tasks are listed in priorityorder, where the first one is most urgent. Some necessarily data for each task are shown togive the user a quick overview. A progress bar is shown for each task row. This is used tohelp the user to keep track of the current progress of each task. When the progress bar hascompleted, i.e. showing 100% the task will be shown under completed tasks.

Each task row has its own layout that includes more details. The user can navigate tothis task by clicking on any of the task rows available in "Tasks layout". This layout includesdetails about the scope of the assignment, the location, information from the supervisor andthe goal of the assignment. Each task has a goal that the user should meet before movingto the next task. This goal is a fixed number based on tasks for underground mine. It canfor instance be based on the number of scoops or the drilling depth in meter. For example itcan be the number of scoops or the drilling depth in meters. The user can add one numberto the counter until the goal is met. If the user adds a number to the counter by mistake or

35

4.3. Sprint 2

wants to regret the added number, a subtraction button is available. In this layout the usercan start the task by clicking "Start" button. When clicking on the "Start" button a pop-upwindow including a checklist will appear. The checklist is mandatory to fill in and submitbefore starting the task. Figure 4.6 and 4.7 show the Tasks layout respective Tasks descriptionlayout.

Figure 4.6: Tasks layout

Figure 4.7: Tasks description layout

36

4.3. Sprint 2

Reported errors layout

From the main layout the user can navigate to “Reported errors” layout. The user can see alist with all reported errors by other users and the user him-/herself. The user can use thesearch window to filter the list and also the spinners that include predefined items, inspiredby terms used in the underground mine. By clicking on the button “View” the user can viewmore details about each reported error. Figure shows 4.8 the reported errors layout. The“Error description” layout shows detailed information about the selected errors. That layoutcan also include a photo of the reporter incident and additional information written in plaintext. Figure 4.9 shows “Error description” layout.

Figure 4.8: Reported errors

Figure 4.9: Error description layout

By clicking “New error report” button in the “Reported errors” layout the user can sub-mit a new error report for any incident that occurs during the work shift. The user can use

37

4.3. Sprint 2

the spinners to fill in what type of error that occurred, the location and the problem. A texteditor can also be used to type additional information in case the spinners are not sufficientenough to describe the error. The user can also take a photo by clicking on the image icon,see Figure 4.10. The photo will appear immediately in the left corner of the layout. When theuser is satisfied with description and the photo, the error report can be submitted by clicking“Send” button.

Figure 4.10: New error report layout

Request supply layout

The layout ”Request Supply” is used to request extra supplies that are needed while workingon the tasks. Since it can be difficult and time consuming for the operator to get these supplieswhile being in the underground mine. The user can view all requested items and submit anew request. The user can choose among a number of predefined options: "Assignment","Location", "Item" and "Quantity" in form of spinners. Also, a text editor is available to writeadditional information. Figure 4.11 shows "Request supply" layout.

Figure 4.11: Request supply layout

38

4.3. Sprint 2

Usability evaluation

The usability evaluation of the Hi-Fi design was based on a questionnaire including threequestions. The five participants went through each layout to discuss the overall design andhow to make it more usable. The questions was used as a starting point of the discussion.This was helpful for the users to understand the aim of the evaluation and what to focus onduring the session.

Login layout

All users agreed that the login layout was a good start layout to the application. User 1,3 and 4 believed that the colors were good for the underground mine and the design wassimple. User 5, who is a technician operator in an underground mine commented that thetext editor and the login button could be a bit bigger. User 2 believed that the login layoutcould include only a user name login without password. He commented that it would bemore time consuming to type a password and not necessarily needed.

Main layout

All users commented on how good the design was for the main layout. User 2 and 3 believedthat the design looked professional but yet simple enough for the underground mine. User1 liked the idea with having clickable images for each layout. The user meant that theseclickable images can work as a short cut to navigate to any layout. User 5 liked the size ofthe images and the text. The user also believed that the margin between each image wassufficient. User 4 agreed that the design was good but the images could be even bigger, tomake it more usable.

Tasks layout and Task description

User 1 commented that this layout was actually the most important one, as it was one that theusers would spend most time on. The user liked the overall design but meant that it includedtoo much information that would not necessarily help the user. One suggestion was to reducethe amount of information for each row. User 2 liked the idea of showing the current assignedtasks but also the completed ones. User 2 liked the colors of the text and the size of each taskrow. The user wondered how many tasks the layout would include and meant that it shouldnot include more than 5. User 3 believed that the design would look better if the amount ofinformation for each tasks was reduced, because this information can only be viewed whenclicking on each tasks. Also, the user meant that there was no need to start the task at thisstage. User 4 and 5 believed that the button to start the task should be bigger in size. User4 also commented that there might be no need to view the completed tasks, as it takes somespace and might be confusing.

Reported errors and error report

All users agreed that it was a good idea to be able to report an error immediately via the ap-plication. User 1 liked that the it was possible to view other reported errors to avoid reportingthe same one. However, the user commented that it could be challenging to keep track onall reported errors. The user liked the filtering functionality but meant it should be biggerin size. User 2 liked the idea of having a standardization while reporting a new error. Ac-cording to that specific user it made it easier to report an error without the need of long andcomplex procedure. This user wanted to increase the size of the filtering function. User 3 hadsuggestion to improve the design. The user wanted to move the icon to take photos, increasetext size and move the button for "report a new error". User 5 who is an actual technicianoperator in an underground mine believed that the layout was a good idea but the designcould be improved to make it more usable. The user meant that it could be difficult for an

39

4.4. Sprint 3

operator to put time on browsing other reported errors, hence the search and filter option arevery good. User 4 liked the option to view old reported errors and that it was possible toview more details about each reported error. The user also believed that the design followsthe same standard throughout the application.

Request supply

User 1 believed that there was no need to see other requested supplies. The user meant thatit takes a lot of space and might not be necessarily needed. User 1, 2 and 4 liked the filteringoption when creating a new request. The users meant that it made it easier to request anitem with predefined items. The user suggested to add one more button "save", in case theuser don’t want to submit the request immediately. User 2 also liked that it is possible toadd additional information. User 5 liked the idea of requesting an item while working in theunderground mine. The user meant that it is a common issue and time consuming to go andpickup the needed item by the operator him or her self.

4.4 Sprint 3

The outcome of sprint 3 was the detailed design with added functionality in order to measurethe overall usability of the mobile application prototype. The final result looked similar tothe Hi-Fi design but with an amount of added functionalities in order to give the user a morerealistic look into the application prototype.

Implementation

For each page in the layout some necessary functionalities were added based on the storiesand tasks in the product backlog. On the first layout login functionality were added. If correctcredentials are used the user will be navigated to the main layout automatically. However, ifthe user entered incorrect credentials an error message would appear on the screen. In themain layout the user can click on any of the three options: “Tasks”, “Reported errors” and“Request supply”. By clicking on “Tasks” the user will be able to view all the assigned tasksthat are on progress as well as the finished tasks. The user can view more details for eachtask. To help the user keep track on the progress, the two counter buttons are clickable foradding and subtracting from the counter if needed.

On ”Tasks” layout a functionality for progress bar was added. This is used to keep track onthe progress of each task and give the user an overall view of the current status. The user canalso navigate back to previous layout by clicking on the white arrow on the bar. The secondoption is ”reported errors” were the user can view all errors reported by the user or evenother users. A filtering functionality with some predefined items was added to help the usereasily find a specific error. The user can by clicking on ”new error report” button submit anew error report. When reporting a new error there is a functionality similar to the one usedfor filtering for common locations and errors. The user can also add more information inplain text and upload a photo of the incident. The user can either take a new photo directlyvia the application or upload a photo from the photos in the tablet. When the new errorreport is submitted, it can be shown in the list of the reported errors.

The third option is to click on "Request supply". This layout follows the same designstandard and similar functionalities in "Reported errors" layout. The same code base wasused for viewing the requested supplies and items and also for submitting a new request.When a new request is submitted the request can be shown in the list.

40

4.4. Sprint 3

Evaluation and user testing

The final usability evaluation are shown in table 4.3 and 4.4. SUS evaluation was used tomeasure the overall usability of the application based on a questionnaire, see section 3.4.Each of the five users navigated through the application by the given tasks discussed in themethod 3.4. Three of the users managed to complete all the given tasks in a reasonable time.The two remaining users failed on some of the tasks. One of these users failed to understandhow to check if a request is created. The other one found it difficult to understand that allspinners must be fulfilled to be able to send a new error. Of these three users who managedto complete all tasks, two users were involved in the project at earlier stages.

The result of SUS evaluation showed the SUS score for each user and each question. Theaverage score of each question was also presented. This was used to calculate the final SUSscore of the application. The result of the SUS evaluation showed an average SUS scoreof 81, see Table 4.3. Each user score was converted to a new number, added together andmultiplied with 2.5. For odd items, the actual score minus 1 and for even items, 5 minus theactual score. The values outside the parenthesis represents the actual score and the valuesinside the parenthesis are the converted ones.

The users who wasn’t involved in earlier stages of the project gave lower score in general.However, the users who were involved in similar projects for underground mine had slightlybetter understanding of the application and gave higher score.

Question User 1 User 2 User 3 User 4 User 5 AverageQ1. 4(3) 5(4) 4(3) 4(3) 3(2) 4(3)Q2. 1(4) 1(4) 1(4) 2(3) 1(4) 1.2(3.8)Q3. 3(2) 4(3) 4(3) 3(2) 3(2) 3.4(2.4)Q4. 1(4) 1(4) 1(4) 1(4) 1(4) 1(4)Q5. 3(2) 4(3) 4(3) 3(2) 3(2) 3.4(2.4)Q6. 2(3) 2(3) 1(4) 3(2) 2(3) 2(3)Q7. 5(4) 5(4) 4(3) 5(4) 4(3) 4.6(3.6)Q8. 1(4) 1(4) 2(3) 1(4) 2(3) 1.4(3.6)Q9. 5(4) 5(4) 5(4) 4(3) 5(4) 4.8(3.8)Q10. 1(4) 2(3) 2(3) 1(4) 2(3) 1.6(3.4)SUS score 85 82.5 85 77.5 75 81

Table 4.3: SUS Evaluation for Sprint 3

41

4.4. Sprint 3

The second part of the test session included rating the application using usability heuris-tics. The users were asked to rate the system based on the ten heuristics suggested by Nielsen[27]. For each heuristic, a clear definition with examples was given in order to achieve morereliable result. The results are shown in table 4.4.

During the test session the users also gave feedback about the layout and possible im-provement from the operators point of view. The users was asked to elaborate each commentand think loud. Some of the important feedback during the session were:

1. Good error messages through the application. It makes it easier to understand the sys-tem and avoid mistakes.

2. Help documentation should be available and help function should be more visible

3. Some of the data shown are not in logical order. That needs to be improved.

4. It is easy to learn the system. Not a lot of remembering is required.

5. The overall design, colors and text and button size are good for the context. However,it has the potential to be improved.

Heuristic User 1 User 2 User 3 User 4 User 5 MedianH1. 2 1 2 2 1 2H2. 1 1 1 1 1 1H3. 2 1 2 1 1 1H4. 2 2 2 2 1 2H5. 1 2 1 1 1 1H6. 2 2 1 2 2 2H7. 2 1 1 2 1 1H8. 2 2 2 2 2 2H9 1 1 1 1 1 1H10. 0 1 1 0 0 0

Table 4.4: Final result of the heuristic evaluation

42

5 Discussion

This chapter discusses the chosen methods, results and conclusion related to them. The aimof the discussion was to highlight the findings and the meaning of them, relation to otherstudies, limitations, explanation of the outcome and suggestion for further research.

5.1 Results

This section discusses and evaluates the outcome of the pre-study, sprints and the final us-ability evaluation.

Initial phase

The outcome or the success of the project depended mainly on the decisions during the engi-neering as stated in section 2.5. The results of the initial phase, a sub-process of requirementengineering is presented in the table 4.1. Table 4.1 presents the agreed functionality fromthe stakeholders and contains four requirements whereof two presents the environment con-straint on which device the application should be ran on and integrated to. The requirementto design the mobile application for an android tablet limited the design and set the standardfor the whole project.

In section 2.5 the three questions needed to satisfy a feasibility study have all been an-swered yes. The system would contribute to the overall objectives of the organization byfacilitating and making the everyday work for the workers in the underground mine moreefficient and usable. The system would be implemented withing schedule and budget butthe scope of the system was minimized from fully functional mobile application to a proto-type. This was done due to that the length of the thesis, scheduled to 20 weeks. The aim ofdeveloping a fully functional mobile application was delimited and developed according torequirements from the stakeholders, to be used on an android tablet with a specific size. Thisresulted in an custom prototype application and not in a generic one that could be adaptedon other mobile operating systems and sizes. We believe that a generic application wouldhave been a better design decision. It could then be used on all mobile devices and wouldnot be time consuming if the type of mobile device would be changed later on in the devel-opment project. The stakeholders wanted to have it for an android tablet and we delimitedthe prototype accordingly.

43

5.1. Results

Requirements elicitation

Appendix A presents the interview questions, divided into five parts used as a basis in orderto collect data about the user and its context. The interview questions are a result of the datacollection with the purpose to learn more about the application domain and its end-users.The interview questions were based on the systematic literature study. We had gathered dataabout the domain, context, issues, structure et cetera and brainstormed these question fromthat data. We believe that if we had access to more information such as observations andmore documents and facts, then the interview questions would have increased and coveredmore details.In section 2.4, the design process was presented on how to design interactive systems withthe user in mind. Following the four steps resulted in interview questions divided in sectionsaccording to the activities presented in ISO 9241-210 [2]. These questions were defined fromthe data collected from the literature study and our interpretation of the theories, what we asdesigners needed to know about the user. We would have liked to complete or build uponthis data with data from other methods such as observation, surveys and similar. The firstactivity was about understanding the user and the context of use. The results of the firstactivity are presented in Appendix A, A1-A2, called "User background and demographicinformation" and "Roles and responsibilities". The second activity was about users needsand requirement for the application. In order to understand what need a mobile applicationcould satisfy for the users in the domain, an understanding of the working environment,communication, available resources and users needs and requests were relevant. The thirdactivity, understanding the design principles, resulted in Appendix F where design questionswere raised and latter applied in producing the concept wire frames presented in appendixG. The fourth activity was about evaluating the design in order to ensure that it meet usersneeds and requirements. According to B.Suranto [37] understanding the requirements couldbe difficult due to that stakeholders often did not know what they wanted from a system orfind it hard to articulate and express. Viewing the initial four requirements in table 4.1 arevague and open for interpretation.

The five respondents recruited to match our end-users and to be interviewed for the semi-structured interviewed are presented in table 3.1. Three of the five users were directlyconnected to the role used to develop the prototype. The other two had previously been inthat role but evolved further to management. The average year of experience are 12 resultingin average age of >30. We did not believe that lack of younger respondents would affectthe outcome of the final prototype due to that all of our respondents regardless of age werefamiliar with smartphones and social media. The respondents were originate from Swedenand Australia. This was a consciously decision to do include users from other countriesdue to that the underground mines in Sweden, we were in contact with, were either fullybooked for guided visits or did not want to have external people observing a sensitive areaand publishing data about them. It was more common that the different underground minecompanies engaged own employees to conduct this kind of research then external people.

Appendix C contains two personas, related situations and scenarios. The appendix is aninterpretations of the end-user derived from collected results from the conducted interviews.

Conceptual design

The requirement document in the thesis can be found in appendix B requirement documenta-tion. The requirement documentation was divided into functionality and description writtenin natural language. According to the recommendation of B. Suranto [37] the requirementdocumentation should be written in functional and non-functional requirements. Due tothesis delimitations and the limited time interval, performance and security et cetera are

44

5.1. Results

not considered in this thesis. Therefore only some parts of the non-functional requirementssuch as usability have been take in consideration and the remaining should be consideredin further work. Even if we had more time we would not be able to test non functionalrequirements due to that we could not visit and actual underground mine.

The application prototype and the requirement delimitations have been adapted to theSAFE and stakeholders restrictions. The platform SAFE has support for maps both in 2Dand 3D but in order to develop a lightweight mobile application exclusion of this require-ment was required. Processing mapping affects the performance negative and would notfulfill the requirement of a lightweight application. There already existed in most of theunderground mine companies a third party programs for mapping. The platform is thebasis for command and control of the system and plays an important role in the technicalaspect of the design. The different underground mines in Sweden have different qualitieson the wireless communication in the mines, due to these differences we assumed a goodand stable wireless communication. The goal of this thesis was not to develop an applica-tion to improve the technical aspect but to include the end users experience and usability of it.

In Appendix E, design questions were raised and answered with help of the design guide-lines. The results of the guidelines are not presented in the thesis as result but can be foundon material.io. To visualize the requirements, different concepts were designed as an initialversion of the application. The designed concepts can be found in appendix G. The conceptswere evaluated using the decision tool, the Pugh matrix. The results of the evaluation canbe found in table 3.1. The decision tool was used to evaluate the concepts by using criteria,adding weight to the criteria and using a baseline to compare the concepts to it and compar-ing if the concept is better, same or worse than the baseline concept. The results presented inthe table 3.1 shows two concept whereof one is used as a baseline. The number of conceptsdepended of the number students conducting the project. Due to the different layouts aconsensus decision was made to make one concept each and evaluate one final.

Reviewing the results in the Pugh matrix 4.2 we could conclude that having more con-cepts would most likely resulted in a different final concept due to more ideas would havebeen considered and implemented in the final concept. The recommendation for the teamsize when using the Pugh matrix is four to six members. The Pugh matrix allows the compar-ison to be subjective but the result of the Pugh matrix is more objective. Therefore applyingthe Pugh matrix on a team of two increases the risk of the result of the Pugh being moresubjective than objective.

The research question stated to explore users perspective by designing the application todifferent roles in order to be flexible. The designed mobile application prototype had dueto time limitations only been adapted to one user role. The idea with the application was toadapt the functionality and data to users role due to that different users had different needsand the design of the Mobile application should reflect the operability.

HI-FI design and implementation

The final implemented design was based on the wire frame and feedback conducted inprevious sprints. The used framework and tool was decided after many discussions withthe supervisor and other developers at the company. We found that the most efficient wayto design the Hi-Fi prototype was to use a tool that could be easily integrated with the codeimplementation later on. Hence, Android framework with XML and Java code was usedto design the prototype and implement the prototype. We did some changes on the designbased on the usability evaluation in sprint 1 and 2. The selection of the colours was basedon the logo of the company as well as following material.io design guidelines. It was very

45

5.1. Results

important to follow these guidelines especially when it came to the margins, navigation andinteractions. Following the design guidelines is following the standard design for androidapplication which is something the users are familiar with and can easily navigate through.These guidelines were already followed while designing the wire frame in previous sprintbut when designing the Hi-Fi prototype it was even more important when taking colours,real margins and navigation into account. The design was mainly based on the wire framebut some things were changes after the evaluation session. Also, the selection of backgroundcolour was based on the context of use, i.e. the dark environments in underground mine.

The chat function was removed because most of the users thought it would be challeng-ing to have such function in an application that should focus on the work tasks. Also, it wasnot possible to integrate the chat function together with SAFE. Hence, the chat layout wasremoved. For the main layout, we decided to have only three main items as these items werethe most important functionalities in the application prototype.

The tasks layout included one of the major functionalities of the prototype. The aim was tomake this layout usable for the underground operators to be able to do their work in efficientway. The digitisation of the given tasks was a big step and would save a lot of effort and timeboth for supervisors and operations if done properly. We followed the heuristics given byNielsen while designing the prototype and tried to consider these principles throughout thedesign. One of the most important principles considered was to match the system with thereal world. We tried to use concepts and phrases familiar to the operators in the undergroundmine. We aimed to design a layout that looks familiar to the actual users to make it easierto learn the system and not make it too complex. This is also reflected in the principle ofminimalist design. We tried to keep only the most important and needed information notonly in tasks layout but also in the rest of the layouts.

The decision to remove the “Start” button from the tasks layout and keep it only in tasks de-scription was made after the usability evaluation session conducted in sprint 2. The opinionsdiffered and we wanted to make it easier for the user to just click the start button immediatelywithout forcing him/her to navigate to the task description. However, the feedback we gotfrom the participants during evaluation in sprint 2 forced us to rethink. We realized thatthe user should navigate to task description and get a full understanding of the assignmentbefore start. With that decision we would make the user navigate to task description anywayand that can have some disadvantages when considering the principle of user control andfreedom suggested by Nielsen [27].

The idea of reporting error and request supplies was appreciated by many of the partici-pants during the evaluation session in sprint 2. The operators in an underground mine donot have the flexibility to move between places, hence it can be challenging to get help orget more supplies needed to complete the assignment. Unlike the tasks layout that wasinspired by SAFE from the beginning, error report and request supplies were not based orinspired by any framework used in the company. The decision to implement these layoutswas mainly because we saw a need of this kind of functionality. Regarding the design, wetried to give these layouts a consistency and standardization. Hence, the filtering functionand the predefined item in the filters looks similar in both layouts.

Final usability evaluation

The final usability evaluation was based on a questionnaire where the user was able tonavigate throughout the system and reflecting on these questions at the same time. Threeof the users succeed to complete the given tasks within a reasonable time and did not needhelp or instructions. The remaining two users had some troubles to complete all of the tasks.

46

5.2. Method

These users did not really need instructions or help they just found some of the functionsunclear. One of the users did not understand that it was mandatory to fill in all spinnersbefore reporting an error or requesting supplies. However, the most important layouts inthe prototype were the “Tasks layout” and “Task description”. All participants managed tocomplete the given tasks for these two layouts.

The SUS questionnaire gave an average score of 81, meaning that the overall usability ofthe prototype based on SUS questionnaire was above the average SUS score of 68 [10]. Wecould clearly see a difference between the score given by users that participated in earlierstages of the study and users that never had seen the design before. We believed that if all fiveusers who participated in the evaluation session was new to the prototype, the score wouldbe even lower. User 5, who is in a management position in the company, gave the lowestscore of 75. This user has never seen the prototype before and was new to the idea behind theapplication. We can also see that the users who were involved in earlier stages gave a higherscore for the questions “I thought the system was easy to use” and “I found the variousfunctions of this system were well integrated”. There is no statically data showing thesestatements but it could somehow be concluded from the results. The users who participatedin earlier stages had more understanding of the overall idea of the application and affectedmany details of the design. One important thing to consider is that no representative userssuch as underground operators affected the user testing and the evaluation. That lowers theexternal validity. This means that if the same evaluation were conducted with undergroundoperators only, the overall usability score would be different.

The downside of the final usability evaluation, as mentioned before, was the lack of rep-resentative users or operators. It was challenging for us to find representative users toparticipate in the evaluation sessions. That clearly have a negative reflection on the overallvalidity of the evaluation, as the participants included only consultants and developers. Wecan clearly see that heuristic number eight (Aesthetic and minimalist design) gave the highestmedian of 2, which is the highest possible score. This means that all participants agreed thatthe prototype is designed in a way to make the system include only the most importantinformation as well as an aesthetic design. However, real users might have different opinionsand ideas on how they want the design to look like and if the prototype really includes onlythe most important information needed or not.

Also, heuristic number four (consistency and standard) and six (recognition rather thanrecall) gave the highest median score of 2. This is also a good indication that the applicationprototype followed a standard design and the participants did not have a need to rememberanything and it was easy to navigate between the layouts without any instructions. However,underground operators might not share the same opinion and that can lower the score if thesession was held with representative users. The last heuristic, number 10 (Help and docu-mentation) gave the lowest median of 0, which is a bad score. This meant that the prototypewas not usable in terms of instructions and help documentations. The prototype lacked thehelp documentation and needed to be improved. However, similar to SUS evaluation, theusers who participated in earlier stages of the study gave higher score for heuristic evalua-tion.

5.2 Method

This section discusses the choice of methods during the initial phase and conceptual designto the choice of the implementation and evaluation tools to evaluate the overall usability ofthe system.

47

5.2. Method

Initial phase

The aim of the feasibility study was to establish clear goals and to answer why the researchwas of importance and what the expectations of the results were. Designing the research re-quired to choose the right methodology. In the initial phase a feasibility study was conductedbefore starting the project. The method was chosen due to its recommendation in the theoryto be used before undertaking initiation and planning. The method was used to determinethe feasibility of an idea, description of the project, requirement and other important factorsand constraints such as environment, technology, resources et cetera. According to the theory,feasibility study is important to clarify the purpose of the project before using resources butalso involve the stakeholders from the beginning of the process to have clear requirements.The usage of the method resulted only in four requirements as stated earlier in the resultssection. The initial requirements from the stakeholders were vague and needed further timespent to investigate and have sessions to clarify the requirement. The feasibility study itselfwas a good method to use but further method was needed to be applied to help clarify theinitial requirements or a extended form of the study or important steps that could be followedto facilitate the investigation.

Requirements elicitation

The results of the interviews were collected and discussed. The data collected resulted intopersonas. The personas, scenarios and situations were based on the answers from the respon-dents, analysed and interpreted by the writers into a holistic approach of the users. Accord-ing to L.Nielsen [31] in section 2.4 it was important to include users everyday experience andneeds. Due to regulations of security in the underground mines and fully booked visiting noobservations were possible to be conducted. This resulted in interpretations of the answersfrom the interviews. The results in this thesis rely on answers and research based on five re-spondents. According to L.Nielsen [31] the number of required personas rely on how muchthe users variate within the specific area. Considering the different roles times varieties ingender, age, technical skills et cetera the amount of recruited users to observe and interviewwould result in more than five people. The persona is a representation of the user in orderto include them in the design process however the downside of using a persona according tothe theories is that persona is a one dimensional version of the user. In order to use persona awider understanding of the whole context was needed. This was equipoise with a systematicliterature study. The personas presented had role-based perspective and were only used as atool to comprehend and constrain the data to target the design.

Conceptual design

The next step in the process was to understand the context of use, the user and domain in or-der to produce user requirements and a design. A systematic literature study was conductedin order to collect data. The chosen methods for this was adapted to the current situationsand constraints. Due to that the end users were not present at the company where the thesiswas conducted but in an underground mine in northern Sweden with no possibilities tovisit or make an observation a systematic literature study was conducted instead. The datacollected was then brainstormed into interview questions and used to do interviews bothpersonally and via Skype. The interviews were semi-structured interviews and latter theonline communication was the only contact that we had with the stakeholders that wereinterviewed.

The ISO 9241-210 standard [1] was used for guidance to collect data in a standard way.This standard discusses important definitions and states regarding what should be achievedbut not in which way. The method was not stated but it was up to the reader to choose. Theten steps for developing persona, situation and scenario was done according to L.Nielsen

48

5.2. Method

[31]. The steps are used to create a fictive persona. In this case the results and analysis of theinterview answers were basis for producing results for the ten steps.

The next phase in the requirement engineering was the requirement specification, writ-ing the requirements to a document. The issue based information or IBIS was used torationalize decisions an was relatively easy to apply, keeping track of all issues and theirlogical relationships. The method was applied on design problems and resulted in pros, consbut also in further questions and problems which in some cases resulted in long discussionsand was time consuming. Some questions were easier to process than others and the issuemapping differed in size and complexity making it hard to come to a final conclusion.

The IBIS method was applied on the question in Appendix F after conducting a litera-ture study in order to be able to answer them but also raise further design questions. Whendesigning the prototype for conceptual design a layered framework was used based on [33]recommendation. The proposed framework was generic and open for interpretation.

Hi-Fi design and implementation

Android Studio was used for designing and implementing the functionalities of the appli-cation prototype. The reason behind using Android’s integrated development environment(IDE) was because it could easily be integrated with SAFE as well as we were more confidentusing android studio and the Java programming language. Designing the Hi-Fi prototypewas easy using the XML code in Android studio. This code was then easily reused to con-tinue with the implementation of the functionality. It would be less time consuming if weused another tool to design the Hi-Fi prototype, but in that case we would not be able to usethat design to continue the implementation of the functionality. We decided to develop thefunctionalities for the application prototype using Java API framework in order to be able tointegrate the code with SAFE later on as well as give the company an opportunity to continuewith the application and eventually release it for real users.

Final usability evaluation

The final usability evaluation was based both on SUS questionnare and application ratebased on usability heuristics heuristic. The downside of using SUS questionnaire in thisstudy was the lack of representative end users in the evaluation. It was very challengingto get in contact with end users to participate in the final usability test. The main reasonis that we were not allowed to visit an underground mine, hence we did not get in contactwith underground mine operators in personal. For that reason, we chose to hold the SUSquestionnaire session with consultants, developers and mangers in Combitech instead. Ac-cording to Bangor, Kortum and Miller [9], SUS questionnaire evaluation is a widely acceptedmethod to measure the overall usability of a system. On the other hand Bangor, Kortumand Miller [9] mean that this method cannot be used to measure the absolute usability of asystem. Remote testing could have been used to measure the usability from end users pointof view. The problem here again is that we could not get in touch with any end user that waswilling to help us to test the application prototype. We were able to evaluate the Hi-Fi designwith one technician that works in underground mine. That technician was not able to helpus during sprint 3 for personal reasons.

Application rate using usability heuristics was used to get feedback from usability ex-perts and developers. Here, the selection of participants was good, as the five participantsincluded two consultants, two developers and one manager. These users had a good back-ground in usability testing as well as developing systems for the underground mines. Theevaluation was based on the 10 heuristics suggested by Nielsen. These heuristics measure

49

5.3. Replicability, Reliability and Validity

all the important aspects in a system from the usability point of view. The idea was tounderstand how usable the application prototype and how much improvement it needs.

5.3 Replicability, Reliability and Validity

Replicability, reliability and validity are used to evaluate the quality of research.

Replicability

The methods used and presented in both theory and method chapter are well defined, how-ever if the same methods were to be applied the outcome of the design would be different.This means that only the design process is able to be replicated and not the results of the de-sign process. Due to that the data collection was mainly qualitative it was difficult to recreatethe exact conditions of the original study. In research only quantitative research is defined asreplicable. In qualitative studies the participants and context can vary. In this case the usersoriginated across the globe and a more generalized result of the context and environment inwhich the users operate was concluded. There are many roles in the underground mine andthe conditions and needs in every mine vary. If the role of the users differentiated from eachother the results would be different and the outcome of each method would differ. Howeverwe believe that a replication of the design process would result in same generalised answerof the research question.

Reliability

The results of this thesis rely mainly on a qualitative research, the semi-conducted interviews,handling non-numeric information and interpretation. Reliability in qualitative research ischallenging and the reliability in this case is wherever the results are consistent if same meth-ods are used under the same conditions. If same methods are applied on the same group ofpeople we believe that same results would be produced. In other cases it would be unlikelythat the final result would be exactly the same. The general understanding is if the researchis replicable then it is reliable. In this case only a degree of reliability can be achieved dueto the design decisions make in the process and the choice of method for the data collec-tion. The methods used in this thesis are human centered and include the user in the processand evaluation in each step. ISO 9241-210, Human-centered design are iterative and includeevaluation of the design to meet the requirements of the user and stakeholders. Due to thenature of the design process the requirements, concepts and evaluation of these would leadto different outcome due to different sources and stakeholders involved in the development.Requirement engineering is another process with evaluation and validation of the require-ments with the stakeholders in every design decision. The main methods used in the thesiswere iterative and validation of the results were consistently checked across the process.

Validity

The methods used in designing and evaluating the application prototype are efficient whenusing data and information from representative users according to the theories presented.However, in this study the lack of representative users in the final usability evaluation af-fected the overall validity of the results. According to Nielsen five users are consideredenough to measure the overall usability of the system. That would be possible if representa-tive users were involved through the whole design process. Hence, the external validity canbe questioned. However, the participant in the evaluation sessions were involved in softwareprojects for underground mines and had an understanding of the environment and needs ofthe operators. Hence, the study has some degree of validity.

50

5.4. The work in a wider context

5.4 The work in a wider context

Ethical aspects related to the work has been taken in consideration were no further data ofthe recruited respondents has been given in the thesis. The interviews were recorded withpermission from the interviews before the actual interview started. The audio has only beenlistened to by the authors of this thesis and latter destroyed of respect to the agreement.No raw data was presented from the interviews but instead used for decision making anddiscussion in the design process. During the usability tests the users were informed aboutthe aim of the test and what is being tested, not whom. Due to confidential informationregarding the project this thesis is apart of at Combitech and their customers for whom thisapplication prototype was developed for the thesis has been reviewed by the supervisor atCombitech before publication.

Future work

One of the limitation of this study was the availability of real end-users. Hence, many im-provements on the design and functionalities can be applied in the future, were undergroundoperators are involved. The idea from the first beginning was to design an application proto-type were the operator can digitally, with a smart phone or a tablet, view all the assignmentsfor the current shift and keep track on the work progress. This means that the layouts fortasks are the most important ones. With the help of end-users the design and implementa-tion of these layouts can be improved. Some more functionalities can also be added to theapplication. A 3D map is an idea we had but because of limitations in time and resources,the idea could not be performed. A 3D map can be implemented in the future to help theoperators to easily find the correct location for the assignment, select the exact position for aneventual error and select a position to pick up the requested supply.

51

6 Conclusion

The purpose of this project was to develop a usable and lightweight mobile applicationprototype focusing on the users needs and requirements in the working environment. Inorder to do so we needed to answer the research question: How can a mobile application bedesigned for usability with focus on operability for an underground mine?

Early in the design process insights were built on the people who would be affected bythe future design, the stakeholders and respondents. The insights for working on theconceptual design corresponded to the customers intention. We developed a holistic un-derstanding of the users, stakeholders, environment, situation and activities by using ISO9241-210 Human centered design. In the initial phase we explored what was desirableamong the stakeholders, what needed to be developed and why. These insights turned intoideas and were translated into requirements and latter into concepts. When the design wasanalysed and decided the conceptual design was specified into detailed prototype, detailsand specifications. To measure if the application prototype was actually usable enough wasnot an easy task. The methods used to evaluate the design and the implementation arewidely known and used but the lack of real end-users made it challenging to draw a finalconclusion regarding the absolute usability. Based on the result, the overall usability wasslightly above the average in terms of operability. The design included functionalities thatmeet the needs of the users we interviewed. But that did not mean that we would get similarresults if representative users were involved. The limited number of recruited respondentshad to some degree a negative impact and delimited the outcome of the final concept andin turn the prototype. The data collected was based on a few user perspectives and if moreusers were recruited a more generalised prototype would have been developed and latterhad a improved impact on the evaluation results and usability. This can be identified inthe results of the evaluation of the Hi-fi prototype where the feedback regarding a specificlayout differed for every person. By involving more representative users the overall usabil-ity of the solution would increase. Another aspect is that that the outcome of the projectmainly depended on the requirements that the users and the stakeholders needed and couldidentify themselves. Usability is not always what the users think they need but also for thedevelopers to identify what the users did not know that they needed to improve the usability.

This application prototype could be a starting point to help the user to perform the daily

52

assignments easier and reduce the time to get help, which are one of the major issues foroperators in today’s underground mines in Sweden and other parts of the world. The under-ground mine is a dark and harsh environment which this application prototype takes theseaspects into account. To answer the research question, a usable mobile application couldbe designed based on several steps that was used and introduced throughout the study inorder to meet the users’ needs and requirements. The first step was to create a plan thatincludes gaining insights from the users, define the scope of the work and recruit users. Thisstep followed by sketching two or more potential designs, interview users to get feedbackand identify issues. The next step was to choose the best design based on analyzing dataconducted from interviews and evaluation sessions with the users. The last step was to im-plement the design and again interview the users, identify design issues and identify designrecommendation based on the feedback. The data and feedback conducted in the final testsession was then used to measure and summarize the overall usability of the system.

53

A Appendix: Interview questions

A.1 User background and demographic information

1. Age?

2. Where do you live and work?

3. What is the highest level of school you have completed or the highest degree you havereceived??

4. How did you come in contact with this domain?

5. How many hours a day do you spend on social media?

6. How many hours a day do you spend on your smart phone?

7. How often do you check your work email?

8. Do you use any type of software systems at work? If yes,please elaborate.

A.2 Role and responsibilities

9. What role and job title do you have in the underground mine?

10. Have you had other roles in the domain?

11. Job description?

12. Years of experience?

13. In what more areas have you had a role in the domain?

14. Describe a typical work day

54

A.3. Communication and challenges in the domain and/or users

A.3 Communication and challenges in the domain and/or users

15. How do you experience your working environment?

16. Are there any challenges or constraints working in this environment?

17. How do you navigate?(Device, map etc.)

18. How do you communicate today,with colleagues or control center?Communicationchannel?

19. Do you use any mobile devices or systems in your work?

20. Do you have access to a network?

21. Do you use your personal mobile phone?

22. How many shifts are there under one day?

23. Do the amount of shifts change depending on the role?

24. How many tasks does a shift usually contain?

25. How do you get your work order/tasks?(digital, on paper etc)

26. Are the tasks prioritizes? If yes, how and do you always follow the prioritization?

27. What kind of information does a task contain?(Location,category,vehicle,task goal,notes etc)

28. If more information is needed regarding the work order, who do you contact?

29. Do you use checklists? If so do you go through the checklist before or after the task isdone?

30. If there is a problem on the checklist, who and how do you report the problem?

31. How often do you encounter equipment/environment problems during the shift?

32. How do you keep track of when a task has met the goal?

33. How do you mark or report when a task has been completed?

A.4 Resources

34. Do you have a work standard or protocol for requiring extra resources or material?

35. If resources are needed, do you request them? If so, who do you contact?

36. Do you have a storage in the underground mine with extra resources or material avail-able?

37. If resource storage exists, are they available on each level?

38. Do you bring extra resources with you after receiving the task(s)?

39. Is there a protocol or documents over items that you might need?

40. Do you receive information from previous shift, goals issues?

a) If yes,how is this information shared?Who shares it with you?

55

A.5. Needs and requests

41. What kind of information is shared between shifts?

42. Is it relevant for you to know which tasks your colleagues are working on during thesame shift?

43. Are the vehicles/machines allocated with the task?

a) If no, how do you allocate one yourself?

44. Can you see if a vehicle/machine is available/busy at a certain point?

45. What kind of information is necessary for you to know about a vehicle in order to per-form the task?

A.5 Needs and requests

46. How do you report a problem and to whom?

47. When reporting a problem, do you use problem codes or do you describe the problem?

48. Do you always report a problem or do you try to fix it yourself?

49. What problems are mostly common to occur in your line of work?(Regarding environ-ment,equipment,vehicle etc.)

50. If you try to fix a problem, which problems do you try to fix?

56

B Appendix: Requirements initialphase

Functionality DefinitionContext adapted design Design for interaction with glovesInformation backup Backup the information due to internet service fail-

ure or accident with the tabletTake photo Take a photo when reporting and errorGet notifications Receive notifications about changes in the work or-

der, request or warnings and emergencies.View Map View current position, warnings, storagePositioning service View resources, people, vehicle et ceteraView checklist Digitizes the checklistGet documents SOP and other related documents to work shiftReport an error for equipment The operator should be able to report an error re-

garding the equipment during the shift.Chat Contact colleagues via chatVisualise progress Able to visualize progress of a task, error report or

request.View all tasks for the shift The operator can view all the assigned tasks for

him/her in the shift.View work order View the work order for the shiftView current location on a map The operator should view his/hers current location

on a map when signing in.Storage management View availability of resources in storage and loca-

tion. Ease of use to reserve, allocate and stock.View location of each task The operator should view the location of the vehi-

cle, start location and destination of each task.Take photo The operator should be able to take a photo of an

object when needed.Checklist for each task The operator should view a checklist for each task.Convey and receive emergency information Convey and receive information about e.g risk ar-

eas, reason and distance(location).

57

Communication channel A chat function where operators can send and re-ceive messages to and from their colleagues.

Access to relevant documents Access to all relevant documents: SOP, service man-uals, etc.

Leave and view notes The operator should be able to leave and view notesto and from other operators, control room and shiftsupervisor.

Colleagues overview Overview of all the colleagues in the shift.View weekly Gantt chart The operator should be able to view the weekly

Gantt chart.Progress follow-up Overview of the activity progress, KPI, goals etc.Change the status of the task The operator should be able to change the status of

the task, for example start, pause and finish the task.View error reports View list of error reports in order.The list can be fil-

tered and searched and customized after needs.

58

C Appendix: Persona

C.1 Persona 1: Sofia Eriksson

Figure C.1: Persona 1: Sofia Eriksson

59

C.2. Persona 1: Situation

C.2 Persona 1: Situation

Before the shift starts at 06:00, a morning meeting is held were the work orders are handedout. The work orders contain type of work, amount, start and end time, work level, startand end destination and name of the shift boss. After the work order has been handed out,a quick check is done to see if everything is in order. Tire change is not uncommon butthis time everything was in order. Sofia get in the truck, logs into the system and starts herjourney down the mine. Her task for the entire shift is to load at a 1020-meter-deep, which isa good depth according to Sofia because her dump destination is above ground. Sofia looksat the gasometer during her way down to the load destination. The gasometer shows normallevels, but it is not unusual that there are gases left from the explosions the day before. If thegas levels are too high Sofia would need to terminate current work order and begin another.When Sofia arrives to her load destination a mining loader is waiting. The mining loader fillsher truck with two buckets, a total weight of 50 tones, including the trucks weight of 12,5tones. The dump destination starts at a maximum speed of 25 km/h with a distance of 16km. The work task is simple, but the road is completely different from a country road. Sofiafeels lucky that the work level is at 1020 meters deep. The mine is current 1545 meters deepand has a total of 160 miles road. It is important to find in the underground mine becausedue to the dark conditions and long roads the risk of driving wrong is high. She feels thatworking in an underground mine can be limited and lonely but the colleagues are alwaysclose. The best thing, according to Sofia is driving back and meeting a lot of people alongthe way, communicating via radio and enjoying the journey with good music. When Sofiaapproaches a tricky curve where no meeting traffic can exist, she calls out to her collegesto inform them. After dumping the current load, she has five loads left. Sofia continuesprocessing her work order with no major chaos in the traffic, flooding or mine collapses. Themobile phone coverage is not good at all places and if anything should break, usually becauseof hard driving, repair must take place immediately. Reporting the problem and waiting formaintenance can take a long time depending on the level on which the vehicle broke down.So before starting the work task Sofia always collects some extra spare parts such as differenthoses, couplings and other necessities. The best thing would be that someone comes with thespare parts when standing.

C.3 Persona 1: Scenario

During the morning meeting, each operator takes a mobile device and logs in with usernameand password to see the work orders for the day. Sofia views the first assignment, which isprioritised in the application. All necessary information and documents for the orders areprovided in the application. When Sofia chooses to start the first task a checklist appears. Thechecklist contains all necessary checks she needs to do in order to continue the assignment.She finds a deviating check, one break light does not work and she performs an error reportof the problem. The error report takes only a couple of clicks and she adds a picture ofthe problem which is submitted and handled automatically by the system to maintenancedepartment, containing all necessary information. The broken break light is not a criticalproblem and she can continue the checklist and submit it when she has done all the checks.The assignment description contains the amount of loads, which she can update using theapplication. Using the application, Sofia can see her current position on a map of the under-ground mine and all of the important information and warnings in her surroundings and toher destination. If anything should break, Sofia can use the error report to request help withhigh priority and get help or use the chat function, selecting operators in same work order tocontact for help.

60

C.4. Persona 2: Kalle

C.4 Persona 2: Kalle

Figure C.2: Persona 2

C.5 Persona 2: Situation

Kalle starts his shift by having a morning meeting above ground at 6:00 am together withhis colleagues and shift supervisor. In the meeting the supervisor goes through what is ex-pected and shares the tasks for each miner. He gets his tasks and plans a carpool to thevehicles/machines together with his colleagues. Kalle starts with the first task in the task list.At 7:10 am he turns on the power of the drilling machine. The machine is not located at thesame place where the drilling work is meant to be. The “drilling place” is badly cleaned andthe surface is uneven. This might be because of depressed material, a lot of gravel and loosestone. Kalle checks if any other miner have left a message in the machine about the situation.He doesn’t find any messages and decides to call his colleague to ask about what happenedand what to do. At 7:40 am kalle drives the machine to another place than the planned one.He starts the drilling and the goal is to drill up to “wreath” 24. When drilling, he uses a com-bination of water and watermist. The drilling goes well and he tries to use the auto mode asmuch as possible. At 10:20 am a problem with the water supply occurred and he reportedthe problem in order to call a mechanic for help. Kalle takes a lunch break and then startstroubleshooting to try to find the problem as soon as possible. The mechanic has not arrivedyet. Kalle finds that the water flow is ok but there is a problem with the compressor. Themechanic arrives at 13:00 pm and it looks like that the problem will take a lot of time to solve.The machine should be ready to use next day. Kalle paused this task and after contacting theshift supervisor they decided that he should start with the next task one on the list.

C.6 Persona 2: scenario

Kalle starts his shift by logging into the application using his user name and password. Hecan easily see his tasks for the shift even before the morning meeting. When the morningmeeting starts, the shift boss goes through some important points that the miners need to

61

C.6. Persona 2: scenario

keep in mind. Because Kalle already knows his tasks, he can ask relevant questions aboutthe tasks if something is unclear. He can easily see the location, the vehicle that will be usedand the goal that needs to be completed for each tasks. He decides to start with the first taskas it is of a higher priority. At 7:10 am he turns on the power of the drilling machine. Themachine is not located at the same place where the drilling work is meant to be. The “drillingplace” is badly cleaned and the surface is uneven. He checks if any other miner have left amessage in the machine about the situation in the application under the field "notes" in thetask description. He notices that the miner that worked on the same vehicle in the previousshift has left a note, meaning that the surface is uneaven and it might be best to drive thedrilling machine to another place. Kalle decides to make an error report about the problembut finds in the reported error list that his colleague has already done such error report aboutwhat happens in the previous task. Some minutes later Kalle receives a note that the task hasbeen updated by the control room where the drilling location has been changed. He startsthe drilling in the new location. At 10:20 am a problem with the water supply occurred andhe decides to make an error report. Because it an error that just occurred he decided to skipgoing through the error list. He makes a new error report and describes the problem easilyvia the application. Kalle takes a lunch break and then starts troubleshooting to try to findthe problem as soon as possible. The shift boss notices that the mechanic will not arrive until13:00 and the problem might take a lot of time to solve. He decides to update the work planfor Kalle. He receives a note telling him that the tasks have been re-prioritized. He pausesthe task and starts immediately with the new prioritized task in another location.

62

D Appendix: Requirements sprint 1

Id Functionality Definition1.1 View all tasks for the shift The operator can view all the assigned tasks for

him/her in the shift.1.2 View current location on a map The operator should view his/hers current location

on a map when signing in.1.3 View location of each task The operator should view the location of the vehi-

cle, start location and destination of each task.1.4 Take photo The operator should be able to take a photo of an

object when needed.1.5 Checklist for each task The operator should view a checklist for each task.1.6 Report an error for equipment The operator should be able to report an error re-

garding the equipment during the shift.1.7 Convey and receive emergency information Convey and receive information about e.g risk ar-

eas, reason and distance(location).1.8 Communication channel A chat function where operators can send and re-

ceive messages to and from their colleagues.1.9 Access to relevant documents Access to all relevant documents: SOP, service man-

uals, etc.1.10 Leave and view notes The operator should be able to leave and view notes

to and from other operators, control room and shiftsupervisor.

1.11 Colleagues overview Overview of all the colleagues in the shift.1.12 View weekly Gantt chart The operator should be able to view the weekly

Gantt chart.1.13 Progress follow-up Overview of the activity progress, KPI, goals etc.1.14 Change the status of the task The operator should be able to change the status of

the task, for example start, pause and finish the task.1.15 View error reports View list of error reports in order.The list can be fil-

tered and searched and customized after needs.

63

E Appendix: Requirementvalidation Sprint 1

Id Functionality Definition1.1 View all tasks for the shift The operator can view all the assigned tasks for

him/her in the shift.1.2 Take photo The operator should be able to take a photo of an

object when needed.1.3 Checklist for each task The operator should view a checklist for each task.1.4 Report an error for equipment The operator should be able to report an error re-

garding the equipment during the shift.1.5 Communication channel A chat function where operators can send and re-

ceive messages to and from their colleagues.1.6 Access to relevant documents Access to all relevant documents: SOP, service man-

uals, etc.1.7 Leave and view notes The operator should be able to leave and view notes

to and from other operators, control room and shiftsupervisor.

1.8 Colleagues overview Overview of all the colleagues in the shift.1.9 View weekly Gantt chart The operator should be able to view the weekly

Gantt chart.1.10 Progress follow-up Overview of the activity progress, KPI, goals etc.1.11 Change the status of the task The operator should be able to change the status of

the task, for example start, pause and finish the task.1.12 View error reports View list of error reports in order.The list can be fil-

tered and searched and customized after needs.

64

F Appendix: Conceptual designquestions

F.1 Design questions

What is the best architecture pattern to use for Android mobile application?

What is the best search pattern for tablets and other mobile devices?

How can one provide as much information as possible in the mobile application withoutoverwhelming the user?

When should infinite scroll be used?

How should one design push notifications in this specific context?

What are the advantages and disadvantages of the basic tools for developing an AndroidApp?

What input forms are suitable for the contextual design?

How should one use tabs, set hierarchy, menus and content to maximize user experience?

65

G Appendix: Design concepts

66

Figure G.1: Wireflow concept 1

67

Figure G.2: Wireflow concept 2

68

Bibliography

[1] ISO 9241-110. “Ergonomics of human-system interaction — Part 110: Dialogue princi-ples”. In: (2006).

[2] ISO 9241-210. “Ergonomics of human-system interaction — Part 210: Human-centreddesign for interactive systems”. In: (2010).

[3] David Alonso-Ríos, Eduardo Mosqueira-Rey, and V Moret-Bonillo. “A Systematic andGeneralizable Approach to the Heuristic Evaluation of User Interfaces”. In: InternationalJournal of Human-Computer Interaction (Jan. 2018), pp. 1–14. DOI: 10.1080/10447318.2018.1424101.

[4] David Alonso-Ríos, Ana Vázquez-García, Eduardo Mosqueira-Rey, and Vicente Moret-Bonillo. “Usability: A Critical Analysis and a Taxonomy”. In: Int. J. Hum. Comput. Inter-action (2010), pp. 53–74.

[5] Android. “Documentation for app developers”. In: (2019). https://developer.android.com/docs.

[6] Susanna Aromaa, Antti Väätänen, Iina Aaltonen, and Tomi Heimonen. “A Model forGathering and Sharing Knowledge in Maintenance Work”. In: Proceedings of the Euro-pean Conference on Cognitive Ergonomics 2015. ECCE ’15. Warsaw, Poland: ACM, 2007,28:1–28:8. ISBN: 978-1-4503-3612-3. DOI: 10.1145/2788412.2788442.

[7] Mattias Arvola and Henrik Artman. “Enactments in Interaction Design: How De-signers Make Sketches Behave.” In: Artifact 1.2 (). ISSN: 1749-3463. DOI: 10- 1080/17493460601117272.

[8] B.D. ( 1 ) Bailey and J. ( 2 ) Lee. “Decide and conquer a pugh matrix can help teamsappraise situations, evaluate choices.” In: Quality Progress 49.4 (2016), pp. 30–37. ISSN:0033524X.

[9] Aaron Bangor, Philip T. Kortum, and James T. Miller. “An Empirical Evaluation ofthe System Usability Scale”. In: International Journal of Human–Computer Interaction 24.6(2008), pp. 574–594. DOI: 10.1080/10447310802205776.

[10] Aaron Bangor, Philip T. Kortum, and James T. Miller. “Determining what individualSUS scores mean: adding an adjective rating scale”. In: 2009.

[11] Gordon Baxter and Ian Sommerville. “Socio-technical systems: From design methodsto systems engineering”. In: Interacting with Computers 23.1 (2011), pp. 4–17. DOI: 10.1016/j.intcom.2010.07.003.

69

Bibliography

[12] Johan Blomkvist and Mattias Arvola. “Pausing or not? : Examining the Service Walk-through Technique.” In: (). DOI: 10.14236/ewic/hci2014.18.

[13] John Brooke. "SUS-A quick and dirty usability scale." Usability evaluation in industry. ISBN:9780748404605. CRC Press, June 1996.

[14] Stuart K. Card, Thomas P. Moran, and Allen Newell. “The Keystroke-level Model forUser Performance Time with Interactive Systems”. In: Commun. ACM 23.7 (July 1980),pp. 396–410. ISSN: 0001-0782. DOI: 10.1145/358886.358895.

[15] Alan Cline. Agile development in the real world. Berkeley, CA : Apress, 2015., 2015. ISBN:9781484216798.

[16] “Concept selection for market potential using fuzzy selection approach.” In: 2008 IEEEInternational Conference on Industrial Engineering and Engineering Management, IndustrialEngineering and Engineering Management, 2008. IEEM 2008. IEEE International Conferenceon (2008), p. 1699. ISSN: 978-1-4244-2629-4. DOI: 10.1109/IEEM.2008.4738162.

[17] Jeff Conklin and Michael L. Begeman. “gIBIS: A Hypertext Tool for Exploratory PolicyDiscussion”. In: ACM Trans. Inf. Syst. 6.4 (Oct. 1988), pp. 303–331. ISSN: 1046-8188. DOI:10.1145/58566.59297.

[18] “Designing a usable mobile application for field data collection.” In: 2004 IEEEAfricon. 7th Africon Conference in Africa (IEEE Cat. No.04CH37590), AFRICON, 2004. 7thAFRICON Conference in Africa, Africon conference (2004), p. 1187. ISSN: 0-7803-8605-1.DOI: 10.1109/AFRICON.2004.1406877.

[19] Torgeir Dingsøyr, Tore Dybå, and Nils Brede Moe. Agile software development. currentresearch and future directions. Berlin : Springer, c2010., 2010. ISBN: 9783642125751.

[20] Katarina Eriksson Barajas, Christina Forsberg, and Yvonne Wengström. Systematiskalitteraturstudier i utbildningsvetenskap : vägledning vid examensarbeten och vetenskapliga ar-tiklar. Natur Kultur, 2013. ISBN: 9789127134119.

[21] Interaction design foundation. “Interaction design foundation”. In: (2019).https://www.interaction-design.org/.

[22] Google. “Material design”. In: (2019). https://material.io.

[23] ISO and IEC 25010:2011. “Systems and software engineering — Systems and softwareQuality Requirements and Evaluation (SQuaRE) — System and software quality mod-els”. In: (2011).

[24] Maristella Matera, Francesca Rizzo, and Giovanni Carughi. “Web Usability: Principlesand Evaluation Methods”. In: Mar. 2006, pp. 143–180. DOI: 10.1007/3-540-28218-1_5.

[25] Author Mattias Arvola and Author Mathias Broth. “Category, Time, and Space: Struc-tures in Cross-Media Design and Production.” In: Cognitive Ergonomics (), p. 96. ISSN:978-1-4503-7166-7. DOI: 10.1145/3335082.3335107.

[26] R. ( 1 ) McCall, A.H. ( 2 ) Dutoit, I. ( 3 ) Mistrík, and B. ( 4 ) Paech. Rationale managementin software engineering: Concepts and techniques. (1)College of Architecture and Planning,University of Colorado, 314 UCB: Springer Berlin Heidelberg, 2006. ISBN: 3540309977.DOI: 10.1007/978-3-540-30998-7_1.

[27] Jakob Nielsen. 10 Usability Heuristics for User Interface Design. Apr. 1994. URL: https://www.nngroup.com/articles/ten-usability-heuristics/.

[28] Jakob Nielsen. “The Usability Engineering Life Cycle”. In: (1992), pp. 12–22.

[29] Jakob Nielsen. “Usability Engineering”. In: (1992).

70

Bibliography

[30] Jakob Nielsen and Rolf Molich. “Heuristic Evaluation of User Interfaces”. In: Proceed-ings of the SIGCHI Conference on Human Factors in Computing Systems. CHI ’90. Seat-tle, Washington, USA: ACM, 1990, pp. 249–256. ISBN: 0-201-50932-6. DOI: 10.1145/97243.97281.

[31] Lene Nielsen. Personas – user focused design. Human-Computer interaction series: 15.London ; New York : Springer, c2013., 2013. ISBN: 9781447140849.

[32] J. Nilsson, T. Sokoler, T. Binder, and N. Wetcke. “Beyond the Control Room: Mobile De-vices for Spatially Distributed Interaction on Industrial Process Plants.” In: LECTURENOTES IN COMPUTER SCIENCE 1927 (2000), p. 30. ISSN: 0302-9743.

[33] Avi Parush. Conceptual design for interactive systems : designing for performance and userexperience. Waltham, MA : Morgan Kaufmann is an imprint of Elsevier, [2015], 2015.ISBN: 9780124199835.

[34] Horst W. J. Rittel and Melvin M. Webber. “Dilemmas in a general theory of plan-ning”. In: Policy Sciences 4.2 (June 1973), pp. 155–169. ISSN: 1573-0891. DOI: 10.1007/BF01405730.

[35] Saab. “Saab”. In: (2019). URL: https://saab.com.

[36] Ian Sommerville. Software Engineering. 9th. USA: Addison-Wesley Publishing Com-pany, 2010. ISBN: 0137035152, 9780137035151.

[37] Beni Suranto. “Software prototypes: Enhancing the quality of requirements engineeringprocess.” In: 2015 International Symposium on Technology Management Emerging Technolo-gies (ISTMET) (2015), p. 148. ISSN: 9781479917235.

[38] “The Scrum software development process for small teams.” In: IEEE Software, Software,IEEE, IEEE Softw 4 (2000), p. 26. ISSN: 0740-7459. DOI: 10.1109/52.854065.

[39] E. L. Trist and K. W. Bamforth. “Some Social and Psychological Consequences of theLongwall Method of Coal-Getting: An Examination of the Psychological Situation andDefences of a Work Group in Relation to the Social Structure and Technological Con-tent of the Work System”. In: Human Relations 4.1 (1951), pp. 3–38. DOI: 10.1177/001872675100400101.

[40] “Usability Evaluation Methods for Software Development: A Systematic Mapping Re-view.” In: 2015 8th International Conference on Advanced Software Engineering Its Appli-cations (ASEA), Advanced Software Engineering Its Applications (ASEA), 2015 8th Interna-tional Conference on, Advanced Software Engineering and Its Applications (2015), p. 1. ISSN:978-1-4673-9836-7.

71