Design Thinking: How to Build User-Centric E-Services That People Actually Use

Too many e-services still fail for a simple reason: institutions digitise procedures instead of designing services around the people who must use them. In both government and the private sector, putting a form online is not the same as creating a service that is clear, usable, trusted, and worth returning to. That distinction matters because adoption does not come from digitisation alone. It comes from whether the service actually solves a user problem with less friction, less confusion, and less wasted time.

This is where design thinking becomes useful, not as a fashionable workshop method, but as a practical discipline for building better services. At its core, design thinking starts with understanding real user needs, then moves through problem framing, ideation, prototyping, testing, and iteration. In practice, this means institutions stop assuming they already understand what users need and start validating how people actually experience the service.

For policymakers, this is not a marginal design issue. It is a performance issue, a trust issue, and often a legitimacy issue. Governments increasingly operate in an environment where public trust is fragile, expectations are shaped by high-quality private-sector digital services, and poorly designed e-services quickly translate into frustration, abandonment, and lower confidence in institutions.

The same logic applies beyond government. Private-sector service owners already understand that user-centricity drives adoption and retention; public institutions should treat that lesson as equally relevant, even if their constraints are different. Compliance, legal certainty, and administrative control all matter, but they do not create trust on their own. Trust is also built when services are understandable, accessible, and visibly designed around real user needs.

This article argues that user-centricity is no longer optional in e-service design. Design thinking is one of the most practical ways to translate that principle into execution, helping organisations create services that people actually use, trust, and benefit from. Estonia’s digital ecosystem offers a strong illustration of this approach in practice, especially in how advanced services have been built around convenience, usability, and end-to-end digital interaction rather than simple form digitisation.

What design thinking actually means in service creation

Design thinking is often described in abstract terms, but in practice it is much simpler than the language around it suggests. It means starting with the people who use the service, understanding what they are trying to achieve, where they get stuck, what they expect, and what would make the experience clear and manageable. If that understanding is weak, the service will usually reflect the institution’s internal structure rather than the user’s real journey.

This is why good service design starts with user needs, not with forms, systems, or organisational charts. A team should first ask basic but critical questions: Who is the user? What are they trying to do? What information do they already have? Where do they become confused, delayed, or forced into unnecessary steps? In both public and private services, this early work helps prevent a common failure pattern in which a service is technically functional but practically frustrating.

In practical terms, design thinking usually means moving through a simple cycle. First, research the user and the current service experience. Second, define the real problem instead of accepting the internal version of it. Third, design and test possible improvements. Fourth, launch in a controlled way and monitor what users actually do, not just what the project team expected them to do.

That last part is often where organisations fall short. They treat launch as the finish line, when it should really be the start of a more informed improvement cycle. Once a new function or process is live, service owners should gather user feedback in detail, look at completion rates, drop-off points, error patterns, time spent on key steps, and recurring support requests, then decide what truly improves the service and what only adds noise or confusion. Australian government guidance, for example, explicitly says agencies should let users rate satisfaction, monitor it continuously, and act on the results rather than merely collecting feedback as a formality.

A good practical example comes from GOV.UK’s iterative design approach. After a homepage iteration was launched, the team collected feedback through channels such as email and social media, identified bugs and reproducible issues, and continued user testing so the service could be refined regularly during beta. The important lesson is not the homepage itself, but the operating model behind it: launch something usable, observe real behaviour, fix what fails, and keep improving based on evidence.

This is also where data-based decision-making becomes essential. Not every user suggestion should be implemented, and not every complaint points to the right fix. Good design thinking means combining qualitative feedback with behavioural data and service metrics, then separating what is merely requested from what actually helps users complete the task more clearly, quickly, and confidently.

Why user-centricity is a performance issue, not a branding exercise

User-centricity is often discussed as if it were mainly a matter of tone, branding, or interface quality. In reality, it is a performance issue. When a service is designed around real user needs, people can complete tasks more easily, require less support, make fewer mistakes, and return with greater confidence. That has direct operational value for both governments and private organisations.

