Hexion’s Fix: 3 Patient Tech Adoption Traps That Undermine Real-World Use

Trap 1: Over-Engineering Features at the Expense of Usability

Many patient-facing technology projects begin with ambitious feature lists: chatbots, medication reminders, symptom trackers, secure messaging, lab result viewers, and more. The logic seems sound—offer everything a patient might need to manage their health. Yet in practice, this approach often backfires. When a mobile app or patient portal is packed with dozens of functions, the core tasks that patients need to perform (like scheduling an appointment or viewing a test result) become buried under complexity. We have seen projects where initial patient engagement rates hovered above 70% during pilot testing, only to drop below 20% after general launch. The cause was not a lack of functionality but an excess of it, creating a steep learning curve that frustrated users.

The Feature Creep Problem: A Composite Scenario

Consider a typical scenario: A mid-sized health system decides to build a patient engagement platform. The product team collects input from physicians, nurses, IT, and administrators, each group requesting different capabilities. The final product includes a dashboard with 15 tiles, a chat window, a medication list, a care plan viewer, and a notification center. During usability testing with a small group of tech-savvy patients, feedback is positive. But when rolled out to a broader population—including older adults and those with limited digital literacy—the results are stark. Patients report feeling overwhelmed. The most common complaint: 'I just want to see my appointment and message my doctor; everything else is noise.'

Why More Features Lead to Less Engagement

The underlying issue is cognitive overload. When users face too many choices, they often disengage entirely. This is not a new insight; it is well-documented in human-computer interaction research under the term 'Hick's Law,' which states that decision time increases logarithmically with the number of options. In a healthcare context, where users may already be anxious or unwell, this effect is magnified. The fix is to prioritize ruthlessly. Start by identifying the top three tasks that 80% of users will perform most often. Build for those tasks first, then iterate. Resist the urge to add features simply because competitors have them. Instead, validate each addition through real patient feedback, not internal assumptions.

Actionable Steps to Avoid the Trap

First, conduct a task analysis with a diverse group of end users (including those with varying tech comfort). Second, create a minimum viable product (MVP) that only includes the top three tasks. Third, measure engagement metrics (such as login frequency, task completion rates, and drop-off points) from day one. Fourth, plan a phased feature rollout—add new functions only after core usage stabilizes. Finally, establish a governance process where any new feature request requires evidence that it will not harm the core experience. This approach may feel slow to stakeholders eager for a full-featured product, but it dramatically increases the likelihood of sustained adoption.

In summary, the trap of over-engineering is common because it stems from a desire to please everyone. Yet by focusing on depth over breadth, you create a tool that patients actually want to use—and that clinicians can confidently recommend.

Trap 2: Ignoring Clinical Workflow Integration

The second trap is perhaps the most insidious: designing patient technology in isolation from the clinical workflows it is meant to support. Many health tech projects are developed by teams that understand patient needs but have limited insight into how clinicians operate day-to-day. The result is a product that patients may like but that clinicians find burdensome, leading to low recommendation rates and eventual abandonment. For example, a patient portal that allows direct messaging to physicians without routing rules or triage can flood primary care providers with non-urgent messages, increasing burnout. Similarly, a remote monitoring system that generates alerts for every minor deviation can desensitize clinicians to real emergencies.

A Composite Scenario: The Alert Fatigue Problem

Imagine a health system implementing a remote blood pressure monitoring program for hypertensive patients. The technology automatically transmits readings to a central dashboard, which then alerts the care team if any reading exceeds a threshold. Initially, clinicians appreciate the data. But soon, hundreds of alerts pour in daily, many from patients whose readings are slightly elevated due to stress, caffeine, or incorrect cuff placement. Clinicians start ignoring alerts, missing the one truly critical reading. The program is eventually labeled a failure. What went wrong? The technology was designed to maximize data capture, but it did not integrate with how clinicians triage and prioritize tasks. In their workflow, a single daily review of all patients combined with an escalation protocol for extreme values would have been far more effective.

Why Integration Matters More Than Features

