prototyping approach in user interface development

2ND CONFERENCE ON INNOVATIVE TEACHING METHODS (ITM 2017) 28-29 JUNE 2017, UNIVERSITY OF ECONOMICS VARNA, BULGARIA

PROTOTYPING APPROACH IN USER INTERFACE DEVELOPMENT

Radka NACHEVA1 1

University of Economics, Varna, Bulgaria [email protected]

Abstract. The present study examines different prototyping approaches in software development. There are researched different variations of so-called “prototyping model“. The paper examines the prototyping process as problem solving process and makes reference to process approach. The aim of this paper is to propose a prototyping approach in user interface development based on evolutionary prototyping approach and process approach. Key words: prototyping, user interface design and development, process approach, problem solving, Unified Modeling Language.

1. Introduction Nowadays it is increasingly talking about the importance of user interface design of software applications. Some experts are of the opinion that it should be started with “design, rather than just end with it. Design is an investment, not a cost“ (Maeda 2015). Other authors indicate that design is directed toward the fulfillment of human needs (Yan 1998). In this connection, user needs could be considered as hierarchy like Maslow’s Hierarchy of Needs: functional, reliable, usable and pleasurable needs (Walter 2011). This assumes that design helps, encourages, engages attention and manages emotions of users to take a decision for using and trusting the product. It provides them a visual comfort when they work with the user interface. In software development there are often used prototypes to receive feedback from users for refining the final product. (Neumann 2004). These are filters that traverse a design space (Lim et al. 2008) and are widely recognized to be a core means of exploring and expressing designs for interactive computer artifacts (Houde & Hill 1997). The aim of the prototyping is to establish an accordance between the product requirements, ideas of designers and users’ mental models. It is achieved by using usability testing and / or evaluation methods and tools. If the interface does not fully meet the needs of the target audience and / or system requirements, the change of the prototype will be made much easier than the final application. In the literature there are different approaches for prototyping which have some advantages and disadvantages. The aim of this paper is to propose a prototyping approach in user interface development based on evolutionary prototyping approach and process approach.

80

2ND CONFERENCE ON INNOVATIVE TEACHING METHODS (ITM 2017) 28-29 JUNE 2017, UNIVERSITY OF ECONOMICS VARNA, BULGARIA

2. Literature review "Never go to a meeting without a prototype" Dennis Boyle, IDEO The prototyping process is conducted in several stages, which can run to the realization of the final product. Prototypes can be created in the early stages of a software project, and immediately prior to finalizing it. They can be repeated as long as necessary and as required, which means that “the process is iterative” (Warfel 2009). The literature identifies the three main approaches (Floyd 1984; Bäumer et al. 1996; Carr & Verner 1997; Hartmann 2009; Beaudouin-Lafon & Mackay 2012): Exploratory, Experimental and Evolutionary Prototyping. (Table 1). Table 1 A comparison of prototyping approaches Exploratory Experimental Evolutionary Study: clarification of Evaluation: Changes Goal system requirements and conducting user adaptation: discuss different testing, the goal is to constantly adapt the alternatives for assess whether the system to implementation technical solutions dynamically satisfy the system changing requirements environment System Requirements Partially realized Detailed system Object of solutions requirements research For the initial stages of For each stage, after Throughout the Stage of the development process receiving the initial development software to determine the requirements process, incl. to development requirements realize the final process system Low Medium High Fidelity Horizontal Horizontal or Vertical Vertical Orientation Rapid (presentation) Rapid (presentation) Pilot system or final Result prototype prototype or system (engagement components with the final (functional prototype) system) When we talk about prototyping the main focus of each approach is on the prototype’s fidelity (Lim et al. 2008) which is different for the different approaches (Figure 1). Figur e 1. Protot ype’s fidelity in different approaches Source: Own elaboration

81

2ND CONFERENCE ON INNOVATIVE TEACHING METHODS (ITM 2017) 28-29 JUNE 2017, UNIVERSITY OF ECONOMICS VARNA, BULGARIA

