Safety, Privacy, and Trust

The team now knows what success looks like. The next question is what the software must protect while it helps people.

Why This Matters

Software can help people, but it can also expose information, create mistakes, or damage trust if it is careless.

Safety, privacy, and trust are not extra features. They are basic requirements.

Core Idea

Good software protects people, keeps private information private, and behaves in ways people can trust.

Comparison

Weak approach	Strong approach
Safety added later	Safety considered early
Privacy treated as optional	Privacy built into the design
Users must guess what happens	Clear and respectful behavior
Trust assumed	Trust earned

Worked Example

A clinic system may hold appointment details, contact information, and notes. If the wrong person can see those details, trust is damaged even if the software still works.

Good design asks who should see what, what should be protected, and what could go wrong if the wrong thing happens.

Common Mistakes

Treating privacy as a legal footnote.
Thinking security only matters after launch.
Exposing more information than people need.
Assuming users will always understand the risk.
Building trust through promises instead of behavior.

Checklist

What information must stay private?
Who should be protected from harm?
What could go wrong if the software is misused?
What would make people trust the system less?

Small Exercise

Pick one software idea and ask:

What must not be exposed?
Who could be harmed if something goes wrong?
What design choice would increase trust?

Summary and Next Step

Safety, privacy, and trust belong near the start of the path because they shape every later choice.

Next, learn how information is kept and found.

What Information It Needs