4.8 KiB
| title | layout | slug | summary | footnotes | |||||
|---|---|---|---|---|---|---|---|---|---|
| Design philosophy | document | values | <span color="blue"><strong>How I think about design</strong></span>, particularly for the browser, and the values I hold close. Good design can't happen without <span color="red"><strong>respect for the user</strong></span> and their device. <span color="yellow"><strong>Taste and personality matter.</strong></span> |
|
I design for the browser first. This is true even in an age of mobile-first and push-them-to-the-app-at-all-costs. I think the web browser is a great equalizer and perhaps the greatest preserver of the open internet.
I care deeply about how something looks, but aesthetics are never the point on their own. Good design should feel thoughtful, trustworthy, and calm; it should reduce cognitive load, never add to it. The goal is to make software more useful and easier to use. If a visual choice, interaction, or animation doesn't improve the experience, it probably doesn't belong there. Dark patterns are an abomination. Delight matters and it should come primarily from responsiveness, care, playfulness, and personality.
Good interfaces should respect the user and their device. The browser, HTML, and CSS are already an extraordinarily capable platform, and I try to stay as close to browser-native as possible. If something can be done well with HTML and CSS, I will always do that rather than rely on JavaScript as a crutch.
I am not opposed to frameworks or complex client-side applications when they're justified, I just think they rarely are and too often introduce more usability, accessibility, and performance problems than the ones they solve. JavaScript should enhance an experience, not become a requirement by default.†
That same respect extends to semantics, controls, and data structures. A button should be a button. A checkbox should be a checkbox. Tabular data should (almost always) be shown in a table. I don't believe in reinventing familiar controls when the native version already communicates the right thing and behaves the way users expect. Page load times, payload size, and memory use all matter too. These are not just engineering's job or an anachronism—they are a foundational part of the user experience.
I don't believe products need to wait for perfect alignment before they improve. Some of the most harmful thinking on product teams comes from the idea that everything has to be redesigned at once in order to be worth doing. Consistency matters, but so does momentum. If something is broken, it's often better to make it better now than to wait for the ideal future state that may never arrive. Many interfaces stay bad for years because teams are too concerned with doing every related piece at the same time.
Good design starts from a strong brief. Every good design effort needs a clear understanding of the users, the problems that need to be solved, and the constraints that shape the solution. On larger teams especially, the brief is what keeps the work focused when there are tons of opions or when strong personalities have outsized influence. Designers should be part of that conversation early. The quality of the brief often determines the quality of everything that follows.
I prefer interfaces that are minimal, but not anonymous. White space, alignment, and typography can solve tons of visual problems. At the same time, software should not lose all of its personality in some quest for minimalism. An app can be clean, efficient, and out-of-the-way while still feeling specific to the team, company, or people who made it. Off the shelf systems like shadcn are amazing but every app doesn't need to look the same. Minimalism is the best place to start, and keeping it as a goal can prevent a design from getting unweildy.
Type is just as much a part of the design as everything else. I often design around or with the words on the screen, and it's OK to add another line of text or force everything to be a single line when it makes the design and usability better.
Finally, design benefits from collaboration, but not from design by committee. Everyone has opinions about interfaces because everyone uses them. That's normal and useful! But not every opinion should carry the same weight, and not every preference should become a product decision. Good design requires judgment: knowing when to listen, when to test, when to defend a choice, and when to change course. My job is not to impose my taste by fiat—my job is to make informed decisions in service of the user and the product—but my taste as the designer does matter and I will rely on it.