In Exploratory Prototyping the fidelity is low, without visualizing key features of the product. The approach is not suitable for studying of users’ expectations. The prototypes are non-functional (horizontal orientation) and are not part of the final system. In contrast, Experimental Prototyping approach is used for usability testing of partially realized solutions (system components) which could not be fully functional. These are often crucial components of the system. That’s why the prototypes’ fidelity is medium the orientation can be both vertical and horizontal. The third approach - Evolutionary Prototyping, “is a continuous process for adapting an application system to rapidly changing organizational constraints” (Bäumer et al. 1996). The prototypes can be used for presenting key product features and for usability testing and evaluation. In connection with the process of prototyping it is necessary to mention that in the literature (Raval & Rathod 2013; Centers for Medicare & Medicaid Services 2008; Helm 2017, etc.) defines so-called „prototyping model“ which is decomposed into design, prototyping, customer evaluation, refinement (review of the prototype). There are many variations of prototyping model. For example, Floyd took it up as consisting of four steps: functional selection, construction, evaluation, and further use (Floyd 1984). Other researchers (Carr & Verner 1997) indicates that the process is decomposed into: creation of an initial prototype, user review of prototype and revise or refine prototype. Another study (Arnowitz et al. 2007) describes that it is performed in phases, and each phase is implemented in several steps: Phase I Plan (steps: verify the requirements, create a task / screen flow, specifying content and fidelity), Phase II Specification (steps: determine the right prototyping characteristics, choose a prototyping method, choose a prototyping tool), Phase III Design (steps: formulate design criteria, create the prototype) and Phase IV Results (steps: review the prototype, validate the design, implement the design). An expert (Warfel 2009) suggests it could be conducted on the following steps: sketching (e.g., whiteboards, paper, code), presentation and critique, modeling (prototyping) and testing. Based on the foregoing, it could be concluded that there is no one correct approach to prototyping and accordingly its decomposition into steps. The selected variation of the process depends entirely on software development approach and dynamics in the relationships with customers. In some cases, it targets faster visualization of requirements to a presentation to users and then the process is characterized by intensity of conducting. In other situations, it is a decisive an accuracy which leads to slower realization of the prototype. Regardless of the prototyping approach it is necessary to perform some basic activities to ensure efficiency of the process and receive a proper feedback on the adequacy of the software project. For identifying these, the author of the present study examines the prototyping process as problem solving process. That requires relying on researches in the mentioned field. Based on the given opinion in some papers (Polya 1945; Hayes 1989; Foshay & Kirkley 2003; Arnold et al. 2005; Maclellan et al. 2012; OECD 2012; Minnesota Office of Continuous Improvement 2016), this study could summarize that problem solving process have several steps: define a problem, analyze the problem, develop a plan, implement the plan and evaluate results. These could vary depending on the field of application. Problem solving theory is naturally embedded in management theories. For example, in management methods such as Plan–Do–Check–Act (PDCA), which has some modifications (Observation-Plan–Do–Check–Act and Plan-Do-Study-Act). PDCA is found

82

2ND CONFERENCE ON INNOVATIVE TEACHING METHODS (ITM 2017) 28-29 JUNE 2017, UNIVERSITY OF ECONOMICS VARNA, BULGARIA

in the ISO 9001 standard where the process approach is explained. According to the standard, every process is a “set of interrelated or interacting activities that use inputs to deliver an intended result” (ISO 2015). Some of the possible benefits that could be achieved by applying the approach are related to customer satisfaction and loyalty, enhanced repeat business, implementation of any management system (ISO 2015), applying “good practices”, etc. This provides an argument in favour with author of this study for suggesting that the process approach should contribute to the formulation of prototyping process variation. The proposed approach must meet the following requirements to comply with the literature review:  to effectively solve problems namely to meet user and software requirements;  to make a successful decision through exploring user needs and refining functionality that has already been implemented (Carr & Verner 1997);  to emphasize prototype dimensions: Features, Functionality, Interaction and Design (Neumann, 2004);  to describe the level of detail at which the prototype is to be evaluated (BeaudouinLafon & Mackay 2012).