A user-friendly service reduces dependency on help desks, support staff, and workarounds. If users can understand the steps, see what is required, and move through the process without confusion, the organisation spends less time correcting avoidable problems. This is one of the clearest signs that service design is working: the process becomes easier not only for the institution, but for the user as well.

The same principle applies to bureaucracy. A badly designed service often forces people to re-enter information, repeat steps, or navigate structures that reflect the organisation’s internal logic rather than the user’s task. Good design reduces that burden. When best practices such as the once-only principle are applied, users are not repeatedly asked for data that the organisation or the state already holds, which makes the service faster, less frustrating, and more credible.

This is why user-centricity should be treated as a strategic capability rather than a cosmetic layer. It affects adoption because people are far more likely to use a service that feels predictable and manageable. It affects trust because services communicate something about the institution behind them: whether it respects the user’s time, whether it understands the real-life task, and whether it can deliver competence through execution rather than slogans. Recent research on e-government satisfaction also points in the same direction, linking service quality and satisfaction with continued use intention and trust in government.

For policymakers, the lesson is straightforward. Better e-services do not just improve convenience; they also reduce avoidable bureaucracy and strengthen the relationship between institutions and users. For service owners in the private sector, the logic is already familiar. In both settings, user-centricity should be judged by outcomes: fewer support needs, less repetition, higher completion, better adoption, and stronger confidence in the service.

What using design thinking in practice looks like

Using design thinking in practice does not require a complicated innovation framework. In most organisations, it can be understood as a disciplined sequence of steps that keeps the user at the centre from the first problem definition to ongoing improvement after launch. The value of the method is not in the terminology, but in the way it forces teams to replace assumptions with observation, testing, and evidence.

The first step is to understand the user and the task. This means identifying who the service is for, what they are trying to achieve, what information they have at the start, what barriers they face, and what “success” looks like from their point of view. In government, that may involve citizens, businesses, civil servants, or intermediaries. In the private sector, it may involve customers, partners, or employees. The principle is the same: start with real behaviour and real needs, not internal process diagrams.

The second step is to map the user journey and identify friction points. A team should look at the full process, not only the digital interface. Where do users drop out? Where do they become confused? Which steps create delay, repeat information, or force users to switch channels? This is often the moment when organisations discover that the biggest problems are not visual design issues, but broken service logic, unclear rules, and fragmented ownership.

The third step is to define the real problem before designing a solution. Many projects fail because they begin with an assumed answer such as a new portal, a new form, or an automation feature. Design thinking works better when the team first agrees on the actual user problem and the evidence behind it. That creates a much better basis for prioritisation and avoids expensive work on features that look useful internally but add little value for users.

The fourth step is to prototype and test early. That does not always mean building a fully functional product. Teams can test simplified process flows, interface concepts, wording, decision points, or assisted mock-ups before investing heavily in delivery. This matters in both public and private sectors because early testing reveals confusion and design flaws while they are still cheap to fix.

The fifth step is to launch with measurement in place. Once a service or function goes live, the organisation should track completion rates, drop-offs, error patterns, support requests, satisfaction signals, and direct user feedback. This is where design thinking becomes operational rather than theoretical. The service owner needs enough data to judge whether the change actually improved the experience or only introduced more complexity.

The sixth step is to iterate continuously. A useful service is never truly finished because user expectations, policy requirements, organisational structures, and technical conditions all evolve. Teams should review what the data shows, compare it with qualitative feedback, and decide what to improve, simplify, remove, or redesign. This is how design thinking becomes part of service governance rather than a one-time project exercise.

The method applies in both government and the private sector, but the operating environment is different. Public-sector teams usually face more legal constraints, stronger accountability requirements, procurement complexity, legacy systems, and wider accessibility obligations. Private-sector teams may move faster, but they can still fail if they optimise only for internal efficiency or growth metrics while neglecting clarity, trust, and real user needs. In both cases, the best results come when multidisciplinary teams align policy, operations, design, technology, and data around the same user journey.

In plain language, the practical model is simple: learn what users need, understand where the process fails, test improvements early, measure what happens after launch, and keep refining the service. That is what design thinking looks like when it is used seriously. It is not a brainstorming ritual. It is a structured way to build services that are easier to use and more likely to succeed.

