Mobility product teams: decide why you need data before collecting it

An operating record can contain more personal information than a builder first expects. A location history may reveal routines; a support request may contain a private concern; a payment record may expose financial circumstances. Access to a useful dataset therefore needs a clear purpose and an agreed boundary before it becomes a product resource.

A proposal to Sparrow Mobility Labs should explain what the builder wants to learn and which information is necessary to answer that question. “We may need it later” is a weak starting point.

Begin with a smaller information requirement

Work backwards from the decision. To test whether a handover is acknowledged promptly, a team may need event times and role labels rather than complete movement histories. For an early interface test, example records may be sufficient. Consider whether aggregation, shorter observation periods or less precise information could answer the question.

The OECD Privacy Guidelines organise data practice around collection limits, purpose, quality, safeguards and accountability. They provide a useful design framework; the permissions and legal requirements for a particular test still need to be established for that setting.

Make access understandable to participants

Describe who will see the information and what each person will use it for. Distinguish the operating team resolving an issue from a builder studying a pattern. A participant should not have to infer whether a private support conversation will become a product example or a presentation slide.

Use explanations that fit the people and circumstances. Provide a way to raise questions and correct inaccurate records. If the proposed use changes, revisit the arrangement before treating earlier access as permission for a new purpose. Account access and an agreed research use are different things.

Build safeguards into the working method

Assign access according to the task and keep shared copies under control. Avoid placing personal records in unrestricted demonstration accounts, presentation decks or broadly accessible team folders. Decide who can authorise an export and how the team will respond if information reaches the wrong recipient.

The same care applies when discussing Captain support. Someone asking for help may be sharing information for resolution, not for a wider study. Keep sensitive concerns separate from ordinary product feedback and share only what the relevant recipient needs to perform the agreed role.

Plan the end as carefully as the start

Set a review point for retained records and explain what happens when the test ends. Identify which material must remain for the agreed purpose, which can be removed and how derived summaries will be handled. A useful learning record need not preserve every personal detail collected during the work.

Before sharing findings, check whether examples or small groups could still identify someone. Preserve the limits of the evidence as well as the result. Responsible data work helps the team learn without turning operating access into an open-ended entitlement to people’s information.