Category: Ideas & Perspectives
Abstract / Executive Summary
Digital systems are often introduced to improve public services, environmental management and community development. Yet the successful deployment of a platform does not necessarily mean that people will use it consistently or that it will become part of their everyday work. The gap between technical implementation and meaningful adoption remains one of the central challenges in digital development.
In this article, we examine what makes digital systems useful, accessible and sustainable for the people expected to use them. Drawing on research into participatory design, technology acceptance and digital inclusion, we explore the relationship between user involvement, local infrastructure, institutional capacity, trust and long-term ownership.
We also consider practical lessons from our work in digital government, environmental data management and field data collection in Papua New Guinea. These experiences illustrate why technical architecture must be considered alongside operational realities, particularly where connectivity is limited and systems need to be maintained by local institutions.
Our central argument is that adoption should be treated as a design and implementation objective from the beginning, rather than something expected to happen after deployment. A digital system creates lasting value when it responds to real needs, fits existing workflows, earns users’ trust and can be operated beyond the initial implementation period.
Keywords
Digital inclusion; participatory design; human-centred technology; digital government; community engagement; technology adoption; institutional ownership; sustainable digital development.
Main article
1. Introduction: The Gap Between Building a System and Getting People to Use It
A digital platform can be technically sound, professionally designed and successfully launched, yet still struggle to become part of everyday practice.
This is a familiar challenge in digital transformation. Organisations invest in software, databases, mobile applications and integrated information systems with the expectation that technology will improve efficiency, transparency and decision-making. However, the existence of a functioning platform does not automatically translate into meaningful use.
Consider a digital environmental monitoring system. It may provide sophisticated dashboards, geographical information and automated reporting. But if field officers cannot submit information reliably, local institutions cannot maintain the platform, or communities do not understand how their contributions will be used, its practical value remains limited.
The problem is not necessarily the technology itself. It may be the relationship between the technology and the people, organisations and processes surrounding it.
The International Telecommunication Union (ITU, 2025) estimates that 85% of people living in urban areas globally use the internet, compared with 58% of those in rural areas. In the Asia-Pacific region, the corresponding figures are 88% and 66%. These differences demonstrate why assumptions about universal connectivity cannot underpin every digital development initiative.
At Eywa Systems, we approach digital transformation through the relationship between technology, governance and the people responsible for using and maintaining digital systems. Our work across government digitalisation, environmental management, geospatial platforms and field data collection has reinforced a practical consideration: a system must function within the environment in which it is expected to operate.
This article examines how digital systems can be designed around that principle, and what organisations should consider when moving from technical delivery towards sustained adoption.
2. Understanding What Makes a Digital System Useful
2.1 Technology acceptance begins with perceived value
One of the foundational contributions to understanding technology adoption is the Technology Acceptance Model developed by Davis (1989).
The model identifies two important determinants of technology acceptance:
- Perceived usefulness: The extent to which individuals believe that using a system will improve their work or activities.
- Perceived ease of use: The extent to which individuals believe that using the system will require relatively little effort.
These concepts remain relevant to contemporary digital systems.
A platform may contain extensive functionality, but users are unlikely to embrace it if they cannot identify a practical benefit. Similarly, a system may offer valuable capabilities but remain difficult to use because its workflows are unnecessarily complicated.
For example, a field officer responsible for collecting environmental information may need to record observations, upload supporting evidence and submit reports. If the digital process requires significantly more effort than the existing approach without providing a clear benefit, resistance is understandable.
This suggests that usability cannot be evaluated independently of the task being performed.
The objective should not simply be to minimise the number of clicks. It should be to make the overall process more useful, reliable and manageable.
2.2 Adoption is an organisational issue as well as a technical one
The DeLone and McLean Information Systems Success Model provides a broader perspective by connecting system quality, information quality and service quality with system use, user satisfaction and net benefits (DeLone & McLean, 2003).
This is particularly relevant to public-sector and development systems.
A technically reliable platform may still produce limited benefits if the information it contains is incomplete, outdated or difficult to interpret. Likewise, good software may lose users when support arrangements are unclear or technical problems remain unresolved.
We therefore need to look beyond the interface and consider the complete environment in which a system operates.
For digital government, this includes institutional responsibilities, existing administrative procedures, data governance, staff capabilities and the availability of ongoing technical support.
A system becomes useful when these elements work together.
3. Designing With People, Not Simply For Them
3.1 Participation should begin before development
Participatory design places users and other relevant stakeholders directly within the design process.
Rather than asking people to evaluate a finished product, it involves them in identifying problems, exploring possible solutions, testing concepts and refining the resulting system.
A 2025 systematic review by Wacnik, Daly and Verma examined participatory design practices across different design disciplines. The authors identified several factors affecting the quality and equity of participation, including whether engagement occurs early or late, directly or indirectly, and continuously or only once.
This distinction matters.
Consulting stakeholders after the main technical decisions have already been made provides limited opportunities to influence the system. By contrast, involving them during requirements gathering can reveal practical needs that may otherwise be overlooked.
For instance, a government department may require a centralised reporting platform, while the officers responsible for entering information need a simple mobile interface. Communities may have different concerns altogether, particularly around accessibility, data collection and how information about them is used.
These perspectives are connected, but they are not interchangeable.
We should therefore avoid treating a single representative or institutional decision-maker as a substitute for understanding the different people who will interact with the system.
3.2 Participation must be meaningful
Inviting stakeholders to a workshop does not automatically make a design participatory.
Meaningful engagement requires opportunities for people to influence decisions. It also requires developers and implementing organisations to explain which suggestions have been incorporated, which have not, and why.
The Digital Principles, developed through collaboration among international development organisations, provide useful guidance. Their principles include designing with people, designing for inclusion, understanding the existing ecosystem, building for sustainability and establishing people-first data practices (Principles for Digital Development, n.d.).
These principles encourage a shift away from technology-led project design towards solutions shaped by the people and environments they are intended to serve.
In practical terms, we should ask:
- Who will use the system directly?
- Who will provide information to it?
- Who will depend on its outputs?
- Who may be excluded by its design?
- Who will be responsible for maintaining it?
The answers should influence requirements, architecture, interfaces, training and operational planning.
4. Designing for the Conditions People Actually Face
4.1 Connectivity cannot be an afterthought
Connectivity is one of the most important considerations when designing digital systems for remote and underserved communities.
The ITU’s 2025 findings show that internet access remains uneven across geographical and income groups. Even where mobile broadband coverage exists, affordability, service quality and digital skills affect whether people can use it meaningfully.
This has direct implications for system architecture.
A platform designed around continuous internet access may perform well in a capital city but become unreliable when used by field teams operating in remote locations.
Offline-first architecture offers one approach. It allows users to complete essential tasks without a continuous connection, storing information locally and synchronising it when connectivity becomes available.
This is particularly relevant to environmental monitoring, agricultural programmes, natural resource management and community-based data collection.
Research from rural Liberia provides a practical example. A study published in BMC Medical Informatics and Decision Making documented an electronic data collection platform designed for community health workers operating in areas with limited connectivity and access to electricity.
The programme involved 317 community health workers and 28 supervisors. It demonstrated the feasibility of collecting and transferring data through offline mechanisms, including Bluetooth-based transfer. The researchers reported that the system remained operational more than four years after its initial pilot, subject to continued hardware support (2020).
The case illustrates an important point: infrastructure constraints should shape system architecture from the outset, rather than being treated as problems to resolve after implementation.
4.2 Design for different levels of digital capability
Accessibility involves more than whether someone can physically open a website or application.
Users may have different levels of digital literacy, language proficiency, familiarity with administrative processes and experience using mobile devices.
A complicated interface can create unnecessary barriers, particularly for people who use digital tools infrequently.
Practical design considerations include:
- Clear language and familiar terminology.
- Consistent navigation and predictable workflows.
- Interfaces suitable for mobile devices.
- Minimal unnecessary data entry.
- Appropriate language options.
- Clear feedback when information is submitted or saved.
- Accessible design for users with disabilities.
These decisions may appear relatively small from a technical perspective. Collectively, however, they influence whether a system fits into people’s everyday activities.
We should also distinguish between the needs of different user groups. A public-facing information portal, an administrator dashboard and a field data collection application may belong to the same digital ecosystem, but they should not necessarily share the same interface or workflow.
5. Building Trust Through Data Governance and Transparency
A digital system often asks people to provide information about themselves, their organisations, their livelihoods or their surrounding environment.
Whether users are willing to contribute that information depends partly on whether they understand how it will be handled.
Trust therefore needs to be considered as part of system design.
Questions of data ownership, access permissions, privacy, security and accountability should be addressed before information is collected at scale.
For community-based programmes, these considerations are particularly important where data may concern land use, natural resources, livelihoods, environmental impacts or social safeguards.
A system should make it reasonably clear:
- What information is being collected and why.
- Who can access the information.
- How the information will be stored and protected.
- Whether information will be shared with other institutions.
- How errors can be corrected.
- How concerns or grievances can be raised.
Poorly defined data governance can undermine confidence even when the technical platform functions correctly.
The World Bank’s Principles on Identification for Sustainable Development similarly emphasise inclusion, responsive system design, privacy, user rights and institutional accountability (World Bank, 2019).
For us, this reinforces the need to treat security and governance as foundational requirements, rather than technical features added towards the end of development.
6. From Deployment to Ownership: Making Systems Sustainable
A digital system should not depend indefinitely on the external team that originally developed it.
This is particularly important in government and development programmes, where project funding may be time-limited but institutional responsibilities continue.
Sustainability requires more than transferring software or providing a user manual. The organisation responsible for the system needs sufficient knowledge, authority and resources to operate it.
Our implementation approach therefore incorporates several connected activities:
- Discover and assess: Understand existing processes, stakeholder needs, infrastructure and constraints.
- Design and plan: Translate requirements into functional specifications, workflows and acceptance criteria.
- Build and configure: Develop the solution through iterative implementation.
- Test and validate: Conduct functional, integration and user acceptance testing.
- Deploy and enable: Prepare the operational environment and provide user training.
- Monitor and improve: Review performance and incorporate feedback.
- Transfer and sustain: Provide documentation, knowledge transfer and operational handover.
These stages are not simply project management milestones. They connect technical delivery with the conditions required for continued use.
Training is particularly important. Different users require different forms of support. End users need to understand how to perform their tasks, while administrators need to understand system configuration, access management, data maintenance and operational responsibilities.
Documentation should also reflect actual working procedures rather than simply describe technical features.
Our experience supporting digitalisation across six Papua New Guinea government agencies under the EU-funded FCCB programme illustrates the institutional dimension of this approach. The programme included digital platforms, government websites and environmental systems. Training activities recorded more than 190 participations across the participating agencies from 2024.
The broader lesson is that institutional capacity should be developed alongside the technology. A system’s long-term value depends partly on whether the organisation using it can continue operating it after the implementation team has handed it over.
7. What Our Implementation Experience Teaches Us
Our work in Papua New Guinea provides several practical examples of how system design needs to respond to operational requirements.
One example is Eywa Data OS, our offline-first field data collection and survey platform, deployed for GCF REDD+ field work in Simbu Province.
The platform allows information to be recorded on a device and synchronised when connectivity becomes available. This approach addresses a specific operational constraint: field data collection cannot always depend on a stable internet connection.
It illustrates why the ability to complete essential tasks offline should be considered a core requirement in relevant environments.
Another example is the Nationwide SME Database developed for the Global Green Growth Institute in Papua New Guinea. The implementation includes survey instrument design, enumerator training, a field data-quality regime, a Django/PostGIS database, a web dashboard and a mobile field application.
The project demonstrates that a national information platform involves more than database development. The quality of the resulting information also depends on how data is collected, how enumerators are prepared and how information is checked before it becomes part of a national repository.
A further example is the Climate Project Pipeline Repository developed for the Pacific Community (SPC). The platform brings together structured project information, dashboards, geospatial views and role-based access. User acceptance testing was completed in August 2026, with operational handover scheduled for November 2026.
These examples illustrate different aspects of implementation: field usability, data collection quality and institutional information management.
They should not, however, be interpreted as independent evidence of community-wide adoption. That would require additional information about actual user behaviour, usage patterns and outcomes over time.
What they do demonstrate is the importance of connecting technical architecture with the practical requirements of the people and institutions expected to operate a system.
8. Measuring Adoption: Looking Beyond the Launch Date
A system’s launch is an implementation milestone, not a sufficient measure of success.
Organisations should establish adoption indicators that reflect how the platform is actually used.
Possible measures include:
| Dimension | Suggested indicators |
| Active usage | Number and proportion of intended users actively using the system |
| User experience | User satisfaction, task completion time and usability feedback |
| Operational reliability | System availability, error rates and successful data synchronisation |
| Data quality | Completeness, accuracy, consistency and timeliness of submissions |
| Institutional ownership | Number of functions managed independently by the responsible institution |
| Sustainability | Continued usage, maintenance capacity and support requirements |
| Inclusion | Participation across relevant geographical, demographic and user groups |
These indicators should be established against an appropriate baseline and reviewed over time.
Importantly, usage volume alone can be misleading. A system may record frequent logins because staff are required to use it, even when it creates little practical value.
Conversely, a specialised platform may be used by a relatively small group of authorised users but deliver substantial institutional benefits.
Evaluation should therefore consider the purpose of the system, its intended users and the outcomes it is expected to support.
9. Challenges and Limitations: Adoption Cannot Be Designed Into Software Alone
Even a well-designed system faces challenges that cannot be solved through interface improvements alone.
Organisational resistance, staff turnover, limited budgets, competing institutional priorities and unclear responsibilities can all affect adoption.
Participatory design also has limitations. Stakeholder engagement can be expensive and time-consuming, and the people who participate may not represent the wider population. Wacnik et al. (2025) highlight how different participation approaches can influence equity and whose perspectives shape design decisions.
There is also a risk of assuming that users always know which solution will work best. Users understand their experiences and constraints, but translating these insights into secure, scalable and maintainable architecture requires technical and institutional expertise.
The challenge is therefore to combine local knowledge with sound engineering and governance.
Nor should digital technology automatically replace existing processes. In some environments, paper-based procedures, face-to-face communication or assisted digital services may remain necessary.
A hybrid approach can be more appropriate, particularly during transition periods or where digital access is uneven.
Ultimately, adoption is influenced by factors beyond the control of the development team. Good design improves the conditions for adoption; it cannot guarantee it.
10. Implications for Digital Development Practitioners
For governments, development organisations and technology providers, designing systems that people actually use requires a change in how success is defined.
The focus should move from delivering technical outputs towards establishing functioning systems that serve real institutional and community needs.
We believe several practical priorities follow from the evidence and implementation experience discussed above.
First, involve users early enough to influence requirements and continue engaging them throughout development.
Second, design for actual infrastructure conditions, including unreliable connectivity, device limitations and different levels of digital capability.
Third, treat information quality, privacy, security and accountability as essential parts of the architecture.
Fourth, allocate sufficient resources for training, documentation, maintenance and institutional handover.
Finally, evaluate adoption over time. A successful launch should mark the beginning of operational learning, not the end of the implementation process.
These priorities are particularly relevant to digital government and environmental management, where platforms frequently need to connect national institutions, technical specialists and people working in geographically dispersed locations.
Conclusion
Designing digital systems that communities actually use requires more than technical capability. It requires an understanding of the people, institutions and conditions that shape how technology is experienced in practice.
Research on technology acceptance and participatory design demonstrates the importance of perceived usefulness, ease of use and meaningful stakeholder involvement. Evidence on digital inclusion highlights the continuing influence of connectivity, affordability and digital skills. Practical implementation experience reinforces the need for offline capabilities, reliable data processes, training and institutional ownership.
Our experience in Papua New Guinea has shown why these considerations need to be addressed together. Field data collection, national information platforms and government digitalisation each present different requirements, but all depend on technology working within real operational environments.
The measure of a successful digital system should therefore extend beyond whether it has been developed and deployed. It should consider whether people can use it, whether institutions can manage it, whether the information it produces can be trusted and whether it continues to provide value over time.
A digital system is not successful simply because it works. It is successful when the people and institutions it was designed to serve can make meaningful use of it, maintain it and rely on it.
References
- Davis, F. D. (1989). Perceived usefulness, perceived ease of use, and user acceptance of information technology. MIS Quarterly, 13(3), 319–340. https://doi.org/10.2307/249008
- DeLone, W. H., & McLean, E. R. (2003). The DeLone and McLean model of information systems success: A ten-year update. Journal of Management Information Systems, 19(4), 9–30. https://doi.org/10.1080/07421222.2003.11045748
- International Telecommunication Union. (2025). Measuring digital development: Facts and Figures 2025. https://www.itu.int/itu-d/reports/statistics/facts-figures-2025/
- Kenny, A., Gordon, N., Downey, J., Eddins, O., Buchholz, K., Menyon, A., & Mansah, W. (2020). Design and implementation of a mobile health electronic data capture platform that functions in fully-disconnected settings: A pilot study in rural Liberia. BMC Medical Informatics and Decision Making, 20, Article 39. https://doi.org/10.1186/s12911-020-1059-6
- Principles for Digital Development. (n.d.). Principles for Digital Development. https://digitalprinciples.org/
- Wacnik, P., Daly, S. R., & Verma, A. (2025). Participatory design: A systematic review and insights for future practice. Design Science, 11, e21. https://doi.org/10.1017/dsj.2025.10009
- World Bank. (2019). Principles on identification for sustainable development: Toward the digital age. https://id4d.worldbank.org/guide/1-principles