The question behind the question
Philosophy is mostly the practice of not accepting the first answer. Someone says "justice", and Socrates asks what they mean, then asks again, until the real idea is on the table. It can be annoying at dinner. It's wonderful in a discovery call.
When a client says "we need a new website", the honest follow-up is: why now, and what should be different after? Sometimes the answer is "we look outdated". More often it's "nobody understands what we actually do", or "our team can't update anything", or "we're invisible to the people we want to reach". Those are three completely different projects, and they deserve three completely different sites.
Socrates liked to say he knew nothing, and then asked questions until everyone else noticed they didn't either. That sounds like a trick, but it's the most generous thing you can do at the start of a project: admit you don't know yet what the site is for, and find out together.
Aristotle's four causes, applied to a homepage
Aristotle said that to really understand a thing, you need four answers about it. He called them causes, but "reasons" is closer to what he meant:
- The material cause: what it's made of. For a website, that's the content: the words, the photos, the projects, the data in the CMS.
- The formal cause: the shape it takes. The structure, the layout, the design system.
- The efficient cause: what brings it into being. The build: the person, the tools, Webflow, the code.
- The final cause: what it's for. Aristotle called this the telos, the end the thing aims at.
Most website projects start with the efficient cause ("which platform?") or the formal cause ("can it look like this site I saw?"). Aristotle would start with the final cause, because it explains the other three. Once you know a homepage exists to help a nervous first-time client understand what you do in ten seconds, the right material, form and build mostly choose themselves.
The acorn is his favorite example: its whole shape makes sense once you know it's trying to become an oak. A website is the same. The layout only makes sense once you know what it's trying to become.
Form follows function (and function follows purpose)
Designers have their own version of this. The architect Louis Sullivan wrote in 1896 that "form ever follows function", and the shortened phrase became a slogan for a century of modern design. It's usually read as "make it useful, not decorative". I read it one step further back: function follows purpose. A button's function is to be clicked. Its purpose is whatever the visitor is trying to get done by clicking it.
That's why I don't treat interactive 3D, motion or a clever CMS as features to add. Each one has to answer a why. A globe earns its place when it helps a visitor see where a studio has worked in one second instead of reading a list. A scroll animation earns its place when it explains a sequence better than a paragraph would. If the only answer to "why is this here?" is "because it's impressive", it goes.
How it shows up in my process
- Discovery starts with purpose, not pages. Before a sitemap, we agree on what a visitor should understand, feel and do.
- Every section earns its place. If I can't say what a section is for, it doesn't get designed.
- Features answer a why. Interactive 3D, motion, a CMS: each one has to make something clearer or easier, not just more impressive.
- The purpose gets written down. One sentence at the top of the brief, so later decisions have something to be checked against.
A few of the questions I actually ask on a first call, all of them versions of Socrates' "what do you mean by that?":
- What should someone believe about you after thirty seconds on the site that they don't believe now?
- Who is the visitor you'd most hate to lose, and what do they need to see first?
- What does your team dread updating today?
- If the new site worked perfectly, what would you notice a month later?
Clear definitions make better sites
A lot of philosophy is defining terms carefully so an argument doesn't slide around. Websites have the same problem. If "services", "solutions" and "what we do" mean slightly different things on different pages, visitors get lost, and so do search engines and AI assistants. Naming things once and using the names consistently is half of good structure.
It's the idea behind the shared vocabulary on this site: every topic in the Observatory is defined once, in a sentence, and every article, mission and service points to the same words. It's a small, very old philosophical habit turned into a CMS collection. You can see those words laid out as a map in Descartes' coordinates and a star chart of ideas.
Why, then how
None of this means endless talk. Asking why is fast when you do it early and expensive when you do it late. A week of honest questions at the start is cheaper than a redesign six months after launch because nobody asked what the site was for.
The how still matters, a lot. I care about easing curves and clean class names more than is probably healthy. But the how is only good relative to a why. Get the why right, and the how becomes a craft problem instead of an argument.