The reality of execution: where organisations get this wrong

This is also the point where many organisations fail. They speak about digital transformation, but what they actually deliver is process replication in digital form. The paper form becomes a web form, the old approval chain remains intact, the language stays administrative, and the burden of navigating complexity is simply shifted onto the user. That is not service design. It is bureaucracy with a login screen.

One of the most damaging myths is that putting a service online means the job is done. It does not. A digital channel can still be slow, confusing, repetitive, and deeply user-hostile. If the process is poorly designed, digitisation only makes failure scale faster. Instead of queues at a counter, users face abandonment, repeat attempts, support tickets, and quiet frustration.

A second mistake is treating user-centricity as secondary to compliance. In reality, compliance and user-centricity are not opposites. A service can be legally sound and still be badly designed; many are. When institutions act as if legal correctness alone is enough, they overlook the fact that users experience the service as a whole. They do not separate policy, interface, process, and communication into neat internal categories. They judge the institution by whether the service works.

A third failure is assuming that compliance alone creates trust. It does not. Compliance may be necessary for legitimacy, but it is not sufficient for confidence. Users build trust when they can understand what is happening, complete the task without unnecessary struggle, and see that the institution has made a serious effort to respect their time and needs. A service that is formally compliant but practically painful can still weaken trust.

Another common error is to treat digitisation as mainly a technology problem. Technology matters, but poor e-services are rarely caused by interface design alone. More often the real issues sit underneath: fragmented governance, unclear ownership, conflicting rules, legacy architecture, procurement constraints, and a weak understanding of the actual user journey. Organisations that ignore these structural problems usually end up blaming users for not adopting services that were never designed well enough in the first place.

There is also a deeper institutional habit that deserves criticism: teams often design from the inside out. They begin with the structure of the ministry, the agency, the database, or the back-office workflow, and then expect users to adapt. This is exactly backwards. Services should be organised around the task the user needs to complete, not around the chart of the institution that provides it. Design thinking matters precisely because it forces this inversion.

The uncomfortable truth is that many organisations already know these problems exist. What is often missing is not awareness but discipline. User research is skipped because timelines are tight. Testing is reduced because delivery pressure is high. Feedback is collected but not acted on. Metrics are available but not linked to decisions. In that environment, “user-centricity” becomes a presentation slide rather than an operating principle.

For both governments and businesses, the message is simple. Better e-services will not emerge from rhetoric, procurement alone, or technical delivery in isolation. They require institutions to redesign how they understand users, how they define problems, and how they judge success. Without that shift, many digital programmes will continue to produce modern-looking interfaces on top of old administrative logic.

Case: Estonia’s e-Business Register

Estonia is a useful case because it shows that user-centric services do not begin with interface design alone. They begin with strong digital foundations that make good service design possible at scale. In Estonia, two of the most important foundations were established early: X-Road as a secure data exchange layer from 2001, and a national electronic identity system from 2002. Together, these created the conditions for services that could move beyond isolated online transactions and toward genuinely integrated digital interaction.

That point matters because many countries try to improve user experience on top of weak institutional and technical foundations. Estonia’s example suggests the opposite sequence. If identity, authentication, digital signing, and secure data exchange are reliable, service owners can design around the full user journey instead of forcing users back into paper-based or fragmented processes. In other words, user-centricity becomes much easier to deliver when the state has already solved some of the core infrastructure problems underneath the interface.

The e-Business Register is a strong example of what that looks like in practice. The official portal provides a single environment where users can view legal persons related to them, change data, submit applications and documents, file annual reports, and access a broad set of business-related information. It is also designed as a quick and convenient route for registering a new company or other legal entity, rather than forcing users into a fragmented administrative process.

This is exactly where design thinking and user-centricity become visible in service outcomes. The user is not asked to navigate a maze of separate institutional structures in order to complete a business task. Instead, the service is organised around what entrepreneurs and companies actually need to do: establish an entity, update information, submit required documents, and access relevant data from one digital environment. That may sound obvious, but in many countries this level of practical integration still does not exist.

