Improving BI User Experience in Corporate Environments: Practical Strategies That Work

Francesco Marino

Discover actionable techniques for improving BI user experience in corporate environments, focusing on user personas, training, and documentation.

When managing a Business Intelligence (BI) platform in a large organisation, improving the BI user experience in corporate environments is just as important as designing a clean user interface.

According to the Nielsen Norman Group,

“The User experience (UX) encompasses all aspects of the end-user's interaction with the company, its services, and its products.”

Today, we will examine a few practices for improving the user experience (UX) of a large corporation's Business Intelligence (BI) platform.

The user personas

When discussing UX, we must remember that each user's journey is unique. We can group users with similar needs into user personas.

For a Business Intelligence platform, I usually consider these user personas:

Report users: they are read-only users of the reports. They want to know:

• How to correctly use the reports.

• Which reports are available, and how can they get access to them?

• Who should they contact if something is not working?

• Who should they contact if they would like to have a new functionality?

Citizen developers typically build new reports, sometimes on top of the data of existing reports. So they want to know:

• How to use the data from existing reports.

• What does the development experience look like for them?

• Who to contact for questions.

Management: They usually use the BI platform, and they are interested in the value the platform brings. They want to know:

• What are the available reports, and what value do these reports create?

• How many users are there, and how often is the platform used?

• Who is the team behind the platform?

• What functionalities are offered?

Developers develop reports and maintain the platform with a proper governance model. They want to know:

• What are the development standards (templates, authentication methods, etc.)?

• What does the deployment process look like?

• What is the established governance model?

Technical support: They are responsible for solving the platform's technical problems.

They want to know:

• What does the architecture of the BI platform look like?

• What are the data sources for each report?

• The list of potential and common technical issues and the relevant solutions.

Ways to improve the User experience

From my experience working with BI platforms, improving the BI user experience in corporate environments involves three main elements:

• When it is easy to find what you are looking for.

• When it is easy to find and contact a person who can help you.

• When it is easy and quick to get potential issues solved.

This usually means easy access to good documentation, easy accessibility to the BI platform team, and good trainings.

In detail, this is what I use to improve the user experience of a BI platform:

• Use of intranet short-links

• Ad-hoc trainings

• Good documentation:

  • Single report documentation

  • Platform documentation:

    • List of reports

    • Technical documentation

    • Developer documentation and Citizen developer documentation.

Use of intranet short-links

Short-links are helpful for all user personas to reach documentation and reports easily.

Several companies use short-links for their intranet sites. For example, to reach the HR system, you can write something like "go/hr" in your browser, click Enter, and be redirected to the HR system.

Nothing special, but helpful. As a BI platform owner, you can use these short-links to make reaching reports and documentation easier. For example:

• go/finance-bi - Access to all the finance reports in the BI tool,

• go/ch-budget-bi - Access to the "CH budget" report,

• go/finance-bi-help - Access the support documentation for the finance BI reports.

These short-links are useful when:

• Users need to access reports and documentation. Of course, they can save the links as bookmarks, but it is often easier this way.

• From a technical point of view, sometimes you need to change the reports or documentation URLs. In such cases, without short-links, you would need to contact all the users and provide them with the new links. With short-links, users can use the same links as before, and you just need to change the target URL to the new one.

Short-links have some cons, too: They are challenging to maintain when you have many. Also, you are adding another technical layer to reach the report, which can sometimes fail.

My suggestion is to use short-links when you have a reasonably big number of daily users. For the rest of the cases, assess if it makes sense to use them or not.

Ad-hoc trainings

Ad-hoc training is helpful for report users to understand how to use the reports correctly.

When you build BI reports, the goal is always to have self-explanatory reports. However, reports are often not self-explanatory, and sometimes there are hidden functionalities that it is better to make clear.

For this reason, when I release a new report, I organise a training session with the final users and, when possible, record it. I normally define the audience and content of the training simply according to the users' journey.

During the training, I explain how the report works following the potential user journeys of the report. Let's make an example to make it clear.

Example - IT TCO report

We released a Total Cost of Ownership (TCO) report on our company's IT applications.

The target audience is composed of:

• IT Owners of specific applications want to see the cost details of their application, drilling down to the cost of individual components.

• The tech lead of a specific area that owns different applications wants to see the TCO of the applications in his/her area of competence and summaries by application and cost category.

