Design guidance for CWEs

From EuroVR Knowledge Base

One of the objectives of the CoSpaces project is to develop design guidance applicable to collaborative working environments (CWEs). This guidance should highlight the main usability concerns that could potentially manifest themselves in collaborative technologies. It is presented here, on the INTUITION knowledge base for comment and (potentially) further development.

Below we present our design guidance for CWEs. The guidance covers the range of usability issues that may afflict collaborative technology. A sound understanding of the issues covered here should enable designers to building systems with common, or avoidable, usability problems. The guidance is written so as to be flexible, and does not seek to prescribe solutions or limit design freedom.

Contents

ACCESSIBILITY

The concepts of usability and accessibility have significant similarities (e.g. Chandrashekar and Benedyk, 2006). Making accessible systems means that they will usable by the broadest possible segment of society. Naturally, CoSpaces should adhere to relevant accessibility standards and guidelines. For example:

GENERAL PRINCIPLES

In this first section, we present guidance based on general and established principles but tailored to CWE development.

Follow a human-centred or, better still, socially-centred design process

  • It is vital to understand the nature of the users and teams who are to use a CWE. Employ established techniques of user-centred design to fully comprehend the tasks, processes, interactions and team dynamics that will be supported. Begin with observations and interviews, identifying critical factors, and establish a relationship with users.
  • Involve users throughout development.
  • Take care to consider the intended setting for the system. What is the working environment like? Assess the levels of ambient light and noise, and determine how this might affect collaboration and the choice of devices.
  • Determine the size of data to be shared between users, ensure the system will be able to handle large volumes of data plus audio and video communication.
  • Be aware of the differences between designing single-user systems and groupware. Be conscious of the social and organisational factors that influence teamwork, and how these might affect the acceptance of collaborative technology. Move from a philosophy of human-centred design to socially-centred design.
  • Be cautious of generalising findings from a specific group when designing for a wider pool of users. If possible, study several examples of the target user group.

Design for acceptance/mass-adoption

  • Collaborative systems rely on establishing a critical-mass of users. As this builds the system will become essential in task-work and will be adopted widely, even by re-luctant users. Critical mass relies on the nature of the tasks and the time taken to perform them, and cannot be specified generally.
  • Establishing critical-mass relies on a system that offers individual users some per-ceived benefit, i.e. it improves their working life. Benefits to groupwork are part of this, but they must not come at significant cost to individuals. Poor usability of the system, for single-users and for groups, will likely result in failure.
  • Users will have grown accustomed to their existing tools, and become expert in their use. Even if the new system improves on these, it will likely be met with some resis-tance. Ensure the system is interoperable with previously existing tools. Aim to fully integrate with groupware functions to create a cross-media landscape of indi-vidual and group tools.

Make systems safe to use

  • Ensure your system complies with applicable standards of health and safety.
  • Special care should be taken for mobile workers, who may be required to attend to other real-world, safety-critical tasks at the same time as using the system. Tasks and interfaces should be structured so as not to put the user under any risk or added stress. Interfaces on mobile devices should provide rich audio feedback, require minimal physical interaction and reduce reliance on visual attention.
  • Wearable computers must be designed so as to not impact on the musculoskeletal health of the user.
  • Some users may experience feelings of nausea and sickness when using virtual real-ity (VR). Even if these are at a low-level, it is unacceptable to require sufferers to use VR. Ensure that the system provides alternative means of interaction for those that suffer with these systems.

Strive for simplicity

  • Interfaces should be designed following aesthetic principles and a minimalist ap-proach – Keep It Simple Stupid (KISS).
  • Employ good visual design so that users are able to navigate an interface effectively.
  • Good design should focus on making functionality obvious. Make functionality the focus of design. The precise functionality of the system should be established through a sound understanding of the intended users and the tasks they engage in.
  • As much as is possible, make the technology invisible to the users. For collaborative systems especially, interaction should be naturalistic and effortless. However, en-sure that users are supported in developing accurate mental models of how the sys-tem behaves, especially when handling their data. Failure to do so may lead to a lack of trust in the system.

