First principles thinking belongs in the brief
The usual complaint about first principles thinking in design goes like this. Someone on the team reads that you should reason from fundamentals instead of copying what exists. Two weeks later there’s a workshop about what a date really is, and the product ends up with a date picker nobody has seen before. It took longer to build, and people have to learn it.
I think that complaint is fair. I’d rather agree with it up front than defend the idea everywhere.
The idea itself is simple to state. You take a problem apart until you reach the things that are true no matter how it was solved last time, and you build up from those. The phrase is old. Aristotle wrote in the Physics that “we do not think that we know a thing until we are acquainted with its primary conditions or first principles” (MIT Classics). He was describing what it takes to know something.
The version people quote today, as a method for making new things, is usually credited to Elon Musk. A CNBC article quotes him describing it as a way to “boil things down to their fundamental truths and reason up from there, as opposed to reasoning by analogy”. The same article has him admitting that analogy is how we reason most of the time: “Otherwise, mentally, you wouldn’t be able to get through the day.”
For designers, I think the admission is the more useful half. Reasoning from scratch is expensive, so the question is where in the work it pays for itself.
Why I leave the patterns alone
At the level of interface patterns, analogy is doing a job. Jakob Nielsen put it this way in 2000: “Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know” (NN/g). A study that Google summarised in 2012 found that people prefer websites that look simple and familiar, and that they form that impression in 17 to 50 milliseconds.
That evidence is thin. Nielsen’s line is an assertion with no figures behind it. The study asked people to rate screenshots, and says nothing about whether anyone finished a task. I don’t have a study that compares task success on conventional and novel controls. What I have is a preference, and a cost I can see: every reinvented control is something a person has to learn before they can do what they came for.
The complaint needs one correction, though. The common pattern and the right pattern can be different things. The GOV.UK Design System tells teams to use a calendar control only if users need to “pick a date in the near future or recent past”, know the day of the week, or see dates in relation to each other (Dates pattern). For a date the person already knows, like a date of birth, it has them type it. That’s a deliberate departure from the calendar habit, written down with its reasons. So the rule I’d keep is to leave a tested pattern alone, which isn’t always the common one.
The brief is where the habits hide
Now move one level up, from the screen to the brief.
Most requirements a designer inherits are a mix of two things. Some are real constraints: the law, the money, physics, the data model. Others are habits nobody has questioned since the process ran on paper. In the brief they look identical. Both arrive as “we have to”.
We have to ask for this. We have to get a signature here. In regulated products the sentence carries extra weight, because challenging it sounds like proposing to break a rule.
Two public cases show how much can sit inside that sentence. Both are British, only because they’re unusually well documented.
In 2014 the team rebuilding the UK’s Carer’s Allowance application reported that it had removed 170 questions from the process, 49% of them. In the film on that page, Pete Desmond explains how: “we’ve done that because we’ve challenged the way that policy’s been interpreted on the claim form.” My reading is that the policy was the constraint, and the form’s interpretation of the policy was the habit.
The second is the handwritten signature. In England and Wales, the Law Commission found that “uncertainty around the legal status of electronic signatures” was among the things “inhibiting the use of new technology”. Its 2019 report concluded that “the current law already provides for electronic signatures”. It also kept one requirement in place: “a deed must be signed in the physical presence of a witness who attests the signature.” In July 2020 HM Land Registry started accepting witnessed electronic signatures, which “still require a witness who is present at the time”.
So the ink turned out to be a habit. The witness is law, and it stayed. A team that threw out both would have shipped something unlawful. A team that kept both would have kept a pen in a digital process for no reason.
How many of the “we have to” lines in your current brief could you sort that way today?
Every “we have to” needs a name next to it
On most briefs I’d expect the answer to be “fewer than I’d like”, and I think the reason is that requirements lose their authors. A line gets copied from the old form into the new spec, then into a ticket, and by the time it reaches a designer it belongs to “compliance” or “the business”. You can’t ask a department why.
Caroline Jarrett wrote down the fix for forms back in 2010, and called it the question protocol. For every question you list “who within your organisation uses the answers to each question” and “what they use them for”. She’s firm about how far to push: “Do not just accept the answer that a particular department needs data. Track down the exact people who actually use the data in their current work.” She adds that you’ll be amazed how often those people admit they don’t need it any more. She gives no numbers for that, so take it as her experience.
I’d extend the same protocol from form questions to every requirement in a brief. For each “we have to”, I want a named person and the thing it rests on: a clause, a contract, a system limit, a cost. An invented brief shows the shape. It’s for opening a business account, and it says “we have to collect a fax number”. Ask who owns it. If the answer is a person in operations who can point to a regulator’s reporting template, it’s a constraint, and you design around it. If the answer is “it was on the old form”, you’ve found a habit.
Where this goes wrong
One way is calling something a habit because you can’t see the point of it. G. K. Chesterton has a parable about this in The Thing (1929). A reformer wants a fence across a road cleared away because he doesn’t see the use of it, and is told: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think” (quoted on Wikipedia). The wet ink case has a version of it. People kept signing on paper while the legal status of the alternative looked uncertain, and that was reasonable caution. Sometimes the owner of a “we have to” is a lawyer who can’t yet give you a clean answer. That’s a real owner. Write the name down and leave the requirement in.
The other is harder to spot. An essay on Commoncog argues that the more damaging failure of first principles thinking “occurs when you reason from the wrong set of true principles”, and that “the only real test you have is against reality” (Commoncog). You can sort a brief carefully, build up from constraints that are all true, and still miss the one that mattered because no one you asked knew it existed. A sorted brief is a better starting point, and it still has to be tested with people.
On your next brief, write a name beside each requirement, and what the requirement rests on. Don’t argue with any of the lines yet. The lines with no name will tell you where to start asking.