Clinical workflow integration ensures that the technology reduces, rather than increases, the cognitive burden on care teams. When a tool does not fit into existing routines—like the morning huddle, the patient rooming process, or the discharge summary—it will be ignored. The root cause is often a lack of cross-functional design: product teams that do not include practicing clinicians as co-designers. The fix involves embedding workflow observation into the development process. Spend time shadowing nurses, physicians, and administrative staff. Understand their pain points, their existing tools, and their communication patterns. Then design the technology to complement those patterns, not disrupt them.

Steps to Integrate Clinician Workflows

Begin by mapping the current workflow for the condition your technology addresses. Use process-flow diagrams to identify bottlenecks and handoffs. Next, convene a small group of clinicians who can provide ongoing input, not just at the start but throughout development. Third, prototype the technology in a live clinical environment (even if just with one or two clinicians) and gather feedback. Fourth, ensure that the technology integrates with the electronic health record (EHR) system, as many clinicians rely on the EHR as their single source of truth. Fifth, define clear roles: who receives alerts, how they are triaged, and what the escalation path looks like. Finally, after launch, monitor clinician satisfaction metrics alongside patient engagement. If clinicians complain, treat that as seriously as patient complaints.

In short, technology that works for patients but frustrates clinicians is a dead end. True adoption requires designing for both user groups, with careful attention to how each interacts with the system.

Trap 3: Neglecting Ongoing User Support and Training

The third trap is assuming that once a patient technology is launched, users will naturally figure it out. In reality, even the most intuitive interfaces require ongoing support, especially for populations with lower digital literacy or those managing complex conditions. Without dedicated training and help resources, patients quickly become frustrated and stop using the tool. Similarly, clinicians need training not just on the technical operation but on how to incorporate the tool into their conversations with patients. Many health IT projects allocate minimal budget for post-launch support, viewing it as a one-time cost rather than an ongoing investment. This is a critical mistake.

A Composite Scenario: The Unsupported Portal

A large accountable care organization (ACO) launches a patient portal that allows secure messaging, appointment scheduling, and medication refill requests. The launch is accompanied by an email blast and a few posters in clinic waiting rooms. No in-person training is offered, and the help desk is staffed only during business hours. Within three months, portal usage plateaus at 15% of the patient population. A survey reveals that 40% of non-users tried to register but gave up due to confusing steps. Another 30% successfully registered but could not remember their password and had no easy way to reset it. The ACO spends six months and significant resources trying to boost usage through additional marketing, but the fundamental support gap remains. The portal is eventually replaced.

Why Support Is a Product Feature, Not an Afterthought

Effective support reduces barriers to adoption and builds trust. When patients know they can get help quickly, they are more willing to try new features. This is especially true for older adults, people with disabilities, and those who speak languages other than English. A comprehensive support strategy includes multiple channels: in-person training sessions, video tutorials, a live chat or phone line with extended hours, and easy-to-find FAQs. Additionally, support should be tailored to the patient's journey. For example, a new user might need help with registration, while an experienced user might need guidance on interpreting a lab result. Clinicians also need support, such as quick-reference guides on how to answer common patient questions about the technology.

Building a Sustainable Support Model

First, budget for support as a recurring expense, not a one-time cost. Second, design the technology with self-service capabilities, such as password reset, account recovery, and in-app tutorials. Third, train a dedicated support team (or partner with an existing help desk) that understands both the technology and the clinical context. Fourth, create feedback loops: track common support requests and use that data to improve the product. For instance, if many patients ask how to view a specific lab result, consider making that information more prominent in the interface. Fifth, offer training to clinicians before launch, and provide ongoing drop-in sessions as new features are added. Finally, measure support metrics (such as first-contact resolution rate and average handle time) and set targets for continuous improvement.

Neglecting support is a false economy. The cost of acquiring a new user is far higher than the cost of retaining an existing one. By investing in support, you not only boost adoption but also build a reputation for reliability that encourages word-of-mouth referrals.

How to Diagnose These Traps Before They Cause Failure

