Design the System Behind a Smart-Scale Weight Tracking App and Staff Its Team

You are the product manager for a new mobile app that connects to bathroom scales: when someone steps on their scale, the reading should reach the app, which displays a chart of how their weight has changed over time. Describe the system you would design to make this work, and the kind of team you would want building the product. ### Clarifying Questions - Are we building our own scale, or should the app work with scales from several manufacturers, and do those scales talk to the phone over Bluetooth or upload readings themselves over home Wi-Fi? - Can several people in a household share one scale, so the system must work out whose reading it is? - Does the scale report only weight, or other body measurements too? - Is this a consumer wellness app, or will doctors or health programs rely on the data, which would raise the bar for accuracy and compliance? ### Part 1 — Design the system Explain the components between the scale and the trend chart: how a reading travels from the device to the app and to any backend, how it is stored and tied to the right person, how the chart is built, and how the system behaves when something fails. ```hint Follow one weigh-in Trace a single reading from the moment someone steps on the scale to the moment it appears on their chart, including the cases where the phone is out of range or the same reading arrives twice. ``` #### What This Part Should Cover - The end-to-end data flow, the sync approach and the data model. - Reliability, correct attribution, and the privacy and security of health data. - How the chart turns noisy daily readings into a trend people can use. ### Part 2 — Build the team Describe the team you would assemble: the roles you need, why this product needs each of them, and how the team would change from the first release to later stages. ```hint Let the design staff the team Each layer of your design, plus the sensitivity of health data, calls for particular skills; ask which are needed from day one and which can wait. ``` #### What This Part Should Cover - Roles mapped to the layers and risks of the system, with a reason for each. - How the team's size and mix evolve over time. ### What a Strong Answer Covers - A design anchored in the user's goal of understanding their weight trend, not technology for its own sake. - Concrete choices on connectivity, offline sync, deduplication and storage, with their trade-offs. - Explicit handling of health-data privacy, consent and the emotional sensitivity of weight. - A team plan that follows from the design and the product's risks. ### Follow-up Questions - Two people in a household weigh within a kilogram of each other. How does the system decide whose new reading it is? - A user reports that last week's readings disappeared after switching to a new phone. Where in your design could that happen, and how do you prevent it? - How would the design change if users could share their readings with their doctor?