Keywords

1 Introduction

Every day we are in contact with some product/software that requires some form of human interaction. Alarm clocks, mobile devices and remote controls all depend on our interaction. It is important to assess how easy it is to use these daily products. We must look at the process of Interaction Design, which is defined as “creating experiences that improve and understand the way of people work, communicate and interact” (Preece et al. 2015).

Interaction Design has been studied through the subject Human-Computer Interaction (HCI). This subject is “worried about evaluation and implementation of interactive computer systems for human use and with the study of the main phenomena around them” (Rocha and Baranauskas 2003).

This process tries to increase quality of software in regards to human interaction with and perception of said software. Unfortunately, many products are not necessarily designed with the user in mind (Preece et al. 2015).

In other words, whoever designed the product did not think about the end user that would use it, often making it difficult for the user to interact with the product.

In order to improve user interaction with the system, HCI attempts to redirect user concern, bringing usability, the degree to which a product or system can be used by specific users to achieve specific goals such as effectiveness, efficiency and satisfaction in a specific usage context (SQuaRE 2011). For the user, the software is the interface, so your design should adapt to it, not the other way around. In his book, Norman (2013) says:

To create a technology that suits the human being, it is necessary to study it. However, today we have a tendency to study only technology. Therefore, people are required to adapt to technology. The time has come to reverse the trend, the time to make technology fit for people.

The interface is a system item that can affect the quality of the product, so it is important to analyse and adapt it according to the user need. According to Crosby (1992) “Quality is conformity to requirements”, what means, if a product is fulfilling all its requirements, it has quality. However, the concern with software quality goes beyond the quality of the code. Quality aspects perceivable by the user should also be considered. In order to establish standards in the quality aspect of the software product, the International Organization for Standardization (ISO) has created a set of standards, which have been called Systems and software Quality Requirements and Evaluation (SQuaRE). This standard defines characteristics and sub-characteristics of quality.

It is necessary to define the quality characteristics to be achieved in the software. SQuaRE can help with this definition, as a great difficulty is to be able to evaluate these characteristics once they are defined. For this purpose, software measurement, which is “a quantitative evaluation of any aspect of Software Engineering processes and products”, can be used (Bass et al. 1999). The Goal Questions Metrics (GQM) method, which starts from a top-down approach, is widely used for measurement. The GQM starts from the measurement objective, following to the questions from which metrics are derived.

With the aim to capture the user aspects and improve the system interface quality, this paper proposes an interaction design process oriented by metrics using as a base an existed process in the literature.

The remainder of this paper is organized as follows: Sect. 2 presents the project methodology. Section 3 addresses the literature review. Section 4 details the interaction design process oriented by metrics defined, and the Sect. 5 the validation of it. The conclusion and future works are presented in Sect. 6.

2 Methodology

In order to define an interaction design process oriented by metrics to measure quality aspects during the process and not only in the final product, this work was divided into four stages:

  • The first stage is a literary review based on the principles of a systematic review in Software Engineering, following a protocol, to identify the existing interaction design processes;

  • The third stage was defining the process;

  • The last stage was the process validation using questionnaire.

3 Literature Review

This section shows a resume of the literature review made, based on a systematic review in Software Engineering area. Its purpose was to achieve the specific goal of identifying a detailed interaction design process. The review was divided into three phases: planning, research execution and results analysis.

3.1 A Subsection Sample

In the planning phase, the objectives, the research questions and the search strategy were defined.

  • I - Objective – The literary review goal is to identify an already existing interaction design process with a high detailed level, so then, to reach the research general objective.

  • II - Research execution - To reach the literary review specific objective, a research execution was defined.

    • Q1 – Which are the existing interaction design processes, considering a high detailed level?

  • III - Search strategy for task selection – The search string was defined in Portuguese and also used in English, using logical operator ‘and’ and ‘or’. The following search strings have been defined:

    • ((“process”) and (usability” or “HCI” or “interface design” or “interaction design” or “centred user”))

    • or ((“software engineering process”) and (“HCI”))

    • or (“interaction design”) or (“HCI”).

In order to identify relevant primary studies in the existing creation of the interaction design process oriented by metrics research, we defined the following selection criteria:

Inclusion criteria:

  • Studies written in English, Portuguese and Spanish with any aspect of interaction design process oriented by metrics as main focus.

  • Papers and books starting from 1989.

Exclusion criteria:

  • Studies outside the scope of this research;

  • Studies that do not provide enough evidence for this research;

  • Duplicate studies. When a study has been published in more than one conference, workshop or journal, the most complete version will be used, i.e., the one which explains it in more detail.

3.2 Execution

Initially, 160 articles and 8 books were identified, resulting in 168 works. First, there was an elimination of works that were not possible from finding any process reference. Later, there was a selection of works, which referee to HCI process or Usability Interaction Design, integrated or not to other applications, methodologies or processes. Lastly, eleven (11) remained to get data collect.

3.3 Result Analysis

In the final literary review, it was noticed that the most HCI process study is connected to make a relation from HCI process integration to the software development process. The works were analyzed according to their level of detail, where this level refers to contain activities, description of activities, tasks to be performed within each activity, inputs and outputs of the activity, and artefacts. After these analyses, the Deborah Mayhew book “The usability engineering lifecycle” (1999), was selected to assist as a basis for the definition of the interaction design process oriented by metrics.

4 Interaction Design Process Oriented by Metrics