Recognizing these traps after they have caused damage is painful. The better approach is to proactively audit your patient technology project for signs of these pitfalls before launch. This section provides a diagnostic framework you can apply at any stage—whether you are planning a new project or trying to rescue an existing one. The framework focuses on three dimensions: feature scope, workflow integration, and support readiness. By scoring your project on each dimension, you can identify the highest-priority risks and take corrective action.

Diagnostic Dimension 1: Feature Scope Audit

Start by listing every feature your technology currently offers or plans to offer. Then, for each feature, ask: What percentage of users will need this in their first month? What is the complexity cost (time to learn, risk of errors) of adding this feature? Can the feature be deferred to a later release? If more than five features score high on complexity cost and low on early need, you likely have a feature creep problem. The corrective action is to create a phased roadmap that launches with no more than three core features. For example, a diabetes management app might start with blood glucose logging, medication reminders, and secure messaging—adding nutrition tracking and community forums only after core engagement is proven.

Diagnostic Dimension 2: Workflow Integration Audit

Interview at least three clinicians (from different roles: physician, nurse, medical assistant) who will interact with the technology. Ask them to walk you through a typical day and identify where the technology fits. If they cannot clearly describe how it will save time or improve care, you have an integration gap. Another test: map the patient journey from diagnosis to follow-up, and note every touchpoint where the technology is supposed to intervene. Are those touchpoints aligned with existing clinic processes? If a technology expects patients to log symptoms every morning, but the clinic only reviews data during weekly visits, the cadence is mismatched. The fix is to redesign the technology's interaction points to match real-world schedules and roles.

Diagnostic Dimension 3: Support Readiness Audit

Review your support plan: Is there a dedicated team? Is training available for both patients and clinicians? Are there self-service resources? If the answer to any of these is 'not yet' or 'we will figure it out later,' you have a support gap. A simple test: ask a non-technical friend (or a patient advisor) to try registering and performing a basic task. Time how long it takes and note where they get stuck. If the experience is frustrating, the support plan needs strengthening. Also, consider the demographics of your target population. If many users are over 65, plan for phone-based support with extended hours. If the population is diverse, offer materials in multiple languages.

By running these three audits early, you can catch problems when they are still cheap to fix. The cost of redesigning a feature post-launch is often 10 times higher than correcting it during design. Use this diagnostic as a regular check-in, not a one-time exercise.

Real-World Approaches to Sustained Adoption

Moving beyond traps and diagnosis, what do successful patient technology adoption programs look like in practice? While every context is unique, several common patterns emerge from projects that have achieved sustained real-world use. This section explores three approaches that have proven effective across different settings: the phased rollout, the clinician champion model, and the iterative redesign loop. Each approach addresses one or more of the traps described earlier, and together they form a comprehensive adoption strategy.

Approach 1: The Phased Rollout

Instead of launching to all patients at once, a phased rollout starts with a small group—often a single clinic or a specific patient cohort—and expands gradually. This allows the team to gather real-world feedback, fix issues, and refine the experience before scaling. For example, a health system deploying a remote monitoring program for heart failure patients might begin with 50 patients from one cardiology practice. Over three months, the team monitors engagement, alert accuracy, and clinician satisfaction. They discover that patients need a simpler device pairing process and that clinicians want a daily summary rather than individual alerts. After implementing these changes, the program expands to five clinics, then to the entire system. The phased approach reduces risk and builds momentum through early wins.

Approach 2: The Clinician Champion Model

Every successful technology adoption effort we have observed involves one or more clinicians who actively advocate for the tool. These champions are not necessarily the most senior physicians; they are the ones who believe in the technology's potential and are willing to invest time in training peers, answering questions, and providing feedback. To cultivate champions, identify clinicians who are early adopters of technology in their personal lives or who have expressed frustration with current workflows. Give them a formal role (e.g., 'digital health lead') with dedicated time and compensation. Encourage them to share success stories in staff meetings and newsletters. When other clinicians see a respected colleague using the technology and achieving better outcomes, adoption accelerates.

