Usecraft

Tactile Thinking

Sat, 09 May 2026 12:00:00 GMT

For as long as I can remember, I’ve been fascinated with machines and how they work. I grew up with the soundtrack of my Dad’s Smith-Corona typewriter hammering away like a machine gun. I’d play with his typewriter when he wasn’t using it. Over the past few years, I rediscovered typewriters and have found them to be useful and interesting in ways I hadn’t quite anticipated.

I’ve discovered that I’m most interested in standard-sized office typewriters from roughly 1960-1984. These feel more like tools and less like antiques, and their industrial design is modernist and beautiful. They’re every bit as designed as a device made today by Apple, with the added benefit of being completely serviceable. It’s extraordinary that these 60 year-old machines can be brought back to life with some solvents, fresh oil and new rubber.

Typewriters from this period are the culmination of a century of continuous development in mechanical engineering and ergonomics. They also reflect an intense period of technological change. They feel like the last great effort from amazingly skilled people who were trying their hardest to hang on to what they had built.

Another reason I chose typewriters from this period is because I wanted to use them to help me think through ideas I’ve been wrestling with. “Modern” typewriters offer the kinds of creature comforts that help the typewriter disappear while writing.

Read the full essay

AI's Heavy Freight

Sat, 02 May 2026 12:00:00 GMT

Back in the late 2000’s, I was brought on by a former client to design an API infrastructure startup named Apigee, which is now part of Google Cloud. Apigee gave me a front-row seat to see the power of good framing and the impact it can have on the long-term success of a technology.

Apigee’s executive team practiced and refined the company’s pitch every day. My job during the early stages of the company was to take the pitch and turn it into an identity, marketing website, applications, and sales materials. We continually refined the messaging and product as the API infrastructure market grew, and this continued until Apigee was well-established and on its way to IPO.

Apigee’s leadership understood the framing game:

Figure out what problem you’re solving and why it’s important.
Find a framing for this problem that makes sense. Communicate why people should care and how they will benefit.
Work to get the market to accept your framing of the problem.
Ensure the product you create is a better fit for the problem you have framed than the products your competitors offer.
Adjust the framing and product based on market needs, the competitive landscape, and public perception.
If you do these things better than your competitors over a sustained period, you’re going to win.

Things get much tougher if your framing is off:

If you have a good product, but your framing is off, then you’re likely to struggle with being successful in the long run.
If you have great framing but your product doesn’t meet the expectations you’ve set, you are vulnerable.
The more out of sync your framing is with what the world needs, the harder it will be for the world to accept what you’ve made.
If you fail to adjust your framing or your products based on shifts in the wider landscape, then you’re likely to be overtaken by someone who can do both better.

There are indications that the computer industry may be in the process of learning some hard lessons around AI’s problem framing.

Steep Grade

If you want to get a sense about how AI’s problem framing is being received out in the wider world, this essay by Nilay Patel, is worth a watch.

John Gruber at Daring Fireball lends his support:

Something is profoundly off in the computer industry when it comes to software broadly and AI specifically. It’s up for debate what exactly is off and what should be done about it, but the undeniable proof that something is profoundly off is the deep unpopularity surrounding everything related to AI. You can’t argue that the public always turns against groundbreaking technology. The last two epoch-defining shifts in technology were the smartphone in the 2000s, and the Internet/web in the 1990s. Neither of those moments generated this sort of mainstream popular backlash. I’d say in both of those cases, regular people were optimistically curious. The single most distinctive thing about “AI” today is the vociferous public opposition to it and deeply pessimistic expectations about what it’s going to do.

Both authors make it clear that there’s something amiss with AI’s framing and what’s being produced with AI, despite there being genuinely useful things created with it.

The high-level pitch of AI is that soon, it’ll do all the things. This is a hard pitch to swallow if you do a thing you’ve worked hard to be good at it, and someone tells you that thing won’t be nearly as valuable in the not-too-distant future. Understandably, the people on the receiving end are going to get angry and be distrustful of the people who make this pitch. When companies lay people off in preparation for the day when AI will do all the things, then people will take this as evidence that the pitch is true, and they will increasingly distrust the things made by the people who made the pitch.

This is the heavy freight that AI is currently carrying, and unless the computer industry can find a way to reframe AI and the problems it chooses to solve, I expect people to become angrier and the grade the computer industry is traveling on will get steeper. This is not a good long-term recipe for success, especially if you’re betting on a technology that can only get smarter if people are willing to feed it with more of the things that they care about.

I think Patel and Gruber both did an excellent job calling attention to the problem, but I didn’t get the sense that they had solid ideas about what the computer industry might pursue instead of automation.

So I’d like to explore whether there might be a different framing around AI, and I’d like to propose some rough ideas around how the computer industry might start to shed the heavy freight of its current AI framing — or at least shift it in ways that can be demonstrably beneficial to humans.

Let me start by zooming out to the pandemic.

Brittle real-world systems are the more pressing existential problem.

One of the things that was shocking about the Covid pandemic was how quickly it brought into focus what’s really important. It showed us just how brittle, fragile, and interconnected the systems we rely upon are.

During the early stages of the pandemic, solid real-time information was very hard to come by. People created grassroots systems for tracking the spread of Covid and communicating out situational awareness. This is software at its best — helping people be more informed and connected in a dynamic situation that’s evolving in real time.

One of the great lessons of the pandemic is how important it is to have humans who are good at making decisions based on messy and incomplete information in unprecedented circumstances. The number of lives saved and lost came down to the decisions people made based on their understanding of what was at stake.

Another lesson of the pandemic was how important the running of the real world is. When the normal functioning of the world was at risk, we discovered who was an essential worker, and who was not. I remember the shock of recognition when I realized all the essential people that contribute to the supply chain that delivers toilet paper to grocery shelves were orders of magnitude more important and vital than the people that do my job.

The pandemic affirmed the utility of software, but also affirmed the importance of humans as creative problem solvers who can act on information, experience, and intuition.

When the pandemic hit, we were dealing with an event that had significant existential repercussions and it was remarkable to see how we collectively threw everything at the problem we could. One example was people rapidly developing cheap open source ventilators in an effort to shore up an overwhelmed hospital system.

In order respond to the next crisis effectively, we need to have a surplus of extremely skilled, resourceful, and creative people who can come together on very short notice and use all of their problem-solving skills and experience to find out-of-the-box solutions for out-of-the-box situations.

I think a healthy society needs to have a reserve of these people at the ready. There’s no way to know in advance what kinds of skills and talents might be needed. The recipe will change depending on what kind of crisis we’re dealing with. Many of the kinds of people needed when a crisis hits might not directly interface with computers when providing some vital service in a time of need.

Automating or accelerating what we already do with software won’t really help us to build in the kinds of resilience we’re going to need to have in order to deal with the world’s increasing environmental, economic, and societal pressures. Without some care, we might even find that speeding things up will destabilize things further.

Also, it’s hard to square the idea that superintelligent AI will be a benefit to humanity if people believe (or see) that it’s going to result in them being less valuable and useful at an industrial scale.

Enabling human creativity is a far better framing than making computers more intelligent.

If AI really is being made for the benefit of humanity then perhaps the job for AI should be to focus on generating a stockpile of creative resources and capabilities so that we can mitigate the worst effects of the next inevitable destabilizing event.

The resources to generate in this case aren’t computer resources. They’re human capacities. Our ability to imagine and invent from as many perspectives as possible is the thing we need to develop and grow.

Computers are amazing tools — and I think AI can be an amazing tool — but the shape of a tool determines its function. If AI is going to be a good tool, one that enhances people rather than degrades, replaces, or disenfranchises them, then we need to take a very hard look at what work this tool is supposed to perform for us.

Sir Ken Robinson’s talk on creativity suggests a way forward:

Robinson defines creativity as “The process of having original ideas that have value”. He characterizes creativity as a ruthlessly squandered resource that should be cultivated and encouraged. He asserts that fostering the faculty of creativity is the best way to ensure that we’ll have the collective wherewithal and diversity of thinking to solve tomorrow’s unforeseen problems.

The job for AI then isn’t just to make computers smarter. The application of AI needs to be in the service of making people smarter, more creative, more inventive, and better able to pool their collective problem-solving capabilities so that we can improve the world we live in.

People will lean into the tools and technologies that allow them to change things for the positive, but in order for this to happen, they need to have AI tools that enable people to solve the kinds of problems that really can have a positive impact on the human condition.

Deepmind’s Alphafold https://deepmind.google/science/alphafold/is an excellent example of this, so I think there’s ample evidence that AI can be used to create incredibly important applications with a wide downstream benefit for people.

If the computer industry wants to start shifting the framing of AI, then it needs to care about what kinds of things we choose to make with AI. We need many more Alphafolds, and we need them fast enough to be able to credibly shift the narrative around AI before people decide they’ve really had enough.

Thoughts on shifting AI’s framing

With the gargantuan resources in play around AI, it’s going to be very hard to change AI’s trajectory in a meaningful way. It might be that we’re living in a world where the computer industry has lost the ability to determine its own future and direction.

