The adult child doing the installation is the primary account holder. The parent does not have an app login at this stage.

Account creation is straightforward: email or social sign-in only, with no complex verification required to get started.

Should the parent eventually have a read-only view of the app? Even a simple "here is what is being monitored" screen could make a meaningful difference to how they experience the product.

How many family members can be linked to a single device? If siblings share caregiving responsibilities, multi-account support would affect the data model and notification structure.

Based on the Pontosense v1 demo, resident profile setup (risk level, mobility aids, pets, health memos) sits within the home profile rather than as a separate sequential step. This structure makes sense: the home establishes the physical context first, and the resident details are added as part of that same setup rather than as a distinct phase. It also means the home can support multiple residents or devices over time without duplicating address information.

Home profile fields include address and household-level details. Resident fields (based on the v1 demo) include risk level, mobility aids, pets, and health memos. Additional fields like name, date of birth, or emergency contact may also be present but were not confirmed in the demo viewed.

Health memos and risk level are optional fields, not required to proceed. Forcing detailed health information at this stage could create friction for installers who do not have that information to hand, or who feel uncomfortable entering it on the parent's behalf.

Based on the v1 demo, it appears a single account can support multiple homes. This is worth confirming, and if so, it is worth understanding how the app handles switching between homes and whether device setup is scoped clearly to a specific home throughout the flow.

Is address used for anything functional in the product (emergency services integration, regional settings) or is it purely for identification purposes?

How does risk level get determined? Is it self-reported by the installer, selected from predefined options, or assessed through a short questionnaire? The answer affects how much guidance the app needs to provide at this step.

Does any of the resident profile information influence the onboarding flow itself (for example, does a high risk level affect the room recommendation), or does it only affect ongoing alert thresholds after setup?

Where does the parent's consent live? Is it captured in the app, or is it assumed to happen in conversation between family members? This is a product ethics question as much as a UX one.

Should the app prompt the installer to confirm they have spoken with the parent before continuing? A simple checkbox ("I've discussed this with [name]") would signal that Pontosense takes this responsibility seriously.

A 78-year-old who has fallen twice getting up in the night has completely different monitoring needs from someone whose main concern is bathroom safety during the day. The app cannot know that without asking. Placing this prompt right after the parent profile is created means the installer is already thinking about their parent as a person with specific circumstances, which is exactly the right headspace for this conversation.

If the parent is present during installation (which they sometimes will be), this is also a natural moment to include them. The brief focuses on the adult child as the primary user but does not say the parent is absent. A prompt that explicitly invites their input here is consistent with the parent awareness step at the end of the flow, and makes the overall experience feel more like a family decision rather than something done to the parent.

The prompt asks two or three plain-language questions: where does the parent spend most time alone, has there been a fall or a concern about a specific room, and what is the main thing the family wants to monitor. The answers do not need to feed into an algorithm. Even just prompting the conversation changes the quality of the room decision that follows.

This step adds no more than 60 seconds to the onboarding and sits entirely before any physical steps, so it does not affect the 10-minute installation time target.

Should the responses be saved and surfaced back to the installer later in the flow, for example during zone definition, as a reminder of what they said they were most concerned about? That would make this step feel purposeful rather than a prompt that disappears once you tap next.

Should this step explicitly prompt the installer to have the conversation with the parent before continuing, or is it designed to be completed whether or not the parent is present?

Explaining what radar cannot detect (faces, voices, identity) is just as important as what it can. Non-technical users may worry about surveillance, and this is the right moment to reframe the device as anonymous movement sensing rather than anything more intrusive.

The briefing uses plain language and a simple visual. No technical diagrams or radar terminology. The goal is a clear mental model, not engineering literacy.

A shareable summary is available after this step, something the installer can show or send to the parent to help them understand what has been set up in their home.

Does Pontosense have a preferred way of explaining radar to non-technical users? The language used here will shape how the parent understands the device for its entire lifespan.

Is there a risk that explaining the device's limitations makes it feel less capable than it is? It would be useful to know whether there is any user research on how to frame this well.

Surfacing this before any physical steps prevents mid-install abandonment. Someone who discovers they need a tape measure after they have already started drilling is much more likely to stop and not come back.

