A Systematic Approach to Support the Idea ... - Semantic Scholar

9 downloads 6542 Views 135KB Size Report
interface design process before prototyping. We also present a systematic, yet flexible methodology to support the designer during this creative phase of the ...
A Systematic Approach to Support the Idea Generation Phase of the User Interface Design Process V. Balasubramanian

Murray Turoff

David Ullman

Graduate School of Management Rutgers University Newark, NJ 07102, USA. Email: [email protected]

Department of Computer and Information Science New Jersey Institute of Technology Newark, NJ 07102, USA. Email: [email protected]

Manager Management Information Services New Jersey Institute of Technology Newark, NJ 07102, USA. Email: [email protected]

Abstract Human-Computer Interaction researchers have primarily focused on systematic techniques and tools for two phases of the user interface design process: design by prototyping and evaluation. Studies have shown that the advent of a number of rapid prototyping techniques and tools have not significantly reduced the amount of time and costs involved in the design and programming of user interfaces. This is due to the fact that designers do not spend enough time thinking about the design problem; instead, they resort to “aimless” prototyping with a complex set of tools. In this paper, we introduce the need for a formal planning and idea generation phase in the user interface design process prior to prototyping, to minimize the effects of ad hoc design practices. This is the phase when preliminary requirements for an information system are available and the designer starts thinking and planning about the problem, making mental and written notes about it. This phase is similar to the problem formulation and idea generation phases discussed by researchers in the area of creative problem solving. We also propose a systematic design methodology containing fifteen non-sequential, highly connected, and iterative set of design tasks to structure the creative and opportunistic thought processes of the designer with appropriate guidance. A tool called HyperDesign has also been developed, incorporating hypertext functionality, to facilitate application of this methodology during this early phase of interface design. Results from a beta test, with students and professionals, confirmed the need for a planning and idea generation phase during the user interface design process with moderate levels of agreement about the validity,

relevance, and usefulness of the proposed methodology. The beta test also revealed that the tool was moderately difficult to use; changes to both the methodology and the software have been proposed which will be incorporated in the next iteration, making it more usable and acceptable by designers.

1. Introduction The user interface (UI) design process can be defined as the total set of design tasks to be carried out to transform users’ requirements into a user interface design specification. UI design requires a judicious mixture of creativity, design knowledge, experience, task analysis and a thorough understanding of users’ requirements. This entire process can be considered to be a creative problem-solving exercise focused towards the creation of artifacts such as documents, mockups and prototypes. In recent years, researchers in Human-Computer Interaction (HCI) have reported on the importance of making this process more structured compared to ad hoc practices currently followed by system designers [20]. Most researchers have primarily focused on two phases of the design process: design by prototyping and evaluation. A number of user interface design and usability guidelines, systematic techniques and tools (user interface management systems and builders) exist for the prototyping/design and evaluation phases of interface design [1]. Before entering the prototyping phase, a lot of analysis goes into thinking about the design problem and planning various elements of the user interface. However, designers do this in an ad hoc manner, making mental or written notes and exchanging memos with other team members. There is no systematic approach to actually guide the designer through this phase because it has never been treated as a separate phase in the UI design process. As a result, designers jump into the prototyping phase prematurely without carefully thinking about the problem.

1060-3425/98 $10.00 (c) 1998 IEEE

In this paper, we introduce the need for an explicit planning and idea generation phase during the user interface design process before prototyping. We also present a systematic, yet flexible methodology to support the designer during this creative phase of the design process. We begin with a review of literature in the areas of software engineering, user interface design, creative problem-solving, and hypertext. We converge on the relevance of these disciplines to this research, followed by details of the proposed methodology. We then provide an overview of a software called HyperDesign to facilitate application of this systematic approach. We also present results of evaluation studies about the usefulness of the methodology and the usability of the tool. We then discuss limitations of this research and some directions for future research. The last section provides some closing remarks and conclusions.

2. Related Work In this section, we review literature in the areas of software engineering, user interface design, creative problem-solving, and hypertext and their relevance to this research. Feedback on completeness of requirements, results of protocol analysis and usability

recently have researchers started looking into structuring the user interface design process, in particular [20]. There has been very little research in the area of idea generation for the purposes of carrying out user interface design. As mentioned earlier, HCI researchers have primarily focused on design by prototyping and evaluation. Although some researchers have acknowledged the need for creative thinking during the interface design process they have not elaborated further on the actual techniques to be used [17, 27]. Snow and Couger have studied the use of creativity generation techniques in the development of information systems (IS) in general [25]. However, they do not consider user interface design as a separate activity during the software development process. Similarly, Couger and Dengate have identified various degrees of creative opportunities in IS development activities [8]. However, their analysis is focused on job categories such as programmer/analyst, system manager and operations manager; it does not take into account user interface designer as a separate function which is increasingly becoming the norm in software development. We propose the introduction of a planning and idea generation phase as part of the UI design process as shown in Figure 1 which represents the various phases