• The company's business managers want to see the total TCO for all the applications and the details, too, to identify cost reduction opportunities.

During the training, we explore each of these user journeys, showing where to click to cover the steps to fulfil the user's needs. In addition, we can clarify additional relevant information: where is the documentation, how to get support, and other functionalities that might be useful outside of the standard user journey scope.

Good documentation

Documentation, if well written, is always helpful. But documentation means many different things. This is how I recommend setting up the documentation for a BI platform:

Single report documentation

Single report documentation is useful for providing information about each report, and it is added directly to the report hosted in the BI platform.

For each report, I typically add documentation in two different ways:

1. I create custom help tooltips for single visuals with metric definitions.

Custom tooltip in Power BI

1. I create a documentation page (usually similar to A4 format) with the following information:

   • Description of the report and target audience.

   • Data sources and refresh frequency.

   • Contacts.

   • What do you do when requesting new functionalities or when users find a bug?

   • How do you access the report? (Users can pass this information on to new colleagues if necessary.)

   • The reports' definitions and assumptions are not used anywhere else. If the definitions come from other applications, we redirect to the application documentation.

Example of a report documentation page

Platform documentation

Platform documentation is useful for providing information at the platform level. It is hosted in tools like Wikis (e.g., Confluence) or SharePoint sites.

Usually, I add the following types of documentation:

1. List of reports

2. Technical documentation

3. Developer and Citizen developer documentation

4. Team information

1 - List of reports

The list of reports provides specific information about all the maintained reports in the BI platform. It usually is just a simple table (I use SharePoint lists) with the following attributes:

• Report name.

• Report description.

• Report target audience (with a guesstimate of the number of users).

• Data sources and refresh frequency.

• Data confidentiality.

• Data owners.

• Point of contact for the report.

• Status.

• Which rights should I request to get access to the report?

• Link to the report.

To ensure this list remains updated, adding a new report can be done as part of the release process.

2 - Platform Technical Documentation

The technical documentation is required to provide information about the platform. Usually, I add these pages/sections:

• High-level platform architecture with details about environments, access management and security set-up.

• Platform details: list of technical accounts, license details, platform settings, detailed architecture and dataflows.

• Governance with details about the operating model (who does what and where?)

• Known issues with solutions or relevant workarounds.

• Support process.

For this type of documentation, I understand that it can sometimes be difficult to track all the cases or changes of the platform. I suggest using common sense here: write documentation when it is useful for others. In most cases, it is.

3 - Developer and Citizen developer documentation

Developer and Citizen developers' documentation should be built to accelerate the development process and increase the quality of the reports developed. Usually, I add these to the pages/sections:

• Preferred authentication methods for the available data sources.

• Which gateway should be used for Power BI, and how can I access the gateways?

• Reusable report templates.

• Deployment process.

• Version control set up.

• Development best practices.

Of course, we need to remember that citizen developers and IT developers have different needs. Sometimes, we need to provide different best practices for these two different audiences.

4 - Team information.

I usually also add a page with information about the team. Specifically:

• What the team has done.

• What services are provided?

• Who is doing what, and a brief personal description

This is useful as a single information point for all the platform's users and stakeholders. It helps give a transparent view of the team's activities and the value added.

Summary

On a Business Intelligence platform, improving BI user experience in corporate environments is as crucial as focusing on User Interface (UI) design. Good UX means users can easily find what they need, get help, and resolve issues quickly.

To achieve this, I suggest:

1. Understanding User Personas: Recognise that different user groups (Report Users, Citizen Developers, Management, Developers, Technical Support) have distinct needs and journeys with the platform.

2. Implementing solutions:

   • Intranet short links: Use simple, memorable URLs (like go/bi-report-name) to provide easy access to reports and documentation. This is especially useful when the underlying URLs change.

   • Ad-hoc Trainings: Offer targeted training sessions when releasing new reports, focusing on specific user journeys and recording them for reference.

   • Comprehensive Documentation: Create clear and accessible documentation, broken down into:

     • Single Report Documentation: Integrated directly within reports (e.g., custom tooltips, dedicated help pages) detailing metrics, data sources, contacts, and access procedures.

     • Platform Documentation: Hosted centrally (like a Wiki or SharePoint), including a list of all reports, technical architecture details, developer standards (templates, best practices), governance models, and information about the BI team.

In my experience, adopting this structured approach benefits users and platform owners.