Project for User Centered Systems Design Library Transaction Management for the Blind

Transcription

1 Project for User Centered Systems Design Library Transaction Management for the Blind Svenja Leifert Line Michelsen Samuli Ulmanen Martin Tägtström December 11, 2005

2 CONTENTS CONTENTS Contents 1 Introduction 3 2 User Profiles 5 3 Contextual Task Analysis 6 4 General Design Principles 7 5 Usability Goal Setting 8 6 Style Guide Development 9 7 Work Reengineering 10 8 Conceptual Model Design 11 9 Conceptual Model Mockups Iterative Conceptual Model Evaluation Screen Design Standards Screen Design Standards Prototyping Iterative Screen Design Standards Evaluation Detailed User Interface Design Iterative Detailed User Interface Design Evaluation Timeplan for the project User Feedback Reflections General aspects of the Usability Engineering Lifecycle Integration with software engineering processes Style Guides Our case: Blind users as a new user group The process according to usercentred sytems design A usercentred approach according to system developers

3 1 INTRODUCTION 1 Introduction The book The Usability Engineering Lifecycle by Deborah J. Mayhew is a book for interface designers, developers and others that practice usability. The lifecycle of usability engineering tasks are well defined in a well structured process of designing user interfaces. Both traditional software and websites are taken into concern in the book. The book teaches how to apply different requirements analysis techniques when designing user interfaces. Usability goals are also of high importance according to the author. Further, how workflow design and user interface design interacts is discussed and also the difference between them are explained. The reader of the usability engineering lifecycle will also learn to use requirements analysis data to design and validate workflow design and the book also teaches to structure a process for user interface design through requirements analysis data and usability goals. Further in the design process the objective usability evaluation techniques will be used for validation. Deborah J. Mayhew has chosen step-by-step procedures in each chapter for explaining all lifecycle tasks. She also explains the usability engineering lifecycle through examples and war stories from own experiences and previous work. The author, Deborah J. Mayhew, has a PhD degree from Tufts University. She also has an impressive professional career starting at the beginning of the 80s. Today she is the Owner and also works as principal consultant for DJMA, Deborah J. Mayhew & Associates. DJMA is an association for internationally recognized experts in software usability engineering. Talboks- och punktskriftsbiblioteket (TPB) is a bureau whose task is to equip people with handicaps with literature which is modified to their needs. This can be done by producing audiobooks of course litterature or digital versions of the books for special screens. TPB has decided to have end user groups have one of their own as a service person on the counter which creates special needs for the design of handling software. At the same time they are a small institution without resources for large projects, which is why only standard systems and ready solutions must be used. In order to create handling software to meet the needs of the blind, Mayhews The Usability Engineering Lifecycle will be used as a framework and fitted to a project where TPB is the customer who has ordered a system from usability experts which must meet the following needs: 1. Keep the use of resources to a minimum. 2. Make a system that is usable by the blind. The third goup involved are the usability experts, a team of three people. The Usability Engineer is experienced in the field of HCI and has researcher education. This role will lead the team of usability experts and manage interactions between the users of the system and all involved in developing 3

4 1 INTRODUCTION the system in such a way, that the usability of the system is maximized. The User Interface Designer should be motivated to serve the users interest and have recognized talent in the field. This role will be responsible for much of the way the user interface will look and function. The User Interface Developer is experienced in his own field. This role will be responsible for high-fidelity prototyping as well as realizing the user interface of the system. The usability experts are in need of developing work, which they will outsource to a developing firm whose main goal is to make profit. The usability experts goals are to manage this effort with the following goals in mind: 1. Meet the goals of the client. 2. Maximize the usability of the system. In order to meet these goals they will use the process defined in this paper which meets the following heuristics: 1. Keep user focus. 2. Active user involvement. 3. Evolutionary systems development. 4. Simple design representations supported by posters. 5. Prototype frequently and often. 6. Evaluate use of the system at the TPB. 7. Keep process explicit and concious when coming to design. 8. Promote a professional attitude in the process 9. The Usability Engineer will be a usability champion. 10. Make sure that all aspects of usability are developed in parallel. 11. Make sure that the development process meets the needs of the library. 12. Establish a user centered attitude. These are based on design guidelines described by Gulliksen & Goransson in Anvandarcentrerad systemdesign [2]. 4

