Working the Problem

I've made a living in product design for over two decades, a journey that began when I moved to San Francisco in 2000. Early in my career, armed with a cracked version of Photoshop and a budget HP computer from my dad, I created album covers, flyers, and Flash banners. This exploration of digital and graphic arts offered newfound joy and a creative outlet that felt genuinely exhilarating.

Growing up in Pennsylvania, creativity came in all forms—from crafting custom furniture in my father’s workshop to drawing detailed sketches of hockey players to playing drums for hours in my garage. My relentless work ethic, partly born from necessity and partly instilled by my father, was a driving force. Despite lacking a formal degree or any concept of how to make a living working with computers, I carved out a niche in San Francisco’s burgeoning software design scene during the 2000s. Navigating through the tech industry’s first major crash, I kept my head down and focused on what I could control: listen, learn, and create. This approach not only sustained me but also led to significant personal and professional growth amidst the chaos of the dot-com bust.

“I kept my head down and focused on what I could control: listen, learn, and create.”

Over the next two decades, I managed to find success, endure failure, and build relationships with both people and machines. A pivotal moment in my career was landing a design role at Sawyer Media, where I contributed to developing a media player coded in ActionScript. Working alongside Ammon, a good friend and gifted designer, I was introduced to the importance of working a problem—a skill that would help define my design philosophy.

One day, we were challenged to reduce the latency of the images displayed in the carousel. It was a particularly long day, and frustration was crystallizing on the edges of my blurry eyes. Ammon said to me, 'Why don’t we grab a coffee and work the problem?'

“Work the problem.”

Sitting with our coffees, Ammon and I rethought our approach. We started to ask questions. What other ways could we improve latency? After a while, we realized that by recoding the controller function that delivered the images, we could reduce the time it took to display the images by 25%. Experiences like this helped define my design process and underscored the importance of problem-solving. By taking the time to step back and ask new questions, we could arrive at a solution we had never considered before.

Now, 15 years later, I sometimes reflect on these principles and their relevance. Do I still work the problem? I think the answer is—usually. Sometimes the solution presents itself immediately. This comes from years of designing software and my general experience and understanding of how people interact with software. Sometimes it simply comes down to asking the right question that needs to be answered. Ultimately, my design process is about continuous learning, adapting, and asking one question: Do I understand the problem?