You are on page 1of 10

User Interface Ontwerp User Interface Design 2011 2012

Prof. Dr. O. De Troyer Responsible assistant: William Van Woensel userinterfacedesign@wise.vub.ac.be WISE Research Group http://wise.vub.ac.be/ Department Computer Science Vrije Universiteit Brussel

Project

Table of Contents
1 2 Goal of the Project .................................................................................................................... 2 Phases of the Project ................................................................................................................. 2 2.1 Definition of the User Classes & Usability Requirements Collection .............................. 2 2.1.1 User Classes .............................................................................................................. 3 2.1.2 Usability Requirements ............................................................................................. 3 2.2 Analysis & Modeling Phase .............................................................................................. 4 2.2.1 Analyzing & Modeling User Tasks........................................................................... 4 2.2.2 User Object Modeling ............................................................................................... 4 2.2.3 Style Guide Definition .............................................................................................. 5 2.3 User Interface Design, Prototyping & Evaluation ............................................................ 6 2.3.1 Design ....................................................................................................................... 6 2.3.2 Prototyping ................................................................................................................ 6 2.3.3 Evaluation ................................................................................................................. 7 3 Practical setup ........................................................................................................................... 7 3.1 Groups ............................................................................................................................... 7 3.2 Subject: Business & modular interface ............................................................................. 7 3.2.1 Assignment ............................................................................................................... 9 3.3 Requested Deliverables ..................................................................................................... 9 3.4 Deadlines and Appointments ............................................................................................ 9 3.5 Contact ............................................................................................................................ 10 3.6 Evaluation ....................................................................................................................... 10 3.7 Evaluation Criteria .......................................................................................................... 10

1 Goal of the Project


The students should design a user interface for a specified application and develop a prototype for this user interface. Usability is a central theme in this course; therefore the user interface you propose should have a high degree of usability. The degree of usability will be a very important criterion in the evaluation of the project. A low usability will be reflected in the mark (see also section 3.7 Evaluation Criteria). Another important aspect is the requirement to use the design method for user interfaces explained in the course (and illustrated below). If the method is not used (or only partially used) this will also be reflected in the mark! The ideal UI design cycle as described in the theory (and which must be followed) is illustrated in the following figure.
Define users and Usability Requirements
User Classes Usability requirements

User Task Analysis & Modeling

User Object Modeling


User Object Models

Define Style Guide

Task models Task scenarios

Style Guide

Design UI

Prototype UI

Usability problems

Usability requirements

Evaluate UI
UI design

Figure 1. UI design cycle.

2 Phases of the Project


The following phases are to be performed in the project: Definitions of the User Classes & Usability Requirements Analysis & Modeling: User Tasks Analysis & Modeling, User Object Modeling, and Style Guide definition User Interface Design, Prototyping and Evaluation

2.1 Definition of the User Classes & Usability Requirements Collection


A classical software design process usually contains a requirements collection and analysis phase, consisting of the acquisition and analysis of all information needed to design and implement the system. The output of this phase, called the Software Requirement Specification

(SRS) does not contain any solutions; it only contains a full and complete specification of the system as desired by the customer. The information needed is usually obtained by one or more interviews with the customers and other stakeholders. The SRS includes the functional and nonfunctional requirements.1 In principle, user classes and usability requirements should be part of the SRS, but usually they are rather poorly specified in the SRS2. The purpose of this project is to design the user interface of the application. Therefore, we do not ask for the full Software Requirements Specification3; however, we do ask for a detailed specification of the requirements related to the user interface. The method to be used prescribes that the first thing to be done is the identification of the intended users of the system. These users should be classified into user classes, based on their characteristics and their system use. Subsequently, usability requirements are formulated for each user class. Note that usability requirements are usually related to functional or non-functional requirements. Therefore, it may be useful for you to also provide a list of functional and non-functional requirements, and refer to these requirements in the usability requirements where appropriate.

2.1.1 User Classes


The goal here is to identify the different type of users of the system and their characteristics. This identification will have an impact on the design of the user interface. Users are classified into user classes based on their use of the system and their characteristics. Users that are similar in terms of system use and characteristics are in the same user class. For each user class, the characteristics that may have an impact on the user interface should be specified. It is left to the student to decide which characteristics to include, but be sure not to leave out these important ones: Type of user (direct, indirect, remote, support) Experience level (task knowledge) Frequency of use Existing computer experience/skills Other systems that will be used concurrently Motivation for using system

2.1.2 Usability Requirements