5 2 USER PROFILES 2 User Profiles Purpose The purpose of develping a user profile is to determine the users of the system, their characteristics and divide them into groups of users according to these characteristics. These characteristics include psychological-, knowledge-,experience-, job-, task- and physical characteristics. Method 1. Determine user categories 2. Determine relevant user characteristics 3. Develop a draft questionnaire 4. Get library feedback on the draft 5. Revise the questionnaire 6. Select a user sample 7. Distribute questionnaires 8. Design data entry/analysis 9. Enter data 10. Summarize data 11. Interpret data 12. Present results Task Organization This task produces user profiles. There is one user profile per user group and the characteristics of the group are based on data from questionnaires which the target users have done. The user interface designer should take the lead role in this task and the usability engineer can provide which characteristics to pursue with the users and to draw conclusions from the questionnaires. Discussion Pros and cons User profiles offer actual user groups with characteristics supported by actual data. Design decisions will need to be based on them. Software developers will also make decisions which have effects on the usability of the system. User profiles have solid data with which to ratify decisions but do they help the developers to see the system from the users perspective? 5

6 3 CONTEXTUAL TASK ANALYSIS Figure 1: Usability engineering lifecycle Main modifications To adress the problem mentioned above, it is suggested that based on the user profiles, personas should be created to promote user centered thinking amongst the developers of the system. This will add an estimated twenty hours to the workload of this task. 3 Contextual Task Analysis Purpose The purpose of the process is to attain a user-centred model of the work as it is currently performed. That is to get an understanding of how the user works, and why different parts of the work is performed. For our case it is important to understand the way the work are performed at the present moment, to be able to eventually fit it for the new user group. Method The contextual task analysis is performed in the users actual work environment. The method can be described with the following steps: 1. Plan the contextual interview/observation thorough. Use literature e.g. Contextual Analysis by Holtzblatt and Beyer and background information about the existing system. 2. Perform the contextual interview/observation out in the work environment over 3 days to ensure that a great number of different work situations will be represented and experienced by the usability engineer. 6

7 4 GENERAL DESIGN PRINCIPLES 3. Document the interviews and observation. Write notes and comments continuously under the interview/observation so you do not forget important information. If possible write some reflections after you have left the work environment. 4. Construct task scenarios for each user group. If possible do this together with the users to make user goals clearer. 5. Identify the different user tasks in a meeting with the users. 6. Involve the users in this step and get their view of how the users organize their work tasks. 7. Document the entire user tasks in one User Task Organization Model. This can be done hierarchically to get an overview of which tasks are a precondition to other tasks. Task Organization Input is knowledge from the user profiles about the identified user groups. Together with the user profiles, the task organization model is to be used for the usability goal setting. The resources needed for performing a contextual task analysis is a usability engineer that is to perform the interviews and the observations of the users while they work. The time expenditure is estimated to be 1/3 less than the estimated hours, as it is our assessment that we can use less hours on most of the involved activities as it is a rather limited concern. Time needed: 200 hours. Discussion Main modifications The main modifications of the process we have chosen to do are: None. Pros and cons The strength of the method is that you involve the users in almost all of the steps, and get the users opinion of the way you have modelled the user s work. The weakness is that it might be a heavy documentation involved in the process. 4 General Design Principles Purpose The purpose is to identify and review general user interface design principles and applicable guidelines for the design. This will be useful 7

8 5 USABILITY GOAL SETTING later on in the usability engineering lifecycle in the part that has to do with design, testing and development. Method In the procedure much effort has to be put in studies about general design principles through books and style guides. These books and style guides have to be seen as inputs to this process. How long this process takes is very much depending on the accessibility of material and earlier gained experience from user interface designing. 5 Usability Goal Setting Purpose The purpose of this process is to give the designer something concrete to aim against when creating the user interface design. And with these clear usability goals this process guarantees that every decision in the user interface design has a purpose. Also the usability goals shorten the design cycle. Another purpose of this process is to serve as acceptance criteria during usability evaluation. Method When setting the usability goals the process refers to the user profile and the contextual task analysis. After that the usability goals will be formulated and prioritized for a review from the users. Task Organization In the Usability goal setting process the User profile and the contextual task analysis work as inputs. The process will result in qualitative and quantitative usability goals. When communicating with the users some more time has to be added since it will be harder when working with blind users. Discussion Main modifications The main modifications of the process we have chosen to do are: To take into account that there are different user groups, that each have different usability goals. Pros and cons This process is relevant since it defines the usability goals but it might be a constraint that the users not are involved when setting the quantitative goals. 8

