PlaisantEtAl97

PublicReengineering Wiki

These authors report on their experiences of reengineering the UIs of six application. They argue that there are significant benefits to be gained by relatively small changes to existing interfaces which can be achieved in a few weeks. Benefits include improved user performance and satisfaction, whilst shortening learning times and reducing error rates. They argue that following their diagnostic strategy allows the identification of areas where substantial improvement can be achieved by minor interface reengineering. There strategies and findings were: Compile and review all the available documentation to learn about the system. Documentation may even be the object of the reengineering. They found having a compressive user manual and a quick reference guide allowed users to perform their tasks more competently. On-line help, mini-tutorials and FAQs make it easier for them to complete tasks; Attend formal training sessions to further learn about the system; Have discussions with managers to identify goals, commitment and available resources; Have discussions with designers to find out about the system constraints and alternatives. If these designers are to be the people who carry out the actual reengineering, then it is important to build a relationship with them and assess their capabilities; Discussions with users - what are their frustrations and expectations?; Observe users - how do they perform their routine tasks? Experts and novices will perform task in different ways. Specific bottlenecks and response times can be identified and the working conditions can be noted. This observation can even be extended to usability trails in the laboratory using representative tasks; Expert review - use the system yourself to gain first hand and in-depth knowledge about the system and the work flows. This approach generated the greatest number of suggestions for short-term improvements; Questionnaires - they used their own QUIS (Questionnaire for User Interaction Satisfaction) developed in the HCI lab at Maryland. They claim this questionnaire is widely used in industry and academia. It evaluates 71 interface features and help to identify problems as perceived by users. It can be given to a larger population, it provides anonymity, facilitates benchmarking against similar sysystems. To measure the benefits of reengineering it can be re-administered afterwards. The authors' role in reengineering was only to make recommendations, not to carry them out. They claim this helped staff maintain a sense of ownership. They recommend a phased implementation. Specific problems related to documentation, system access (eg locked doors or even length login procedures), data display, data entry, consistency, system/error messages and additional functions. For system access they found they could make user' life easier by bringing distant equipment closer, opening up frequently locked rooms, repairing damaged equipment, increasing system speed and reliability and simplifying access procedures. Using colour, sorting and grouping of fields, highlighting, mixing upper & lower cases, bolding and removing obsolete information and obscure codes can help data display. Improved data entry can reduce error and speed up performance. To achieve this they removed instances where data was being entered twice, displaying default values, limiting cursor movement to editable fields, touch screens, more visible cursors and consistent key sequences. Consistency was a problem which could be addressed by considering common action sequences, terms, units, layouts, abbreviations, spelling, capitalisation and colour. the result for users is faster learning, higher productivity, lower error rates and better retention. Error and system messages can improved by making them more specific and providing constructive guidance. Adopt a positive tone and avoid unnecessary info, eg error code. Again, consistency with these messages helps, eg format and placement. Discussions with users and feedback from questionnaires identified additional functionality, eg graphical representations and information visualisation to better present a given screen. They recommend providing a schedule and a statement of the effort involved, as well as ranking recommendations in terms of payback. The recognise that reengineering is complex and risky and has the potential to disrupt users. They warn that such narrowly focused reengineering may be inappropriate when more major problems lie outside the UI. Seems they've missed the opportunity to use the web as a target interface (see tilley & smith) - but perhaps that doesn't offer such a quick fix and would require more substantial reengineering.

• Start Here in this Web
• Categories
• Index
• Recent Changes
• FAQ