Ethics is a design decision
AI ethics is the practice of making sure an AI-powered product treats people fairly, honestly, and without hidden harm — and in a product team, most of those choices are design choices.
It's tempting to treat ethics as someone else's job: legal reviews the terms, a policy team writes the principles, and the designer just makes the screens. That framing is comfortable, and it's wrong.
Think about where AI harm actually happens in a product: in a default switched on without asking, a disclosure that's technically present but visually buried, a confirmation step removed to make the flow "frictionless." The designer decides the defaults, the disclosures, and the friction — and those are exactly the levers where AI harm happens or doesn't.
A recommendation engine, a photo filter, a chatbot in a support flow: each one arrives at the user through an interface you shaped. If that interface hides what the system does, ethics failed at the design layer, no matter what the terms of service say.
-
keywords
- #Defaults
- #Disclosure
- #Friction
- #Responsibility
Bias in AI products
Bias is the most discussed AI risk, and the most misunderstood. It's rarely a villain writing bad rules — usually it's a system doing exactly what it was trained to do, on data that reflects an unequal world.
Where it comes from
AI models learn from data, and data encodes the inequities of the world it was collected from. If a hiring dataset reflects decades of skewed hiring, a model trained on it will reproduce that skew — confidently and at scale.
Bias also creeps in through what's missing. If a voice dataset contains few speakers of a particular accent, the model isn't neutral about that accent — it's simply worse at it. Absence in the data becomes failure in the product.
How it surfaces in products
In an interface, bias rarely announces itself. It shows up in small, testable ways: who the default settings serve, whose name breaks the sign-up form, whose face the camera feature doesn't recognize, whose dialect gets scored lower by a writing assistant.
Each looks like an edge case in isolation. Together they draw a line between users the product was really built for and users it merely tolerates.
The designer's checks
You can't retrain the model from the design seat, but you can catch bias before it ships. Test with diverse users and inputs: recruit beyond your convenient sample, and feed the feature names, photos, and phrasings from outside your own demographic. Question training-data provenance: ask the team where the data came from and who is underrepresented in it — if nobody knows, that's your answer. Watch aggregate outcomes: a feature can pass every usability session and still fail a group; review results split by user segment, not just averages.
A feature that works brilliantly for the average user and fails a specific group is not a good feature with edge cases — it's a biased feature.
-
keywords
- #TrainingData
- #Representation
- #DiverseTesting
- #Provenance
Disclosure and consent
Users deserve to know three things, plainly and at the moment it matters: when content was generated by AI, when they're talking to a machine rather than a person, and when their data will be used to train something.
Each of these belongs in the interface, not in the terms. A support chat should say it's automated before the first message. A "train on my data" setting should be a real choice the user makes, not a pre-ticked box discovered later.
Burying an AI disclosure in the terms of service is a deceptive pattern — legal cover is not the same as informed consent. You've already seen how deceptive patterns trade user trust for short-term metrics; hiding what an AI does is the same trade with higher stakes.
-
keywords
- #InformedConsent
- #Transparency
- #DataTraining
The synthetic-users debate
Synthetic users are AI-simulated research participants: a model prompted to answer your interview questions as if it were a person in your target audience.
Be fair to the idea before judging it. Synthetic users are genuinely useful for pressure-testing your research plan cheaply: rehearsing an interview script, spotting confusing questions, generating hypotheses worth checking. Rehearsal has value.
The danger begins when the rehearsal replaces the performance. Synthetic feedback is a remix of the model's training data — it can only tell you what's plausible, and it cannot surprise you the way a real user does. The moments that change a product — the workaround you never imagined, the frustration nobody predicted — come from humans. Use synthetic participants to sharpen your questions, then ask those questions of real people.
-
keywords
- #SyntheticUsers
- #RealResearch
- #Hypotheses
Energy and labor footprints
Two costs of AI stay invisible from the design seat, and honesty requires naming them. Running a model consumes energy every time a user triggers it, so a design that fires generation on every keystroke has a real physical cost that firing it on demand does not. And behind most models sits human labor: people paid to label data and review outputs, often for low wages. You don't fix either with a screen, and guilt isn't the goal — awareness is. Knowing the costs exist helps you avoid designs that spend them carelessly.
-
keywords
- #Energy
- #DataLabeling
- #HiddenCosts
Pushing back inside the org
Ethics only matters if it survives contact with a roadmap. The most practical tool you have is a question, asked calmly in every design review: "Who does this fail?" It reframes the conversation from average outcomes to specific people, and it's hard to dismiss without answering.
When the answer is uncomfortable, escalate with evidence, not opinion. A recording of a user hitting the failure, a test where the feature misreads a name, a segment-level result — evidence turns an ethical objection into a product defect, and teams know how to fix defects.
And sometimes the honest move is refusal. Declining to design a harmful pattern is a professional judgment, the same as declining to ship an inaccessible screen. Say what you won't build, say why, and offer the alternative you will.
-
keywords
- #DesignReviews
- #Evidence
- #Escalation
- #SayingNo
A designer's checklist
Before an AI feature ships, walk through these questions:
Defaults: Is AI on by default, and would users choose that if asked?
Disclosure: Can a user tell, in the interface itself, when content is generated and when they're talking to a machine?
Consent: Is data-for-training a real, unticked choice?
Bias: Have you tested with diverse users and inputs, and reviewed outcomes by segment?
Research: Did real humans validate anything synthetic participants suggested?
Cost: Does the design trigger the model only when it earns its energy?
Failure: Can you answer "who does this fail?" — and did you act on the answer?