9 6 STYLE GUIDE DEVELOPMENT 6 Style Guide Development Purpose The Style Guide Development brings all results into one document which can be used as a tool (i.e. the Product Style Guide, which developers use to build the system) later in the Usability Engineering Lifecycle or afterwards. Method The Style Guide is divided into different parts which are written after certain important steps of the Usability Engineering Lifecycle. 1. Document work products from all Requirements Analysis tasks (including User Profiles, Contextual Task Analysis, Platform Capabilities and Usability Goals). 2. Document the validated Conceptual Model Design (including the Reengineered Work Models and the Conceptual Model). 3. Document the validated Screen Design Standards. 4. Communicate the Style Guide. 5. Enforce the Style Guide: Use management support to make people use the Style Guide. Task Organization The outcome is the communication of the results of all steps to every member in the project team. Obviously, it is not necessary to involve the users in this process, although it could be useful to communicate the results of tests and profiles to them to provide a stronger interest in the development of the system. The User Interface Designer should be responsible for this task, helped by the Usability Engineer and eventually other team members, especially those that worked with the Requirement Analysis. The time table given in the book (all in all 256 hours, devided into different levels of the writings) does not need to be adjusted for our purpose. Discussion Pros and cons The main strength of the Style Guide is that it puts all the information of the entire process together. You can always refer to it as a basis for upcoming processes. However, this implies the risk of relying too much on it without own reflections. Furthermore it is very difficult to make everyone use a document which is as complex and extensive as the Style Guide. 9

10 7 WORK REENGINEERING 7 Work Reengineering Purpose The purpose of work reengineering is to remodel current work to take advantage of automation that computers make possible, to better meet the goals of the institution, using the existing knowledge and experience in the institution to do so. Method To let the users paticipate in reorganzation the work tasks is highly recommended at this time of the process as it helps the designers to understand the users needs. 1. Reengineer the Current User Task Organisation Model and Task Scenarios: Analyse current task organisation in terms of underlying goals. 2. Validate and refine the Reengineered Task Organisation Model and Reengineered Tast Sequence Models: Make index cards with grougs, subgroups of users and low-level tasks (adjustment: cards in Braille). Let users group them. Capture most common expectations across users. 3. Document the Reengineered Task Organisation Model and Reengineered Task Sequence Models. Task Organization As an input we need the User Profiles and Task Analysis in form of Usability Goals. Those form the Task Models and Work Task Models. As a result we get a Reengineered Task Organisation Model which is documented in the Style Guide and will serve as a foundation for the Conceptual Model Design and Detailed User Interface Design. The main role should be taken by the User Interface Designer. He should work with any and all members of the project team that participated in the User Profile and Contextual Task Analysis section. The Usability Engineer should also be involved, as well as the users (which participate in the validation anyway) might participate. The process needs about 110 hours of Usability Time and 22 hours User Time (a little more than proposed in the book, adjusted in terms of aditional work to prepare materials for blind users). Discussion Pros and cons This method is very good for getting the users view on his own work and understanding how he sees the organisation of tasks. On the other hand, people have different ways of achieving goals and the sorting of the users might be too complex, so that one looses the overview of the tasks. 10

11 8 CONCEPTUAL MODEL DESIGN Main modifications In the Work Reengineering process, the index cards with the groups and subgroups of users, as well as the low-level tasks need to be written in Braille, so that the blind users can sort them on their own. 8 Conceptual Model Design Purpose The purpose of Conceptual Model Design is to...define a coherent, rule based framework that will provide a unifying foundation for all the detailed interface design [?]. This step defines the interaction and visual style of the application as well as an organization of the reengineered tasks from the previous step. Method Conceptual Model Design is the first step into actual UI-design and among other things chooses the platform to which the system is developed to. 1. Define either a product or process oriented Conceptual Model 2. Clearly identify processes 3. Design presentation rules for processes 4. Desing rules for windows 5. Identify major displays 6. Define and design major navigational pathways 7. Document alternative Conceptual Model Designs in sketches and explanatory notes Task Organization This task relies on data from the Reengineered Task Model and Reengineered Task Scenarios as well as Platform Capabilities and Constraints, documents produced earlier in the process. This step produces the Conceptual Model Design. As this step involves designing interaction and visual styles of the application, it is appropriate that the user interface designer takes the lead role in this task. Any in the project team who have taken part in the creation of User Profiles, Contextual Task Analysis and Work reengineering tasks should provide feedback on the UI-designers work. He should also receive input from the Usability Engineer of the team. This task will is estimated to take 200 working hours. 11

