Full Circle

1. Boom Days

I got my start in design back during the dot-com boom. I was fortunate to start working in software at a time when if you had a pulse, were fairly resourceful, and were willing to work hard, you could get a job in tech in San Francisco.

The web was still relatively new and evolving quickly. Humans were working hard to figure out what it was good for and how to design for it. Where you went to school or what degree you held wasn’t nearly as important as whether you could do a thing, or whether you could quickly figure out how to do a thing you said you already knew how to do.

Working then was exhilarating and frightening. The web was growing by leaps and bounds. Working in tech in San Francisco in the late 1990’s and early 2000’s was a constant hustle, and the hustle often involved projecting confidence that you knew what you were doing, getting the job, realizing that you were in over your head, burning late hours, and then pulling it off.

Part of the hustle in consulting was asserting that you had a process that would get you to the best result as quickly as possible. This gave prospective clients confidence that they would be in good hands and they were making a sound investment with guaranteed returns.

At the time, we believed in what we were asserting around design process but reality always had a way of intervening. The rapidly evolving state of the web and our understanding meant that process changed on every project. We barely knew what we were doing back in those days, so there was a lot of faking it until we made it.

During this time, humans figured out how to build a online bookstores, local guides, search engines, online magazines and newspapers, online maps, airline booking sites, streaming music services, streaming video services, multimedia experiences, touch-based kiosks, smartphones, online word processors and spreadsheets, online auctions, online banking, blogs, videoconferencing, and so on. These things hadn’t existed before. They were something new.

Every day brought a new development and how we designed had to evolve just as quickly as the medium we were working in. I absolutely loved it. There’s real magic in being able to go from an idea to software that does a thing, that moves on the screen.

I think part of the reason it felt like magic is that we genuinely had no idea what was going to come out at the other end of a project. We had to feel our way through it. We’d get inspired by some new development or technique, or pull from the rich history of graphic design, motion graphics, cinema, and generative art. Not knowing was a prerequisite for making something new, interesting, and good.

One of the key ways of working through our not knowing was to ask questions about what’s possible, what good looks like, what might work. The questions wouldn’t just be verbal, they would be questions we would ask of the technologies we were building with. Asking questions of new technology meant building with code and seeing what came out.

The things we made would eventually tell us what the final shape should be. It would feel amazing seeing how far our ideas had traveled as they became software that would move and change in response to input and actions.

Once we were done and the product was launched, we’d have the satisfaction of having invented something that was made of questions, creativity, fear and stubbornness. Our clients would never know this of course, but they would feel it in how the work shined.

I think this was my favorite time working in software — a time when we knew far less, moved much faster, and invented more.

---

2. Uppercase “D” Design

If you were a design consultancy in the early to mid 2000’s, your design process could be a huge perceived competitive advantage. High profile consultancies like Ideo worked to formalize and evangelize their approach to multidisciplinary design, which eventually found its way into academia and design school curriculums.

Design gradually grew up and took on ever more important sounding titles. Interaction Design and User Interface Design became User Experience Design. User-Centered Design was a thing for a while until Human-Centered Design ate its lunch. Service Design was coined. Design frameworks multiplied like Tribbles, Design Operations appeared at large companies, Research-Driven Design made an appearance, as did Design Science. There’s huge power in naming and lots of status for the coiners of the names.

With each evolution of how design saw and branded itself, the process got more involved and baroque, the artifacts got more detailed, and the culture of design claimed a greater degree of ownership over how software should be made. With each evolution, designers spent more of the attention on how they were doing the job rather than the impact that they were having. Consistency of practice and output became the goal, rather than whether the things we were making were actually good, or solved enough of the right problems.

By the early 2010s, designing started to feel more like a set of recipes to follow, rather than what comes out of the collective hard work of giving ideas shape through good and useful software.

As the practice of software design matured, it seemed to become more preoccupied with getting things right before software is actually made. Designing would be broken into phases where we’d research what problems might be good to solve, validate that a chosen problem was a good one, then brainstorm possible solutions, explore a bunch of them, and winnow them down until we had a couple to show customers for feedback. And all this work was expected to happen before a line of real code was written. Design started to pitch itself as a kind of risk mitigation

