Giving someone access to information is not the same as giving them something useful.
That distinction gets collapsed constantly in product development, and the consequences show up in two places with striking regularity: healthcare technology and business intelligence. Both fields have spent the last decade building access layers, portals, dashboards, self-service reporting tools, and both are dealing with the same downstream problem. The access exists. The value does not always follow.
Understanding why requires looking at what these systems are actually asking users to do, and whether the design supports that or just assumes it will happen.
Patient Portals and the Gap Between Available and Usable
The patient portal has become a standard feature of modern healthcare delivery. Most health systems have one. Meaningful use requirements pushed providers to build them, and millions of patients now have login credentials for a platform that shows them their lab results, appointment history, and medication lists.
Usage rates tell a different story than availability rates. A significant portion of patients who have portal access rarely or never log in after the initial setup. Among those who do, a common complaint is that the information they find raises more questions than it answers. A lab result flagged as outside the reference range with no contextual explanation. A clinical note written in terminology calibrated for another clinician, not the patient reading it at home.
Patient portal development that actually improves engagement tends to approach the problem differently from the start. Rather than building a data display layer on top of the existing clinical record, the better implementations ask what a patient actually needs to do and design around those tasks. Scheduling a follow-up appointment. Understanding what their post-visit instructions mean in practical terms. Knowing whether a result requires action or is within expected variation for their condition. Those are the use cases that drive return visits to the portal, and they require deliberate design decisions, not just data access.
The portals that patients actually use tend to have shorter, plain-language summaries alongside clinical data, clear calls to action when something requires a response, and messaging features that make it easy to ask a question without calling the office. None of these are technically complex. They are prioritization choices that many implementations did not make because the goal was deployment, not adoption.
Why Tableau Alternatives Are Worth Taking Seriously
Tableau became the default answer to business intelligence visualization for long enough that evaluating other options started to feel unnecessary. It is powerful, it handles complex data relationships well, and most analytics teams have at least one person who knows it. Those are real advantages.
They are also exactly the conditions that produce vendor lock-in and shelfware. Tableau’s licensing cost is significant at scale, its performance on very large datasets requires infrastructure investment, and its learning curve means that in many organizations the tool gets used heavily by two or three analysts and ignored by the broader team that was supposed to benefit from it.
The alternatives to Tableau have matured considerably. Looker, now part of Google Cloud, works particularly well for organizations that want governed metrics and consistent definitions across teams, because it pushes logic into the data model rather than into individual reports. Power BI is the practical choice for organizations already running Microsoft infrastructure, with tighter integration into Teams and Excel workflows than any other option. Metabase sits at a different point on the spectrum: genuinely accessible to non-technical users for basic exploration, limited for complex analytical work, and priced in a way that makes broad deployment feasible without a significant budget conversation.
The right answer depends almost entirely on who is building the reports and who is reading them. A centralized analytics team serving a large organization needs different capabilities than a small company trying to give department heads visibility into their own metrics. Choosing based on feature comparison rather than actual user profile is how organizations end up with a powerful tool that sits mostly unused while people export to Excel anyway.
The Underlying Problem in Both Cases
Patient portals and data visualization tools are both, at their core, communication products. They exist to move information from where it lives into the hands of someone who needs to act on it. The technical challenge of building them is real but largely solved. The design challenge of making them work for actual humans in actual situations is where both categories continue to fall short.
The organizations that get this right tend to involve the end user earlier and more honestly than feels comfortable. Not in a focus group that validates existing decisions, but in actual testing with real tasks and real confusion surfaced without apology.
What users cannot do with your tool is more useful information than what they can.