The goal is to identify the usability requirements for the system. These are the requirements that should be satisfied in order to make the system easy and efficient to work with, as well as easy to learn. Note that it is neither possible nor desirable to specify all possible usability requirements. You should concentrate on usability requirements that will make the difference between a good usable and a frustrating system. Also note that the requirements that you specified should be satisfied by your design (proved by means of evaluation)!! For each usability requirement, you should specify the following: Description Motivation User class(es) for which the requirements is applicable (use ALL if the requirement is for all user classes) Measuring concept Measuring method Criteria for judging (current level, worst acceptable level, planned target level, best possible level)
1

For a further and more complete elaboration on the classical software design process we refer to the software engineering course, and the programming assignments for the 3 rd bachelor computer science. 2 The IEEE specification only includes the general header User Interfaces under the section Specific requirements External interface requirements 3 That is, using the IEEE standard and standard techniques as the UML Use Cases.

As mentioned before, it may be useful that you provide a list of functional (or non-functional) requirements, and refer to them in the usability requirements where appropriate. This will also prevent you from mixing up functional requirements and usability requirements. You should at least provide a description for such a functional (or non-functional) requirement mentioned. Note that usability requirements should not be overly general or vague (e.g., the task should be completed fast; the system should be usable for different kinds of users; minimal effort should be required for learning to use the system; ..). Instead, focus on usability requirements specific to the system under development (e.g., when resolving reservation conflicts, display reservations related to the conflict together with the related rooms; show an overview of important data entered in the form before submitting the data; provide the possibility to edit a certain property of a number of rooms at the same time; ..). Also, it is important to motivate your requirements; implementing support for requirements takes time and effort, so why is this usability requirement important to the system at hand?

2.2 Analysis & Modeling Phase


In the context of user interface design, the Analysis & Modeling phase consists of three sub phases: identifying, analyzing & modeling of the user tasks, defining the user object model(s) and defining the style guide. Note that, although these three phases are described separately, there is a very strong correlation between modeling of user tasks and defining the user object models.

2.2.1 Analyzing & Modeling User Tasks


The goal of this phase is to identify, analyze and model the tasks of the users, in order to identify which ones need to be supported by the system and how. User tasks need to be defined and modeled for each user class. Each task need to be modelled by a CTT. In addition, for each user class, a high-level CTT should be provided linking together the tasks for this user class using temporal relations (e.g., login, add / edit / remove item). Also, take care to re-use tasks as much as possible (e.g., search room: re-use this task in the edit / delete room tasks in case a room first needs to be selected). If some tasks are common to some user classes and are performed in the same way for the different user classes, you can indicate this by using the same name for the task; the task only needs to be elaborated once. Keep in mind that when modeling tasks in UI design, we model the tasks of the user (and not the tasks of the system itself) and in addition, the modeling of the task is done from the perspective of the users (and not from the perspective of the system). User tasks may include tasks that will not be supported by the system (like picking up the phone, making a decision). The user tasks that need to be supported by the system are elaborated into more detail. Take care to decompose as far as needed. If you start to model UI action (like push a button, or select an item from a menu), you are too far! Indeed, you still have to design the UI. Also, dont stop too early; tasks like enter user information can still be subdivided in tasks where individual user properties are entered. To model the user tasks, you SHOULD use CCT (Concurrent Task Trees) (technique treated in the lectures).

2.2.2 User Object Modeling


The goal of this phase is to define the object models for the different user classes. These models should define the objects the user manipulates in order to fulfill their tasks. Therefore, these models should be cross-referenced with the task models (i.e. check that all objects needed in the tasks are available in the user object models). Make a model per user class. Only if all user classes have the same user object model then one user object model is sufficient (however, note that in 99% of the cases, separate user models will be needed!). Again, we stress that during modeling of the user objects, the viewpoint of the user should be used, not the viewpoint of the system. The

objects that need to be modeled in this phase are the objects the user has in mind and expects to find, sees and manipulates; not objects that are be internally used by the system, nor the system objects that will be used to represent user objects4. As a technique to describe the user object models, the students should use either the EER modeling technique, the ORM technique, or UML class diagrams.5

2.2.3 Style Guide Definition