12 9 CONCEPTUAL MODEL MOCKUPS Discussion Pros and cons This step maintains focus on the user and their context, which is a strength. This step also brings together a wide range of aspects affecting the usability of the system. Here a detailed description of the work context and users (The Reengineered Task- and Organizational Models) is considered together with the platform (Platform Constraints and Capabilities) to which the application is being developed. This also opens a window to compare different software platforms from both a technological and usability viewpoint. A key weakness in this step is that it does not, by default, involve users. The needs of the users are technically included earlier in the Usability Engineering Lifecycle. Is it thus unnecessary to do so now? Maybe users should, if possible, choose which conceptual models to make mock-ups of or at least be given a chance to give feedback on all conceptual models produced. This would both contribute to involvement of users as well as in supporting a user centered attitude within the developing parties. Another weakness is that the software developers are not involved in this step. It is one thing to design in a usercentered way than to have that design developed. Is the consideration of of platform Capabilities and Constraits enough to both involve the developers in usability design and contribute to a usability-friendly attitude? Having at least someone in the development team give feedback on the CM s produced or better yet, have them produce one themselves, would be a good way to involve the development team at an early point. Main Modifications After several concept models have been developed, the user groups defined in User Profiles and the developers of the system should be given a chance to give input on all the concept models. Short description on what they like and what they dislike with modification requests. This will add twenty hours to the task but will help the usability experts choose, which designs to develop further into mockups. 9 Conceptual Model Mockups Purpose Here, different designs for interaction-,visual style, and functionality grouping are prototyped. This will facilitate the involvement of users to design in a very early stage. Prototypes will only include the general frame of functionality. The purpose of this task is to support the evaluation and choosing of the Conceptual Model by the use of prototyping. This also facilitates user testing of the Conceptual Model. 12

13 9 CONCEPTUAL MODEL MOCKUPS Method The method of this task merely consists of choosing how to produce prototype and then carrying it out. Generally this means either lo-fi mock-ups or hi-fi programmed prototypes. Lo-fi mock-ups serve their purpose just as well as a hi-fi mock-ups at this stage of the lifecycle. Using hi-fi mock-ups, if developed by the actual developers, could be used to expose developers to a usercentered way of thinking. 1. Select the functionality 2. Sketch the user interface design 3. Build the mock-ups Task Organization This task is based on the various Conceptual Models from the previous task in the Usability Engineering Lifecycle. Several mock-ups or low functionality prototypes are produced. The User Interface Designer takes responsibility over this activity. All other members of the team should provide feedback. This task will take an estimated 80 working hours to complete. Discussion Pros and cons The strength of this task as a part of the whole lifecycle is it s early placement. Prototyping early in the process saves on costs later as the most obvious and harmful flaws of the Conceptual Model are found early. It s strength as a step lies in avoiding the my baby -syndrome where one concentrates rather fanatically on one design. Here, several prototypes are produced to avoid this. It s weakness lies within this aspect as it could be time consuming and costly to consider many ideas. Another weakness is that, one cannot tell how many conceptual models one needs to consider. Main modifications To keep the number of Conceptual Models from exploding, they should be concentrated only to the current platform of the library. The number of CM s to consider should be kept to three. 13

