From Usability Tasks to Usable User Interfaces Kenia Sousa, Elizabeth Furtado University of Fortaleza (UNIFOR) Av. Washington Soares, 1321 – 60.811-905 – Fortaleza – CE – Brazil {kenia, elizabet}@unifor.br +55 (85) 3477-3079 ABSTRACT

integrated part of the system functionality through the inclusion of usability tasks in the task model. With this integration, we are able to include usability starting early in the process and following a specific sequence of activities in order to actually design usable UIs.

In this paper we describe how the identification of usability tasks in the task model as an early consideration of usability in the process can directly influence the design of usable User Interfaces (UI). We intend to make system analysts and UI designers work and communicate better by sharing artifacts, thus providing a process that aims at the integration of professionals working with a productive process in order to develop UIs with usability. Author Keywords

Usability tasks, integration.

user

interfaces,

usability

The early consideration of usability requirements and the representation of such requirements, through usability tasks, improve the reflection on how to concretize users’ usability requests. Besides that, the integration of usability tasks with functionality tasks makes the specification of the system more complete, with all the possibilities of interaction, and other usability aspects, such as error treatment, and user explicit control.

patterns,

ACM Classification Keywords

In this paper, we intend to present the process followed to design UIs based on usability requests, focusing on three main activities: analyzing usability requests, defining users’ tasks by considering usability requests, and analyzing usability patterns to decide the best option to attend users’ usability requests.

INTRODUCTION

We also intend to facilitate the integration between system analysts and UI designers, professionals who usually come from different academic backgrounds and have to work together in projects, sharing artifacts. We propose professionals to share the task model in an incremented manner. First, the system analyst details use cases using the task model. Then, the UI designer analyzes usability requests in order to increment the task model with usability tasks that represent usability requests.

There are also other scenarios where professionals only consider usability when designing the UI prototype, going from the elicitation of usability requests directly to the identification of which visual objects to use to attend functionality requests.

This work aims at presenting how to design UIs by starting with the elicitation of functional and non-functional requirements of an interactive system, which are detailed in a task model with functional and usability tasks.

H5.m. Information interfaces and presentation (e.g., HCI): Miscellaneous. D.2.1 [Software Engineering]: Requirements/Specifications – elicitation methods. H.5.2 [Information Interfaces and Presentation]: User Interfaces –Prototyping, Graphical User Interfaces (GUI). From our experience in the industry and in the academic environment, we have noticed that most system specifications that are made available for UI designers focus on functional aspects, such as use case specifications. In many cases, there is an additional and optional specification that may include usability aspects. But, they are usually disassociated with the established functional aspects.

This paper is organized as follows. In the second section, we present the state of the art. In the third section, we specify our proposal for designing UIs based on usability tasks. In the fourth section, we demonstrate a case study. In the fifth section, we present a discussion of the results. And, in the sixth section, we conclude this paper.

Our main intention is to make users’ usability requests an

STATE OF THE ART

In this section, we present artifacts and activities that are being generated/performed by professionals from both areas and that can be integrated in one process. The following sub-sections are task models, usability requirements, UI 1

definition plan, and UI prototyping, which influence the activities and the guidelines of the process presented here.

Usability requirements represent users’ preferences or constraints that could or should, respectively, be part of a usable interactive system. For example, provide feedback to the user; provide guidance to the user, etc. Usability requirements are usually elicited from users in the beginning of the project.

Task Models

Based on a recent study, we have decided to apply in our process use case models and task models as a detailed specification of a set of related use cases, instead of using use case flow of events. The application of use case models and task models helps UI designers and system analyst to work together during the definition of requirements, making the validation of functional and usability requirements more agile.

Usability patterns represent mechanisms to be applied in prototypes in order to address usability requirements; and they are associated to one or more usability requirements. For instance, the usability requirement ‘provide feedback’, which is a user request, is mapped to the usability pattern ‘progress indicator’.