By 2015, I found myself increasingly uncomfortable with uppercase “D” Design, and I actively sought out smaller, scrappier teams, and worked to build partnerships with like-minded product and engineering stakeholders. Shipping useful software quickly and iteratively can allow you to cut through a lot of process. When you’ve made a useful thing that’s well instrumented, your customers tell you what you need to make and what problems are critical to solve.

I also worked to build up domain expertise in the industries I was making software for. Building deep knowlege helps you to shortcut all of the parts of the process which are concerned with finding and understanding worthwhile problems to solve. Finding good design solutions goes a lot faster too.

This way of working served me well for a few years more, but I was wholly unprepared for “Design Thinking” when it appeared and started to work its way into the collective design consciousness.

---

”Design Thinking” Over Design Doing.

With the advent of “Design Thinking”, the ambitions of uppercase “D” Design got bigger still. Design was now eating entire software companies.

The gist of “Design Thinking” is that entire companies can unlock their inner designer by employing a framework comprised of set of methods designed to encourage software organizations to think about human-centered designing in the same ways that designers think about it. It’s the equivalent of a whole-body design process for corporations, and it was everything uppercase “D” Design ever wanted.

When the “Design Thinking” movement took hold, I remember feeling as if I were having an out of body experience — the methods promoted could be useful occasionally, but most struck me as forced, performative, highly wasteful, and often resulted in our having fewer real conversations, generating more noise, less clarity, fewer genuine insights, and far fewer lessons learned through the making of useful software. “Design Thinking” seemed to matter more than design doing.

During this time, I felt increasingly out of sync with how design was happening and I started to question myself, despite having more than two decades of experience shipping fairly complex software projects. What can I say? My imposter syndrome is old enough to legally buy beer.

There was no escaping “Design Thinking”. When everyone in an organization is a designer, everyone workshops. Even software developers were forced to draw concept posters, think about “how might we…” and describe “what’s on their radar” until they figured out how to get themselves excused. We were awash in Post-its and high on Sharpie fumes.

Good friends made a sport of my suffering by vibe rendering me covered in Post-its and inadvertently created a record of the toll that “Design Thinking” exacted over time:

Eventually, and much to my relief, “Design Thinking” eventually fizzled out. All was not wasted. Seeing exactly how I didn’t want to design helped me crisp up my take on lowercase “d” design.

Eat your heart out Ideo:

1. The simpler I make the job of designing, the more attention I can pay to what we’re trying to make.
2. The better I understand the people we’re supposed to be helping, the better I can serve their needs.
3. The more I understand the wider context, the more likely we’ll make successful products.
4. The better I support my team, the more impact they will have.

---

Full Circle

This leads me to 2026. I’ve been on sabbatical with the amazing support of my family. During this break, I built out the materials I wanted to have in place for when I started looking for work again. I finished my portfolio, and I built this site, hoping to work through some thoughts about designing and the future of CAD that have been on my mind.

I built this site with the help of Cursor along with an assist from Claude. I made it by asking questions of the technology and built it up one question at a time, not all that different from when I got my start designing for web. I designed the initial look and feel in Figma, but quickly moved over to making finer design decisions through code because I wasn’t sure about what the technology could be made to do. The thing I made started to tell me what it should be, and all I had to do was listen and work to make the signal stronger.

Much to my surprise, this project brought me back to the feeling I had when I started working in software — that thrill when you’ve made a thing you wanted but didn’t know how to make when you started. And what’s more, I’m back to learning through the making, which I think is the point of putting something out into the world and seeing what happens when you do.

The experience of building this site has made me realize that I’ve been mourning for design for years now — watching it slowly slip away and become diminished as it continuously grasped for more. I think I allowed myself to be diminished by not fighting for what I believe in.

With the building of this site, I’m surprised to discover that I don’t need to mourn for design. The parts I love about designing are still here and are still useful. They just work a bit differently than they did before. I’m excited to see what the future holds, and I have so many questions for it.