Neighbourly
Local task-sharing service — research, UX design and early product definition
Local task-sharing service — research, UX design and early product definition
Overview
Neighbourly was a proposed digital service for local communities, designed to help people request and offer small everyday tasks — such as collecting prescriptions, borrowing tools, or helping with short errands. The idea came from a founder who had seen informal mutual-aid activity during periods of disruption and wanted to turn that behaviour into a more structured platform.
We were brought in to help validate the idea, understand potential users, and shape an initial product direction before significant development investment.
The challenge
The concept sounded promising in conversation. People generally liked the idea of stronger local support networks. The difficulty was that enthusiasm for the idea was not the same as evidence of sustained demand, trust, or willingness to change existing habits.
There were also unresolved questions:
Who would use it first — people needing help, or people offering it?
Would users trust strangers in their area enough to participate?
Was there enough recurring need to sustain activity beyond a novelty period?
How would the service handle safety, reliability and reciprocity without becoming heavy or bureaucratic?
What we did
We ran a focused discovery phase that included:
Stakeholder interviews with the founding team to clarify assumptions and success measures
User interviews with residents in mixed urban and semi-rural areas
Review of existing informal behaviours (WhatsApp groups, local Facebook groups, word of mouth)
Journey mapping around requesting help, offering help and building trust
Early experience principles and a lightweight service map
A simple prototype to test comprehension, trust and motivation
The research made it clear that while people valued local help in principle, many already had informal routes they preferred. Trust was highly contextual. Some participants said they would use the service only in exceptional circumstances. Others worried about obligation, safety, or awkwardness around refusing requests.
We also tested messaging and onboarding concepts. Participants often understood the service, but did not feel a strong enough reason to switch from current habits.
Outcome
The project did not proceed to full build in the form originally imagined.
The evidence suggested that demand was narrower and more situational than the initial vision required. Without a clearer wedge — for example, a specific audience, a more urgent use case, or a stronger trust mechanism — the platform risked launching as a well-intentioned service with low ongoing activity.
We recommended pausing full product development and either:
narrowing the proposition around a more specific need, or
testing a much smaller manual version of the service before investing in a broader platform.
The founder chose not to proceed at that time.
What we learned
This project reinforced a lesson we return to often: positive reactions to an idea are not the same as validated need.
People can like a concept, speak warmly about it, and still not use it. Informal alternatives, trust barriers and weak urgency can all undermine a service that appears strong on paper.
It also highlighted the value of early research as a decision tool, not just a design input. In this case, the most useful outcome was not a polished product direction — it was a clearer recommendation to stop, narrow, or re-frame before significant build costs were incurred.
Not every project should proceed. A good process should make that visible early enough to act on.