This step is placed after the radar briefing rather than at app open because the checklist items are more motivating once the user understands why they matter. A tape measure makes more sense after learning about the 4 m bedroom placement rule.

Checklist items include: a tape measure, the Wi-Fi network name and password, a pencil for marking the wall, wall anchors and screws, and optionally a second person to help hold the device during installation.

Are wall anchors and screws included in the box, or does the user need to source them? This affects both what goes on the checklist and whether the 10-minute install estimate is realistic.

This flow is designed around a single device per household. Room selection is therefore a consequential, one-time decision rather than a repeatable step.

If multiple devices are supported, is there an "add another device" loop after setup is complete? Would the second device require full recalibration, or could it inherit room data from the first?

Is this a one device per home product, or one per room? This is a pricing and product question with direct consequences for how room selection is framed in the onboarding.

A firm default recommendation (like "most families start with the bedroom") assumes the family has not already had the conversation about where the real risk is. It could easily nudge the installer toward the wrong room. The needs-framing step earlier in the flow is designed to surface exactly this information, so by the time the installer gets here they are equipped to make the right choice for their specific situation rather than following a generic default.

The app's role here is to present the considerations clearly: what each room enables in terms of monitoring, what the placement constraints are, and what the implications are if the decision needs to change later. The installer makes the final call.

Outlet access may constrain which room is actually viable. The app should surface this consideration before the installer commits, not after.

Does Pontosense have a clinical or product perspective on which room is the higher priority for the most common use cases? That context should inform how the considerations are framed on this screen, even if the app stops short of making a recommendation.

Is this choice reversible without losing calibration data? If moving the device means starting over, that needs to be communicated clearly at this step so the installer understands the stakes before they decide.

Showing only the rules that apply to the chosen room keeps the experience focused. A bedroom installer does not need the shower warning, and a bathroom installer does not need the 4 m bed distance rule. Room-gated instructions feel tailored rather than generic, which matters when you are trying to build trust with a non-technical user.

The 4 m check requires a tape measure, which the user has because of the pre-install checklist. The app illustrates this with a diagram rather than just stating a number.

Is the 4 m measured from the device to the bed frame, or to the centre of where the person actually sleeps? The app should be specific, since this directly affects calibration accuracy.

What if the ideal corner does not have an outlet nearby? Does the app offer a path forward (a different corner, guidance on extension cord use) or does it just block progress?

The shower exclusion is a hard constraint, not a preference. It should be shown as a clear illustrated rule with a "do not install here" visual, not buried in a list of tips where it could be missed.

Are there moisture or IP rating considerations to communicate? Does the device need to maintain a minimum distance from any water source beyond the shower enclosure?

For bathroom installs, what are the "key zones" the device actually monitors? Toilet proximity, shower entry, a general fall detection area? This needs product definition before zone calibration can be designed.

This step uses a static illustrated diagram with a short checklist: outlet within reach, unobstructed field of view, and correct distance from bed (bedroom) or clear of shower (bathroom). No AR overlay.

Is an AR camera overlay worth exploring for this user group, or would a well-designed static diagram be more reliable and less likely to create confusion for someone who is not technically confident?

Should the app show live Wi-Fi signal strength at this step, before the user commits to a location? If the signal is too weak at the chosen location, it is far better to surface that now than after the device is already mounted.

The brief confirms the device is wall-mounted but does not specify how. I am assuming the installation involves marking the wall, drilling, and attaching some kind of bracket before the device clips or screws into place. The actual mechanism needs to be confirmed, as it directly affects how many sub-steps this phase contains and how the instructions should be illustrated.

Step-by-step illustrated instructions are shown here, not a summary screen. Physical installation is the highest-risk moment for abandonment in hardware onboarding, so each sub-step gets its own screen.

The 10-minute installation target covers this physical phase only, not the full onboarding journey including account setup, briefing, and calibration.

What does mounting actually involve? Does it require drilling, or is there an adhesive or no-drill option? The answer significantly affects who can realistically install the device and what tools they need.

