FREE COMPUTER SCIENCE STACK LEVEL · 17 OF 20

People, interfaces & ethics

How do you know a system is usable, accessible, and worth building?

The question this layer answers

How do you know a system is usable, accessible, and worth building?

Design for human tasks and consequences. This layer connects Task analysis, Accessibility, Experiments, Privacy, Professional responsibility to the rest of the computing stack.

Design for human tasks and consequences

Study real tasks, build accessible interactions, and assess outcomes with evidence. Treat privacy, fairness, and professional responsibility as design constraints with owners and observable consequences.

How do you know a system is usable, accessible, and worth building?

This section is a sequence of worked studies. Each study asks you to reconstruct an example, solve a new problem, and check the assumptions behind your answer. Keep your derivations and code so you can revisit them without looking at the solution.

What you will work through

1. User research and task analysis

Study the work people are trying to do before choosing controls. Separate goals from proposed features. Analyze a task and its failure points. Identify limits of a research sample.

2. Accessible structure, focus, and feedback

Make the same task operable through different input and perception modes. Use semantic controls and labels. Plan keyboard focus across state changes. Explain why automated checks are incomplete.

3. Usability evidence and controlled experiments

Choose measurements that answer a question about learning or task success. Distinguish usability tests from A/B tests. Define a metric and guardrail. Recognize selection and novelty effects.

4. Privacy, fairness, and data minimization

Analyze who bears the cost of collecting data and making predictions. Apply purpose limitation to a data flow. Compare group-level error rates. Explain why one fairness metric is incomplete.

5. Professional responsibility and technical decisions

Make consequences, uncertainty, and accountability part of engineering work. Identify affected stakeholders. Write an evidence-based impact assessment. Document a reasoned go or no-go decision.

Before you begin

Basic software design. Each lesson names any additional prerequisites. Revisit the mathematics and programming sections whenever a calculation or execution trace becomes a barrier.

Evidence of understanding

Evaluate a learning interface using task observations, a keyboard walkthrough, a data-flow inventory, and a written impact assessment. Revise the design and record what evidence changed your decision. A correct multiple-choice answer is only one kind of evidence. Preserve the intermediate steps, test an edge case, and explain why an attractive alternative fails.

Continue beyond the guided lessons

The primary readings provide fuller treatments and additional exercises. Work the section project after the guided problems, then return to a problem a few days later without notes. Use a failed attempt to identify the specific definition, assumption, or step that needs more practice.

Free People, interfaces & ethics lessons

Practice lab: Audit one complete keyboard task

About 35 minutes. Basic web navigation; no programming required.

Use a local form or prototype with a text field, submit action, validation error, and success message. Do not collect real personal data.

  1. Complete the task using only the keyboard.
  2. Record focus order and how each field is named.
  3. Trigger an error, correct it, and verify that feedback is perceivable.
Hint

Inspect the task after both success and failure, not only the initial screen.

Worked solution

An acceptable result uses logical focus order, visible focus, labeled controls, and a submit action reachable by keyboard. Errors identify the problem in text and connect it to the relevant field while preserving input. Success is communicated without relying only on color. Record any focus loss or trap and propose a specific correction. This walkthrough finds concrete issues but does not certify accessibility for every user or assistive technology.

  • All required actions work without a pointer.
  • Focus stays visible and does not become trapped.
  • Errors and success have meaningful text.

Change one assumption

Repeat at 200% zoom. Which assumptions about available space fail?

Evaluate whether people can complete the task

Connect interface decisions to observable behavior, accessible operation, privacy, and consequences for different users.

1. Study design · allow 40 minutes

A preference is not a successful task

A team interviews five enthusiastic existing users, asks “Do you like our new enrollment screen?”, and concludes that the redesign will help first-time students. Design a study that can support or refute that claim. Specify participants, realistic tasks, success criteria, observations, and how to avoid teaching the interface during the test. Distinguish a formative usability study from an experiment estimating a population effect.

Get a starting hint

Observe an action with a concrete endpoint. Existing enthusiasts are not automatically representative of first-time students.

