Making App Data Tangible

My master’s thesis at the FH St. Pölten Master in Interactive Technologies asked a specific question: can data from an everyday smartphone app be transformed into something physical, and does that physical form actually change how persuasive the app feels? I built a prototype — a scoreboard with two motorised columns that mirror the points system of the household-management app Flatastic — and ran a two-week between-subjects field study with six households to find out.

The problem

Apps that use persuasive design — fitness, finance, habits, household management — rely on the user opening the app for the persuasion to land. The data is there, the strategy is there, but it sits behind a screen lock and a tap. Prior data-physicalization research has shown that turning data into physical form makes it easier to perceive, easier to share, and easier to act on. But the existing body of work overwhelmingly uses sensor data collected for the physicalization (step counts, plant moisture, air quality). Only ~10 % of personal data-physicalization projects between 2010 and 2020 used data from an existing app, leaving an open question: can the persuasive strategies that already live inside apps be amplified by giving their data a physical form?

This thesis answered that question with two research questions: RQ1 — how can app data be transformed into a data physicalization at all? And RQ2 — what is the effect of doing so on perceived persuasiveness and user experience?

Why Flatastic

Flatastic is a household-management app that turns chores into a points-based scoreboard. It already uses several persuasive design principles — competition, self-monitoring, rewards — and its data has a property that matters for a physical translation: it is shared across roommates and benefits from being visible in the space everyone shares, not behind individual logins. Flatastic gave me an authentic, multi-user dataset with a built-in persuasive structure that I could then attempt to amplify.

Architecture

The hardware sits behind an ESP32-S3 (DevKitC-1, WROOM-1 module). Two 10 kΩ linear motorised slide potentiometers (Alps RSA0N11M9A04, 100 mm travel) act as the columns, driven by a TB6612FNG motor driver. Each column is illuminated from inside by an addressable WS2812B LED strip in a per-user colour. A 9 V / 1 A external supply powers the sliders, stepped down to 5 V for the microcontroller through an LM2596 buck converter. A PIR motion sensor wakes the device when someone enters the room, and the columns sit dormant otherwise — a deliberate choice to keep the device unobtrusive in a shared living space.

On the software side the ESP32 runs C++ on PlatformIO. It boots in dual Wi-Fi mode (Access Point + Station): on first launch it opens its own network and a captive-portal web UI guides the user through Wi-Fi credentials, login, and per-user column assignment. Once connected, the device polls Flatastic’s API on motion-triggered intervals, normalises each user’s points against an expected mid-cycle value, and drives the columns to a proportional height. A 14-day cycle resets the scoreboard automatically. Overdue tasks turn a column red, and — initially — caused it to move up and down to draw attention (more on that in what I’d do differently).

Decisions — and what I rejected

Microcontroller: Raspberry Pi Pico WH → ESP32-S3. I started with the Pico because of its size and price, but the captive-portal flow requires the device to run as access point and station at the same time, and the Pico’s Wi-Fi stack couldn’t sustain that reliably. The ESP32-S3 handled both modes without complaint and brought enough flash and GPIOs to fit the rest of the design.

Motor driver: L298N → TB6612FNG. The L298N was the obvious starting point — well-documented, easy to find — but it’s a bipolar-transistor design that wastes power as heat. Swapping in the MOSFET-based TB6612FNG dropped the heat output, improved switching speed, and shrank the footprint. In a long-running device sitting in someone’s living room, “doesn’t get warm” matters.

Power: battery → wall supply, 5 V → 9 V. The first version ran on 5 V, the same rail as the microcontroller, so I tried battery operation for placement flexibility. Two problems: the sliders had enough friction at 5 V that they occasionally stalled mid-stroke, and battery operation for a device meant to run for weeks creates new failure modes (going dark mid-study is worse than not being there). I moved to a 9 V wall adapter and stepped down to 5 V for logic. System draw is ~130 mA at rest, ~300 mA peak during motor or LED activity — comfortable headroom on a 1 A supply.