3. Prototyping model based on process approach The proposed model (Figure 2) is seen as iterative evolutionary prototyping process that receives certain inputs, perform a few steps and delivers output artifacts. The present study offers the following stages of prototyping based on generalized steps of problems solving in the literature review: system requirements analysis (corresponds with analyze the problem), sketching (corresponds with develop a plan), prototype development (corresponds with implement the plan), exploring usability (corresponds with evaluate results) and refinement.

Figure 2. Prototyping model based on process approach Source: Own elaboration

83

2ND CONFERENCE ON INNOVATIVE TEACHING METHODS (ITM 2017) 28-29 JUNE 2017, UNIVERSITY OF ECONOMICS VARNA, BULGARIA

Input process parameters are the system requirements and the chosen technologies and tools for software development. They provide the necessary basis to perform the process. As an output artifact of the prototyping process is created a verified prototype that in the development process should be further improved with a view that the proposed approach is based on evolutionary prototyping. The restrictive conditions for conducting the process are associated with stage "Exploring Usability". In particular, these are the competencies of users who will participate in the prototyping process and the environment where it will be conducted. The first stage of the process is System Requirements Analysis. Its purpose is to undertake an assessment of the main interaction scenarios with the system from the user’s perspective. This requires to model the main navigation flows, which requires identification of:  the main actors in interaction scenarios with the system;  the main entities of the subject area and their hierarchical organization, if any, to create the initial information model;  the prototype should realize the critical requirements of trouble free functioning of the system which are presented from the perspective of users, in terms of implementing the interface interactions. As a basis for formulating serve up information model;  information structure of the application or these are navigational elements through which user manages the application (not necessarily combined in a standard user menu);  user interface elements involved in the information flow, so that their number could be between 5 and 9, i.e. these will be designed according to the "7 ± 2" rule, giving some confidence that users of the system will not put unnecessary cognitive resources in working with interface. In practice for software requirements analysis are often used so-called "RACI matrix" (Responsibility assignment matrix) and "House of Quality". The second one is much more complicated than the first one because the requirements are viewed from two perspectives by assigning relative weights and levels of difficulty. The author of this study combines ideas from both tools to form a table that can be used to analyze the requirements (Table 2). Table 2 Software requirements analysis table Requirement of a consumer point of Priority Difficulty view Name of software module 1. Functionality 1 2. Functionality 2 2.1. Functionality 2.1.

Permissions User 1 User N

The requirements in Table 2 could be grouped into categories and subcategories with defined priority, difficulty of implementation and permissions. These are divided hierarchically, which contributes to better development of subsequent information flows. In prioritizing the requirements, the author of this study adopts a three-level scoring where requirements of Priority 1 are a high priority that gives meaning "required for realization". Requirements which have Priority 2 are “medium priority” and implemented after Priority 1 requirements. Priority 3 is interpreted as “low” and these are not mandatory for implementation in the initial prototype of the system because do not demonstrate key characteristics.

84

2ND CONFERENCE ON INNOVATIVE TEACHING METHODS (ITM 2017) 28-29 JUNE 2017, UNIVERSITY OF ECONOMICS VARNA, BULGARIA

