Start with the decision the prototype needs to inform.
A medical device software prototype can place the expected workflow on a phone or tablet for product review, usability feedback, a development decision, a demonstration, or an investor meeting. The next milestone determines which parts of the concept need to work.
A useful starting sentence is: the prototype must allow the intended user to complete the primary workflow so the team can evaluate a specific product question.
Concept inputs
Define the product before defining the screens.
These inputs give the design, software, testing, and early MedTech records a common starting point.
Intended purpose
What the product is intended to do and where the mobile app fits within the product.
Users and use environment
Who will use the app, where they will use it, and the conditions that affect the workflow.
Primary workflow
The main task the user must complete from the first action through the expected result.
Inputs and outputs
The data the app receives, how the software uses it, and what the user or connected product receives.
Risks and assumptions
The product risks, technical assumptions, and known limits that affect the prototype.
Milestone and testing
Who will review or use the build, what will be tested, and which decision follows the evaluation.
Working build
Put the primary workflow on the device.
The prototype should let the intended user complete the agreed workflow from start to finish. Representative data and product states make the review meaningful.
- Primary workflow from entry through the expected result
- Representative inputs, outputs, and app states
- Interface behavior for the agreed prototype scope
- Agreed concept, workflow, and software tests
- Client review and testing through Apple TestFlight
MedTech baseline
Develop the software and early records together.
The intended use, users, workflow, risks, and product milestone shape the regulatory baseline and the records needed for the prototype. The design and development file can connect product inputs, software requirements, design, risk controls, traceability, testing, and the released build.
Usability engineering records address the intended users, use environment, user interface, use-related risks, and early evaluations. Applicable FDA device-software and cybersecurity guidance and relevant ISO 13485 design and development requirements depend on the product and agreed scope.
Handoff
Keep the build and its records together.
The handoff can include the source repository, versioned build, agreed design and development records, test results, and known issues or limitations. Those records preserve the reasoning behind the prototype as the product moves forward.
Begin with one sentence