Ambient Intelligence: Sensor Dashboard
Stanford HAI · Ambient Intelligence Lab
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 monitors 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 monitor each sensor data and catch broken sensors before data loss.
Abstract
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.
Both the participants and researchers need their own set of platforms with the same underlying backend and data:
The researcher problem
With multiple sensors across many homes, there's no single place to check whether they are still running. A researcher can find out a sensor broke days after the data is already gone, risking the study.
The participant problem
In their own home, an older adult's daily movement gets picked up by sensors, wearables, and cameras. They need to see how that data is used, and control that collection themselves.
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.
So et al.
CSCW, "They Make Us Old Before We Are Old"
Older adults often see assistive technology as a sign of their own decline, so tools meant to support aging can reinforce a self fulfilling prophecy of decline. It is important to enable this platform to give back autonomy rather than taking it away.
The result is two separate dashboards built with a human-centered AI approach sharing the same backend pipeline for sensor status
Researcher dashboard: built for triage at scale
I worked with the research team to build a platform with features that was deliberately molded to each of their custom research needs. The dashboard is organized around each participant's floor plan, because researchers need to see where a sensor physically sits to service it. Sensors show both raw readings and a summary statistic, since researchers want to inspect the data themselves rather than trust one metric. Even inside the team, participant names stay hidden until a researcher hovers to reveal them.
Participant dashboard: transparency and control
The user is an older adult who has invited a sensing system into their home and needs visible control over it. Each sensor reads as on or off in a large, readable font, for people who may not be confident with technology. A sensor the participant has not consented to is greyed out rather than removed, because seeing it sit there switched off shows them that they are in control, affirming their autonomy.
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 is synced to reflect the change in consent.
Researcher platform
Onboarding. The participant enrolment process is a four-step flow that integrates consent and system setup.
Enter the participant's details.
Upload a LIDAR scan of the room, mark each sensor's location on the floor plan, and add a placement note to help researchers remember where it sits.
Collect consent across all sensors. A participant can agree to motion sensing and environmental monitoring while declining a sleep wearable or cameras in common areas. The interface registers this mixed state explicitly as partial consent rather than flattening it into a yes or no.
Review choices on a confirmation page, then begin collecting sensor data.
Floor plan view is 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 shows the aggregation of all sensors in all homes. 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 four key metrics: 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), and full names stay hidden until a researcher hovers over it. A free-text notes field lets researchers attach observations to the person rather than to a sensor. Further down the record, a researcher can send reminders to take the daily survey. The reminder reaches the participant dashboard as a dismissible banner, and dismissing it marks it read, which clears the unread indicator on the researcher side. A reminder count also sits next to each participant in the side list, so the team can see 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 researcher's screen, so a researcher can see it and quickly resolve the issue.
Participant dashboard
PIN login replaces a full username and password with a short PIN, which is easier to remember. 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 control is 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.
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.
Four steps stand between the current prototype and a live deployment at The Sequoias.
Live data pipeline. Wire Google Cloud to automatically pull data in 2 min cadence rather than on demand manual uploads or data pulls.
Data persistence. Move participant records, researcher notes, and consent state to cloud storage rather than in memory.
Privacy & security. Implement access control, restrict CORS, and add authentication beyond participant PIN to align with the project’s privacy commitments.
Physical configuration. Upload real LIDAR scans of each participant's home rather than using a generalized floor plan from The Sequoias website.