14 10 ITERATIVE CONCEPTUAL MODEL EVALUATION 10 Iterative Conceptual Model Evaluation Purpose This task will iteratively remove the major flaws in the style of interaction and the visual style as well as organization of functionality of the application. It will also select the most suitable concept to which the user interface design will be based. The purpose of this process is to provide quick and early feedback on the Conceptual Model and correct the major flaws in it. This step will also single out and optimize the Conceptual Model to take to the next stage of User Interface Design. Method The method used to iteratively evaluate the Conceptual Model can be chosen at will. However, formal usability testing is the preferred method, because the results from Contextual Task Analysis and User Profiles can be used to develop the test for the users. 1. Decide on ease of learning/ease fo use focus for the test 2. Decide on user and task focus for the test 3. Design test tasks 4. Design the test and develop test materials 5. Design and assemble the test environment 6. Recruit/schedule pilot test users 7. Run pilot test 8. Revise test procedures and materials 9. Recruit/schedule test users 1. Run the test and collect data 2. Summarize data 3. Analyze data 4. Draw conclusions/formulate recommended design changes 5. Document/present result 14

15 11 SCREEN DESIGN STANDARDS Task Orgnization This task relies on several Conceptual Model Designs and Conceptual Mock-ups for material. The user testing in the task can be conducted in many ways, but if formal user testing is used, User Profiles and Contextual Task Model may be used to prepare the test. This activity produces a single and optimized Conceptual Model on which the user interface desing will be based. However, this model is left open as some flaws could be found later on in the process. The Usability Engineer will lead this task as the most crucial aspect lies in end user testing. The User Interface Designer will act as secretary and will help design the test. It is crucial to involve the development team and the library team in this step as it will promote a usercentered way of thinking. This task will take an estimated 150 hours to complete. Discussion Pros and cons As a part of the whole lifecycle, this task introduces user evaluation at a fairly early stage eliminating major problems early on in the process. A strength of this task as a part of a user centered design process is that it is iterative in nature, and attempts to involve all involved personell in the project in a cross diciplinary effort. However, it is not specified how to involve the developers and the staff of the client. Perhaps this would hinder the adaptability of the method but suggestions would have been appropriate. Another strength is that the user testing method can be chosen at will but it should be kept in mind that the method should use the User Profiles and Contextual Task Analysis to construct the user tests. Main modifications This test should be performed in the same locale as the work that the finished system is used to support. 11 Screen Design Standards Purpose The purpose of the screen design standards is to ensure consistency and simplicity in detailed design across all displays within a product interface. Method This is a task where you define the standards of the screen and the interaction with the design. Here it is relevant to use existing standards for designing user interfaces for the blind. In the following are the main categories of the screen design standards listed: 1. Control standards: Use of checkboxes, combo boxes, push buttons etc. for input control by the user. 15

16 12 SCREEN DESIGN STANDARDS PROTOTYPING 2. Product window standards: Standards for layout and design of screens. 3. Dialog contents standards: Use of checkboxes, combo boxes, push buttons etc. 4. Message box content standards: Used for indicating different types of messages like error messages, status etc. 5. Input device standards: Identification of all relevant input devices. Here, the competences of the accessibility designer are relevant. 6. Feedback standards: Both visual standards and tactile or audio feedback standards will be relevant. Task Organization The screen design standards needs the following input: User profiles, contextual task analysis work organisation models, usability goals, the platform capabilities, and the style guide. The output of this task are: Documents containing different standards for screen design. The major roles in this task is taken by: User interface designer, usability engineer, and the accessibility designer is also needed to supervise the user interface designer about standards for user interfaces for blind people, and help them take appropriate decisions. The time expenditure of this process should be around: 180 hours as stated in the book, but +20 hours due to involving the accessibility designer. 12 Screen Design Standards Prototyping Purpose The screen design standards prototyping should support the evaluation, make us able to evaluate the high level user interface design, and evaluate the conceptual model. Method You could choose to either make a paper prototype, or to make a functional prototype. In the following is a short summary of which steps to go through: 1. Select the functionality to be prototyped - this should be done together with the users to know what the most relevant functionalities are. 2. Prepare a paper prototype. 3. Build the prototype. 16