Requirements Analysis

Planning and Idea Generation

Task-based design methodology

User Interface Design Feedback on architecture based user interface design changes

Feedback on developmentbased design changes Feedback on usability, user satisfaction, functionality, and performance

Static Prototyping - mockups Dynamic Prototyping - GUI builders System Design

Guidelines support

Usability Evaluation - heuristics, cognitive walkthroughs, protocol analysis Development

Testing - Unit, System, and Acceptance

Deployment

Maintenance/ Enhancement Requests

Maintenance/Enhancement

Figure 1. The User Interface Design Process within the context of the Software Development Life Cycle.

2.1. Software Engineering and User Interface Design A number of researchers have reported on methodologies to engineer the software design and development process as a whole [12, 14]. However, only

of the Software Development Life Cycle (SDLC). The introduction of this phase makes UI design a three-stage process as shown in Figure 1: planning and idea generation, prototyping and design, and evaluation. The best analogy for our discussion is the database design

1060-3425/98 $10.00 (c) 1998 IEEE

process which also involves three phases: logical design (planning and modeling the entities and relationships using E-R diagrams), physical design (actually creating the database tables and procedures), and evaluation (testing the database using sample data). For the data modeling phase a number of systematic techniques and tools have evolved over these years. There is nothing similar for the planning and modeling phase of the user interface design process. Note that Figure 1 is a simplistic view of the SDLC. The intention here is not to discuss the merits and demerits of various forms of the SDLC such as waterfall, spiral, incremental, iterative, etc. Suffice it to say that we prefer iterative development which includes prototyping in order to augment the requirements analysis phase already carried out through traditional means. Other parts of the figure are self-explanatory and hence we will not provide details of each of the phases. We consider the actual and final implementation of the user interface as an integral part of the development phase during the SDLC. With the introduction of the planning and idea generation phase prior to prototyping, the user interface design process is now made of the following three phases, as shown in Figure 1: Planning and Idea Generation: This is an early design activity where a designer reviews the requirements for an information system and mentally plans the various design elements of the user interface. During this phase, a designer’s thought process is “opportunistic and evolutionary” [20]. He or she is continuously moving between abstract thinking and concrete ideas as he or she gains greater insight into the problem. Currently, designers do plan this phase either in the form of design notes or memos to users and other team members, but it is seldom structured. In addition, there are no guidelines or systematic support for this phase. The need to support designers in capturing ideas or alternatives has been discussed in [20], but no concrete techniques have been proposed. Verplank, in an interview, mentions how software developers get carried away by prototyping even before looking at the problem or generating a set of alternatives [27]. He suggests that one of the ways to train designers to record and maintain alternatives is to encourage them to keep “idea logs”. We believe that the proposed design methodology will facilitate idea generation in a guided manner. This, in turn, will assist designers to develop a better understanding of system requirements. Prototyping and Design: A number of prototyping techniques have evolved over the past decade. Static prototyping, also called low-fidelity prototyping [22], relies on mockups, storyboarding and paper and pencil strategies. This is followed by dynamic or high-fidelity

prototyping [28] with the construction of the actual interface using user interface management systems or popularly known as graphical user interface builders. These builders also generate programs for the user interface layer which can directly be integrated with application and data layers. Myers and Rosson have reported that rapid prototyping techniques and tools have not significantly reduced the amount of time and money spent on designing and developing user interfaces [18]. Various software firms which have released a number of windowing systems have specified a number of user interface design guidelines as to how to make the system more user-friendly. Most guidelines are concerned about improving the usability aspects of the resulting interface; they do not provide any active guidance on how to go about identifying various design elements of the interface. That is, guidelines based approaches do not help designers with a design morphology to structure their creative activities. Also, since most guidelines are linear and recipe-based, they do not provide flexibility during the design process. They also do not facilitate capturing details of the design (design memory) and the rationale behind the design (design rationale). We believe that this proposed approach will reduce the “aimless” prototyping that occurs in system development efforts. Evaluation: At the end of the prototyping and design phase, a number of evaluation techniques can be employed to assess the usability of the resulting interface. These include well known strategies such as usability testing, usability engineering, heuristics evaluation, protocol analysis, cognitive walkthroughs, and controlled experiments [1]. There are also guidelines for applying these techniques. There have also been efforts to put guidelines online in the form of help systems and hypertext-based manuals [23]. Most guidelines address how to improve the usability of the interface but on how to think about the problem and plan the interface.

