PROTOTYPING APPROACH IN USER INTERFACE DEVELOPMENT

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.

Full text

2ND CONFERENCE ON INNOVATIVE TEACHING METHODS (ITM 2017)
28-29 JUNE 2017, UNIVERSITY OF ECONOMICS VARNA, BULGARIA
80
PROTOTYPING APPROACH IN USER INTERFACE
DEVELOPMENT
Radka NACHEVA1
1 University of Economics, Varna, Bulgaria
r.nacheva@ue-varna.bg
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.

2ND CONFERENCE ON INNOVATIVE TEACHING METHODS (ITM 2017)
28-29 JUNE 2017, UNIVERSITY OF ECONOMICS VARNA, BULGARIA
81
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
Goal
Study: clarification of
system requirements and
discuss different
alternatives for
implementation
Evaluation:
conducting user
testing, the goal is to
assess whether the
technical solutions
satisfy the system
requirements
Changes
adaptation:
constantly adapt the
system to
dynamically
changing
environment
Object of
research
System Requirements
Partially realized
solutions
Detailed system
requirements
Stage of
software
development
process
For the initial stages of
the development process
to determine the
requirements
For each stage, after
receiving the initial
requirements
Throughout the
development
process, incl. to
realize the final
system
Fidelity
Low
Medium
High
Orientation
Horizontal
Horizontal or Vertical
Vertical
Result
(engagement
with the final
system)
Rapid (presentation)
prototype
Rapid (presentation)
prototype or
components
(functional prototype)
Pilot system or final
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

2ND CONFERENCE ON INNOVATIVE TEACHING METHODS (ITM 2017)
28-29 JUNE 2017, UNIVERSITY OF ECONOMICS VARNA, BULGARIA
82
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

2ND CONFERENCE ON INNOVATIVE TEACHING METHODS (ITM 2017)
28-29 JUNE 2017, UNIVERSITY OF ECONOMICS VARNA, BULGARIA
83
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 (Beaudouin-
Lafon & 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

2ND CONFERENCE ON INNOVATIVE TEACHING METHODS (ITM 2017)
28-29 JUNE 2017, UNIVERSITY OF ECONOMICS VARNA, BULGARIA
84
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
view
Priority
Difficulty
Permissions
User 1
User N
Name of software module
1. Functionality 1
2. Functionality 2
2.1. Functionality 2.1.
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.

2ND CONFERENCE ON INNOVATIVE TEACHING METHODS (ITM 2017)
28-29 JUNE 2017, UNIVERSITY OF ECONOMICS VARNA, BULGARIA
85
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);

2ND CONFERENCE ON INNOVATIVE TEACHING METHODS (ITM 2017)
28-29 JUNE 2017, UNIVERSITY OF ECONOMICS VARNA, BULGARIA
86
 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.

2ND CONFERENCE ON INNOVATIVE TEACHING METHODS (ITM 2017)
28-29 JUNE 2017, UNIVERSITY OF ECONOMICS VARNA, BULGARIA
87
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 Human-
Computer 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-Information-
Technology/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-in-
tech-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.