Setup UX: companion app → captive portal. The default pattern for this kind of device is a companion mobile app. I rejected it because installing an app just to configure a single appliance is a hard sell, and apps die when phones change. A captive portal works in any browser on any device, requires no install, and uses a setup metaphor most users already recognise from hotel Wi-Fi. Discussion with field-study participants confirmed the choice — they all found it intuitive.

Three columns physically, two electrically. The 3D-printed body was designed to fit three columns, but I built the circuit for two. The field study targeted two-person households, and the third channel would have added cost and complexity without strengthening the answer to RQ2.

What the field study showed

Six households, two weeks, between-subjects design — three on Flatastic alone, three on Flatastic plus the physicalization. The dependent variables were perceived persuasiveness (Drozd et al. 2012 scale), user experience (UEQ-S), intrinsic motivation (IMI), and task-completion metrics.

The persuasiveness result was the cleanest. On day 7 the physicalization group scored a mean of 22.17 versus 13.67 for the App-only group — an 8.5-point gap, statistically significant at p = .03. The gap was still present at day 14 (20.50 vs 13.33). All physicalization households attributed their increased motivation to the device’s constant physical presence — they didn’t have to remember to open Flatastic; the state of the household was visible whenever they walked past the columns.

User experience split cleanly along the UEQ-S dimensions. Pragmatic quality — does it work — was statistically identical between groups (the app does the job regardless). Hedonic quality — is it enjoyable — was 6.71 versus 3.58. IMI Enjoyment moved in the same direction (18.67 vs 11.50). Roommates described the physicalization as “competitive and fun”; App-only households described their experience as functional but flat.

Task completion was more nuanced. The mean was higher in the physicalization group (47 vs 30), but with N = 6 the medians (31 vs 28) were close, and removing one high-completion outlier flattened the difference. The cleaner signal was overdue task delay — the physicalization group cleared overdue tasks ~18 hours faster on average (74.88 vs 93.33 h).

The strongest single finding from the focus groups: passive reminders work; active reminders annoy. The constant visibility of the columns was the feature every physicalization household praised. The overdue-task animation — columns moving up and down to demand attention — was universally described as too frequent and irritating. It scored lowest in the per-principle ranking among physicalization users.

What I would do differently

Drop the active reminder, or make it gentler. The animated overdue-task signal was the clearest design failure of the prototype. The data-physicalization itself already does the work of reminding by simply existing in the room — adding motion on top crossed the line from “ambient” to “nagging.” A future version would replace the animation with a quieter cue (a colour shift, perhaps), or skip the active reminder entirely.

Embed into existing objects. The strongest qualitative feedback was about furniture. Several households suggested integrating the columns into a clock, a shelf, or a piece of art. This matches the abstraction principle from Sauvé and Houben (2022): the most successful physicalizations blend into the room when not actively engaged. The standalone-gadget form factor I shipped works for a study but reads as “tech device” in a way that limits long-term adoption.

Test on hardware sooner, with cheaper proxies. The Pico→ESP32-S3 migration and the L298N→TB6612FNG swap each cost real time because I committed to a microcontroller and a driver before stress-testing the dual-Wi-Fi mode and the thermal behaviour. A cardboard mock with one column instead of two, validated in week three rather than month three, would have surfaced both problems earlier.

Test more households, longer. N = 6 over 14 days is enough for a thesis-scale field study but too small and short to generalise. The persuasiveness result held over the two weeks but showed a small downward drift in the physicalization group — a four- or eight-week study would reveal whether that’s noise or a genuine novelty effect. Recruiting beyond friends-of-friends would also broaden the household-routine variation that turned out to dominate task-completion numbers.

Pair with the developer. The thesis treats Flatastic as an arms-length data source. The honest production path is co-design with the app team — incorporating their visual language, their feature priorities, and the data they care most about surfacing. That collaboration would also unlock interaction in the other direction (modifying app data through the physicalization), which is the obvious next research step.

Supervised by FH-Prof. Dr. Wolfgang Aigner and Dr. Victor Adriel de Jesus Oliveira, FH St. Pölten. Source code, 3D models, and supplementary materials on GitHub.