Approach 3: The Iterative Redesign Loop

Technology is never static; user needs evolve, clinical guidelines change, and new capabilities emerge. An iterative redesign loop treats the product as a living system that requires continuous improvement. This approach involves regular cycles of data analysis, user feedback collection, prioritization, and implementation. For example, a patient portal team might review usage analytics quarterly, conduct user interviews with both patients and clinicians, and then prioritize the top three improvements for the next release. The key is to keep the cycle tight—every few months, not annually—and to communicate changes clearly to users. This builds trust and shows that the organization is listening. It also prevents the accumulation of small frustrations that can lead to abandonment over time.

Combining these approaches creates a robust framework for adoption. Start with a phased rollout to minimize risk, leverage clinician champions to drive peer buy-in, and use iterative redesign to keep the tool relevant. While no single method guarantees success, this combination has consistently outperformed projects that rely on a big-bang launch and hope for the best.

Common Pitfalls and How to Avoid Them

Even with a solid plan, there are several recurring pitfalls that can undermine patient tech adoption. This section highlights five of the most common mistakes we have observed, along with practical mitigations. By being aware of these pitfalls, you can build safeguards into your project from the start.

Pitfall 1: Assuming One Size Fits All

Patient populations are diverse in age, health literacy, language, and technology comfort. Designing a single interface and support model for everyone is a recipe for exclusion. Mitigation: Segment your user base and tailor the experience where possible. For example, offer a simplified view for older users and a more detailed one for power users. Provide materials in multiple languages and at various reading levels. Use patient advisory groups to test designs with representative users.

Pitfall 2: Underestimating the Importance of Onboarding

The first experience a patient has with the technology sets the tone for long-term engagement. If registration is confusing or the initial tutorial is skipped, many users never come back. Mitigation: Invest in a guided onboarding process that holds the user's hand through the first few tasks. Use interactive walkthroughs, not just text instructions. Offer the option of live assistance during onboarding. Measure completion rates and drop-off points to continuously improve the flow.

Pitfall 3: Failing to Address Privacy and Security Concerns

Patients are increasingly aware of data breaches and may hesitate to share sensitive health information through a mobile app or portal. Mitigation: Be transparent about data practices. Explain what data is collected, how it is used, and what protections are in place. Display security certifications (like HIPAA compliance) prominently. Provide clear opt-in mechanisms and allow patients to control their data sharing preferences. Address privacy concerns in marketing materials and during onboarding.

Pitfall 4: Ignoring the Role of Caregivers

Many patients, especially older adults or those with chronic conditions, rely on family caregivers to manage their health. If the technology is designed only for the patient, it may not fit the caregiver's workflow. Mitigation: Consider caregiver access and permissions. Allow caregivers to be designated as proxies, with appropriate consent. Design features that support shared management, such as joint appointment scheduling or medication tracking. Interview caregivers during the design phase to understand their needs.

Pitfall 5: Measuring Success Only by Downloads

Many organizations celebrate the number of app downloads or portal registrations, but these metrics do not indicate real-world use. A patient may register and never return. Mitigation: Define meaningful engagement metrics from the start, such as weekly active users, task completion rates, and clinical outcomes (e.g., improved blood pressure control). Track these metrics over time and set targets that reflect genuine use, not just initial adoption.

By anticipating these pitfalls, you can design interventions that prevent them. A proactive approach is far more effective than scrambling to fix problems after launch.

Frequently Asked Questions About Patient Tech Adoption

Drawing from common questions we have heard from product managers, clinicians, and healthcare executives, this section addresses the most pressing concerns about patient technology adoption. The answers are based on practical experience and general industry knowledge, not on any single study. Always consult current best practices and regulatory guidance for your specific context.

Q: How long does it typically take for a patient technology to achieve sustained adoption?

