Most products treat privacy as a legal task. The product gets designed and built, and near the end someone writes a privacy policy describing what it turned out to collect. By then the important decisions have already been made: there's an account system, an analytics SDK, a server holding everything, and a policy that can only describe them.
We think that order is backwards. Where data lives and who can read it shapes the architecture, the features, the onboarding, the pricing and even the support process. It's a design decision, and it belongs at the start.
Start with a data map, not a wireframe
Before we sketch a screen, we write down every piece of information the product will touch. For each one we answer three questions: where is it created, where is it stored, and who can read it? It's a plain table, but filling it in changes the conversation.
"We'll need an account" stops being an assumption and becomes a choice with a cost. An account means storing an email address and a password, resetting forgotten passwords, handling breaches and answering deletion requests. Sometimes that's worth it. Often it isn't, and the product is simpler without one.
Every field you collect is a promise to protect it, for as long as you keep it.
The device is a capable place to work
A decade ago, anything clever had to happen on a server. That's no longer true. Phones and laptops now ship with fast processors, dedicated machine-learning hardware and on-device models for speech and language. Search, transcription, summaries and classification can all run where the data already is.
When the work happens on the device, the privacy story becomes short and easy to believe. There's no server to breach, no retention policy to enforce and no data request to answer, because there's nothing on our side to hand over. It also tends to make the product faster and lets it work offline.
Say no to the default SDKs
Much of the tracking in modern apps isn't there because anyone decided to track people. It arrives bundled with crash reporters, analytics dashboards, attribution tools and advertising libraries, each added for a reasonable-sounding reason. Together they send a steady stream of behavior to companies the user has never heard of.
We start with none of them, and add something only when we can explain exactly what it sends and why. Usually there's a quieter alternative. Apple, for example, shares crash reports with developers only from people who've opted in to sharing analytics with them, and it does so without an extra SDK.
Make the trade-offs visible
Privacy has real costs, and pretending otherwise erodes trust. If data never leaves the device, then losing the device without a backup means losing the data. If backups are encrypted with a passphrase only the user knows, a forgotten passphrase can't be recovered by anyone.
The honest design response is to state these trade-offs plainly, at the moment they matter, and to give people the tools to manage them: an easy, free, encrypted backup, and clear words about what happens if it's lost. People can handle the truth. What they don't forgive is finding it out later.
Design the policy alongside the product
When privacy decisions are made early, the privacy policy almost writes itself, and it's short. It can describe what the product does rather than list everything it might do. We write ours in plain language, with a summary at the top a reader can trust, and we keep it in step with the product so the two never drift apart.
A short, specific policy is one of the strongest signals a product can send. It tells people the team thought about their data before they built anything, not after.
A checklist we use
- Can this feature work without an account?
- Can this processing happen on the device?
- Does every third-party library earn its place, and do we know what it sends?
- If data must leave the device, is it the minimum, and is it encrypted?
- Can people export everything they've made, and delete it?
- Have we told people the trade-offs in plain words?
None of this is exotic. It's ordinary product design with one more question asked early: what's the least we need to know?
Eiderlane designs and builds apps and websites. Read more in the journal, or see how we work.