The future plans for a website dictate its design. The past gives it context and boundaries.
There is a significant difference between designing a website and designing a printed object, like a magazine. Printed materials do not have to account for the technical debt of their pasts. The first issue of a magazine might look completely different from its twentieth issue. They are, for the most part, independent from one another.
Websites are different. Old content is easy to find on the web, and the oldest content on a website will always share the new content’s design. A website’s design needs to account for what’s come before.
This means that your typical website re-design has a lot of work to do.
Over time, this work can result in a degree of digital detritus that requires a wholesale overhaul of design and content. Even when that’s not the case, the work the design needs to accomplish increases exponentially with each additional type of content.
All this is a fancy way of saying: if your website has a ton of content types, the design itself increases exponentially to scale. A rising level of complexity lifts all boats. If you want to manage and maintain a unified, cohesive design for all your blog posts, pages, photos, and more, that’s a lot of content to design.
What was, what is, and what will come to pass
This website has always been one thing: a series of blog posts, organized in index and archive pages in reverse chronological order.
In the future, I’d like to add more stuff to my website. I’d like it to feel less like a collection of loosely arranged documents, and more like my personal home on the web. I’d like to share links to the most recent case studies from my portfolio. I’d like to fetch what movies I’m watching from my Letterboxd profile. I might share the books I read1. I’d love to share status updates — like tweets, but on a platform I own instead of Twitter. Finally, I’d like to start sharing photos here too2. I’m not sure if I’ll share those photos in some sort of a grid, or if I plan on writing photo stories, or both.
All this new content means the design of this site will naturally increase in complexity. If I’m not careful, I worry that the site’s increased complexity and feature list will begin to resemble urban sprawl: poorly planned, boring to look at, and stripped of personality.
As a front-end web design and developer, I’m well aware of the difficulties in making complexity both simple and performant. But it’s worth stating here: I expect this site to be fast, easy to use, and not destroy your smartphone bill.
In his redesign series, Frank Chimero stayed where he thought the design of his website was going to go before he started work on it. I like this. It’s interesting to see how a project mutates as it goes along. I’m inspired by this, so I thought I’d do something similar. I suspect that, since my website will be more complex than Frank’s, our end result will be very different. But I’m surprised at how aligned our initial goals are. Here’s what I’d like this website to be:
- Obvious: Just enough design to make the site feel like its design was inevitable. How else could it look?
- Timeless: I’d like the website to be simple and clear. I don’t want to add design that gets in the way. I don’t think my work will ever be comparable to Vignelli’s or Ram’s, but I’d like to take inspiration from their methodologies. I’d like the website to be useful, understandable, clear, and unobtrusive — and maybe have an air of quiet elegance.
With my long-term goals stated, and my thesis laid out, it’s time to begin considering the fundamentals. Because this website is going to be text-heavy, it’s about time we discussed type.
- Related: Goodreads is terrible and Amazon should hire somebody to redesign it. ↩
- I’m increasingly concerned that Instagram’s signal to noise ratio is getting worse. In the long run, it is also probably best to put anything I’d like clients to see on a domain I own, rather than feeding it to the Instagram algorithm. ↩
- Assuming people are outside. Don’t do that. Stay home. It’s a pandemic out there. ↩
- More on this in a future post, but as my clients’ sites have gotten progressively larger, even the compressed CSS files get huge. The last site I worked on had eight different content structures and five custom pages. Its zipped CSS file weighed nearly 200kb. That’s not because the code is bad or because I repeated myself. It’s just because that’s how much CSS was necessary. React-style components are a game-changer for websites like that. ↩