Ambient Intelligence: Sensor Dashboard
The number of US adults over 60 is set to double by 2050, outpacing the caregivers meant to support them. Ambient intelligence, a network of in-home sensors that tracks daily activity, is one way to help them age in place safely.
To run a study like that in real homes at The Sequoias, I designed and built two linked dashboards on a shared backend: one giving residents direct control over every sensor, the other letting researchers catch failures before any data is lost.
TL;DR
The number of US adults aged 60 or older is expected to double by 2050, while the workforce of caregivers needed to support them keeps shrinking. One response is aging in place through ambient intelligence: a network of sensors and tools around the home that monitors daily activity so older adults can stay independent longer.
This project sits inside Stanford HAI's ambient-intelligence research program, a privacy-preserving sensing platform that combines wearables, environmental sensors, and vision (where appropriate) with an LLM voice assistant and a caregiver app to support both older adults and the people who care for them. The broader study runs as a longitudinal deployment in real homes at a partner independent-living community, The Sequoias.
Putting always-on sensing into someone's home immediately raises the question of privacy and surveillance. My piece of the platform is a human-centered control layer that lets both researchers and participants maintain control over the sensors, so the data the study depends on is both trustworthy and consented to. I designed and built two dashboards on a shared backend, then evaluated them and scoped the path to live deployment.
Role
End-to-end: design of both dashboards and the full-stack prototype behind them.
Context
HCI research project within the Stanford HAI ambient-intelligence study, built for the testing phase at The Sequoias.
Stack
React clients for both dashboards, a shared FastAPI service, and Google Cloud for storage and the data pipeline.
Two users, one pipeline
A researcher fleet-monitoring view and a participant control view, built on the same backend so a participant's choice and a sensor's failure live in the same data.
In-home sensing fails in two directions at once, and a single dashboard cannot serve both. I framed the work around two distinct users with opposite needs.
The researcher problem: silent failure
Across many sensors in many homes, there's no way to see sensor health at a glance. A researcher might only discover a silent sensor failure after the data is already lost, a study-killing risk at deployment scale.
The participant problem: feeling surveilled
As an older adult's daily movement is tracked by sensors, wearables, and cameras, they need a transparent way to understand how their data is used and to control collection directly, without feeling watched in their own home.
Grounded in prior fieldwork
I situated the design in existing literature on how older adults and caregivers actually respond to in-home sensing. Two studies shaped the entire approach.
Green et al.
Workshop with professional caregivers
Participants raised that continuous sensing could make them feel surveilled and erode their decision-making autonomy. Some proposed being able to turn the system off in specific rooms to preserve safe spaces.
Design implication
The ability to disable sensing is not a convenience feature but a precondition for the system being accepted at all, pointing to a human-in-the-loop model where the people being sensed help configure the sensing.
So et al.
CSCW, "They Make Us Old Before We Are Old"
Older adults often read assistive technology as a sign of their own decline, so tools meant to support aging can reinforce a deficit model of it. Participants wanted to track how their data was used, to opt out, and, critically, for the connected services to actually work.
Design implication
Infrastructure reliability and participant trust are the same concern from two sides. This justified a researcher dashboard: catching sensor failure early is what keeps the study trustworthy for participants.
Infrastructure reliability and participant trust are not separate concerns; they are the same concern viewed from two sides.
The result is two dashboards built with a human-centered AI approach, deliberately separate in audience and stance, but joined underneath by a shared backend. The separation is the design: each side gets an interface shaped entirely around its own user, while every consent change and every failure flows through one pipeline.
Researcher dashboard: built for triage at scale
For a team running a deployment across many homes, nearly every choice answers a practical question someone on the team actually raised. It is organized around each participant's floor plan, because researchers need to see where a sensor physically sits to service it. Sensors show raw readings alongside a summary statistic, since researchers want to inspect the data themselves rather than trust one metric. Participant identity is protected even within the team; names stay hidden until a researcher deliberately hovers to reveal them.
Participant dashboard: transparency and control
The participant view takes the opposite stance for the same human-centered reason. The user is an older adult who has invited a sensing system into their home and needs visible control over it. Each sensor reads simply as on or off in a large, readable font, designed for people who may not be confident with technology. A sensor the participant has not consented to appears greyed out rather than removed, because seeing the disabled sensor is what makes their control legible; hiding it would quietly take that sense of control away.
One shared backend
Both apps are independent React clients reading from and writing to the same FastAPI service. When a participant toggles a sensor off, the backend records both the consent change and the time it occurred, and the researcher dashboard reflects it within seconds. A participant's decision and a researcher's view of that sensor are never out of sync.
The two platforms ship as a deployed researcher dashboard and a deployed participant dashboard. Here are the features that carry the most product weight on each side.
Researcher platform
Onboarding.The participant enrolment process is a four step flow that integrates consent and system setup. First, the participant's details are entered. Next, the researchers can upload an image of a LIDAR scan of the room and mark the location of each sensor in the floor plan, as well as write a placement note to help them remember the location. Third, a participant's consent is collected across all sensors. For example, a participant can consent to motion sensing and environmental monitoring while declining a sleep wearable or cameras in common areas, and the interface registers this mixed state explicitly as partial consent rather than flattening it into a yes or no. Finally, a confirmation page allows researchers to confirm their choices and begin collecting sensor data.
Floor plan viewis the default entry point. Each sensor appears as a status-colored dot on the participant's home layout, so a researcher reads location and health together, and placement notes attached to a sensor help a staff member find the physical device when they need to service it.
All sensors view is the aggregate counterpart. Rather than inspecting one home at a time, a researcher can step back and see key themes across the entire sensor fleet at once, which supports a cross-home triage workflow instead of a per-participant one.
Sensor detail modal. By clicking into a dot on the map or a sensor card on the slide, a sensor detail modal shows up as a color-coded timeline of collecting, gap, and offline states, a sparkline in which gaps render as breaks rather than zeros, and the four metrics that matter most: connection uptime, data completeness, gap count, and longest gap. The modal also holds tagged researcher notes and any participant-reported issues for that sensor.
Participant panel and participant record handle enrollment and oversight. The left panel lists everyone enrolled with their ID, age, and a color-coded consent status (Full Consent, Partial, Withdrawn), while the participant's full name is not shown until it is hovered. A free-text notes field lets researchers attach observations to the person rather than to a sensor. This makes the human-centered commitment to consent concrete, since consent here is itemized, attributed, and revisable rather than assumed once at signup. Scrolling down, a researcher can send reminders to the participant. Opening the record reveals a reminders section headed by the running total sent, a control to send a new reminder, and a link into the full history. When sending one, a researcher chooses the reason, whether to complete the daily survey or to turn a sensor on or off, and can attach an optional message. On the participant dashboard the reminder arrives as a dismissible banner, and dismissing it marks it read so the unread indicator clears on the researcher side. Each participant also carries a reminder count that shows up on the side, so the team can see at a glance how engaged that person is.
Resident requests tray. Participants can fill out a Google Form to send a request or feedback, and these requests will automatically show at the bottom of the request tray, so a researcher can see it and quickly resolve the issue.
Participant dashboard
PIN loginreplaces a full username and password with a short PIN, because a PIN is easier for an older adult to remember, and the longer term intention is to keep the dashboard permanently signed in on the participant's own tablet so even the PIN becomes unnecessary.
Floor plan with on/off controlis the main view. Each sensor shows as simply on or off in a large, readable font, designed for participants who may not be confident with technology, with a control to withdraw or restore consent for each one. When a researcher sends a reminder through their portal, it shows up as an orange banner on the participant's side, where they can dismiss, or see past reminders. While depth cameras and WYZE cameras are not being controlled in this dashboard, in the future a link will be added so clicking on the button directs them to the camera app, fulfilling the purpose that this dashboard is a comprehensive dashboard.
By clicking into the information icon on each sensor, the participant can see what data that sensor collects and why, along with its location on the map so the participant can physically go look at it. This gives complete transparency and control without crowding the default view or making the participant feel surveilled.
With both dashboards deployed, I ran a System Usability Scale study with four users ranging from older adults to peers. I adapted the SUS to each dashboard, asking participants to rate statements from 1 (strongly disagree) to 5 (strongly agree), for example, “I thought it was easy to find information about a specific participant or sensor” and “I felt confident monitoring sensor health and participant issues using this dashboard.”
What the data showed
Researcher side: two of four agreed it was “unnecessarily difficult to identify which sensors required attention”, traceable to all sensors rendering red in this half-hardcoded prototype, and to the all-sensors view surfacing too much at once. Other statements landed positively, including ease of finding a specific participant or sensor and learnability.
Participant side:everyone found it easy to use and most agreed an older adult would learn it quickly. One participant wasn't sure of the difference between turning a sensor off and never consenting to it.
The fix it surfaced
That last point sharpened a design rule: when a participant never consented to a sensor, its control is greyed outrather than toggleable, making the distinction between “turned off” and “no consent given” legible at a glance. On the researcher side, the all-sensors view needs tighter information density and real (not hardcoded) status colors so attention routes to the sensors that actually need it.
Four steps stand between the current prototype and a live deployment at The Sequoias.
Live data pipeline. The system processes data on demand from manual uploads today, and Empatica wearable data is still pulled and checked by hand once a day. The backend is linked to Google Cloud but needs to be wired so data is pulled on a ~2-minute cadence instead of hardcoded.
Data persistence. Participant records, researcher notes, and consent state currently live in memory and are lost on restart, acceptable for a prototype, not for a study that runs for weeks. These move to durable cloud storage.
Privacy & security.The backend currently runs with open CORS and no auth beyond the participant PIN, while handling data adjacent to PHI under IRB and HIPAA. Deployment requires proper access control and a review against the project's own privacy commitments.
Physical configuration.The floor plan is a generalized model from the Sequoias website. Accurate per-home sensor locations require a real LIDAR scan of each participant's home to replace the placeholder.