Defining User Interface Design Patterns in the Insurance...

Interface Insured

Defining User Interface Design Patterns in the Insurance Sector

A.D.G. van Helbergen, B.Sc.

Thesis to acquire the degree ofMaster of Information Science

Thesisto acquire the degree of

Master of Information Science

Interface InsuredDefining User Interface Design Patterns in the Insurance Sector

A.D.G. van Helbergen, B.Sc.

August 2009

Supervisors

prof. dr. G.C. van der Veerdr. M. van Welie

Vrije Universiteit Quinity B.V.Faculty of Sciences – Department of Computer Science UtrechtInformation Science – Multimedia and Culture .Amsterdam

Interface InsuredDefining User Interface Design Patterns in the Insurance Sector

Thesis submitted in partial fulfillment of the requirements of the degree ofMaster of Information Science

Author: A.D.G. van Helbergen, B.Sc.Studentnumber: 1275070E-mail: [email protected]

Coursecode: 400284, 30 ects

Vrije UniversiteitFaculty of SciencesDepartment of Computer ScienceInformation ScienceMultimedia and CultureDe Boelelaan 10811081 HV Amsterdam

Internal SupervisorsFirst supervisor: prof. dr. G.C. van der Veer [email protected]

Second supervisor: dr. M. van Welie [email protected]

Quinity B.V.Maliebaan 503581 CS Utrecht

External SupervisorsDaily supervisor: ir. M.P.H. Vossen [email protected]

General supervisor: drs. J. Snijders [email protected]

Management supervisor: drs. R.W. Guitink [email protected]

The complete version of this document contains confidential appendixes, which are not availablein the public version. These appendixes may be requested via the Quinity office which can befound at http://www.quinity.com.

mailto:[email protected]






http://www.quinity.com

Summary

In this day and age the need for User-Centred Design is growing more essential for an appli-cation to be successful. Software Engineers are generally not schooled in User-Centred Designor Human Computer Interaction techniques and they need guidance in creating User Interfaces.This guidance can be accomplished in the form of patterns.

Patterns are a structural way to describe a proven solution to a recurring design problem. Theycan aid designers in their decision making process. The use of patterns are manifold. Primarilythey enable the reuse of solutions and prevent designers from reinventing the wheel. Secondly,patterns help cut down development costs, -time and -errors because of this. Patterns can befound in everywhere and during this research we focussed on patterns in the insurance sector.

Insurance is a means for people to secure their wealth and property against unforeseen events.It is defined by a contract, or policy, in which an agreement is made that a premium is paidfor the possibility that a remission is paid in return, if and when an uncertain event occurs.Insurance policies can become very complicated and their administration even more so. Insur-ance companies have to deliver their services to many different parties that are involved in theinsurance process. They are therefore eager to relocate their transactions to an online systemand automate as much of it as possible.

The goals of this research were to formalise a method for extracting User Interface Designpatterns and finding and evaluating these in online insurance applications. This is interestingbecause the field of User Interface Design patterns is still young and there are still many patternsto document. Moreover the world of insurance is usually quite closed-off because companies arevery protective of their trade secrets. Because of this, not much is known about insurance soft-ware implementations as most of them are custom-made.

We accomplished the above by formulating a pattern extraction method and using an existingsoftware engineering method called DUTCH, which we adapted to our needs, to evaluate threeinsurance software modules. By comparing certain task areas in the modules to other softwarewith similar task descriptions, we extracted patterns for these tasks areas. We then createdprototypes of these patterns and evaluated them against the original software modules to see ifour patterns had increased the usability of the module.

The research taught us the DUTCH is quite an elaborate method which tends to steer us in thedirection functional analysis instead of interface analysis. Furthermore, this research deliveredus with five new patterns: Incremental Search, Unified Edit, Calculator Tool, Power Text Editand Leveled Search. We evaluated the first three of these and received positive results.

i

Acknowledgements

The writing this thesis has been a long journey. The path I have followed has taken quite a fewsharp turns along the way and, at times, has led me to crossroads and steep climbs that havemade me feel lost and hopeless. I could not have navigated this path alone and therefore I wouldlike to thank the people who helped me read the map.

First and foremost, I would like to thank Mark Vossen and Jeroen Snijders, my external su-pervisors at Quinity, for their selfless dedication to my cause. Their input has been invaluable tomy success and the quality of this research would not have been as high without them. A specialacknowledgement is due for Evert-Jan Oppelaar for his interest and extra input and words ofencouragement. A general thank you goes out to the whole Quinity firm for their support andwarm hospitality. Sebastiaan, Eric and Arnold, thank you for the good times!

Secondly, I would like to thank Gerrit van der Veer and Martijn van Welie, my internal su-pervisors, for providing me with the possibility to do this research under their wing. Gerrit andMartijn are both big players in the HCI scene and working with them has been an honour anda great learning experience. I hope that the patterns resulting from this project will be a usefuladdition to Martijn’s collection.

I would like to thank my parents for being the rock solid foundation of my life that they are.Thank you for supporting me throughout my whole student career, where the choices I havemade would not always have been your own. Special appreciation goes to my father who wasable to give me the paternal boot once in a while.

Last but not least, I would like to thank my late girlfriend, Juliette van Baal, for joining me onmy path the past three years and providing me with her guidance, her knowledge and especiallyher comfort. As the paths of peoples’ life-journey often do, they split up, leading in different di-rections. I hope that that our paths will not stray too far and that they may cross again someday.

— Go big, or go home —

Allard

iii

Contents

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iAcknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iiTable of contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ivList of figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiiList of tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xAcronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii

1 Introduction 11.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Thesis Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2.2 Relevance to the Master Information Science Curriculum . . . . . . . . . 2

1.3 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Research Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4.1 Formalising a Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4.2 Analysing Insurance Software . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.5 Thesis Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 On HCI, Software Engineering and Patterns 52.1 Human Computer Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Software Engineering Lifecycle Models . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3.1 Waterfalls, Prototyping and Incremental Development . . . . . . . . . . . 72.3.2 RAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3.3 Spiral Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3.4 DUTCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4.1 Performance Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4.2 Issues-Based Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4.3 Self-Reported Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4.4 Other Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5 Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.5.1 Pattern History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.5.2 Anti-Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.5.3 Pattern types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.5.4 User Interface Design Patterns . . . . . . . . . . . . . . . . . . . . . . . . 162.5.5 Guidelines versus Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.5.6 Writing Patterns and Pattern Structure . . . . . . . . . . . . . . . . . . . 172.5.7 Patterns Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 On Insurance and Insurance Software 213.1 What is Insurance? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.1 The Principles of Insurance . . . . . . . . . . . . . . . . . . . . . . . . . . 21

v

Contents

3.1.2 The Premium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.1.3 Distribution of the Products . . . . . . . . . . . . . . . . . . . . . . . . . 223.1.4 The Market Targetgroup . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2 Insurance Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2.1 User groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2.2 The Future of Insurance Software . . . . . . . . . . . . . . . . . . . . . . . 253.2.3 Quinity Insurance Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2.4 Other Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4 Method 334.1 Our Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1.1 Software Engineering Versus Pattern Engineering . . . . . . . . . . . . . . 334.1.2 Where We Looked for Patterns . . . . . . . . . . . . . . . . . . . . . . . . 344.1.3 How to Extract and Evaluate Patterns . . . . . . . . . . . . . . . . . . . . 35

4.2 The Generic Research Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.2.1 Combining DUTCH with Pattern Engineering . . . . . . . . . . . . . . . 374.2.2 A Single Cycle through Altered DUTCH . . . . . . . . . . . . . . . . . . . 37

4.3 Application of the Research Method . . . . . . . . . . . . . . . . . . . . . . . . . 404.3.1 A Description of our Implementation . . . . . . . . . . . . . . . . . . . . . 404.3.2 What we did not measure . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.3.3 Constraints of the Test Group and Test Schedule . . . . . . . . . . . . . . 41

5 The Results of the Case Studies 435.1 General elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.1.1 User profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.1.2 Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.1.3 Case Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.1.4 Collecting Issues in Task Model 1 . . . . . . . . . . . . . . . . . . . . . . . 45

5.2 Reviewed New Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.2.1 Incremental Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.2.2 Unified Edit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.2.3 Calculator Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.3 Non-Reviewed New Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.3.1 Power Text Edit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.3.2 Levelled Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.4 Overview of Applicable Existing Patterns . . . . . . . . . . . . . . . . . . . . . . 51

6 The New Patterns 556.1 Incremental Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556.2 Unified Edit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566.3 Calculator Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586.4 Power Text Edit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596.5 Levelled Search Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7 Discussion and Conclusion 637.1 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

7.1.1 DUTCH in Combination with Pattern Engineering . . . . . . . . . . . . . 637.1.2 Our Initial Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637.1.3 The Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

7.2 Answers to the Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . . 65

vi

Contents

7.3 Open Issues and Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Bibliography 67

A Surveys 73A.1 User Profile Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73A.2 User Profile Survey Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76A.3 USE Questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77A.4 USE Questionnaire Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79A.5 After-Scenario Questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80A.6 After-Scenario Questionnaire Results . . . . . . . . . . . . . . . . . . . . . . . . . 81

B Interviews 83B.1 Interview Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83B.2 Interview 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84B.3 Interview 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86B.4 Interview 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89B.5 Interview 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90B.6 Interview 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93B.7 Interview 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

C Use-case Scenarios 99C.1 Scenarios for Task Model 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

C.1.1 Forms Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99C.1.2 Policy Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99C.1.3 Claims Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

C.2 Scenarios for Pattern Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 100C.2.1 Incremental Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100C.2.2 Unified Edit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101C.2.3 Calculator Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

D Issues 103D.1 Scenario-based Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

E Performance Metric Results 107E.1 Incremental Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107E.2 Unified Edit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108E.3 Calculator Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

F The Initial Method 111F.1 Why a different plan? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111F.2 The Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111F.3 The Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

vii

List of Figures

1.1 RIA screenshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1 Waterfall Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Prototyping Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Spiral Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4 DUTCH Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5 Pattern Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1 QIS position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2 QIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.3 Elvia Policy System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.4 Unigarant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.5 Coda 2go . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.6 Siebel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.7 SAP ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.8 Norma EMD/EPD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.9 AMC Zorg Dekstop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1 Generic Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.2 Specific Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.3 DUTCH altered . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.1 Prototype Incremental Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.2 Prototype Unified Edit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.3 Prototype Calculator Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

A.1 USE Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79A.2 ASQ Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

E.1 Time-on-task Incremental Search . . . . . . . . . . . . . . . . . . . . . . . . . . . 107E.2 Clicks Incremental Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107E.3 Time-on-task Unified Edit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108E.4 Clicks Unified Edit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108E.5 Clicks Unified Edit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108E.6 Task Success Calculator Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109E.7 Time-on-task Calculator Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109E.8 Clicks Calculator Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109E.9 Clicks Calculator Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

ix

List of Tables

2.1 Typical elements found in a pattern form . . . . . . . . . . . . . . . . . . . . . . 18

3.1 The risks of a consumer and the respective policies . . . . . . . . . . . . . . . . . 233.2 The risks of a business and the respective policies . . . . . . . . . . . . . . . . . . 23

5.1 Non-implemented Existing Patterns . . . . . . . . . . . . . . . . . . . . . . . . . 525.2 Implemented Existing Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

A.1 User Profile Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

D.1 Scenario Issues Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103D.2 Scenario Issues Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104D.3 Scenario Issues Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

xi

Acronyms

ASQ After-Scenario Questionnaire 12, 13, 36

CSUQ Computer System Usability Questionnaire 13

DUTCH Design of User Tasks from Concepts to Handles 3, 10, 11,33–35, 57

GUI Graphical User Interface 1, 5

HCI Human Computer Interaction 1–3, 5,10, 14, 16

PDS Product Definition System 26

PT prototype 33–37,57, 58

QFS Quinity Forms System 26

QIS Quinity Insurance Solution 26, 28

QUIS Questionnaire for User Satisfaction 13

RAD Rapid Application Development 9

RE Requirements Engineering 6, 7, 9, 35

RIA Rich Internet Application 1, 2

SE Software Engineering 3, 5–7,10, 14

xiii

Acronyms

SUMI Software Usability Measurement Inventory 13

TM task model 33–35,57, 58

UCD user centred design 1

UI user interface 16, 17

UID user interface design 1–3, 6,12, 15–17, 19,33, 35

USE Usefulness, Satisfaction and Ease of Use 13, 57, 58

UVM user virtual machine 35

xiv

1 Introduction

In this chapter we introduce our research by giving an overview of its context in Section 1.1and an overview of our motivations in Section 1.2, for this research. We introduce our researchquestions in Section 1.3 describe our research approach in Section 1.4. We finish off this chapterby clarifying the over all structure of this thesis in 1.5.

1.1 Context

With user tasks of software applications growing evermore complex and the emergence of RichInternet Applications (RIAs) (Figure 1.1), which aim to cover similar ground to desktop ap-plication software online (Garrett, 2005), well thought-out user centred design (UCD) becomesevermore essential to the commercial success of an application. The same growth of the need ofUCD can be observed in the insurance market. The growing use of online shopping has causedconsumers to expect the acquisition of policies, handling of claims and mutation policies to bepossible via online applications. According to NIBE-SVV (2006), the Dutch insurance marketexpects online sales of bulk insurance policies to have a market share of eighty percent by 2010.

Software engineers are generally not schooled in UCD or Human Computer Interaction (HCI)techniques and to satisfy software developers’ need for explicit guidance and advice in the design-ing of Graphical User Interfaces (GUIs), HCI professionals have started capturing user interfacedesign (UID) principles in patterns (Norman and Draper, 1986). Following this, collections ofthese patterns have arisen (Van Welie, 2009; Tidwell, 2005) and discussions about UID patternlanguages have commenced (Schummer et al., 2004).

UID patterns is an evolving research area. The approach of UID patterns was already proposedby Norman and Draper in 1986 but there is still discussion as to the ideal form and use of UIDpatterns (Van Welie et al., 2000; Richter, 2003). The above makes it difficult for anyone to definea complete set of patterns (not that anyone claims to have done so) and there are still patternsout there to be discovered.

1.2 Thesis Background

This thesis is written as a report of a 6-month research at Quinity1, an IT-company that makesweb-based software solutions for business administration in the insurance and banking sector.

1.2.1 Objectives

The goal of this research was twofold.

1. Formalise a method for UID pattern identification

2. Identify UID patterns for web based applications in the insurance market

1http://www.quinity.com

1

http://www.quinity.com

1 Introduction

(a) Hotmail (b) Gmail

(c) YouTube (d) Google Maps

Figure 1.1: Examples of RIAs: Hotmail and Gmail, two well-known online email clients; YouTube, avideo sharing community site; and Google Maps, an interactive map with satellite images

Making use of our own method proposed for the first goal, existing insurance software wasanalysed to generate UID patterns. prototype (PT) applications were created that incorporatedthe newly found patterns. These PTs were then be compared to the existing applications, toestablish the patterns’ worth.

1.2.2 Relevance to the Master Information Science Curriculum

This thesis is a result of a Master Project, a graduation project which acts as the conclusion ofthe study of Information Sciences at the Vrije Universiteit Amsterdam.

“Information Sciences [. . . ] focus on theory development and best practices of ef-fective creation, structuring, processing, communication and sharing of informationand knowledge using ICT.” (Vrije Universiteit, 2008)

This thesis provides a relevant contribution to the domain of Information Sciences because itincreases the insight into the HCI aspects of a specific field of software applications to whichpeople do not often have access and of which many designers have little knowledge.

1.3 Research Questions

With the goals of the research in mind, we are able to define the following research questions.

1. Which patterns are relevant to the insurance market?

2. What forces are applicable to these patterns?

2

1.4 Research Approach

3. When is pattern A applicable and when pattern B?

4. Is there such a thing as The Insurance Pattern?

We performed this research with these questions in mind and aimed to be able to answer themafter conclusion of this research.

1.4 Research Approach

The following provides an overview of the research method. A more detailed explanation of thecomplete method is given in chapter 4.

1.4.1 Formalising a Method

To accomplish the first research goal, formalising a method for UID pattern identification, weused the Design of User Tasks from Concepts to Handles (DUTCH) method described by Van derVeer and Van Welie as an evaluation method for our patterns. We chose this method becausewith DUTCH, the design of systems. . .

“. . . is driven by an extensive task analysis followed by structured design and iterativeevaluation using usability criteria.” (Van der Veer and Van Welie, 2003)

Moreover, the method’s iterative nature made it suitable for the implementation of the proof-of-concept PT. Yet, as DUTCH is an engineering method and not a pattern recognition method,it was not applicable in its pure form. We had to extend the method to fit our needs for identifyingUID patterns by adding the process of identifying patterns to the method cycle.

1.4.2 Analysing Insurance Software

To accomplish the second goal, the identification of UID patterns, we evaluated and analysedthree existing insurance software cases:

1. Forms Administration System

2. Policy Requisition System

3. Claims Administration System

We then sought out software cases that had comparable functional task descriptions andanalysed their solutions. From the combination of these analyses, we deduced generic UIDpatterns, which we then reimplemented into the above mentioned cases. The evaluation of thesePTs provided a measure for the quality of our deduced pattern.

