Privacy by design is not a privacy review before launch. It is the product making different decisions because privacy was considered from the beginning.
Privacy by design is often discussed too abstractly
Product teams hear phrases such as privacy by design, data minimisation, purpose limitation and user control.
All of them sound correct.
The problem is that principles do not automatically translate into tickets, acceptance criteria, database fields or API behaviour.
A product manager still has to decide:
- Which data fields are necessary?
- Which are optional?
- When should notice appear?
- How should purposes be separated?
- What happens if a user declines one purpose but accepts another?
- Which downstream system receives the preference?
- What should happen when the user later changes it?
Unless privacy changes these design decisions, it remains an external review rather than part of the product.
Start with the purpose, not the form
A common product workflow begins with a screen:
We need a registration form. What fields should it contain?
A privacy-by-design workflow starts one step earlier:
What are we trying to achieve?
Then:
What is the minimum personal data needed for that outcome?
This small change matters.
If the purpose is account recovery, perhaps a mobile number or email address is needed.
If the team also wants date of birth 'for future personalisation', that is a separate purpose and should be treated as a separate product decision.
Purpose should drive collection.
Collection should not create the purpose afterwards.
Every field should have a reason
One useful product discipline is a personal-data field register.
For every significant field, the team records:
- Field name
- Data category
- Business purpose
- Mandatory or optional
- Collection point
- System of record
- Downstream use
- Retention trigger
- User control
- Owner
This may sound administrative, but it creates design clarity.
Teams often discover fields that exist because an old version of the product used them, because a stakeholder once requested them, or because a template included them.
Removing unnecessary collection improves both privacy and product simplicity.
Notice should be part of interaction design
The DPDP framework requires notice to inform the Data Principal about the personal data and the purpose for which it is proposed to be processed, along with information about exercising rights and making complaints.
That means notice is not simply legal copy.
It is also an interaction-design problem.
- When is the user most likely to understand the decision?
- How much information belongs at the first layer?
- How does the user access deeper detail?
- How should a purpose be worded so that it is specific without becoming unreadable?
- How do we avoid combining unrelated purposes into one decision?
Good notice design is a collaboration between legal, product, UX and privacy operations.
Consent should influence product state
If a user says yes or no, the product should behave differently.
That sounds obvious.
Yet many consent implementations store the choice in one platform while the actual product experience remains unchanged.
A mature design treats consent and preference as part of application state.
For example:
Marketing consent = No
could mean:
- promotional audience eligibility = false;
- marketing event export = blocked;
- campaign personalisation = disabled;
- marketing processor sync = stopped.
The design requirement is not merely 'capture consent'.
It is 'enforce the user's decision.'
Design the negative path before launch
Product teams are naturally good at designing the happy path.
User gives consent.
Account is created.
Feature works.
Privacy maturity shows up in the negative and changing paths.
- What if the user declines?
- Can the core service still work where appropriate?
- What if the user withdraws later?
- Does the interface explain the consequence?
- What if a purpose is retired?
- What if a child or other specially governed user flow requires different handling?
- What if a downstream integration fails to receive the updated preference?
These are product requirements, not post-launch compliance details.
Build privacy into the backlog
A practical privacy-by-design approach can turn privacy into ordinary product work.
Examples of backlog items include:
As a user, I can see the purposes for which my data is being requested.
As a user, I can decline an optional purpose without losing access to unrelated functionality.
As a privacy administrator, I can identify which notice version supported a consent event.
As a system, I propagate a withdrawal to all mapped downstream services.
As an auditor, I can reconstruct the decision trail for a specific processing activity.
Once written this way, privacy becomes testable.
Privacy acceptance criteria should be measurable
Consider a story:
'Allow users to withdraw marketing consent.'
Weak acceptance criteria:
User can switch off marketing.
Strong acceptance criteria:
The current consent state is displayed.
The withdrawal can be completed without unnecessary friction.
The timestamp and purpose are recorded.
The CRM eligibility flag updates.
The marketing platform receives the change.
No new promotional campaign is triggered after the control takes effect.
The audit trail records successful propagation.
A failure creates an operational exception.
This is privacy by design becoming engineering.
Product teams are where policy becomes real
Privacy teams can define the rule.
Legal teams can interpret the law.
Security teams can protect the data.
But product teams decide what the user actually experiences and what the system actually does.
That makes them central to privacy maturity.
The goal is not to turn every product manager into a privacy lawyer.
The goal is to give product teams enough structure, metadata and reusable controls that privacy decisions become part of normal product development.
iConsent's architectural role is to support that translation: from purpose and notice to user choice, system state, downstream action and evidence.
Privacy by design works when it stops being a slogan and starts appearing in the requirements.