Once enough people buy into the idea of AI being a race where the victor takes all, is it even possible to choose a direction that’s selective around where we make use of AI and where we don’t? I honestly have no idea. Sometimes the train can’t be stopped when the freight is too heavy.

However, I hope the computer industry will decide to frame AI differently now that it’s becoming apparent there’s a significant misalignment between how AI makers see the tech and how the rest of the world sees it. I think this is the prudent play to make, but it would require a change in ambition, focus, messaging, and outcomes.

With this in mind, here is a list of incomplete thoughts about how we might go about shifting the framing around AI. Hopefully you’ll find some food for thought here.

1. Recognize that the framing we choose for AI determines the kinds of products we’ll make.

If you’re an AI maker, and you’ve convinced the market (and yourself) that AI is a zero sum game up for grabs between the good guys and the bad guys, it’s unlikely that you’re going to spend much attention figuring out what today’s tech is really good for. Instead, you’re going to try and deliver the thing with existential implications because that’s what the market now expects, and that’s where the big incentives are. Right now, this feels like a case of target fixation on a massive scale. The only way out of target fixation is to look at a different target.

2. Adopt a much narrower problem framing

The more AI can be used to solve legitimate problems that people have, the better the pitch. The more AI enables people to solve the problems they care about, the stronger the pitch. Given that the vast majority of problems people face are messy and have real-world dimensions and repercussions, there’s always going to be a limit to how much AI can do on its own. The more honest and realistic the pitch, the easier it is to deliver against expectations. A narrower problem framing may also buy the computer industry some much-needed time. If we’re making things that we don’t fully understand because they aren’t constructed in a way that makes them open to inspection, this is an incredibly shaky foundation upon which to build. It’s hard to trust the assertion that this technology is going to be the thing that changes everything when even the makers of it can’t really anticipate what it will do with each new generation.

3. Commit to make things that add to people rather than take away.

This requires that we take full responsibility for the benefits and harms around AI. Our eyes need to be wide open here. Damage done whether we notice it or not is still damage. This also means that we need the same kinds of regulatory structures and safeguards in place that we see in the medical industry to ensure that AI is being developed in accordance with the public good. One of the challenges that comes with building a foundational technology that’s used to make other things is that the makers of the technology will be judged by the things people make with it. The more safeguards there are in place to ensure the tech is being used for the greater good, the more likely it will be used for the greater good.

4. Demonstrate genuine interest in fostering human creativity.

We need to treat the study of enabling humans to be more creative as a first class problem — and this isn’t just about being more creative with computers. This is understanding the rich tapestry of creativity, invention, and expression writ large. The more we can understand what creativity is and how to foster it, the better we’ll understand what subset of problems can be aided with the help of computer-enabled things. We’ll also be able to recognize what sorts of things prevents humans from reaching their full creative potential. You’ll recognize that we’re taking this subject seriously when people are able to create entirely new classes of useful, interesting, beautiful, and functional things — not just build the same things faster and with less care. You’ll also be able to see it when the next generation of creators can start to make inroads on problems that have stumped humanity for generations.

5. Figure out which problems are software shaped.

Solving software shaped problems well can make a huge difference in the lives of people. Attempting to make non-software shaped problems amenable to software solutions will certainly cause harm, and will further reinforce the collective perception of AI as being harmful.

6. Conserve what already works well.

If you’re a company that already produces software that does something genuinely valuable, take good care to ensure that what you add to your products is genuinely aided by the inclusion of AI. People can tell the difference between a feature that’s added for their benefit versus a feature that benefits the company that makes the software. Once you put those capabilities in the software, it’ll be very hard to remove them, so take care. If the AI-enabled capabilities you’re adding require that you treat your customers (or the things they make) like food, this will not result in shifting the framing of AI in a positive direction, and it will likely degrade the goodwill you’ve built up over years.

7. Give people greater control and agency.

One of the easiest ways to take fear away is when people have a sense of control over their conditions. There’s a big difference between helping someone do a thing and doing the thing for them. So much of today’s AI usage seems to be focussed on having AI do the thing. There are huge opportunities for AI to augment how people do things, but this is a much harder problem to solve. It requires having a deep understanding about what problems people have, how they want to work, and what they need. This understanding can’t be generated by sifting through the extremely weird slice of the human condition that finds its way online. The digital design for a building or a website does not contain any record of whether it is well-suited to the problem it is supposed to address.

8. Give people the ability to own and shape the fundamental technologies they use.

We have more than 60 years of software not being organized in this way. Having worked for one of the world’s premiere CAD software companies I can tell you that people are tired and frustrated by having so little control over the software they rely upon to do their jobs. Huge opportunities here. Enable professionals to make their software fit the way they work and you’ll see the benefits of AI-enabled software compound over time.

9. Create software that people can shape to fit their way of thinking.

If we spend the next decade focused on the problem of making software fit people with the same vigor and enthusiasm that we spent making people fit to software over the last two decades, we’ll be in a much better place. Surely with the help of AI we should be able to move twice as fast as we did before. Software that can understand what people are asking for is an incredibly useful capability to build upon.

10. Build fundamental AI technologies so that they can be understood.

We don’t yet know how to do this, but it’s hard to see how AI can be made to reliably work in high-consequence real-world contexts without the ability to definitively verify the results and the chain of reasoning. The more black box a technology is, the less people can and should trust it when lives and livelihoods are at stake. If the AI technologies we currently have can’t help us get to ground truth, then it’s likely that we haven’t discovered the right fundamental AI building blocks.

11. Give people the information and tools that help them make smarter decisions over time.

When humans get to decide the things that are important to them, they feel a sense of agency. Making good decisions requires integrating information from multiple sources, only some of which may be online. We need to invest in tools and technologies that can help people become better, more thoughtful decision makers. The pattern-seeing abilities of LLMs are a remarkable capability, but the ability for foundational models to make these patterns understandable to humans feels significantly less developed. The ability for AI to accurately communicate in pictures, animation, 3D models, immersive experiences in real-time is still in its infancy. Huge opportunities here.

12. Create incentives for people to make better use of AI — and their own potential.

The hard problem of figuring out what AI is good for has to start with an admission that it won’t be good for everything. For example, we now make refrigerators that can notify us when our milk needs to be replaced. It’s hard to imagine that the talented people who worked on this couldn’t have made better use of their gifts on more pressing problems. What people make with AI will color what people think about it. If we want to change the perception of what AI is good for, we must incentivize people to make good things that really can make a difference.

13. Treat all of these things as first-class problems to solve today, not something we’ll eventually do when computers are superintelligent.

Assuming that computers will one day be smart enough to do all these things is feels like an awfully big IOU to write given the costs incurred to deliver today’s AI. I’d wager that unless we can figure out how to do the things I’ve described above, I doubt we’ll be wise enough to build the guardrails in place to ensure that we get to enjoy the best outcomes from our superintelligent friends should they arrive. Perhaps the way we’ll be able to tell that AI is in alignment with us is by the things we have it help us make. If what we make is something that disenfranchises a huge swath of creative people, that’s a pretty good sign that the companies that make AI are misaligned. However, if the result of AI is that it helps us build up the reserves of creative capacity to help us mitigate (or even prevent) the next destabilizing event, we’d have good evidence that the makers of AI are in alignment with the greater needs of humanity.

14. Have humility to travel farther.

If we’re going to set out to do a big thing that is paved with unknowns, approaching the problem with humility may be a necessary precondition for success. To make something novel means accepting the possibility of failure. The problem of AGI could be significantly harder than AI boosters are willing to admit. Perhaps building AGI will be more like building a cathedral that takes generations to construct. I don’t know nearly enough about AI to have a well-formed opinion about whether this is true, but I do know that when you’re making something new, it’s always better to underpromise and over deliver.

The Great Teacher

Mon, 27 Apr 2026 12:00:00 GMT

Some years ago, I was feeling stuck at work. The product problems I was working on were exceedingly hard to move and I was struggling to feel a sense of progression.

I decided I needed to learn something far removed from the world of software. I wanted it to be something concrete. I wanted something that I’d have no expectation of ever being good at it. I wanted something that would feel like an accomplishment. I wanted to learn something cool.

I chose unicycling.

[↑] 26” Surly Conundrum mountain unicycle with a 4” tire and hydraulic brake. What could possiibly go wrong?

I had seen videos of people riding unicycles with fat tires and thought it looked like a blast.

Common wisdom is that you should start out on a small unicycle with a 20” wheel so that your feet are close to the ground. That didn’t interest me. I wanted to ride something BIG.

So I bought a 26” Surly Conundrum unicycle and protective gear, suited up for battle, and headed down to the garage in our apartment building, found a way to get up on the thing, and started to learn.

After fourteen half-hour sessions over two weeks, I was able to mount, tool around, ride in figure eights, and voluntarily return to an upright postition more often than not.

I was shocked by how easily it happened and later came to realize that unicycling had taught me valuable lessons about learning, but also about making software.

Here’s what I learned:

1. Choose something worth learning.

Find a thing that calls to you.

The first and most important thing I did was follow my intuition that this would be a fun thing to learn how to do. Sometimes it’s better to not overthink things.