Like most use case descriptions, such as essential use cases [Constantine & Lockwood, 1999], the task model does not focus on early design decisions and it uses small sentences to specify the tasks. On the other hand, the task model presents more advantages for the UI generation, such as the hierarchical structure, as in the CTT [Paternó, Mancini & Meniconi, 1997]; the clear expression of temporal relationships among tasks; and, as we propose, the possibility to include usability tasks in the model.

Interaction patterns represent design solutions for known usability problems; they are incorporated into the system architecture; and they are associated to one usability pattern. The usability pattern ‘progress indicator’ is mapped to the interaction pattern ‘feedbacker.class’ and it is implemented in the final system in order to provide feedback to users after the execution of a task.

The hierarchical structure is an intuitive form to decompose problems in smaller parts and maintain the relationship among all the parts, and it provides the possibility to reuse task structures [Mori, Paternò & Santoro, 2002].

UI Definition Plan

The UI Definition Plan is a new artifact included in the process as our contribution for the generation of usable UIs. Its main goal is to define which visual objects and usability patterns should be part of the UI. Its generation follows three main steps.

Concerning the relationship among tasks, its definition on the model enables UI designers to understand the hierarchical organization as groups of tasks that can be organized in sections of the system. The consideration of tasks’ relationships and the hierarchical organization can help UI designers to better define the system navigation.

The first step to produce this artifact is to group system analysts, software architects, and programmers from a software organization in order to define values (in a scale from one to five) for each visual object (e.g. combo box) and usability pattern (e.g. online help). For instance, the possible performance levels that visual objects and usability patterns can have are: extremely low (1), low (2), medium (3), high (4), and extremely high (5).

The focus of this paper is on how usability tasks can help in designing UIs. As an example, the ‘feedback’ and ‘err or treatment’ usability requirements can be expressed as the ‘show error message’ usability task performed by the system; the ‘provide search facility’ requirement can be expressed as the ‘search for info’ task.

The visual objects and usability patterns are organized in categories, for instance, search, navigation, alerts, etc. That is, for the search category, we can have simple search, advanced search, site index, FAQ, etc. We only include in the artifact categories related to the usability requirements informed by users. If the user requested feedback, we include the alert category; for guidance, we include the navigation category and the search category; etc.

The integration of usability tasks and functionality tasks makes the system specification more complete. Therefore, the system analyst and the UI designer can communicate better since they are able to see in one artifact functional and non-functional requirements expressed as tasks. For instance, in a task model with functionality tasks to include data, related to the usability task to provide explicit feedback to users, it is easy for the UI designer to know that after every inclusion of data, the system needs to present a confirmation (or not) of the inclusion.

The second step is to group users and business executives that represent the final user’s interests in order to attribute a weight (in a scale from one to five) for each non-functional requirement specified by the user as important. For instance, the level of performance that the client is expecting from the system can be: extremely low, low, medium, high, and extremely high.

Usability Requirements

Three different levels of usability are inter-related in order to allow the consideration of usability since the beginning of the product lifecycle and the actual inclusion of usability in the final system [Juristo et al., 2003].

The third step is the execution of an algorithm to decide which one is the best visual object or usability pattern in a certain category (e.g. search) to be placed on the UI. We are

2

currently researching for the best algorithm to implement this solution. Currently, UI designers and usability experts are choosing the best visual objects and usability patterns.

correct possible misunderstanding and inconsistencies in a timely and efficient manner; control changes to requirements as they appear throughout the lifecycle in order to satisfy users’ changing needs; define the system architecture considering usability; define the system structure and behavior with visual models that can be understood by users; constantly evaluate the system with users; and control the evolution of requirements through the maintenance of the product and its elements.

UI Prototyping

Prototypes can be generated in the following levels of platform-dependent categories [Coyette et al., 2004]: Paper sketches are useful to demonstrate to users which activities the system attends and the possibilities of navigation in the system, even users can help build them. Drawing prototypes are useful to demonstrate standards and style guides. Executable prototypes are useful to demonstrate navigation and usage.

