3.2 Impact of Program Design

What you need to know

• Programs are used by people, and design decisions can help or harm them. Programmers have a responsibility to consider effects on all potential users.
• Privacy: deciding what data to store, how long, and who can access it is a design choice. Storing less is safer.
• Security: keeping data private (encapsulation) and validating inputs reduces the chance of misuse.
• Accessibility and inclusion: programs should work for people with disabilities and across different devices, languages, and contexts. Assuming every user is like the developer produces exclusion.
• Bias: a program's logic and data can embed assumptions that treat groups unfairly; testing with diverse inputs and users helps surface it.
• Legal and ethical obligations include respecting intellectual property (citing code you use) and not collecting data without consent.
• These considerations apply during design, not as an afterthought.

Worked example

A class UserProfile stores name, email, and — because it was convenient — full date of birth and home address, all with public getters. Reconsidered: date of birth is only needed to check age, so store a boolean isAdult instead; make the address private with no getter since nothing needs it. Same functionality, far less exposure if the data leaks. That's design impact.

Going deeper

The nuance, edge cases, and connections that turn a 3 into a 5.

• This is Unit 3's ethics topic, and it's specifically about design decisions — what a class stores, who can access it, what it assumes about users. Unit 4 has a parallel topic (4.1) about data collection. Together they're the CSA equivalent of CSP's Big Idea 5.
• Data minimization is the design principle: store only what the program needs. Every extra field is a privacy risk if the data leaks and a maintenance cost if it changes. A class that stores a full date of birth to check "is 18+" should store a boolean instead.
• Encapsulation is a security tool: private fields with validating setters mean bad data can't get in. A public field can be set to anything by anyone. This is why 3.1's design advice and 3.2's ethics overlap.
• Accessibility means designing for people with disabilities (screen readers, motor impairments, color blindness) and for varied contexts (slow devices, small screens, different languages). A program that only works for users like the developer excludes everyone else. The fix is investigating users during design and testing with diverse people.
• Bias in program logic: a class whose validation assumes names have no spaces, ages are under 100, or addresses have a US format encodes assumptions. When the assumption is wrong for a group, the program fails for that group. Testing with diverse inputs surfaces this.
• Consent and transparency: users should know what a program stores and does. Storing data silently, even if legal, is an ethical problem the CED wants you to recognize.
• Intellectual property applies to code you use: cite libraries and borrowed code. On the exam this is conceptual; in practice it's licenses and attribution.
• The CED frames all of this as the programmer's responsibility. The correct answer to "who should consider these impacts" is the developer, during design — not a legal team afterward.

Mistakes that cost points

• Choosing the "collect everything" option. Minimization is always the responsible choice.
• Treating accessibility as optional polish. The CED treats it as a design responsibility.
• Assuming legal = ethical. The exam distinguishes them. A design can be legal and still irresponsible.

Practice questions

Written in the style of the real exam. Try each one before revealing the answer.