Compare your reasoning with the worked solution

Recruit participants from the intended first-time population, including relevant device, language, and accessibility needs. Give a realistic goal such as finding a course with a prerequisite and enrolling in an available session, using a scenario that does not name the controls to click. Define success before observing results: correct course and session, no unintended enrollment, and comprehension of next steps. Record completion, errors, assistance, time with context, and participants' explanations. Ask neutral follow-ups after the attempt and do not coach unless the protocol records the intervention.

A small formative study can reveal concrete obstacles and inform redesign; it does not reliably estimate a population-wide percentage improvement. For a causal comparison, randomly assign eligible users to versions, use comparable tasks and exposure, choose the primary outcome in advance, and report uncertainty and exclusions. Avoid treating satisfaction as a substitute for task success. A result may show that a visually preferred screen increases mistaken enrollments. Keep identifiable recordings only as long as needed and obtain appropriate participant consent.

Check your reasoning

  • Recruit for the claimed user population.
  • Define observable success before testing.
  • Separate discovery of problems from estimation of causal effect.

2. Interaction audit · allow 35 minutes

A dialog must remain operable without a pointer

A course enrollment dialog opens visually, but keyboard focus stays on the background page. Its close control is an unlabeled icon, errors appear only in red, and closing it moves focus to the top of the document. Specify an accessible interaction sequence from opening through validation and closing. What should be checked manually in addition to an automated accessibility scan?

Get a starting hint

Track focus, accessible names, error relationships, and the user's original task. Visual appearance alone does not expose state to assistive technology.

Compare your reasoning with the worked solution

Open the dialog from a keyboard-operable control with a clear name. Move focus into an appropriate initial element, give the dialog an accessible name, and ensure background content is not accidentally interactive while it is modal. Keep keyboard navigation within the modal interaction, provide a named close control, and support the expected dismissal behavior without discarding work unexpectedly. On validation failure, identify each error in text, associate it with its field, and provide a useful summary or focus strategy when multiple fields fail. Do not communicate the error only through color.

On close, return focus to the invoking control if it still exists, or to a logical successor if the action changed the page. Announce successful enrollment through appropriate status feedback and update the visible state. Manually test keyboard order, visible focus, zoom and reflow, screen-reader names and announcements, dismissal, and error recovery. An automated scanner can detect some missing semantics but cannot establish whether the focus destination makes sense or whether a user can complete the task.

Check your reasoning

  • Specify the complete focus lifecycle.
  • Make errors textual and programmatically associated.
  • Test task completion with keyboard and assistive technology.

3. Calculate and question · allow 45 minutes

One overall rate conceals different errors

A scholarship screening model has group A: TP=80,FN=20,FP=20,TN=80; group B: TP=40,FN=60,FP=10,TN=90. Compute accuracy, true-positive rate, and false-positive rate for each group and overall. Would equalizing approval rates alone establish fairness? Propose an evidence and appeal process, and explain how collecting more sensitive attributes can create a privacy trade-off.

Get a starting hint

Specify what the labels mean and whether they are trustworthy. Different error measures answer different normative questions.

Compare your reasoning with the worked solution

A has accuracy 160/200=80%, TPR=80/100=80%, and FPR=20/100=20%. B has accuracy 130/200=65%, TPR=40%, and FPR=10%. Overall accuracy is 290/400=72.5%, TPR=120/200=60%, and FPR=30/200=15%. Approval rates are 100/200=50% for A and 50/200=25% for B. The aggregate hides the much higher missed-positive rate for B.

Equal approval rates alone would not establish fair treatment: labels may reflect historical exclusion, groups may contain unmeasured variation, error costs differ, and satisfying one statistical criterion can conflict with another. Investigate label construction, missing data, deployment consequences, and performance for relevant intersections with adequate uncertainty. Provide understandable reasons, a meaningful human review or appeal route, and a process for correcting data. Sensitive attributes may be needed to detect disparities, but collect only what is justified, restrict access and retention, separate audit use from operational decision use where appropriate, and assess whether the audit itself creates risk. A numerical metric informs a decision; it does not settle the ethical judgment.

