Skip to the six system pressures ↓
Mobilized News · Feature and analysis · ICT and cybersecurity
Being connected should help people do something useful.
Technology people
can use.
Systems they can trust.
Why more devices, data and digital services do not automatically create public benefit—and how accessible design, open cooperation and clear responsibilities can build lasting digital capability.
Signals → Systems → Solutions → Action
The service behind the screen
People need a working service.
A new app is one possible tool.
A student needs to reach a lesson. A grower needs to coordinate a delivery. A resident needs to complete an application. A health worker needs accurate information. Each task depends on technology—and on much more than the screen in front of them.
The connection must work. The device must be usable. The service must make sense. Information must be handled appropriately, and someone must help when things go wrong.
ICT means information and communications technology: the networks, devices, software and services people use to communicate, create, store, process and exchange information. It includes physical infrastructure, digital tools and the arrangements that keep them operating.
These systems have opened valuable possibilities for learning, collaboration and public service. Yet an online form can still be inaccessible. A fast network can still be unaffordable. An organization can buy software and remain unable to move its own information to a different provider.
The lesson is practical: a technology purchase is only one part of a service. Whole-system design connects infrastructure with people’s needs, rights, skills, resources and public accountability. It asks whether people can actually accomplish the task, and whether the capability will endure.
Communities do not all need to build their own networks or host their own software. They need informed choices, appropriate expertise and workable relationships with the people supplying the service. Shared tools and open knowledge can help those choices become more realistic.
Digital progress means people gain useful capability—and a meaningful say in the systems they depend on.
Coverage is different from meaningful connectivity.
ITU’s 2025 reporting identifies continuing gaps in quality and affordability even as network coverage expands. A useful assessment asks about the connection people can obtain, the device they can use and the skills and support available to them. [1]
Follow the connections
Four connected functions.
One everyday experience.
A digital service depends on all of these functions. Improvements work best when the relationships between them are designed deliberately.
Connect
Provide suitable networks, reliable power and affordable devices and service. Design for the connection people actually have.
Complete the task
Build accessible, understandable services with relevant languages and workable support. Test whether people can finish independently.
Work together
Help authorized systems exchange necessary information through agreed formats, interfaces and rules. Preserve privacy and appropriate limits.
Maintain and improve
Fund skilled operation, updates, security, repair and recovery. Learn from users and keep responsibilities clear over time.
Across all four: governance and human rights.
Who decides what the service does? Who controls access and data? How can a person correct an error or challenge a decision? These questions belong alongside architecture, procurement and performance. The UN’s DPI safeguards framework makes that relationship explicit. [4]
Examine the design behind the outcome
Six pressures.
Practical ways forward.
Open a card to move from evidence to the design problem, its consequences and useful questions. The appropriate response depends on the service and community.
6 of 6 pressures
No matching pressures. Try a broader search or clear the filters.
01The connectivity problemA signal without meaningful accessNetwork coverage is a starting point. A usable connection is the outcome.ExploreClose→
02The inclusion problemServices people cannot comfortably useA digital service works only when people can complete what they came to do.ExploreClose→
03The dependency problemUseful tools that cannot work togetherCommunities need connections between systems—and realistic choices about suppliers.ExploreClose→
04The trust problemData collected without a clear public purposeUseful sharing begins with a reason, limits and accountability.ExploreClose→
05The reliability problemSecurity treated as a final add-onDependable service includes preventing, detecting and recovering from failure.ExploreClose→
06The capability problemA launch without a lasting serviceHardware and software need people, resources and care throughout their lives.ExploreClose→
What better design can make possible
Judge the system
by the capability people gain.
These are outcomes to design for and measure. A new platform, an open-source licence or a network launch does not establish them on its own.
Participation
More people can complete useful tasks.
Measure who can use the service, who needs help and who remains excluded. Include disability, language, affordability and device constraints.
Dependability
People can rely on the service.
Track interruptions, response times, recovery performance and successful task completion. Have workable alternatives for essential needs.
Privacy
Information serves a defined purpose.
Make necessary collection and sharing understandable. Establish limits, appropriate access and ways to correct mistakes or challenge misuse.
Choice
Changing tools becomes a realistic option.
Assess usable exports, documented interfaces, support and migration costs. Keep enough knowledge to make informed supplier decisions.
Local capability
Skills and useful knowledge endure.
Develop paid operational capacity and accessible training. Share methods, documentation and lessons so people can adapt and improve the service.
Better use of resources
The full lifecycle is considered.
Compare total operating costs, energy needs, support periods, repair and replacement. Choose equipment and services appropriate to the task.
Inclusion needs a route back in.
A person who cannot authenticate, loses a device or encounters an incorrect record still needs a way to obtain help. Provide accessible support and review processes. Participation should not depend on flawless technology or a person’s ability to navigate it unaided.
Documented approaches, useful lessons
Shared infrastructure.
Practical public value.
These examples show different layers of cooperation: connectivity, reusable software and data exchange. The cited organizations describe how their systems work; results depend on implementation.
Guifi.net: infrastructure held in common.
The Guifi.net foundation describes a shared telecommunications network involving users, service operators, organizations and public bodies. Its model includes arrangements for contributing to infrastructure and maintaining it. [7]
The lesson: cooperation can include the physical network, its operating rules and the economics of keeping it working.
The limit: shared infrastructure still needs technical skills, investment, appropriate permissions and reliable service operations. “Open” does not mean there are no costs.
DHIS2: shared tools, local implementation.
DHIS2 is an open-source platform for collecting, managing and analyzing data. The HISP Centre at the University of Oslo coordinates its core development through an international collaboration, alongside implementation partners. [8]
The lesson: institutions can share software development and knowledge while adapting implementation to their needs.
The limit: software alone cannot establish accurate reporting, effective service delivery or appropriate handling of sensitive information. Those require people and governance.
X-tee: connect systems with rules.
Estonia’s Information System Authority describes X-tee as a technical and organizational environment for data exchange. The underlying X-Road technology provides a distributed exchange layer with common management and trust arrangements. [9] [10]
The lesson: systems can exchange information without first merging all records into one central database.
The limit: the architecture does not decide which sharing is appropriate. Legal authority, permissions, data quality, oversight and security still matter.
Make the language useful
Open cooperation
needs clear distinctions.
These concepts can support one another, but they solve different problems. A credible proposal explains which it uses and why.
Open source
Software supplied under a licence that permits use, study, modification and redistribution under its terms. It can support shared development and adaptation. Hosting, security, support and maintenance still need resources.
Open standards
Shared technical specifications that help independently developed systems work together. Procurement should check actual compatibility, implementation quality and the conditions for using a standard.
Digital public infrastructure
Shared digital foundations that can support services across organizations, such as payment or data-exchange systems. Public benefit depends on access, governance, safeguards and dependable operation. [3]
Community capability
The people, skills, institutions and resources needed to choose, operate and improve a service. A community can strengthen that capability through partnerships without taking on every technical function itself.
Open cooperation does not require open personal data.
Share code, standards, documentation and appropriate learning resources. Protect private records and credentials. Interoperability should enable necessary, authorized exchange—not unrestricted access to everyone’s information.
A place for AI, with a defined job
Automate a task.
Keep responsibility visible.
Begin with the problem and compare available approaches. A simpler form, a better search tool or clearer information may address the need before an AI system is considered.
When AI is proposed, test it on representative tasks and users. Examine errors, privacy, accessibility, cost and the consequences of a wrong output. NIST’s generative AI guidance identifies risks including confident but incorrect outputs and provides a framework for managing them. [11]
Make clear when people are interacting with automation and how to reach a responsible person. For consequential services, design meaningful review, correction and challenge routes. Measure the quality of the outcome, alongside time saved.
A GPS for practical progress
Start with a real task.
Build lasting capability.
A school, community group, public institution or small business can begin at a manageable scale. Include the people using the service and those responsible for keeping it running.
- Step 01
Define the outcome.
Name a concrete need: completing an application, coordinating deliveries, reaching a lesson or finding reliable information. Identify who experiences the problem and how you will recognize improvement.
- Step 02
Map the full service.
Follow the task through connection, device, interface, data, staff and suppliers. Include power, support, security and offline or assisted alternatives. Locate the actual barrier before buying a tool.
- Step 03
Bring users and operators into the design.
Include people with different abilities, languages, resources and digital experience. Agree what information is needed, who controls it and how concerns will be handled.
- Step 04
Compare complete options.
Assess existing services, shared tools, open-source and commercial options. Compare accessibility, security, interoperability, operating costs, support, data export and the ability to change providers.
- Step 05
Pilot with clear responsibilities.
Set a limited scope, budget and review point. Name the service owner, provide training, establish appropriate permissions and test support and recovery. Protect essential access during the trial.
- Step 06
Measure and share what you learn.
Track task completion, exclusion, cost, reliability and user experience. Report limitations and failures as well as gains. Share reusable methods and documentation while protecting sensitive information.
Cooperation makes improvement travel.
Communities can share procurement questions, accessibility methods, training resources, code and lessons from real operation. Support the maintainers doing the work. Adapt what is learned to local institutions, languages and conditions.
Where connected media helps
Follow the technology story
beyond the launch.
An ICT story connects to education, food, health, energy, public decisions and livelihoods. Useful reporting asks what a tool helps people do, who can access it, how it is financed and what happens when it fails.
Mobilized can connect verified developments with the experience of users, engineers, accessibility specialists, public servants and community operators. Their knowledge helps explain what a product announcement leaves unanswered.
Share a practical question, a documented approach or evidence from a project. Clear reporting and open cooperation can make useful knowledge easier to find. Lasting capability comes from applying it through dependable services and accountable decisions.
Follow the evidence
Sources and further reading.
Primary sources support factual explanations and examples. Design recommendations are editorial analysis. Report years identify the evidence used; descriptions of capabilities are not independent guarantees of public benefit.
- [1] ITU · Facts and Figures 2025Connectivity, quality, affordability and digital participation. Report findings describe the named evidence year.
- [2] W3C Web Accessibility Initiative · Introduction to Web AccessibilityHow disability-related barriers arise and how accessible design supports participation. This feature does not claim to certify accessibility compliance.
- [3] UNDP · Digital public infrastructureShared digital foundations, governance, open technology and public-interest implementation.
- [4] UN Universal DPI Safeguards · FrameworkSafety, inclusion, accountability and structural risks across the infrastructure lifecycle. A framework requires implementation and oversight.
- [5] NIST · Cybersecurity Framework 2.0, 2024A risk-management framework for organizations of different sizes and sectors. Applying it does not eliminate all risk.
- [6] ITU and UNITAR · Global E-waste Monitor 2024Electronic waste, repair and product lifecycle challenges. No historical quantities are presented here as current measurements.
- [7] Fundació Guifi.net · Commons NetworkThe foundation’s account of shared telecommunications infrastructure, participating operators and its economic model.
- [8] DHIS2 · About the platformThe project’s description of its open-source platform and international development and implementation collaboration.
- [9] Estonian Information System Authority · X-teeOfficial account of Estonia’s data-exchange environment and the distinction between X-tee and the underlying X-Road technology.
- [10] Nordic Institute for Interoperability Solutions · X-Road technology overviewDistributed data exchange with common management and trust arrangements. Architecture alone does not establish appropriate use of data.
- [11] NIST · Generative Artificial Intelligence Profile, 2024Guidance for identifying and managing generative AI risks, including unreliable outputs. It is a voluntary framework, not a product approval.
- [12] Mobilized News · ICT & CybersecurityA route into Mobilized’s coverage of digital systems, access, privacy and responsible technology.
- [13] Mobilized News · ParticipateWays to contribute knowledge, a story or a project for editorial review.