When setting off on a project, It's important that you choose a skill or a problem that you're invested in. The more invested you are in what you're doing, the more likely you'll stick with it when things get hard.

Choose something you think will be hard to master.

One of the easiest ways to not learn a thing is to think that you should be good at it. No one goes into unicycling with the expectation that they’ll be good at it from the start. My expectation that unicycling would be hard forced me to acknowledge my ignorance in how it was going to go. I was able to give myself permission to be bad at it. There’s freedom in this.

When choosing something hard to do, it's important to acknowledge what you don't know. Questions are more important than the answers. The difficulty of the problem relative to your understanding much shape the approach you take. Acknowledging the possibility of failure is a precondition for solving a wicked hard problem.

Choose something where your ego isn’t at stake.

It was helpful to choose a thing to learn where I had nothing to prove. No one ever starts out looking good when unicycling. Humility is a useful when you’re learning a new thing as it keeps you open to the hard lessons you’ll learn along the way.

When there's a lot on the line for a project you're working on, or if that project can't fail, then you're almost certain to work in ways that result in fewer lessons learned.

Have a reasonable starting goal in mind.

I kept my goals modest so that I’d be more likely to have a win at the end. I’d be happy just to learn how to get up on the unicycle and tool around. The more constrained the initial problem, and the clearer you are on what your desired end state will be, the more likely your effort will be successful.

So many software projects fail because they are all-or-nothing propositions. A key to being successful is to choose the kinds of problems that generate something useful along the way.

2. Create the space for learning.

Accept that failure is the most common state.

The desire to get something right is one of the greatest impediments to learning something new. Learning happens when you discover that the world doesn’t work as you think it does. If somehow I’d been magically able to unicycle the first time, it would mean that I had learned nothing. Since I knew the failure was inevitable and would likely result in my crashing in various undignified ways (unicycles are inherently unstable machines), I understood that the project would require some preparation, and some safety equipment.

Anticipating what's at stake for your project before the work happens is a good way to improve the odds you'll be successful. If you understand the nature of the problem you're trying to solve, it will help you to figure out what you'll need to have in place to increase the chances you'll be successful in the long run.

Find a safe place to practice and fail.

I decided I’d learn in the garage in our apartment building. It was flat and would be big enough to roll around and quiet enough in the evenings that no one would see my failures. When you think you’ll have an audience, you’ll be less likely to put yourself in a position where you can fail.

I think this is one of the reasons why so many useful software capabilities start off as side projects.

Mitigate the consequences of failure.

I assumed that I’d get injured without protective equipment. I invested in shin guards, wrist guards, and a helmet. When you reduce the consequences for failure then you don’t have to try and avoid it, and you can learn faster.

So much of a software project's success comes down to how it's set up and what the rules of engagment are. Is there space to fail? Do we have the kinds of infrastructure in place where we can push changes to production regularly, safely, and cheaply? Can the problem we're hoping to solve be broken down into smaller parts? Is the team supported by leaders that will back them when mistakes happen?

3. Get to work.

Break the problem down into logical components.

I assumed that there would be two major problems to solve: Riding and mounting. It seemed reasonable but my understanding of the problem turned out to be incomplete. More on this two paragraphs down.

Unexamined simplifying assumptions is one of the most common ways software projects fail. They can be hugely consequential but can also escape our notice quite easily. Make it a habit to identify and articulate the simplifying assumptions you are making when you embark on a software project. You'll often end up figuring out the thing you need to test that will determine whether you'll be succesful in the long run.

Figure out what the first step should be.

My research indicated that the easiest way to start was sitting on the unicycle while hanging on to something. Also, given the height of the unicycle, mounting felt daunting. I was most interested in learning how to ride, so sitting and trying to move felt like the right place to start. Besides, even if you could somehow learn to mount a unicycle, would it count as mounting if you can’t figure out how to get moving?

Product teams can often spend more attention worrying about how a particular feature or capability will be adopted, rather than focussing on the heart of the thing they are trying to make. Getting to the heart of a problem -- the thing that everything else hinges on -- is key to making rapid progress when building new software.

Double check to ensure that there aren’t other important problems to solve.

Once I let go of the wall for the first time, I quickly discovered that safe dismounting was also a problem to solve for. I think learning by doing and letting the problems come to you can be a valid way to operate but thinking more clearly is helpful too — especially in situations where overlooking something important could have significant repercussions. It’s a good thing I started with unicycling rather than DIY paragliding.

A great number of software projects fail because it's easy to overlook all of the things that must be true in order for a project to work. What are we missing or overlooking? What do we wish were true that might not actually be true?

Operate within the current limits of your understanding or skill.

When you try to ride a unicycle beyond your skill, you’re on your ass and fast. Successful unicycling is really the practice of delaying the moment when you’re on your keister. If you can delay that moment indefinitely, then you’re a pretty good unicyclist.

When designing software it's always important to be aware of the limits of your understanding. Don't design more than can be reasonably built. North star vision exercises almost always write checks that designers and software organizations are not prepared to cash.

4. Learn through encountering, recognizing and understanding failure.

There’s no way to learn how to unicycle without putting your ass in the saddle.

You can’t unicycle by proxy. You can’t workshop it, no user journey will get you closer, you can’t storyboard it, you can’t plan it in advance, you can’t mock it up, you can’t low-fidelity prototype it. Putting your ass in the saddle and having some skin in the game is the only way to learn.

So much of the design process is geared towards reducing the chances that a bad idea will come in contact with the real world. This has the result of depriving designers and the teams they serve the opportunities to learn as quickly and as deeply as they might.

Create the conditions where success and failure are clear.

Unicycling is awesome in that success and failure are binary. If you’re up, that’s a 1. If you’re on your backside, that’s a 0. The clearer the distinction is between these two states, the easier it is to judge your progress and diagnose problems.

So many software projects can get mired because a team doesn't have clear ways to determine what success and failure looks like. This is a consequence of making things that touch many people at a distance where the impact of design choices can not be easily observed.

Make failure fast and cheap.

When starting out in unicycling, failure happens almost immediately. Gravity operates at 9.8m/s, and it’s always operating. Strictly deterministic systems that are easy to observe make great environments for learning. The cost of learning unicycling is inversely proportional to how much protection you’re wearing and how much health insurance you have.

The easier and safer it is to make a change, and the clearer success and failure are, the faster software teams can learn.

Diagnose what doesn’t work and adjust

Much to my surprise, the riding portion of unicycling was pretty straightforward: lean forwards and keep the unicycle moving with you. Unhappy path avenues were more complex and varied. If you lean too far to one side or another, you tip over. If the unicycle moves too slow relative to you, then you fall forwards. If the unicycle moves too fast relative to you, then you fall backwards. For the record. It’s much preferable to let the unicycle roll ahead of of you as you gently drop to your feet behind it. I learned this after I took my feet off the pedals while I was still moving and ghost rode myself into a rapid unscheduled disassembly event.

The lesson here is to not overthink too much before you embark on a software project. It's always going to go differently than you think it will. As long as you are paying attention to the signals, you can adjust as you go.

When the cause of a failure isn’t clear, reduce the number of variables you’re juggling at one time

Getting up on the unicycle turned out to be more of a challenge than I had anticipated — owing in part to the altitude of the unicycle I chose to learn on. I found that it was helpful for me to build up the motion of mounting one step at a time while observing the outcomes. I also found that building a routine of rituals that I repeated gave me a good foundation upon which to judge whether the next new thing I did was an improvement, or a step in the wrong direction.

In software, it can often be helpful to build up iteratively by establishing a baseline that you know works and then experimenting as you go. If you make too many changes at once, it can become hard to diagnose what the cause of a problem is.

Don’t argue with reality.

One of the harder lessons I learned was what happens when things would start to go south and I’d attempt to compensate. When an unstable system is out of equilibrium, poorly applied corrections can exacerbate the problem. Imagine what happens to Wile. E. Coyote when he hits a wall. So much for dignity.

Arguing with reality is a very common mistake for software organizations to make when they are driving towards a goal they've set for themselves. It can take real courage to admit that the thing you were tasked with making won't work.

Learn to anticipate when it’s about to go poorly.

After I was able to consistently recognize the signs that impending failure was approaching, it became easier to gracefully dismount. The more practice you have, the easier it becomes to anticipate correctly. The ability to anticipate is a sign that you’re in tune with the problem space you’re operating in.

Being in tune is how you get to be able to trust your gut and intuition, critical ingredients for any designer hoping to make something new that hasn't existed before. Building deep domain knowledge is also critical for being able to build something new in software. After all, almost all of the simple and easy things have already been invented. You can't make something truly novel if you don't know your stuff.

Notice when you’re repeating mistakes. It’s a sign there’s something you need to learn.

I definitely struggled with getting up reliably during my second week of unicycling. It took me maybe a hundred tries to get a feel for how to mount with the right pressure on the pedals. Sounds like a lot, but it only takes about 30 seconds to get into position and give it a go. When working in a situation where the unknowns outweigh the knowns, the cheaper it is to try a variety of things out and learn from them, the faster learning happens, and the more likely you’ll discover the right solution.