17 13 ITERATIVE SCREEN DESIGN STANDARDS EVALUATION Task Organization Input that are needed for the process are: Use the screen design standards. The outcome is: A prototype of some sort. The existing library personnel should be involved to help to choose the relevant functionality for the prototype. The user interface designer should be involved as well. Time as stated in the book; 152, + 50 hours due to use of screed reader or translation to Braille. 13 Iterative Screen Design Standards Evaluation Purpose The purpose of the process is to get quick and early feedback from the users on the screen design standards. Method See the section about the evaluation of the conceptual model. Task Organization The prototype is needed to perform the evaluation. Products of the activity are: Screen design standards to go in the style guide. Usability engineer, users that tests (end users) and pilot testers (present users) should be involved in the evaluation phase. Accessibility designer should add experience and knowledge. Time expenditure as stated in the book, maybe a little more time should be needed due to making a prototype that are tested by the end users which are blind. Time needed: 160 hours. Furthermore more time would be needed if the instructions for the blind test users should be in Braille but that could be solved by reading the instructions loud for the users. Discussion Pros and cons The pros of this part of the method are that the users are involved in the evaluation. Both test users and end users are involved, which can be two different groups of users, but it can also be from the same user group. We chose to involve the present users as pilot testers and the new group of users in the prototype testing, as the new group of users is very different from the present users in the way they interact with the system. The evaluation will further help preventing inconstancy of the user interface design, and the look and feel of the system is tested and optimized. Furthermore the process is iterative and is coherent with user centred design, and takes the user environment into account. The cons of the process that can be mentioned are: It is a heavy process for a project that takes a long time and might risk to be excluded. 17

18 14 DETAILED USER INTERFACE DESIGN Main modifications The main modifications of the process we have chosen to do are: To involve the accessibility designer in the process as well, as he will be able to add experience and knowledge about standards for users interfaces for blind people. 14 Detailed User Interface Design Purpose The Detailed User Interface Design is in general what all the other tasks in the process are aimed at, as well as to define and sometimes document the design based on the Central Model Design and the Screen Design Standards. Method The method is mainly a completation of the User Interface Design. 1. Complete the identification of all pathways between windows, dialog boxes and message boxes. 2. Complete the design of menu bar and/or all other action controls. 3. Complete the design of content of all windows, dialog boxes and message boxes. 4. Complete the design of all interactions with input devices. Task Organization The Input for the Detailed User Interface Design are the Conceptual Model Design and the Screen Design Standards communicated by the Style Guide. The outcome of this process is a completely functional prototype to be evaluated. If the developers are unexperienced with designing and developing directly from a product Style Guide, the User Interface Designer should take the main role. If not, the developers can design and produce the code directly from the product Style Guide, working closely together with the User Interface Designer. He should serve as a consultant. The Usability Engineer can also provide input. The time needed for the Detailed User Interface Design of about 240 hours given in the book needs not to be changed except for 20 additional hours for consulting the accessibility designer. 18

19 15 ITERATIVE DETAILED USER INTERFACE DESIGN EVALUATION Discussion Pros and cons An advantage of doing a detailed user interface design, is that you will have the advantage of getting a response to how the final product will be, and you will be able to iteratively evaluate the detailed design with the users. Furthermore you will be able to design a detailed user interface as you imagine it in a final version of the product. Main Modifications The accessibility designer should be consulted to guarantee and improve the accessibility for blind users. 15 Iterative Detailed User Interface Design Evaluation Purpose The final interface is evaluated against usability goals by evaluating both design and functionality. A short description of the method The evaluation of the Detailed User Interface Design works just as the evaluation of the Conceptual Model Design. Task Organization The Iterative Detailed User Interface Design Evaluation works with the results of the Detailed User Interface Design process. Products of the activity The outcome of the evaluation is a completely functional prototype. If it does not meet the Usability Goals, this process has to be repeated until it does. It is then documented in the Style Guide which is used by the developers to build the final system. Involved roles The Usability Engineer leads the evaluation, where the User Interface Designer is only needed as an assistant. Users will of course take part as evaluators, as well as project team members serving as assistants, when needed. The evaluation is said to take about 144 hours, where we have to add 40 hours for adjusting the test tasks to the needs of the blind test users. Discussion Pros and cons An advantage of doing a detailed user interface design, is that you involve the users from the very conceptual model design to the very specific design where you will have the users evaluate a user interface as it will be at the end product. 19

20 17 USER FEEDBACK Figure 2: Gantt chart 1. Main Modificatons The test tasks have to be communicated to the blind test users in another way than to seeing ones. Either does it have to be printed in Braille or read out loud. 16 Timeplan for the project A Gantt chart illustrating the time needed for the different work tasks can be seen in Figure 2 and User Feedback Purpose In order to evaluate the success of the finished product, to evaluate ones own organization and to prepare for future projects, user feedback is vital. The purpose of this process is to provide post-installation feedback from the users on the finished system. 20

