Improving feedback for Open Codelists

Why are we doing this?

We want to improve the feedback loop for OpenCodelists so we can better understand user experiences and identify pain points earlier. Currently:

• Users typically only provide feedback when prompted (e.g. via Slack or in-person conversations)
• We suspect that some users are encountering bugs or usability issues that go unreported
• we're merging updates, sometimes with a “launch first, learn later” approach—we need better visibility into how those changes are working in practice.

Improving passive and active feedback channels will help us gather insights post-launch and ensure future iterations are will be backed up with more real user experiences.
Slack thread 🧵

How will we know when it's done?

• Users will have a low-friction way to leave qualitative feedback (e.g. via a visible feedback form)
• We’re capturing basic metrics on how users interact with OpenCodelists, such as:

How many users access the Codelist Builder over time?

What proportion go directly to the Builder vs via Search?

How often are features like code metadata, documentation links, or external tools (e.g. NHS Browser) used?

• we can identify key metrics to indicate user behaviour with Open Codelists
  -- how many people have used the Codelist builder for a given time period?
  -- what proportion go straight to the Codelist builder vs Search Codelist -> Codelist builder?
  -- how often are info type tools (i.e. code metadata from the ellipsis button, links to docs/ code usage tool, NHS Browser - yet to be built!) used

What are we doing?

• Design a feedback form - possibly Google Forms?
• Add UI elements to surface the form in relevant places (e.g. during codelist creation or search for codelists).
• Figure out ideal metrics to start monitoring user behaviour in Open Codelist - #2554

Defining delivery tasks guidance