Building good dashboards for internal users is not easy, but the challenges and pitfalls are generally well understood. Creating data apps for external users is an entirely different matter, with its own set of considerations.
User-facing analytics are data apps and dashboards that are made for users external to your organization, usually your customers, clients, or end-users. Perhaps you provide services and want to show your customers how they are performing. Perhaps you’re leasing or selling devices that collect data about their performance and utilization and want your customers to know how they’re performing. Or maybe you’re creating and publishing rich, interactive maps and graphics that highlight local impacts of climate change.
In all these cases, you’re dealing with a broad range of users, who are also usually less familiar with the data being shown. At the same time, you also know less about them, and often can’t easily get feedback from them. To build useful data apps for these users, it’s important to put yourself in their shoes and try to envision the kinds of questions they might have, and the decisions they might need to make.
External users are more challenging, because they work in a different context, so need to be reminded that they’re looking at a data app coming from you. That makes branding and design even more important to ensure they understand what they’re looking at. They’re also less forgiving about a slow dashboard than your internal users.
User-facing data apps need to enable quick decisions even more than internal ones, and at the same time give people ways of digging deeper if necessary. It’s also a good idea to include more context and pointers to other data than you might have for an internal dashboard. And they need to be snappy, or risk losing your users/customers. Here are a few tips and guidelines for building successful and delightful data apps for external users.
External users, more even than internal ones, will use your data app for a quick check first: Is everything as expected? Is any action needed? Your data app needs to be designed for this task. There are several ways to do this.
One is to help users by phrasing headings as questions. How many users did we have today? How many gizmos did we sell this quarter? How are sales tracking relative to our quarterly goal? Etc. Each of these needs to be paired with a relevant data visualization or number, of course.
Another is creating a visual hierarchy, so users can find key information quickly without getting overwhelmed. Structuring a dashboard using big numbers at the top (we discussed these and other strategies for building better dashboards recently) gives users the top-line information quickly without having to hunt for it. Other views need to be designed so they don’t compete with these numbers, but connect with them. Careful use of color can help with this, as can using section headings and spacing that group logical units of information.
A quick “TL;DR” or executive summary-style section at the top can also help to assure users that metrics are in check, or point them to specific ones that might need attention. This can be generated by your analysis code, and incorporate not only numbers from the overview, but also links to the more detailed views discussed in the next section.
Crucially, quick insights mean limiting the amount of information being shown. An external-facing data app shouldn’t go into too much detail, but keep things high-level with the option to get more information. It is tempting to add more and more information to a dashboard, but at the risk of overloading it and making it less useful for its purpose.
Depending on your use case and users, you might want to build in ways to allow your users to dig deeper. This won’t be necessary for all use cases, but it can be incredibly helpful for your users when there is a problem they need to diagnose. Splitting off detailed analytics views can also help to keep the scope of the overview dashboard more manageable, and keep it focused on the essential information.
One good way of doing this is with multiple pages that are linked from the main page of the app. If a user has a question about the data shown on a particular chart, the link to more details should be right there as well. Using code to build charts helps to create more and less detailed versions of the same view, too. You can reuse most of the code, with options to control the level of aggregation, which additional data columns to show, etc.
Not only will the visualizations be more detailed on these pages, there will also be more controls. This includes filters, ways to add more data columns, options to turn models off and on, and even ways to control models. If you’re building your dashboards with code (as you should!), you can run models right in the user’s browser, which means giving them direct and fine-grained control over them. Models can help users understand what the data is telling them, and play with what-if scenarios.
Even with detail views, there are always going to be questions your data app won’t be able to answer. For these, you might want to provide ways to export the data so users can do their own analyses in tools like Excel. A common data format like CSV is ideal for this, because despite its simplicity and flaws, it is readable by virtually any software.
External users are usually less familiar with the data and terminology being used in a data app than internal ones. They need more guidance and context to be able to understand, and not misunderstand, what’s being shown.
Ways to help users include making sure that all charts are properly labeled, including units on axes, time periods, legends for color encodings, etc. Chart and section titles should also be clear about what is being shown, and additional text can be added to help users interpret what they are seeing.
In addition, if there is documentation about the metrics shown, the specific charts, models, etc., link it directly from the app. It is easy to assume that your users will understand what they are looking at, but there are many reasons why they might not: perhaps they aren’t familiar with the app yet, haven’t used it in a while, or are only starting to work with data in their role.
Finally, when all else fails, users need to be able to reach a human to ask questions. Including a way to reach support or the developer of the app should be included in the app, and be easy to find.
Your users might be using many data apps in their work. Make sure they know which one they’re looking at! This includes both branding and thoughtful design.
Branding is all about your visual identity: logos, colors, typefaces, etc., that identify your company or product. You want your users to recognize your data app at a glance when they flip through their browser tabs.
Good design, in addition to the visual hierarchy mentioned earlier, also means making your data app look great so your users will actually want to use it. A well-designed app is more enjoyable to use, which translates into more of your users’ mental energy spent on their task than wondering about your poor design choices.
For both branding and visual design, Observable Framework makes it easy to create themes that can be used across many different data apps and pages. They can be imported just like code, and any changes will automatically propagate through all your data apps for consistency.
An important consideration here is also accessibility. External-facing data apps, even more than internal ones, will be used by a wide variety of people with different abilities. This is not only a good idea to make sure all your users can actually use your app, but you might actually be legally required to follow accessibility guidelines. Observable Framework’s use of web standards allow you to quickly incorporate all the assistive technologies that are built into today’s web browsers and operating systems.
Quick insights not only require thoughtful design, but also a data app that loads quickly. Traditional BI tools load their data when the page loads, which can take a long time.
Outside users, even more than internal ones, will lose focus and move on if they have to wait. Since they’re also paying for your services, they will also be less forgiving, and more vocal, about their dissatisfaction than internal users would.
Making your dashboard load fast isn’t a luxury, it profoundly affects how people use, perceive, and engage with your work. Users come to your dashboard with a question or the need to check in on their data. Having to wait for the data to load means they might get distracted and move on to other things in the meantime. This makes their work less efficient, and reflects badly not just on your dashboard, but the entire image they have of your products and services. Your databases might be under load, or there might be a lot of data processing happening behind the scenes. Your users won’t know that or, frankly, care. What they see is that you’re making them wait.
This is why Observable Framework puts speed first. As a static site generator, it runs data loaders offline (on a schedule, see the next point) to generate “baked” data packages. These load instantly when your dashboard or data app loads, which makes for a profoundly different experience for the user. It also gives developers more freedom to perform complex queries, data processing, and modeling, since they’re not constrained by load times.
The data in your app needs to be as fresh as makes sense for your application — but beware of the fallacy of up-to-the-second data. While it might seem that data needs to be as current as possible, data about incomplete days, weeks, or months can be a distraction. If your data shows sales, for example, your users might wonder why they’ve been dipping when in reality they’re looking at data that only contains parts of the last week, month, or quarter. This can lead to misunderstandings and bad decisions.
A well-considered update schedule means that the data shown is always meaningful, without the noise, distraction, and cognitive load of incomplete data. In addition, any dashboard or data app should always show when the data was updated, so users can understand what they are looking at.
Observable Framework’s data loaders can be run at whatever interval makes sense for your application. Observable Cloud offers scheduled builds for this purpose: set up an interval at which your app needs to be built, and it will be taken care of. This includes logs for trouble-shooting, ways of canceling and restarting builds, and many more useful features.
User-facing data apps can provide a lot of value to your users, and make your products and services much more accessible and valuable to them. Building good ones is challenging, but also very rewarding.
Many of the considerations for external-facing data apps also apply internally, but some of them are unique. Branding and visual design, for example, are less crucial for internal users (though they will also appreciate a clean, good-looking dashboard). External users also need more context, and being able to quickly find information is even more important to them if they’re more casual users (in terms of time spent, not importance) of your data.
Some of the other items are also important for internal users as well, of course, such as speed, the need to carefully consider how and when to update data, or the visual hierarchy of the information being shown. But since you’re likely to know more about your internal users, you can tailor the information to their needs much more directly, and more specifically, than you can for external users.
To explore further, check out these materials:
A blog post on why building data apps with code gives you more flexibility and power, especially when you’re building user-facing dashboards
More on data loaders, and how they make for snappy data apps, no matter how complex your data processing
The Observable Cloud launch post, describing the platform and what it can do for you