Ask Wallingford — A Roadmap for a Responsible AI Town Assistant

AI Product Strategy · UX/UI Design · Web Development · Product roadmap

Live pilot: Explore Ask Wallingford

Project overview

Ask Wallingford explores how a responsible AI-assisted service could help residents and visitors find reliable local information in one place.

Starting with Wallingford, Oxfordshire, the project brings together local businesses, public events, opening times and health and care services. Its longer-term ambition is to turn this structured information into a useful town assistant that provides clear answers supported by visible sources.

This case study follows the proposed journey from an initial concept and working website pilot to a more complete, evidence-led digital product. It documents what has been built, what needs testing and how the service could develop.

The current website is an early-stage pilot. The projected final-product imagery below illustrates a future design direction, not the present live interface.

The opportunity

Finding local information often involves moving between business websites, event programmes, council pages and public-service directories.

These sources serve different purposes and are updated at different intervals. A venue may publish its opening hours separately from its kitchen times. An event may appear on several websites with different levels of detail. A service listing may remain visible after its information has changed.

Ask Wallingford investigates whether a single, source-led experience could reduce this fragmented search process while keeping users aware of uncertainty.

The opportunity is not simply to add a chatbot. It is to build a dependable information foundation that an assistant can use responsibly.

The product vision

The proposed final product would allow users to ask everyday questions about their town and receive concise answers linked to relevant sources.

Users could also browse businesses, events and services directly, without using a conversational interface.

The intended experience combines:

• Natural-language questions.

• Searchable local directories.

• Clear opening-hours information.

• Date-based event discovery.

• Visible sources and verification dates.

• Business-owner corrections and submissions.

• Responsive desktop and mobile access.

The guiding principle is simple: make local information easier to find without making it appear more certain than it is.

Project objectives

The roadmap is structured around six objectives:

1. Establish a useful pilot focused on one town.

2. Organise local information into consistent, maintainable records.

3. Make evidence and information freshness visible.

4. Test whether users can complete common local-discovery tasks.

5. Introduce AI only when the underlying information and safeguards are ready.

6. Explore wider coverage after the local model has been validated.

My role

I developed the product concept and translated it into an initial website experience.

My work included defining the pilot scope, researching local sources, organising directory content, designing the interface and implementing the frontend.

I also refined the live experience through iterative review, addressing content hierarchy, section alignment, navigation, progressive disclosure, button behaviour and text contrast.

Alongside the pilot, I developed a roadmap for the content operations, AI integration and user testing needed to progress towards a more complete service.

Audience and user needs

Residents

Residents need practical information about everyday services, local shops, places to eat and upcoming activities.

Their questions are often specific: where to go, when a venue opens or which organisation provides a service.

Visitors

Visitors need an accessible introduction to the town, including places to explore, food and drink options and useful amenities.

They may not recognise local venue names or know which websites to consult.

Local businesses and organisations

Businesses and service providers need a straightforward way to suggest sources, correct inaccurate details and understand how their information is represented.

These audiences informed the decision to combine a question-led starting point with conventional browsing.

The development roadmap

Each phase introduces a capability that depends on the previous one. Expansion is conditional on the pilot demonstrating that its information can be maintained and its answers can be trusted.

Phase 01 — Define the local pilot

The initial scope focused on a manageable set of useful local tasks rather than attempting to represent every aspect of the town.

The pilot covers events, food and drink, everyday shopping, health and care services, and trusted local information sources.

Early design decisions included prioritising official information, separating browsing from question-led discovery and making the service’s pilot status explicit.

This established a focused starting point for development without implying that the product was already a comprehensive town-wide assistant.

Phase 02 — Build the working website

The first implementation created a responsive website with a question-led hero and structured local directories.

The current experience includes:

• A local-question input and suggested prompts.

• An illustrative source-aware answer panel.

• A food and shopping directory.

• Upcoming public-event listings.

• A health and care directory.

• Links to trusted local sources.

• An explanation of the responsible AI approach.

• A demonstration route for suggesting updates.

The question-led interaction currently demonstrates the discovery concept. It is not presented as a fully connected generative AI service.

Information architecture

The homepage introduces the service before offering routes into specific local tasks.

Upcoming events appear before food and shopping, giving time-sensitive information greater prominence. Health and care services occupy a separate section, followed by trusted sources and the product’s methodology.

Collapsible sections reduce the amount of information initially visible. Users can open the directory they need and close it again without navigating away.

Local directories

The food and shopping pilot contains 38 entries across pubs and bars, cafés, restaurants, bakeries and delis, and convenience shops. Some entries appear in multiple categories.

Filters support focused browsing, while expandable details keep opening hours and additional notes available without overcrowding the initial card layout.

The events directory provides month-based browsing. The health and care directory groups services by type and directs users to providers for current details.

Source-led content

The pilot prioritises first-party venue and operator websites alongside relevant council, NHS and regulator information.

Records distinguish published details from provisional or unavailable information. Review dates and source links help users judge whether they should confirm a detail before acting.

The listings represent researched snapshots, not continuous live feeds.

Phase 03 — Validate the experience

The next stage would test whether the pilot supports real local-discovery tasks.

