Loading your
interface experience...
Swipe, scroll, or use the arrow keys to navigate
If you have made it this far through the site, you have probably already noticed that the work does not stay inside one category for very long.
Audio, video, visual systems, live production, artificial intelligence, and whatever else has appeared along the way may initially look like separate bodies of work. They are separate. That distinction matters.
What changed for me over time was not that the differences disappeared. It was that the similarities became more important.
I did not have language for any of that at the time. I was trying to remain functional. The strategy continued to serve me throughout my life.
What began as a way of managing overwhelming information gradually became a way of understanding communication, perception, creative work, tools, organizations, and eventually systems themselves.
The original conditions mattered. They are not the identity that came out of them. The adaptation was.
I did not have language for any of that at the time. I was trying to remain functional. The strategy continued to serve me throughout my life.
What began as a way of managing overwhelming information gradually became a way of understanding communication, perception, creative work, tools, organizations, and eventually systems themselves.
The original conditions mattered. They are not the identity that came out of them. The adaptation was.
One of the earliest places I remember seeing that adaptation reflected back to me was when I got my first Mac. The experience was not simply that I had gained access to a computer.
I had gained access to a system designed around the idea that consistency mattered. Different applications performed different functions, but they shared a common language. The commands repeated. The windows behaved in recognizable ways.
Actions that belonged everywhere did not have to be reinvented every time the software changed.
What made each program distinct was not that everything about it was different. It was that its specialized functions emerged from a coherent foundation. That was important to me. It made apparent that many of the boundaries people treat as necessary are really design decisions.
A system can preserve difference without producing fragmentation. Once I understood that, learning new software became less about treating each program as an isolated territory and more about finding the shared logic underneath it.
That understanding did not remain limited to computers.
My early creative work developed through that same environment. Before I had any formal reason to call myself a designer, I was creating digital artwork.
At the time, I was not separating aesthetics from design because I had not yet been taught to. The design emerged from the aesthetics:
These were not theoretical categories. They were things I was adjusting because I could see when the image was resolving and when it was not.
Later, working alongside professional designers gave structure to intuitions I had already been developing. It gave me a more formal understanding of why certain decisions worked, how visual systems could be extended, and how design functioned beyond the production of something attractive.
That did not replace the earlier process. It clarified it. The same thing happened repeatedly.
I would begin by doing something because I could perceive that it worked. Then, through experience, comparison, conversation, or another discipline entirely, I would gain better language for what I had already been doing.
The language did not create the capacity. It made the capacity easier to examine, refine, and transfer.
Keynote became another important part of that process. I began building presentations because the information I was working with was not being communicated as effectively as it could have been. The need came first. The software gave me a sufficiently capable way to respond to it.
At the beginning, I was already making intentional decisions about where attention should move:
I understood what I was doing intuitively long before I had a useful phrase for it. Later, I came to understand it as attention control. That language helped, but the process was already there.
What made Keynote important was not only that presentation software can sequence information. Any presentation software can do that.
It was the quality of the tool itself:
The way those capabilities were exposed through the interface made the refinement worth pursuing.
The more I understood the software, the more it rewarded understanding. It did not force me to spend all of my energy compensating for the tool. It gave me room to ask:
What else could be integrated into it?
Graphics developed somewhere else:
Each could retain its own function while becoming part of a larger authored experience.
At that point, the presentation was no longer simply a container for information. The way the information moved had become part of what the information meant.
This is where the relationships between disciplines began to matter more than the boundaries around them. Not because every domain is interchangeable. It is not:
Understanding how they connect does not remove the responsibility to understand them separately. It increases it. A weak understanding of one domain does not become stronger simply because it has been placed beside another.
What changed was that I stopped assuming the separation between them was absolute. A domain could remain complete in its own context and still contribute something to a larger system.
Sometimes that contribution was literal:
Other times what transferred was not the material itself, but the principle:
The more I worked across different kinds of systems, the more obvious it became that knowledge was rarely confined to the place where I found it.
If you think about it at this point, everything being described may be revealing this idea throughout what you’ve already experienced in this website. The individual works may have initially seemed unrelated because they were produced in different domains and for different purposes.
What I came to understand is that the end result was only one visible state of a much larger process.
The deeper work was often happening before the finished thing existed:
Finding relationships between elements that had been treated as separate. Deciding which parts of the process should remain visible and which should disappear into the system.
Building a structure capable of carrying more than one function without becoming incoherent.
That is why the work can look different while still feeling related. The sameness is not in the output. It is in the way the output was approached.
This also changes what it means to solve a problem:
Those descriptions may be correct, but they are not always complete. The named problem is often only the place where the system has become visible enough to cause discomfort. The more useful question is:
What produced the condition?
That does not mean every project needs to become an investigation into the nature of reality. It means that solving the visible symptom without understanding the relationship around it often preserves the mechanism that created it.
Sometimes the right answer is still simple. But simplicity reached through understanding is different from simplicity imposed before understanding.
One removes unnecessary structure. The other may remove necessary context.
The same principle applies to the way a system carries knowledge:
The logic that allowed it to function matters too. If that logic remains inaccessible, then the system can be used, but it cannot be understood as deeply, criticized as effectively, improved as intelligently, or extended as far beyond the person who created it.
Sharing the system is therefore not separate from developing it. It is another stage of the same process. The more clearly the structure can communicate why it exists, how its parts relate, and what conditions shaped it, the more durable and extensible it becomes.
That does not require exposing every detail. It requires exposing enough of the logic that the system is not dependent on mystery in order to preserve its value.
This page is part of that. It is not only describing the process. It is showing enough of the process for the connections to remain available outside of my own head.
Refinement enters after that:
Refinement is the process of making the structure carry more of its own weight.
When something has been considered deeply enough, the person engaging with it is asked to perform less irrelevant labor. The interface communicates more clearly. The information arrives in a more coherent order. The workflow does not require unnecessary compensation. The cognitive load is moved away from figuring out how the system works and toward whatever the person actually came there to do.
That is one reason attention to detail matters. It communicates that the user has been considered. It shows that their time, perception, and effort were not treated as disposable. It also changes how the less visible parts of the work are understood.
When care is apparent in the surface, it becomes evidence that the same standard may exist in the structure underneath it. Refinement does not guarantee that a system is good. But a lack of refinement often exposes where the thinking stopped too early.
A refined system can also reveal more of its own logic:
At its best, refinement does not make the system louder.
It reduces the noise until the signal no longer has to compete with the structure carrying it.
The work throughout this site is still:
...and everything else it appears to be.
None of those descriptions are wrong. They are simply not the whole structure. What connects them is not a single medium or a fixed professional category.
It is the continued development of a way of perceiving relationships, building coherence across difference, and creating systems in which the parts become more capable because they have been understood together.
The projects did not become the same thing. The process underneath them did.