The objective of specifying a style guide is to define a standard style and a consistent look and feel for the UI. Keep in mind the characteristics of the different user classes (type of users) and the rules and guidelines of dialog support given in the theory when making the style guide. At least the following items should be included (if applicable): Standards for window interaction (opening, closing, navigation, etc.) For instance, how are windows closed and minimized, and how does navigation occur between the different windows (e.g., between left and right pane; object windows are opened when clicking on a content item; ..). Standard window layout This specifies which types of windows exist (e.g., task / object / help windows), for what they are used, and what their default layout is (this can include screen mock-ups). Standards for menus and push buttons (e.g., naming, appearance, sequence, behavior) This part specifies which types of menus and push buttons exist, and what their default behaviour and layout is. For instance, destructive options are always displayed at the bottom left, and when not usable in the current context, options are greyed out. Standards for use of keyboard keys This includes available shortcuts: for instance, CTRL-N to make a new content item; pressing enter always submits the current form; using the left and right arrow keys allows navigating through the tabs; .. Standards for use of graphics, tables and diagrams If relevant, this part specifies the default representation of graphics, tables and diagrams in the user interface. For instance, in case of diagrams, use a specific type (e.g., line) for a specific purpose (e.g., indicating the evolution of data); use the sa me background color for tables and diagrams; .. Standards for use of window controls, and mapping of data types to window controls This part specifies which window controls are used for which types of data. For instance, when a limited amount of values is available, use a dropdown box; in case small integers need to be entered, use a spin box; use a calendar view to enter dates; .. As another example: when a list contains more than 10 values, provide means to filter this list (e.g., via autocomplete). Standard use of color, type, fonts, etc. This part specifies which colors and fonts are used in which cases. For instance, the VUB color scheme is used; the title of a screen is always in bold and size 24px; clicked objects (i.e., hyperlinks) are given a different color; .. Standards for common user objects This part specifies how common user objects (e.g., users, books, rooms, ..) are displayed in the system. For instance, when a user is displayed in search results, their username, first and

Although the same modeling techniques can be used for the object model and classical data models, the difference between the two is the nature of the objects: objects perceived by the user are modeled in the User Object Model (which do not necessarily correspond to internal objects), and internal data objects are modeled in a data model. 5 Since EER and UML were taught in mandatory bachelor courses, these techniques are assumed to be known. Students that are not familiar with any of these techniques should study them on their own.

last name are given, while in the users object window, their birthdate, e-mail address, address, .. are additionally given. Standards for integration of information/objects from other applications (e.g., cut and paste) If relevant, this part specifies how objects from other applications can be imported in the application. For instance, menu options can be available; keyboard shortcuts (e.g., CTRL-C, CTRL-V) can be used; items can be dragged from Windows Explorer and dropped in the user interface; ..

If applicable, it is allowed to refer (with a valid reference of course!) to existing, well known and used style guides (for example, the KDE style guide, or the Windows Style Guide), but don't forget that these style guides only provide the basic, generic style for any application; you should ALWAYS complement them with the specific details needed for your own application!

2.3 User Interface Design, Prototyping & Evaluation


Interface design, prototyping, and evaluation are strongly connected and form an iterative process. The students are expected to go through these three phases in an iterative manner, until they obtain a final prototype, i.e. a prototype that satisfies the usability requirements specified and supports all specified tasks, is acceptable for the customer, and can be used as input for the actual implementation. The students are expected to report on their design, prototype, and how they got from the initial design to their final design (and final prototype), which evaluation techniques they used and what changes these brought along in the design (and prototype). Also note that based on the design reports and prototype you deliver, a third party (software developers) should have all the necessary information to actually implement this design.

2.3.1 Design
Obvious, the output of the previous phases should be used as input for the design of the UI. The design should take into account the different user classes; the user tasks that need to be supported; and the object model(s) that were created in correlation with these tasks. Naturally, the dialog design should be consistent with the style guide and appropriated for the target user classes. Apply the task-driven design technique given in the course to come to a UI design. Give (as a first step in the design) the enabled task sets (not how you derive them).

2.3.2 Prototyping
The goals of prototyping are to detect usability problems in the user interface and to provide validation of the user models (task models and object models), the style guide definitions and the user interface itself. To reduce the risk of an unsuitable UI and improve the acceptance by the user, actual users should be involved in the validation of the prototype. You are asked to build a prototype using a tool that allows for (basic) interactivity in prototypes, such as Axure6, GUI Design Studio7, Balsamiq8 (make sure the evaluation period of the chosen tool does not expire before the end of the project!). The final software prototype has to be COMPLETE! This means that we want a prototype with a UI for each of the user classes and for all user tasks that need to be supported by the system. The actual functionality (e.g., adding users and documents to a database) should not be provided; however, basic interactivity (such as navigating between screens, closing screens, etc) should be present. Note that, although the actual interface has to be desktop-based, you are allowed to use web-based techniques (e.g., HTML) to prototype this interface.