Make systems that are flexible and versatile

  • The system should be easy for novices to use and learn. Collaborative systems might be used infrequently, most likely on an ad-hoc basis. Do not rely on users be-coming experts through daily exposure. Design to anticipate irregular use by users with varying levels of expertise.
  • However, design should also consider supporting expert users. Include shortcuts and accelerators that may improve interaction for experienced users.
  • Where systems offer multiple layers of information, users should be easily able to access more detailed content
  • Employ a variety of interaction styles. Systems might be employed on an array of different hardware. Establish what these are in requirements gathering activities and design the system accordingly.

Do not overload the user

  • Develop interfaces based on recognition, rather than the users’ recall. Users should not have to remember the meaning of particular states, or changes. System states and the transitions between them should be easily perceived.
  • Try not to rely on the short-term memory of the user. Although in collaborative situations, users may be able to share responsibility for remembering this will mean added coordination effort and detracts from task performance.
  • Learn from the design of ambient interfaces. Design system elements so that they inform the user without requiring significant focus. Information should be provided on the periphery of the user’s attention, unobtrusive but easily accessible. For ex-ample, consider the use of good icon design in Instant Messaging tools to indicate a user’s status.
  • Ensure the system is compatible with the work-flow.
  • Avoid spamming users with irrelevant, unnecessary, unsolicited or unwanted com-munication. Enable users to determine their own availability and select how they wish to be alerted to new events and communications.

Design the system to avoid errors, and to handle those that do occur effectively

  • Avoiding errors is of even higher priority for collaborative systems than single-user systems. Users need to be confident their data is safe and secure. Whilst collaborat-ing in real-time, dealing with errors may be awkward and disruptive to task per-formance.
  • Make sure the system is robust.
  • Ensure that errors can be recovered from easily. If errors occur during real-time collaboration, this should not result in data loss or session breakdown unless abso-lutely unavoidable. Ensure data is backed-up frequently.
  • Provide appropriate help and documentation. Make this searchable, task-focussed, procedural and concise. Design the system so that help documentation is a secon-dary, rather than primary, resource. In real-time collaboration users will not wish to spend valuable time consulting help files.

Strive for consistency

  • Follow appropriate platform and software conventions.
  • Use consistent terminology throughout.
  • Ensure that the look and feel of the system is consistent across all aspects of use. Make interfaces recognisable. Do not use different icons to represent the same func-tion.
  • Design the systems to be interoperable with other applications. Collaborative tools will often be used in conjunction with other software. Identify what these are, and ensure compatibility.
  • Make sure the system is accessible to all users, according to established standards where possible.

Place users in control

  • Users need to be free to explore the system and should be able to do so without fear of irreversible error. Support undo and redo functionality. If users enter into a state by error, they should be able to exit this easily without having to negotiate compli-cated dialogue procedures
  • Make actions predictable and visible.
  • If total user freedom is impossible, constrain the user through good design.

Make the system intuitive to use, established on real-world knowledge and expectations

  • Enable users to interact with the system by direct manipulation as much as possible. Performing actions should correspond to real-world conventions.
  • Take advantage of users’ knowledge and design the system to be familiar to the us-ers. However, take care to consider professional and national cultural differences be-tween users when making such assumptions. Identify any discrepancies between representations and expectations through user trials in the early stages of interface design. These do not require high-fidelity prototypes. Use story-boards and inter-face mock-ups combined with focus groups or interviews instead.
  • Make interaction elements obvious to the user.
  • Comply with existing standards for interaction, unless better solutions have been de-veloped through user-centred design.

Provide the user with useful feedback

  • Users should be able to determine system status with minimal effort.
  • Make the system responsive to user behaviour - users should always be able to see how their behaviour is changing elements within the system.
  • For collaborative systems, feedback extends beyond the user and the system. Users need to be aware of the activity of other users, where they are, their availability, what changes they have made/are making, what they can see, and so on.

COLLABORATION PRINCIPLES