There's a big difference between trying a lot of things in Figma, and trying a lot of things in working software. You'll learn much faster and find better solutions if the cost of trying out ideas in software is cheap.

5. Learn through repetition.

Daily practice facilitates nervous system rewiring.

I found that practicing each day had the greatest compound effect as my nervous system rewired to incorporate the lessons learned in the past. Repeated small changes paid greater dividends over time compared to me trying to brute force my way into unicycling competence.

Getting into the habit of releasing small additions to software, and building the muscle memory through continual releases is one of the most important skills a product design team can learn how to do.

Repetition over time will eventually free up cycles for higher-level thinking.

When I started, I had to focus very intensely on what I was doing. Learning how to unicycle involves rewiring your nervous system so that more of the the activity is handled subconsciously. This frees up mental cycles for observing what’s happening while it’s happening.

As designers, when we focus too much on process rather than outcomes, we're not able to give ourselves over to the thing we're making. The more complex and involved the process, the longer it takes to reach a state where you can focus on outcomes and impact. There's a world of difference between learning a set of dance steps and performing the dance so that your audience feels something.

Find balance first, then aim for flow.

I’ve always had good balance from cycling, so it only took a few days for me to be able to tool around the parking garage in our building — and after a few weeks, I experienced flow. It was surprising to reach this state so quickly given my assumption that unicycling would be hard to learn. That said, the inherent instability of unicycling meant that flow state was often rudely interrupted as gravity took over. The important takeaway here is that flow is the thing that happens when you do a bunch of other things right, and flow stops when you do one or more things wrong. If I had tried to aim for flow without first having the basics in place, I think I would have struggled a great deal, or ended up in traction, or both.

The ordering of problems is incredibly important when you're in the business of inventing new technologies or products. What's the core of your product? What's the first real bit of value that the whole thing hinges upon? Spend the majority of your attention there. If you've made something that really offers value, inventive humans will figure out a way to use it, even if there's almost no first user experience or polish. That can come later after the thing you're making is humming along.

6. Celebrate your wins.

Define what success looks like

There are at least a couple of different framings for success that are important where unicycling is concerned. On the macro scale, success is pretty easy to spot. When you’re up for as long as you want to be up, and you can gracefully come down when you want to stop, you can count that as a success. On the micro scale, there are a bunch of different steps you need to take in order to mount the unicycle, get it moving forwards, make left turns, right turns, cycle in place, and return to the ground. Each has success and failure states. Thankfully, they’re all quite obvious and easy to discern.

When making something new, I think it's quite easy to not think about all the things that must be true for a particular feature to be successful. Figuring out what those hard parts are requires smart people to work very closely together to talk through what the obsticles and challenges might be. The requirements for a project should follow from this essential work, not preceed it. The more we treat the creation of software like factory work, the easier it is for people to stay in their lanes and not take responsibility for the sum of the parts.

Successes are just as important a signal as the failures.

Unicycling is a game of doing a lot more of the right things than the wrong ones. The harder part of learning is understanding why one behavior results in success while another will result in failure. Since the physics of one wheeled vehicles are pretty simple, and the mechanics of having a body are also relatively well understood, it wasn’t too hard to understand why one thing worked while another didn’t, and this helped me learn faster. The more cause and effect are joined, the easier it is to diagnose problems.

Situational awareness is incredibly important when you're making something for people not you and the impact of your design decisions happens at a distance. If the thing you're making isn't instrumented well enough, or if you change too many variables at once, you lose the ability to pinpoint the downstream consequences of the choices you're making.

Pay attention to what’s working over time.

When you’re learning a a skill that requires the integration of a number of sub-activities, it’s important to identify which ones are working well in isolation and in concert. The more you can integrate the successful parts, the better you’ll get at the whole activity. As I became more comfortable with unicycling, I was able to identify the areas where I wasn’t as strong. Turning right was easier than turning left for a while. The more that went well, the easier it was for me to fix the things that still needed improving.

I think it's very easy for busy software teams to stop taking stock of whether the thing they are making is actually good. Even when they do, they may not factor in the time to improve things because they're too busy making the next thing. Team members may not use the thing they are making regularly enough to be able to judge whether it's any good, or whether it's really improving.

Work to build a sense of momentum.

By practicing a half hour each day for two weeks, I was able to build success upon success with few setbacks. The more progress I made, the more enjoyable unicycling became. Momentum is something that’s often hard to come by when working on software design problems. Being able to go from sitting to tooling around after about seven hours of total practice time was a huge boost for me.

It's incredibly easy for software teams to get bogged down in wanting to get things right before a product is launched, but I've always found that getting something early out, learning from it at each stage, and iterating like hell always results in better software faster than when teams try to polish what they're making to a high sheen before launching.

7. Change it up.

Shift tactics if you’re stuck.

I found it helpful to change things up when I got stuck. If tooling around was a challenge, I’d practice mounting the unicycle. Shifting tactics made the whole thing feel like a problem to solve. As long as I could try new things, I didn’t feel as if the problem would be too hard to solve indefinitely.

How often is it that software teams decide that the thing they're trying to make just isn't working? How big is the thing you're trying to test? The more expensive it is, the more invested we become in the outcome and the harder it is to change tack.

Know when to call it and come back fresh.

I noticed that during each practice session, I’d start to reach a point of diminishing returns after 45 minutes of practicing. Calling it and coming back fresh the next day would often be enough to give me the perspective needed to figure out how to get past yesterday’s blocker.

The harder a software problem is to solve, the more likely you'll need to step away and approach it from different perspectives. How much room is there to do this in a culture that tends to think in two to four week sprints?

Be open to the journey and adjust as you go.

One of the things I was surprised to learn was that the thing I thought would be the hard part — riding around — wasn’t all that difficult. Reliably getting up on the unicycle was more of a challenge.

Part of learning or making something new is being open to the challenges it presents. The fewer preconceived notions you have about how it's going to go, the more open you'll be to where the project takes you.

Look for the a-ha moments that unlock things

I struggled with mounting the unicycle for a while because I thought the job was to hop on and sit upright on the unicycle. Each time I’d do this and start to pedal, the unicycle would move forwards and out from under me. The trick for solving this was to realize that the goal needs to be to get up and lean forwards so that you start to fall forwards. My flash of insight was to realize that unicycling is the act of falling forwards and then have the unicycle catch up just enough to maintain your momentum. If you start to slow down, just fall forwards a bit more. I’m still amazed that being able to unicycle isn’t a physical activity as much as it’s a way-of-seeing activity.

Truly understanding what's at stake for a project only happens when you go on the journey of putting it out into the world. Learning how to understand what's at stake is one of the most important skills to develop as a designer.

Future CAD Building Blocks

Sun, 26 Apr 2026 12:00:00 GMT

When setting out to build a new product or technology, it’s important to spend some time to think about what sorts of things need to be in place for the effort to be successful. This is crucial when you’re operating in a context where there are significant consequences for missing some important ingredient.

It’s also important to think about where you’re hoping to head and why. This helps you stay focused on the outcomes. My sense is that if generative AI is going to be useful to people who use CAD software, it’s going to be when it’s employed in a way that significantly improves some aspect of how CAD software works, or improves the quality of what gets designed and produced.

Given this, I thought it might be interesting to consider the kinds of building blocks that will need to be in place so that CAD software can evolve in ways that are good for humans and computers.

One of the most important ingredients is having permission to reinvent CAD. Many CAD tools are extremely mature, having been continuously developed for decades. Asking mature software with a loyal customer base to change is a herculean task.

When companies find ways to look at old problems with fresh eyes, they often find opportunities for innovation and reinvention. Consider how James Dyson reinvented the vacuum by attacking the problem from first principles.

In order to create the room to reinvent, it can be helpful to ask questions that can help you spot opportunities. What did the world look like when the patterns of today’s CAD was set? What’s changed since then? Do CAD users collaborate as they always have, or are there new patterns that need to be enabled? What would CAD look like today if we were inventing it from scratch and could use all of the technologies available now?

Read the full essay

Capturing the Imagination

Sat, 25 Apr 2026 12:00:00 GMT

I’m interested in the distance between the experience of designing architecture with CAD software and the experience of being in architecture.

I recently came across this walkthrough of a building designed by Cutler Anderson Architects. that made me want to dig into this topic a bit.

The architecture shown in this video is sensitive and beautiful. The way it’s introduced to the audience is lovely and I think reflects something about the way Jim Cutler thinks about creating the experience of architecture.

One thing that struck me immediately was how the design of this building only makes sense because of the wider context in which the building exists: the site, the foliage, the water, the pathway leading through the woods to the front door, the materials, the mechanisms used to open the building to its environment, the change in light, and the change in seasons.

All of these things are essential and integral to the design — and yet none of them exist within the CAD software that was likely used to design this building. This seems odd, especially in an age where computers are so capable.

I can’t help but think about the amount of skill and imagination required to be able to look at design drawings and be able to visualize what the final experience will be. Is there an upper limit to the level of complexity a trained architect can visualize? I’d imagine there must be.