In our proposal (Figure 1), functional tasks are tasks generated from functional requirements and usability tasks are tasks generated from usability requirements (or guidelines). Both usability and functional are interaction tasks, which are user actions with the possibility of immediate system feedback [Mori, Paterno & Santoro, 2002].

Prototyping can follow these categories in order to be evaluated by users in different times during the life cycle, thus, allowing detailed discussion concerning the UI design. Our approach allows UI designers to start user evaluation with a set of paper sketches alternatives since they provide agility. With paper and pencil, UI designers can show the system navigation to be validated with the users. If they want changes, they are done fast and they can be revalidated in the same meeting. This level of prototype does not need to focus on visual objects and usability patterns, which will be a result of the UI Definition Plan. THE PROCESS

Figure 1. Association of usability tasks to usable UIs.

We have been working on the definition of a lightweight development process for interactive systems that can serve as a guide, providing useful steps and artifacts that can be tailored and customized when organizations intend to develop usable interactive systems. This process is called UPi, which means a process to develop interactive systems aiming at Usability, Productivity, and Integration.

Usability requirements are associated to usability patterns, organized in categories, which can represent usability tasks. Based on a list of categories, usability tasks are selected to be included in the system. The usability patterns, previously related to the selected categories, are considered for evaluation, according to the approach presented in the UI Definition Plan. Then, the most appropriate usability pattern is selected to be included in the UI.

One of the best advantages of UPi is the idea to focus on activities, artifacts and guidelines that add value to the UI generation. With this approach, it can be integrated with any other process and inherit activities that are vital to the entire process, but that are better defined and solidified in other processes. For instance, project management, configuration and change management, implementation, and deployment activities are very well detailed in the RUP [Krutchen, 2000].

For instance, the usability requirement to provide users with ‘guidance’ has many options of usability patterns organized in the following categories: search, navigation, and help (See Table 1). The search category can become the usability task ‘search for student data’ when the system domain concerns students. Table 1. Mapping of usability requirements with usability patterns.

The UPi approach is based on five Usage Centered Design usability rules [Constantine & Lockwood, 1999] and six RUP best practices [Krutchen, 2000].

Usability Requirement

The consideration of usability rules make the UPi a process that when applied results in interactive systems that: are easy to learn and use by users who do not have experience in working with the system; are efficient to use by users who have experience with the system; accommodate changes as users gain more experience; support users in performing their work better; and consider the environment where the system will be used.

Categories (Tasks) Search

Guidance

Navigation Help

The six best practices helps the UPi to: develop the product incrementally and present each result to users in order to 3

Usability Patterns Simple search Advanced search Retractable Menu Icon menu Requested help Auto Wizard

The focus on tasks as a means for including users’ requirements in the system supports HCI and SE professionals to communicate better since they are concerned with “the work that the software is intended to support” [Sommerville, 2004].

The purpose of the UI Prototyping activity is to design a UI prototype either in drawings or in executable prototypes following the description specified in the task models, in the UI definition plan and in the system architecture.

Since usability requirements are specified in a rather abstract level, they can only be verified when the system is complete. That is the reason we propose usability tasks to be a more concrete representation of usability requirements that can guide the UI design process. Some works, such as [Bass, John & Kates, 2001], [Folmer & Bosch, 2004], [DePaoli, 2004] and [Nunes, 2003] propose that usability should also be realized in the architectural level, not only in the presentation layer. We agree with this approach by refining the architecture with interaction patterns derived from the selected usability patterns from the UI Definition Plan, as we have detailed in another work [Sousa, Furtado & Mendonça, 2005]. In this work, we want to focus on how the association of usability tasks with usability patterns can facilitate usability testing earlier in the process with prototypes. Therefore, software architects are not responsible for verifying the usability from an architecture point of view, then delaying it for users or usability experts to validate the system usability only after the implementation. UPi includes activities from requirements, analysis and design, implementation, and test, organized in four phases, as depicted in Figure 2. In this paper, we focus on the inception and elaboration phases in order to demonstrate how UPi can help in designing UIs based on usability tasks. The purpose of the Elicit Stakeholder Needs activity is to understand users, their personal characteristics and information on the environment where they are located that have a direct influence on the system definition, and to collect special non-functional requirements that the system must fulfill, such as performance, cost, and device requests. The purpose of the Find Actors and Use Cases activity and Structure the Use Case Model activities is to define and refine the use case model.

