Values in Defaults and Interfaces

By the end of this lesson, you will be able to...

• Trace a value from a system promise to a default, threshold, label, metric, or friction point.

• Compare two interface choices by asking who gains convenience and who carries the burden.

• Review whether a control is visible, contestable, reversible, and supported by evidence.

Idea in one sentence: Interfaces do not only show a system; their defaults and thresholds decide which behavior is easy, visible, measured, and difficult to contest.

Core Insight

The housing-support team has learned from Ana's case. They now want to redesign the application portal before the next enrollment period.

At the design review, the team presents four small changes:

1. The default contact channel is text message because it is cheap and fast.
2. The first upload field asks for the document most common in the historical dataset.
3. The status for an incomplete case is pending applicant action.
4. The dashboard counts a case as resolved when it closes, whether or not the applicant received support.

Each choice sounds operational. The team says the choices are neutral implementation details, not ethical decisions. But each one answers a value question:

• Is speed more important than reliable reach?
• Should the majority case define the first path?
• Does the status describe the applicant's situation or the department's workflow?
• Is administrative throughput a good proxy for successful access?

The choices do not announce their values. They place those values in the path of least resistance. A person can disagree with the policy and still be guided by the default, the label, or the threshold.

The Naive Idea: Values Live Somewhere Else

Teams often imagine a sequence like this:

values and ethics -> policy document -> neutral interface -> user behavior

In that model, the interface merely implements a decision made earlier. If the policy document says “serve residents fairly,” the controls are assumed to be fair unless the code has a defect.

The problem is that a policy is not the only place where a system makes a choice. The interface decides what a user sees first. A threshold decides when a case changes state. A label tells people how to interpret an event. A metric defines which outcomes count as success. A friction point makes one path expensive and another path easy.

The interface is therefore part of the policy's operation. It does not just communicate a rule. It distributes attention, time, privacy, access, and the burden of recovery.

From Value to Control Surface

Plain meaning:

A value is a concern about what should be protected, enabled, or distributed. A control surface is the place where a system makes that concern operational.

In this scenario:

“Make the service accessible” is a value claim. A multilingual form, a save-and-return path, and a human contact option are control surfaces that can support it. They do not guarantee access, but they give the value a visible place in the mechanism.

Technical name:

An encoded value is a value expressed through a repeatable system choice. It may appear in a default, threshold, label, ranking rule, metric, permission, or amount of friction. Encoding does not mean the designer secretly inserted a moral statement. It means the system repeatedly makes one possibility easier, more visible, cheaper, or more legitimate than another.

Use this table to locate the encoding:

The table is not a list of “bad” choices. It is a way to make choices inspectable before declaring the system neutral.

Where Neutrality Breaks

Return to the four redesign choices.

The text default reduces work for the department. It may also exclude applicants who share a phone, change numbers, have limited connectivity, or cannot safely receive messages there. An email default would redistribute the burden; it would not automatically be better.

The first upload field favors the most common document. That helps the majority case move quickly. It may make a less common but legally valid document feel like an exception, adding uncertainty to people already facing a harder path.

The label pending applicant action assigns the visible cause to the applicant. It hides the fact that the service chose the deadline, the contact channel, and the available recovery path.

The resolved metric turns a state transition into a service outcome. It can reward closing cases even when successful access is falling.

The system is not wrong because it contains choices. Every usable interface contains choices. The review question is whether the choice is appropriate for the promise, visible to the people affected, and open to correction.

A Worked Trace: One Default Becomes Four Outcomes

Consider Ana's next application. The portal has a default contact channel, a threshold, a label, and a metric.

Step 1: Input

Ana starts from a public computer. The form selects text message as the contact channel. She does not notice the small “choose another channel” link and continues.

The default has already made one assumption: a private, stable phone is available and safe to use.

Step 2: Transition

Ana cannot upload one document. The portal stores the case as missing_document and starts a seven-day timer. The timer is a threshold: after seven days, the case moves to closed.

The system does not ask whether the missing document is easy to obtain, whether the applicant can receive reminders, or whether a human review is required. Those questions have been removed from the normal path.

Step 3: Intermediate state

The dashboard shows pending applicant action. The caseworker sees a near-deadline item and a daily closure target. The label and metric make closure look like the applicant's unfinished work plus the worker's successful throughput.

Step 4: Output

The application closes. The department reports a resolved case. Ana experiences an inaccessible service and has to discover an appeal route that the interface barely exposes.

Step 5: Naive failure contrast

The technical-only explanation says:

Ana chose the default, missed the threshold, and failed to provide the document.

The encoded-values explanation asks:

Which assumptions did the default, threshold, label, and metric make easy to ignore, and who paid when those assumptions were wrong?