21 17 USER FEEDBACK Figure 3: Gantt chart 2. 21

22 17 USER FEEDBACK Method The feedback is collected with a questionnaire which is distributed to users within the organization. 1. Develop draft questionnaire 2. Pilot/revise questionnaire 3. Distribute questionnaiire 4. Analyze data 5. Draw and document conclusions Task organization User feedback will be extracted via questionnaire possibly. Recomendations for improving the current product and suggestions for redesigning a future release. The Usability Engineer is responsible for this task. The User Interface Designer plans and executes the user feedback techniques. Discussion Pros and Cons User feedback is essential in keeping up to pace on ones teams weaknesses and strengths as the finished product will now be evaluated on final time as the tool that it was designed to be, or nearly that which it was designed to be. The strength of this step is that it is user centered in nature. However if the possible problems that are found in the user feedback, cannot be addressed quickly and efficiently, the usability expert team has ran away with knowledge which to use in their next project and the user gets nothing. The framework of this project, The Usability Engineering Lifecycle, addresses this only within the usability team. The developers are a part of a fast responce as well and are forgotten out of the picture. Main Modifications In order to address the mentioned problem, the developers, must be kept up to date on the usability issues at hand. This is possible if they know the framework, and have posters and handouts available to give to the developers on request. Also, the developers could be involved in the Iterative Detailed User Interface Design evaluation, so if a usability problem arises during feedback, it can be addressed by the development team with speed and fury. 22

23 18 REFLECTIONS 18 Reflections This section contains some reflections on the Usability Engineering Lifecycle. There will be a discussion of different aspects that we find interessting General aspects of the Usability Engineering Lifecycle A good ability of the Usability Engineering Lifecycle is, that is a very detailed and specified process, and Mayhew proposes very concrete tools for how to do each step of the analysis. The book is further very easy to get an overview over, even though it is a large book with a lot of pages. It proposes a step-by-step procedure for how to do perform the process, and is thereby a usable procedure for how to use the process. By using Mayhews Usability Engineering Lifecycle you will assure that the system development process will put the usablity and the users in focus. [2] 18.2 Integration with software engineering processes What might be seen as a weakness of the Usability Engineering Lifecycle is that it is only a process for designing a user interface, and not a complete system design method for how to do a user centred system development. But the author compensates for that, by arguing through the whole Usability Engineering Lifecycle that (and how) the process fits into e.g. the object oriented software engineering process, which might be seen as a strength of the Usability Engineering Lifecycle. Furthermore the author argues that the Usability Engineering Lifecycle also fits into other software development processes e.g. RUP [2]. [?] 18.3 Style Guides Mayhew proposes that styleguides should be used for documentation, and communication of the design decisions to the developers. A question that could be asked is if these style guides are enough documentation, or if it is too simple to make the developers feel involved in a user centred process? 18.4 Our case: Blind users as a new user group When designing for a new group of users, especially when the users are blid, and therefore have another way of approaching the user interface and another way of interacting with the system. One difference in the interaction of the blind users and the system, are the input and output devices - purely technology. But for this comes the challenges of making the users use the system with these technologies. We therefore find it relevant to involve the 23

24 18.5 The process according to usercentred sytems design REFERENCES accessibility designer in as many parts of the process as possible, to be able to use his/hers experiences The process according to usercentred sytems design We discussed the Usability Engineering Lifecycle according to the user centred systems design principles as they are defined in citek1. So we asked our selfes do the Usability Engineering Lifecycle have: User focus, active user involvement, crossdisciplinary teams, a user centred attitude, early prototyping etc. These questions were based on the 12 usability key principles as stated in [2]. We found that all 12 key principles were more or less fulfilled A usercentred approach according to system developers The Usability engineering Lifecycle might be perceived as a heavy and time consuming process to system developers. And it might be a challenge to make the actual system developers to understand the importance of designing user centred, and to involve the users in the whole system development process. References [1] Jan Gulliksen, Bengt Göransson, Anvandarcentrerad systemdesign, 2003, Studentlitteratur, ISBN: [2] Deborah J. Mayhew, The Usability Engineering Lifecycle, 1999, Academic Press, ISBN: