Redesigning a community directory to support location-based search
🧭 Overview
Organisation: Royal Borough of Greenwich
Role: Product Designer
Timeframe: 3 months
I led the redesign of location-based search for the Greenwich Community Directory to better reflect how residents actually find services.
Research showed location was a key decision factor — particularly for optional and local activities — yet the directory’s location experience was fragmented and difficult to use. Improving this wasn’t just a usability fix, but a strategic opportunity to increase trust, relevance, and real-world usefulness.
⚠️ Problem
Although the directory held a rich database of services, searching by location was confusing and ineffective:
- Users could only browse via a cluttered GIS map
- No way to filter by neighbourhood or area
- Listings didn’t clearly show where services were located
- Inconsistent location naming broke users’ mental models
As a result, many residents abandoned the directory in favour of Google — losing access to curated local services.
🎯 Challenge
How might we support both:
- Residents who search by service first, then refine by location
- Residents who explore by location first, then assess relevance
All within tight technical constraints and inconsistent location data.
🧠 Approach
I took a behaviour-led approach, combining:
- Desk research across councils and existing studies
- User testing to uncover real search patterns
- Concept exploration and effort vs impact prioritisation
- Detailed design grounded in delivery feasibility
🔍 Key insights
User research highlighted two primary search behaviours:
- Service-first searching — users prioritised service listings but struggled to interpret location information.
- Location-first searching — users primarily explored using the map.
To ensure the product meets the needs of all it's users, it was important to support both of these behaviours.
🧩 Solution
Through prioritisation with the Product Manager and developers, we delivered three high-impact improvements:
Highlights
Separate 'List' and 'Map' views
Reduced cognitive load and aligned with distinct search behaviours.
🛠️ Implementing neighbourhood filters
The problem
In our CMS, the only required location data field for service listings is the 'postcode'. We had an internal database that allowed us to map postcodes to regional 'wards'. This presented a problem because raw postcodes weren’t meaningful for filtering, and ward names were too granular and unfamiliar to residents.
The solution
I defined a more intuitive list of Greenwich neighbourhoods and mapped all service postcodes into these areas, creating a scalable postcode-to-neighbourhood dataset. This layered meaningful, human-readable location filters on top of existing data — without changing the CMS.
📈 Impact
- Made it easier for residents to find nearby services by supporting both service-first and location-first search behaviours
- Improved usability and trust while reducing friction within real-world technical and service constraints
- Demonstrated behaviour-led design that balanced user needs with system and delivery realities