2.2. Creative Problem-Solving Creativity plays a major role during the idea generation phase of any problem-solving process. Couger says that the key to creativity is “a structured approach through which an investigation considers a wide range of alternatives” [6]. Couger adds that great inventions and works of art are not accidents but products of disciplined approaches to discovery and transformation of ideas. This view is similar to Simon’s view that creative problem-solving can be facilitated by following a structured approach [24]. Zwicky, an astronomer, is credited with having found the concept of using morphological models or structures as a basis for idea generation [29]. The essence of the morphological model is the decomposition of a problem into its parts, each of

1060-3425/98 $10.00 (c) 1998 IEEE

which can be solved relatively independently. Relationships can be constructed between these partial solutions to form the solution to the whole problem. The three phases of the user interface design process can be compared to Couger’s Creative Problem Solving (CPS) Model [6]: planning and idea generation is equivalent to the CPS combination of problem definition, compiling information, and generating ideas; prototyping and design is equivalent to developing an implementation plan in CPS; and evaluation is equivalent to evaluating and prioritizing ideas in CPS. Couger and his colleagues discuss the need to enable information system designers to become more creative by adopting certain creativity generation techniques [9]. Snow and Couger report on how members of an IS department in a microelectronics center of a large engineering company successfully applied various creativity techniques such as 5Ws/H (Who-What-WhereWhen-Why-How), brainstorming, wishful thinking and problem reversal [25]. These techniques not only resulted in significant improvements in creativity but also in increased tangible benefits such as savings in computing time as well as programming time in many of their projects. However, these studies were restricted to the entire IS development process as a whole and not the user interface design process in particular.

2.3. Hypertext Hypertext supports non-sequential problem-solving, backtracking, relationship management, and annotations [3]. The incorporation of hypertext into the problemsolving or design process is not new. A number of researchers have incorporated hypertext to manage information in a software engineering environment [11], to manage source code and documentation in a CASE environment [4] and to support construction and argumentation activities in the domain of architectural design [10]. Hypertext provides flexibility in the way information is presented and in the way it is accessed. Flexibility is one of the keys to creative problem solving apart from other factors such as motivation, information and fluency [27]. We have also developed a prototype tool, incorporating hypertext functionality, to support this design methodology. Both the methodology and the tool enable non-sequential processing of design tasks thereby increasing flexibility.

3. Proposed Design Methodology 3.1. Overview As a result of our research efforts, we have arrived at a design methodology containing fifteen non-sequential and highly interconnected set of design tasks to support

the idea generation phase of interface design. These interconnected set of tasks form a hypertext network as shown in Figure 2. At an earlier HICSS conference, we presented a use scenario where we applied this methodology to plan the user interface design for an electronic Encyclopedia Britannica with hypertext functionality [2]. The methodology consists of the following fifteen design tasks. We present short descriptions of each design task without going into details. The reader is directed to the above mentioned paper for details on how to apply each of the fifteen design tasks to create the user interface design specification for an information system. • Identify requirements of the application. Broad business goals are converted into a set of requirements. The analysis during this phase is similar to what is normally done in any software project. The output of this task can be a Software Requirements Specification (SRS) document. • Identify the metaphor to represent the system. The user interface is made familiar to the user through the use of real-world concepts. A set of metaphor alternatives are identified, then evaluated using metaphor design guidelines and the appropriate choice is made [5, 16]. • Identify objects that comprise the application. Using the requirements derived earlier, various application objects that comprise the problem domain are identified. This is similar to the concept of identifying entities during the Entity-Relationship (ER) modeling phase in a software project. However, the objects need not be restricted to data objects but can also include interface objects such as menus, windows, lists, etc. A user interface object may be a combination of several data model entities depending on presentation requirements. The activities within this task include identifying: entities, attributes of entities, parts of entities (logical groupings of attributes within each entity) and various forms of presenting these entities (short form or summary, intermediate form, and full-form or detail). • Identify lateral linkages or relationships between objects. Relationships among objects or entities are identified These relationships need not be restricted among data objects but can also be among interface objects. This task includes identifying: relationships between objects and relationships between parts of a single object. • Identify operations on objects and relationships. Based on the requirements, objects, and relationships identified earlier, various kinds of operations that can be performed on objects and relationships must be

1060-3425/98 $10.00 (c) 1998 IEEE



identified. This includes: generic operations such as creation, deletion, and modification of objects, attributes, and relationships. These operations can be multi-purpose or polymorphic based on the type of object; explicit operations such as search and retrieval by name, types, status, or other qualifiers; control operations such as zooming, scrolling, printing, selecting, and marking.

