Designers
The product and industrial designers whose ideas a founder can use when designing an MVP: Dieter Rams, Don Norman, Jony Ive, Tony Fadell, Charles and Ray Eames, John Maeda and Massimo Vignelli, organized by principle (simplicity, honesty, detail, feedback, affordance, storytelling, constraints) and ending in a design review checklist. Interface heuristics, layout and accessibility are on UX/UI design principles; the MVP design phase itself is product design. Jobs's own views are on Steve Jobs.
Who they are and why listen
| Designer | Known for | Key text | Why a founder should care |
|---|---|---|---|
| Dieter Rams (b. 1932) | Braun (joined 1955, head of design 1961–97); Vitsœ 606 shelving (1960) | ten principles for good design (late 1970s) | the clearest checklist for "is this good?" |
| Don Norman (b. 1935) | cognitive scientist; VP of Apple's Advanced Technology Group in the 1990s; co-founded Nielsen Norman Group | The Design of Everyday Things (1988 as The Psychology of Everyday Things; revised 2013) | why users fail, and why it's the design's fault |
| Jony Ive (b. 1967) | Apple 1992–2019 (iMac, iPod, iPhone, iPad, Watch); founded LoveFrom (2019) | interviews; Apple product films | simplicity as order, not absence; care |
| Tony Fadell (b. 1969) | ran Apple's iPod division; co-founded Nest (2010) | TED 2015 "The first secret of design is … noticing"; Build (2022) | noticing habituated problems; storytelling |
| Charles & Ray Eames | furniture, films and exhibitions (1940s–70s) | 1972 "What is design?" Q&A | design as working within constraints |
| John Maeda (b. 1966) | MIT Media Lab, RISD, then tech industry | The Laws of Simplicity (2006) | ten short rules for reducing complexity |
| Massimo Vignelli (1931–2014) | graphic, product and signage design with Lella Vignelli | The Vignelli Canon (2010) | discipline, meaning and consistency |
The common thread: good design is a set of decisions about what the product is, not decoration added at the end. That's why it belongs in the MVP, not after it.
Simplicity
Everyone on this page argues for simplicity; they mean different things by it.
| Principle | What it means | Source | Apply it by… |
|---|---|---|---|
| less, but better | "Weniger, aber besser": concentrate on the essential and don't burden the product with non-essentials | Rams, principle 10 (Vitsœ); also the title of his 1995 book | removing every screen, field and option that the core job doesn't need |
| simplicity is order, not absence | "True simplicity is derived from so much more than just the absence of clutter and ornamentation. It's about bringing order to complexity." | Jony Ive, iOS 7 introduction film, WWDC 2013 | grouping and sequencing necessary complexity rather than hiding it |
| real vs applied simplicity | "There's an applied style of being minimal and simple, and then there's real simplicity." | Ive, quoted in Wired News (2003) | checking that the simple look matches a simple model underneath |
| complexities, not complications | "We love complexities but hate complications!" | Vignelli, The Vignelli Canon (2010) | letting power exist, but never making the user manage it |
| subtract the obvious, add the meaningful | Maeda's tenth law, "The One" | Maeda, The Laws of Simplicity (2006) | cutting generic features and investing in the one thing only you do |
John Maeda's laws of simplicity
The ten laws as Maeda states them on lawsofsimplicity.com, with a founder's reading.
| # | Law | Maeda's summary | For an MVP |
|---|---|---|---|
| 1 | Reduce | the simplest way to achieve simplicity is through thoughtful reduction | cut features until the core job is obvious |
| 2 | Organize | organization makes a system of many appear fewer | group settings and actions; one primary action per screen |
| 3 | Time | savings in time feel like simplicity | measure and shorten time to first value |
| 4 | Learn | knowledge makes everything simpler | teach the one concept users need, in context |
| 5 | Differences | simplicity and complexity need each other | a power-user path can exist if the default path is clean |
| 6 | Context | what lies in the periphery of simplicity is definitely not peripheral | emails, receipts, error pages and support are part of the product |
| 7 | Emotion | more emotions are better than less | a little warmth in copy and visuals is not clutter |
| 8 | Trust | in simplicity we trust | good defaults users can trust, with undo |
| 9 | Failure | some things can never be made simple | accept irreducible complexity (tax, compliance) and support it well |
| 10 | The One | simplicity is about subtracting the obvious, and adding the meaningful | see above |
Dieter Rams's ten principles
Rams wrote them in the late 1970s after asking himself whether his own design was good design (Vitsœ). The names are his; the "what it means" column condenses Vitsœ's text.
| Principle | What it means | Apply it to your MVP by… |
|---|---|---|
| 1. Good design is innovative | new technology creates new possibilities, but innovation is never an end in itself | using new tech only where it changes the user's outcome |
| 2. Good design makes a product useful | it must satisfy functional, psychological and aesthetic needs; remove anything that detracts from usefulness | testing each feature against the one job users hire it for |
| 3. Good design is aesthetic | aesthetics affect well-being, but only well-executed things can be beautiful | fixing broken states before adding polish |
| 4. Good design makes a product understandable | it clarifies structure and, at best, is self-explanatory | a first-time user completes the core task without help |
| 5. Good design is unobtrusive | products are tools, neutral and restrained, leaving room for the user | no decorative animation, no brand noise in the work area |
| 6. Good design is honest | it doesn't claim to be more innovative, powerful or valuable than it is, or manipulate with promises it can't keep | marketing copy that matches what the product does today |
| 7. Good design is long-lasting | it avoids fashion and doesn't date | conventional patterns over this year's trend |
| 8. Good design is thorough down to the last detail | nothing arbitrary or left to chance; care shows respect for the user | a pass over every empty, loading and error state |
| 9. Good design is environmentally friendly | conserves resources, minimizes physical and visual pollution | lighter pages, fewer notifications, less visual noise |
| 10. Good design is as little design as possible | less, but better; back to purity, back to simplicity | the last pass: what can still go? |
Vitsœ publishes the principles under a CC BY-NC-ND 4.0 license, which is why they're quoted so consistently.
Honesty
| Principle | What it means | Source | Apply it by… |
|---|---|---|---|
| honest design | no manipulation, no promises the product can't keep | Rams, principle 6 | removing fake urgency, pre-ticked boxes and hidden costs |
| meaning first | Vignelli starts every job by searching for the meaning of the thing (semantics), then its structure (syntactics), then whether people understand it (pragmatics) | The Vignelli Canon | writing down what the product is for before designing screens |
| understood or wasted | "Whatever we do, if not understood, fails to communicate and is wasted effort." | The Vignelli Canon | five-second tests on your landing page and first screen |
| don't blame the user | people blame themselves when things go wrong; it's usually the design | Norman, DOET | treating every support ticket as a design bug until proved otherwise |
For an MVP, honesty is also practical: dark patterns inflate early metrics and destroy the signal you need to know whether the product works. See validation.
Detail
| Principle | What it means | Source | Apply it by… |
|---|---|---|---|
| thorough to the last detail | nothing arbitrary; care shows respect | Rams, principle 8 | listing every state of every screen (empty, loading, error, success) |
| discipline | "Design without discipline is anarchy, an exercise of irresponsibility." Every detail matters because the result is the sum of them | The Vignelli Canon | a small design system (type scale, spacing, colors) used everywhere |
| look closer | Nest shipped with three screws for different walls, found installs still went badly, and designed one custom screw that worked everywhere | Fadell, TED 2015 | watching real users do the hardest physical or setup step |
| the details make the design | the line "The details are not the details. They make the design." is widely attributed to Charles Eames, but I found no primary source (Wikiquote traces it only to a 2000s UX book) | attributed | treat as a slogan, not a citation |
| care is visible | Ive has argued in many interviews that people can sense whether an object was made with care (paraphrased) | Ive interviews, 2000s–10s | fixing the small rough edges users touch daily |
Choosing which details: a small team can't polish everything. Polish what users touch every session (the core action, its feedback, notifications) and the moments that decide trust (sign-up, payment, errors, data loss).
Feedback and the two gulfs
Don Norman's model of why people fail with things. Every action crosses two gaps:
| Gulf | The user's question | Bridged by |
|---|---|---|
| gulf of execution | "What can I do here, and how?" | signifiers, constraints, mappings, a clear conceptual model |
| gulf of evaluation | "What happened? Is it what I wanted?" | feedback and a visible system state |
The 2013 edition breaks this into seven stages of action: goal → plan → specify → perform (execution) and perceive → interpret → compare (evaluation). Each stage is a question a design review can ask.
| Principle | What it means | Source | Apply it by… |
|---|---|---|---|
| feedback | every action gets an immediate, informative response; too much of it is annoying too | Norman, DOET (2013) | a visible response to every click (Nielsen's 0.1 s limit); progress for anything slower |
| conceptual model | the user's mental picture of how it works; it comes from the "system image" (the product, its docs, its behavior) | Norman, DOET | naming things after what users think they are, not your database tables |
| discoverability | can users figure out what actions are possible? | Norman, DOET (2013) | labeled buttons over hidden gestures in the MVP |
| human-centered design | observe, generate ideas, prototype, test, repeat | Norman, DOET (2013) | a weekly loop of watching users and changing the prototype |
Feedback and latency patterns for web apps are on UX/UI.
Affordances, signifiers and mappings
| Concept | Norman's meaning | Example | MVP check |
|---|---|---|---|
| affordance | a relationship between an object and a person: what actions are possible | a door affords pushing or pulling | can the user actually do the thing they want here? |
| signifier | a perceivable signal of where and how to act | a flat plate says push; a handle says pull | is every clickable thing obviously clickable, and nothing else? |
| mapping | the relationship between controls and their effects; natural mapping uses spatial layout | hob knobs laid out like the burners | do controls sit next to what they change? |
| constraints | physical, cultural, semantic and logical limits that guide action | a SIM tray with a cut corner only goes in one way | does the UI make wrong actions impossible rather than warned about? |
A door whose design sends the wrong signal (a handle on a push door) is popularly called a Norman door. The software equivalent is a link styled as plain text, or a "button" that's really a label.
Norman's own correction: he introduced "affordance" to design in 1988, borrowing it from the psychologist James J. Gibson, and designers then used it loosely to mean "something that looks clickable". In the 2013 edition he added signifiers to separate what's possible (affordance) from what's communicated (signifier). His own summary of the revision: the science is unchanged except for the addition of signifiers (jnd.org).
Storytelling and noticing
Tony Fadell's TED talk (recorded March 2015; titled "The first secret of design is … noticing" on ted.com) is about habituation: we stop noticing everyday annoyances, so we stop fixing them. His examples are the sticker on fruit, "Charge before use" (the iPod shipped charged instead), and the programmable thermostat nobody programmed (the Nest learned from adjustments instead). Jobs, he says, called the counter-habit "staying beginners".
| Principle | What it means | Source | Apply it by… |
|---|---|---|---|
| look broader | examine the steps before and after the problem; remove or combine them | Fadell, TED 2015 | mapping the whole journey (buy, install, first use), not just your screen |
| look closer | the tiny details you've stopped seeing | Fadell, TED 2015 | recording your own first-use session and watching it back |
| think younger | beginners and young people haven't habituated yet | Fadell, TED 2015 | testing with people who've never used a competitor |
| tell the "why" before the "what" | a product needs a story that starts with the problem and why it matters, before features (paraphrased) | Fadell, Build (2022) | writing the launch story before building, and cutting features that don't serve it |
The "vitamins versus painkillers" test (build something people need, not something nice to have) is a venture capital cliché of unclear origin that is sometimes credited to Fadell; I couldn't tie it to Build, so treat that attribution as loose. Brian Chesky's "11-star experience" exercise belongs to the same family and is on founders.
Constraints
| Principle | What it means | Source | Apply it by… |
|---|---|---|---|
| design depends on constraints | Charles Eames, asked whether design admits constraint: "Design depends largely on constraints." The key is recognizing as many as possible and working within them enthusiastically | "What is design?" Q&A, 1972 (as transcribed on Wikiquote) | listing constraints (time, budget, platform, skills, law) on page one of the spec |
| constraints, not compromises | "I have never been forced to accept compromises but I have willingly accepted constraints." | Charles Eames, Domus interview, 1970 (as cited on Wikiquote) | choosing limits deliberately (one platform, one language) instead of half-supporting everything |
| constraints guide users | physical, cultural, semantic and logical constraints prevent errors | Norman, DOET | disabling impossible options instead of showing errors afterward |
| self-imposed rules | discipline is "a set of self imposed rules" that keeps work consistent | The Vignelli Canon | a fixed type scale, spacing scale and color palette from day one |
| few typefaces | out of thousands of typefaces "all we need are a few basic ones, and trash the rest" | Vignelli, 1991 exhibition poster (in the Canon) | one or two typefaces for the whole product |
A fixed time budget is the startup version of an Eames constraint: see appetite in product design.
Jony Ive, Jobs and LoveFrom
Ive joined Apple in 1992 and became head of industrial design after Jobs's return; he became chief design officer in 2015 and left in 2019. Isaacson records Jobs calling Ive his "spiritual partner at Apple"; their offices were linked by a covered corridor, and Ive gave the eulogy at both Jobs's family service and Apple's employee memorial in 2011.
What Ive said he learned from Jobs (Vanity Fair summit, October 2014):
- focus means "not doing something that, with every bone in your body, you think is a phenomenal idea";
- the work matters more than being liked: when Ive defended his team after a brutal critique, Jobs said "you're just really vain. You just want people to like you", and Ive said he came to agree;
- form and function aren't a trade-off: "I think a beautiful product that doesn't work very well is ugly."
After Apple he founded LoveFrom (2019) with Marc Newson; clients have included Airbnb and Ferrari (its first electric car). In 2025 OpenAI bought io, the AI-hardware start-up he co-founded, for a reported $6.5 billion, and LoveFrom took on design across OpenAI.
The lesson: the Jobs–Ive partnership worked because the product decider and the design lead were effectively one unit. In a startup, the founder who owns the product must also own the design standard, or delegate it to someone with the authority to say no.
Other voices
| Who | Idea | Where to go |
|---|---|---|
| Jakob Nielsen | ten usability heuristics for reviewing interfaces | UX/UI: usability heuristics |
| Kenya Hara | art director of MUJI since 2001; in Designing Design and White he treats "emptiness" as a space ready to be filled, not nothingness | his books (Lars Müller) |
| Massimo Vignelli | meaning, discipline and appropriateness before style; "Design is One" (the same values at every scale) | The Vignelli Canon (free PDF from RIT) |
| Brian Chesky | the 11-star experience | founders |
| Steve Jobs | "design is how it works" | Steve Jobs |
Design review checklist for your MVP
Run it on the core flow before each release. The source of each item is in brackets.
PURPOSE AND HONESTY
[ ] One sentence says what the product is for [Vignelli]
[ ] Every feature serves that one job [Rams 2]
[ ] Copy claims nothing the product can't do today [Rams 6]
[ ] No fake urgency, pre-ticked boxes, hidden costs [Rams 6]
SIMPLICITY
[ ] I removed at least one screen, field or option
this cycle [Rams 10]
[ ] One primary action per screen [Maeda: Organize]
[ ] Time from sign-up to first value measured and
shortened [Maeda: Time]
[ ] Irreducible complexity is supported, not
hidden [Maeda: Failure]
UNDERSTANDING
[ ] A first-time user finishes the core task with no
help [Rams 4]
[ ] Everything clickable looks clickable; nothing
else does [Norman: signifiers]
[ ] Controls sit next to what they change [Norman: mapping]
[ ] Names match the user's model, not our schema
[Norman: conceptual model]
[ ] Impossible actions are prevented, not
warned about [Norman: constraints]
FEEDBACK
[ ] Every action has an immediate visible response
[Norman: feedback]
[ ] Users can always tell what state they're in and
how to undo [Norman: gulf of evaluation]
DETAIL
[ ] Empty, loading, error and success states exist
for every screen [Rams 8]
[ ] One type scale, one spacing scale, one palette
[Vignelli: discipline]
[ ] Emails, receipts and error pages reviewed
[Maeda: Context]
[ ] The hardest setup step was watched live
[Fadell: look closer]
NOTICING AND STORY
[ ] Someone who has never used a competitor tested it
[Fadell: think younger]
[ ] The whole journey (find, buy, set up, use) was
mapped [Fadell: look broader]
[ ] The launch story starts with the problem [Fadell]
CONSTRAINTS
[ ] Constraints (time, platform, budget, law) are
written on page one of the spec [Eames]
[ ] Nothing is styled for this year's trend [Rams 7]
[ ] It looks good AND works; if not, it's ugly [Ive]Critiques and limits
| Critique | Detail |
|---|---|
| minimalism as style, not substance | Norman (a former Apple VP) and Bruce Tognazzini (Apple's first interface designer) argued in 2015 that Apple's pursuit of a clean look had lost discoverability, feedback and undo: hidden gestures, unlabelled icons, hard-to-read type. Rams's principle 10 misread as "remove labels" produces exactly this. |
| the principles are taste, not evidence | Rams's and Vignelli's rules are judgments by great designers, not tested findings; Vignelli's "trash the rest" of the typefaces is a preference stated as law. Use them as a checklist, and use user testing to decide. |
| affordance was misused, including by its populariser | Norman himself revised the vocabulary: "affordance" in design talk usually means signifier. The 2013 edition exists partly to fix that. |
| beautiful and unwanted | good design doesn't create demand. Fadell spent years at General Magic, a celebrated device company that failed; the iPod succeeded with a store and music deals behind it. Validate the problem first (validation). |
| copying the look | many Apple products visibly echo Rams's Braun work (the iOS calculator and the ET 66, for example). Copying the surface of great design without its reasoning gives you a style, not a product. |
| cost and time | Rams-level thoroughness in every detail is a luxury; an MVP must choose which details matter (see detail). |
| attribution drift | design quotes are misattributed as often as Jobs quotes; the Eames "details" line is one example. Cite the source or paraphrase. |
Takeaways checklist
[ ] I can state what the product is for in one sentence
[ ] I cut features until the core job is obvious, then
cut once more
[ ] Honest copy; no dark patterns
[ ] Every state of the core flow is designed
[ ] Every action gets immediate feedback
[ ] Clickable things look clickable (signifiers)
[ ] I watched a real first-time user this week
[ ] I mapped the journey before and after my screen
[ ] Constraints are written down and chosen, not
suffered
[ ] Our small design system is used everywhere
[ ] Quotes on our deck are checked or paraphrasedReferences
- Vitsœ, "Dieter Rams: ten principles for good design" (opens in a new tab): the canonical text of the ten principles
- Wikipedia, "Dieter Rams" (opens in a new tab): career dates, "Weniger, aber besser", Braun and Apple influence
- Don Norman, The Design of Everyday Things: Revised and Expanded Edition (Basic Books, 2013; first published as The Psychology of Everyday Things, 1988): affordances, signifiers, mappings, feedback, constraints, conceptual models, the gulfs and seven stages of action
- Don Norman, "The Design of Everyday Things: Revised and Expanded Edition" (jnd.org) (opens in a new tab): table of contents and what changed in 2013
- Don Norman, "Apple's products are getting harder to use because they ignore the principles of design" (jnd.org, 2015) (opens in a new tab): the minimalism critique
- Wikipedia, "The Design of Everyday Things" (opens in a new tab): summary of the gulfs and seven stages
- Tony Fadell, "The first secret of design is … noticing" (TED, 2015), transcript (opens in a new tab): habituation, look broader, look closer, think younger
- Tony Fadell, Build: An Unorthodox Guide to Making Things Worth Making (Harper Business, 2022): storytelling and the "why"
- John Maeda, The Laws of Simplicity (opens in a new tab): the ten laws as stated by the author (book: MIT Press, 2006)
- Massimo Vignelli, The Vignelli Canon (2010), PDF from RIT's Vignelli Center (opens in a new tab): semantics, syntactics, pragmatics, discipline, "complexities but hate complications"
- Wikiquote, "Charles Eames" (opens in a new tab): the 1972 "What is design?" Q&A, the Domus constraints quote, and the attributed "details" line
- Wikiquote, "Jonathan Ive" (opens in a new tab): the iOS 7 simplicity quote and Wired News 2003 quote, with sources
- Lessley Anderson, "Jonathan Ive Shares Three Lessons He Learned from Steve Jobs", Vanity Fair (October 2014) (opens in a new tab): focus, vanity, "a beautiful product that doesn't work very well is ugly"
- Wikipedia, "Jony Ive" (opens in a new tab) and "LoveFrom" (opens in a new tab): Apple career, the Jobs partnership, LoveFrom clients and the OpenAI deal
- Wikipedia, "Tony Fadell" (opens in a new tab): General Magic, iPod and Nest
- Wikipedia, "Kenya Hara" (opens in a new tab): MUJI, Designing Design and White
- Nielsen Norman Group, "10 usability heuristics for user interface design" (opens in a new tab): the heuristics referenced from UX/UI