This guidance is focussed more specifically on the core-elements of collaboration – communication, coordination and awareness – that CWEs need to support. It should be noted that there is considerable overlap between these three aspects, and all are equally important for CWE development.

Communication

Enable users to communicate with each other, through speech and text

  • Users of collaborative systems will need to communicate directly with other users. Include multiple communication channels. Allow users to talk and write to each other.
  • Consider the likely size of conversations, i.e. how many users will be involved, since this can cause usability problems. Ensure there is a high bandwidth to support con-versations with many users, design for a minimum of three or four users.
  • Assist users in identifying who is speaking, for example by highlighting the speaker’s avatar/icon/picture. Ensure that audio connections are free of echo or feedback.
  • Try and support indirect communication, e.g. conversations overheard between other users. Take care to avoid the danger of unwarranted eavesdropping. Perhaps design the system with ‘public’ areas, where all approved users may enter and interact with those in the space. ‘Private’ or restricted access areas should be available for more sensitive discussions. Consider also how users can communicate their thoughts with the wider group as they conduct individual work, in the way that a person might pro-vide a running commentary as they negotiate a difficult task.
  • Communication should be quick and easy to establish. One option might be to pro-vide persistent audio/visual links. Alternatively, ensure connection is effortlessly es-tablished. Choose real-world analogies, e.g. glancing, moving towards people, etc.
  • Audio-video connections should be established simultaneously, to avoid any lag. When sessions end they should ‘fade-out’ rather than end abruptly.

Enable users to augment their verbal communication with gestures

  • Allow users to gesture explicitly when interacting with other users. A basic option is to include pointers, which are identified as belonging to specific users.
  • Users should be able to illustrate concepts through gesture. For example, in the way that a person might describe the size of an object by placing their hands a certain dis-tance apart. In order to be naturalistic this might require video communication, or sophisticated tracked avatars.
  • Users should be able to employ a range of emblematic gestures in their communica-tion. This refers to actions such as the nodding or shaking of the head to indicate ‘yes’ or ‘no’, for example. Where sophisticated avatars or video are involved this functionality should be relatively straightforward. In lower-fidelity situations, con-sider alternative solutions, e.g. the emoticons used regularly in Instant and SMS messaging.
  • Finally, users should be able to use gestures to refer to items within the workspace. The key challenge is to ensure this can be achieved fluidly, simultaneous with speech, and as naturalistically as possible. If possible, provide tactile feedback to enhance awareness of the limitations within digital information
  • Gestures should be sensible (i.e. make sense to the user), sensable (i.e. can be meas-ured by the system) and desirable (i.e. are suited to the application).

Enable users to communicate through shared artefacts

  • Users should be able to see and hear what others are doing with artefacts within the CWE. This relates closely to the concept of feedback. Supporting this level of communication will enhance the users’ ability to make sense of virtual collaborative spaces, and to mediate their behaviour.
  • At a minimum, systems should enable users to view artefacts concurrently. User should be able to annotate and manipulate these together.
  • Users should be able to easily determine if aspects of their interactions are limited by the technology, or by the behaviour/limitations of other users.

Coordination

Users should be able to move easily between loosely- and tightly-coupled collaboration

  • Collaborative work comes in many forms. Within a project, tasks might be individ-ual in nature, or require focussed groupwork. In co-located situations, it is easy to move between the extremes. Collaborative systems should:
  • Make it easy to find and establish contact with other users
  • Enable users to determine their availability
  • Allow users to maintain awareness of what others are doing
  • Identify opportunities to move from individual to group work
  • The system should allow individual views to the CWE. Communicate these views to other users as required. For co-located working situations, for example, users may wish to work on a specific area of the interface on their personal device, whilst a broader area is viewed on a shared display.
  • Designers may wish to distinguish between lightweight interactions and more for-mal meetings where, for example, multiple participants are involved and compli-cated data is worked on. It should be simple and straightforward, e.g. the click of a button, to move between the two states.

