UKOmnibus Research Guard questionnaire-review walkthrough

Raw source preview

Raw, unprocessed file text shown below.

---
title: "UKOmnibus Research Guard questionnaire-review walkthrough"
status: processed
source_type: prototype walkthrough
session_date: 2026-04-23
duration: "44m 49s"
customer: "UKOmnibus Group"
participants:
  - Nathan Pereira
  - Desmond Leo
product_area: "Research Guard"
tags: [ukomnibus, research-guard, questionnaire-review, prototype-test, customer-evidence]
---

# UKOmnibus Research Guard questionnaire-review walkthrough

## Source file

- [questionnaire review walk through - Nathan.docx](<./questionnaire review walk through - Nathan.docx>) — original Microsoft Teams transcript export.

## What happened

Nathan worked through the Research Guard prototype against a real questionnaire. The session covered the research brief, survey constraints, questionnaire structure, routing, response options and the downstream effects of proposed changes. Nathan made decisions throughout rather than receiving an automatic rewrite.

## Evidence relevant to launch

### The review found issues that matched a researcher's own checks

When the prototype revisited a routing change and its knock-on effects, Nathan said:

> “That's kind of exactly what you would do in a questionnaire review anyway.”

**Reference:** Nathan Pereira, 36:36–37:21.

Later, when asked whether the process increased confidence in the reviewed questionnaire, he said:

> “It's asking the right questions for sure.”

**Reference:** Nathan Pereira, 42:06–42:44.

### The human-in-the-loop design mattered

Nathan responded positively to the product asking before making consequential changes:

> “It's saying, I think we should do this. What do you reckon? I kind of like that.”

**Reference:** Nathan Pereira, 36:55–37:28.

He also identified the need for both a thorough mode and a quicker mode, depending on how much control the user wants.

### Nathan saw a route to less manual work

When the product identified that a compound question should be split, Nathan said this could remove a step he would otherwise complete himself:

> “It means I won't have to do it manually.”

**Reference:** Nathan Pereira, 28:48–29:29.

### Overall reaction was positive, with a clear usability caveat

Nathan described the experience as “really good” and said he liked it. He also said some questions could feel cumbersome, particularly on complex questionnaires. This supports the value of the controlled review approach while reinforcing the need for a quicker path and clear expectations about review time.

**Reference:** Nathan Pereira, 38:03–42:27.

## What this supports

- A target user worked through a founder-operated prototype against his own questionnaire, supplied the answers and decisions, and did more than react to a product description.
- The human-approval model and downstream consistency checks matched how the user expected questionnaire review to work.
- The user identified plausible manual-work reduction and reported greater confidence in the review process.

## What this does not prove

- That every recommendation is correct or complete.
- That junior users achieve senior-researcher outcomes.
- Measured time saved on a completed project.
- Willingness to pay for Research Guard as a separate product.
- Independent demand beyond an existing pilot relationship.