1.5 Thesis Structure

The thesis will have the following structure. In Chapter 2 we describe HCI and Software Engi-neering methods and we introduce the concept of design patterns, their history and the currentstate of affairs in this research domain to give a scientific background and to place this researchin a scientific context. In Chapter 3 we define the different aspects of the insurance and the insur-ance sector, describe characteristics of insurance software and compare contemporary insurance-and general administrative software packages. This serves as general knowledge, to place the

3

1 Introduction

software and patterns described in this thesis in a physical context. Then, in Chapter 4 weexplain the research method of this project in more detail. We examine existing patterns, newpatterns and the results of the prototype evaluation of each case consecutively in Chapter 5.After this, in Chapter 6, we reveal a catalogue of the new patterns we discovered. We concludethis thesis in Chapter 7, where we discuss the strong and weak points of this research and finishby summarising this research and its results.

4

2 On HCI, Software Engineering andPatterns

To perform this research it was necessary to collect background information from existing lit-erature about user interfaces, engineering methods and patterns. To this purpose, this chapterserves as an introduction to Human Computer Interaction- and Software Engineering concepts.We start with definitions of HCI itself in Section 2.1 and follow with definitions of usability inSection 2.2 to give a general outline of the field in which this research was performed. As back-ground for the engineering of patterns we look at different software engineering lifecycle modelsin Section 2.3. As background information for our evaluation techniques, we look at differenttypes of metrics in Section 2.4 and last but not least we give a summary of existing patternliterature to conclude the defining of the scientific context of this research in Section 2.5. Theorder of the sections is set up so as to go from broad knowledge to specific details of contextknowledge.

2.1 Human Computer Interaction

“Human-computer interaction is a discipline concerned with the design, evaluationand implementation of interactive computing systems for human use and with thestudy of major phenomena surrounding them.” (Hewett et al., 1996)

Although there is no official definition for HCI, the definition above provided by the CurriculumDevelopment Group of ACM SIGHCHI1 covers the ground well. In general, HCI is seen as thestudy of computers (computer machinery), people (the users) and the interaction betweens thetwo.

This interaction takes place at the interface of the machine which can encompass both hard-and software. On the software side, a part of the field concentrates on the creation and designof GUIs, attempting to increase their usability.

2.2 Usability

Just as there are many definitions for HCI, there are many different definitions for usability. TheInternational Standards Organisation defines it as

“the extent to which a product can be used by specified users to achieve specifiedgoals with effectiveness, efficiency, and satisfaction in a specified context of use.”(International Standards Organisation, 1998)

The Usability Professionals Association takes a more production-oriented approach and definesusability as

1Association of Computing Machinery Special Interest Group Computer Human Interaction

5

2 On HCI, Software Engineering and Patterns

“an approach to product development that incorporates direct user feedbackthroughout the development cycle in order to reduce costs and create products andtools that meet user needs.” (Usability Professionals Association, 2009a)

Arguably one of the most wide-spread definitions is that of Krug, which states that

“usability really just means that making sure that something works well: that aperson of average (or even below average) ability and experience can use the thing -whether it’s a Web site, a fighter jet, or a revolving door - for its intended purposewithout getting hopelessly frustrated.” (Krug, 2000)

There are many more definitions around, some of which can be found at (Usability ProfessionalsAssociation, 2009b). All these definitions refer to the same following notions (Tullis and Albert,2008).

∙ A user is involved.

∙ That user is doing something.

∙ That user is doing something with a product, system or other thing.

In some literature, a distinction is made between usability and user experience. Usability beingthe ability of the user to complete a task as easily as possible and user experience also taking thewhole experience (feelings, thoughts and perceptions that result of the whole interaction) intoaccount (Tullis and Albert, 2008). Our view is that usability is a subset of user experience andthat usability contributes to user experience but not necessarily the other way around. Duringthis document we will treat usability as such.

2.3 Software Engineering Lifecycle Models

As we need a method to create patterns for UID, which is a part of Software Engineering (SE),we will take a short look at some of the software engineering methods that exist to see if thereis one that is applicable to our situation.

When developing software it is pertinent to use a method with clearly defined phases. This ispreferable over working in a random or ad hoc fashion in which there is little control or monitoringof the quality and budget used of the project. The main elements that every SE method consistsof are (van Vliet, 2000):

1. Requirements Engineering (RE)

2. Design

3. Implementation

4. Testing

5. Maintenance

Simply executing these phases in order is too crude a way of working to produce qualitysoftware. Therefore, when actually creating software, many companies tend to use more sophis-ticated methods with extra cycles, feedback loops and quality control. We will discuss somethese further evolved methods now.

6


Figure 2.1: The waterfall model; adapted from (van Vliet, 2000, p. 50)

2.3.1 Waterfalls, Prototyping and Incremental Development

Although clearly phased approaches to SE with iteration and feedback were already in use sincethe 1960s, according to van Vliet, the waterfall model is generally attributed to Royce (1970).The waterfall model is the most basic SE method and consists of the elements mentioned abovelinked in succession. These phases are combined with verification and validation of the qualityof the products between each phase (see Figure 2.1).

In spite of verification and validation methods at the end of each phase, it is difficult to maintaina sufficiently high amount of quality in-between phases in practice. Furthermore unclear orundefined requirements in early phases warrant for an error-prone product later in a later phase.Due to these two reasons, the principal of prototyping was introduced. In prototyping, (part of)the phases are executed multiple times (see Figure 2.2). This is done to minimise the effort neededto recover from errors found in later phases. Building prototypes with incomplete functionalityenables the engineers to clarify unclear requirements of the end user and to implement thisfunctionality correctly in a later version of the product. In this fashion, prototyping becomes atool for Requirements Engineering.

Another option for work towards a final product without having to create the whole productin one go, is to work with iterations and create functionality incrementally. This model is called

7


Figure 2.2: The prototyping model; adapted from (van Vliet, 2000, p. 53)

8


Figure 2.3: The spiral model; original source (Boehm, 1988), adapted from (van Vliet, 2000, p. 63)

incremental development. For each iteration the waterfall model is employed and the softwaregradually grows into the final product. “Developing software in this way avoids the ‘Big Bang’effect.” (van Vliet, 2000)

2.3.2 RAD

Rapid Application Development (RAD) combines elements from iterative models, such as userinvolvement and prototyping. On top of this it adds an extra element, “[. . . ] it employs thenotion of a time box, a fixed time frame within which activities are done.” (van Vliet, 2000)This time frame is immovable and if making the deadline is in jeopardy, then functionality issacrificed.

2.3.3 Spiral Model

To encompass all previous models Boehm introduced the spiral model (Boehm, 1988). Every(sub)problem that arises when engineering software can be solved with a certain amount ofiterations around the spiral, including the RE- and maintenance cycles. Figure 2.3 shows thespiral and its consecutive parts.

9


Figure 2.4: The DUTCH method; adapted from (Van der Veer and Van Welie, 2003; van Vliet, 2000, p.556)

2.3.4 DUTCH

As each software project has its own characteristics and goals, different SE methods will alwaysbe in use. To accomplish specific objectives within the HCI domain the DUTCH method wasdeveloped by Van der Veer and Van Welie (see Figure 2.4). This iterative method has a strongfocus on the user of the system under development. The method has four phases which areiterated through until the software is finished.

Evaluating the current situation The current situation (documents, current software and taskanalysis) is used to make a descriptive task model

Envisioning a future situation The descriptive model is used to define a prescriptive task modelwhich solves the problems of the current situation.

Specifying the system The descriptive model is used to define the functionality of the system.

Evaluation Every phase is constantly evaluated together with users.

We believed this to be a good method to use as a starting point for defining patterns in ourresearch. Primarily, because of its user-centered nature and secondarily because of its iterative

10

2.4 Metrics

nature. We will elaborate on DUTCH and how we implemented it in this research in Chapter 4.

2.4 Metrics

To measure how usable a product is, we have to measure its usability in some form. To accomplishthis we can measure different metrics while the user interacts with the product. We will nowdiscuss different metrics and how we can measure them.

2.4.1 Performance Metrics

Performance metrics measure user behaviours during scenarios and tasks. They measure specificactions and behaviour of the user during interaction with the product such as mouse clicks, timeto complete a task and and are the most objective type of metrics as they can be clocked, countedor calculated. The following types of performance metrics exist (Tullis and Albert, 2008).

Task Success Success measures whether a user is able to complete a task or not. This metrichas two forms, binary success and levels of success. Binary success is the simplest wayto measure success, it has two possible outputs ‘success’ or ‘failure’. Levels of success aremore intricate allowing for partial degrees of success which can be defined as seen fit.

Time-on-Task Also called task-time, time-on-task measures how much time it took the user tocomplete the task. This is a very effective measure for the efficiency of a product becausethe amount of time it takes a user to accomplish a task says a lot about the usability ofthe product.

Errors Errors are the amount of mistakes a user makes while performing the task. Basically theyare incorrect actions which defer the user from completing the task. An error is often anindication of an underlying usability issue.

Efficiency Efficiency is a measure of the amount of effort a user has to put into a task to completeit. This can be measured by the amount of actions a user has to perform to complete atask. These actions can have many shapes or forms, such as the amount of clicks or buttonpresses.

Learnability Learnability is a measure of how performance changes over time. It can be measuredby looking at the time and effort needed by the user to become proficient with the product.

Performance metrics are not only useful to see how well users are using the product but theyare also very useful to estimate the magnitude of usability issues. If there are many users whoencounter a certain usability problem it is more likely to be important than if only one userencounters it. We used performance metrics as part of our evaluation process. Which specificmetrics we used and why is discussed in Section 4.3.

2.4.2 Issues-Based Metrics

Identifying usability issues and improving product design accordingly provides a lot of valueto a product and this process is seen as the cornerstone of the usability profession (Tullis andAlbert, 2008). Issues are generally seen as something purely qualitative, where an issue consistsof a description of problem perceived by some users during an evaluation test and possiblyrecommendations on how to fix this problem. But using metrics to measure issues, adds value tothe product without slowing down the process. the following metrics can be added to usabilityissues.

11


Frequency How often an issue arises or how many users perceived it during an evaluation testis measured with frequency.

Severity This is a rating which can be given to an issue to determine how important the issueis, aiding in prioritising issues.

We believe usability issues are a very important part of usability evaluation and incorporatedidentifying them into our evaluation process.

2.4.3 Self-Reported Metrics

When measuring satisfaction, a part of usability, one of the most obvious ways to measure it iswith self-reported metrics. Otherwise known as subjective data or preference data, the elicitationof this data is used to inform about the user’s experiences and their perception of the system.A multitude of techniques are available to collect this data in the form of questionnaires anddifferent rating types. These elicitation techniques often use survey type questioning with Likert-type scales (Likert, 1932), closed- and open-questions. An overview of the different techniques isgiven below (Tullis and Albert, 2008).

Post-task Ratings

The first type of rating one can collect is that associated with tasks. These ratings can giveinsight into which tasks users found difficult and can point to parts of the system which shouldbe improved (or left alone).

Ease of Use The user is asked to perform a variety of tasks and to rate how easy or difficulta task is after having performed each one. This provides a rough measure of perceivedusability.

After-Scenario Questionnaire Developed by Lewis (1991), the After-Scenario Questionnaire(ASQ) poses three rating scales each touching on different aspects of usability: effec-tiveness, efficiency and satisfaction.

Expectation Measure This method proposed by Albert and Dixon (2003) rates the expecteddifficulty of tasks as well as the perceived difficulty. Comparing the average expectationratings with the average experience ratings provides special insight into which tasks requirepriority in optimising.

Usability Magnitude Estimation A totally different approach without Likert scales is proposedby McGee (2003). In this approach users assign usability values to a certain design,possibly in combination with reference ’good’ and ’bad’ designs, and then assign relativevalues to other proposed designs, building up their own scale as they go along.

As stated, post-task ratings are extremely useful for evaluating the usability of product for acertain task. As we evaluated UID patterns for specific task during this research we incorporatedthese ratings in our study. ASQ was our rating of choice because of its simplicity and that itprovided multiple axes which we believed to be insightful.

Post-session Ratings

Another type of rating is the the overall measure of perceived usability after their whole sessionwith the product. This can give a useful overall usability rating of the product, especially if thesame technique is used more than once over a period of time.

12

2.4 Metrics

Aggregated Individual Task Ratings This is the simplest technique and consists of taking anaverage of self-reported data across the different tasks.

System Usability Scale This scale was developed by Brooke (1996) and is a rating consisting often statements together with a 5-point Likert scale. The statements are both positively andnegatively worded. The score is calculated, via a special formula, to produce a combinedusability rating of the whole system (in contrast to being divided into categories).

Computer System Usability Questionnaire From the same author as the ASQ technique, theComputer System Usability Questionnaire (CSUQ) contains 19 statements with 7-pointLikert scales and an N/A option (Lewis, 1995). All of the statements in CSUQ are wordedpositively and the result can be viewed in four main categories: System Usefulness, Infor-mation Quality, Interface Quality and Overall Satisfaction.

Questionnaire for User Interface Satisfaction The Questionnaire for User Satisfaction (QUIS)has 27 ratings Chin et al. (1988) in five categories: Overall Reaction, Screen, Terminol-ogy/System Information, Learning and System Capabilities. The first six scales are oppo-site words without statements (e.gTerrible/Wonderful), the rest are ratings on a 10-pointscale with different anchors depending on the question.

Usefulness, Satisfaction and Ease of Use Questionnaire The Usefulness, Satisfaction and Easeof Use (USE) questionnaire was developed by Lund (2001) and has 30 ratings scales dividedinto four categories: Usefulness, Satisfaction, Ease of Use and Ease of Learning. Each rat-ing is a positive statement with a 7-point Likert scale. Initially the different statementshave a weight coupled to them, but later factor analysis showed that they were weightedso close together that they could be treated as equal (Lund, 2009).

Software Usability Measurement Inventory A well-known commercial method is known as Soft-ware Usability Measurement Inventory (SUMI). This rating was written by Porteous et al.(1993). It has 50 statements, positive and negative, with a simple Disagree/Neutral/Agreescale. What is interesting about this rating is that because it is a de facto industry stan-dard and has been used to evaluate many different products, comparisons can be easilymade to other products.

Product Reaction Cards A whole other system which steps away from the survey principle is theuse of product reaction cards as developed by Benedeck and Miner (2002). This methodconsists of 118 cards with both positive and negative adjectives on them. The participantschoose the cards they think describe the system. Although this method is best used toelicit commentary, it can also be used in a quantitative manner by counting the amountof positive and negative cards chosen.

We did not incorporate the use of this rating in our research because we were not interestedin the usability of the system as a whole but only of the usability of the specific patterns. Wehowever did provide the above information because we used the USE questionnaire in our initialmethod which abandoned later during the study. Details of this can be found in Appendix F.

2.4.4 Other Metrics

There are even more metrics which can be used to measure the usability of a product. They arelisted below.

13


Behavioural Metrics During a usability test users perform many actions which are not directlyrelated to the task at hand. This metric measures these actions. Behavioural metricsconsist of overt behaviours such as laughing, groaning, tapping their fingers or lookingbored. One of the best known behavioural metrics is eye-tracking, which is well-knownfrom its use in advertising.

Physiological Metrics Physiological behaviours consist of covert events a user displays duringusability testing. These can be emotional statuses such as frustration and stress or physicalmeasurements such as heart rate and pupillary response.

Combined Metrics The following two metrics are not a pure measurement by themselves. Com-bined metrics are created by combining multiple base metrics (any of the above) to derivea new score which to compare to other measurements.

Comparative Metrics This metrics is found by comparing any usability results to expert or idealresult data and calculating the relative position of the product.

We did not incorporate these methods into our study for various reasons. Behavioural andphysiological metrics require special equipment to record and are very time consuming to mea-sure. Taking the resources for this research into account these metrics were not an option. Wedid not have any expert or ideal data to create comparative data with and we did not see anyuse for combined metrics in this specific study which is why we left these out of the study aswell.

2.5 Patterns

“A Design pattern is a structured textual and graphical description of a provensolution to a recurring design problem.” (Borchers, 2001, p. 7)

Patterns are a structural way to aid designers and engineers in their decision making process.Patterns describe generic solutions to generic problems. The user of a pattern is expected tohave (some) knowledge of the domain, he still has to decide when and where to use a certainpattern.

Therefore the word “proven” in the case of the above definition implies that the solutionworks for the problem but is not necessarily the best solution given the engineer’s context.In conjunction, a single problem can have multiple solutions depending on this given context(Tidwell, 2006; Borchers, 2001).

The use of patterns is manifold, not only do they enable the reuse of solutions and preventdesigners from reinventing the wheel but they help cut down development costs, -time and -errorsbecause of this. Moreover, patterns improve communication about the development project.First of all the create an abstraction level between the problem and the solution, making thesolution more comprehensible because lower layers are concealed. Second, it enables simplercommunication between developers themselves because they can talk about generic solutionswhich no longer need to be explained to each other (Snijders, 2004).