The system should enable users to coordinate their actions with each other

  • Make user goals explicit. What are a user’s immediate intentions? What are their long-term goals? Communicate this information to other users.
  • Make sure all changes are visible to users. This includes historical and real-time changes. What has been changed, who changed it and when. Make documents lockable, but simultaneously provide mechanisms for users to negotiate with the user who has locked a file.
  • Show the interdependencies that are present in the work. How the labour is divided, what work is prerequisite for tasks, what are the required shared resources, etc.?
  • Ensure the system supports concurrency. Make sure users and data are protected when multiple users can work on the same artefact simultaneously. Take care to avoid breakdowns, and make this easy to overcome when they do occur. As far as is possible, try to anticipate actions and identify potential conflicts.

Design the system with consideration of social rules and conventions

  • The extent to which the system imposes social rules on users should be determined through close involvement with users.
  • Technologically determined structures may be recommended for highly procedural tasks and/or safety-critical domains. They may also be useful for regular, straight-forward communications. However, where communication varies substantially, a more socially determined structure is appropriate.
  • Consider whether it is necessary to employ turn-taking as opposed to concurrency. What sort of permissions need to be negotiated?
  • What control is necessary over entry and exit to a session? 
  • How should floor-control (the passing of control between users) be negoti-ated? This could be users passing a ‘baton’ or token between themselves, or having a chair-person.
  • The system should respect the privacy of users. They should be able to determine what information is public, and what is confidential. In some situations, different levels of access may be required. Information may be inaccessible to some users, but accessible to others.
  • Take care to avoid abuse of the system. Although the system should respect user privacy, it is important that users remain identifiable. Consider establishing varying levels of access; determine what these are through close work with end users.


Do not overload or unnecessarily distract the user

  • Take care that the user is not constantly interrupted in their task work. Design the system so that users can customise how they are alerted to changing events.
  • Users should be able to determine their own availability. Different levels of avail-ability could have user definable settings for how they are notified.
  • It might be possible for the system to ‘intelligently’ determine the availability status of users. However, caution is advised and the user should, at the very least, be able to switch off such functionality.

Use adaptable and changeable models of collaborative work

  • Take care when basing system design on user models. Do not use fixed models of user behaviour. Users should have access to underlying collaboration models, and be able to amend these according to new organisational realities. Make all changes traceable.

Awareness

Support users in finding and contacting collaborators

  • A good collaborative system will support planned meetings and informal, ad-hoc meetings. These should be scalable, i.e. users can participate from a range of set-tings. It should be easy to augment meetings, e.g. to move from instant messaging to a multi-participant meeting where changes are made to data in real-time.
  • Show the identities of users in the workspace. Who is actively working, who is ob-serving, who is currently inactive? Show what activities users are currently engaged in, what tasks are they working on and what tools they are using.
  • Show embodiments and contextual information about other users. What are they looking at, for example? Allow users to fully express themselves, by either com-municating implicitly over video or explicitly by emoticons or similar.
  • Show the locations of users, within virtual and physical spaces. Where are their ef-forts focussed, and what can they see? Users should be able to register their loca-tions, not just indicate their presence or absence from base stations.

Maintain awareness over time

  • Design the system to support mutuality.
  • Users may wish to customise what events, activities, other users, and so on, they are informed about.
  • Include activity logs, news-feeds, histories, and so on, to support users in getting a broad overview of workplace activity.

Provide collaboration spaces

  • Collaborative systems could be designed according to room or place metaphors. Us-ers should be able to see who else is in a ‘room’, where they are and what they are doing.
  • Although users should be able to customise their interfaces, there should be enough commonality in what users see so that they can establish common ground. Users should be able to see what others can see, or be aware of any differences between their viewpoints.
  • A system may incorporate several different collaboration spaces. These should re-late to each other.
  • Consider inclusion of areas where users can present information they are working on publicly, allowing colleagues to view, comment on or use as the basis for initiating further contact.



Retrieved from "http://kb.eurovr-association.org/index.php/Design_guidance_for_CWEs"
Log in / Create account  
Views