Before the first screen, listen.

Before there is an interface, there is already a way people get things done. Start there.

A call to someone who knows the right person. A name written in a notebook. A payment made when a delivery arrives. A message forwarded to a family member who can help. These arrangements may look informal from outside, but they often carry knowledge, trust, and practical support that a new product will need to understand.

It is tempting to begin a technology project with screens. They make an idea visible and give everyone something exciting to discuss. Yet a polished interface can still make the wrong task easier, introduce an extra step, or exclude someone the service was meant to reach. Listening helps us decide what is worth building in the first place.

For a founder, an organisation, or a team commissioning software, this is useful work to do before the brief becomes a list of features. It gives that list a reason to exist.

The service starts before the screen.

Consider an illustrative collection service. A customer wants an item picked up. The visible action might be a request on a phone. Around it sit less visible questions: does the collector know the location, who confirms the price, what happens if nobody is home, and how will the customer know the job is complete?

Designing only the request form leaves these questions to other people. Sometimes that is appropriate; a conversation may resolve an unusual situation better than another menu. But the team should make that choice consciously. A digital step belongs within a service that people can actually complete.

A useful early exercise is to draw the journey as it happens today. Include the person doing the task, the people helping them, the information passed between them, and the places where work pauses. Keep asking what happens immediately before and after each step. The edges of the drawing often reveal the next important question.

Ask about the last time.

A broad question about whether someone likes an idea can produce an encouraging answer without telling you much about their behaviour. A recent event is a better place to begin. It gives the conversation a setting, a sequence, and details that can be examined together.

Leave room for an unexpected answer. If someone describes a phone call, ask what the call helped them resolve. If they keep a paper record, ask when they return to it. You are trying to understand the purpose of the behaviour before deciding whether software should change it.

When a participant suggests a feature, explore the situation behind it. A request for notifications may be about uncertainty over a booking. A request for a dashboard may be about preparing one report each Friday. The suggestion matters, but understanding the underlying task creates more than one possible solution.

Notice the things a conversation misses.

People become skilled at working around difficulties. A workaround can become so familiar that it no longer seems worth mentioning. With permission, watching a person attempt a task can reveal the information they look for, the steps they repeat, and the moments when they switch tools or ask somebody else.

Use the circumstances of the intended service as questions to investigate. Can someone comfortably complete it on their own device? What happens when a connection drops? Does the wording make sense in the language they prefer? Is a shared phone involved? These are possibilities to check with real users, not assumptions to attach to an entire community.

Observation should be respectful. Explain what the session is for, ask before recording, avoid collecting information you do not need, and make it easy to stop. A participant should not have to expose private messages or financial details to help you improve a design. A safe demonstration or an anonymised example may be enough.

Make room for the missing voices.

The people easiest to reach are rarely the whole audience. An organisation's most engaged customers may already know how to get help. Staff may be comfortable with its language. Friends may want the idea to succeed. Useful feedback from these groups still leaves gaps.

Seek people who have abandoned the task, use a different route, need assistance, or face accessibility barriers. Include the staff and partners who will deliver the service: a promise on a screen becomes their responsibility somewhere. Arrange conversations in ways participants can access, including an appropriate language, location, and communication format.

Different needs can conflict. A customer may want flexibility while an operator needs a reliable schedule. Record the tension rather than averaging it away. It might suggest a booking window, a clearer exception process, or a choice that needs to be explained. The team still has to make decisions; research helps it see whom those decisions affect.

Turn what you learn into something testable.

Listening has little value if the findings stay in a presentation. Separate what you observed from what you think it means, then identify the smallest useful test. This makes it possible for someone else to question the interpretation before it becomes a requirement.

In that illustrative example, showing a confirmation number is one candidate response. It may not be enough. Perhaps the customer needs to know when a real person has accepted the request, or what to do if nobody responds. A paper sketch can help the team explore those differences before connecting any systems.

Give a participant a realistic task and let them try it. Watch where they hesitate, what they expect to happen, and whether they can recover from a mistake. Avoid explaining the design while they use it: your explanation may supply information the eventual service will not provide.

Keep a short decision record: what we learned, what changed, what remains uncertain, and what would make us revisit the decision. This helps new team members understand the reasoning and prevents an early assumption from quietly becoming permanent.

What this looked like on DortiBox.

On DortiBox, we worked with Freetown Waste Transformers to develop the customer and collector applications. The work drew on a needs assessment involving FWT, local stakeholders, and residents, followed by a user-testing workshop and a pilot with collection enterprises. These stages helped connect the software with the service around it.

One practical adjustment was adding cash on pickup after some customers experienced difficulties with the initial payment option. For us, that reinforced a simple point: successfully requesting a service and being able to pay for it are connected parts of the same experience.

What we carry from that work is the importance of giving feedback a route back into delivery. When use reveals a practical barrier, there needs to be room to revise the product. Working with FWT and the people delivering the service made that wider context part of the development conversation. Read more about our app development contribution to DortiBox.

Keep the conversation open after launch.

A launch changes the kind of evidence available. Now there are real requests, support conversations, incomplete tasks, and operational handovers. A count can tell you that people stop at a particular step. Talking with them can help explain why. Neither should be asked to answer every question alone.

Decide who receives feedback and when the team reviews it. Look for patterns, but leave room for a serious problem affecting a smaller group. Agree what needs an immediate fix, what needs more investigation, and what can wait. Where possible, tell participants what their feedback helped change.

Services also change around the software. A new payment option, a different staff process, or a change in people's devices can make yesterday's reasonable decision less useful. Staying close to the work means continuing to check whether the product still fits it.

A good first brief can contain unanswered questions. Making those questions visible gives a design and development team something useful to investigate together. The aim is to begin with enough understanding to make the next decision well - and enough openness to change it.