Define the unit of scope
Start with a screen versus state rule that both teams can apply to every requested behavior.
Screen versus state
A screen is a distinct navigation destination or full layout. A state is an agreed variation such as loading, empty, warning, disabled, or changed values within that layout.
Confirm: List the states included under each of the three screens.
Overlays and system UI
Decide whether dialogs, keyboards, dropdowns, notifications, popovers, boot views, and global navigation count inside or outside the three screens.
Confirm: Mark every layer that can appear above a screen.
Interaction paths
Write the input that enters each screen, available controls, transition conditions, back behavior, timeouts, errors, and the path out.
Confirm: Can the three screens be reviewed as complete user journeys?
Contain implementation uncertainty
The trial should test representative engineering work while keeping high-variance dependencies visible.
Animation boundary
Name each animation, trigger, duration, loop, interruption behavior, format, supplied source, and whether optimization or original motion design is included.
Confirm: Which animations are mandatory for acceptance?
Data boundary
State whether values are static, simulated, or connected to a real protocol, plus update frequency, commands, acknowledgements, invalid data, and errors.
Confirm: Who supplies representative data and the protocol mapping?
Target boundary
Confirm whether review happens in a simulator, on customer hardware, or both, and who supplies drivers, firmware access, hardware, SDK, and a reproducible build.
Confirm: Is target bring-up already complete?
Write acceptance and delivery
A contained price needs observable acceptance criteria and a named package delivered after approval.
Acceptance scenarios
List each screen, state, input, transition, data example, visual behavior, target or simulator, and any measurable performance expectation.
Confirm: Who signs off, and how are defects recorded?
Deliverables
Specify approved design source, LVGL source, prepared assets, communication protocol document, build instructions, integration notes, and known limitations.
Confirm: Does the package match the customer repository boundary?
Payment gates
Connect deposit, design approval, working demo, final approval, balance, and source release to the same written scope.
Confirm: Is the customer able to review before final payment?
Handle expansion without argument
Change control keeps a successful trial from turning into an undefined full project.
Included correction
A defect is behavior that does not match the approved design, documented requirement, acceptance scenario, or agreed target result.
Scope change
New screens, new states, changed flows, revised target hardware, new languages, new protocols, or altered approved designs should be estimated before work continues.
Separate quote
Custom drivers, hardware bring-up, extensive animation, product logic, complex connectivity, missing build access, and work beyond three screens require a separate quote unless explicitly included.