The part of building websites that interests me most is the people. Why does an organisation need a website? What are people asking for, and what do they actually need? How do they work together to decide what it should do?

Those questions shape the whole project. They also raise a question about inclusion: how do we make sure everyone involved has a meaningful opportunity to influence what gets built?

I’ve worked with clients who have already commissioned a website, discussed their requirements and signed off a specification, only to find that the finished product isn’t what they expected. The process appears to have included them at every stage. Yet somewhere along the way, their expectations and the proposed solution have drifted apart.

I can’t assume those clients simply felt embarrassed to ask questions. Perhaps the explanations were too abstract. Perhaps the same words meant different things to different people. Perhaps nobody stopped to check whether there was a shared understanding.

Whatever the reason, formal agreement hadn’t been enough.

Understanding makes participation possible

You don’t need to get deep into technical language to lose someone in a conversation about a website.

A developer might talk about forms, a content management system or a connection to a customer database. These are familiar concepts to someone who works with them every day. To somebody else, they may leave important questions unanswered. What will this look like? Who will enter the information? Where will it go? What will I have to do?

Someone may understand the words without being able to picture the process.

That matters because it is difficult to challenge a proposal you cannot visualise. It is difficult to spot a missing requirement when you cannot see how the proposed system fits into your working day.

The people most comfortable discussing technology can end up shaping the decisions. Meanwhile, colleagues with valuable knowledge of members, customers or everyday administrative work may struggle to connect that knowledge to what is being proposed.

For me, this is where digital project management becomes a question of inclusion. Being invited to a meeting or sent a document gives someone access to the discussion. Meaningful participation also requires a process through which their contributions can influence decisions.

Making the project understandable

In my experience, a long technical specification rarely creates shared understanding on its own.

Detailed documentation has a place, especially when a system is complex. But people also need a clear account of the basics: what are we trying to achieve, what will the website do, and what will it not do? What is needed from each person, and what should their contribution look like?

I’ve found that clients respond well to seeing concrete examples. A visual illustration or a walkthrough can give them something to question. Following a familiar task through the proposed system can reveal misunderstandings that pages of description have left untouched.

That might mean showing what happens when someone joins an organisation: the information they provide, what staff receive, and what happens next. Now the conversation has something tangible at its centre. Someone can point to a step and explain why it won’t work for their team.

Visual explanations need clear supporting language too. No single format will work equally well for everybody. A short overview, a demonstration and more detailed information can offer different ways into the same discussion.

The aim is to make it possible for people to understand the decisions well enough to contribute.

Leadership can support inclusion

There is another difficulty I see in group projects: lots of people are involved, but nobody has clear responsibility for bringing their views together.

Discussion can circle around the same questions. Conflicting requests remain unresolved. People leave meetings with different ideas about what has been agreed.

Appointing one person to lead can strengthen inclusion, rather than weaken it. That person’s role should include making sure people know what is needed from them, helping questions surface, and checking that decisions are understood across the group.

They don’t need to know every answer. They do need to be willing to ask for explanations and recognise when agreement is still unclear.

Everyone should have a meaningful opportunity to contribute. That doesn’t mean every decision needs to be unanimous. A clear lead can explain how different needs have been considered, what has been decided and why. People should be able to see what happened to their input, even when their preferred option hasn’t been chosen.

A shared measure of success

The responsibility I feel towards a client is to leave them with something that meets their needs and expectations, and that they understand and feel able to use.

That responsibility starts long before the website is finished. It runs through how I explain a proposal, how we discuss the work, and how we establish whether we mean the same thing.

Shared understanding takes effort. It needs time, clear communication and someone willing to take responsibility for it.

For me, an inclusive digital project gives people a real opportunity to shape the outcome. It makes their knowledge part of the work, and makes the work understandable enough for that knowledge to count.

About me

I’m Chris Gibson. I’m a digital consultant who helps organisations turn their needs into practical, understandable digital tools. I’ve also created The Digital Sense Check, a plain-English guide to making better digital decisions. Designed for people without technical expertise, it supports the shared understanding that helps make participation in digital projects more inclusive. See: https://digitalsensecheck.co.uk/

Image description: Professional team collaborating on digital accessibility and inclusive user interface design