Figure 2. UPi activities.

The purpose of the Detail a Use Case activity is to: describe the use case’s tasks using the task model ; describe any usability requirements related to the use case; evaluate their positive and negative implications; and define the system navigation based on the task model hierarchical structure, using paper sketches.

The purpose of the Evaluate Prototype activity is to verify if the UI prototypes are in accordance to usability principles and to validate with users if the UI prototypes are in conformance with their view of the system and needs. To better understand the order of execution of the activities during the case study, it is important to notice that these activities were performed in three iterations. In the first iteration, we performed activities from inception (elicit stakeholder needs and detail use case) and elaboration (define UI plan and UI prototyping). In the second iteration, we performed an activity from inception for the first time (review requirements) and repeated an activity from elaboration (UI prototyping). In the third iteration, we

The purpose of the Review Requirements activity is to verify with users if the requirements are in conformance with their needs by showing them the elaborated paper sketches. The purpose of the Define UI Plan activity is to define which visual objects and which usability patterns can be part of the UI according to the non-functional requirements defined in the Elicit Stakeholder Needs activity. 4

performed activities from construction (implement components), and transition (evaluate the system)

institutions involved in this project have visited people in their houses to research how they interact with the TV in order to use the resultant information as definitions for the Brazilian DTV system.

CASE STUDY

In this section, we present the application of UPi in a research project to define the Brazilian Digital TV (DTV) System. In this project, we are responsible for developing an executable prototype for the DTV access portal, which is an interactive application that provides access to all the other interactive applications in the DTV.

With the result from the brainstorming in hands, we needed to organize these ideas in functionality for the DTV portal, as specified in the next sub-section. Requirements Definition

Our main goal in this strategy was to organize the functional and non-functional requirements in use case models and detail them in task models, as specified in the UPi activities Find Actors and Use Cases, Structure the Use Case Model, and Detail a Use Case.

Brainstorming

Our main goal in this brainstorming meeting was to identify the main functional and non-functional requirements for the DTV portal, as specified in the UPi activity Elicit Stakeholder Needs.

First, we grouped all the requests in five main tasks for the DTV portal: (i) Interact with applications; (ii)Personalization; (iii) Help; (iv) Insertion of text; and (v) Navigation.

The stakeholders were represented by professionals from other institutions that are participants of this project and users’ representatives, who were students randomly selected from the participating institutions.

These tasks were detailed in a task model, as depicted in Figure 3, which shows functional and usability tasks mixed together in the same model. Usability tasks do not lead to changes in the structure of the task model because usability tasks are interaction tasks.

These students were representing two distinct groups of users: digitally literate, and digitally experienced. Unfortunately, we did not have the participation of digitally illiterate users because we did not have eligible time to

Figure 3. Task model.

prepare materials to explain to them the characteristics of this new interaction device.

One example of functional task is the task to interact with an application, which was explicitly requested during brainstorming meetings. One example of usability task is the task to personalize the portal, which attends the following usability requirement: adaptability to users’ specific needs. This task is composed of the following subtasks: personalize the visualization of data, personalize background and font color, and personalize font size.

As a result of the brainstorming meeting, we listed the following (functional and usability) requirements: (i) possibility to interact with various applications, organized in categories, from the portal; (ii) flexibility to enable the inclusion of new applications to be accessible through the portal; (iii) allow access to multiple applications simultaneously; (iv) there should be some level of adaptability to users’ specific need s; (v) facilitate insertion of text for several applications; (vi) provide guidance for novice users; etc.

Then, we defined some options of interactions (usability patterns) for each task. For instance, for the insertion of text: (i) Virtual keyboard with the cellular phone pattern; (ii) Virtual keyboard with the computer pattern; (iii) Virtual keyboard with the alphabet sequence; and (iv) Physical keyboard with the computer pattern. For personalization of colors: (i) provide pre-defined color templates; and (ii) offer a list of colors from where the font and background colors can be chosen.