For the development of the interaction, design process oriented by metrics proposed in this work, the Mayhew (1999) process was used as the basis. Thus, it is worth mentioning that because it was based on an already existing process, some specifications of the activities are similar to those defined by Mayhew (1999).

For the development of the interaction, design process oriented by metrics proposed in this work, the Mayhew (1999) process was used as the basis. Thus, it is worth mentioning that because it was based on an already existing process, some specifications of the activities are similar to those defined by Mayhew (1999).

4.1 Process Objective

Late identification of poor software quality can lead to costs for the customer, not to mention end-user dissatisfaction. That is why the development of software comes every day more being carried out with the help of HCI, which aims at user centralization. Even with the process facing the user, it is difficult to measure the quality of the product. Therefore, a process oriented to metrics was proposed so that, throughout the process, this quality is measured qualitatively or quantitatively. The process is divided into two phases: requirements analysis; Design, evaluation and development. Within each phase are the activities, which follow the template of objective, description, input, output, technique, task, role involve.

4.2 Requirements Analysis

The requirements analysis phase, as the name says, is responsible for identifying the requirements, seeking to understand the whole scenario in which the system will be inserted. It is at this stage that the GQM is planned and the objective and the questions regarding product quality are defined, as can be seen in the upper part of the process in Fig. 1. Currently, in the literature there are templates to assist in the definition of the objective.

4.3 Design, Evaluation and Development

The second range of the process is the design, evaluation, and development phase that is where the system builds along with its design and is divided into three levels. At the first level the conceptual model is carried out, at the second level the screen design standards, and lastly the detailed design of the user interface. All levels are followed by evaluations, and level 2define the metrics for the level.

4.4 Details of Role Involved

The roles for the process oriented by metrics were defined following the RACI responsibilities matrix as defined by COBIT (2012). RACI in English means, responsible, accountable, consulted, informed, which means:

‘R’ (Responsible): Is the one who performs the task; ‘A’ (Accountable): Is who is responsible for the correct execution of the task, is often the owner of the project; ‘C’ (Consulted): Are the people who provide information for the project; ‘I’ (Informed): Is the one who receives information about the progress of the task.

4.5 Details of Role Involve

Team Manager - is responsible for IT (Information Technology) for the project under development; Project Manager - is responsible for the project, as well as its progress; Requirements Analyst - is responsible for identifying system requirements; Usability Analyst - is responsible for the usability of the system; Metrics Analyst - is responsible for defining and analysing metrics; Developer - is responsible for developing the system; User - is the end user of the system.

5 Process Validation

A search is often a retrospective investigation, when, for example, a tool or technique has been used for a while. The main ways of collecting qualitative or quantitative data are interviews or questionnaires. These are done by taking a sample that is representative of the population being studied. The results of the research are then analysed to derive descriptive and explanatory conclusions (Wohlin et al, 2012). The method chosen to validate this work was the questionnaire.

5.1 Target Audience

The first group to answer the questionnaire was students of a postgraduate class in Information Technology Management at the Faculty of Technology of the University of Brasília; these students cursed the discipline of Software Processes.

The second group was students of the graduate in Software Engineering at the University of Brasilia that had already cursed the discipline HCI.

5.2 The Questionnaire

The questionnaire was made in the TYPEFORM and contains 25 questions, which are type: multiple choice, yes or no, classification, scale and text. The questions are to define the user profile and the process quality.

5.3 Data Collected

The questionnaire was answered by 29 students of the postgraduate in Information Technology Management and 18 students of the graduate in Software Engineering and had already coursed HCI. It is important to cite that some students continued the questionnaire without answer some questions.

5.4 Analysis of Data Collected

According to the data collected was possible to verify the following information about the knowledge in HCI: 42% none, 36% little, 11% moderate, 11% good and 0% very good as shows the Graph 1. The Graph 2 represents the percentage of the knowledge in Software Process, which 4% has none, 24% little, 20% moderate, 39% good and 13% very good. So, their answers about process can really contribute to improve the process.

Graph 1.
figure 1

Knowledge in HCI.

Full size image
Graph 2.
figure 2

Knowledge in software process.

Full size image

The Graph 3 represents the students’ opinion about the possibility to measure the interface quality using the process proposed, and the answers are: 3% no, 22% a little, 36% need to try and 39% yes. The Graph 4 shows that the most students would use the proposed process, 48% with restrictions and 48% would use complete.

Graph 3.
figure 3

Is it possible to measure the interface quality using the process?

Full size image
Graph 4.
figure 4

Would you adopt the proposed process?

Full size image

These evaluations were made with the first version of the process, according to the feedback, the process was modified to the version 2. The Fig. 1 represents the version 2, and this new version will be validated with a new group through the questionnaire. The biggest difference between the version 1 and version 2 is the number of activities. The process was divided into 3 phases and now there are only 2.

Fig. 1.
figure 5

Interaction design process oriented by metrics.

Full size image

6 Conclusion

There are many studies currently attempting to relate software development to the HCI area. In this way, most of these integrate activities related to interaction design, in a software development process.

The interaction design process oriented by metrics aims to improve the interface quality of software products, facilitating the analysis of this quality through the metrics defined during the process. Based on the selected Mayhew (1999) process, the proposed process was adapted, adding GQM activities throughout the process, and detailing each activity according to the items: objective, description, input, output, technique, task, role involved.

In a future work, with the objective of validating the new version of the process oriented by metrics proposed, a questionnaire will be applied, with a different group to improve the process.