{'fraction_non_alphanumeric': 0.019374068554396422, 'fraction_numerical': 0.003974167908594138, 'mean_word_length': 5.254658385093168, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Arbitration of a help system

DESIGN CAN BE AS MUCH AN ACT OF NEGOTIATION as it is of creation, and designers can find themselves cast in the role of negotiator or arbitrator among competing interests. Designers of user-assistance systems often face the most difficult negotiations, because user assistance tends to be perceived as a less important module. This secondary status means that proponents of user assistance negotiate from a weak position with respect to other modules’ interests. This article presents a case study describing the design of the user assistance—and that design’s negotiation—for an enterprise business’s intelligence application. One of my clients is a large company that is building an internal, enterprise businessintelligence portal that provides consistent and structured access to quantitative metrics from across the organization. The portal is built on top of Siebel Analytics (the Cayman release of 2005), which creates dashboards of query reports but is not a portal platform. While Siebel Analytics provides a powerful back-end engine for integrating data sources into a common business model, its limited UI prevents almost all inline help techniques and JavaScript customizations. Therefore, all user assistance must be provided off-page. Our job was to implement user assistance within the requirements and constraints of both the stakeholders and the platform. The portal is designed with the following goals: 1. Provide a common user experience across all dashboards. 2. Provide a dashboard organization that enables users to easily navigate to known dashboards and discover unknown dashboards that can help them. The portal requires two levels of user assistance: 1. Global Help for the portal itself 2. Local Help for each individual dashboard In both levels, help includes instructive information to help users perform needed actions as well as supplemental information such as change-management processes, metric and domain ownership, known issues, and future plans.