One recommendation to be followed when eliciting stakeholders’ needs is to perform user analysis using contextual inquiry, which is valuable to understand how users achieve their goals in their own environment. Other

5

Then, we needed to evaluate these options according to Nielsen’s usability goals [Nielsen, 1993], such as ease of learning, efficiency in use, satisfy users’ needs , decrease the number of errors, facilitate navigation, etc.

of positive implications over the negative ones. The result of this work was the generation of a table associating usability patterns with their positive and negative implications (See Table 2). Our next step was to concretize these ideas by generating the UI prototypes, as explained in the next sub-section.

In order to do that with the participation of the other institutions of the project and with users’ representatives, we scheduled our first usability workshop, presented in the next sub-section.

Prototyping

According to the categories of prototypes previously presented in the state of the art section, the UI designers started by designing device-dependent paper prototypes, as specified in the UPi activity UI Prototyping, in order to concretize the decisions made during the first usability workshop.

First Usability Workshop

Our main goal in this workshop was to choose the best usability pattern for each requirement based on the evaluation of positive and negative aspects of each proposed usability pattern, as specified in the UPi activity Define UI Plan, which considers the strategy presented in [Rosson & Carroll, 2001].

First, three UI designers discussed among themselves the implications of each decision and prepared some versions of paper sketches until they reached a final version of the paper prototypes.

These proposed usability patterns were selected from a list, such as the one available in [Welie, 2005], which are organized in the following format: problem to be solved, solution, context in which it can be used, and graphical illustration.

Concerning the personalization example, Figure 4 depicts three buttons on the top bar, which are related to: font/background color; font size; and organization of data. When the user selects one of these three buttons, the bottom bar presents four buttons, which correspond to four options for each kind of personalization. For instance, four options to combine background and font color; four options of font size; and four options to organize the visualization of data, dividing the space.

For the participants to evaluate the usability patterns, we provided a set of guidelines. After they read the guidelines, each group evaluated the positive and negative aspects of each usability pattern suggested for the requirement. Then, the participants discussed and reached the final decision of which was the best usability pattern for the requirement under discussion. The personalization group considered the guidelines as they evaluated the positive and negative implications of each usability pattern, aiming at achieving Nielsen’s usability goals. For demonstration purposes, we focus on presenting the personalization of colors. Table 2. Evaluation of usability patterns.

Usability Pattern

Implication + efficiency of use

Provide pre-defined color templates to change font/background colors.

+compatibility of the system with the real world + clarity of information - the user has a limited range of choices

Offer a list of colors from where the font/background colors can be chosen.

+ increase satisfaction

the

Figure 4. Prototype for personalization.

After the work of the UI designers, the paper prototypes were evaluated (Review Requirements) by three usability experts, who analyzed if each prototype was following Nielsen’s ten heuristics, such as correspondence to the real world, user explicit control, uniformity, flexibility, etc.

user

+ flexibility of use - difficulty beginners

in

use

by

After the heuristic evaluation, it was clear that the personalization follows the user explicit control heuristic, since it lets users explicitly choose the option of personalizing, instead of the system doing it for them, and it

As a result of the evaluation, the personalization group decided to use color templates because of the greater impact

6

also allows users to return to the previous option when requested.

captured the interaction with the DTV using a specific software.

When the prototypes were changed to suggestions of the evaluators, we needed to paper prototypes to receive feedback from the from the first usability workshop, as detailed sub-section.

After the tests, we evaluated the checklists and generated reports with solutions to the problems encountered during the tests. These reports contain solutions that are associated to Nielsen’s usability goals and to usability patterns.

reflect the present the participants in the next

DISCUSSION

Rosson and Carroll proposed an approach to decide which features to include in the UI based on positive and negative characteristics of each feature [Rosson & Carroll, 2001].

Second Usability Workshop

