I like to share the story of how I got started in web design.
I was sick one weekend, a tax refund check freshly in hand, CSS for Dummies, and text edit—in my first year of University.
I built my first website that weekend.
A few months later, I cold emailed a speaker that had presented their career—a highschool chemistry teacher from Utah turned naturalist & photographer for National Geographic. I had gone to his website after the talk, saw it was basically a Word document.
I emailed him: "I can build & design your website for you."
He called me while I was in Studio: "Love it. How much?"
That's how I started designing and building websites, around 18 years ago.
View Source & Inspect Elements
I was showing an intern today how to use inspect element to identify how a thing was built, as he dealt with a bug.
He'd done a great refactor: starting from a z-index bug-fix ticket to refactoring the component and standardizing the code & design with the design system of choice. Been fun discussions along the way.
I directed their movements to contextualize the design differences I was seeing. (Yay margins, paddings, gaps, and the box model.) I realized that this sort of inspection and looking into the HTML and CSS this way isn't necessarily a common practice anymore.
Curiosity-driven, bottom-up thinking, system-minded independent study
Last year, I studied design systems.
I copied the CSS from various people, websites, and organizations I liked, de-minified, and spent time reading their CSS' on my local machine:
Also, dove into open sourced and/or public design systems:
- Primer by Github
- Carbon by IBM
- Stacks by Stack Overflow
- Pajamas by Gitlab
- Cedar by REI
- U.S. Web Design System by USDS
- Astro by U.S. Space Force
- Atlassian's design system
- Protocol by Mozilla
- IBM's Design Language
Questions of Adventuring
- why were these decisions made?
- what are cool ways to construct components?
- what patterns do I like best, why?
- how these decisions localize well?
- what does their documentation look like?
- how's it structured? Compared to others? Why?
- what are normal patterns used?
- how are the greater business values extended and deepened in the story the documentation tells?
I could do a review of REI's Cedar—absolutely lovely. And I've seen multiple releases now just in the times I come back to learn from it.
Another of Gitlab's Primer, and how the documentation is structured, detailed, thoughtful, and clear.
Then there's ProPublica, a news org, that has a very distinct grid-area layout for rapid design iteration and structure a newspaper would regularly use.
I wish I had written about them then. I think that's a path for future article series. I digress.
Design Systems Book Club with Dan Mall
While I was working on my first design system contract for a disabled, neurodivergent focused productivity tool start-up, I also took part in a book club about Dan Mall's book. The final sesh, we had a QnA with the author.
I got to ask fun questions about pricing—how much do you charge?—and about consulting—what do various engagements look like as a design system consultant?
One of the people I'd learned from afar. During the times of Design Twitter, small web design conferences like Brooklyn Beta, New Adventures, HybridConf and early design co-working communities like Friends Work Here and Mild Bunch. Fun personal moment.