Identify strategic choices to complete specific goals. These are menus or controls that appear in primary windows and dialogs. These allow the execution of generic, explicit, and control operations identified earlier (to create and manipulate objects and relationships), to apply qualifiers to objects and relationships, and to search for objects and relationships. These choices should satisfy the major

S S

S A

Goals

Identify requirements

Identify objects

S

Identify lateral linkages or relationships

P

(C)

(C)

(C) A

S

Identify modifiers/ qualifiers

Identify metaphor

(C) A

A A

Identify strategic choices

A

S

(C) M

A

M S

S

M

Identify help messages (C)

A A

Identify screen layout

M

A

(C) M

M S

Identify formats

A

Identify reactive choices

(C) S

A

A

A A

(C)

L

A

A

S

Identify lists of objects

Identify interaction states

S

(C)

(P)

(C)

Identify error conditions

A S

M

S

A

S

A A

(C)

Identify operations

A

A

M A M

Identify shared processes

(C) (C)

User Interface Design Document

Figure 2. Hypertext network of user interface design tasks. •



Identify qualifiers to select sub-sets of objects and relationships. Qualifiers can be attributes or terms which help in the retrieval of objects and relationships by a query or other explicit operations identified earlier. This includes identifying various types of objects and relationships, other information such as status (tentative, permanent), created_by, modified_by, etc. Identify lists of objects based on specific selection criteria. A combination of objects, qualifiers, and explicit operations can produce lists of objects or indexes satisfying certain search criteria. The designer should be able to record the combinations that can result in such lists.





functional requirements specified by the SRS. Identify reactive choices on objects or lists of objects. Reactive choices enable the user to react to outputs produced after a set of interactions. These are menus available in secondary dialogs and windows. They are usually based on the current interaction state and the strategic choices available for that given state. Whereas searching for objects that satisfy a specific criteria can be considered a strategic choice, selecting an item from the retrieved list to view details can be considered a reactive choice. Identify user interaction states. Interaction states represent the intermediate states of the application as a result of user interaction. These states depend on the execution of strategic and reactive choices. Interaction states do not imply

1060-3425/98 $10.00 (c) 1998 IEEE











modes. Mapping out all the states and the actions that produce them can be represented in a state chart. Identifying strategic choices, reactive choices, and interaction states go hand in hand. Identify formats of objects or parts of objects. Formats of objects, lists, menus for strategic and reactive choices are decided during this task. A number of usability guidelines such as consistency, depth of menus, number of items in each menu etc., must be worked out. For example, it must be determined whether the interaction paradigm should be action-object or object-action. Since textual descriptions of formats may not make much sense, the output of this task could be linked to a presentation/drawing tool. Identify shared processes or operations. Some generic operations (identified earlier) can be polymorphic functions which can act on objects of any type. These shared functions increase reusability. Identify error conditions. Illegal operations in any given interaction state can result in error conditions. The designer should identify various possible error conditions and mechanisms to prevent/handle them. Identify system and help messages. This task involves identifying various kinds of help/system messages based on strategic and reactive choices, interaction states, and possible error conditions. Help messages should be contextsensitive. Identify the screen layout -- workspace, control area, status area, and message area. The combination of the interface metaphor, strategic and reactive choices, formats, help messages, and error conditions should be taken into account to identify the menu bar, the workspace or the client area, various interaction dialogs, the control area, and the status area. The output of this task (which is the culmination of other tasks) should result in the completed user interface design specification document.

We believe that, in addition to usability considerations, the above set of design tasks provides a comprehensive approach to designing self-evident user interfaces for interactive systems. Since interface design is a creative process, the above does not imply any particular order by which the designer should carry out these tasks. The order is not as important as the completion of the process. While existing interface design guidelines imply that interface design is a straightforward and recipe following process, this

approach is based on the fact that interface design consists of a complex set of non-sequential and iterative tasks for which we need automated support. We believe that this model of the design process can become a communication template between users and designers. We also believe that this process will also create a better understanding of the requirements for an information system.

3.2. Hypertext Functionality The fifteen design tasks are highly interconnected based on some natural relationships among themselves, forming a hypertext network as shown in Figure 2. This network diagram has been created on the same lines as the hypertext structure of the planning scenario discussed in [26]. Each of the fifteen design tasks can be treated as process nodes. Arrows represent data flows and relationships between tasks. Each of the process nodes receives a set of inputs and the designer triggers them while navigating through the network to produce a set of outputs. The intermediate outputs form parts of the overall design artifact. The combination of design tasks, inputs, and outputs together form a hypertext network. A broad set of “System Goals” for an interactive system are input into this network which are transformed into a “User Interface Design Document” at the completion of all the design tasks. Hypertext functionality enables nonlinear interaction and backtracking through the various tasks. While the hypertext network supports various ways of solving the design problem (and hence encourages creativity and flexibility), the task-based approach helps impose structure on the creative process. Table 1. General Semantic Framework for Hypertext Functionality [21]. Nodes Detail Collection Proposition Summary Issue Observation