What makes the Estonian case especially strong is that these are not just digital forms with a nicer interface. Company registration, changes to company data, and liquidation are treated as structured workflows with clear logic at each step. For example the system validates activity fields against official activity-code registers, checks company names against EU and Estonian trademark and company-name rules, validates contact addresses against the address register, and confirms mandatory email access through validation links. In addition person data is pulled and checked against the population register, while articles of association are standardized in a machine-readable and validateable format. Furthermore, users can provide feedback at every stage regarding specific system processes. This feedback is then analyzed, and the resulting insights are implemented to drive continuous system improvement. Ultimately, the entire development cycle adheres to the best practices of design thinking.

The same design logic extends beyond the immediate register workflow. Estonia also applies a more proactive service model around adjacent obligations and registrations. Beneficial-owner registration is handled as a related compliance process, while optional VAT registration and optional employee registration are handled through the relevant tax authority services. This matters because it shows the user is not simply forced to complete one isolated step after another; the system is built to anticipate the wider business lifecycle and connect the relevant public services around it.

The register also shows why user-centricity is more than convenience in a narrow sense. It reduces friction, lowers avoidable administrative effort, and makes digital interaction more natural for the user. Estonia’s broader digital ecosystem reinforces this by enabling authentication and digital signing through tools such as ID-card, Mobile-ID, Smart-ID, and e-Residency-related credentials, which helps convert legal and administrative steps into manageable digital actions.

This does not mean Estonia offers a simple template that every country can copy without adaptation. Its scale, governance model, and long-term digital investments are specific. But it does show something important for both governments and private-sector service owners: truly user-centric services are easiest to build when design discipline is combined with trustworthy digital infrastructure, interoperable systems, machine-readable rules, and a serious commitment to end-to-end service logic. That is the real lesson.

What policymakers and service owners should do next

What should policymakers and service owners do next if they want design thinking to produce better e-services in practice? The answer is not to launch another innovation initiative. It is to put a more disciplined operating model in place. The following ten actions are concrete, evidence-based, and relevant to both governments and private-sector organisations.

1. Start with user needs, not institutional assumptions

The first discipline is basic but often ignored: understand what users are trying to achieve before deciding what to build. Government guidance is explicit on this point, arguing that if teams do not know user needs, they will not build the right service. That principle applies equally in business and government.

2. Design the whole service, not just the digital touchpoint

Users experience a task from beginning to end, not as a collection of organisational channels. Strong service standards therefore focus on solving a whole problem for users and providing a joined-up experience across channels. If the online step is efficient but the surrounding process is fragmented, the service is still badly designed.

3. Build multidisciplinary teams around the service

Good e-services do not emerge from design, policy, or technology working in isolation. Public-service standards consistently recommend multidisciplinary teams that combine user research, delivery, service design, policy or legal insight, content, technology, and data. This is essential because the real service problem usually crosses organisational boundaries.

4. Use data to guide decisions after launch

Launch should not be treated as proof of success. Teams should define what success looks like, measure performance continuously, and use metrics such as completion, drop-off, errors, support demand, and satisfaction to decide what to improve. The point is not to collect dashboards for reporting purposes, but to make better service decisions with real evidence.

5. Treat iteration as normal governance, not project failure

Many organisations still behave as if a launched service should already be “finished.” Better practice says the opposite: services should be iterated and improved frequently. The GOV.UK example shows why this matters, as live feedback and user testing were used to identify issues and refine the experience after release rather than freezing the design prematurely.

6. Reduce bureaucracy through reuse and integration

A user-centric service should not repeatedly ask for information the organisation or the state already holds. OECD’s digital government framework explicitly links maturity to joined-up, seamless, integrated, and proactive service delivery. In practice, that means building services that reuse trusted data, reduce duplicate steps, and lower the administrative burden on users.

7. Build on strong digital foundations

User-centric services depend on underlying capabilities such as secure identity, privacy protection, interoperability, and reliable infrastructure. Estonia’s experience shows this clearly: X-Road and national e-identity made it possible to move toward more integrated digital services, including the e-Business Register. Design thinking becomes far more effective when these foundations are already in place.

