Apple Reintroduced Its Design Principles. Read the One About Delight.
Eight principles returned to the Human Interface Guidelines on 8 June. Four of them are sharp enough to cut with, and two of them score my own product badly.
Date
Category
Writer
On 8 June, Apple quietly did something I did not expect. It put design principles back into the Human Interface Guidelines. The change log entry is two words, Reintroduced design principles, which is a very Apple way to mark a shift in how a company wants to be argued with.
This matters more than a documentation update usually would. For most of the last decade the HIG has been a reference manual: here is a tab bar, here are its metrics, here is when to use it. Useful, and entirely tactical. Principles are a different kind of document. They are what you reach for when the manual does not cover your case, which is every interesting case.
So I read them properly rather than skimming, and then did something more useful: I held each one against the product I am currently building and wrote down where it fails.
Video. "Principles of great design," Apple Developer, WWDC26. The session the HIG page links to.
The eight, and what each one actually asks
Stated flatly they read like anyone's values deck. The value is entirely in the sub-clauses.
Principle | Apple's one-liner | The demand underneath it |
|---|---|---|
Purpose | Make something meaningful | Be able to say what the product is for, at every stage |
Agency | Let people do things their own way | No locked flows, and cheap recovery from mistakes |
Responsibility | Act in people's best interest | Collect only what the product needs, and say why |
Familiarity | Build on what people know | Borrow existing metaphors rather than inventing |
Flexibility | Adapt to diverse contexts and needs | Accessibility from the start, and every input method |
Simplicity | Be clear and direct | Every element earns its place |
Craft | Care about every detail | Maintenance is design work, not cleanup |
Delight | Make it human | Know which emotion you are aiming for |
Table 1. The eight principles as published, June 2026.
Four clauses sharp enough to cut with
"Simplicity isn't minimalism"
The full text: "Simplicity isn't minimalism. Aim for a focused, useful experience that keeps the important things close by and lets the others fall away."
This is the line I want printed and stuck to a wall, because the conflation it corrects is the most common self-deception in our field.
Minimalism is a visual style and it is cheap to fake. Remove elements until the screenshot looks calm, ship it, and let the user absorb the complexity you pushed off the screen into a settings pane, a gesture nobody discovers, or a support article. The screenshot is the deliverable and the screenshot looks great.
Simplicity is a judgement about which things are important, which requires knowing what the product is for and being right about it. One is a filter applied to a canvas. The other is a decision with consequences.
I have shipped minimalism and called it simplicity. Most people reading this have too.
"Help people recover from mistakes"
Under Agency: "When people know they can reverse an action or return to a previous state, they feel free to explore, and that freedom makes your interface more inviting."
What I like here is that the causal claim is not the obvious one. Undo is normally justified defensively: people make mistakes, let them fix them. Apple's framing is offensive. Undo is what makes exploration affordable in the first place, and the value is delivered continuously to people who never once press it.
That reframing changes the economics of building it. A recovery mechanism nobody triggers is not an unused feature with poor adoption. It is a permission that was granted, and the evidence that it worked is that people did things they would otherwise have hesitated over. Which is, inconveniently, not measurable.
"Don't mistake delight for decoration"
Under Delight, and the most self-aware sentence on the page: "don't let pursuit of delight for its own sake get in the way of your product's core purpose."
I have a pixel cat in my product. This line is addressed to me personally.
The test it implies is not is this charming. It is does this charm sit between the person and what they came for. Those produce different answers surprisingly often. The cat passes only because it occupies no path: nothing must be dismissed to get past it. The moment a delightful element requires an interaction to clear, it has become a toll.
"Shipping isn't the finish line"
Under Craft, and the paragraph treats maintenance as a design activity rather than an engineering one. It ends: "Design is an ongoing commitment."
Easy to nod at. Considerably harder to accept that it means the quality bar applies to work nobody will ever praise you for, on a surface nobody will screenshot.
Where my own product scores badly
Two, and I would rather write them here than have someone else find them.
Familiarity: a self-inflicted tax
"Use concepts that people know. People bring knowledge of the real world and other software to every new experience."
JEFIELD deliberately refuses folders, tags and categories. That is the single most familiar organising metaphor in computing, understood by every person who has ever used a computer, taught implicitly by every operating system since 1984.
I refuse it for a reason I still believe in, which is that classification at the moment of capture is a tax charged when you are least able to pay it. But I should not pretend the refusal is free. It is a direct and continuing cost to familiarity, paid by every first-time user, and no amount of philosophy makes it disappear. The principle is not wrong. I am knowingly trading against it, and a trade you have named is a strategy while a trade you have not named is a mistake.
Flexibility: a failure I did not discover for months
"Consider a variety of input methods. People interact with their devices in different ways."
For most of this year JEFIELD's entire capture mechanism was paste and drag. Neither gesture exists on a touchscreen. HTML5 drag and drop does not fire for a finger at all.
So the product was, functionally, a desktop application wearing a responsive layout. Everyone building it was building it on a desktop, every screenshot looked correct at phone width, and nobody noticed for months. I will write that one up on its own, because the failure is more interesting than the fix.
Why principles are useful at all
Apple's own framing, in the opening paragraph, is unusually modest and I think exactly right:
"There's no one right way to apply these principles. Instead, they're tools to help you weigh competing priorities and make key decisions on the path to a great design."
This is the difference between a principle and a rule, and it is worth being precise about it.
A rule tells you what to do. Rules stop working the moment the situation is novel, which in product work is most of the time, and their failure mode is that people follow them into obviously bad outcomes because the rule said so.
A principle tells you what you are trading away. That keeps working forever, because the trade is the thing you actually have to decide. Familiarity against purpose. Simplicity against flexibility. Delight against clarity. Craft against shipping.
The list is not a checklist to pass. It is a set of axes to be honest on, and the honesty is the deliverable.
A note on the reintroduction itself
One last observation, about the timing rather than the content.
Principles get removed from documentation when a company is confident and reinstated when it is not. That is not a criticism. It is the correct response to a period where the range of things being built has widened faster than any component library can cover. When your guidance has to serve interfaces that are spatial, conversational, ambient and traditional at once, the tab bar metrics stop being the useful part, and you have to go back to saying what you believe.
Every studio hits this eventually. Ours did. The moment you cannot answer a new brief from the existing system, the system was never a system. It was a collection of past answers.
Sources
Apple. Design principles, Human Interface Guidelines. Reintroduced 8 June 2026. developer.apple.com/design/human-interface-guidelines/design-principles
Apple. Principles of great design, WWDC26 session 250. developer.apple.com/videos/play/wwdc2026/250
Apple Developer. “WWDC26: Principles of great design.” youtube.com/watch?v=Xa9L2yx_QH8
Related reading
Latest Articles.
© Moc Mallen Studio
Thoughts, ideas, and perspectives on design, simplicity, and creative process.
