Target and operating context
Define the environment in which the UI must build, run, receive input, and exchange data.
Hardware and display
List the exact MCU or MPU, board, display size and resolution, controller, bus, color depth, orientation, buffers, memory, and storage.
Confirm: Which drivers already work, and who owns hardware bring-up?
Runtime and toolchain
State the OS or runtime, LVGL version, SDK, compiler, IDE, build system, dependency versions, and repository structure.
Confirm: Can a new engineer reproduce a clean build?
Input and environment
Describe touch, encoder, physical buttons, gestures, viewing conditions, boot sequence, power states, and accessibility constraints.
Confirm: Which input paths and device states must be demonstrated?
Interface, data, and content
Screens are only one part of the workload. States, data, assets, languages, and transitions determine the real implementation surface.
Screens and states
Inventory screens, overlays, dialogs, menus, normal states, errors, empty data, disabled controls, loading, and interruptions.
Confirm: Does every visible state have a trigger and an exit path?
Data and protocol
Provide representative values, update rates, units, limits, event ownership, commands, acknowledgements, timeouts, and error behavior.
Confirm: Is simulated data acceptable, or must the demo use the real protocol?
Typography and assets
Provide source artwork, fonts and licenses, icons, images, animation references, localization sets, and asset-generation responsibility.
Confirm: Who approves visual changes made to fit target constraints?
Access, acceptance, and handoff
Make the review route and the delivered package contractual rather than implied.
Project access
Agree repository access, hardware availability, remote target access, SDK packages, credentials, issue tracking, contacts, and response expectations.
Confirm: What happens to schedule and price if access arrives late?
Acceptance evidence
Name the target or simulator, scenarios, visible behavior, performance expectations, video or live review, defect process, and approval owner.
Confirm: What exact evidence releases the final payment?
Source and documentation
List LVGL source, design source, assets, protocol documentation, build notes, dependency records, integration guidance, and known limitations.
Confirm: Can the customer team maintain and rebuild the delivered result?
Commercial and ownership controls
Clarify what can be shared, what must be protected, and how changes are handled before files move between teams.
Security and IP
Define NDA needs, source and asset ownership, third-party licenses, credential handling, data retention, portfolio permissions, and deletion requirements.
Confirm: Are all supplied and generated assets licensed for the product?
Scope changes
Set a written path for new screens, changed behavior, late target changes, missing dependencies, review cycles, rework, and separate estimates.
Confirm: Who can approve a change in scope or schedule?
Support boundary
State the defect period, response route, supported branches and versions, integration support, exclusions, and terms for later feature work.
Confirm: What is a defect against the accepted scope, and what is new work?