We believe patterns to be very useful tools in the design- and SE process. Patterns haveproven their use in technical terrains and are now being explored for other terrains, such HCI.We believe this exploration to be a positive venture and wish to add to the pattern knowledgewith this research.

In the following sections we will look at patterns a little more closely. First we will give a shorthistory of patterns as background information. Then we will describe the anti-pattern, another

14

2.5 Patterns

form of pattern. Next, ew describe different types of patterns to create a context in which toplace the UID pattern of which we will then dive into more detail. As the use UID patternsare a relatively recent development we will describe its predecessor: guidelines. After this we gointo some depth on how to write patterns. We finish with a view on the current state of patternlanguages and existing pattern collections.

2.5.1 Pattern History

The oldest form of patterns dates back to 1977, when Alexander, Ishikawa, Silverstein, Jacobson,Fiksdahl-King, and Angel defined many patterns for construction, architecture and community-based design (Alexander et al., 1977). Alexander found that it was possible to create “qualitywithout a name” using available architectural and constructional knowledge and bound thisknowledge into a total of 253 patterns. These patterns were all reviewed by other architects andtested in the real world as part of their validation.

Patterns were introduced into software engineering by the Gang of Four2 in 1995 with theirbook Design Patterns: Elements of Reusable Object-Oriented Software. The design patternsmovement is “probably the most important step forward in object-oriented design” (Eckel, 2009).Gamma et al. described 27 technical design patterns in their book (Gamma et al., 1995) andduring the years more patterns have been added to this collection.

2.5.2 Anti-Patterns

Adjacent to patterns, which provide a generic solution to generic problems, there are anti-patterns, which describe generic non-solutions or failures (Brown, 1999). Anti-patterns describecommon pitfalls and misconceptions, explaining why a solution to a generic problem which seemscorrect, actually is not. On the subject of failed software Brown claims the following.

“These repeated failures, or “negative solutions”, are highly valuable, however inthat they provide us with useful knowledge of what does not work, and throughstudy: why. Such study, in the vernacular of Design Patterns can be classified asthe study of Anti-Patterns.”(Brown et al., 1998)

Recent research has discouraged the use of anti-patterns. It is claimed that they cause pitfallsin the cognitive process because they focus on what goes wrong instead of right. Van Biljon,Kotze, Renaud, McGee, and Sheffah (2004) state that the anti-pattern should not be used whenthe positive pattern has not been documented thoroughly and that it is therefore generallyadvised not to use them.

We believe that anti-patterns can be useful in certain situations where patterns have manyvariations. In the process of defining patterns, however, we do not believe anti-patterns tobe constructive because they, as stated above, focus on what goes wrong instead of right andtherefore cloud judgement. We think that we should focus on grasping the ideal form of a patternand then perhaps, once this is defined, come back to describe its pitfalls.

2.5.3 Pattern types

There are many different abstraction layers in which to view software development and manydifferent aspects of software itself that can be taken into consideration. Virtually every layer andaspect has its own methods and best practices recorded in pattern form. Following is list of themost prominent patterns (Snijders, 2004).

2GoF for short

15


Process Patterns These are patterns which define procedures during the lifecycle of applications.These streamline projects and aid standardisation and continuity in the development pro-cess. The lifecycle models in Section 2.3 are examples of process patterns.

Analysis Patterns Developed by Fowler (1996), these patterns define virtual representation ofbusiness concepts for use in information systems. These can be used to map products to avirtual environment. Although many companies make use of this concept, these companiesare rarely aware of this and there is little literature about the pattern type and its use.

Technical Design Patterns Introduced by the GoF, (see Section 2.5.1), these well-known pat-terns describes solutions to technical problems which arise during the development ofsoftware.

User Interface Design Patterns These patterns describe standard and best practices for UID.They record user task flow, dialogue, functionality, organisation of screens, data visualisa-tion and the organisation of graphical elements on the screen.

Functional Patterns These are patterns which describe recurring functional aspects of (domainspecific) applications.

There are also less well-known patterns, such as performance patterns, which merit mentioning.But to discuss each pattern in detail would be outside the scope of this document as each patterntype merits its own research. The only type of pattern which is of interest to us is the UID pattern.We will discuss this pattern type in detail in the next sections.

2.5.4 User Interface Design Patterns

As mentioned above, UID patterns are used to describe everything that is applicable to userinterfaces (UIs). To comprehend exactly what a UID pattern is, it helps to know that they canalso be called Interaction Design Patterns. These patterns are meant to describe all interactionthat takes place at the UI of a machine. These patterns describe, task flow, user-machine dialogueand functionality. Van Welie explains it best, when he states,

“These patterns concern the static structure, the appearance and dynamics be-haviour of the user interface, but not the implementation in terms of coding. Theyinclude the ‘look and feel’of the interface as far as it goes beyond mere style.”(Van Welie, 2001)

The use of UID patterns in HCI was first proposed by Norman and Draper (1986) but did notreally take off until the first pattern collection arose with Tidwell’s Common Ground collection3.

UID patterns are different from standard patterns, as UID patterns are created from a userperspective instead of the designers like technical design patterns are. The problems describedin UID patterns are only indirectly the designers’ problems (Van Duyne et al., 2003; Van Welieand Traetteberg, 2000; Segerstahl and Jokela, 2006). These problems, which the user has, canbe categorised into the following principles (Norman, 1998; Van Welie, 2001).

Visibility The ability to understand something just by looking at it.

Affordance The perceived and actual properties of an object which indicate how it is to be used.

Natural Mapping The creation of a relationship between the task the user wishes to completeand the mechanism to accomplish this.

3Which is now superseded by her Designing Interfaces Collection

16

2.5 Patterns

Constraints The reducing of the number of ways to perform a task or the knowledge neede toperform it, thus making the mechanism simpler.

Conceptual Models The correspondence of the user’s understanding of the system to how itactually works.

Feedback The indication of whether tasks are completed and completed correctly.

Safety The protection of the user against unintended mistakes or irreversible actions.

Flexibility The ability to adapt to a user’s way of working and to change things later on in atask process.

These categories give an indication where to look for issues within software. Although theyare very general we believe it to be useful to take these different views into consideration as theymay enable us to discover solutions which are not obvious at first.

2.5.5 Guidelines versus Patterns

In the past, designers have used guidelines to aid them in the design of UIs. Guidelines havemultiple usability issues. First of all because they describe both dos as well as don’ts. Secondly,it is not defined when a guideline is applicable or when to deviate from it. This choice is left upto the experience and knowledge of the designer who may not be up to the task. Guidelines donot capture the context, forces or rationale applicable to a certain solution.

Patterns are preferred over guidelines because they formulate examples solely of good design.Moreover they are more effective than guidelines because of the structured and generic way inwhich they discuss problems and their solutions (Van Welie et al., 2000). Although UID patternsin turn have their own usability issues with designers (Segerstahl and Jokela, 2006; Seffah andJavahery, 2002), the use of them is still seen as “highly beneficial” (Seffah and Javahery, 2002).The usefulness and effectiveness of patterns has been discussed through the years and extensionshave been also been made to improve them (Van Welie and Traetteberg, 2000; Ahmed andAshraf, 2007).

2.5.6 Writing Patterns and Pattern Structure

There are many different ideas on what written patterns should look like. The basic idea setforth by Alexander is that “Each pattern is a three-part rule, which expresses a relation betweena certain context, a problem, and a solution” (Alexander, 1979, p. 247). The way different partsof a pattern relate to each other is shown in Figure 2.5.

Common aspects of a pattern form are shown in Table 2.1. There are many different forms inwhich patterns can be written, the form of choice depending on the goal at hand. Besides beingnarrative or tabular, different pattern forms can contain other elements, such as forces and forceresolutions. An overview of different pattern forms is given by Fincher (2008).

The actual writing of useful and reusable patterns is seen as a very difficult task by thepattern community. Beck et al. (1996) state that only a certain group of professionals is ableto see patterns as well as describe them correctly. Writing patterns is a group process whichrequires a lot of interactive and iterative reviewing to get right. Some of the best practices havebeen recorded by Meszoras and Doble (1998) in the form of interconnected patterns, a patternlanguage in itself.

As daunting as writing patterns may seem, this research was done to accomplish exactly that.We believed that with an iterative process and user feedback it would be possible to define

17


Figure 2.5: The relationships between different pattern elements; adapted from (Snijders, 2004)

Name A name serves to uniquely identify a pattern, but is alsooften used to browse through a pattern collection.

Problem The problem is a very short description of what the typ-ical problem is that the pattern solves.It is often a singleline, with just the bare essentials of the problem, since thestructure of the pattern has possibilities to elaborate onthe problem in other sections.

Context The context says something about when the given solu-tion applies, and sometimes (when considered necessary)it states when the solution does not apply. This is the partwhere a ‘situation’ is being sketched, that is exemplary forthis pattern to work.

Solution The solution is a short description of how to solve thedesign problem at hand in the given context.

Rationale The rationale is often a more in depth answer to the ques-tion ‘why’ the solution works in that context. This is thepart of the pattern someone can actually gain some de-sign knowledge by understanding the reasons behind thesolution. Applying this knowledge in another context oron another problem can lead to new design ideas.

Example Patterns are ‘proven solutions’ to a ‘recurring design prob-lem’, therefore examples of the solution should be easy tofind. The example-section often contains images to clarifywhat is meant.

Table 2.1: Typical elements found in a pattern form

18

2.5 Patterns

candidate patterns which have a basis of reliability and reusability due to their reviewing froma test group. We will expand more on this in Chapter 4.

2.5.7 Patterns Languages

The patterns provided by Alexander et al. (1977) were structured to create a language that relatedall the patterns together. A pattern language is an interconnected set of patterns organised andstructured in a meaningful way from the point of view of the user of the set (Van Welie andVan der Veer, 2003). Languages have the structure of a network, higher level patterns aresupported by lower level patterns and neighbouring or connected patterns round off the problemat hand encompassing the total project (Jackson, 2008). At the moment it is difficult to write aUID pattern language as there is still too much discussion about the ideal form of the patternsthemselves. At the moment there are calls from the designer community for standardisation ofpattern forms (Stapleton, 2009).

On a less structured level we have pattern collections or catalogues. These are basically anyset of patterns, often with some form of categorisation. In practice collections contain patternscorresponding to a certain domain.

Since the Common Ground pattern collection (Tidwell, 1999) many collections have emerged,some in books such as (Borchers, 2001) and (Kunert, 2009), some in books with correspondingsupport websites (Tidwell, 2006, 2005) and (Van Duyne et al., 2003, 2006), but most of themonline (Yahoo!, 2009; Van Welie, 2009; Toxboe, 2009). There are many specific collections whichrefer to small domains or specific categories of interaction, such as information display pat-terns (Behrens, 2008) and game interaction patterns (Folmer, 2008). An overview of well-knowncollections can be found at (Erickson, 2009) and (Borchers, 2006)

The relationships between patterns can create different views dynamically for task domainsor problem hierarchies when implemented in interactive tools such as Quince (Infragistics, 2009)or the Visual Design Pattern Wizard (Hennipman, 2008). The richer the relationships are, themore one can speak of a language. With enough interconnections a single pattern may even existin multiple languages. A test was designed by Todd et al. (2004) and administered to existingcollections to determine if these collections could be called a language. The results of this testshowed that there is still much work to be done in this department.

We did not aim to create a pattern language of ‘insurance patterns’ with this research. Thatwould have been too large a task for the resources at hand. However, hopefully the patterns thatwe found can someday be incorporated in an existing language or catalogue, or possibly theycan be expanded to create a language.

19

3 On Insurance and Insurance Software

When studying software for the insurance market it is necessary to get a general impression ofthe product insurance, what it is, how it works and how the companies that provide it work.In Section 3.1 we investigate what insurance is, to inform on what insurance software has to becapable of. We will then outline how the insurance market works as background information forthe context of the software. After this, in Section 3.2, we define the software requirements thatcan be derived from this background information as a basis for later analysis. Finally we take abrief high-level look at the software package we will be testing, as well as comparable insurancepackages and administration software.

3.1 What is Insurance?

During their lives, people build up wealth and property. Concurrently a need arises to securethis wealth against unforeseen events. The principles of insurance are based on this need. Ageneral description of insurance as described by NIBE-SVV (2006)1 is given below.

3.1.1 The Principles of Insurance

Insurance caters to the need for financial security in two ways.

1. By counteracting Financial losses inflicted by damages (e.g. indemnity insurance).

2. By remitting a payment at a certain time in life (e.g. life insurance )

An indemnity insurance that compensates all types of loss that are consequences of an insuredevent. This could be in the form of financial compensation for material losses that occur due toburglary or an accident. Life insurance provides for a need that a person can get a single sumof money or a series of remissions in the event of reaching a certain age or death. Insurances ofthis type are pension plans where the insured person can create a retirement fund to provide forthemselves during old-age.

By Dutch law2, an insurance is defined by the following elements.

∙ There has to be a notion of a contract, otherwise known as a policy.

∙ The contract has to include the payment of a premium.

∙ The contract’s goal is to provide one or multiple remissions.

∙ The size of the remission, the amount of remissions or the length of the premium paymentshas to be uncertain.

1Nederlands Instituut voor het Bank- en Verzekeringsbedrijf : the Dutch Institute for Bank and Insurance Com-panies

2Burgelijk Wetboek art. 7:925 (Dutch Common Law)

21


In The Netherlands the provision of insurance services is supervised by the Authority of Fi-nancial Markets and the Nederlandse Bank. The Authority of Financial Markets surveils theconduct of insurance companies as to protect the consumer and the Nederlandse Bank checksthe solvency and organisational structure of insurance companies to ensure that they do not gobankrupt.

3.1.2 The Premium

To determine the height of the premium for insurance policies, the law of large numbers is used.The total costs for a certain loss is determined for a very large group with statistical analysis.This amount is then divided by the group, resulting in the risk premium. The actual premiumconsists the following elements.

∙ Risk premium

∙ Portion for business costs and provision

∙ Portion for profit

∙ Insurance tax

3.1.3 Distribution of the Products

Insurers use multiple channels for distributing their products to maximise their sales. Thedistribution of insurance products is done by the following agents.

∙ The insurance company themselves, also known as direct writing.

∙ Via a broker-type intermediary.

∙ Via an authorised representative or empowered intermediary

There are two important things to note here. First of all, with banks offering insuranceproducts as authorised representatives the line between insurance companies and banks is gettingthinner. Furthermore, brokers are slowly disappearing. This is mostly due to the fact thatconsumers are able to acquire their products themselves via direct writing and with help of theinternet.

3.1.4 The Market Targetgroup

The insurance market is basically divided into two target groups, the industry and the consumers.Consumers are people that act from within a personal situation whereas businesses act as acollection of people or have much larger risk. The risks for consumers and businesses are describedin Table 3.1 and Table 3.2, respectively.

Within a company, the employees can be grouped together and seen as a collective. Insurersmake special products for collectives which usually entail a discount or special packages for acertain company. Many companies also arrange their employee benefits in this manner.

22

3.1 What is Insurance?

Risks Policy types

Loss of, or damage to personal belongings Fire and theft,Auto,Valuables

Life, death, sickness Life,Health,Disability

Other capital damages Liability,Legal aid

Table 3.1: The risks of a consumer and the respective policies

Risks Policy types

Loss of, or damage to commercial porperties Fire and theftValuables

Capital damage Industrial damages,Liability,Legal aid

Employee risks Old age,Death,Disability,Health

Table 3.2: The risks of a business and the respective policies

23


3.2 Insurance Software

The functional requirements for insurance software are not unique (Quinity, 2003a). Ease ofuse, speed, low costs and transparency of the provision of services are essential for a competitivemarket position. The challenges for insurance companies are as follows.

∙ To lower the time-to-market for products

∙ To improve the efficiency of operational processes.

∙ To deliver real-time reports

∙ To maximise chain integration

On top of these requirements which arise from competition between insurers, the consumersimpose requirements on the insurance software as well. Consumers have grown accustomed tohandling a lot of their business online. This calls for the existence of a front-end where user canview their insurance file, file claims or handle other insurance related issues (Quinity, 2005, p.3).

Insurance software packages therefore have a certain set up which is recurrent across companies.The main elements are as follows.

∙ Policy administration

∙ Connections to external (legacy) applications

∙ Debtor administration

∙ Claim administration

On top of these elements, many products have different output channels to cater to theirvarying user groups.

3.2.1 User groups

In view of the different distribution channels, the structure of the insurance companies and therecurring software goals, the following (large) user groups can be defined.

Consumers As the largest group of all, consumers will use the system for buying their insuranceproducts online and for managing their policies and claims. These users have little or nodomain knowledge and can not be expected to be computer literate. Consumers need asystem that is easy, fast and fool-proof.