Convergent Links Specification Membership Association Path Alternative Inference

Divergent Links Elaboration Opposition Speculation Branch Lateral Extrapolation

So that designers understand the nature of relationships between the design tasks, the network has been mapped to the general semantic framework for hypertext functionality proposed by Rao and Turoff [21]. The framework proposes that all hypertext networks can generally be classified to contain six different types of nodes and twelve different types of links as shown in Table 1. The individual tasks themselves can be

1060-3425/98 $10.00 (c) 1998 IEEE

classified as nodes of specific types while the numerous pathways between them can be treated as links of specific types. For example, in Figure 2, the task “Identify Objects” is a collection node (C) with a number of subtasks or activities within it, not shown in the figure. This task is linked to another task “Identify lateral linkages or relationships” by a path link (P). This link type is only a suggestion based on the fact that after the identification of object, a designer could immediately proceed to the identification of relationships between objects since the two tasks are closely related. Other node types found in the network include proposition node (P), association link (A), membership link (M), lateral link (L), specification link (S). Each of these design tasks, in turn, can be further decomposed internally into sub-networks. Although the labeled arrows are shown uni-directional, they are actually bi-directional, enabling the designer to go back and forth between the linked tasks. Also, the set of tasks need not be carried out sequentially.

A broad set of objectives for a system is fed into this cylinder and at each of the sieves, the design gets further refined. Thus, the designer progresses from an abstract set of goals to a concrete design document in the process of completing these tasks. Note that unlike a traditional sieve which represents one-way progression, the links between the various design tasks allow the designer to go back and forth thereby refining the outputs of previous phases. One can also imagine a spiral going around the walls of the cylinder thus allowing the designer to navigate through the whole process as a continuum instead of a one-way, downward progression. Once again, it is interesting to note that this is not linear but rather an iterative and non-linear process.

4. HyperDesign - Tool Design, Development, and Evaluation

Figure 3. Spiral-Sieve Model of the proposed design methodology.

We have developed a tool called HyperDesign to assist user interface designers in applying the proposed design methodology during the idea generation phase of the UI design process. This tool, incorporating hypertext functionality, was developed using Relationship Management Methodology (RMM), a systematic approach to design and develop hypermedia applications[13]. The conceptual design was transformed to a system design so that we could use readily available software components to build the tool. It must be noted that while designing the user interface for this tool (Step 5 of RMM), the proposed methodology itself was used during the early, planning stages. This served as a first step in validating the methodology. Although we will not go into the details of how the tool has been developed using RMM, we will summarize the functionality required of the tool. The tool helps the designer to use the methodology by providing the following facilities: • Carry out the fifteen design tasks in any order. Traverse from one design task to another through a suggested relationship. • Create design elements as a result of performing design tasks. • Describe details of design elements. • Link and unlink design elements to design tasks. • Link and unlink design elements to each other based on some relationship.

The hypertext network can be represented in an alternate form, which we have called the Spiral-Sieve model, as shown in Figure 3. The fifteen design tasks can be logically grouped into three sets of five design tasks each, arranged as three different sieves or filters inside a cylindrical drum. The suggested links and link types between the design tasks are still preserved in this model.

We evaluated both the usefulness of the methodology and the usability of the tool. Both types of evaluation were carried out using usability inspection methods which are becoming increasingly popular and effective [15]. We adopted usability testing techniques, as opposed to controlled experiments, and the evaluation was carried out in two parts: initial usability and

G o a ls

R e q u ire m e n ts

O b je c ts O p e ra ti o n s

M e t a p h o r R e la ti o n s h ip s

Q u a lif ie rs

F ir s t -le v e l S ie v e

L is t s

S tr a te g ic c h o ic e s

In t e ra c ti o n s t a te s

S e c o n d - le v e l S ie v e

R e a c ti v e c h o ic e s

F o rm ats S c re e n la y o u t

S h a re d p ro c e ss e s

E rro r c o n d it io n s

H e lp m e ssag es

T h ir d -l e v e l S ie v e

D e s ig n D o c u m e n t

1060-3425/98 $10.00 (c) 1998 IEEE