In the present paper is used five-level scale to indication the implementation difficulty of a specific requirement. That allows more detail coverage. Difficulty level 1 denotes “the highest level” at which additional resources in the realization of the prototype are necessary. For example, the acquisition of additional knowledge and skills, purchase of additional software, hardware, etc. Difficulty level 2 means “high level” and extents that no additional resources are required, but the requirement is characterized by specificity and needs more time for development. Difficulty level 3 designates requirements of “medium difficulty” that also do not require additional resources, but require more development time. Difficulty level 4 requirements denote a “low level of difficulty”. Difficulty level 5 are those with the “lowest level” which development time is relatively short. Next step is modeling the aggregate requirements by appropriate means. This can be done through "storyboarding", data flow diagrams, UML diagrams, BPMN diagrams, SysML diagrams and even classic block schemes. There is also a special user interface modeling language - Interaction Flow Modeling Language (IFML), which however cannot be determined as required in practice, despite his obvious advantage resulting from its purpose. With the integration of user-oriented approach in developing of software products there are used two types of diagrams - task flow and user flow, which actually visualize navigation flows about performing tasks with the application’s interface. The author’s studies suggest that none of the two types of diagrams has an established notation. Often these are displayed in a free form, according to the preferences of design teams or using flowcharts. They are suitable for presenting the consumer perspective, but do not give additional information about the system, which is essential for proper realization of the prototype. Therefore, guided by the presumption of a clear representation of requirements and proper implementation of the evolutionary prototype in this step of the prototyping process this paper suggests using so-called "use cases", modeled by UML activity diagram. It is used the structure of the documentation of use cases in UML. These are focused on the objectives of users, making them suitable tool for a description of the prototype. The advantage is that through them is facilitated the development process, since both are present the expected action by the user (the input data) and the response of the system (processing performed on the input data and the generated output). For each use case it is described:  Description - a brief description of the use case, indicating expectations of its implementation;  Pre-condition - the condition that is observed before the execution of the use case;  Main flow - main steps of the implementation of the use case presented as a numbered list;  Alternate flow – steps that indicate the result and outcome of the failure of one of the steps in the main flow, i.e. possible failures of the use case and the expected response from the system being developed;  Post-condition - short description of the result of the use case execution. Documented use cases are visualized through activity diagrams. The aim is providing both user flows and the functioning of the system. The use cases and diagrams are used as the basis for implementation of the next step of the prototyping process - Sketching. It can be defined as a kind of planning. During the step user interface design patterns are created to help the subsequent development of the prototype. That requires complying with:  placing important items in the effective height of the pages (above the fold);

85