Is there a printed quick-start card in the box, or is the app the only instruction source? A fallback matters for users who lose phone signal partway through.

Would a time estimate at this point ("about 5 minutes left") help reduce drop-off? Progress indicators can make a meaningful difference in multi-step flows where users cannot see the end.

I have placed tilt validation before Wi-Fi pairing because tilt is a hard block: if the angle is wrong, the device will not work regardless of whether Wi-Fi succeeds. Catching this first means the user only goes through the pairing process (which tends to be the most anxiety-inducing step for non-technical users) once the device is confirmed to be physically set up correctly. A tilt failure mid-pairing would feel like wasted effort and is a likely abandonment point.

That said, this ordering assumes the device can communicate tilt data to the app via Bluetooth before Wi-Fi is established. If the hardware does not support that (for example, if tilt data is only readable over Wi-Fi), then the order would need to flip and Wi-Fi pairing would have to come first. This is a technical constraint that needs to be confirmed with the engineering team before the flow is finalized.

Does the device communicate tilt data over Bluetooth before Wi-Fi is established, or does tilt data require a Wi-Fi connection to reach the app? The answer determines whether this ordering is even technically possible.

If Wi-Fi must come first for technical reasons, how do we handle the scenario where a user completes pairing only to then fail tilt validation? What does that recovery look like without it feeling like the earlier pairing effort was wasted?

Is tilt shown as a live reading, or just pass/fail? A live angle display would let the user make precise adjustments rather than guessing whether they have moved it enough.

The error state needs a visual showing what a correct angle looks like next to an incorrect one. Text alone is not enough, since most users have no intuition for what "out of range" means in practice.

The retry here is a short loop: adjust the bracket and recheck. If the bracket itself is the structural problem, the user should be offered a path to contact support rather than being asked to keep trying.

Pairing uses Bluetooth to bootstrap the Wi-Fi connection so the user does not need to manually enter credentials on the device itself.

Does the device support 5 GHz networks, or 2.4 GHz only? This is one of the most common failure points in hardware pairing and should be communicated clearly before the user attempts to connect.

How does the app handle mesh networks or homes with multiple SSIDs? Users who are not technically confident may not know which network to choose, or may accidentally select a guest network.

Is there a QR code or WPS pairing option for users who find manual network selection difficult?

The brief specifically calls out Wi-Fi failure as a known abandonment point. The error state here needs to offer a genuine recovery path (tips, alternatives, a save option) rather than a dead end that leaves the user with a mounted device they cannot use.

The device is already mounted at this point, potentially in a private room in someone else's home. The installer may be visiting for the day, may not live nearby, and may not be able to return the same week. Treating Wi-Fi failure as an expected scenario rather than an edge case changes everything about how this screen is designed: the error screen needs to feel like a safe stopping point, not a dead end, and the re-entry experience needs to automatically route a returning user back to the right place without them having to remember where they left off.

This has implications beyond the UI. A pause state requires the backend to persist saved setup state across sessions, and the app to recognize a mid-setup user on re-launch and route them accordingly. These are product and engineering requirements that flow from this design decision, and they need to be flagged early.

Recovery suggestions shown in this state: move the router closer, use a Wi-Fi extender, check that the correct network band is selected, and confirm the device is within range.

How long does saved setup state persist? If the installer cannot return for two weeks, is their progress still there? And what happens if a firmware update ships in the meantime?

If the app had shown live signal strength during the placement step (before any mounting), this failure could often be prevented entirely. Is a proactive signal check at the placement step worth building into the flow?

This step uses a guided tap-to-define interface where the user draws walls and marks furniture on a schematic floor plan, rather than relying on automatic scanning. The 10-20 cm accuracy requirement makes precision input important.

Does the app accept room dimension inputs, or does it rely entirely on the user drawing? If drawn, how does a finger tap on a small screen achieve the required accuracy?

Can the device contribute to its own room mapping through an initial radar sweep, or is all input manual at this stage?

The 10-minute installation budget applies to the physical mounting phase only. Calibration is a separate phase and should be given the time it needs. Framing it as "worth getting right" helps manage user impatience without understating the importance.

