FAQ: How to create Effective Messages

Transcription

1 User Experience Direct (UX Direct) FAQ: How to create Effective Messages Disclaimer The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, functionality, or service and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle s products remains at the sole discretion of Oracle. This document contains preliminary images. 1

2 FAQ: How to create Effective Messages User Experience Direct (UX Direct) is an Oracle Applications User Experience (UX) program that provides user experience expertise to Oracle customers and partners for their implementations, customizations, and use of Oracle enterprise applications. The goal of this program is to enhance end user experiences during and after customer implementations and to improve user adoption of Oracle s enterprise applications. Overview High quality software applications smooth the flow of work for end users by displaying well-timed messages in plain language. For example: 1. Are messages designed according to user-centered design principles? Ensure that messages are created as part of a user-centered design (UCD) process. Study how users work and what they need to know when the application reacts to their input. Never write a message as a workaround for poor design and usability. For example, if a user is likely to make a mistake when entering data or to navigate to the wrong place before saving data, it s best to revisit the design. Show messages within the context of the task being performed and integrate them with the rest of the user experience. Layer messages with other assistance available in the user interface, such as tool tips, instructional text, or pop-ups. Messages help users to feel in control of their applications by providing feedback about what they have just done and what the applications are doing in response. Messages help minimize errors, display warnings, and, when errors do occur, inform users about what has happened and how to fix the problems or obtain help. Effective messages are needed not only in the core application that an organization purchases, but also in any software that the organization adds to the application to configure and customize it. The questions and answers in this guide help software designers who are implementing Oracle applications to understand the different message types and how to use them effectively to help optimize applications for task completion and productivity. 2. Have you categorized your messages and been consistent in their appearance? Categorize your messages by type and apply the visual experience, such as icons and headings, consistently to each type. Users should be able to distinguish between message types and priorities by their appearance, especially when messages appear together. For example: Use these message categories: Error: Tell users about incorrect data or formats when they complete a field, leave a page without saving, or perform other actions that need validation. Explain how to correct the errors. Error messages should also appear when the application encounters serious problems that users cannot resolve themselves. 2

3 Warning: Tell users about important consequences that will occur immediately or in the future when they perform an action. Warning messages also prompt users to make important decisions about irreversible actions before proceeding. Information: Tell users about changes on the page or in the application. Processing: Tell users when actions or requests are in progress, especially when there is a delay in the application s response. Confirmation: Tell users when actions or requests are complete. 3. Do you understand what validation rules are being used for the messages and when they are being applied? Understand how the application validates data and actions and apply the type of message accordingly. Consider the following scenarios: The application validates data entered by the user or another process. A problem may arise, for example, when saving a page with missing data, completing a page with incorrect data, navigating from one page to another without saving, and so on. Show error or warning messages in response. The application validates the creation or update of a business object or a page. Use information messages when users should know about these changes. When the application validates that an action or request is in progress, use processing messages. When the application validates that an action is complete, use confirmation messages. To help users complete tasks, explore what validation the technology stack provides by default. For example, the Oracle Application Developer Framework (ADF) provides client-side components that automatically validate data entered in editable fields or converts data to the correct format. These components have their own messages. Other client-side validation and more complex server-side validation of business rules, for example, require development. Remember that server-side validation is generally slower than client-side validation. Design accordingly with the user in mind, using server-side validation at the end of tasks or page completion, rather than for individual fields, so that productivity is maximized. Make sure that business analysts, designers, and developers collaborate on the design and implementation of validation rules and the associated messages types. 4. Have you written clear, actionable message text for the user? Write a concise message that tells users about the cause of the problem and how to fix it or that tells users clearly how the application is performing. Use terminology that matches the rest of the user interface, and ensure that the language is suitable for the person likely to see the message. If end users will see the message, use simple, non-technical terms and language. If technical or functional users will see the message, disclose technology stack details using appropriate terms and language. Never blame or accuse users of doing something wrong, or frighten them with uppercase words and exclamation marks (such as DANGER or ERROR! ), knowledge-based numbers, technology stack details, and so on. If a developer writes the message text, have it reviewed by a writer, representative user, or help-desk member before implementing it. 5. Have you integrated messages with your help desk? Messages are frontline help-desk support, too. When users cannot fix errors themselves for example, a serious application error then integrate the message into your helpdesk policies. Capture as much error information as possible automatically for users, and route it to the help desk for the user. For example, raise alerts and create diagnostic logs in the background. Never tell users to contact your system administrator. Instead, write message text telling users that the help desk has been contacted, quote an incident number, and tell users what to do next. For example: 3