Proposed tasks include finding a café’s opening hours, locating an upcoming event, identifying a relevant health service and checking the source behind a listing.

Testing would examine:

• Whether users understand the service’s purpose and limitations.

• How easily they find and use the filters.

• Whether expandable sections help or hinder discovery.

• Whether source links and review dates are noticed.

• How the experience works on smaller screens.

• Whether keyboard and assistive-technology users can navigate effectively.

The interface has undergone visual iteration, but formal usability and accessibility testing has not yet established its effectiveness.

Phase 04 — Create a maintainable information system

Before introducing a more capable assistant, the project would need to move beyond frontend content into a structured information system.

A proposed record would include a business or service name, category, location, official URL, opening-hours details, source, review date and verification status.

The supporting editorial workflow would allow records to be reviewed, corrected and flagged when information becomes old or conflicting.

Potential automated updates would be assessed source by source. Suitable feeds or permitted integrations could support event updates, while other information may still require manual review.

Automation would assist maintenance rather than remove the need for oversight.

Phase 05 — Introduce responsible AI assistance

The proposed AI layer would retrieve information from approved records before generating an answer.

Rather than relying on general model knowledge for local facts, the assistant would use the curated information store and provide links to supporting sources.

The intended safeguards include:

• Avoiding unsupported opening times or availability claims.

• Showing when information was last reviewed.

• Stating when a reliable answer is unavailable.

• Flagging conflicting or stale records.

• Directing users to the original provider for confirmation.

• Keeping health-service discovery separate from medical advice.

This phase would require technical implementation and evaluation before any claim of reliable AI performance could be made.

Phase 06 — Develop the projected final product

The projected final interface explores a more complete and visually engaging experience while retaining the pilot’s core principles.

The concept introduces local imagery, richer discovery cards and a more developed desktop and mobile presentation. The question-led entry point remains central, supported by direct routes into events, businesses and services.

This is a design direction to test—not a fixed specification. Further research may change the balance between search, conversational assistance and browsing.

The final product should be defined by useful, dependable interactions rather than visual polish alone.

Visual design system

The developing visual identity uses dark blue, restrained teal, warm neutrals and white.

Editorial serif headings give the service a recognisable local-publication character, while sans-serif body text supports practical information and interface controls.

Outlined CTAs and filter pills maintain a light appearance. Dark blue hover and selected states provide consistent feedback, with a lighter blue hover for the primary Ask Wallingford button.

The visual system is intended to remain calm, readable and adaptable as the amount of content grows.

Iteration during the pilot

The pilot evolved through a series of focused design reviews.

Refinements included aligning the hero panel, moving events higher on the page, introducing collapsible sections, improving supporting-copy placement and making CTA labels more descriptive.

Further changes addressed event-card contrast, section-background separation and consistent filter states.

These iterations demonstrate the development process, but should be distinguished from findings gathered through formal user research.

Measures of success

The next stages would introduce measurable evaluation rather than assuming that a live website is a successful service.

Proposed measures include:

• Task-completion rate for common local queries.

• Time taken to locate a relevant listing.

• Accuracy of answers against approved source records.

• Frequency of unsupported or unanswered questions.

• Proportion of records reviewed within their intended interval.

• Time required to investigate and apply a correction.

• User understanding of source and freshness information.

No performance improvements or adoption figures are claimed at this stage.

Risks and design considerations

The main challenge is maintaining reliable information over time.

Opening hours, event programmes and service arrangements can change. Automated collection may fail or misinterpret a source, while AI-generated wording can make uncertain information sound authoritative.

The roadmap therefore places content maintenance, source attribution and evaluation before geographic expansion.

Other considerations include accessibility, privacy for submissions, permission-aware data collection and the operational effort required to keep the service useful.

Wider rollout

If the Wallingford model proves useful and maintainable, the structure could be adapted for other towns.

A wider service would need location-specific records, local source ownership, consistent verification standards and a clear process for correcting information.

County-wide coverage would be a separate development stage, not simply a larger version of the same homepage.

The initial goal remains to validate one town well before attempting broader coverage.

Current outcome

Ask Wallingford has progressed from an initial product idea to a live, source-led website pilot.

The project currently demonstrates information architecture, responsive interface design, directory browsing and a visible approach to responsible local information.

Its roadmap identifies the additional research, infrastructure and safeguards required to develop a more complete AI-assisted product.

The projected final-product visuals communicate that ambition while remaining clearly separate from the current implementation.

Key learning

A useful local assistant depends on the quality and maintenance of its information, not only on the capability of its AI model.

Source visibility, uncertainty and review processes need to be designed into the experience from the beginning.

This project also reinforced the value of phased development: a focused pilot can expose practical design and operational questions before the complexity of live AI and wider coverage is introduced.

Portfolio summary

Ask Wallingford is an early-stage product roadmap study exploring a responsible AI town assistant. It follows the journey from concept and source research to a working website pilot, then sets out a phased route towards validated usability, maintainable local data and evidence-backed AI assistance.

Current deliverable: A live responsive pilot.

Future direction: A tested, source-grounded local assistant with a more developed desktop and mobile experience.

Explore the current Ask Wallingford pilot