functionality testing using protocol analysis followed by a beta test to evaluate the usefulness of the methodology and the usability of the tool. Protocol analysis with three subjects revealed initial usability and functionality problems in the alpha version of the tool which were fixed for the next phase of the evaluation. Due to space limitations, we will describe only the highlights of the beta test.

4.1. Beta Test The focus of the second stage of the evaluation was to determine the validity, relevance, usefulness and ease of understanding of the methodology as well as the usability and utility of the software. For this, we carried out usability testing in the form of a beta test using the “beta” version of HyperDesign. We adopted a combination of a laboratory study approach and a casestudy approach using both students and professionals as participants. Note that such an informal usability testing approach is in line with the practice of “discount usability engineering” first proposed by Nielsen [19]. The emphasis is to take a “common-sense” approach to gather rapid feedback at low cost so that more iterations of a system can be tested. One group of participants contained seven undergraduate students taking a course on Designing Interactive Systems while another group consisted of five professionals from a large financial institution. While the students used the methodology and the tool to plan the interface for an Issue Based Information System, professionals were encouraged to use this approach to any “real” problem that was of interest to them in their work environment. At the end of the task assignment, participants completed a five part questionnaire, containing both closed and open-ended questions, requesting for the following information: background information, perception of the importance of the user interface design process, design practices in the organization, usefulness of proposed design methodology for interface design and requirements gathering, and usability of HyperDesign software. Both students and professionals reported that the methodology was moderately valid and relevant to designers in the real world. Both groups reported that the methodology was moderately useful to think and plan about UI design. Students reported that the methodology was moderately easy to understand while professionals were more neutral. While students readily accepted the non-linear approach, professionals preferred a more linear (or guided) approach since they were accustomed to procedural ways of developing systems. Both students and professionals reported that the tool was moderately difficult to understand and difficult to use. However, both groups moderately agreed that a tool like HyperDesign is

required to assist designers to structure their thought processes during the early stages of UI design. Both groups were moderately satisfied with the output of the methodology. Students moderately agreed that the design output of the tool can be used by a technical team as a specification document. Students also indicated that they were more likely to use the tool in the real world than professionals. In general, students spent more time with the tool completing more number of design tasks compared to professionals. Based on an analysis of problems reported by participants as well as their responses to open-ended questions, a number of modifications have been suggested to the software in order to increase its usability and acceptance by designers.

5. Contributions We have developed a systematic design approach and a tool to support the planning and idea generation phase of the user interface design process. The entire UI design process can be compared to the 4-Ps Model of Creativity [6]. This model states that creativity is a dynamic phenomenon comprised of four highly interactive components: the person who is the creative agent (designer), the process that is put into action (planning and idea generation phase), the product that is the outcome of the process (UI design specification), and the press or the environment in which the first 3-Ps interact (user interface design process). The focus of our research has been to encourage creativity in the design process followed by an individual designer. We see (Table 2) that the design tasks proposed by this methodology can be compared to some of Couger’s twenty-two structured techniques to facilitate creativity [6]. We direct the reader to Couger’s comprehensive text for definitions and details of these techniques. Couger who initiated empirical studies in each of the 4-Ps of the creativity model suggests that IS organizations can benefit a great deal by combining the results of creativity research in the areas of creativity potential of people, creative processes, criteria to measure creativity of IS products and services, and providing a positive climate for creativity [7]. In the context of the UI design process, we have made a beginning in this direction by supporting the creative abilities of an individual designer during the idea generation phase. Whereas Couger's research focuses on IS as a whole, we have focused only on the user interface design aspect of the IS process and specifically the upstream activities of planning and idea generation. This systematic approach is an essential first step towards formalizing what designers should do while designing. Although they might currently have their own ways of planning the interface, none of it is formal or

1060-3425/98 $10.00 (c) 1998 IEEE

reported in research literature. The methodology and the tool will actively provide the designer with a set of design tasks to be completed as opposed to being a passive online reference for guidelines and other usability principles. We believe that a non-recipe based, hypertext approach to design encourages creativity and provides the flexibility required for carrying out interface design and refining requirements. Both the methodology and the tool fit into the larger context of other methodologies and tools in software engineering.

creativity of the designer’s output through expert judging, designer satisfaction with the process and the product, and the completeness of the methodology. We also need to compare the design outputs of designers who use this approach versus those who do not. The creativity of the resulting user interface design specification based on the use of this methodology can be measured in terms of both utility and novelty using some of the metrics suggested by Couger and Dengate [8]. Utility of an IS product can be measured in terms of reduced costs, increased return on investment, retaining market niche, maintaining customer