What happens when non-architects need to do something with the designs? What happens when clients need to understand drawings, or the people who will be constructing the building need to refer to the designs? What happens if these parties misunderstand the drawings? Lots of potentially expensive and avoidable errors can occur.

Being able visualize a design is essential for architectural design software, if for no other reason that it takes a lot of people to turn the idea of a building into a real building, and they all need to understand what the end product will be. The more complex the design is, the more important it becomes to have rich, flexible, expressive, and immersive ways to visualize designs.

This leads me to wonder:

Why doesn’t architectural design software make it easy to get a sense about what the experience of a building will be?

This seems like something that architectural design software should be good at doing, just like it’s good at making drawings. There’s a good deal of evidence to support that this is technically possible, but we haven’t yet found a way to fully connect the dots between designing and visualizing in architectural CAD software.

How architectural designs are visualized today:

There are a number of ways to visualize architectural designs if you’re motivated enough and are willing to put in a good deal of work.

Since CAD files are schematic in nature, getting a design ready for rendering requires adding high-quality materials, lights, props, furniture, foliage, terrain, sky, weather, surrounding buildings, people, etc.. A design essentially needs to get dressed, much like a set is dressed for a film.

Here’s a video that shows three of the commonly-used architectural visualization applications and the effort required to dress up a design and render it:

Once a design is dressed, it needs to be shot from a number of different perspectives, and if an animation is to be made, then the camera and models need to be animated as well. This work is labor-intensive enough that there are limits to how much of it can be re-used if and when a design changes, which again limits how often designs make the transition from schematic representation to photorealistic rendering — or beyond.

Over the years, there have been a number of visualization tools that have streamlined parts of the process of preparing designs to be visualized. Enscape, Twinmotion, Lumion, and D5 are examples. Some have incorporated game engine technology, which has evolved to be able to deliver interactive photorealistic pictures at real-time frame rates.

Where it used to take minutes to hours to painstakingly simulate the path of photons as they bounce from surface to surface, materials to camera, game engines through a series of novel tricks and specialized hardware, can get the generation of detailed photorealistic scenes down to small fractions of a second.

Dedicated design visualization tools have evolved ways to streamline the ingestion of CAD data, and some have come up with novel ways to substitute high quality 3D assets and materials for the schematic symbols that comprise a CAD design. This is an improvement, but still contorts around a set of immovables that are a consequence of CAD designs being closely bound to proprietary file formats.

In some cases, these visualization tools are now fast enough to run while CAD designs are being modified, allowing architects to be able to see the impact of the design choices they are making in real time. This can be especially useful when an architect is collaborating with people who may not have the ability to understand design drawings. Here’s an example of this in action:

Having the ability to visualize designs adjacent to where designing is happening is much better than not having it at all, but I think that the division between designing and seeing that’s been present in CAD from the outset prevents us from understanding that the ability to see, feel, interact with, and inhabit a design is actually fundamental to the creation of complex things meant to exist and function in the real world.

It’s worth noting that all of the contortions and effort people have to go through to supply schematic CAD models with all the things that bring a design to life would largely go away if CAD software had the ability to incorporate them in the first place. It seems strange that architects should have to do the virtual equivalent of moving into the design just to convey a sense about what it’ll be like in real life. We can do better.

Today’s CAD Software is Remarkable and Not Nearly Enough

When AutoCAD was invented more than 45 years ago, the pitch was that it was better to draft and design with computers than on paper.

[↑] Source: https://www.winworldpc.com.

The computers of 1982 were far less powerful than those of today, Lines, shapes, and symbols were all these computers could manage. This wasn’t a shortcoming because humans had been perfecting the design of buildings through schematic representation for millennia. There really is no more succinct or definitive way to describe a building — Design drawings are a kind of lossless compression.

As computers became more powerful and sophisticated, CAD evolved to treat the design of buildings as a system of interconnected relationships that can be easily updated. Models for designs began being represented in three dimensions. This was a significant improvement.

[↑] Source: https://www.aecbytes.com.

By any measure, CAD software has been wildly successful. Take a look at any building under construction today and it’s a guarantee that it was designed through drawings and simplified 3D models. It’s clear this works pretty well.

But is it enough? Does this level of visual fidelity make anyone feel something about the spaces they’re designing in the same way they would if they were inside those spaces? Does it inspire? I don’t think so, and I think this needs to change.

Capturing the Imagination

Software for the designing of buildings should be able to place architects in and around the structures they are designing, so they can feel them, learn from them, and react to them. It should also be able to do the same for the people who commission architectural designs.

The commissioning of an architectural design can represent a huge investment of money, time, and patience. The period between when design starts, and when it’s realized can take years. That’s a helluva lot of delayed gratification.

Sometimes design work can be speculative and the goal is to inspire. Being able to engage the imagination is an essential tool that architects employ. It’s the way they buy time and marshal the resources needed to turn the idea of a building into a real one.

I love this image of Frank Lloyd Wright’s mile-high skyscraper drawing.

[↑] Source: Architizer.com.

The scale and position relative to the audience was clearly designed to encourage a viewer to look up and imagine what it would be like to see such an incredible structure in real life. This is the thing that architectural design software needs to enable.

So Much Room to Become More

One of my favorite sources of architectural visualization inspiration is Visualizing Architecture. Their visualizations are hand-crafted meditations on the buildings they’re portraying. They’re staggeringly beautiful.

[↑] Source: Visualizingarchitecture.com.

It’s hard to imagine that the architecture firms that commission these visualizations don’t come away surprised by what these artists manage to express about their buildings. I especially love that they’re not entirely photorealistic — they’re illustrative. They leave room for the imagination of the viewer to do some work, to inhabit the space, to see it clearly. They convey a clear point of view, they command attention, they stand out. They’re memorable. They elevate the designs, the architects, and the people who commissioned the work.

When design visualizations happen early enough in a project, the ability to explore and express what’s important about a design can help clarify the design itself. This is one of the reasons creating architectural models is such an important part of the process.

The cheaper and easier it is to visualize a design from within CAD software, the more opportunities there are for architects to evaluate what they are making.

This isn’t a nice-to-have. It’s fundamental to the practice of architecture. It’s something that can make the difference between a clumsy design, and one that accurately reflects and represents its purpose and context.

The software tools for architecture shouldn’t just be tools for manipulating the shapes and symbols that eventually result in a building. They need to become much more. They need to become tools for capturing the imagination.

Lessons From Pixar's USD

Sun, 19 Apr 2026 12:00:00 GMT

One of the more interesting trends in design software over the last decade has been the creation of software that’s aimed at enabling groups of people to collaborate on complex projects.

When large organizations of people create something complex, like an animated feature film or a building, it requires that specialists be able to contribute their part to collective effort. Each specialist has a unique job to perform, and they frequently may need to use specialized applications that are tailored for their role.

The more complex a project is and the more people that contribute to it, the harder it becomes to integrate their work into the larger whole. When the thing being designed requires pulling all the parts together to see how they fit, getting all the different kinds of software to speak to one another becomes a huge headache.

Back in 2012, Pixar Animation Studios created a data interchange format called Universal Scene Description (USD) to address this problem.

Read the full essay

AI Product Packaging Challenges

Thu, 16 Apr 2026 12:00:00 GMT

The tension between what a technology can do and how it’s packaged is a thing I’ve grappled with for the majority of my career as a designer. This isn’t a new problem. It’s been around at least as long as humans have been making and selling technologies for use by others.

One of my favorite examples of tech product packaging is Atari 2600 cartridge package design.

If you were a nerdy kid growing up in the late 1970s, the toy you wanted for Christmas was the Atari 2600 Video Computer System.

Atari 2600 games were incredibly simple by today’s standards, having to fit on 2-8kb ROM cartridges that would run on an 8-bit i.19 MHz processor with 128 bytes of RAM. The graphical performance of the 2600 was significantly more limited than the games found in arcades and corner stores.

In order to compensate for a lack of graphical sizzle, Atari’s graphic designers employed incredible product art to capture the imagination of kids looking to bring their arcade experience home.

[↑] 45 years later, I still want to play games that look like these.

I suspect Atari’s graphic designers understood that they couldn’t lead with game graphics as they weren’t compelling enough on their own. Turning the cartridge boxes over reveals the stark reality of what could be achieved with the Atari 2600’s low-cost hardware.

[↑] Gameplay graphics are just large enough to be legible, but small enough that you can hope they’ll be better when displayed on a TV.

One of the things I love about these package designs is that I think they were the best solution given the limitations of the technology they were promoting. The box art was exciting and made reference to arcade game cabinet art. The 2600 system was positioned as an entertainment platform and Atari branding was instantly recognizable at stores, making it easy for parents to recognize and find.

I love these because that they’re juuust on this side of a very fine line where aspiration runs in advance of reality. These games were still fun to play even if they only superficially resembled the arcade games they were inspired by, and a kid’s imagination could do a lot of heavy lifting to compensate for the lossiness of the experience relative to the real arcade games. The console’s gameplay captured the spirit of the original game and the box art sealed the deal.

One of the dangers of creating products that don’t live up to their promise is that it can be easy to set expectations that you can’t fulfill. When this happens, the results can be catastrophic.