Intermediaries As the main task of this group is selling products using the system, this grouphas some domain knowledge and is especially well familiarised with the different products.Users in this group can be expected to be computer literate but not that they have the alot of time to learn how to use the system.

Insurance Staff This group can be seen as experts on the insurance domain. The group consistsof certain subgroups: Policy Acceptants, Fraud Experts, Claim Experts and other specificprofessions within the insurance administration, who all practice their specific tasks ona daily basis. These users have very specific knowledge that they have to process withthe system which has to cater to their specific needs. The speed at which they performa task is their main concern because their main goal is to process as much informationas possible. Insurance staff can be expected to be above averagely computer literate andthey can also be expected to take a reasonable amount of time to learn how the systemworks as it will be very specific depending on their job description.

24


Administrators This group has the highest clearance of all the other groups. Just like theinsurance staff, the administrator group can be split up into multiple functional subgroups,such as Insurance Staff administrators and Product Developers. The administrator groupworks ‘behind the scenes’ as they manage the staff and the products. This group is highlycomputer literate and has moderately knowledge of the insurance domain. The work theydo is extremely complex and the system has to be very stable and clear. Speed is less ofan issue to this group, whereas consistency and efficiency are.

By analysing the different subgroups, we see that insurance software has to deliver custominterfaces for virtually the whole spectrum of user types. Luckily, the situations in which thedifferent users interact with the system are distinct so that the interfaces do not have to beintertwined and can be physically separated. During this research our focus lay on a mixture ofthe Intermediaries, Insurance staff and Administrators. This was because the tasks they had arethe most complex in the system and we had the best chance of finding new patterns there.

3.2.2 The Future of Insurance Software

There are certain developments active in the Dutch insurance market today. If we extrapolatefrom these issues, we can get an indication of where the market and the software supporting itare headed (NIBE-SVV, 2006).

The most prominent of changes is that of chain integration. The adjusting of different auto-mated systems to work together creates major cost reductions for companies because it enablesthem to minimise the overhead. A large force in chain integration is the use of internet technologyto connect the different systems or locations.

The connecting of different systems and locations is becoming more important as the amount ofregulating organisations grows. Although the Dutch government is privatising different marketsto create a more level playing-field, the administrative overhead for insurers is growing because allthe regulating organisations need to have access to data at any given moment. Each organisationhas its own flavour of reports and digital forms and it is up to insurers to adhere to these.

Internet is also a new area of distribution of insurance products. Insurance companies cannow easily get into contact with their consumers directly. Selling insurance online is especiallyeasy for bulk products such as indemnity insurance. NIBE-SVV expects the sales share of bulkproducts via the Internet to be 80% by the year 2010.

In relation to the selling of products via the Internet, the market for intermediaries is shrinking.Smaller intermediaries are being taken over by larger ones or by insurance companies themselvesin an attempt to get a grip on the market. There seems to be a tendency of less but largercompanies with more specialised customer advisers.

An issue which has always been present but which only recently has become into play is fraud.In the past not much attention was paid to fraud because the investment was not worth thereturn. The tipping point however has long been reached and many insurers are becoming verykeen on catching fraud. There is a big role to play for software systems to help the insurers inthis task.

In the coming years, the ageing of the population will pose a problem for most insurancecompanies. They will have to turn-out larger remissions and on top of this the health costsare increasing. To compensate this many insurers are expanding their services to hospitals andhealthcare centres so as to pay their remissions in kind.

In conclusion, the cooperation between the different parties is increasing. This calls for ahigher streamlining of data processing and work flow. On top of this the services of insurancecompanies are being expanded to social services as well. This increases the need for cooperationeven more.

25


Figure 3.1: QIS positions itself in between the different elements of an insurance company, from (Quinity,2005)

3.2.3 Quinity Insurance Solution

The system we evaluated during this research was Quinity Insurance Solution (QIS), a multi-tiered modular software package based on web technology that aims to encompass the wholeinsurance process. It situates itself on all the different assets of an insurance company, as shownin Figure 3.1, and therewith attempts a total solution for insurance companies.

QIS consists of many modules but two modules that provide its base are the Product DefinitionSystem (PDS) and Quinity Forms System (QFS). The PDS enables product developers to defineactual insurance products on a logical level as objects and add them to the system withoutprogramming knowledge (Quinity, 2005). QFS allows an employee to create forms for any generalpurpose, but most importantly to create forms which have a specific mapping onto the insuranceproduct objects. Together, PDS and QFS become a powerful combination as insurance productscan be implemented simultaneously with their request- and mutation forms. This cuts down theneed for highly trained programmers and shortens the time-to-market for new products (Quinity,2003b). Screenshot of QIS are shown in Figure 3.2.

Together with its other modules a system is realised which can be accessed through threedifferent channels (Quinity, 2003a) which service the different user groups metioned in Chapter3.2.1 nicely.

∙ Intranet for administrators and insurance staff

∙ Extranet for intermediaries

∙ Internet for consumers

The main goal which is accomplished by using these different channels and web technologyis that a single application (though modular) can be built which suits the needs of its differentusers. This is possible because each channel has a different goal and therefore a different face.

3.2.4 Other Software

To place the software we were evaluating in perspective, we also did a short analysis of comparablesoftware. It was rather difficult to do this for a number of reasons. First off, the software anddata that insurance companies own are very privacy-sensitive. Insurers are not keen on prying

26


(a) Form system (b) Form System

(c) Policy System (d) Product Definition System

Figure 3.2: QIS is built up of many different modules

27


eyes and we were therefore not granted access to active software environments. Secondly, most ofthe packages used are custom-made due to their specific nature and the companies’ requirements.This makes it hard to find general information about that software. The information we wereable to find, for the most part, only supplied us with a general description of the systems andnot with any visuals of that system. Following is the information we were able to find.

Mona Lisa A custom-made policy registration solution used by Monuta and Unive is Mona Lisa(Unive has named the system Impulsa and has a personalised implementation) which wasbuilt for them by Solidium and Atis (Hilarius Media, 2003). This system was a replace-ment for an older mainframe-based application. Mona Lisa is built in an Advantage Plexenvironment (Computer Associates Plex Wiki, 2008), a product of Computer Associates.The Mona Lisa program is data-oriented and consists mainly of overview screens withtables and detail screens with editable properties.

Elvia Policy System A solution from the insurance company Elvia3, a daughter company ofMondial Assistance4, is the Elvia Policy System (EPS). The EPS is a perfect example ofhow a information system enables intermediaries to sell products to consumers via theirwebsite. The system looks like a simple web form, but when we study the code we can seethat the form is parsed into the website by an iframe and is not part of the intermediary’ssite at all. On the back-end there is a centralised online system to manage all the everythingfrom a single application (Figure 3.3).

Salesgarant Salesgarant5 is the extranet channel of Unigarant6. Though we were not able tosee this environment in action, Unigarant’s site itself allows consumers to request pol-icy quotations on their site via forms (Figure 3.4). This points towards similar formsinteraction.

AllianzNet Insurer Allianz 7 has a multiple intermediary extranet systems, AllianzService, Al-lianzNet and Allianz Allegro. AllianzNet communicates with a legacy CICS mainframein the back-end. The communication between the front- and back-end is mainly donewith WebSphere technology (The Future Group). Sadly, we were not able to obtain anyscreenshots of this application.

Certigo Certigo8 by Netaspect9 is an all-round insurance solution with many similar charac-teristics to QIS. The company however does not divulge any information to its interfaceanywhere.

Because it was so difficult to get access to actual competitor software we turned our headstowards other candidates. We found that certain off-the-shelf packages for (financial) adminis-tration are used by various insurance companies as parts of their total system.

Coda The finance system specialist Coda10 has developed many products for financial admin-istration. Recently they have launched their programs as an online service called Coda

3http://www.elvia.ch/4http://www.mondial-assistance.com/5https://www.salesgarant.nl/6http://www.unigarant.nl/7http://www.allianz.nl8http://www.certigo.nl/9http://www.netaspect.nl/

10http://www.coda.com/

28

http://www.elvia.ch/

http://www.mondial-assistance.com/

https://www.salesgarant.nl/

http://www.unigarant.nl/

http://www.allianz.nl

http://www.certigo.nl/

http://www.netaspect.nl/

http://www.coda.com/


(a) New policy (b) Policy mutation/ cancellation

Figure 3.3: Screenshots of the Elvia Policy System; source (Elvia)

Figure 3.4: Screenshot of the Unigarant policy quotation request form; source (Unigarant N.V., 2008)

29


(a) Homepage (b) Opportunities (c) Cash invoice matching

Figure 3.5: Screenshots from Coda 2go; source (CODA Ltd., 2009)

Figure 3.6: Screenshot of Siebel; source (IBM, 2009)

2go11 in cooperation with Salesforce12. The interfaces provided by the tour of the differ-ent software solutions look well-ordered and intricate (Figure 3.5). It has a lot of tables,data and forms, but they are shown in a well structured manner. Altough the navigationis data oriented the terminology seems applicable and there are also a few task orientedshortcuts.

Siebel Customer Relationship Management The Siebel CRM solution13, created by Oraclecomes in two flavours, the stand-alone version and the online On Demand version. Thissystem too is very data oriented. Although the interface has similarities to Coda, Siebeldoes not do a very good job. The interface seems crowded an unstructured (Figure 3.6).

Enterprise Resource Planning SAP14 is a company that builds many enterprise solutions. Theinterface to its enterprise resource planning software, though bland, seems to do tricknicely. It is very clean and clear cut with excellent visualisations used for wizards and taskprogress (Figure 3.7).

To increase the amount of comparable software as much as possible, we also looked at othertypes of administrative software. We found two very good examples in the medical sector.

Norma EMD/EPD In some hospitals in The Netherlands a program is used called NormaEMD/EPD15, made by MI Consultancy16. This program administrates the medical sta-tusses of patients. The screenshots from this stand-alone program in Figure 3.8 show

11http://www.coda2go.com/12http://www.salesforce.com/13http://www.oracle.com/us/products/applications/siebel/index.htm14http://www.sap.com/15Elektronisch Medisch Dossier/Elektronisch Patienten Dossier : Electronic Medical File/Electronic Patient File16http://www.miconsultancy.com/nl/

30

http://www.coda2go.com/

http://www.salesforce.com/

http://www.oracle.com/us/products/applications/siebel/index.htm

http://www.sap.com/

http://www.miconsultancy.com/nl/


(a) Sales processing (b) Travel management (c) Relationship management

Figure 3.7: Screenshots from SAP ERP; source SAP A.G. (2009)

(a) (b) (c)

Figure 3.8: Screenshots of Norma EMD/EPD; source (MI Consultancy, 2009)

that it is very data-oriented with long lists, tables and property sheets. Without domainknowledge this program is definitely very confusing.

Zorgdesktop Formerly known as Poliplus, AMC Zorgdesktop (AZD) is used by the AmsterdamMedical Centre (AMC) to view patient data, such as lab results and medical history. AZDwas developed by AMC themselves and uses modules provided by ChipSoft17 a medicalspecialist software company. AZD has an extremely tabular interface, much like Norma.The structure in the forms however is lacking and there seems to be little attention paidto human factors as the screen colours are not easy on the eyes and layout is inconsistentacross them (Figure 3.9).

The different software packages we saw proved not to be very spectacular. For the mostpart the systems consist of overview-, detail- and input screens in which the objects which areadministrated can be viewed or edited. There is a general lack of intuitive design as most of theinterfaces are data- and not task oriented because this is simplest to implement. We think thattransforming this orientation will be the greatest challenge in our quest for defining patterns.

17http://www.chipsoft.nl/

31

http://www.chipsoft.nl/


(a) (b)

Figure 3.9: Screenshots of AMC Zorg Desktop; source (ChipSoft, 2009)

32

4 Method

In this chapter we discuss the method we used to find the answers to the research questions pro-posed in Section 1.3. First, we give an explanation of our views and ideas on pattern engineeringin Section 4.1. Following this we give a description of the adaptations we made to DUTCH inSection 4.2, describing our method, with adapted DUTCH, in its ideal form. Finally, we detailthe specific considerations of our implementation of this method for this research in Section 4.3.

4.1 Our Approach

This research had two objectives, as mentioned in Section 1.2.1.



To accomplish both of these goals we devised an approach to extract patterns. When de-vising this approach we took into consideration the differences between software- and patternengineering, the characteristics of how to find patterns and our own ideas on how to extractpatterns.

4.1.1 Software Engineering Versus Pattern Engineering

There are differences between pattern engineering and normal software engineering. The differ-ence which was of most interest to us, was one of tactics. With software engineering, the goalis to improve the software under scrutiny to its maximum potential within the boundaries andrestrictions, such as money and time, imparted on the project by the context in which the projectis performed. When evaluating this software, we wish to test that single piece of software asmany times as possible in as many different ways as possible to minimise the possibility of errorsbeing present in the system.

When engineering UID patterns, this is a different story. To find patterns, we want to comparedifferent software packages which have similar functional elements, to find overlap between themand extract generic elements. Using different software packages which exhibit similar function-ality as input for a certain pattern will give us a broad overview of which things work in animplementation and which things do not. Testing the same software over and over again wouldnot increase our knowledge of a pattern; we do not wish to test the software, we wish to test thepattern.

An approach to test the pattern would be to implement it into a package which does notcontain this pattern (or at least not in its entirety) and to see if the usability of the systemimproves with this implementation. Another possibility would be to create a fictional contextwith different prototype systems, which all have the extracted pattern implemented up to acertain degree and find which of the systems has the highest usability. Which ever method isused, hopefully, the prototype with the the extracted pattern fully implemented in it, has thehighest usability.

33

4 Method

If this is not the case, there are two possible things that could be incorrect in our patternspecification.

1. We have not captured the user’s problem correctly. The problems in the compared casesdiffer on a functional level because we have missed something in the problem description,i.e. the solution is correct but not applicable to this specific problem.

2. We have not captured the solution correctly. The combined solution that we have devel-oped does not cover all the problems the user is facing, i.e. the problems match up but thecombined solution we have defined is lacking in some way.

For instance, if we were to look at a pattern for searching, we would find that there are differenttypes of searching a user can perform which require different ways in which the results of a searchshould be displayed. Searching for an email contact is functionally different from searching forlemmas in an encyclopaedia because the first is about specifying and refining our search to findone specific contact. Whereas the latter, although containing a refining element, is primarilyabout aggregating results to collect as much relevant data as possible.

Drawing from the above, the goal of evaluating a software system is different in pattern engi-neering than in software engineering. Software systems in pattern engineering function as testingbeds in which a pattern can be substantiated. Whether we improve the software or not, is notreally the issue, it is whether we extract the pattern correctly that counts. Of course, applying acorrect pattern and applying this pattern correctly, should mean that the task to be performedby the user is made easier and, in turn, that the usability of the software is improved. Howeverit is the difference in scope and focus that we wish to distinguish here.

4.1.2 Where We Looked for Patterns

Taking into account that this research project had a time limit, we had to make a selection of theareas where we looked for patterns. We formulated the following groups of user tasks as targetareas to search for patterns in the software under examination.

Tasks performed often Characteristic of a pattern is that it is a reusable generic solution toa generic problem. We thought it most logical to find a reusable solution in a task thatoccurred frequently throughout the system. An example of this is searching. Whetherediting customer details, a policy or an email the object that we wish to edit has to befound first.

Tasks that often fail A task that fails is most probably special in some way, it is possiblydifficult to perform because of its cognitive load or because the context is misleading insome way. Whatever the case, if we are able to find or define a similar case in which theuser can perform the task successfully we are able to compare the two scenarios and distilthe differences between them, pointing us in the direction of a pattern. An example of thisis when the user is asked to input financial values that are dependent on each other. Theamount of calculation that the user has to perform often confuses him resulting in wrongvalues being entered.

Tasks that often succeed In a situation where a task is often performed successfully there couldwell be something special about the implementation as well. Perhaps a task is so simplethat is it is virtually impossible not to complete, but if this is not the case it pays toinvestigate different solutions. In contrast to tasks that fail, where we look at the differencesbetween failing and succeeding solutions, here we look at the similarities. Generalising

34

4.1 Our Approach

these qualities can lead us to patterns as well. Here an example is the navigating of amenu structure. When a user is able to find the information he is looking for quickly andeasily the information has been structured in a good way.

We do not dispute that patterns exist in other areas. For instance, the changing of a userpassword is task that the user will most probably not perform often and therefore does not fallinto one of the categories above. It is important for this function to be implemented correctlyif the user is to be able to interact with the system and a pattern can probably be found forthis function. However we believed patterns to be most useful for the areas mentioned abovebecause of the impact these patterns could have on the development of software. A task whichis performed sporadically is less of an issue than one performed on a regular basis.

4.1.3 How to Extract and Evaluate Patterns

In relation to where to look for patterns, we also formulated an approach to extract them. Theapproach is based on our ideas of going about pattern engineering, as described in the previoussection, in combination with an evaluation step taken from software engineering. The patternengineering part of the approach consists of three abstraction levels, as shown in Figure 4.1.