There is no universal timeline, but many projects see initial engagement within the first three months after launch. Sustained adoption—where a significant portion of users continue to use the technology beyond six months—often requires ongoing refinement and support. In our experience, a well-designed phased rollout with clinician champions can achieve 40-50% sustained engagement within a year. However, this varies widely based on the patient population, clinical context, and the complexity of the technology. Focus on continuous improvement rather than a fixed deadline.

Q: Should we build our own patient portal or buy an existing platform?

This decision depends on your organization's resources, customization needs, and timeline. Building your own offers complete control but requires significant technical expertise, ongoing maintenance, and compliance with regulations like HIPAA. Buying a commercial platform often provides a faster time-to-market and built-in features, but may require compromises on customization. A hybrid approach—using a commercial platform with some customization—is increasingly common. Evaluate vendors based on integration capabilities, scalability, user experience, and support offerings. Pilot test with a small group before committing to a large-scale contract.

Q: How do we measure return on investment (ROI) for patient technology?

ROI can be measured in multiple dimensions: clinical outcomes (e.g., reduced readmissions, improved HbA1c), operational efficiency (e.g., fewer phone calls, reduced no-show rates), patient satisfaction scores, and revenue (e.g., increased patient volume or reimbursement for digital health services). Start by defining what success looks like for your organization. For example, if the goal is to reduce no-show rates, track appointment adherence before and after the technology launch. Calculate the cost savings from avoided no-shows against the total cost of the technology (development, licensing, support, training). Be realistic about timeframes; many benefits accrue over 12-24 months.

Q: What is the biggest mistake organizations make when implementing patient technology?

In our observation, the most common mistake is treating the technology as a standalone project rather than a change management initiative. The focus is on software features and timelines, while the human side—training, workflow redesign, clinician buy-in, ongoing support—is underfunded. This leads to low adoption and eventual abandonment. The fix is to allocate at least as much budget and attention to change management as to the technical build. Involve stakeholders early, communicate frequently, and celebrate small wins along the way.

Q: How do we handle patients who are not digitally literate?

Digital literacy varies widely, especially among older adults and underserved populations. Strategies include offering simplified interfaces (large fonts, minimal navigation), providing in-person or phone-based training, and involving family caregivers. Some organizations use 'digital navigators'—staff members who assist patients with technology during clinic visits. Also, ensure that the technology does not replace human interaction but augments it. For patients who cannot or will not use the technology, maintain alternative communication channels (phone, in-person visits).

These questions represent just a few of the concerns we hear regularly. The key is to remain flexible and listen to your users—both patients and clinicians—as you iterate.

Synthesis and Next Actions

Patient technology holds immense promise for improving health outcomes, but that promise is only realized when the technology is actually used in real-world settings. Throughout this guide, we have identified three critical traps—over-engineering features, ignoring clinical workflow integration, and neglecting ongoing support—that consistently undermine adoption. We have also provided diagnostic tools, real-world approaches, and answers to common questions to help you navigate these challenges. The overarching theme is that patient technology adoption is not primarily a technical problem; it is a human one. Success requires empathy for both patients and clinicians, a willingness to iterate based on feedback, and a commitment to continuous investment in support and training.

To put this into action, we recommend the following immediate steps. First, conduct a feature scope audit of your current or planned technology, using the criteria in the diagnostic section. Identify any features that could be deferred or simplified. Second, schedule workflow integration interviews with at least three clinicians who will interact with the technology. Map their current processes and identify where the technology can add value without adding burden. Third, review your support plan: is it adequately funded and staffed? If not, create a budget and timeline for building out support resources. Fourth, consider adopting a phased rollout approach, starting with a small pilot group. Fifth, identify potential clinician champions and engage them early. Finally, establish a regular cycle of measurement and iteration, using both quantitative and qualitative feedback to guide improvements.

Remember that adoption is not a one-time event but an ongoing process. The organizations that succeed are those that treat patient technology as a living tool that evolves with its users. They invest in relationships, not just software. They listen to complaints and act on them. They celebrate small successes and learn from failures. By avoiding the three traps outlined here and following the positive practices we have described, you can significantly increase the likelihood that your patient technology will achieve real-world use and, ultimately, improve patient health.