Designing acceptable user registration processes for e-services

User registration can have a serious impact on the success of online government services. Different services require different levels of identity assurance, and different registration processes are put in place to deliver them. But from the citizen’s perspective, these processes often require a disproportionate amount of effort, which reduces users’ acceptance. Typically, when sign-up to high-effort services is not mandatory, take-up is low; when it is compulsory, it causes resentment, and neither is desirable. Designers of services requiring registration currently have no way of assessing likely user acceptance at design time. We are introducing a tool that allows system designers to identify the impact of registration processes on different groups of users, in terms of workload and friction. Personas have been successfully applied to assist security designers, and we extend the concept with statistical properties, and introduce the Persona Group Calibration (PGC) exercise to calibrate the different personas for sensitivity to specific identity-related elements.


INTRODUCTION
The registration process for any e-service can have a dramatic impact on the user's lived experience.There is empirical evidence that cumbersome registration processes reduce the number of service users (egovbarriers.org 2007).Security measures adopted should not be a burden on users (OECD 2007).User behaviour is goal-driven they sign up to an e-government service because they need to complete a task (Sasse & Flechais 2005), and barriers to completing such tasks have a significant negative impact on the user's lived experience (Inglesant & Sasse 2007).If registration processes for e-services are too cumbersome, citizens are discouraged in the earliest stages, and may never experience the potential benefits of transacting online.To support designers of eservices, we have developed a citizen-centric technique that allows us to capture the user's sensitivity to registration process design elements and help us predict the expected workload and level of friction (chances that a user leaves the process) caused by new registration processes.The technique is based on an empirical exercise (Persona Group Calibration) to identify causes of friction within the registration process.This information is then used to predict expected reactions to new designs across different projects.
In the Compliance Budget, Beautement, Sasse & Wonham (2008) define friction as the imbalance between the business process (user goals) and security behaviour required, including any inherent cognitive and physical workload.In our model, workload is measured as a separate factor since it was found that workload and friction are not always linearly related: registration pages with high workload values might still result in low friction, for instance when online access makes their lives easier (e.g. because it removes the need to travel to an office only open for certain hours).Thus we introduce the Type of Service (i.e. level of regular compulsion) to explain this phenomenon.

THE METHOD
The following section describes the method we have developed to capture user's sensitivity to friction in e-service registration processes, followed by an outline of the process to apply this information in a prediction model to forecast friction (including workload).

Setting the foundations
In this section we will establish the set of design elements that have a negative impact on the user's lived experience (causing a negative reaction, such as frustration and even service abandonment).We conducted an empirical study to determine the main points that cause workload and frustration in e-service registration processes.Five design elements were identified.These are grounded in empirical data and discovered through the adoption of techniques borrowed from Grounded Theory: open and axial coding (Charmaz 2006) We also noted that these design elements are weighted differently depending on the regularity of compulsion for an e-service being discussed.For this purpose, we had to consider the Type of Service (ToS) as a behavioral modifier.The Type of Service can be defined as: the number of times users are legally obliged to use a service in any given year.These can be summed up in 4 levels: ─ Level 1: No legal obligation to use the service ─ Level 2: Legal obligation to use service at most a couple of times in a lifetime ─ Level 3: Legal obligation to use service at most once per year ─ Level 4: Legal obligation to use service multiple times per year At Levels 3 and 4 penalties apply when citizens do not comply with set regulations (e.g.deadlines), while benefits exist for compliance.For Levels 2, 3 and 4 citizens can alternatively send forms by post.

Persona Group Calibration (PGC)
Adhering to citizen-centric design principles we developed personas following Cooper's recommendations and through successive refinements, starting from a plausible approximation of our user, supplementing it with experience, interviewing and secondary data, we move towards a fictitious user archetype having specific characteristics, needs and goals (Cooper 2004).To predict the expected reactions of different personas towards specific design elements in registration processes, we first need to understand how persona representatives behave when facing different tasks.These representatives participate in a Persona Group Calibration (PGC) exercise which in turn provides us with a set of behavioural parameters.Representatives of a persona under investigation may obtain similar results to representatives of another persona.In this case, these two personas can then be grouped under a single persona group.A persona group encompasses one or more personas that share a common factor: behaviour when facing different design elements in registration processes.
We needed to set the assessment in the context of a set of pre-defined registration tasks; to identify these, we surveyed the registration processes on a number of e-government portals, and for each eService identified, we measured design elements defined in Section 2.1, except for workload.Perceived workload is user-specific, and can only be measured during calibration.From this exercise the most common registration page setups used in e-services were generalized into nine different fictitious registration processes.The registration processes cover as many configurations as possible in order to capture the widest range of data from test participants.Extreme configurations are also present within the set of nine processes (e.g. from a simple email/password registration process and up to lengthy and laborious processes which also require physical travelling).
Based on the pre-defined tasks, we built a mechanism that helps us capture user behaviour, providing us with enough data to be able to predict friction on different configurations of design elements.We created a fictitious government portal offering 9 e-services with different registration processes.PGC participants were asked to go through each registration process.After each task, the participant was asked to rate 6 workload scales assessing the different dimensions as specified in NASA-TLX (Mental Demand, Physical Demand, Temporal Demand, Performance, Effort and Frustration).Following the 9 tasks, the participant was asked to give a weighting for each of the six scales by completing a pair-wise comparison exercise.For a full discussion on NASA-TLX, the reader is directed to Hart & Staveland (1988).After each of the nine registration tasks, the participant is also required to state whether he/she would consider completing the process (given the current registration process configuration), and such decision needs to be taken in four situations, one for each level defined in the Type of Service design element.To rate friction, participants are asked the following question: "Given this registration process, would you consider registering for this service?"Four 10-point Likert scales ranging from 0 to 1 (with increments of 0.1) are presented, one for each of the four Type of Service levels.
After completing the 9 tasks, the participant's data collected was transferred to a spreadsheet for further processing.Each sheet contains 9 rows, (one for each task) whereby each row holds the task ID, rating for each NASA-TLX workload scale, a computed overall weighted workload measure for each task, and friction for the four type of service levels.Once the participants from a specific persona group complete the PGC exercise, all of their data is merged and prepared for further processing.To be able to predict friction and workload we first need to fit two regression models on our data: a) Linear Regression Model for workload and b) Binary Logistic Regression Model for friction.After fitting these two models on the data (using a statistical package), we are provided with a y intercept (b 0 ) together with a set of regression coefficients, one for each design element, explaining the model's fit on our data.These coefficients can be defined as a persona group's behavioural properties with regards to the different design elements present in registration processes (see Section 2.1).These coefficients are then associated with the persona group under investigation.We found that certain design elements (predictors) are not statistically significant in the prediction of workload and friction.For this purpose and following proper model fitting techniques and statistical tests, only the most significant elements are used for both friction and workload models.Friction was best explained by IG, D, I and Type of Service, while Workload was best explained by ItR, D and I.This process allows us to capture a specific persona group's sensitivity to different design elements (using regression coefficients).We now apply these insights to elicit the level of friction and workload in new (or existing) registration processes.For this purpose one final step is required.For a specific registration process, we need to determine the values for each of the design elements defined in section 2.1.These are the required predictors, which together with the regression coefficients determined in the previous step, would allow us to generate friction and workload values.The regression coefficients, y intercepts and predictor values are then parameterized into the following two equations: The first equation is the linear regression model, where Y is the outcome variable (predicted worklaod).