2ND CONFERENCE ON INNOVATIVE TEACHING METHODS (ITM 2017) 28-29 JUNE 2017, UNIVERSITY OF ECONOMICS VARNA, BULGARIA

 forming the information structure of the application through navigation items and at the same time, providing a quick access to frequently used actions (the application's functionality), and a multivariate approach to users for achieving their goals;  determining the location and size of the strategically important components of the application to which the distance is shortest. The aim is applying the Fitt's Law;  deploying the distinctive graphic element of the application (logo) so that both come to the attention of consumers and also does not have a central position. All of the mentioned requirements serve as basis for creating sketches, which display the positions of the identified user interface elements and which in practice are products of so-called „interaction design “. Created sketches of the interface are used in the next stage of the prototyping process – Prototype development. In terms of applying evolutionary approach to this prototyping model, it is necessary to apply tools that will be used in the development of the final system. The prototype forms its basis. Practically, this step is related to implementation of problem solving plan. The next step in the prototyping process is Exploring Usability. Its aim is to check the usability and usefulness of the prototype. This stage can be defined as the stage of checking the compatibility of established design concept, system requirements and user expectations, including logo design. The study can be conducted with users or only with experts. At this stage it should be applied methods and tools for usability testing and evaluation. The results from exploring usability stage serve as basis for making certain changes to the prototype. That is the stage Refinement of the prototyping process. The aim is to modify the prototype in accordance with the results of the previous stage, so as to meet the mental models of representatives of the target audience, but also to comply with the system requirements. Finally, it should be concluded that the proposed variation of the prototyping process combines methods and approaches from different scientific fields. It is repeated as long as necessary and as needed.

4. Conclusion The user interface is crucial in the development of software applications. If it is well designed it could help users to achieve their goals, to satisfy them and to encourage them to use it. Software prototypes support development teams to explore usability, usefulness and acceptability of their projects. The proposed prototyping approach can be used for development of a user interface of different applications independently of the type – desktop, web-based, mobile. Its advantages are related to implementing process approach, using tools for system requirements analysis and modelling, using tools for documenting use cases of the software. It is practically implemented during the development process of a prototype that is part of the PhD thesis of present study’s author.

Literature Arnold, M.L., Heyne, L.A. & Busser, J.A., 2005. Problem Solving: Tools and Techniques for the Park and Recreation Administrator. Fourth Edition. Sagamore Publishing LLC.

86

2ND CONFERENCE ON INNOVATIVE TEACHING METHODS (ITM 2017) 28-29 JUNE 2017, UNIVERSITY OF ECONOMICS VARNA, BULGARIA

Arnowitz, J., Arent, M. & Berger, N., 2007. Effective Prototyping for Software Makers. Effective Prototyping for Software Makers, pp.204–217. Bäumer, D. et al., 1996. User interface prototyping - concepts, tools, and experience. Proceedings of the 18th international conference on Software engineering, (March), pp.532–541. Beaudouin-Lafon, M. & Mackay, W., 2012. Prototyping tools and techniques. The HumanComputer Interaction Handbook, pp.1081–1104. Carr, M. & Verner, J., 1997. Prototyping and Software Development Approaches. Department of Information Systems, Hong Kong: City University of Hong Kong. Centers for Medicare & Medicaid Services, 2008. Selecting a development approach. Centers for Medicare & Medicaid Services, pp.1–10. Available at: http://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-InformationTechnology/XLC/Downloads/SelectingDevelopmentApproach.pdf. Floyd, C., 1984. A Systematic Look at Prototyping. Approaches to Prototyping, pp.1–18. Foshay, R. & Kirkley, J., 2003. Principles for Teaching Problem Solving. , pp.1–16. Hartmann, B., 2009. Gaining design insight through interaction prototyping tools. Design, (September), p.194. Available at: http://bjoern.org/dissertation/hartmann-diss.pdf. Hayes, J., 1989. The Complete Problem Solver Second Edi., London: Routledge | Taylor & Francis Group. Helm, J., 2017. Methods for Software Prototyping. Available at: http://sce.uhcl.edu/helm/REQ_ENG_WEB/My-Files/mod4/Software_Prototyping.pdf. Houde, S. & Hill, C., 1997. What do prototypes prototype? Handbook of Human Computer Interaction, pp.1–16. ISO, 2015. The process approach in ISO 9001:2015. Lim, Y.-K., Stolterman, E. & Tenenberg, J., 2008. The anatomy of prototypes. ACM Transactions on Computer-Human Interaction, 15(2), pp.1–27. Maclellan, C.J. et al., 2012. A Generative Theory of Problem Solving. , 1, pp.1–18. Maeda, J., 2015. DesignInTech Report, Available at: http://www.kpcb.com/blog/design-intech-report-2015. Minnesota Office of Continuous Improvement, 2016. Problem Solving Handbook: Solving Problems Isn’t Always Elementary, Saint Paul. Available at: https://mn.gov/admin/assets/Problem Solving Handbook_tcm36-68605.pdf. Neumann, P., 2004. Prototyping. October, pp.1–13. Available at: http://pages.cpsc.ucalgary.ca/~saul/pmwiki/uploads/Main/topic-neumann.pdf. OECD, 2012. PISA 2012 Field Trial Problem Solving Framework. Oecd, pp.1–47. Available at: http://www.oecd.org/pisa/pisaproducts/46962005.pdf. Polya, G., 1945. How to Solve It. The Mathematical Gazette, 30, p.181. Available at: http://www.jstor.org/stable/3609122?origin=crossref. Raval, R.R. & Rathod, H.M., 2013. Comparative Study of Various Process Model in Software Development. International Journal of Computer Applications, 82(18), pp.16–19. Walter, A., 2011. Designing for Emotion, A Book Apart. Warfel, T.Z., 2009. Prototyping: A Practitioner’s Guide. , p.195. Yan, H.-S., 1998. Creative Design of Mechanical Devices 1st ed., Springer Singapore.

87