A practice for shipping AI with your name on it.

The person who shipped it is responsible for it. Not the model. Not the system. Not the brief. The designer with their name on the artifact. I argue this in the book the way Don Norman argued it to me: in every other century, we have called architects accountable for the buildings they put their name to. We have not yet earned the right to a softer standard.

• Write the worst-case news headline a journalist could tell about this feature. If it names harm, redesign.
• In every review, ask the original question before the technical one: should this thing exist?
• When you sign off, say your name out loud. Hear it.

Designers, users, stakeholders, and the systems we build are part of the same loop. We don't get to opt out of consequence because we work in the abstract. Brenda Laurel told me she stopped arguing methodology long ago and started arguing the work itself: design as something we owe each other, not something we sell back to ourselves.

• Replace the language of us-versus-them with the language of we. Watch what it changes about the brief.
• For every requirement, find the human need underneath. Write the need above the requirement.
• Notice when a “conflict” is really an invitation to integrate two real perspectives.

Most design fails not because we got the future wrong, but because we missed the present. We designed for the user who has thirty unbroken minutes, when ours has four. Babak Parviz built devices that changed how people see the world; what I took from our conversation is that the discipline is paying attention to what is actually in front of you, not what your roadmap predicted would be.

• Design for the device the user actually holds, in the room they actually sit in, with the attention they actually have.
• Leave breathing room in the interface. Empty space is a feature.
• Run tests on bad Wi-Fi, with notifications on, after a hard meeting.

The systems we ship can fabricate convincingly now. The most dangerous design move in 2026 is to accept the polished answer. I wrote this chapter for the moment when an LLM hands you a confident research summary and you don't ask the second question. Kuldeep Kulshreshtha was more direct in our conversation: companies are firing user researchers and replacing them with a proxy that has never met a user.

• When the model hands you a confident answer, ask the next question. Then the next.
• Once a month, deliberately seek a perspective that contradicts your current direction.
• Spend an hour with someone who uses the product nothing like you do.

Care is the discipline of design, not its sentiment. The teams I respect most center the people most at risk from the thing they are building, and they do that work first, not last. Aahed Zarouk reframed the AI conversation for me around real data and real context: it is harder to design with care when the inputs are decorative.

• For every feature, name the person most vulnerable to it. Design from their seat.
• Replace empathy theater with one real conversation a week.
• Add the care decision to the design rationale, in writing. Make it traceable.

Inclusion is not the audit step. It is the foundational practice, and the way you know is by looking at who is in the room when the decisions get made. Carlos Cordero and Allison Leach gave me the phrasing I keep using: nothing about us without us. That is a responsibility, not compliance.

• Audit who is in the room at decision time, not at presentation time.
• Create more than one way for people to weigh in. Some won't write a doc; some won't speak in a meeting.
• Notice whose burden each design decision moves. Move it deliberately.

There is a paralysis showing up in our field that I have started calling AI terror. The way through it is not AI evangelism. It is staying open to what the medium can become while keeping a hand on what we still owe people. Faria Anzum gave me my favorite analogy: photography did not kill painting. It made room for abstract art.

• When a new capability shows up, spend one hour using it before you decide what to think.
• Stay open to feedback that contradicts the roadmap. The roadmap was always a guess.
• Build flexibility into the design so the next surprise doesn't break it.

Understanding goes past the research summary. It is the practice of holding several framings of the same problem in your head at once and refusing to collapse them too early. Cheryl Platz has spent her career keeping the human present inside systems that would otherwise route around us, and the discipline that takes is exactly the one this principle names.

• Hold the problem in three different framings before picking one. Write all three down.
• Spend extended time in the actual environment where the product lives. Notice what doesn't appear in the research.
• Listen for the story underneath the stated need.

This is the deepest principle, for me. Helen Edwards put it in language I have not been able to shake: what we choose to automate becomes meaningless, and what we choose not to automate is what stays meaningful. Soul, in this practice, is the discipline of deciding what we refuse to hand over.

• Before automating something, ask whether the meaning is in the doing.
• Connect every shipping decision to a deeper purpose, in writing. If you can't, ask harder.
• Design from love rather than fear. Both will write code; only one will be worth keeping.