# Smart Home Control for Shared Households > Who may add a device, remove a housemate, or override someone mid-use? The questions existing smart-home apps don't answer. - **Case study:** https://yazdanjoo.de/projects/smart-home-control - **Author:** Sanaz Yazdanjoo (UX Engineer) - **Role:** UX Researcher (team of 4) - **Year:** 2023 - **Timeline:** SoSe 2023 - **Status:** published - **Context:** University course project - **Summary outcome:** Two think-aloud sessions turned verbatim quotes into four documented design changes, each shown as a before-and-after pair. A Paper-Prototype Study of the Social Layer: Who May Add, Share, and Govern Devices ## About A four-person course project at Bauhaus-Universität Weimar (summer semester 2023) about what smart-home apps get wrong about shared living. The design problem was never device control — existing apps solve that. It was the social layer of a shared household: who may add a device, who may remove a housemate, who may override someone else mid-use. A questionnaire study (24 responses) framed the territory, a 12-screen paper prototype made a governance model tangible, two think-aloud sessions tested it, and four design changes — each documented as a verbatim participant quote, the change it prompted, and a before/after photograph pair — closed the loop. ## Challenge Smart-home apps model a home as one owner and a set of devices. A shared flat fits neither assumption: residents come and go, devices belong to some people and are used by everyone, and the moment two people want the same lamp at once is a social negotiation, not a technical conflict. The project framed exactly that gap — membership, permissions, and simultaneous use — as the design problem. ## Solution A 12-screen paper prototype covering four documented task flows, all anchored on one home screen. Onboarding runs scanning → naming → access → confirmation, with a three-step progress indicator that deliberately stops at the confirmation screen. Governance is built into the everyday paths rather than an admin area: who may use a device is chosen at setup, residents are invited by link, and a device in use can be locked while in use — resolving simultaneous access without a queue. The galleries below show the tested v1 version, grouped by flow. ## Design The revision is the most documented part of the project. Both test transcripts were coded into four categories — positive feedback, negative feedback, questions, ideas and suggestions — and four changes were made, each traceable to a verbatim quote from the sessions. They are shown below exactly as they happened: the quote, the change it prompted, and both photographs — the tested v1 screen on the left, the revised v2 screen on the right. The revision also fixed a defect the test itself exposed only indirectly: the resident roster differed across three v1 screens — two residents on one, three on another, five on a third, with the same person written “Drake” on one card and “Jake” on another. The v2 screens normalise the roster everywhere. ## Methodology Phase 1 — Discovery. A questionnaire (Google Forms) was chosen over interviews, focus groups, and shadowing: it fit the timeline, and it let respondents answer at their own pace, which supported confidentiality and autonomy. It was piloted with a small group before distribution to check for ambiguity and leading questions; consent was obtained and responses were anonymous. Questions were sequenced deliberately — demographics, then habits, then needs — so respondents were not steered toward an attitude about smart homes early. Of 30 people approached, 24 responded. Roughly a third reported difficulty syncing devices; a quarter named remote adjustment of settings as a persistent pain point. Segmentation produced two named groups — students and part-time employees, and full-time employees — plus an “others” bucket, each with a documented attitude toward smart-home apps and a separate attitude toward mobile services generally. The user profile explicitly included cognitive, visual, and mobility impairment: accessibility was scoped at discovery, not bolted on later. Phase 2 — Evaluation. Two think-aloud sessions in a controlled setting, each participant seated individually with a facilitator. Audio was recorded and photographs taken; participants were briefed on recording and anonymity. The facilitator used probing questions when participants went quiet and observed facial expressions; each session ended with a retrospective debrief. Participant A — 31, a junior software developer. Participant B — 43, with a degree in an unrelated field. Both are iOS users; neither had used a smart-home app before. Transcripts were coded into four categories: positive feedback, negative feedback, questions, and ideas/suggestions. ## Results The findings worth keeping are the ones that did not become quick fixes. A dead end surfaced in a flow we thought was finished: Participant A selected both devices at the scanning step, but only one carried into setup, and the confirmation screen had no way back — she noticed immediately and asked what had happened to the second device. Frames were read as the only tappable things: Participant B tapped only elements with a visible button border, engaging the boxed room selector on the device settings screen and treating the unframed rows beside it as labels. Destructive actions produced anxiety before they produced errors: encountering “delete this room”, Participant A worried aloud about triggering it accidentally and proposed moving room management to a dedicated screen — a structural objection, not a cosmetic one. The method itself was a finding: both participants needed to backtrack, neither could do it while holding the cards, and both ended up laying the prototype out on the floor — A sorting it into order first, B improvising late. And both participants opened every screen by reading its title aloud, which is why the “which home am I in?” gap surfaced on four separate screens. Two participants is a thin sample, and the original report says so. Revisiting the artifacts, the resident roster inconsistency across three tested screens is a defect a heuristic review would have caught before it reached a participant. The same revisiting surfaced a documentation lesson: most of the report's session photographs turn out to show the revised cards rather than the ones tested — the set was re-photographed after the changes were made. The sessions themselves are evidenced by the transcript and by the four changes that came out of them, but I'd now photograph artifacts at the moment of testing rather than afterwards. ## Limitations - Two think-aloud participants is enough to expose a dead end and a misread affordance, not to establish how often either occurs or how severe it is. The original report says so, and no wider round followed. - Both testers were iOS users who had never used a smart-home app, and neither was tested inside an actual shared household — the social situation the design is about was described to them, not lived during the session. - The questionnaire (24 of 30 people approached) was distributed through the team's own reach, so it framed the territory and named pain points; it was never a representative sample of shared-flat residents. - A paper prototype cannot produce the conflict the project is about: no device latency, no second resident acting at the same moment. Simultaneous use could only be walked through, never experienced. - The v2 revision was never put in front of a participant, so the four changes are reasoned responses to observed problems — not changes shown to have fixed them. - The photographic record is weaker than the sessions were: most session photographs in the report show the revised cards, because the set was re-photographed after the changes. What was tested is evidenced by the transcript, not by the photos. ## Participant Voices > "Now I can go to the device… but what happened to the other device that I selected two steps ago? … there is not even any back button here…" > — Participant A, screen E — discovering the onboarding dead end > "I'm worried about this option... What if I delete it accidentally?" > — Participant A, screen F (room view) — on “delete this room”, before proposing a dedicated room-management screen > "what can I do with this radar? Is it clickable?" > — Participant B, screen B — the frames-are-tappable pattern, in his own words ## Key Numbers - **24** — questionnaire responses (of 30 people approached) - **2** — think-aloud usability test participants - **12** — screens across 4 documented task flows - **4** — design changes made from test findings ## Outcome A university course project — adoption in the product sense doesn't apply. What the course closed on is the revised v2 prototype: four changes, each documented as a participant quote, the change it prompted, and a before/after photograph pair. The revision itself was never put in front of another participant — re-testing it is where a next session would have to start. ## Methods - Questionnaire study (N=24) - Think-aloud usability testing (N=2) - Low-fidelity paper prototyping - Qualitative coding & thematic analysis - Information architecture & flow mapping - Iterative design revision ## Tech Stack - Google Forms ## Skills & Topics Questionnaire Study · Think-Aloud Testing · Paper Prototyping · Qualitative Coding · Thematic Analysis · Information Architecture · User Flow Mapping · Iterative Design · Accessibility · Smart Home · Google Forms