# How Data Teams Earn Adoption for New Dashboards - Published: 2026-10-27 - Author: [Informatics Magazine](https://informaticsmagazine.com/author/informaticsmagazine-com.md) - Topics: [Q&A](https://informaticsmagazine.com/qa.md) - Source: https://informaticsmagazine.com/qa/how-data-teams-earn-adoption-for-new-dashboards/ - Publisher: Informatics Magazine ### End Legacy Workbooks at Production Huddles The change that worked for us was retiring the spreadsheet in the meeting, not in an email. We have rolled out several dashboards for order volume, production, and customer retention. Our first attempt failed. We built a nice dashboard, announced it, and within two weeks everyone was back in their old spreadsheets because those felt safe and familiar. The dashboard was an extra tab, not the source of truth. The second time, we picked one recurring decision, our weekly production planning meeting, and ran it only from the dashboard. If a number was not on the screen, we added it that week instead of letting someone pull up their own sheet. Within a month people were opening the dashboard before the meeting to prepare, because that was where the conversation happened. We also asked the heaviest spreadsheet users to help design the views. They knew which numbers actually mattered, and once their work was in the tool, they became its biggest advocates instead of its quiet resistors. My advice: tie the dashboard to one real decision, make it the only source in that room, and let the skeptics build it with you. --- ### Make Signals Shape Next Steps The strongest adoption lever is not training, it is consequence. A dashboard becomes habitual when it changes what happens next. In one operating review, we stopped allowing updates framed as activity, such as calls made or articles published. Every update had to begin with a dashboard signal, followed by an explanation and a proposed decision. That format did something subtle. It made the dashboard a language for judgment rather than a screen people checked after the real conversation. It showed freshness, reducing false precision. Once colleagues saw that imperfect data could still support timely decisions, usage increased. The key was redesigning the meeting, because behavior follows the institution that rewards it. --- ### Define Separate Purposes for Both Tools We avoid asking colleagues to abandon spreadsheets on day one because they often hold years of practical knowledge. Forcing a switch can make people feel they are losing control. Instead, we show how the dashboard removes specific burdens, such as combining updates manually or deciding which file is current. This approach makes the change useful rather than disruptive. The key is to give each tool a clear purpose. The dashboard supports routine monitoring and shared decisions, while spreadsheets remain useful for exploration, modeling, and detailed checks. We reinforce this balance by using the dashboard in leadership reviews and team check-ins. When decision makers rely on the shared view, adoption grows naturally because everyone knows where discussions begin. --- ### Embed Clickable Reports in Google Sheets We stopped asking people to adopt a new place to look. Every report and analysis my agency delivers is a Google Sheet, because that is where clients and our own team already work. A dashboard in a separate tool needs its own login and a new habit before anyone opens it. A Sheet arrives in the same place as everything else they use. The change that made reports part of everyday decisions was in how we build them. Every web address in a report is a full clickable link, so the reader can open the page a row describes in one click. Every label is written in plain words with the action attached, never a code or a tier name only the analyst understands. Each report also carries a short methodology section saying where the numbers came from. When a reader can check a number in one click and knows what to do about each row, they use the report. When they have to ask the analyst what a column means, they go back to their old spreadsheet. --- ### Consult Evidence Before Strategy Talks The change that worked best was moving dashboard use upstream in the decision process. Previously, teams looked at reports after a decision had already formed through conversations and spreadsheet reviews. We changed the sequence so the dashboard was reviewed before planning discussions began. It became the common evidence base rather than a retrospective summary. That shift reduced unproductive debates over whose numbers were correct. Everyone entered the conversation with the same definitions and timeframe. We also designed the view to highlight movement and exceptions instead of filling the screen with static totals. People respond faster when they can see where attention is required. Over time, the dashboard became part of meeting preparation because arriving without having checked it meant missing the context behind the discussion. Routine use emerged from workflow design and not reminders. --- ### Tailor Views to Individual Needs People go back to spreadsheets when a new dashboard doesn't fit the work they're already accountable for. An accountant lives in QuickBooks because the job requires it. A supplemental analytics tool is competing with existing habits, and a familiar spreadsheet usually wins that contest. The change that's made the biggest difference for us is designing dashboards around each role instead of showing everyone the same view. We make sure dashboards allow filtering by role, which is what makes data actionable instead of overwhelming. When the first screen someone opens answers a question they already have to answer for their job, they don't need a reason to go back to the spreadsheet. --- ### Co-Design Logic and Add Live Alerts To prevent users from reverting to old spreadsheets, it is important to address the specific friction point that necessitated their use in the first place. My two decades of experience in ERP implementations in manufacturing and distribution has revealed to me that adoption is not usually a problem of training but rather of design trust. Users stick to spreadsheets since they trust their own manual calculations more than those produced by a black box system. The most successful modification in my delivery process has been to move from presenting finished products to co-designing logic together with end-users right from the start. In my work on big systems, I always start with asking for examples of actual spreadsheets that shop floor managers or procurement heads use when performing day-to-day operations. By converting local formulas and hidden data points into the dashboard, we remove a valid basis for using the spreadsheet. Effectively, we transfer mental models into the system. This helps to combine the visions of the IT director about governance and the operations director regarding functionality. When the dashboard reflects the specific logic the team utilizes for running the business, resistance to the change decreases significantly. To ensure that the dashboard is incorporated into everyday operations, I focus on building one crucial feature that a usual spreadsheet cannot provide, e.g., real-time drill-downs into warehouse stock or alerts about vendor lead time changes. Once a user realizes that the system can send him alerts about a bottleneck long before he opens the file, the spreadsheet becomes a liability rather than a safety measure. The primary goal is to demonstrate that the dashboard is not simply a reporting tool but an operational asset that adds immediate tangible value that cannot be achieved through manual work. --- ### Run Pipeline Calls From the Screen Sore subject. The pipeline dashboard, built to track investor conversations for our founder clients, lost to a spreadsheet twice before it held. Both times we launched it with a walkthrough and a link. People nodded and were back in the spreadsheet by the afternoon. The third time we announced nothing. The Monday pipeline call simply ran off the dashboard, screen shared, with no spreadsheet open anywhere. If your conversation was not on it, you had nothing to talk about that week. I am fairly sure the dashboard was never the problem. The spreadsheet lives on in someone's drive (we do not ask). --- ### Turn Viewers Into Contributors The key change that made the dashboard a routine tool was turning passive viewers into active contributors. Early versions were reviewed by people who worked closest to the numbers. They were asked to identify decisions delayed by late or hard-to-reconcile information. Their examples then guided the order of improvements. The dashboard was also introduced through a regular decision calendar, giving each view a clear purpose on a specific day. This structure made using it part of the workflow rather than an extra instruction. Managers reinforced the habit by asking questions the dashboard was designed to answer. When someone brought a spreadsheet, the response was to explore whether the dashboard was missing an important signal, keeping adoption collaborative and improvements tied to daily work. --- ### Replace Weekly Files With Five Numbers The change that worked for me was introducing the dashboard inside a meeting that already existed. Nobody got a training session or a launch email. The weekly review that used to run off a spreadsheet just ran off the dashboard instead, and the spreadsheet stopped being passed around. Spreadsheets win because they're familiar and everyone trusts their own copy. So I'd build the first version around one question the team already argues about, like which lead sources are worth more budget. If the dashboard answers that faster than the sheet does, people use it. If it needs a walkthrough first, they quietly open the old file. Two habits matter a lot. I let people check the dashboard's numbers against their spreadsheet for the first couple of weeks, because that's how trust gets built, and I'd rather they do it out loud than in secret. And I stop updating the spreadsheet on a set date, so there's one place the numbers live. I also keep the first dashboard small. Five numbers that drive a decision beat thirty that describe the business. People add more once they're using it, and they ask for the additions themselves, which tells you it's become part of how they work. --- ### Expose Uncertainty and Close Correction Loops I helped colleagues move toward a dashboard by making uncertainty visible instead of hiding it behind polished totals. Where figures depended on incomplete information or changing assumptions, the screen included a confidence note and a clear update date. That honesty was important because spreadsheet users often distrust tools that appear overly certain. The meaningful change was establishing a regular correction loop. When someone found an inconsistency, the issue was acknowledged, resolved, and briefly documented so others understood what changed. This created confidence that feedback improved the dashboard rather than disappearing into a request queue. Over time, colleagues relied on it because it became a transparent shared record. The spreadsheet was no longer the safer option for verifying what the organization believed at that moment. --- ### Place an Exception Queue Beside Metrics Familiar spreadsheets are workarounds for unanswered questions. I have seen adoption improve when teams map the spreadsheet's hidden job, annotating an exception, comparing a trend, or preparing an explanation. The new view must absorb that job before behavior changes. Otherwise, colleagues export data, rebuild context, and conclude the spreadsheet is more useful. A useful change was placing a small exception queue beside headline metrics. It showed why a number moved, who could validate it, and when the decision was due. That made the dashboard a shared work surface, not a scorecard. It became routine because it reduced follow-up messages and prevented competing versions of risk from forming in personal files. --- ### Build for Routine Stock Allocation Twelve years running analytics for twelve years, and I've built several dashboards nobody used. People go back to spreadsheets not because they're familiar. It's that a spreadsheet lets them ask a question you didn't anticipate, and a dashboard mostly doesn't. If the answer someone needs is one cut away from what you built, they'll export it and do that cut themselves, and now they're back in Excel permanently. What changed things was building the first version around a decision someone made regularly, not around a topic. Not a sales dashboard. A view for the Monday call where stock gets reallocated, built with the person who runs that call. It covered less and got used because it answered the question being asked, rather than being available for general questions. The others still exist. Nobody opens them, and I've stopped maintaining two. --- ### Use Plain Notes in Growth Sessions The mistake is treating adoption as a training problem when it is often a matter of trust. People return to spreadsheets when they can recreate the logic, adjust figures, and explain them during meetings. We introduced a dashboard alongside a plain-language decision note to make its purpose clear. The note explained what each metric included, excluded, and which questions it could not answer. The most important change was replacing a broad launch with a recurring decision. We began each weekly growth review with the same dashboard views. Spreadsheet attachments were discussed only when they revealed data quality issues. This helped separate number checking from decision-making, making the dashboard familiar through regular meeting habits rather than promoting it as a new tool. --- ### Recruit Skeptics as Operational Testers Data products gain staying power when the people closest to execution can influence the questions they answer. Senior leaders often request summary metrics, but adoption depends on whether coordinators can identify a stalled handoff before it affects a client relationship. That distinction determines whether a dashboard is opened daily or only before leadership reviews. I changed the rollout model by recruiting a group of skeptical operators as design reviewers. Their job was not to approve visual layouts, but to bring exceptions that had previously required calculations. Every scenario became a test case before release. The result was a tool shaped by operational friction, and those reviewers became peer advocates for adoption. --- ### Automate the Most Painful Daily Task Most marinas we work with come from spreadsheets, paper and a lot of phone calls. I've learned that people don't go back to a spreadsheet because they love it. They go back because it still holds something the new tool doesn't, or because it still feels faster for the one job they do every day. So the change that works is moving the most painful job first and making it clearly better. For marinas that is usually invoicing berth holders and keeping track of who has paid. Once invoices go out and payments register automatically, nobody needs to update the spreadsheet anymore, and it quietly stops being used. The other piece is showing the answer people check most often on the first screen. A harbourmaster at Arhus Nordhavn told us what he values most is seeing berth availability and guest data at a glance. If the new tool answers the daily question faster than the old file did, you don't have to argue for adoption. --- ### Silence False Alarms and Restore Trust In our experience at Streamrise, people abandon a dashboard less because it is unfamiliar and more because it cries wolf. So the change we made to our internal dashboard was to make it go quiet when there is nothing to do. On 4 October our owner summed up the problem in one sentence: the warnings are always red, and yet there is never anything for me to do. That is the moment a dashboard dies, because the person learns to stop looking, and the one real warning is lost among the permanent ones. We went through every warning that was permanently lit: - A server capacity gauge used a formula that could exceed 100%. It was showing 116%, which is impossible. It was replaced with a direct measurement taken every 30 seconds; the real figure was about 44%. - A delivery-quality flag, once set, was never cleared by anything. It now only counts problems from the last 48 hours. - A "thin margin" warning kept firing for four services whose margins the owner had already reviewed and accepted. We added a "margin checked" button that records the accepted markup. The warning stays silent unless the markup later drops below that level. - A low balance with an outside SMS provider was buried inside a generic "system errors this hour" count. It got its own red tile with the actual balance, because it needed a different action: someone has to top it up. What I would tell anyone introducing a dashboard: 1. Every tile needs a defined "nothing to do" state, and you should verify it actually reaches it. 2. If a number can be impossible, it will be trusted for nothing else either. Check the formula before the design. 3. Let people acknowledge a known, accepted condition, and bring it back automatically only if it gets worse. 4. Write the warning as the concrete fact and the action, not the name of a metric. Spreadsheets win by default because people trust numbers they built themselves. A dashboard earns the same trust by being right when it is calm, not by having more charts. --- ### Let Shared Charts Explain Choices I introduce a dashboard around a decision colleagues already need to make, starting with the question that sends them back to a spreadsheet. We look at the relevant comparison together on one chart. Reproducing the same rows with a prettier interface doesn't change where people think the work happens. If a result surprises them, they should be able to see where it came from and what each measure means before they reach for an export. At Ronas IT, I maintain a warehouse that brings operational data into BigQuery. We build departmental marts with dbt and view them in Metabase. For one leadership chart, we changed how we presented annual commercial utilization by adding a second series: the margin between earnings from a person's commercial project hours and what that person was paid. The audience read the chart more positively with both series in view than they had expected from utilization alone. I wouldn't use that margin as an objective score of individual contribution, especially for senior engineers. That is the kind of introduction I would use for a new data product: start with a recurring call, show the people making it how the chart answers their next question, and let them challenge the definition of the measures. If the comparison they need is missing, I would change the view and return to the same decision rather than ask them to learn another interface in the abstract. The test is whether they can make and explain the call from a shared chart. A login count can't tell me that. --- ### Route Uncertain Cases to Human Review A data product needs to make a real decision easier, including the awkward cases. In QuickIntell's healthcare workflows, a strong model output was not enough to earn operational trust. Teams needed to understand the inputs, the uncertainty and when a person should take over. We built around exceptions: extract and organize the information, flag missing or conflicting data, and route uncertain cases for human review with a traceable history. That made the output useful as a starting point for work instead of another result staff had to reconstruct from scratch. For a new dashboard, I would apply the same lesson. Start with the decision colleagues already make and the information they currently gather to make it. Show the source, the unresolved issue and the next responsible person. Involve the people doing the work because they know the edge cases. If the new product removes repeated checking and preserves a clear way to challenge its output, adoption has a practical reason. A cleaner chart alone does not remove the need for a familiar spreadsheet. --- ### Show Benefits and Simplify Adoption Sometimes introducing new software into an existing team can be really challenging, especially if the team is non-technical. Leading with the benefit tends to speed up onboarding. It's important for person to know why they should care to use the software. The first thing to do is to show how the product can help them, for example, if it can speed up the work, enable new things to do, or reveal data that would otherwise be invisible. All of those things tend to get people excited and motivated to start using a new product. Another thing is to make sure that software is easy to use. When picking a ready solution, it comes down to choosing one that is not confusing, with good UX. If you have more control, for example when creating the dashboard, it's extremely important to make it as simple as possible. Many people overestimate how much effort users are willing to put into adopting new software. The final method, when others fail, is just a task from a superior to adopt new technology. This is the worst one, as I think it's best for people to use software they like and want to use. However, the use of some software is just necessary, and many programs are adopted into companies this way. For example, with some data policies, like SOC 2, using google sheets for sensitive data might not be viable, and its necessary for all employees to use a specialized internal tool, that does not share data to third parties. When I was developing internal tools for Huawei, showing the benefit was usually enough for wide adoption across the team. When we onboard large companies onto kellota, we try to rely only on showcasing benefits and on the ease of use. In rare cases, where some employees are hesitant to adopt our software, we showcase the benefits to the manager, and they convince the employee. For example, sometimes some employees still prefer pen and paper and are hesitant to switch to an app for tracking hours. But because the app calculates complex salaries automatically, it saves management so much effort that they persuade employees to change how they work. --- ### Surface Stalled Handoffs Across Teams Colleagues rarely abandon spreadsheets because of loyalty to rows and columns. They abandon new tools when the tool demands duplicate entry while spreadsheet does practical work. In litigation, practical work is often triage. Which file needs a call, a record request, a liability follow-up, or immediate attention before a deadline changes case posture? We gained traction by limiting the dashboard to decisions that required coordination across roles. It drew from existing case activity and highlighted stalled handoffs instead of asking everyone to maintain a second narrative. The introduction succeeded because it removed a daily reconciliation task. People used it because it saved time when responsibility could become unclear. --- ### Solve One Manager's Monday Problem Most dashboards die the same way. Someone spends weeks building them, sends a link in Slack, gets a few "looks great" replies, and then everybody goes back to their spreadsheets. I've watched it happen at two companies now. The tool isn't the problem. The rollout is. At Softline Solutions I built a self-serve reporting layer on top of BigQuery for about 1,500 client accounts. Account managers had been pulling data through manual SQL exports and pasting numbers into Google Sheets. It worked, sort of. But it was slow, error-prone, and ate 80+ engineer-hours a month in support requests. So we built dashboards in Looker. Nobody used them at first. Here's what changed that. I stopped doing group demos. Instead I sat with three account managers one-on-one and asked them to show me their actual Monday morning workflow. I watched where they opened a spreadsheet, where they copy-pasted, where they spent five minutes waiting for a query. Then I showed them how to get the same answer from the dashboard in under a minute. That's it. No slide deck, no feature tour. Just "here's the thing you already do, but faster." Those three people became the ones who told everyone else. The second thing that worked was making the old way harder, gradually. We didn't shut down the legacy SQL access overnight. But we did stop maintaining certain manual report templates. When someone asked me to update the Q3 revenue sheet, I'd say "that number is live on the dashboard now, I can show you where." It's a gentle nudge, not a wall. I also built a "last refreshed" timestamp into every dashboard panel. Sounds small. But it solved a trust problem. People didn't believe the numbers were current (fair enough, our old reports were often stale by days). Seeing "updated 4 minutes ago" right there on screen made a real difference. At MyTona, working on analytics for Cooking Diary (22M+ downloads), I learned the same lesson from the other side. Our game designers had custom Tableau dashboards for player retention. The ones that got adopted were always the ones built with a specific person's question in mind, not the ones built to "give visibility." If nobody's asking the question your dashboard answers, it won't get used. My short version: don't launch a dashboard. Solve one person's problem with it, then let that spread. People adopt tools that save them time today, not tools that might be useful someday. Timur Rakhmatullin, Senior Software Engineer, Softline Solutions --- ### Link Summaries to Detail Pages and Follow-Ups I introduce a data product through a recurring decision the team already has to make. The person opening it should be able to inspect the evidence and continue into the work. Our internal Command Center at Market Brew provides a practical example. During the initial weekly-report review, a business colleague questioned the totals and clicked through to investigate. The link opened the general pipeline, without the date-range and salesperson controls needed to see exactly what the report counted. Another discrepancy exposed historical activity being counted in a later period because the record had been updated then. We changed the report so each metric opens its matching historical rows with the same stage and reporting dates. We added date and salesperson filters, sorting and export, and separated the date a milestone happened from the time it was recorded. That made the report usable as an entry point to evidence the colleague could inspect. The rollout change was to put that view into a regular working routine: a Monday-morning email covering the completed week, linked directly to the underlying Command Center records. The introduction could focus on a concrete task: review the week, question a count, open the relevant records and determine the next action. My advice is to make the first use about one real decision. Carry the report's context through the links and any export, and fix the friction colleagues encounter while checking it. The useful connection is between the summary, the evidence and the next action. That gives people a reason to return to the data product as part of their work. --- ### Start With Priorities and Preserve Traceability Spreadsheets win by default because people trust them. They built them, they know where every number came from, and they can change them. A new dashboard has to earn that trust, and most fail because they launch as a replacement for the spreadsheet instead of an improvement on it. At Fuselab Creative, we design dashboards for enterprise and regulated teams, and the change that made the biggest difference to adoption happens before launch: we start with the decision, not the data. In discovery, we ask each role one question: "What do you open your spreadsheet to decide?" Then we design the first screen around those three or four recurring decisions, and cut everything else back to a second layer. The second change is to keep the spreadsheet's strengths. Every number on the dashboard should be traceable to its source in one click, and users should be able to export what they see. When people know they can check the math, they stop going back to their own files to verify it. Finally, we introduce it inside an existing routine, such as the weekly ops meeting or the morning status check, instead of a separate training session. If the team uses the dashboard to run a meeting it already holds, it becomes the shared reference within a few weeks. --- ### Migrate History From Source Records We stopped introducing dashboards as a separate product. The figures have to come out of the documents people already create in their daily work. For an industrial metalwork company, margin per job is computed from the time entries and purchase lines booked against that job, so the planned versus actual view updates as the work is recorded. Nobody has to export data to a spreadsheet to know where a job stands. The change that made it stick was removing the reason to keep the spreadsheet. Spreadsheets survive when they hold something the new tool does not, usually history. So we migrate the history first: in that project, 7,500+ jobs, 4,800+ quotes, 54,000+ time entries and 19,000+ purchase lines. When the dashboard shows the past correctly, people trust it for the present. A dashboard bolted on top of data that lives elsewhere ends up being checked against Excel, and then replaced by it. ## Related - [Sunset Dashboards and Datasets Without Eroding Trust](https://informaticsmagazine.com/qa/sunset-dashboards-and-datasets-without-eroding-trust.md) - [How Data Teams Sunset Dashboards Without Drama](https://informaticsmagazine.com/qa/how-data-teams-sunset-dashboards-without-drama.md) - [Data Teams Share Onboarding Practices That Build Context Faster](https://informaticsmagazine.com/qa/data-teams-share-onboarding-practices-that-build-context-faster.md) - [How Data Teams Make Safer Decisions About Sensitive Information](https://informaticsmagazine.com/qa/how-data-teams-make-safer-decisions-about-sensitive-information.md)