Just about a year after these cartridges were released, Atari found itself on the other side of this line when it released Pac-Man. At the time, Pac-Man was one of the most popular arcade games and kids were very familiar with how it worked. Atari’s management had failed to understand the importance of being able to follow through on the expectation players would have of the game, and did not give the game’s sole designer enough time or freedom to figure out whether it was possible for the Atari 2600’s aging hardware to do a credible job with Pac-man. The experience delivered did not match customer expectation and the Atari brand suffered a significant blow.

More of Atari 2600 Pac-Man story on hackaday.com

As an aside, someone eventually did find a way to make a credible Pac-Man for the Atari 2600, but it took more than 20 years for the better game to arrive. Amazing what creative humans can accomplish when given the time and space. This effort even managed to win the admiration of the game’s original designer.

This is all to say: how a product or technology is packaged relative to what it delivers matters greatly. It can often determine whether a product or technology will ultimatelty be successful or not.

Turning back to the present, I wonder how AI products will eventually be packaged and what shapes they will have once we fully figure out what they’re good for.

After having spent some time building with Cursor and Claude, I’m struck by the contrast between how powerful these technologies are and how little their capabilities are apparent at first glance.

When the primary interface for accessing AI capabilities is through text-based interfaces, it requires that users be curious enough to be willing to poke around and feel their way through the tech, much like early PC users had to feel their way around text-based adventure games.

With a technology that can accept and understand natural language as well as today’s LLMs can, text-based interfaces can get you a helluva long way. But this approach comes at a cost of discoverabilty. It doesn’t explicitly communicate how it should be used and what it’s good for.

In the long run, how AI capabilities are packaged and surfaced will have a profound impact on how readily they are adopted. I think this will be one of the biggest challenges for the designers of AI products.

In some interesting ways, today’s AI product packaging problem feels like the inverse of the Atari 2600 game packaging problem. The package leads with the 8-bit screen art, but the experience of playing looks and feels like the artist’s rendering.

Atari games		AI
Extremely constrained compute	→	Abundant compute
Few, capped capabilities	→	Massive, evolving capability
Rigid gameplay experience	→	Highly personal and customizable experiences
Delivered through high-affordance interfaces	→	Accessed through low-affordance interfaces
Overly aspirational product packaging with very limited ability to follow through on the promise	→	Aspirational technology messaging with (as yet) unrealized potential

The job for Atari’s packaging designers was to find ways to make the best of a very limited set of technologies by generating a sense of drama and excitement. The limitations of the underlying hardware defined the upper boundaries of how the games could reasonably be packaged and sold.

By contrast, the open-ended nature of AI is both its strength, and its weakness. When you have a technology that promises to do so much, the trick becomes finding ways to show how it can be used to solve some important subset of problems that humans care about today — many of which may be rather mundane.

Given this, I think it’s likely that today’s general purpose AI interfaces will eventually need to give way to domain-specific interfaces. The kinds of affordances needed for architects and mechanical designers (for example) will likely be different than the kinds of affordances that software devlopers will need to have.

And just as software developers are bootstrapping the tools and workflows they want to have to facilitate agentic engineering, making AI work for other domains such as architecture, construction, mechanical design will require developing the interfaces, affordances, and workflows to enable skilled practitioners to figure out how to best incorporate AI into their own ways of working.

This feels like a very different conception of product packaging than traditional desktop software for professionals. It might be that the packaging job around AI will be to build out a critial mass of easy-to-use core capability so that practitioners can see the utility of AI-enabled workflows, and then offer ways for them to take it the rest of the way.

So in some ways, we may be strangely back to the Atari model where AI is the platform, and it’s accessed through well-packaged “cartriges” that are good at doing specific jobs.

One thing that’s going to be interesting to see is what the impact of aspirational messaging around AI will have on the development of AI-enabled products and services. I wonder whether the belief in the unlimited promise of AI might actually present challenges for productizing the tech. When you’re promising so much, it can be easy to overlook the smaller things that could turn out to be very useful.

Even if foundational AI progress were to stop today, I think AI’s natural language understanding and pattern recognition are more than enough to fundamentally reshape how we interact with computers (and how they interact with us). It will be interesting to see whether we’re willing to give ourselves the time and space to fully explore this, or whether the pressure to deliver the future will tempt us to take shortcuts that outpace our understanding of how to best productize these powerful technologies.

Mind the Gap

Wed, 08 Apr 2026 12:00:00 GMT

For as long as I’ve been working as a designer, I’ve been fascinated by how the design tools we use influence the way we think and work together. When there are big shifts in the enabling technology landscape, our design tools evolve to take advantages of the new capabilities. When the changes are significant enough, we often discover something about how we really want to be designing.

Once such shift occurred when Figma was invented. Figma’s key insight was understanding that organizations of people design software, not individual designers. Most software is made by teams of people who all have an important role to play. They all need to see a design, and contribute to the design, and shape the thing the design represents.

Figma’s brilliance was to figure out that software makers need their design tools to live in the space that connects all these people together — just as the system of record for code needs to live in the space that connects developers together.

Figma outcompeted the Sketch + InVision combination because it collapsed the distance between designing and sharing designs. No upload was needed, no translation needed. No re-uploading and re-translating each time a design was updated. With Figma, read-only designs were simply a permissions setting, rather than a completely different data format. Figma eventually won because organizational designing was a more fundamental need than design review.

Figma utilized advanced web assembly techniques to build a design tool native to the web and browsers. When you have a web-native design tool, the cost of delivering a read-only view essentially goes down to zero, and the time to deliver it to eyeballs is the same as it is for designers that need to make changes in real time. Figma’s solution changed the economics of design collaboration by making it essentially free and able to operate in real time.

It’s hard to overstate how profound this is or how far ahead of the curve Figma was. The desktop CAD software industry has still not fully digested Figma’s key insight, which is now more than 10 years old. If anything, the design of buildings, infrastructure, and machines is even more an organizational activity than writing software.

Figma is an excellent demonstration of how shifts in the enabling technology landscape can help us to find better ways to use computers to design complex things made to operate in the real world.

Just as Sketch and InVision were built upon a foundation of ideas that were shaped by the capabilities and limitations of the underlying enabling technology landscape of their time, so too are design tools like Figma.

I’m going to use my journey of building this site as a way to call attention to some of foundational assumptions that may start to be no longer be true with the advent of useful LLMs that can write workable code in response to natural language requests.

Let me start by calling out the first:

One of the foundational assumptions behind Figma is that making changes to software is expensive. When making changes to software is costly, it’s a good idea to figure out what you want to build well in advance.

So what happens if making changes to software suddenly gets significantly cheaper? I think it gets much harder to make the argument that it’s worth doing most of your high-fidelity thinking about the shape of software independently from the software you hope to create.

When I was creating this site, there was a point where it made sense to stop designing in Figma and make the remainder of the design decisions in the site itself. This point happened far earlier than I anticipated.

The primary design challenge for this site was to figure out the responsive layout behavior. When you need to squeeze in a lot of content on something like a phone, it’s going to require a different solution than displaying the content on a 4K monitor. In the space between these two extremes, there are a lot of different devices to consider: big phones, landscape phones, small and large tablets in portrait and landscape orientations, 1080p monitors, 1440p monitors.

When you add all of these variations up, the design of the site ends up being a lot more involved than it would initially seem, and the challenge becomes laying everything out to make sure it fits, just as you would if you were moving into a new home and needed to make sure that all your furniture was going to fit into the new place.

In Figma, the more variations you have to deal with, the more effort it is to fully detail out the design. Figma does have some conveniences in place to make this easier, but generally these conveniences require being willing to utilize Figma components, component auto-layout, styles, and variables. These aren’t rocket science, but they operate according to their own logic which only superficially reflects the logic of web browsers and CSS. Many of these capabilities were added to Figma later in its gestation, so they’re nestled in weird corners of the design tool (yes, I’m talking about you, variables).

If you want the benefits of having design elements in Figma to approximate how they might behave as parts of live applications, then you need to fully take on Figma’s idea about how to lay out and organize all the different parts of a design on a two-dimensional surface.

It’s better to have these things than not, but they do come at a cost and can be pretty fiddly if you want to have the freedom to move things around and try a bunch of options.

I often think that the price of designing in Figma is that you have to be willing to think like Figma prefers. The more you want to take advantage of the things that make Figma good for designing websites in a production capacity, the more brittle and locked in the design becomes.

This isn’t a criticism of Figma — I think the choice Figma’s designers made here was a reasonable one to make — it’s just that if your mind isn’t particularly Figma-shaped, it’s hard to ever reach flow state with this tool. I much prefer to work loose first, and structure things only once I decide the design is ready for this.

One of the challenges I find with Figma’s auto-layout behavior is that it makes a lot of assumptions around how components will react to having their parent frames stretched and resized. Sometimes these assumptions are correct, but on many occasions they are not. Unfortunately, the rules that govern their behavior aren’t visible and can’t be easily tweaked, which is especially problematic for a design tool. Even something as simple as modifying the position of an element governed by auto-layout frequently can’t be achieved without breaking the component, repositioning the item you want, reassembling the component, and then turning auto layout back on.