Implementation Level We call the lowest level the Implementation Level. This is where wegather cases as input or prototype our own implementations to consolidate a pattern.

Functional Level We call the second, middle level, the Functional Level. On this level we ab-stract the different tasks and functionalities present in the system to create a descriptionof the task problem and its solution.

Pattern Level We combine the descriptions of each case together on the highest level, which wecall the Pattern Level. Here we take the relevant parts of each problem description andthe most useful parts of each solution description, crafting an optimal solution to a genericproblem description. In essence this level is not really different from the level below it,except in terms of its genericalness. The combination of a generic problem together witha generic solution, delivers us a pattern.

Software engineering evaluation methods use iterative testing to improve their product. Wecan use this technique to evaluate our pattern, which is our product. Having extracted a patternit can be translated back to a certain case, either an existing one or a completely new case. Thisimplementation can then be compared against other implementations with out the pattern tosee if there is an improvement in usability. In this manner, pattern- and software engineeringmethods are executed symbiotically.

To illustrate this process we will work through it now with an abstract example correspondingto Figure 4.1. Let us assume we have a set of four cases: V , X, Y and Z which all have a searchfunctionality. We abstract all the cases to a general description and start to compare them. CaseV turns out to be quite different from the other cases and we therefore discard it all together.Cases X, Y and Z have similar problem descriptions and we therefore combine these to a singlegeneric problem description. The solutions which cases X and Y have to their problem seemuseful, thus we combine these to a generic solution description. Case Z however does not seemto have a very useful solution and we discard that solution. The generic problem and solutioncan now be defined as a pattern. To test our pattern, case Z makes an excellent candidate, as itdoes not have our extracted pattern implemented. We now implement our pattern in the contextof Z creating Z∗. The comparison of Z and Z∗ will indicate if our pattern is correct or not.

35

4 Method

Fig

ure

4.1

:T

he

Gen

ericA

ppro

ach

—M

ultip

leca

seare

abstra

ctedto

describ

egen

ericfu

nctio

nality,

the

usefu

lca

sesare

then

com

bin

edto

describ

ea

gen

ericpro

blem

and

solu

tion,

which

intu

rnare

our

basis

for

apattern

36

4.2 The Generic Research Method


In accordance with our ideas above, we defined our method as follows.

4.2.1 Combining DUTCH with Pattern Engineering

To reach our first goal for this research, formalising a method for identifying UID patterns, wechose to combine an existing method for software- and user interface engineering with our ap-proach for pattern engineering. Our method of choice was DUTCH for the reasons already statedin Section 1.4. The method is driven by task analysis and usability criteria which are importantelements when evaluating a system’s usability. The method is also iterative which enables us todo multiple user tests to check if our changes to the system are actually improvements.

As DUTCH is an engineering method and not a pattern engineering method, it was not appli-cable in its pure form. Therefore we applied it as an evaluation step to of our pattern extractionprocess. We translated our approach shown in Figure 4.1 to a DUTCH-specific approach asshown in Figure 4.2. Specifically this means that we not only analysed the current system butwe also used other systems that had similar functionality to create a descriptive task model (TM)of the generic problem and solution pair, TM1, from which we extracted our pattern. We thendevised a prescriptive task model, TM2, for the an input case by applying our pattern to it. Torecord the patterns we found, we used the template proposed by Van Welie, Van der Veer, andEliens (2000) and extended by Hennipman, Oppelaar, and Van der Veer (2008).

Another thing we altered in the DUTCH method was the prototype deliverable and its cor-responding part in the validation process. Normally, TM2 describes a new work process forthe software at hand and the prototypes and evaluations pertain to this new TM. However, forthis research we were not interested in creating a whole new TM or a PT of a completely newinterface, we wanted to evaluate the correctness of the discovered patterns. Therefore we madesmall PTs which described only a specific pattern and performed small use case tests aroundthese. We did not develop a PT for the system as a whole.

4.2.2 A Single Cycle through Altered DUTCH

Because we deviated from the normal steps of the DUTCH method quite a bit, it is useful togive a more detailed explanation of all the actions that were taken during this research. Thefollowing is a breakdown of the steps of our ideal research setup adapted from the originalDUTCH method (Van der Veer and Van Welie, 2003) which can be performed iteratively untilthe result is satisfactory. Our adaptation of the DUTCH method for pattern engineering upholdsthis iterative process, as shown in Figure 4.3. We will give details on our own implementationand considerations in the next section.

Evaluation of the Current Situation In this first phase the initial user requirements are gath-ered by studying existing documentation. Where the documentation is lacking interviewsand other RE techniques are used. On top of this, existing applications are studied byconducting structured interviews and user walkthroughs. The knowledge of the currentsituation is recorded in a descriptive task model, TM1. This step is the elevation fromthe implementation level to the functional level for problem descriptions, as shown in Fig-ure 4.1. Any apparent UID patterns that emerge from the software and of which designknowledge already exists, are documented here.

Envisioning a Future Situation Using the combined knowledge of TM1 and solutions imple-mented in other cases, a prescriptive task model describing an improved design of the task

37

4 Method

Figure 4.2: Several different cases are used as input to extract a generic problem and solution pair, apattern, which is then applied in the transition from TM1 to TM2 to create a prototype ofthat pattern

Figure 4.3: In our adaptation of DUTCH we added the the extraction of patterns in the middle of TM1,TM2 and the PT

38


model domain is created, TM2. This is done for a specific case with which we wish to eval-uate the pattern. This model implements the solution part of our pattern. Other usabilityissues which we encountered in the system during the composing of TM1, but which arenot relevant to the pattern, are not addressed. This step is analogous to the previous one,elevating the solutions descriptions from the implementation level to the functional level.

Specification, Designing and Prototyping for Patterns With the combination of TM2 and thetotal of the users’ knowledge of the system (its technology, its semantics and syntax),termed as the user virtual machine (UVM), a pattern is defined. This step is the elevationfrom the functional level to the pattern level in Figure 4.1. The defined pattern is appliedto the case chosen in TM2 and a prototype of it is implemented as shown in Figure 4.2.The pattern of this new solution is designed by performing three sub-activities: (i) speci-fying the functionality (ii) structuring the dialogue between the users and the system and(iii) specifying the presentation of the system to the user This phase therefore results inmultiple small prototypes, each presenting a specific pattern.

Evaluation In concurrence, evaluation of each phase can take place simultaneously to validateits products. Which type of evaluation is used depends on the phase being evaluated andcan consist of things like walkthrough sessions or prototype testing. Our new version ofDUTCH however, calls for a special treatment when it comes to the PTs. Just as TM2 isnot a description of a whole new system, the PT are not a PT of a whole new system andtherefore should not be evaluated as such. Using the different metrics found in Section2.4.1 and Section 2.4.3 we can compare tasks performed with the current system and withthe PT portraying the pattern.

The group of users that is used to do evaluations, has some criteria in our adapted DUTCHthat have to be observed for the evaluation to be a success. Even more than with normalDUTCH, it is necessary for the users to be end-users of the system which is being examined.It is extra important in this case, because we are evaluating specific domain software, thatextremely novice users, who have no or little domain knowledge, cannot work with. Thetime needed to understand the scenario applicable in the user-test would not make thetests productive. Furthermore, it is useful to select a wide range of users, from novice(with domain knowledge, however) to expert. The discussions about the amount of users,for a test apply here (Nielsen, 1993, p. 117–121). We are not opinionated on this point,and leave this to your discretion. Lastly, we believe it best to test both systems with thesame user base. This way the same users evaluate both the current system, without thepattern, and the PT, with the pattern, and a relative score can be calculated.

The PT is developed to be an implementation of a single pattern. Therefore during theevaluation the scenario is separated from the context of the system to a certain level.We believe that splitting the pattern from its context does not affect the validity of theexperiment. First of all, we do not completely split up the pattern and the context becauseduring the evaluation the user is given a scenario which describes a context within whichthe user is to perform the task. Without this context there would be no goal in thescenario, no drive for the user to perform the tasks. Secondly, the separation of the taskand its context is not really an issue if it does occur, because we wish to test the pattern.If the pattern is correct then it will show that the usability of the system improves nomatter what the context. This is inherent to the fact that a pattern should be a genericsolution.

We made these adaptations of the method to accommodate our research objectives. We believethat the above changes in the method increased the chance for us to achieve these goals, because

39

4 Method

they enabled us to extract patterns from the respective TMs and evaluate them specifically.

4.3 Application of the Research Method

To complete our research in a timely fashion and not exceed the resources available to us, wetook the certain things into consideration and had to set limitations to our actions.

4.3.1 A Description of our Implementation

Following is a description of our exact implementation of the generic method explained in thesection above. We applied the whole method to the following software systems. We will describethe patterns that were found in these systems in Chapter 5

1. Forms administration system

2. Policy requisition system

3. Claims administration system

Evaluation of the Current Situation First we administered a general user profile survey to de-fine our user-group to gain background information of our test users. Our survey wasbased on the sample template designed by Mayhew (1999, p. 49–55) and can be seen inAppendix A.1. The survey looks at elements such as age, computer literacy and experiencewith certain programs. We used this survey because it gave a good overall view of thecharacteristics and capabilities of the users and did not need to be adapted very much tobe applicable for this research.

Due to time constraints we assigned each user to two of the systems that we were evaluatingfor the timespan of rest of this phase. They were assigned according to the results of thisuser profile survey and in such a manner that there was at least one experienced and onenovice user assigned to each system.

After this we performed semi-structured interviews with our user group, see Appendix B.1.Asking specific questions about the assigned case. As these interviews did not turn outto be very revealing we also interviewed two designers of the software modules to acquiremore detailed information.

These interviews gave us enough information to develop use-cases with general tasks. Wethen performed user tests by making use of the think-aloud protocol during a scenario-based walkthrough session as described by Tullis and Albert (2008, p. 103) and (Whartonet al., 1994) where we measured issue-based metrics described in Section 2.4.2. Thesesessions gave us insight into how the users interacted with the applications, which issuesthey run into, which improvements they want and, most importantly, what their workroutines and cognitive processes are.

Lastly, we performed an expert-review with the system ourselves, as well as described byNielsen (1993, p. 155–163). We did this to maximise our chances of catching usabilityissues.

Envisioning a Future Situation Using the knowledge gained from the current situation, we per-formed this phase as described in the previous section.

Specification, Designing and Prototyping for Patterns This phase was performed as describedin the previous section.

40

4.3 Application of the Research Method

Evaluation Due to time constraints we performed one iteration of designing, prototyping andtesting of the PT. To evaluate our proposed patterns we performed tests using the cur-rent version of the system and our PT. We measured the following performance metrics,described in Section 2.4.1, (i) task success (ii) time-on-task (iii) errors and (iv) efficiencyusing a user-testing program called Morae1 from TechSmith. This recorded all our sessionsso that we could analyse them later. To prevent bias of the users’ perception towards anycertain prototype, we shuffled the order in which the tests were administered so that eachuser performed the tasks in a different order.

In combination with the measurement of performance metrics, which measure quantitativedata, we also measured qualitative data. To accomplish this we used the ASQ technique,as described in Section 2.4.3 and Appendix A.5. This questionnaire gave us insight intohow the users perceived the different tasks. We used this questionnaire because it wastask-based and gave as variables along multiple axes, which we thought was usefull, asit provided more information. These two metrics provided enough data to compare thecurrent system and the PTs.

4.3.2 What we did not measure

We decided not to look at learnability, behavioural or physiological metrics when analysingthe cases. Measuring this information was not feasible for this study and beyond its scope, asmetioned in Section 2.4.4. In relation to the learnability metric there was another consideration.This metric was not applicable in our research because refers to the system as a whole, combiningmultiple tasks and workflows, whereas we were interested in the usability of our specific patternswhich provided for one single task.

4.3.3 Constraints of the Test Group and Test Schedule

The test group consisted of five people, that had varying amounts of practical experience withthe different software modules. This is a small group to perform user evaluation with, but theour resources did not permit us to acquire more users.

Four of the users were consultants that worked with the product and one was a project leader ofa development team for the product. The reason we chose not to use completely inexperiencedusers in the study is that it did not seem useful. The necessary background knowledge andimplicit domain knowledge that is needed to work with the system, is far too high in the chosencases. Inexperienced users simply are not the user group of the system, whereas the staff membersare.

The tests per case were all administered simultaneously. This was necessary to complete theresearch within the set time span. By doing this, we chose not to evaluate our experienceswith a test to adapt the test of the following case. Moreover, it was not necessary perform thesuccessively because all testing was in-house and the test users were still available if somethinghad gone drastically wrong.

1http://www.techsmith.com/morae.asp

41

http://www.techsmith.com/morae.asp

5 The Results of the Case Studies

In this chapter we reveal a summary and the highlights of the results of this research. In Section5.1 we describe the results of the actions that were common across all input cases. We describethe user profile, the interviews, the input software cases, the user tests and heuristic evaluationfor our TM1. After this, in Section 5.2 we describe the patterns we found and reviewed, howwe developed them and the result of our user tests with these patterns. In the following section,Section 5.3, we describe new patterns we found but were not able to review and we conclude inSection 5.4 by listing pre-documented patterns which already are implemented or could be.

In relation to this chapter, the catalogue of the new patterns can be found in Chapter 6 andthe research result data can be found in Appendixes A through E.

5.1 General elements

The following section describes the common research elements applied to all the input software.

5.1.1 User profiles

The profile of the users with which we performed evaluation in this research can be summarisedas follows. The specific results of the user profile questionnaire can be found in Appendix A.2.

The test group consisted of four consultants and one project leader. They were four men andone woman of Dutch origin with an age between 25 and 30, all in possession of a university degree.The group members consist of both novice and experienced employees, none of the employeesview themselves as experts on the insurance domain.

All the members are experienced with computers and also enjoy working with them. Themajority finds computers interesting for qualities besides their use as a work tool. They enjoylearning new applications, although they do not always find it worth the time this takes. Ingeneral they believe the computer has made their life easier. They all have a reasonable to largeamount of experience with the Forms Administration System, less experience with the PolicyAdministration System and little with the Claims Administration System. None of the users hasworked worked with similar software nor do they know of any.

All of the users are right-handed, more than half is short-sighted of which the majority is mod-erately impaired. One person in the group is colour-blind. Apart from this, there no handicapswhich have to taken into consideration.

5.1.2 Interviews

We performed four semi-structured interviews with the user group members (one user was absentat the time) to gather general information about their work procedures and their experiences withthe software systems. A guide for the questions we asked each user can be found in AppendixB.1 and the transcriptions of the interviews can be found in Appendix B.2 through AppendixB.5.

Because the users have less experienced with the Claims Administration System we were notable to get a clear view of how the system worked from their interviews. Therefore we called on

43


two designers of the systems and interviewed them as well. These interviews can be found inAppendix B.6 and Appendix B.7.

5.1.3 Case Software

As already mentioned in Section 3.2.3 the software we evaluated to generate patterns for thisresearch was the Quinity Insurance Solution. QIS is a modular product which attempts tosupply a complete solution for the whole insurance process. The system has many sub-modulesand decided to analyse the three of these.

Forms Administration System To enter any data into the system so that it can be managed, aform has to be filled out. These forms can be built and managed with the Intranet ap-plication QFS. Together with Product Definition System the Forms Administration formsthe basis of QIS. With the PDS an insurance product can be defined as an object in thesystem, with all of its attributes recorded. QFS enables us to create complete form dia-logues which are mapped onto a product object, therefore allowing us to create and modifyinsurance products in the system. The forms can be summoned by other modules or evencompletely separate software systems, enabling third parties to incorporate functionalityof QIS into their internet website.

This module is of interest to us because work flow is counter intuitive, where users tendto think in a top-down manner from form to question, for the system to work it has to beused in bottom-up fashion, defining questions first and grouping them in forms later.

Policy Requisition System This system is part of the Policy Administration System which isused to manage the policies that clients of an insurance company have. The requisitionsystem is used via an Intranet by intermediaries to apply customers for an insuranceproduct. The application for insurance is passed along to the insurance company who canthen process it further.

This is an interesting module for us because it is the main entry point for intermediariesinto the system. Furthermore the use of policy packages is interesting because it createsa loop in which the intermediary can input multiple policies. It seems that they tend toget confused about their status as they progress through the process of applying for aninsurance policy.

Claims Administration System This Intranet system is used by back-office employees, such ascall centre staff members, to register insurance claims that clients have. The system coversthe complete process of administrating the claim. Controlling the claim from when it firstcomes in, through its examination of different claims experts, its checking for fraud, up tothe point where it is either denied or accepted and possible payments are made.

This module is interesting for us because it has to cater to many users with differentexpertises (call centre staff, fraud experts, damage experts). Therefore the module has toinclude a lot of functionality which is not applicable to all users. Users tend to get lost inall possibilities.

An interesting point to note here, is that all of these modules are a type of administrationsystem. The data is key in all of these systems. This means that all the functions in the systemare not arranged around the tasks of the user but around the data itself. Manipulation of thedata is accomplished through low-level tasks such as creating, editing, saving and deleting asingle data object. The interactions are not visual but textual and higher level abstract notionssuch as linking data objects are only supported through manual textual input.