( ) ( )
The second equation is a binary logistic regression model, where P(Y) is the probability that a person completes the registration process, where 1-P(Y) is defined as the probability that a person abandons the registration process.
In both cases, b 0 is the y intercept for the model while b n is the coefficient for the corresponding predictor X n (design element value).These coefficients will vary across different persona groups based on the output from the PGC exercise.
After calculating Y and P(Y), we obtain a grounded idea of how a particular persona group reacts to a given design.Given the designers objectives (e.g.friction < 10%) an iterative process commences whereby the registration process is revisited, modified and re-assessed as part of a larger business process.This helps designers achieve a balance between the level of identity-assurance required (security goals) and the friction caused on the business process from the perspective of different user groups.

CASE TOOL
The method described in Section 2 is laborious, therefore we developed a decision support system to assist decision makers in the iterative assessment of design alternatives.Persona groups are stored in a persona library, making them available for re-use in different projects.This collaborative web-portal was developed using ASP.Net MVC 3. SPSS is used to generate the statistical parameters after each PGC exercise.

CASE STUDY
Formative evaluation of the method and corresponding tool was carried out through a realworld case study.A collaborative agreement was set up with a government agency in Malta (Employment and Training Corporation -ETC).

Objectives
ETC's management wanted to create an e-service to be used by the majority of human resource managers on the island.This requires a registration process that is acceptable by, and that does not add considerable burdens on users.

Method
We considered the HR Manager persona group for this study, and a number of representatives from several leading IT firms were contacted to participate in the first PGC exercise.Data was collected and prepared for processing.The two regression models were applied and the respective 4 sets of coefficients (and y intercepts) were generated and assigned to the persona group under investigation.This allowed us to analyse the impact that the registration process might have on this persona group.The registration process required users to visit a registration authority in person and after verifying their identity, a PIN would be sent by post.Once received, a new password is requested in order to activate the account.This can be annotated as follows:

Results
The predictors (design element measurements) were parameterized into the regression equations, together with the respective y intercepts and regression coefficients, and values for friction and workload were obtained.Projected friction given the registration process and type of service under consideration was of 44% (i.e.1-P(Y) == (1-0.557)*100)) with a workload of 71%.This meant that almost half of the potential users would have abandoned the registration process and opted for alternative means.This has led management to reconsider their original plans and revert to alternative registration processes.One option was to offset the physical workload by requesting additional information, verifying such data manually while eliminating the need to visit a registration authority.A new registration process was devised with the following measurements: This resulted in improved values with friction at just over 10% -however, workload increased to 75%.In situations where the Type of Service is high people are ready to accept higher levels of workload in order to gain access to this kind of service (making their lives easier for future interactions), hence the low level of friction.

CONCLUSIONS
Beautement, Sasse & Wonham (2008) presented the Compliance Budget paradigm which denotes that compliance issues are mainly caused by friction between the required security behaviour and the user's goals.Our work helps to quantitatively approximate the point at which users decide not to comply with the required security in registration pages.We plan to adopt and extend Faily & Fléchais' Persona Cases (Faily & Fléchais 2011).These personas, grounded in empirical data, would be associated with persona groups adding behavioural knowledge to such, which knowledge is in turn used to predict friction and inherent workload.Giving a 'voice' to personas through predictive statistical parameters, allows designers to make informed design decisions based on measurable and comparable values.
Larger PGC exercises (with more participants) will result in more fine-tuned predictions however a statistical saturation point exists.The first case study gives a clear indication that the mechanics of the method (and corresponding tool) yield useful information.The captured knowledge on persona groups under investigation can be reused across different projects.We are confident that this method, and associated tool, will help designers garner further insights on their users which would in turn improve design decisions.

Table 1 :
Annotation of proposed registration process

Table 2 :
Annotation of redesigned registration process