The behavior of Figma’s auto-layout feature only approximately matches the way that browsers and CSS behave, but the differences are significant enough that you end up juggling the weirdness of Figma’s auto-layout behavior and the weirdness of browsers and CSS. All of this comes at some cognitive cost.

This is a lot of overhead to deal with if what you really want is a responsive website that behaves well when the screen is resized. Beautifully structured designs in Figma isn’t the goal, Having the website deliver content to eyeballs across a wide range of devices is the goal.

Up until quite recently, this overhead could be justified, owing to the fact that many designers don’t speak CSS natively and moving things around in Figma was considerably cheaper than moving them around in code.

Prior to building with the help of AI, If you wanted to have as much control over the final product as possible, doing the detailed design work in Figma was the price you needed to pay. You had to make the detailed pictures so that when you handed the design over for building, your front-end developer could understand what the work would entail and what you wanted the final product to look like. Going to the effort to be thorough in the ask is one of the ways that designers show their respect for the challenges that come with getting web browsers to do what you want them to do.

After building this site, I’m not so sure that this is how designing is going to continue to work in the future.

When I started this project, I decided that I’d only lay the basics out in Figma to ensure the site was going to work in principle. The rest of the design work would happen directly on a working version of the site itself in Cursor. I wanted to understand whether incorporating AI into my process would result in my having more or less control over the shape of the thing I wanted to create.

The experiment worked far better than I could have anticipated. I built the site up key feature at a time, and worked through the responsive behaviors as they came up.

I even built some tooling in the site to help in the process — a debugger overlay that displayed the current screen width and the breakpoint range. This made it possible for me to describe the changes that I wanted such that Cursor could understand what I wanted without fail.

Cursor made working with the content management system, HTML, and CSS feel like working with clay. It allowed me to rough out a fully functional but basic site, and then sculpt it until it was just as I wanted. I was able to work by tackling the big rocks first, followed by smaller rocks.

This fits my style of thinking far better than Figma does, which is organized around the idea of content being contained in nested frames whether you’re ready for this or not.

The thing that was interesting to notice was that it was much faster and easier for me to make design decisions on the site itself than it would have been in Figma. I didn’t need to wrestle with the Figma’s auto-layout behavior. I could make style changes and have them cascade appropriately across elements that shared the same CSS. There was no drift between an idealized design and the working site as is typical.

Building and designing with Cursor gave me significantly more control over the layout than I could do in Figma, and the whole process was much faster than if I had detailed everything out in Figma and then had to translate this into HTML and CSS, grappling with the inevitable mismatch between as-designed and as-built.

I was also interested to observe that I didn’t design more of the site than I needed to. When coding is expensive, it’s common to attempt to design a lot more than will ever actually get built. You try to anticipate all of the possible edge cases you might run into, just to build confidence that the core of what you’re going to build will handle enough of the key problems. I didn’t need to do this. When there was a problem with the design, or something I missed, I could see it instantly and come up with a new solution, and see if that made it better within the span of minutes.

Essentially, this project incorporated a much higher percentage of my design time because the act of designing had merged with the act of building.

And by designing at the point where ideas turn into working code, the site got better faster — as did my ideas. The more I understood how the underlying content management system worked, the more sophisticated I could get in what I asked for. The rate of improvement accelerated over the duration of the project and I got to be surprised by where it (and I) ended up.

This sense of surprise is perhaps the most profound part. When the design tools we use condition us to supply them with every detail of the design before our ideas can be turned into software, then the design tools we use ultimately ask us to narrow our thinking — and limit our expectations for what we’re making. By specifying how we expect the final, dynamic product to be through static pictures, we leave very little room for it to become something else, or something more.

Coming back to earth, one designer using AI coding tools to build out a custom blog isn’t the same as an organization designing a software product meant to serve a large number of people. I had the luxury of taking shortcuts and could move to coding before having everything worked out. It’s hard to imagine an established product team being willing to do this — yet. Figma still offers a great deal of value.

It’s also worth noting that this blog wasn’t asking very much from a technology perspective. Because this site is made of the same stuff as the web, and this is what LLMs have been trained on, anything I asked for was a relatively simple pattern matching exercise. If ever there were an LLM-shaped problem, it’s this project. It was almost purely happy-path from an AI usage perspective and so it’s not a real test. Making software under real-life conditions is a lot messier and dynamic than this, and the consequences for fucking up are much greater.

By doing the rough designing in Figma but making all detailed design decisions directly in working software, it helped me notice how static designs are far harder to evaluate than a working product. No newsflash here. We always notice the things we missed when we can see our designs moving.

Being able to resize the window and see how the site reacted, and then make changes directly to the site was significantly easier and faster. Just dealing with the quirks of layout in web browsers was far more direct than having to cajole Figma to be able to handle all of the variations I thought I might encounter. There’s a big difference between trying to imagine all of the possibilities versus dealing with them directly. The first gives you the illusion that you’ve anticipated everything, and the second just lets you solve the problems as they occur.

Another benefit of shifting design over to working software as quickly as possible is that while I was making changes, I was using the thing I was making. Clicking on links, reading text, looking at images, watching to see how the site responded to different screen widths, etc.. I was directly engaged with how the content management system operates, and gained first-hand knowledge of how it “thinks”. The more you understand the underlying capabilities and limitations of the technologies you’re building with, the more effectively you can design for it. This also seems like an important signal.

My experience building and designing the site with AI coding tools makes me think about the gap that Figma originally collapsed between designing and design review.

People tolerated this gap and assumed it was just the cost of doing business when there weren’t any alternatives. We believed there was a distinction between designing and collaborating because that’s all the technology would allow.

Once people started to see the benefits of designing in software meant for organizations of people, and once they saw that it was possible to do without the impedance of having to prepare and curate designs for sharing, Figma took off.

My experience of designing and building this site with the help of AI coding tools leads me to think that just as Figma enabled organizations of people to design software, I think we’re going to see a new set of technologies and tools change the nature of designing again.

It won’t be because the computer industry finally figured out how to make the easy button that can one-shot a fully realized design that does all the things. It’ll be because designers can directly shape and learn from the actual things they are helping to invent, and that’s honestly how it should be.

CAD's Next Shift

Sun, 05 Apr 2026 12:00:00 GMT

Stories of how things came to be in technology fascinate me. How did humans manage to take a technology that was originally used for calculating ballistic trajectories and thermonuclear reactions and transform it into a technology that helps us design and build entirely new things like computer chips, buildings, factories, railways, robots, cars, movies, music, games, and art?

There are four snapshots that immediately come to mind. Two happened during the birthplace of CAD, one happend when humans decided to stop designing on paper, and one that’s still in the process of being figured out.

I’m afraid that I won’t do any of these stories the justice they deserve, but I think seeing them together is instructive. Each of these stories involves people grappling with advancements in computer technology in an effort to make tools that can help humans design complex things meant to function in the real world. Many of the problems they grappled with are problems that still exist in CAD software today.

When we compress time and see how some of the fundamental ideas we take for granted were invented, it becomes easier to recognize that many of our ways of interacting with CAD software aren’t set in stone, they’re just what made sense at the time that they were invented.

Read the full essay

Cursor Impressions

Fri, 03 Apr 2026 12:00:00 GMT

I recently finished the build-out of this site and thought it might be useful to jot down my thoughts on what it was like to work with Cursor.

[↑] Cursor allowed me to build out this site and custom components on top of Astro.

Why Cursor?

I wanted to have a high degree of control over the look and feel of the site. Cursor incorporates a web browser, which makes it easy to see the changes you’re making as you go. The browser makes it easy to point directly at the UI element you want to change so that Cursor understands what you’re referring to. I had a good deal of familiarity with VS Code, which also made Cursor a good choice.

Overall impressions

My experience of building with Cursor and AI was overwhelmingly positive. I had very few hiccups along the way. A good deal of this is due to the underlying capabilities of the models. The ability of today’s LLMs to understand natural language is shocking.

I think the CMS I used as the basis for this site helped a good deal too. Astro is highly structured and modular, and is made of the stuff LLMs have been trained on, so I think it was a great first AI-assisted project to work on. It also helped that I knew exactly what I wanted to have in the end, which made it easier for me to ask for what I wanted.

The overall impression I had of building was one of momentum. Normally when I build something my progress is pretty choppy as I tend to bump into the limits of my knowledge and ability pretty quickly. On this project, my progress was shockingly smooth.

Typical usage pattern

Here’s the basic usage pattern that seemed to work the best for me:

Step	Mode	Note
1	`Ask mode`	Ask what would be involved in making a change I have in mind. Point directly at the thing to change in the browser or file list. Add screenshots if needed.
2	`Ask mode`	Ask for options along with pros and cons. Continue asking questions until I’m confident I understand what was at stake.
3	`Plan mode`	Ask to make a plan based on the conversation.
4	`Plan mode`	Add any additional adjustments and clarifications to the plan.
5	`Agent mode`	Build the plan.
6	`Agent mode`	Review the results. Make additional manual adjustments and tweaks with the inspector, or in the code.
7	`Agent mode`	Follow up with additional related enhancements until feature is complete.
8	`Git`	Commit changes.

