In an earlier article we discussed the importance of the aesthetic design of dashboards. However, “Audience” is another key design factor within the dashboarding architecture. Determining user profiles and their privilege domains will contribute to the creation of a personalized dashboard experience. An effective dashboard must only present those KPIs that are relevant to a given user and within the user's domain of privilege. These KPIs must also reflect the specific grains relevant to the user.
Dashboard personalization requires the establishment of a three-dimensional framework inclusive of the following:
Dashboard personalization is an intersection of a three-dimensional framework
- User groups and hierarchies
- Privilege domain
- Content domain
User Groups and Hierarchies
The main purpose for developing user groups and hierarchies is to avoid the repetitive task of allocating certain sets of privilege and content access to each individual user. Establishing such groupings allows allocating a set of privileges to all users within a given group with a single stroke of software command. Similarly, through inheritance, multiple user groups within the hierarchy may be allocated a set of privileges with a single click.
For example, if five hundred sales personnel require access to reports with sales trend, market share, and sales forecast variance, this could be accomplished in a single stroke by grouping these five hundred people as the Sales Group and giving this group access to corresponding KPIs and reports common to them all. However, in a more realistic situation, fifty of these sales personnel may be responsible for only one of ten regions, say Region 1. Additionally, twenty customer service reps and twenty-five distribution personnel may be assigned to Region 1, all of them requiring competitive market share information in Region 1. In this case, a hierarchy for Region 1 would include sales, customer service, and distribution groups to inherit the same set of reports or KPIs. Note that there would be separate groups such as Region 1 Sales, Region 1 Customer Service, and Region 1 Distribution because each of them may need a separate set of KPIs unique to each group, while also requiring a certain common set of KPIs for Region 1.
Groups and hierarchies are determined based on business requirements and information needs. User hierarchies may be multilevel, which allows a cascading of privilege sets from higher to lower levels. A user may belong to more than one group, and therefore inherit a combination of privileges from all of the groups to which he or she belongs.
Applications of user groups and hierarchies have been most prevalent within the different database management and business intelligence software. Any experienced database administrator can help build an effective user hierarchy and groups if the organization does not already have a matured business intelligence (BI) infrastructure in place. However, user groups and hierarchies in a database context are rarely helpful in managing a dashboard deployment because those groups and hierarchies enforce the access privilege to database resources-tables, views, columns, and database commands-whereas the dashboard groups enforce the restrictions and privileges related to dashboards functions, features, and KPIs, which are very different than a database.
Before starting to develop user groups and hierarchies for a dashboard deployment, one needs to acquire a clear understanding of the separate business functions and their varying information needs. It is important to know the organizational hierarchy, the domain of responsibility defined for each level of hierarchy, and the corresponding information needs. This information is essential in building a dashboard framework that encompasses both privilege and content domains.