Table 2. Couger's creativity techniques compared to proposed design methodology. Couger’s Creativity Techniques (1995) Brainstorming/Brainwriting Techniques Boundary Examination Attribute Association Technique Manipulative Verb Technique Analogies/Metaphors Technique Bug List Technique Decomposable Matrices/Progressive Abstraction Techniques Interrogatories (5Ws/H) Technique Left-Right Brain Alterations Technique

Proposed Design Approach In general, the entire methodology currently supports the individual designer to capture his or her thought process during the early pre-design activity. Identify Requirements Identify Objects, Relationships, Qualifiers, Lists Identify Operations, Shared Processes, Strategic and Reactive Choices, User Interaction States Identify Metaphor(s) Identify Error Conditions, System and Help Messages The entire design approach of moving from an abstract set of goals to a concrete user interface design specification is achieved by progressive decomposition and refinement. The entire methodology focuses on the designer asking the Who-What-Where-When-Why-How (5Ws/H) questions with respect to user interface design. The proposed approach involves left-brain functions such as reading, writing, analyzing, idea-linking, abstracting, categorizing, logic, reasoning, and judgment. It also involves right-brain functions such as understanding analogies/metaphors, seeing the whole picture, synthesizing, visualizing, spatial perception and recognizing patterns (Identify Formats and Screen Layout)

6. Future Research The methodology is a first step towards acknowledging the existence of a creative phase during the user interface design process. The output of this HyperDesign (and the methodology) is a set of informal, textual documents which together form the user interface design specification. There is no structure to this formal output. Generation of the output in a formal language may facilitate the integration of this tool with graphical user interface builders and other CASE tools. The written design specification generated by this approach can be used to create mockups and prototypes in order to study the graphical, functional, and behavioral aspects of the actual user interface. More work is required in the area of incorporating formal design rationale (such as IBIS) facilities. We believe that a successful interface design morphology can serve as a structured communication template between designers and users. This needs to be tested in future through case studies and field trials. Controlled experiments need to be conducted to observe how well this methodology supports the creative process. That is, we need to measure aspects such as the

base, improved efficiency and improved functionality. Novelty of an IS product can be measured in terms of its uniqueness, how it is used and the type of change that occurs due to its introduction. Such studies can also measure if the number of iterations of the prototyping phase are reduced (thus saving time) due to the early guidance in planning provided by this methodology. Also, designers’ subjective assessments of improvements in their own creative abilities can be measured. We acknowledge the fact that UI design (for that matter any design) is a group process. The initial focus of our research has been the individual designer and the process followed by him or her. Further research is required to observe team members in a group applying this methodology either as a basis to brainstorm or to carry out focus groups about the various design elements in a system. Such a systematic approach will greatly help a team of designers to collaboratively plan the interface for an information system and capture details of their design and also the rationale behind their design. A group collaborative system based on the principles of hypertext, computer-mediated communications and this

1060-3425/98 $10.00 (c) 1998 IEEE

design methodology can then function as a group memory system, specifically geared towards the acquisition, storage, retrieval, and dissemination of interface design specification and group design rationale in software development projects.

7.

8.

9.

7. Conclusion User interface design is a complex process. Designers need as much support as possible in the form of procedures, guidelines, techniques, and tools. We have developed a user interface design methodology and a tool to support the planning and idea generation phase during interface design. We believe that having a morphological model or structure of pre-determined design tasks will reduce the cognitive overhead on the part of designers allowing them to concentrate more on the fundamental aspects of the problem instead of spending time on figuring out how to go about designing the artifact. While many user interface management systems assist in the generation of interface components, the designer must know the mechanics of these tools. We believe that if greater emphasis is placed on actual planning activities and capturing the essentials of design in a structured manner, less time can be spent on “aimlessly” prototyping during the subsequent phase. We call out for UI designers and programmers-turned-designers to use this technique as a way to plan and think about the user interface before directly jumping into the prototyping phase. Acknowledgments: We thank Drs. Starr Roxanne Hiltz, Michael Bieber, Tomás Isakowitz, J. Daniel Couger and anonymous reviewers for their comments. We also thank NJIT students and members of the industry who participated in this research. Parts of this research were supported by NSF Grant #9015236.

10.

11.

12. 13.

14.

15.

16. 17.

18.

19.

20.

21.

22. 23.

References 24. 1.

2.

3.

4. 5.

6.