What worked well

I had surprisingly few hiccups along the way, and none that stopped me from building the site out in the way I wanted. It’s hard to articulate just how smooth the process was relative to me having to manually build this out. Here’s what worked for me:

Tactic	Note
Vanilla Cursor	I used vanilla Cursor in order to assess what it could do. No skills. Cursor seemed to have a good understanding of how Astro is structured just from examining the code.
Incremental building	Building up interfaces one component at a time worked far better than one-shotting an entire page. This enabled me to build up the site one key component at a time, and ensured that the changes I made did not degrade the site over time.
Making small changes	Numerous, smaller rounds of changes also helped me better understand how to effectively ask for bigger changes.
Screenshot references	Uploading screenshots of the features I wanted to build seemed to work better for me than through Figma’s MCP server. I found that when sending Figma links to Cursor, the resulting CSS code would be messier than through screenshots.
Debugger	Debugging mode was very helpful in a few spots where Cursor would make a change I had requested, confidently assert that it was successful, but clearly was not. Debugging mode would take into account the plan that I had asked for when the original changes were made, and this reduced the amount of framing I’d need to do in my debug request.
Stack trace copy-and-paste	Pasting Astro error stack traces into the debugger easily resolved any breaking changes.
Explain this feature to me	When starting with a new agent or context window, I’d ask Cursor to explain a feature of the site for me. This enabled me to utilize the same descriptive language Cursor was using, which improved the results.
Natural language	Using natural language requests when operating with shared context was astonishingly effective. No different than if I were art directing.
Example websites	Pointing Cursor at example websites to understand how a certain feature was constructed. Use this as a jumping off point for feature development.
Documentation review	Having Cursor review Astro’s documentation to understand the best way to build a specific feature.
Ask Claude	Asking Claude for an explanation of how a typical feature would be constructed and then using this as a spec to feed into Cursor.

Issues

The issues I encountered while building with Cursor were relatively minor, owing primarily to my unfamiliarity with working with AI-assisted coding. I encountered no major blockers.

Issue		Resolution
Styling errors when translating a screenshot	→	Minor manual tweaking
Too many changes at once	→	Start over and constrain the ask
Cursor over-systematizing	→	Clearer scoping in my requests, minor refactoring/cleanup stage
Cursor under-systematizing	→	Point Cursor to examples in code to follow.
Cursor makes a change that breaks Astro	→	Copy the error message into debug mode.
Styling changes that wouldn’t take	→	Adding screenshots of problem and desired result to the debugger.
Cursor attempts to do too much at once	→	Constrain the problem, reduce the scope of the change.
Poorly or partially executed feature	→	Roll back, reduce scope, be more specific and organized in the ask.

Areas for improvement

Agent integration with UI

From time to time, Cursor got stuck in plan mode or ask mode and would not switch over to agent mode when it came time to build. Near as I can tell, this behavior is session-specific and tied to an agent. My workaround was to start a new conversation, make reference to the plan file created by the original agent, and then continue. Not a huge issue but definitely would take me out of the flow and reduced my confidence in Cursor.

This gave me the sense that the integration between the underlying models and the UI isn’t quite solid. Is this an artifact of the weirdness that must come with connecting LLMs to software that wasn’t designed for this use case? Or is this the weirdness that comes with an Electron based application that isn’t natively written for Macs? Hard to tell.

Cursor’s lack of awareness of its own UI

I was surprised by how limited access Cursor’s agents have to the state of Cursor’s UI. Just as I can ask questions around the codebase I’m working on, I expected to have the same ability when it came to Cursor’s UI. For instance, I might ask “how can I do X in Cursor”, and I’d get an explanation, but no ability to have Cursor enact the change directly.

Code autocomplete gets in the way

Code autocomplete was particularly useful when repeating the same edits in multiple places, but annoying in it’s always-on nature. I felt as if it interfered with my ability to make code edits more often than not. I don’t quite know what the solution is for this. There were a number of occasions where I’d ask a question about the code, get a response that included the code in the application, but Cursor wouldn’t consistently provide links to the specific line in the codebase. I could not find an easy way to tell Cursor to do this.

Browser inspector bugginess

There was a fair amount of bugginess on the browser and inspector side. I had to learn to open the inspector panel to activate the object selection control. Inspector panel resizing could also be buggy in that when dragging a panel border to resize, the mouse release event wasn’t registered, resulting in the panel width following the mouse as you move across the screen.

General text lagginess

Cursor’s UI would often get laggy during longer sessions. I’d notice it when typing summaries for git commits, even when Cursor wasn’t working on a task. Not a deal breaker, but performant text handling should be a given in a code-based tool for software developers.

Thoughts about Cursor as a product

VS Code is a double-edged sword

I think it was smart for Cursor to utilize VS Code from an adoption standpoint. The barrier to entry is much lower for developers who are already accustomed to working with it. Perfectly reasonable approach to take. With this said, I wonder whether the reliance on VS Code — and all the product-level assumptions that might come with it — might prevent Cursor from evolving towards something that is more specific to the needs of developing applications with AI.

The most important parts of Cursor feel like they are shimmed into VS Code’s UI. It may very well be that this is what works best for experienced developers, but I found this to be awkward from a product design perspective. The UI to choose which agent mode you’re in seems hugely consequential, but not very prominent. I suspect a new user would be hard-pressed to tell just how important it is to the functioning of Cursor.

Single document focus

There’s also something about the nature of building with AI that seems different than the kinds of development work that typically happens in VS Code. So many of the changes that Cursor helped me make to this site were global and systematic in nature. By contrast, VS Code seems largely oriented around the idea of viewing and editing just a handful of documents at once, and the browser is oriented around viewing and interacting with one web page at a time.

Significant interpretability challenges

While I’m still early days of working with and understanding AI, it seems to me that one of the strengths of LLMs is that they have a way to see complex relationships and patterns that makes it possible for them to be used to make coherent, systematic, global changes across an application. To do this well requires bringing humans along for the ride. I think there’s a great deal of work yet to be done around visualizing the structure of the code you’re working with and visualizing the changes the model intends to make. The better AI can help humans understand complex structures and changes, the better humans will be at using AI to make complex but understandable software.

Better communication of planned changes

Similarly, the interpretability of planned changes, or changes that have been completed feel like an area for exploration that could use some more interface real estate than what the chat or document panels can easily accommodate.

Systematic software views

I suspect that we’re going to need more systematic ways to present and view the entirety of a piece of software, along with the changes planned or implemented by LLMs. An example of this could be a kind of “super-browser” that utilizes an infinite canvas, just like in Figma. This super-browser would allow all the pages or states of an application could be arrayed on the canvas, and any changes planned or executed could be displayed and highlighted on this canvas. Object selection could also work globally as well - so when you select one instance of an object on a page, you have the ability to select all of the other identical objects throughout the site or application. Surely people are already working on this.

Room to evolve when code isn’t the thing?

As we become more comfortable with the idea of building software with LLM’s I think it’s likely that the code view may become less important as time goes on. People will care more about what the code does, and less about how it is organized. I wonder what it will mean for Cursor’s long term evolution as we figure out what AI native software development norms should look like. I suspect that they will be organized more around system-level interactions and visualizations and less around code views and file structure. This might be a hard thing to pull off for a product experience that’s so closely tied to VS Code.

Using Cursor to customize Cursor

I have a sneaking suspicion that we’ll eventually see AI harnesses that are by default open to the same kinds of customizing and tweaking as the code they are meant to operate on. I don’t know what this is going to look like in practice, and this would impose significant challenges for maintaining and updating the software, but I get the sense that the boundaries between the models and harnesses will be a lot blurrier than how today’s Cursor seems to be organized.

How This Site Was Made

Sat, 28 Mar 2026 12:00:00 GMT

With the tremendous acceleration that’s happening with technology, I wanted to have a public place to think aloud and see what patterns show up. I knew I didn’t want to use a readymade blog theme. I wanted to have the ability to experiment with richer forms of storytelling and visual explanation.

I thought that this might be a good opportunity to better understand whether I could get something useful by building with AI coding assistance. I wasn’t interested in attempting to one-shot a blog into existence; I wanted to see if I could build the site up in a way that would help me explore what the best ways to work with AI.

Here’s what I did.

I started by setting up and exploring Anthropic’s Claude. There’s a great deal of delight and personality that’s carried entirely through textual experiences. This feels appropriate for a technology that’s been fed and trained on textual information. Answers to my questions were concise, readable, and organized. Far easier to digest than search results.

Read the full essay

Full Circle

Sat, 21 Mar 2026 12:00:00 GMT

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:

[↑] This was so good I made it my Slack avatar. Is the man in the picture all-in on the process or is this a cry for help?

[↑] The million-sticky stare. Can’t. Handle. Another. Workshop.

[↑] Don’t let friends abstraction ladder. It’s Post-its all the way down.

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:

The simpler I make the job of designing, the more attention I can pay to what we’re trying to make.
The better I understand the people we’re supposed to be helping, the better I can serve their needs.
The more I understand the wider context, the more likely we’ll make successful products.
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.