Data Acquisition & User Behaviour
Didge Design Guide – Data Acquisition & User Behaviour
Purpose of This Document
This document defines how Data Acquisition and User Behaviour should be designed, documented, and implemented within the Didge platform.
It establishes a shared mental model for:
how data enters the system
what behaviour is expected from users
how technology supports that behaviour
how configuration enables correct execution
This guide is internal-facing and is intended for:
product and domain leads
implementation and solution design teams
engineers and QA
training and onboarding teams
Why Data Acquisition Needs Its Own Design Layer
In Didge, most failures do not occur because of missing features, but because of a misalignment between real-world behaviour and system design.
Examples:
staff are too busy to take photos at the moment of disposal
disposal happens in different physical locations
weighing may occur later or elsewhere
Data Acquisition design ensures that:
the system fits operational reality
users are not forced into unnatural workflows
data remains accurate even under pressure
Position in the Didge Design Framework
Data Acquisition sits between checkpoints and forms.
Packages define outcomes
Checkpoints define controls
Data Acquisition defines behaviour
Forms define data structure
Configuration makes it executable
This layer describes how a control is executed in the real world.
What Data Acquisition Is (and Is Not)
Data Acquisition IS:
behaviour-focused
scenario-based
technology-aware
tolerant of operational variability
Data Acquisition IS NOT:
UI or screen design
form field specification
technical implementation detail
Core Concept: Data Acquisition Scenarios
All data enters Didge through Data Acquisition Scenarios.
A scenario describes:
when data is captured
who captures it
what they physically do
how they interact with technology
Scenarios are designed before forms and configuration.
The Four Layers of Data Acquisition
Every scenario must address four distinct layers.
1. Intent
Why the data is being captured.
2. Human Behaviour
What the person does in the real world.
3. Technology Interaction
How the person uses Didge, CamPro, or other tools.
4. System Preconditions
What must already be configured for this to work.
Keeping these layers separate prevents confusion.
Data Acquisition Behaviour Sheet (Standard Template)
The following template must be used to document each Data Acquisition Scenario.
1. Data Being Acquired
Checkpoint:
Purpose:
2. Acquisition Scenario
Scenario Name:
When this occurs:
3. Required Human Behaviour
Describe what the person does in the physical world.
4. Technology Interaction
Describe how the user interacts with:
CamPro
Didge mobile app
Didge web platform
Avoid UI-level detail.
5. Supported Acquisition Methods
List all allowed capture methods:
☐ Image-based capture
☐ Manual entry (mobile)
☐ Manual entry (web)
☐ Post-event entry
6. Validation & Guardrails
Define what is required for submission:
mandatory fields
AI confidence thresholds
prompts for missing data
7. System Preconditions
Define what must exist before this scenario can work:
configured locations
categories
units of measurement
user access
8. Failure & Fallback Behaviour
Describe what happens when:
capture is missed
image cannot be taken
weight is unavailable
9. Data Outcome
Describe what the system produces:
records created
flags applied
reporting availability
Design Rules (Non-Negotiable)
Behaviour drives system design, not the other way around
Post-event entry must be supported where operationally necessary
Data quality must be protected through validation, not user discipline
AI assists, but manual fallback must always exist
Scenarios must be testable by QA
How This Is Used in Practice
Package defines what must be measured
Checkpoint defines what control exists
Data Acquisition Scenarios define how data enters the system
Forms and configuration are aligned to these scenarios
QA tests each scenario end-to-end
Common Mistakes to Avoid
designing forms without understanding behaviour
assuming capture always happens in real time
forcing image capture when operationally unrealistic
hiding fallback paths
Intended Use
This document establishes the standard approach for designing Data Acquisition in Didge.
All new packages and checkpoints must consider Data Acquisition Scenarios before implementation.
Last updated
Was this helpful?