6 7

http://www.axure.com / http://www.carettasoftware.com/gds/ 8 http://balsamiq.com/

Also note that your prototype should display realistic information. For instance, if in the actual system a UI list will contain around hundred items, this amount should also be reflected in the prototype, i.e. showing this list with only 3 example items is not reflecting the true situation and will not allow to judge the usability in a correct way.

2.3.3 Evaluation
The goal of the evaluation of the prototype is to check whether the UI satisfies the usability requirements that were formulated and to provide validation of the models (task models and object models) and the style guide definitions. When flaws are detected, a new iteration of the previous phases is needed. Note that detected flaws will always influence your design and prototype, but it may potentially also influence earlier phases (i.e. requirements, user tasks, etc); in this case, you should alter all phases appropriately! For your own project, you should apply a formative evaluation method (as described in the course). A short evaluation report is required, describing the evaluation method(s) used, together with relevant information (e.g., in case of cognitive walkthrough, the evaluated tasks), the usability problems detected, and the resulting changes made to any design phase and the prototype(s). Furthermore, note that you will be asked to apply a summative evaluation method on the project of another group (see section 3.2.1), for which a more extensive evaluation report will be required.

3 Practical setup
3.1 Groups
The project will have to be completed in groups of three students. Working (evening) students are encouraged to work in groups of two or three students as well, but we will allow exceptions given their specific situation. In that case, they will receive a reduced assignment. How the work is divided internally is up to you and is not relevant for the evaluation; the work will be evaluated as a whole, and all group members will receive the same mark. In case you experience serious problems with your partners (for example, one partner is refusing to cooperate), the responsible assistants of the course should be notified as soon as possible. Notifying the assistants a few days before a deadline is of course far too late, and will not be taken into account. You will be given a deadline to form your groups. Once you found other group members, one of the group members mails the composition of the group to userinterfacedesign@wise.vub.ac.be, CCing the other group members. After the deadline for group formation, the remaining students will be assigned to a group by the responsible assistants.

3.2 Subject of this years project: Business & modular interface


Note: groups with only one student only need to support the functionality indicated between and (i.e., this functionality does not need to be supported, while this functionality needs to be supported).

In this project, you will be asked to develop the interface for a business application, meant for small to medium-size shops. This tool will be a classical desktop application. The application is modular, meaning it consists of cooperating modules that each implements some functionality (e.g., one module is responsible for stock management, another for selling products, etc). The application will be used by shop clerks and shop managers. Shop clerks are employees with only minimal responsibilities and training with the application, and their numbers depend on the size of

the shop. Shop managers are responsible for managing stock and sales, and are better trained in using the application; only a very limited amount of managers per shop exist. The first module is the stock-management module. This module is responsible for managing all products in the shops stock, and is used by shop managers. Each stock product (e.g., Coke) has a type (e.g., beverage), a price, and a stock amount (e.g., 53 in stock). The interface should allow users to add new products into the stock, update existing products (e.g., the stock amount or price) and remove products from stock. The interface should provide useful overviews of these stock products (e.g., focusing on products that are almost no longer in stock), and allow to quickly order new products via a form in case some product is (almost) no longer in stock. This form needs as input: the product, quantity to buy, and supplier (the latter does not need to be modeled further). The second module is the sales module. This module is responsible for managing sales of products to customers, and can be used by both shop clerks and shop managers. It provides an interface where the user can enter a sale. For each sale, this interface allows entering the sold products (either manually via the product code, or automatically via a barcode scanner) and potentially the customer (either manually by searching for the customer, or automatically by scanning the customers card). Afterwards, the total amount to pay is displayed. This amount can be paid in two ways: either via cash, or charged to the customers account (see account module). If a cash amount was given, the user enters this amount in the interface, after which the interface displays the amount of cash to return. If the sale is charged to the customers account, the system displays the total amount left on that account. Depending on the customer account (see below), it is possible the product cannot be paid if the account balance is negative. In the underlying implementation, this module cooperates with the stock and account module (see next paragraph): for instance, it decreases the stock amount of a product after a sale, and decreases the amount of money on a customers account (this does not have to be modeled). The account module manages the registered customers of the shop, and is available to shop clerks and managers. Each customer has a name, address, birth date, telephone number and e-mail address. The modules interface allows adding new customers, updating existing ones, and removing customers. Sales can be charged to a customers account (see before), where relevant information (products, total price) is displayed for each sale. Each customer account has a balance. Customers can put money on the account, increasing the account balance (the interface should simply support increasing the account balance). Each time a sale is charged to the account, the price is subtracted from the total balance (possibly leading to a negative balance). This module should allow for useful overviews of the customer accounts (e.g., focusing on the negative accounts) and quickly updating an account balance when a customer wants to put money on his account. A customer search function should also be available (e.g., to search customers based on name and address). Account-specific settings should be possible, where for instance some customers are not allowed to have a negative balance on their account (e.g., because they have the tendency of not putting money on their account in a timely fashion). Finally, an overview module provides overviews of the combined information from the stock and sales modules, and is used only by the shop manager. The goal of these overviews is to help the shop to optimize their business. For instance, yearly sales overviews can be shown, where the total sale numbers per month are shown together with the most popular sold products. That way, stock management can be optimized. For instance, some products should not be put in stock in months where they are barely sold. As another example, in case some months have poor sale numbers compared to the others, this could mean certain seasonal products are missing (e.g., ice cream), or lead the shop manager to limit the opening hours of the shop to save on expenses. Hint: Your goal is to make the best possible interface in the world for this system!! Imagine yourself running a shop: what kind of support would you like in this interface? Note that this might require some extra functionality (e.g., to support the main requested functions mentioned above). In many