Check your reasoning

  • Compute group and aggregate rates with correct denominators.
  • Question labels and consequences.
  • Provide recourse and a justified data-minimization plan.

4. Decision record · allow 35 minutes

Write a decision another engineer can challenge

A learning app proposes ranking students publicly by study time. The team expects more engagement, but offline study is unmeasured, time can be inflated, and some students share devices. Write a technical decision record with the intended benefit, affected groups, failure modes, alternative designs, a reversible trial, and stop criteria. What evidence would distinguish learning from merely leaving the app open?

Get a starting hint

A proxy becomes a target when people are rewarded for it. Define an outcome closer to the educational purpose.

Compare your reasoning with the worked solution

The intended benefit is sustained learning, while study time is only a noisy proxy. Public ranking can reward idle sessions, penalize efficient or offline learners, expose behavior, and misattribute shared-device activity. Alternatives include private personal goals, optional cohort challenges, and progress based on meaningful practice with user control over visibility. A reversible trial should be opt-in, limit retained data, avoid high-stakes consequences, and let users remove their participation.

Choose evidence closer to learning: delayed retrieval or transfer tasks, correction of prior errors, and voluntary sustained practice, with attention to gaming and unequal access. Predefine stop criteria such as increased unwanted disclosure, complaints about coercion, substantial subgroup harm, or engagement gains without learning gains. Record who owns the decision, which uncertainties remain, and when it will be reviewed. A reasonable conclusion may be to reject public ranking even if it increases session minutes. Ethical responsibility includes declining a technically feasible optimization when the measured target conflicts with the product's purpose.

Check your reasoning

  • Separate the proxy from the intended benefit.
  • Evaluate concrete alternatives and affected users.
  • Specify reversible rollout and observable stop criteria.

Study the underlying methods

Section project: Evaluate an accessible learning flow and its data choices

4 to 6 hours. Design and evaluate a small learning-platform flow: find a lesson, understand prerequisites, mark progress, and resume later. Produce a paper prototype or local HTML prototype with no external services. Inputs are a task scenario, stated learner needs, and representative curriculum data; outputs are two design alternatives, an evaluation record, a revised prototype, and a brief data-impact assessment. Include a learner using only a keyboard and a learner unfamiliar with the subject sequence. If consenting participants are available, conduct a small task-based observation with permission and record anonymized observations. Otherwise perform a documented cognitive walkthrough and accessibility inspection, clearly labeling it as an evaluator review rather than user research. Do not invent participants, quotes, success rates, or disability experience. Define what progress means and explain which information would be stored locally or in an account, why it is needed, and how it can be corrected or deleted. The goal is evidence-based iteration and explicit tradeoffs, not a polished screen without a tested learning task. Include signed-out and signed-in states if the prototype presents account features. Make clear which progress survives refresh or a device change, and test that the interface communicates the actual storage behavior.

Milestones

  1. Write task scenarios, success conditions, learner assumptions, and two genuinely different navigation alternatives.
  2. Build one testable prototype and document keyboard order, labels, and progress semantics.
  3. Run consented observation or a clearly labeled evaluator walkthrough and record actual findings.
  4. Revise the prototype in response to the most consequential observed problems.
  5. Write a data-minimization and impact note covering retention, correction, deletion, and potential misinterpretation of progress.

Acceptance criteria

  • Every interactive control in the HTML version is reachable and operable by keyboard, with visible focus; paper alternatives include an explicit keyboard interaction specification.
  • A learner can locate prerequisites, open a lesson, mark it complete, and find the next or resumed activity without an unexplained dead end.
  • The evaluation record distinguishes observations from interpretations and identifies the method actually used.
  • At least two concrete design changes are linked to recorded evidence or a documented accessibility defect.
  • Completion labels describe a recorded action and do not claim demonstrated mastery without a corresponding assessment.
  • The data inventory justifies each collected field and includes a workable correction and deletion path.

Implement both navigation alternatives locally and compare them with the same task script, reporting individual observations and limitations instead of unsupported statistical claims.

Practise People, interfaces & ethics free →