The second question does not prove that another design will succeed. It identifies the control surfaces where a design review can act.

Compare Choices Without Hiding the Burden

Suppose the team is considering three contact designs:

The third option may be preferable for a high-stakes service, but the table does not make it universally correct. A choice becomes responsible when the team says what improves, what becomes expensive, who bears the cost, and which signal would trigger revision.

This is the central trade-off: defaults reduce friction for the ordinary path, but they also exercise power over people who do not fit the ordinary case. Removing all defaults is not a solution; it can transfer cognitive and administrative work to the user. The design task is to choose defaults deliberately, expose important alternatives, and make correction possible.

A Small Values-to-Control-Surface Review

For each important system promise, write one row:

promise -> value at stake -> control surface -> affected group -> burden -> evidence -> revision trigger

For the portal:

people can complete an application
-> accessibility and agency
-> save-and-return, language choice, assisted contact, visible recovery path
-> applicants with unstable access, disabilities, or language barriers
-> extra design and support capacity
-> completion and recovery rates by access condition
-> pause automatic closure when silent exits or failed appeals rise

This format prevents a value from remaining a slogan. It connects the promise to a control, a group, a cost, and an observable boundary.

Common Confusions

Confusion: A default is neutral because users can change it

Why it is tempting: the alternative technically exists.

Better model: visibility, timing, effort, and confidence affect whether people can exercise the alternative. A buried option is not equivalent to an easy option for every user.

Confusion: Encoding a value means the designer intended harm

Why it is tempting: the language of values can sound like blame.

Better model: encoding describes a repeatable effect, not a claim about private motives. A well-intended default can still distribute burden badly. Review the mechanism and evidence before judging intent.

Confusion: More choices always create more freedom

Why it is tempting: a larger menu looks like more agency.

Better model: choices can add cognitive load, translation work, and decision friction. Agency requires usable options, understandable consequences, and a way to recover from a choice.

Confusion: A better metric removes the value conflict

Why it is tempting: measurement feels more objective than judgment.

Better model: a metric makes one outcome visible and others easier to ignore. Pair throughput with access, distribution, appeals, and harm signals rather than pretending the conflict disappeared.

Check Your Understanding

Check: A benefits portal changes its default from “share data with partner agencies” to “do not share,” but the opt-in explanation is written at a university reading level. What should the reviewer inspect?

Think first, then reveal.

Answer: The default protects privacy more strongly, but the opt-in friction may prevent people from accessing legitimate support. Inspect comprehension, language access, who bears the lost-service risk, and whether the alternative is genuinely usable.

Check: A team reports that average completion time fell after it moved the appeal link from the first page to a settings menu. What value may the new metric hide?

Think first, then reveal.

Answer: Speed may have improved for completed cases while contestability and recovery became harder. Check appeal discovery, closure reversals, and outcomes for people who needed correction.

Practice: Audit One Interface Choice

Choose one real or realistic system: a school enrollment form, a workplace scheduling tool, a tenant-maintenance app, or a benefits chatbot. Select one default, threshold, label, ranking rule, metric, or friction point.

Write a short values-to-control-surface review:

1. What promise is the system making?
2. Which value is at stake?
3. Where is that value encoded in the control?
4. Who benefits from the current choice, and who bears its burden?
5. What alternative would redistribute the burden?
6. What evidence would distinguish improvement from displacement?
7. What signal should trigger a review or rollback?

Use this rubric:

• Specificity: names an actual control, not “the system's ethics.”
• Distribution: identifies who gains convenience and who pays effort, risk, delay, or loss of privacy.
• Mechanism: traces input, transition, intermediate state, and output.
• Trade-off: compares at least two plausible designs without claiming a cost-free solution.
• Evidence: names a measurable signal and a revision trigger.

Resources

• [BOOK] Design Justice - Focus on how design choices center some people and distribute burden to others.
• [ARTICLE] Value Sensitive Design - Use its value investigation lens to connect stakeholder concerns to design controls.
• [BOOK] The Alignment Problem - Examine cases where an objective or metric diverges from the human outcome it was meant to represent.
• [ARTICLE] Dark Patterns - Use the examples to inspect how interface friction and visibility can steer behavior; do not treat every default as deceptive by definition.

Key Takeaways

• Values become operational through defaults, thresholds, labels, metrics, ranking, friction, and visibility.
• A default can be convenient and still exercise power over people who do not fit the ordinary case.
• Review a control by asking what it improves, what it costs, who bears the cost, and what evidence reveals the boundary.
• More choice is not automatically more agency; usable alternatives and repair paths matter.
• A responsible design makes important assumptions visible and keeps revision possible.