cases, there is a thin line between usability requirements and functional requirements. The main difference is that usability requirements exist to make the system more usable and easier to learn. Usability support can range from simple issues (e.g., allowing large lists to be ordered and/or searched) to more extensive issues (new features: e.g., allow stock updates via spreadsheets).

3.2.1 Assignment
Firstly, you should design, prototype and evaluate an interface for this system, following the phases discussed in section 2. Secondly, next to the evaluation of your own project (see section 2.3.3), you are asked to perform an extensive evaluation of the project of another group, using a summative evaluation method. You will have to hand in a report that carefully documents the entire evaluation process. This report should also motivate why you choose a certain method, and depending on the method, why you made certain choices (e.g. the usability requirements you chose to evaluate) as well as the result of the evaluation.

3.3 Requested Deliverables


Requirements Specification Report: 1. User classes 2. Usability requirements Analysis & Modeling Report: 3. User tasks: CTTs + explanations 4. User Object Model(s): (E)ER/ORM/UML diagram(s) + explanations 5. Style Guide Design Report: 6. Design & Prototype: give the design (including enabled task sets) and illustrate your prototype in the report. The final prototype should also be demonstrated on the project defence 7. Evaluations: employed techniques + description on how the evaluation has influenced the end result Evaluation Report: 8. Documentation on the evaluation of another project. Project defence: 9. The final prototype should be demonstrated, explained and questions about the reports can be asked. All group members need to be present.

3.4 Deadlines and Appointments


All deliverables should be handed in on paper at WISE (office 10F705) before 17h00 on the date given by the deadline (except for the evening students). A digital version should also be handed in using the dropbox feature on the PointCarr webpage of the course. Please note that all deadlines are hard deadlines. You will lose marks when you hand in too late. A box to deposit your paper report will be present. A date will be foreseen during the exam period to defend your project; subscriptions for a timeslot will be done through the PointCarr webpage. You will be informed in due time of the exact date, and how/when to subscribe. Group formation: Friday Oct 27, 2011(hard deadline)

Requirements, Analysis, Modeling, Design & Evaluation Report: one single report, containing the first three deliverables (deliverables 1-7), plus a digital version of your prototype: Dec 7, 2011 Evaluation Report (deliverable 8): Dec 23, 2011 Defence and demonstration: during the exam period (you will be informed in due time)

3.5 Contact
If you have questions or you would like to have an appointment for extra information, you should mail to userinterfacedesign@wise.vub.ac.be.

3.6 Evaluation
You will receive two marks: one for your own project and own for your evaluation of another groups user interface. For your own project, the evaluation will be distributed as follows: Reports: 60% Final Prototype & defense: 40% (the defence may also influence either positively or negatively your marks) Both projects should receive at least 9/20; otherwise you will receive the lowest mark.

3.7 Evaluation Criteria


Reports: completeness, correctness, quality of the resulting design, presentation style of the document Prototype: consistency with the design, USABILITY!, look & feel, completeness, robustness Evaluation: quality and thoroughness of the evaluation Defence: quality of the demo, quality of the answers to the questions

10

You might also like