4 When deciding whether to show messages inline (that is, on the page itself) or in dialog boxes, consider the type of task that the user is working on, the frequency of the error, and the seriousness of the error. Show messages about routine tasks that may occur frequently inline to minimize disruption. For example: Customize your messages with additional support information or policies. Make sure that users have been trained about what support they can expect, too. Append unique message numbers to the message text so that technical users can quickly look up errors and warnings in knowledge bases or support forums, or search for solutions on the web. Do not disclose such numbers to end users they do not find them useful and may even find them intimidating. 6. Have you applied message usability best practices? Use researched and established guidelines to determine when and how messages should appear to users. Show informational messages that require no immediate action inline. For example: Show messages about infrequently occurring, page-level actions, or serious issues and consequences in dialog boxes so that users do not miss them. For example: Messages must appear close to the location of issues so that users can quickly correct errors and continue their tasks. Show messages using visual clues, such as icons, colored borders, and headings. For example: Show messages about navigating between pages, processes under way, and warnings with questions that require user responses in dialog boxes. For example: For heads-down tasks, show all messages together in a list after the task has completed. This list does not interrupt productivity; instead, this list enables users to address issues together on the page. For example: Include a message in a modal dialog box to prevent users from interacting with a page until the message is resolved (for example, during a process that is running, when a response to a warning is needed, or when a serious error occurs). For example: 4

5 To enable users to continue seamlessly to their next actions, consider using action buttons to confirm message dialog boxes. Most messages that users see are related to errors, but do not forget the powerful user experience benefits of using other types of messages in these ways: 7. Have you anticipated the importance of back-end messages too? Back-end messages, such as error, warning, and information messages are also created by applications. These messages are intended for technical users or the help desk and usually appear or are printed in text-based log files. For example: Use warning messages to ask users to confirm their actions before proceeding. Use clearly labeled actionable buttons, rather than Yes or No buttons. For example: For these messages: Apply basic text formatting for headers and lists, structuring the output so that it is more readable. Use appropriate technical language with precise details for diagnosing and fixing issues. Use warning messages to let users know about the downstream consequences of their actions. Use informational messages when details on a page are updated or when the page status changes becoming readonly, for example. When no visual indicators are available or sufficient, use confirmation messages to confirm for users that their actions have been completed as intended. For example, if a user is deleting a large number of objects, confirm the number of deleted objects; or, if the user is submitting an expense report, confirm that the report has actually been submitted. Users prefer more rather than fewer confirmations. For example: Use confirmation messages at the end of lengthy processes so that users can confirm that they understand the process status. Do not allow processing message dialogs to close without confirmation because users may be away from their computers when the messages appear. Write concisely, eliminating unnecessary words. Log files can be long, can contain many details, and are frequently read online. Write the text so that readers can scan the contents and pick out key information quickly. Make sure that the file can also be read when printed. User Experience Benefits from Messages Following a UCD process that includes user experience best practices for messages means that the application communicates with users in an accurate, friendly, contextual way, maximizing task completion and productivity. Consider messages as a hidden window into the level of excellence of your user experience. When you create messages that reflect how your users work, telling them what they need to do to complete their tasks quickly, communicating with them about an application s behavior, and enabling the help desk to respond to issues effectively, users will have confidence in the quality of the rest of the user experience design and implementation. For more information about making messages and user assistance part of your user experience, visit the 5

6 UsableApps.oracle.com website or the Oracle blog on user assistance at blogs.oracle.com/userassistance. 6

7 Oracle Corporation Worldwide Headquarters 500 Oracle Parkway Redwood Shores, CA U.S.A. Worldwide Inquiries Phone ORACLE1 Fax oracle.com Copyright 2012, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. UNIX is a registered trademark licensed through X/Open