The accuracy requirement is communicated in plain language ("mark the centre of where the person actually sleeps, not just the general area of the bed") rather than in centimetres, which is not meaningful to a non-technical user.

Does the app give real-time feedback on zone accuracy as the user maps, or is accuracy only assessed after they submit? Live feedback would significantly improve the quality of what gets captured.

For bathroom installs, what exactly are the "key zones"? Toilet proximity, the shower threshold, a general fall detection perimeter? This needs product definition before the UX for this step can be finalized.

A fast but inaccurate calibration produces a device that technically works but generates unreliable alerts. That erodes trust in the system over weeks and months in a way that is very hard to recover from. Getting someone to remount a device is a solvable problem. Getting them to trust alerts again after too many false ones is much harder. The flow therefore treats calibration as worth whatever time it takes, and the 10-minute installation budget is explicitly scoped to the physical mounting phase only.

This is a values decision as much as a design one. It reflects a view that the product's long-term credibility depends on getting this right at setup, and that saving a few minutes here is not worth the downstream cost of a system the family stops trusting.

How is accuracy scored? By the device, the app, or against a stored baseline? And who defines what counts as "good enough," given that different room sizes and layouts may require different thresholds?

Is the check instantaneous, or does it require a period of stillness (for example, 30 seconds)? This affects pacing and what the user needs to be told to expect at this point.

The error state should pinpoint which zone is inaccurate, not just show a generic "try again" message. Targeted feedback means the user can fix the specific problem without redoing everything.

Given how much calibration errors affect downstream accuracy, an "accept anyway" bypass should either not exist or require the user to explicitly acknowledge the consequences before proceeding.

Alert defaults are pre-set by room type: bedroom installs default to sleep-focused thresholds, bathroom installs to movement and fall detection. Users can adjust these after setup.

Are the defaults good enough that this step could be optional, with a "customize later" path for users who do not want to make these decisions at the end of a long installation? Forcing threshold decisions at this moment adds cognitive load when the user is likely already tired.

Who receives alerts? Only the installer, or all linked family members? If multiple contacts are supported, there needs to be a way to configure this without overwhelming everyone.

This is the only point in the journey where the installer is still in the app, still engaged, and still thinking about the setup. An async alternative relies on them following through after the fact, which most people will not do once they have left the parent's home and moved on with their day. Making it part of the flow means it happens while the motivation is still present.

A parent having a monitoring device installed in their bedroom without being walked through what it does can easily feel like surveillance, even when the intent is care. Placing this step in the flow signals that Pontosense takes the parent's awareness seriously as a product value, not just a nice gesture. It also differentiates the product from monitoring tools that treat the person being monitored as secondary to the person doing the monitoring.

The app provides a shareable summary screen in plain language that the installer can show or send to the parent. It covers what the device monitors, what it cannot detect, who can see the data, and how to contact Pontosense with questions.

Should this step be skippable or required? Making it required is the stronger signal of product values, even if it adds a small amount of friction. Making it optional means most installers will skip it, which defeats the purpose of including it in the flow at all.

Is consent captured in the app, or does it happen verbally between family members and live outside the product entirely? Depending on the jurisdiction, this may have legal implications worth understanding early.

If the parent is not present during installation, does the app support an async path where the installer can share the briefing with the parent after the fact, and track whether it has been opened?

The completion screen should show a first live reading right away, as proof that the device is actually working. An empty data screen at this point feels anticlimactic and raises doubt about whether the installation succeeded.

What does the "next steps" content actually include? Tips for interpreting the first week of data? How to adjust alerts? How to add a second device? The completion screen is the handoff to the ongoing product experience and deserves thoughtful design.

Is there a follow-up touchpoint 24-48 hours after install (a push notification or email) that checks in and offers guidance? First-week drop-off is a real risk and worth designing against proactively.

What does the ongoing experience look like for the installer? Are they notified of all alerts, or only critical ones? Alert fatigue is a real risk that the product needs a clear strategy for.

Is there a path to remount or recalibrate without losing historical data? If the parent rearranges their room or the device needs to move, what does that recovery flow look like?

How does the product handle major life changes, like the parent moving to a care facility or the device being passed on to another family?