Our main goal in this workshop was to evaluate the paper prototypes for each requirement, as specified in the UPi activity Review Requirements.

The difference between the table generated in the first workshop (based on Rosson and Carroll’s work) from the UI definition plan (which we yet intend to apply) is that the UI definition plan considers users’ preferences, according to the elicited non-functional requirements, and it also considers the software organization’s and the client’s reality concerning costs, not focusing only on usability implications. In general, the UI definition plan provides a more solid decision making process based on mathematical calculus, instead of letting UI designers decide which objects and patterns to allocate on the UI solely based on their knowledge, or letting users’ repres entatives give design opinions with no prior knowledge.

Each group evaluated the paper prototypes. As a result, some changes were requested for the personalization UI prototype, such as the inclusion of a preview area where the user can preview the changes in data display, font size, or color before actually selecting an option in order to provide more efficiency in use. Besides that, the options of personalization were included in the preview area, excluding the bottom bar in order to facilitate navigation. With the final version of the prototypes, we had enough information to pass to the developers so they could start Implementing Components to be evaluated by users’ representatives.

The advantage of using patterns instead of only relying on guidelines is that they are in essence very general and require specialized knowledge from the UI designer. For instance, to apply the guideline “maintain consistency”, UI designers would have to know that they need to determine specific areas for: output/input data, error messages, instructions, etc. On the other hand, usability patterns graphically presented on a UI as solutions for users’ requests are easily and more productively applied during the UI design process when previously mapped.

Currently, the developers are working on implementing the executable prototypes. They have finished implementing three applications for insertion of text, which allowed us to start performing usability tests, as explained in the next subsection. Usability Tests

Our main goal with tests performed with users is to validate requirements and the prototypes, as proposed in [Schilling et al., 2005] and specified in the UPi activity Evaluate Prototype.

The main contributions in this process are the following:

A group of three usability experts were responsible for performing the following activities before the tests started: First, they defined a questionnaire to apply with users in order to understand their characteristics and familiarity to the DTV technology. Second, they selected appropriate metrics (e.g. number of errors, number of access to the help, etc). Third, they created a checklist based on Nielsen’s usability goals and on the metrics from the previous step. Fourth, they prepared the environment with a DTV, a couch, and a center table in order to make users feel at home. Fifth, they selected users with different profiles between the age of seven and fourteen.

Usability requirements (e.g. guidance, feedback) should be pointed out as usability tasks performed by users in order to be used as a bridge between general usability requirements and usability patterns that can be seen and understood by users through prototypes. The UI Definition Plan allows UI designers not to rely only on their skills and facilitates their decision–making process by evaluating patterns according to multiple perspectives and with user participation. The mapping of usability requirements, usability tasks, and usability patterns can be used as a source for UI design. When the organization acquires a reliable source based on the literature and also on experience that can be used as reusable knowledge, UI designers do not have to rely only on their skill.

When the users arrived, each one at a time was taken to the DTV room, where a usability expert explained the goals of the test; applied the questionnaire; and defined a specific goal to be achieved while interacting with the DTV. While the user interacted with the application, usability experts filled out the checklist in the visualization room, where we monitored the environment and the user with a camera and

These contributions improve the design of usable UIs because it makes the UI design process more inter-related, that is, no specification defined in the beginning of the

7

process is left forgotten in a document. Each requirement, either functional or non-functional is mapped into a task, which in turn is associated to a list of patterns that are visualized in prototypes, thus, allowing evaluation with users early in the process.

5. Folmer, E.; Bosch, J. Cost Effective Development of Usable Systems; Gaps between HCI and SE. In: ICSE 2004 - Workshop Bridging the Gaps Between Software Engineering and Human-Computer Interaction, 2004, Scotland. 2004. 6. Juristo, N.; Lopez, M.; Moreno, A.; Sánchez, M. Improving Software Usability through Architectural Patterns. In: Workshop Bridging the Gaps between SE and HCI - International Conference on Software Engineering (ICSE), 2003, USA. 2003, pp. 12-19.

CONCLUSION