Baecker, R. M., Grudin, J., Buxton, W. A. S., and Greenberg, S. (1995). Readings in Human-Computer Interaction: Toward the Year 2000, Morgan Kaufmann Publishers, Inc. Balasubramanian, V., and Turoff, M. (1995). A Systematic Approach to User Interface Design for Hypertext Systems, Proceedings of the 28th Annual Hawaii International Conference on System Sciences (HICSS `95), Maui, Volume III, 241-250. Bieber, M. (1993). Providing Information Systems with Full Hypermedia Functionality, Proceedings of the Twenty-Sixth Hawaii International Conference on System Sciences. Bigelow, J., and Riley, V. (1987). Manipulating Source Code in DynamicDesign, Hypertext ‘87 Proceedings, 397-408. Carroll, J. M., and Mack, R. M. (1985). Metaphor, computing systems, and active learning, International Journal of Man-Machine Studies, 22, 39-57. Couger, J. D. (1995). Creative Problem Solving and Opportunity Finding, Boyd & Fraser Publishing Company.

25.

26.

27.

28.

29.

Couger, J.D. (1996). Results of a Trans-Discipline Research Structure for Study of Creativity/Innovation in I.S., Proceedings of the Twenty-Ninth Annual Hawaii International Conference on System Sciences (HICSS '96), 309-317. Couger, J.D., and Dengate, G. (1992). Measurement of Creativity in IS Products, Proceedings of the Twenty-Fifth Annual Hawaii International Conference on System Sciences (HICSS '92), 288-298. Couger, J.D., Higgins, L.F., and McIntyre, S.C. (1990). Differentiating Creativity, Innovation, Entrepreneurship, Intrapreneurship, Copyright and Patenting for IS Products/Processes, Proceedings of the Twenty-Third Annual Hawaii International Conference on System Sciences (HICSS '90), 370-379. Fischer, G., and McCall, R. (1989). JANUS: Integrating Hypertext with a Knowledge-based Design Environment, Hypertext ‘89 Proceedings, 105-117. Garg, P. K., and Scacchi, W. (1987). On Designing Intelligent Hypertext Systems for Information Management in Software Engineering, Hypertext ‘87 Proceedings, 409-432. Humphrey, W. S. (1989). Managing the Software Process, AddisonWesley Publishing Company. Isakowitz, T., Stohr, E. A., and Balasubramanian, P. (1995). RMM: A Methodology for Structured Hypermedia Design, Communications of the ACM, 38(8), 34-44. Jacobson, I., and Jacobson, S. (1995). Series of articles on the Software Engineering Process, Object Magazine, January, March, June, and September 1995. Mack, R.L., and Nielsen, J. (1994). Usability Inspection Methods: Executive Summary in Nielsen, J., and Mack, R.L. (eds.), Usability Inspection Methods, John Wiley & Sons, 1-23. Marcus, A. (1993). Human Communication Issues in Advanced UIs, Communications of the ACM. Mountford, S.J. (1990). Tools and Techniques for Creative Design, in The Art of Human-Computer Interface Design, (ed.), Laurel, B., Addison-Wesley Publishing Company, Inc., 17-30. Myers, B. A., and Rosson, M. B. (1992). Survey on User Interface Programming, Proceedings of the Conference on Computer-Human Interaction (CHI ‘92), 195-202. Nielsen, J. (1989). Usability Engineering at a Discount, Proceedings of the Third International Conference on Human Computer Interaction, HCI International ‘89, 1-8. Preece, J., Rogers, Y., Sharp, H., Benyon, D., Holland, S., and Carey, T. (1994). Human-Computer Interaction, Addison-Wesley Publishing Company. Rao, U., and Turoff, M. (1990). Hypertext Functionality: A Theoretical Framework, International Journal of Human-Computer Interaction, 2(4), 333-357. Rettig, M. (1994). “Prototyping for Tiny Fingers,” Communications of the ACM, 37(4), 21-27. SIGCHI. (1995). Special Section on Tools for Working with Guidelines, 27(2), 30-51. Simon, H. A. (1960). The New Science of Management Decision, Harper & Brothers, New York. Snow, T.A., and Couger, J.D. (1991). Creativity Improvement Intervention in a System Development Work Unit, Proceedings of the Twenty-Fourth Annual Hawaii International Conference on System Sciences (HICSS '91), 412-418. Turoff, M., Rao, U., and Hiltz, S. R. (1991). Collaborative Hypertext in Computer Mediated Communications, Proceedings of the 24th Annual Hawaii International Conference on System Sciences (HICSS `91), Hawaii, Volume IV, 357-366. Verplank, B. (1994). Interview with Bill Verplank, in HumanComputer Interaction (eds.), Preece, J., Rogers, Y., Sharp, H., Benyon, D., Holland, S., and Carey, T., Addison-Wesley Publishing Company, 467-468. Winograd, T. (1995). “From Programming Environments to Environments for Designing,” Communications of the ACM, 38(6), 65-74. Zwicky, F. (1969). Discovery, Invention, Research, Macmillan Press, NY.

1060-3425/98 $10.00 (c) 1998 IEEE