44

5.2 Reviewed New Patterns

5.1.4 Collecting Issues in Task Model 1

Using the information gathered in the interviews, we analysed the software modules ourselveswith a walkthrough and an heuristic evaluation.

Walkthrough Sessions

From the interviews we devised a scenario for a common task for each system, which the usershould be able to perform when working with the system in a normal fashion. These scenarioscan be found in Appendix C. We performed the walkthrough sessions using the think-aloudprotocol as explained in Section 4.3.1.

Due to time constraints we were not able to do a walkthrough with all the users on everysystem. We assigned each system three users and we allocated the users so that every systemwas reviewed by at least one experienced and one novice user. These sessions led us to a list ofissues which can be seen in Appendix D.1.

The biggest issue in the Forms Administration system was that the information structure ofthe system was inverted to that of the users’ cognitive process. The system enforced the user,though not actually stating this anywhere, to create questions first, group these, add the groupsto one or more forms and then build a dialogue on top of the form. The user tends to think theother way around. The user does not make the distinction between dialogues and forms whichthe system makes. Other issues that we came across were related to speed. The system often didnot provide functionality which the user needed, such as editing multiple objects simultaneously,copying objects and a visual interface to link these objects.

The biggest issue that was present in the Policy Requisition System was related to guidance.The task that the user performs consists a multi-tiered wizard which loops itself. Depending onthe options the user chooses, or rather the characteristics of the policy package being required,the wizard loops through multiple policy requisition protocols. It is appeared easy for the userto loose track of his progress during this process. Other issues which we found related to a steeplearnability curve and the being buried of certain options.

The issues that we found in the Claims Administration System were mostly of a visual na-ture. Users were unclear about how to go about their tasks as the entry points were not clear.Furthermore lack of visual structure hindered the guidance of the system. Users were unclear onwhere they could perform certain tasks and in which order to perform them.

Heuristic Evaluation

After the walkthrough sessions we performed a heuristic evaluation of the system ourselves. Ourfindings did not differ radically from our findings of the walkthrough. However, we were able tozoom in on a few issues which the user had already grown accustomed to. These issues includedthe input of financial data in an illogical order when requesting a policy and various visual aspectswhich users complained about.


There were many usability issues which we could choose to focus on look into. We chose toinspect three patterns, one pattern for each system. In this section we will give a descriptionthese new undocumented patterns and the results of their evaluation with a prototype. Theexact patterns will be given in the next chapter.

45


5.2.1 Incremental Search

This pattern can be found in Section 6.1.

Description

An insurance company does not wish to keep double records or have duplicate information intheir system. This would not only waste system resources but also be a magnet for administrationerrors. It is quite possible that a claim is entered as duplicate for it the incident for which theclaim is being made, that is registered in the system. For instance if two people that insurance atthe same company are involved in a car accident together they would both register their claim,but it would be the same incident. To enforce that no duplicate claim is entered into the ClaimsAdministration System, when entering a claim, the user first has to search the for the claim todiscover if it already exists. When the user has determined this is not the case, he can create aenter a new claim into the system. If the claim already exists, obviously, the user is expected tocontinue his with the existing claim.

This makes the search task the user have slightly different to a normal search. In this casethe user is interested in finding exactly that claim object in the system under which the incidentis registered. Finding objects like it would only be confusing to the user. The user has to beable to enter specific search parameters by which to find the claim object. This is comparable tosearching in a telephone book. The user is looking for an exact record relating to the parametershe has. If there is no record that matches he is not interested in another or similar record.

This differs form a usual search method as implemented by an internet search engine or adating site. In the former the goal is to aggregate as many (useful) results as possible. If thereis no exact match the user will wish to see results that partially match his parameters. Withthe latter partial matches are already a de facto standard where there has to be a form of fuzzylogic deciding what defines a match and what does not.

Moreover, the needs of the user in the Claims Administration System take it a step further.If the object can be found, this is fine and the user can continue working with that object. Butwhat the user is really after is if the object can not be found so that he can decide to createa new claim object. This is makes for a form of reverse searching where we are not looking toaggregate multiple results, but narrow our result space down to exactly one or zero.

Prototype and Evaluation

We developed a pattern for this task which displayed a result counter, as shown in the screenshots in Figure 5.1. The counter updated real-time as the entered his parameters, Figure 5.1a andFigure 5.1b. The counter was situated inside a progress bar which grew as the result count shrankand turned from grey to green when the result set had shrank to a reasonable size which wouldbe meaningful for the user to browse, Figure 5.1c. If the result set for the entered parametershad shrank to a size of zero, the bar turned red, indicating that no results would be returned,Figure 5.1d. When the user effectuated a search or the result set size had become zero a buttonwould appear enabling the user to create a new object, Figure 5.1e.

In the scenario we used to evaluate this PT, Appendix C.2.1, we asked the user to determine ifthree different claims existed. The first two did and the third did not. All of the users succeededin this task without any errors. The performance metrics show that when user used the PT therewas a 36% drop in the time-on-task, Figure E.1, and a 56% drop in mouse clicks, Figure E.2.The ASQ results show an increase of more than one point on all axes A.2a. The satisfactionaxes jumps out here with a 2-point increase.

46


(a) The result bar starts off grey. . . (b) . . . and turns green when a reasonable result setis collected

(c) The result bar turns from green. . . (d) . . . to red when the result count hits zero

(e) The create new object button appears when a search is effectuated or when the resultcount is zero

Figure 5.1: Screen shots of the prototype for the Incremental Search pattern

5.2.2 Unified Edit


Description

When working with the Forms Administration System the user often has to perform very repeti-tive work. This is case when the user has to input many questions into the system which all havethe same attributes. When creating question objects simultaneously, an option to accomplishthis would be to be able to duplicate objects. However, when the user has to manipulate multipleobjects to adjust a certain attribute, he has to do this manually object by object in the currentsystem.

A similar case here is the properties screen in Windows Filemanager. By selecting multiplefiles and then selecting properties we can change attributes for all of these files in one singlescreen as if we were editing a single file. Options which are too complicated to edit in this formare disabled. Attributes that differ across files are not disabled but greyed to indicate this. Theseattributes can still be edited to the value we wish.

An example in which the task description is similar but the solution is different is the editfunction in PHPMyAdmin. Here the user is able to select multiple objects to edit but cannotedit them all simultaneously. The screen the user is redirected to contains separate edit formsfor each selected object.


The PT we devised contained a function with which the user could select all the objects hewished to edit, Figure 5.2. First the user selected the objects by checking the checkboxes, Figure5.2a, and then clicked on a separate edit button after which he was redirected to an edit screen

47


(a) The user selects the objects he wishes to edit

(b) A list of objects being edited is given at the top of the screen

Figure 5.2: Screen shots of the prototype for the Unified Edit pattern

which applied to all the selected objects. The fact that multiple objects were being edited wasmade clear at the top of the edit screen where a list was given of these objects, Figure 5.2b.

In the scenario we used to evaluate this PT, Appendix C.2.2, we asked the users to changethe visibility conditions of two questions in a form so that the questions would only becomevisible when certain values were entered into a third question. All of the users accomplished thistask. The performance metrics show that there were a lot more errors when using the PT thanwith the original interface, Figure E.5. The other performance metrics showed improvementin the PT. The time-on-task decreased with 39%, Figure E.3, and the amount of mouse clicksdecreased with 42%, Figure E.4. The ASQ results show an increase on all axes, Figure A.2b.The effectiveness and efficiency axes are noteworthy here, with a 1.5-point and 2-point increaserespectively.

5.2.3 Calculator Tool


48

5.3 Non-Reviewed New Patterns

Description

During the requisition of an insurance policy the user is often asked to enter financial data whichis composed of multiple sub-amounts, for the amount of valuables insurance, for instance. It isoften the case that the system asks for a total amount first and sub-amounts later. This requiresthe user to do some calculating in their own head before entering the data.

A similar situation arises with the tax return program of the Belastingdienst. When a userhas to enter an amount which is dependant on other sub-amounts the program provides an extracalculator screen. This screen is not a straightforward calculator, data can be entered accordingto its semantics and the program calculates the total according to the context. Sub-amounts arealways retained and can be used recurrently elsewhere in the system if this is necessary.

The main issue that arises here is that we do not think it useful to let a user do any calculationof his own. If a user only possesses the sub-amounts, he should enter these and the system shouldcalculate the total itself. This not only simplifies the task for the user, who now has to enter lessdata elements and does not have to calculate anything, but arguably also lowers errors becausethe calculation is no longer done manually.


The pattern we defined here, simply put, is an adding tool, Figure 5.3. In our prototype, wecreated a set of fields in which sub-amounts were to be entered, Figure 5.3a. When the userentered data into these fields the total at the bottom of the field set was updated to display thetotal, Figure 5.3b.

In the scenario we used to evaluate this PT, Appendix C.2.3, we asked the users to enterfinancial data as if they were place a requisition for an insurance policy. In the original interfacenone of the users succeeded in this task correctly against 80% of the users succeeding in thePT, Figure E.6. The other perfomrance metrics show that ther was a decrease of 27% in thetime-on-task, E.7, a very negligable decrease in the amount of clicks, E.8, and a strong decreasein the amount of errors made, E.9. The ASQ results show a 1-point increasein efficiency andeffectiveness whereas the satisfaction rating stayed the same.

5.3 Non-Reviewed New Patterns

The following two patterns are patterns we found during this research but did not have time toprototype and evaluate. We therefore merely describe them and do not give any test results.The exact patterns can be found in the next chapter.

5.3.1 Power Text Edit

This pattern can be found in Section 6.4.As mentioned with the Unified Edit pattern in Section 5.2.2 the user often has to perform

repetitive and tasks when working with the Forms Administration System. An upcoming ten-dency is to use an external program which can record macros. This enables the user to record asingle iteration and then let the program repeat the same action for a selection of objects. Butthis is very tedious and time consuming. This function differs slightly from the Unified Editcontext in that, with that pattern users want to edit multiple objects to change an attributeto a single value. The users need a way to edit multiple similar objects at once even when theattributes they wish to change vary slightly.

The online survey tool SurveyGizmo displays such a function. Survey Gizmo allows the user tocreate multi-page surveys and distribute them. When creating a survey the user adds questions

49


(a) The fields start emtpy. . .

(b) . . . and the total is updated as the user inputs data

Figure 5.3: Screen shots of the prototype for the Calculator Tool pattern

50

5.4 Overview of Applicable Existing Patterns

to a page in that survey. If the question is multiple choice the user can edit all the answer optionsin one swoop with a special text area where all the answer options are displayed per line. Theoption attributes are displayed on the same line divided by pipe symbols1.

We envision an interface which is similar to that of Survey Gizmo. Perhaps combined withthe selection method proposed in United Edit or with an information hierarchical grouping, suchas ‘all the questions on a page’, these questions can be displayed in the new text area. Everyquestion object is displayed on its own line in the text area as flat text. The attributes of thatobject are divided by pipe symbols or an other defining symbol of choice. In this way the usercan make small adjustments over multiple objects and save them all in single action.

5.3.2 Levelled Search

This pattern can be found in Section 6.5.Sometimes when a policy is requisitioned in the Policy Requisition System it is not always

directly accorded. Sometimes data that needs to be entered is not available yet, the value ofthe house may need appraising, or the applicant needs to be screened in some form or other, forfraud for instance. In this case the incomplete insurance application can be saved for editing ata later date. When this happen users need to find this application and search for this policy.However a screen full of results is not useful for the user to see.

A fairly similar search task can be observed in the web shop Bol.com. Here users enter a titlefor something they wish to acquire. However the system has no way of knowing if the user islooking for books, DVDs or board games. This has to be deduced from the available stock orthe context. the system solves this by returning the results in categories. When entering the“Lord of the rings” into the search bar, the system returns top hits in the the categories: Dutchbooks, English books, music, DVDs and games. The user can then choose to continue in oneof these categories. The meta search engine Cuil2 also uses this category distinction. Searchingfor “jaguar” returns results in many different categories: the car, the operating system and thefootball team3.

What is interesting about this form of displaying results is that the user is searching for acertain item and has to find it via objects that are of a different abstraction level. In the case ofthe Policy Requisition System, the user is searching for a policy belonging to a specific person.So to find the policy it is easiest to find the person. We propose an interface in which the resultsof the search are grouped by an appropriate higher category. The result screen of policies shouldbe preceded by a screen with the people that hold them, thus minimising the need for browsingthrough results.


This section lists all pre-documented patterns which were applicable in the insurance software.The names correspond to the names used in Quince4 (Infragistics, 2009) so that they can befound easily. We will not describe these patterns themselves.

In Table 5.1 we give list patterns which are applicable but not yet implemented in the software.We give the name of the pattern and a description where it could be implemented. In Table 5.2we list all the patterns that are pre-documented and presently implemented. Here we give thename of the pattern and where it is implemented.

1a pipe symbol: ∣2http://www.cuil.com/3They however do not return any results for the animal, for some reason.4http://quince.infragistics.com/

51

http://www.cuil.com/

http://quince.infragistics.com/


Table 5.1: These are the pre-documented patterns which we thought would be useful to implement inthe software. They can be found in the Quince tool.

Pattern name Where it should be implemented

Alternating Row Colors This would be a great addition to the very tabular views of thesystem.

Cascading Lists This would useful in the edit screens where options are sometimesmulti-layered.

Clear Entry Points This is applicable on all of the entry screens for every application.These do not provide any indication of what a user can do with thesystem.

Closable Panels This could be very useful to display extra information or providelinks to tasks that are often used.

Dashboard This could be used in the Policy Requisition System in combinationwith Clear Entry Points, displaying the current status of policyrequisitions and actions related to them.

Inline Validation With so much data being entered into forms constantly, Inline Val-idation would be a real time saver for the user.

Input Prompt Possibly, as an alternative to Input Hints.

Journal Navigation When filling in the various wizards.

Large Set Single Selec-tor

When selecting questions or variables to enter into a form.

Liquid Layout There is often so much data that a filled out screen could providemore space to put it in and also provide some air for the data tobreathe.

Local Zooming Could be very useful when displaying ’extra’ information of objects.

Multiple Selection forma Large List

Useful to select questions when defining groups or forms.

New-Item Row This could be very useful when adding conditions to questions.

Preview We believe that this could be used to bridge the gap between thedata objects and the actual end result.

Primary Action This could be implemented in the Policy Requisition System to im-prove the guidance of the system.

Same Page Error Mes-sages

Errors are usually displayed in a central place, whereas it wouldbe more useful (espaecially in the large forms) to display multipleerrors directly next to the originating field.

Status Area This could be extremely useful in the more complex wizards todisplay progress or other relevant data.

Continued on next page

52


Table 5.1 – Continued from previous page

Pattern name Where it should be implemented

Task Pane This could be used on various start screens to speed up user activity.

Text Field Autocomple-tion

This could be used often in the various forms, for suggesting otherobjects which need to be referenced.

Titled Sections This could be used to group various tasks that are now scattered ina long list under ’Various’.

Transition Because screens look similar, it is not always clear that a screen hasrefreshed. Adding a transition to it may aleviate this.

Tree table This could be used in the same way as Local Zooming.

Table 5.2: These are the pre-documented patterns which we found were currently implement in thesoftware. They can be found in the Quince tool.

Pattern name Where it is implemented

Breadcrumbs Almost everywhere.

Button Groups Object edit screens.

Data Tips In the form of tool tips.

Date Picker Where a date needs to be entered in a form.

Forgiving Format With date and postcode fields.

Form The whole system.

Global Navigation Everywhere.

Grid Layout Everywhere.

Illustrated Choices In combination with action links (They could be used more fre-quently, though.).

Input Hints Near fields that have to adhere to a specific format.

Left Aligned Labels Almost everywhere.

Navigation tabs All the menus are structured in this fashion.

Paging The resultsets are so large that this is implemented on every resultscreen.

Property Sheet All object screens are property sheets.

Responsive Disclosure This is used so that parts irrelevant form parts are not displayed.

Search Is the entry screen to the applications.

Search Results Is the way all objects are displayed.

Continued on next page

53


Table 5.2 – Continued from previous page

Pattern name Where it is implemented

Sortable Table Is used when displaying certain reultsets.

Visual Framework Is implemented everywhere, but could be used a bit more consis-tently.

Wizard This pattern is used in for policy requisition, although it is notimplemented to its fullest potential.

Work With This is the standard pattern used for editing data objects.

54

6 The New Patterns

This chapter is a catalogue of all the new patterns which we found during this research.

6.1 Incremental Search

Name Incremental Search

Alias Finding a specific single item

Problem The user has to search a data set for a specific object which is neededin a larger task.

Usability Principle Minimising actions, Immediate feedback

Context The user has to either find this exact object or determine that itdoes not exist so that he can create it.