8. Make accessibility, clarity, and simplicity non-negotiable

A service that only works for confident or digitally advanced users is not well designed. Public service standards stress simplicity and the requirement that everyone can use the service. That means writing clearly, reducing unnecessary steps, testing with diverse users, and treating accessibility as core service quality rather than a compliance afterthought.

9. Give leaders responsibility for removing barriers

Senior leadership matters because many service problems are not visible at interface level. Multidisciplinary team guidance highlights that leaders must set direction, remove barriers, support evidence-based improvement, and help teams reuse and simplify across products and services. Without that support, user-centricity is easily blocked by siloed governance, procurement, and institutional inertia.

10. Judge success by outcomes, not delivery theatre

The final recommendation is cultural. Organisations should stop rewarding the appearance of delivery and start rewarding measurable outcomes for users. A modern interface, a completed procurement, or a launched portal means little if users still need help, repeat the same information, abandon the process, or distrust the result. Real success is visible in better completion, less friction, less bureaucracy, and stronger confidence in the service.

Sources

1. OECD. Recommendation of the Council on Digital Government Strategies. https://legalinstruments.oecd.org/en/instruments/OECD-LEGAL-0406/
2. OECD. Rethinking e-Government Services. https://www.oecd.org/content/dam/oecd/en/publications/reports/2009/10/rethinking-e-government-services_g1gha7b1/9789264059412-en.pdf
3. OECD. The OECD Digital Government Policy Framework. https://www.oecd.org/en/publications/the-oecd-digital-government-policy-framework_f64fed2a-en.html
4. OECD. Government at a Glance 2025: Digital Government Index. https://www.oecd.org/en/publications/2025/06/government-at-a-glance-2025_70e14c6c/full-report/digital-government-index_1edec44e.html
5. OECD. The E-Leaders Handbook on the Governance of Digital Government. https://www.oecd.org/en/publications/the-e-leaders-handbook-on-the-governance-of-digital-government_ac7f2531-en.html
6. GOV.UK. Government Design Principles. https://www.gov.uk/guidance/government-design-principles
7. GOV.UK. User research for government services: an introduction. https://www.gov.uk/service-manual/user-research/how-user-research-improves-service-design
8. GOV.UK. Have a multidisciplinary team. https://www.gov.uk/service-manual/service-standard/point-6-have-a-multidisciplinary-team
9. Government Digital Service. Iterate. Then iterate again. https://gds.blog.gov.uk/2012/07/18/iterate-then-iterate-again/
10. Digital.gov.au. Multidisciplinary teams. https://www.digital.gov.au/policy/digital-experience/toolkit/managing-teams/multidisciplinary-teams
11. Digital.gov.au. Criterion 4. Measure if your digital service is meeting user needs. https://www.digital.gov.au/policy/digital-experience/digital-performance-standard/dps-criterion-4-measure-if-your-digital-service-is-meeting-user-needs
12. Interoperable Europe. Design Thinking Tools for Stakeholder Engagement. https://interoperable-europe.ec.europa.eu/collection/eugovtech/design-thinking-tools-stakeholder-engagement
13. Local Government Association. Design thinking. https://www.local.gov.uk/our-support/transformation/transformation-capability-framework/design-thinking
14. Registrite ja Infosüsteemide Keskus. E-Business Register Portal. https://www.rik.ee/en/e-business-register/e-business-register-portal
15. e-Estonia. e-Services & registries. https://e-estonia.com/solutions/e-governance/e-services-registries/
16. e-Estonia. X-Road – Interoperability services. https://e-estonia.com/solutions/interoperability-services/x-road/
17. X-Road. X-Road History. https://x-road.global/xroad-history
18. e-Governance Academy. A digital success story: the cornerstone of e-Estonia celebrates its jubilee. https://ega.ee/a-digital-success-story-the-cornerstone-of-e-estonia-celebrates-its-jubilee/
19. e-Estonia. e-Business Register. https://e-estonia.com/solutions/ease_of_doing_business/e-business-register/
20. Impact of User Satisfaction With E-Government Services on Continued Use Intention and Citizen Trust in Government. https://www.informingscience.org/Publications/5248