The main goal in this paper is to present a real application of UPi in a research project in order to prove that this process is able to achieve results that are aimed by most professionals involved in designing interactive systems.

7. Krutchen, P., Ahlqvist, S., Bylund, S. User Interface Design in the Rational Unified Process. Object Modeling and User Interface Design. Mark Van Harmelen Eds. Addison-Wesley, 2001.

The main contributions of this process are: (i) the participation of users throughout the process, especially during requirements elicitation, requirements validation, and prototyping; (ii) the concretization of usability requirements through the identification of usability tasks; (iii) the integration of usability tasks and functionality tasks in the task model; (iv) the use of task models to facilitate the organization of UIs based on the task model’s hierarchical structure; (v) the evaluation of multiple usability patterns to choose the one most suitable to functional and non-functional requirements; and (vi) the iterative evaluation of the UIs starting with the evaluation of prototypes until the implemented system.

8. Mori G., Paternò F., Santoro C. CTTE: Support for Developing and Analyzing Task Models for Interactive System Design. IEEE Transactions on Software Engineering. August, 2002, pp.797-813. 9. Nielsen, J. Usability Engineering. Academic Press, Cambridge, MA, 1993. 10. Nunes, N.J. What drives software development: issues integrating software engineering and human-computer interaction. In: INTERACT 2003, Zurich. 2003.

The results we achieved with the process were the following, which are related to each contribution specified above, respectively: (i) user satisfaction; (ii) the decrease in the number of change requests in the final system related to the lack of usability; (iii) better communication between UI designers and system analysts; (iv) the facilitation of the work of UI designers; (v) the design of UIs more consistent with users’ requests; and (v i) the design of usable prototypes.

11. Paternó, F., Mancini, C., Meniconi, S. ConcurTaskTrees: A Diagrammatic Notation for Specifying Task Models, Proceedings Interact’97, pp.362-369, July’97, Sydney, Chapman&Hall, 1997. 12. Rosson, M. B., Carroll, J. M. Scenarios, Objects, and Points of View in User Interface Design. Object Modeling and User Interface Design. Mark Van Harmelen Eds. Addison-Wesley, 2001.

REFERENCES

13. Schilling, A; Madeira, K.; Donegan, P.; Sousa, K.; Furtado, E.; Furtado, V. An Integrated Method for Designing User Interfaces Based on Tests. In: ICSE 2005 – Workshop on Advances in Model-Based Software Testing, 2005, Missouri. 2005.

2. Constantine, L., Lockwood, L. Software for Use: A Practical Guide to Models and Methods of UsageCentered Design. Addison-Wesley, Reading, 1999.

14. Sommerville, I. Making Ethnography Accessible: Bringing Real-World Experience to HCI Designers and Software Engineers. In: ICSE 2004 - Workshop Bridging the Gaps Between Software Engineering and Human-Computer Interaction, 2004, Scotland. 2004.

1. Bass, L. J, John, B. E. & Kates, J. Achieving usability through software architecture. Carnegie Mellon University/Software Engineering Institute Technical Report No. CMU/SEI-2001-TR-005. 2001.

3. Coyette, A., Faulkner, S., Kolp, M., Limbourg, Q., Vanderdonckt, J., SketchiXML: Towards a Multi-Agent Design Tool for Sketching User Interfaces Based on UsiXML. In: TAMODIA’2004, Ph. Palanque, P. Slavik, M. Winckler (eds.), ACM Press, NY, 2004, pp. 75-82.

15. Sousa, Kenia; Furtado, Elizabeth; Mendonça, Hildeberto. UPi - A Software Development Process Aiming at Usability, Productivity and Integration. In: CLIHC 2005, Mexico. 2005.

4. DePaoli, F. A service-oriented approach to bridge the gap between Software Engineering and HumanComputer Interaction. In: ICSE 2004 - Workshop Bridging the Gaps Between Software Engineering and Human-Computer Interaction, 2004, Scotland. 2004.

16. Welie. 2005. Available at: http://www.welie.com. Accessed in: June, 1st, 2005.

8