Forces – The user is not only searching for an object but needs to know ifthe object exists or not.– The search space is large enough for the user not to comprehendthe total dataset.

Solution Near to the search form, show a counter that displays the amountof hits according to the current criteria.

Update the counter in real-time while the user fills out the searchcriteria. Combine the counter with a progress bar and enable thebar to change colour as the solution space shrinks. The bar canturn green when the solution space is acceptably small and turn redwhen there the solution space has a size of zero.

Rationale The user can keep on filling in criteria until he reaches a solutionspace that is small enough to comprehend. This pattern gives abetter answer to if an object exists than a standard search becauseit can give insight into exactly which criteria make the search failand when. Also if the user fills in certain criteria which return nohits then the user can be sure that the desired object does not existand choose according actions. This improves satisfaction.This pattern speeds up the users search behaviour because theycan keep on filling out the search form until they are satisfied withthe result, which is usually faster than browsing results and thenrefining search criteria. This improves performance speed.

55

6 The New Patterns

Examples A Swiss online telephone book, http://tel.search.ch/, showshow the counter decreases while typing. Pressing enter shows thecurrent results, yet the user can continue typing.

6.2 Unified Edit

Name Unified Edit

Alias Editing objects simultaneously

Problem The user wishes to edit multiple data objects in a single pass.

Usability Principle Natural Mapping

Context The attributes of the objects the user wishes to edit all need to beset to the same value.

Forces – The objects can be collected in some manner (by use of a search)– The choice has to be made whether differing attribute values acrossobjects should be editable or not.

Solution Allow the user to select the elements he wishes to edit from a searchand add a multiple edit button.Visualise the collection which is to be edited, as if it were a singleobject, showing the editing screen in a normal fashion. Attributes ofwhich the values differ across objects should be editable but greyed.Attributes that are to tooc omplicated to edit in this manner shouldbe disabled. Add list to the screen that displays all the objects whichare being edited. After the attributes are edited they should be setidentically across all objects.

56

http://tel.search.ch/

6.2 Unified Edit

Rationale Performance speed is drastically increased because the user now onlyhas to perform the desired action a single time instead of once foreach object. Furthermore, the chance of errors is lowered becauseof this as well.

Examples The tool phpMyAdmin, http://www.phpmyadmin.net/, is a freedatabase administration program that enables users to selectmultiple objects which can then be edited simultaneously.

In Windows Filemanager, http://www.microsoft.com/windows/

WinHistoryDesktop.mspx, when you edit the properties of multiplefiles simultaneously, properties of which the values differ across filesare greyed out.

57

http://www.phpmyadmin.net/

http://www.microsoft.com/windows/WinHistoryDesktop.mspx

http://www.microsoft.com/windows/WinHistoryDesktop.mspx

6 The New Patterns

In Microsoft Powerpoint, http://www.microsoft.com/

powerpoint, the same thing happens when editing propertiesof multiple objects simultaneously. It is very subtle but here thevaluebox of width is greyed out.

6.3 Calculator Tool

Name Calculator Tool

Alias Creating a total sum

Problem The user needs to enter numerical data of which the value has to becalculated from certain sub-values.

Usability Principle Natural Mapping, Conceptual Model, Error prevention

Context The user does not have the required value directly available to himand has to perform a manual calculation before he can enter therequested data.

Forces – The sub-values not so complex that they can be entered into thesystem in a practical manner.– The calculation is always the same or it can be computed by thesystem according to the user’s input.

Solution Provide a helping calculator tool in which the user can enter thesub-values that are available to him.Let the system compute the requested value from the sub-values.However, save these sub-values so that the user can edit them later.

58

http://www.microsoft.com/powerpoint

http://www.microsoft.com/powerpoint

6.4 Power Text Edit

Rationale With this solution the user does not have to perform the calcula-tion himself. Not only does this, increase satisfaction because it iseasier for the user, it also lowers the error rate because the calcu-lation does not have to be performed by the user. With complexcalculations this can be a big issue. Moreover, the task completionrate is increased because user can now enter values which they dohave available to them and which require minimal cognitive process-ing. This solution also provides the user with a new feature thatallows him to ’play around’ with the sub-values to reach a desirabletotal-value.

Examples The tool that the Dutch revenue service, http://www.

belastingdienst.nl/ provides to enter tax returns, oftensasks for layered financial data. When the user is asked for thegeneral expenses of the household, he is provided with calculatortool which enables him to enter sub values which are available tohim so that the total can be calculated by the system.

6.4 Power Text Edit

Name Power Text Edit

Alias Quick text edit

Problem The user wishes to edit multiple similar data objects in a singlepass.

Usability Principle Affordance, Natural Mapping

Context The variables or values the user wishes to edit differ per object anda point and click interface is too slow for the user.

59

http://www.belastingdienst.nl/

http://www.belastingdienst.nl/

6 The New Patterns

Forces – The objects have to be gathered in some form (by using a search).If the gathering is insufficient to isolate the desired objects, the ob-jects also have to be selectable in some form (as with Unified Edit).– The user is an experienced user with a good understanding of theunderlying data model of the system.– The amount of objects that are to be edited should not be so largethat the user cannot oversee them in a single glance.– A need arises for a strong error check on the back-end of thisinterface because the user may inadvertently break objects or re-lationships between other objects which are dependant on theseobjects.

Solution Provide a text area field in which all the objects are shown per lineand their properties are divided by a defining symbol, such as a pipesymbol.The user can then edit all attributes of the objects at will and thensave them all in one single pass. Provide the syntax for the objectabove the text field so that the user has a reference as how to buildthe object correctly.

Rationale This increases both performance speed and satisfaction because itenables the user to edit many attributes at and objects in a veryunrestricted manner. Caution is advised, however. This patternshould only be applied for experienced users as it introduces marginfor error.

Examples The survey tool SurveyGizmo, http://www.surveygizmo.com/,allows users to edit the answer objects of multiple answer-typequestions using a text area.

. . . becomes . . .

60

http://www.surveygizmo.com/

6.5 Levelled Search Results

6.5 Levelled Search Results

Name Levelled Search Results

Alias Unclear object search parameters

Problem The user has to search a data set for a specific object which is neededin a larger task.

Usability Principle Affordance, Minimising actions

Context The search parameters the user has available are not sufficient todefine this exact object.

Forces – The objects need to be in a form information hierarchy so thatthe can be categorised.– The result set has to be large enough for categorisation to beuseful.

Solution Provide the user with the categories that contain matching objects.The user then selects one of these categories to browse through theresults in that category.

Rationale This increases satisfaction because the user is not forced to browsethrough a batch of results which are not relevant. Possibly it alsoincreases performance speed because there are less results to browsethrough. However, the user is required to perform an extra clickwhich can possibly counteract this speed gain.

61

6 The New Patterns

Examples The webshop Bol.com, http://www.bol.com/, asks its users torefine their search by category. They provide main categories centre-screen and sub-categories on the left hand side. They even expandon this pattern by providing relevant results in each category below.

62

http://www.bol.com/

7 Discussion and Conclusion

In this chapter we conclude this thesis. First we draw conclusions from the research results inChapter 5 and evaluate the research process in Section 7.1. Then we attempt to answer ourresearch questions in Section 7.2. Finally, we discuss which research agendas still remain andwhat future research should focus on in Section 7.3.

7.1 Evaluation

In Section 1.2.1 we stated that we had the following research goals.



We believe that we have accomplished both these goals to a certain degree and will discusshow successful we were in this section.

7.1.1 DUTCH in Combination with Pattern Engineering

To formalise a method for UID pattern identification we combined an existing software engineer-ing method called DUTCH with our own ideas about pattern engineering. We found DUTCHto be a useful as an evaluation method in the adapted form in which we used it.

DUTCH is a software engineering method that is oriented on task analysis. This is veryeffective when improving software in general but less when attempting to extract UID patterns.UID patterns, by definition, do not question user tasks; this is left to functional design patterns.UID patterns take the task at hand for granted and question the way the user executes it withthe system. The DUTCH method steers toward task analysis whereas we want to busy ourselveswith interface analysis. It costs quite some effort to constantly remind oneself of this.

The DUTCH method is a method that drives on progress. Each iteration is meant to deliverproduct versions that are an improvement to the version before it. In pattern engineering wewish for our pattern to improve over time, yet this does not mean that we wish for our prototypesto be strict improvements. We might wish to deliberately sabotage one of prototypes in a certainway to see if this affects its usability in any way. This is something that is not accounted for inthe DUTCH method.

In conclusion we believe DUTCH to be a very strong and useful method for engineeringsoftware. As a pattern evaluation method it is rather elaborate and in practice a minimalisticapproach might be more pragmatic.

7.1.2 Our Initial Method

Something we wish to note here is that DUTCH is an extremely good tool for evaluating thefunctions of a system in relation to its user. It requires us to make task descriptions, recordinggoals and a lot of background information. However this lead us to having tunnel vision at thebeginning of this research. We had defined an initial research method with DUTCH, which we

63


discovered in mid-process would not be suitable to answer our research questions. We changedthe set-up of our method during the course of this research to what is described in Chapter 4.Our initial research method and its preliminary results can be found in Appendix F.

In the initial method we wished to create a new interface for all of the three insurance systemswe analysed, applying newly found patterns in this new interface. This would be a classic taskfor DUTCH to be applied in. However, this would not have given us the detailed results ofwhich pattern worked and to what length it worked. This is the reason we decided to make smallprototypes implementing a single pattern and compare these to the original system.

7.1.3 The Patterns

We discovered five new patterns during this research. We were not able to implement two ofthese in a prototype and test them, so we will focus our attention on the three that we did review.

Incremental Search We think this pattern is the most solid of the lot. The ASQ results increasedon all axes and the performance showed drastic improvements. We de not believe there isanything to discuss here.

Unified Edit With this pattern performance metrics showed a strong increase in errors in theperformance metrics which is troubling. We believe this to have to have two causes. Thefirst being that the users attempted to perform the required task in the prototype in exactlythe same fashion they would in the original system. However this was not implementedwhich caused for some confusion and accounts for virtually all the errors. The secondcause, which is related to the first, is that the pattern was probably not clear enough.Once users were aware they had to go about the task in a different manner a few of themstill had to explore this a bit before they understood how to accomplish the task in the newinterface. This accounts for the remaining few error counts. We still believe the pattern tobe a success however, because of the strong increase on the efficiency and effectiveness axesin the ASQ results. This increase is to be expected as the pattern transforms a repetitivetask into a single task and eliminates extra actions.

Calculator Tool This pattern’s ASQ results show that the satisfaction remained the same. Webelieve that this is not a representative result of the pattern. Similarly to the Unified Editprototype we had only implemented the pattern and disregarded other elements of thesystem. However, during the evaluation the users wanted to use a help function to explainspecific terminology to them. Some of the users were dissatisfied by the fact that this helpfunction was disabled and took that into consideration when grading the prototype. Thelow success rating in the original system here requires some explanation. The reason thatall the users failed in the original system is not because they had to perform the calculation.The wording of the question for the input field was misleading, which caused them to missthe fact that they had to perform a calculation at all. Our pattern circumvents thisproblem. Because the calculation is done for the user and no longer asked, the wordingof the question is no longer and issue. The single task failure that still occurred with theprototype was due to the terminology problem mentioned above.

What the evaluations have taught us, is that to evaluate a pattern successfully we have to keepevery other element of the system the same, isolating the pattern variable as best as possible.We had not thought that unrelated elements would reflect in the evaluation scores the way theydid with the Calculator Tool pattern.

Summing up, we believe that these patterns are useful and can be a valuable addition toexisting pattern collections. They do require more evaluation than they have gotten and theUnified Edit and Calculator Tool patterns most probably require some refinement.

64

7.2 Answers to the Research Questions

7.2 Answers to the Research Questions

At the beginning of this thesis, in Section 1.3, we posed four research questions. In this sectionwe will answer them. Our questions were the following.

1. Which patterns are relevant to the insurance market?

2. What forces are applicable to these patterns?

3. When is pattern A applicable and when pattern B?

4. Is there such a thing as The Insurance Pattern?

The first three questions are answered in Chapter 5. The existing implemented patterns andrelevant non-implemented patterns that we found are listed there. We do not discuss thesepatterns any further because they are already well documented elsewhere. The new patternsthat we discovered can be found in Chapter 6. The forces and context are described there aswell and speak for themselves.

As for the last question, “Is there such a thing as The Insurance Pattern?”, we answer thiswith ‘no’. This is because we found that the insurance software turned out to be a specific form ofadministration system. This made comparison to other administration software an easy jump tomake. When defining abstract insurance objects, more often than not, no better representationis applicable than tables. This was prevalent in all other administration software we saw. Italso explains why the visuals are often so bland. However, we believe that usability can bedrastically improved by incorporating the the patterns mentioned in Table 5.1 and transformingthe system from being data oriented to being more task oriented. With so many similaritiesbetween administration software in general, we believe that the patterns we have found duringthis research are applicable to all administration software in general and not just insurancesoftware. This is can also be deducted from the tasks to which the patterns pertain, the searchingand manipulation of data objects. If the data object is a client in a CRM system or a receipt ina financial administration is not of importance. Of course, this is my no means a definite ‘no’.We have only evaluated part of a single insurance system and more systems should be analysedin future research to answer this question with more certainty.

7.3 Open Issues and Future Work

In this research we evaluated DUTCH as an evaluation method patterns during pattern engineer-ing. As stated there were issues with the use of this method and there are many other methodswhich can also be evaluated to see how they fit with pattern engineering. In this research we havedeviated so far from the standard DUTCH method and goals that it is questionable to speak ofthe DUTCH method. Possibly a new method needs to be defined in which pattern engineeringincorporates select elements of software engineering into its evaluation cycle. Another optionentirely, would be to investigate if patterns can extracted without a prototype evaluation cycleat all. By simply describing what you see intricately and using some form of logical evaluationor by using existing cases and comparing those instead of creating prototypes.

In the area of the patterns themselves we see possibilities for a lot of research. First of all,we only scratched the surface of insurance software with this research, analysing only threemodules of a single software package. First, the whole system could be analysed thoroughlyand second it should be compared to other insurance systems in more detail to complete thepicture. This will hopefully enlarge our set of new patterns and all of these can analysed againstother administration software packages to see if they apply there as well. On top of all this, our

65


set of new patterns now requires its own iterations of evaluation and improvement so that thespecifications of our new patterns are perfected.

In short there is more than enough work to be done.

66

Bibliography

Seffah Ahmed and Gaffar Ashraf. Model-based user interface engineering with design patterns.The Journal of Systems and Software, 80:1408–1422, October 2007.

W. Albert and E. Dixon. Is this hat you expected? the use of expectation measures in usabilitytesting. In Proceedings of the Usability Professionals Association 2003 Conference, Scottsdale,AZ, USA, 2003.

C. Alexander. The Timeless Way of Building. Oxford University Press, New York, 1979.

C. Alexander, S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl-King, and S. Angel. A PatternLanguage: Towns, Buildings, Construction. Oxford University Press, New York, 1977.

K. Beck, R. Crocker, G. Meszaros, J.O. Coplien, L. Dominick, F. Paulisch, and J. Vlissides.Industral Experience with design patterns. In Proceedings 18th International Conference Soft-ware Engineering, pages 103–114. IEEE Computer Society Press, 1996.

Christian Behrens. Information Design Patterns. Website, 2008. URL http://interface.

fh-potsdam.de/infodesignpatterns/. [Last accessed June 2009].

Joey Benedeck and Trish Miner. Measuring Desirability: New Methods for evaluating Desirabilityin a Usability Lab Setting. In Usability Professionals Association Conference, Orlando, FL,USA, July 8–12 2002.

B.W. Boehm. A Spiral Model of Software Development and Enhancement. IEEE Computer, 21(5):61–72, 1988.

J. Borchers. A Pattern Approach to Interaction Design. John Wiley & Sons, Chichester, UK,2001.

Jan Oliver Borchers. Patterns. Webpage, May 2006. URL http://www.hcipatterns.org/

patterns. [Last accessed June 2009 ].

John Brooke. SUS: A quick and dirty usability scale. In P. W. Jordan, B. Thomas, B. A.Weerdmeest, and I. L. McClelland, editors, Usability Evaluation in Industry. Taylor & Francis,London, UK, 1996.

William Brown, Raphael Malveau, Hays McCormick, and Thomas Mowbray. The SoftwarePatterns Criteria. Website, 1998. URL http://www.antipatterns.com/. [Last accessed June2009].

William J. Brown. Anti-Patterns: Refactoring Software, Architectures and Projects in Crisis.John Wiley & Sons, New York, 1999.

J. P. Chin, V. A. Diehl, and K. L. Norman. Development of and Instrument Measuring UserSatisfation fo the Human-Computer Interface. In ACM CHI ’88 proceedings, pages 213–218,1988.

67

http://interface.fh-potsdam.de/infodesignpatterns/

http://interface.fh-potsdam.de/infodesignpatterns/

http://www.hcipatterns.org/patterns

http://www.hcipatterns.org/patterns

http://www.antipatterns.com/

Bibliography

ChipSoft. Integratie azd en cs-ezis. Webpage, 2009. URL http://www.chipsoft.nl/Mediair/

Archief/032006/AZD.htm. [Last accessed June 2009].

CODA Ltd. Coda 2go screenshots. Webpage, 2009. URL http://www.coda2go.com/

applications/resources/screenshots. [Last accessed Jun 2009].

Computer Associates Plex Wiki. What is Plex? Wiki Website, November 2008. URL http:

//wiki.plexinfo.net/index.php?title=What_is_Plex%3F. [Last accessed June 2009].

Bruce Eckel. Electronic book: Thinking in patterns with java: Problem-solving techniques usingjava. Electronic Book, 2009. URL http://mindview.net/Books/TIPatterns/. [Revision0.9].

Elvia. Anleitung Tour Online. Mondial Assistance (Schweiz) AG, Wallisellen, Switserland. URLhttp://www.elvia-eps.ch/pdf/EPS_Anleitung_d.pdf.

Tom Erickson. The Interaction Design Patterns Page. Webpage, March 2009. URL http:

//www.visi.com/˜snowfall/InteractionPatterns.html. [Last accessed June 2009].

Sally A. Fincher. Hci pattern-form gallery. Webpage, August 2008. URL http://www.cs.kent.

ac.uk/people/staff/saf/patterns/gallery.html. [Last accessed June 2009].

Eelke Folmer. Interaction design pattern library for games. Website, 2008. URL http://www.

helpyouplay.com/. [Last accessed June 2009].

Martin Fowler. Analysis Patterns: Reusable Object Models. Addison-Wesley Professional, 1996.

Eric Gamma, R. Helm, and J. Vlissides. Design Patterns: Elements of Reusable Object-OrientedSoftware. Addison-Wesley, Reading, 1995.

J.J. Garrett. AJAX: A New Approach to Web Applications. Essay, February 2005. URL http://

www.adaptivepath.com/ideas/essays/archives/000385.php. [Last accessed March 2009].

Elbert-Jan Hennipman. The Pattern Design Wizard. Website, 2008. URL http://www.

elbert-jan.nl/testCG/. [Last Accessed June 2009].

Elbert-Jan Hennipman, Evert-Jan Oppelaar, and Gerrit C. Van der Veer. Pattern Languagesas Tool for Discount Usability Engineering. In Interactive Systems. Design, Specification, andVerification, number 5136 in Lecture Notes in Computer Science, pages 108–120. SpringerBerlin / Heidelberg, July 2008.

Thomas T. Hewett, Ronald Baecker, Stuart Card, Tom Carey, Jean Gasen, Marilyn Mantei,Gary Perlman, Gary Strong, and William Verplank. Acm sigchi curricula for human-computerinteraction. Website, 1996. URL http://sigchi.org/cdg/.

Hilarius Media. Unive maakt levensverzekeringen rendabel met panklare IT-oplossing vanMonuta. Webpage, June 2003. URL http://www.systemimagazine.nl/html/archief/2003/

jun/1320.html. [Last accessed June 2009].

IBM. Solution Starter: Project Server to Siebel. Webpage, 2009. URL http://msdn.microsoft.

com/en-us/library/aa168486%28office.11%29.aspx. [Last accessed June 2009].

Infragistics. Quince. Website, 2009. URL http://quince.infragistics.com/. [Last accessedJune 2009].

68

http://www.chipsoft.nl/Mediair/Archief/032006/AZD.htm

http://www.chipsoft.nl/Mediair/Archief/032006/AZD.htm

http://www.coda2go.com/applications/resources/screenshots

http://www.coda2go.com/applications/resources/screenshots

http://wiki.plexinfo.net/index.php?title=What_is_Plex%3F

http://wiki.plexinfo.net/index.php?title=What_is_Plex%3F

http://mindview.net/Books/TIPatterns/

http://www.elvia-eps.ch/pdf/EPS_Anleitung_d.pdf

http://www.visi.com/~snowfall/InteractionPatterns.html

http://www.visi.com/~snowfall/InteractionPatterns.html

http://www.cs.kent.ac.uk/people/staff/saf/patterns/gallery.html

http://www.cs.kent.ac.uk/people/staff/saf/patterns/gallery.html

http://www.helpyouplay.com/

http://www.helpyouplay.com/

http://www.adaptivepath.com/ideas/essays/archives/000385.php

http://www.adaptivepath.com/ideas/essays/archives/000385.php

http://www.elbert-jan.nl/testCG/

http://www.elbert-jan.nl/testCG/

http://sigchi.org/cdg/

http://www.systemimagazine.nl/html/archief/2003/jun/1320.html

http://www.systemimagazine.nl/html/archief/2003/jun/1320.html

http://msdn.microsoft.com/en-us/library/aa168486%28office.11%29.aspx

http://msdn.microsoft.com/en-us/library/aa168486%28office.11%29.aspx

http://quince.infragistics.com/

Bibliography

International Standards Organisation. Ergonomic Requirements for Office Work with VisualDisplay Terminals (VDTs); Part 11 — Guidance on Usability, 1998.

Godfrey Jackson. A Pattern Language. Webpage, 2008. URL http://www.jacana.plus.com/

pattern/index.htm. [Last accessed June 2009].

Steve Krug. Don’t make me think! A common sense approach to Web usability. New RidersPress, Indianapolis, 2000.

Tibor Kunert. User -Centered Interaction Design Patterns for Interactive Digital TelevisionApplications. Human-Computer Interaction Series. Springer Verlag London, 2009.

J. R. Lewis. IBM Computer Usability Satisfaction Questionnaires: Psychometric Evaluation andInstructions for Use. International Journal of Human-Computer Interaction, 7(1):57–78, 1995.

J.R. Lewis. Psychometric Evaluation of an After-Scenario Questionnaire for Computer UsabilityStudies: The ASQ. SIGCHI Bulletin, 23(1):78–81, 1991. Also see http://oldwww.acm.org/

perlman/question.cgi?form=ASQ.

Rensis Likert. A Technique for the measurement of Attitudes. Archives of Psychology, 140(55):1–55, 1932.

Arnold Lund. Measuring Usability with the USE questionnaire. Usability and User ExperienceNewsletter, 2001. URL http://www.stcsig.org/usability/newsletter/0110_measuring_

with_use.html. [Last accesssed June 2009].

Arnold Lund. Personal communication, May 2009.

Deborah J. Mayhew. The Usability Engineering Lifecycle: A Practitioners Handbook for UserInterface Design. Morgan Kaufman Publishers, Inc., SF, CA, 1999.

M. McGee. Usability Magnitue Estimation. In Proceedings of the Human Factos and ErgonomicsSociety Annual Meeting, Denver, CO, USA, 2003.

Gerard Meszoras and Jim Doble. Pattern Languages of Program Design 3, chapter A PatternLanguage for Pattern writing, pages 527–574. Addison-Wesley, Reading, MA, USA, 1998.URL http://www.hillside.net/patterns/writing/patternwritingpaper.htm.

MI Consultancy. Demonstratie filmpjes van norma. Demo clips, 2009. URL http://www.

miconsultancy.com/nl/index.php?option=com_content&task=view&id=31&Itemid=50.[Last accessed June 2009].

NIBE-SVV. Thuis in de verzekeringsbranche. Krips B.V., Meppel, Netherlands, 5 edition, 2006.

J. Nielsen. Usability Engineering. Academic Press, Boston, San Diego, CA, USA, 1993.

D. Norman and S. Draper. User Centered System Design; New Perspectives on Human-ComputerInteraction. Lawrence Erlbaum Associates, Inc. Lahwah, NJ, USA., 1986.

Donald Norman. The Design of Everyday Things. Basic Books, 1998.

M. Porteous, J. Kirakowski, and M. Corbett. SUMI User Handbook. University College, Cork,Ireland, 1993. see http://sumi.ucc.ie/.

Quinity. Oplossingen voor verzekeraars. Leaflet, Utrecht, The Netherlands, 2003a.

69

http://www.jacana.plus.com/pattern/index.htm

http://www.jacana.plus.com/pattern/index.htm

http://oldwww.acm.org/perlman/question.cgi?form=ASQ

http://oldwww.acm.org/perlman/question.cgi?form=ASQ

http://www.stcsig.org/usability/newsletter/0110_measuring_with_use.html

http://www.stcsig.org/usability/newsletter/0110_measuring_with_use.html

http://www.hillside.net/patterns/writing/patternwritingpaper.htm

http://www.miconsultancy.com/nl/index.php?option=com_content&task=view&id=31&Itemid=50

http://www.miconsultancy.com/nl/index.php?option=com_content&task=view&id=31&Itemid=50

http://sumi.ucc.ie/

Bibliography

Quinity. De Quinity Formulierencomponent. Leaflet, Utrecht, The Netherlands, 2003b.

Quinity. Quinity Insurance Solution. Booklet, Utrecht, The Netherlands, 2005.

A. Richter. Generating User Interface Design Patterns for Web-based E-business Applications.In INTERACT 2003 - 2nd Workshop on Software and Usability Cross-Pollination: The Roleof Usability Patterns, Zurich, Switzerland, September 2003. Siemens AG, Competence Cen-ter User Interface Design. URL http://www.swt.informatik.uni-rostock.de/deutsch/

Interact/09%20Richter.pdf.

W.W. Royce. Managin the development of large software systems: Concepts and tehcniques. InProceedings IEEE WESCON, pages 1–9. IEEE, 1970.

SAP A.G. Sap erp demos. Demo clips, 2009. URL http://www.sap.com/solutions/

business-suite/erp/demos/index.epx. [Last accessed June 2009].

T. Schummer, J. Borchers, J. Thomas, and U. Zdun. Human-computer-interaction patterns:workshop on the human role in HCI patterns. In Conference on Human Factors in ComputingSystems, pages 1721–1722, 2004.

A. Seffah and H. Javahery. On the Usability of Usability Patterns - What can make patternsusable and accessible for common developers. In Workshop entitled Patterns in Practice, ACMCHI Conference, Mineapolis, MI, USA, April 2002.

K. Segerstahl and T. Jokela. Usability of Interaction Patterns. In Conference on Human Factorsin Computing Systems, pages 1301–1306, 2006.

Jeroen Snijders. Functional design patterns. Masterthesis, University of Utrecht, Utrecht, TheNetherlands, August 2004.

Patrick Stapleton. UI Pattern Documentation Review. Article, June 29 2009. URL http:

//www.boxesandarrows.com/view/ui-pattern. [Last accessed August 2009].

The Future Group. Allianz - java case study. Webpage. URL http://www.the-future-group.

com/index.php/allianz. [Last accessed June 2009].

Jenifer Tidwell. Common Ground Collection: A Pattern Language for Human-Computer In-terface Design. Website, 1999. URL http://www.mit.edu/˜jtidwell/common_ground.html.Last accessed March 2009.

Jenifer Tidwell. Designing Interfaces: Patterns for Effective Interaction Design. Website, 2005.URL http://www.designinginterfaces.com/. [Last accessed June 2009].

Jenifer Tidwell. Designing Interfaces. O’Reilly Media, Inc., 1005 Gravenstein Highway North,Sebastopol, CA 95472, USA, 2nd edition edition, 2006.

E. Todd, E. Kemp, and C. Philips. What makes a good user interface pattern language? InProceedings of the fifth conference on Australasion user interface, volume 28, pages 91–100,2004.

Anders Toxboe. UI-patterns.com. Website, 2009. URL http://ui-patterns.com/. [Lastaccessed 2009].

Tom Tullis and Bill Albert. Measuring the User Experience - Collecting, Analyzing and Present-ing Usability Metrics. Morgan Kaufman Publishers, Burlington, MA, USA, 2008.

70

http://www.swt.informatik.uni-rostock.de/deutsch/Interact/09%20Richter.pdf

http://www.swt.informatik.uni-rostock.de/deutsch/Interact/09%20Richter.pdf

http://www.sap.com/solutions/business-suite/erp/demos/index.epx

http://www.sap.com/solutions/business-suite/erp/demos/index.epx

http://www.boxesandarrows.com/view/ui-pattern

http://www.boxesandarrows.com/view/ui-pattern

http://www.the-future-group.com/index.php/allianz

http://www.the-future-group.com/index.php/allianz

http://www.mit.edu/~jtidwell/common_ground.html

http://www.designinginterfaces.com/

http://ui-patterns.com/

Bibliography

Unigarant N.V. Fiets premie berekening. Webpage, 2008. URL https://www.unigarant.nl/

UnigarantWebsite/Verzekeringen/Verzekeringen/Fiets/PremieBerekenen.htm. [Lastaccessed June 2009].

Usability Professionals Association. What is Usability? Webpage, 2009a. URL http://www.

upassoc.org/usability_resources/about_usability/definitions_of_usability.html.[Last accessed June 2009].

Usability Professionals Association. More Definitions of Usability. Webpage, 2009b. URL http:

//www.upassoc.org/usability_resources/about_usability/definitions.html. [Lastaccessed June 2009].

J. Van Biljon, P. Kotze, K. Renaud, M. McGee, and A. Sheffah. The use of anti-patterns inhuman computer interaction: wise or ill-advised? In Proceedings of the 2004 annual researchconference of the South African institute of Computer scientists and information technologistson IT research in developing countries, pages 176–185, 2004.

Gerrit C. Van der Veer and Martijn Van Welie. DUTCH - Designing for Users and Tasksfrom Concepts to Handles. In Dan Diaper and Neville Stanton, editors, The Handbook ofTask Analysis for Human-Computer Interaction, chapter 7, pages 155–173. Lawrence Erlbaum,Inc., 2003. URL http://www.cs.vu.nl/˜martijn/gta/docs/chapterDUTCHv2.3.pdf. [Lastaccessed March 2009].

Douglas K. Van Duyne, James A. Landay, and Jason I. Hong. The Design of Sites: Patterns,Principles, and Processes for Crafting a Customer-centered Web Experience. Addison-WesleyProfessiona, Reading, 2003.

Douglas K. Van Duyne, James A. Landay, and Jason I. Hong. The Design of Sites. Website,2006. URL http://www.designofsites.com. [Last accessed June 2009].

Hans van Vliet. Software Engineering: Principles and Practice. John Wiley & Sons, Ltd,Chichester, 2000.

M. Van Welie, G.C. Van der Veer, and A. Eliens. Patterns as Tools for User Interface Design.In Jean Vanderdonckt and Christelle Farenc, editors, International Workshop on Tools forWorking with Guidelines, pages 313–324. Springer, October 7–8 2000. URL http://www.cs.

vu.nl/˜martijn/gta/docs/TWG2000.pdf. [Last accessed March 2009].

Martijn Van Welie. Task-Based User Interface Design. PhD thesis, SIKS, 2001.

Martijn Van Welie. The Amsterdam Pattern Collection. Website, 2009. URL http://www.

welie.com/patterns/. [Last accessed June 2009].

Martijn Van Welie and H. Traetteberg. Interaction Patterns in User Interfaces. In PLoP 2000conference, 2000.

Martijn Van Welie and Gerrit C. Van der Veer. Pattern Languages in Interaction Design: Struc-ture and Organization. In Proceedings of Interact, number 3, pages 1–5, 2003.

Vrije Universiteit. The domain of the Master Information Sciences (IS). Webpage, 2008. URLhttp://www.few.vu.nl/onderwijs/masters/is/. [Last accessed April 2009].

Cathleen Wharton, Riemand John, Clayton Lewis, and Peter Polson. Usability Inspection Meth-ods, chapter The Cognitive Walkthrough Method: A Practitioner’s Guide, pages 105–140.John Wiley & Sons, Inc., NY, USA, 1994.

71

https://www.unigarant.nl/UnigarantWebsite/Verzekeringen/Verzekeringen/Fiets/PremieBerekenen.htm

https://www.unigarant.nl/UnigarantWebsite/Verzekeringen/Verzekeringen/Fiets/PremieBerekenen.htm

http://www.upassoc.org/usability_resources/about_usability/definitions_of_usability.html

http://www.upassoc.org/usability_resources/about_usability/definitions_of_usability.html

http://www.upassoc.org/usability_resources/about_usability/definitions.html

http://www.upassoc.org/usability_resources/about_usability/definitions.html

http://www.cs.vu.nl/~martijn/gta/docs/chapterDUTCHv2.3.pdf

http://www.designofsites.com

http://www.cs.vu.nl/~martijn/gta/docs/TWG2000.pdf

http://www.cs.vu.nl/~martijn/gta/docs/TWG2000.pdf

http://www.welie.com/patterns/

http://www.welie.com/patterns/

http://www.few.vu.nl/onderwijs/masters/is/

Bibliography

Yahoo! Design Pattern Library. Website, 2009. URL http://developer.yahoo.com/ypattern.[Last accessed June 2009].

72

http://developer.yahoo.com/ypattern

Defining User Interface Design Patterns in the Insurance...

Documents

Transcript of Defining User Interface Design Patterns in the Insurance...