Designing systems that scale
As my scope increased, I moved from designing individual experiences to designing the systems that let products and teams keep growing.
The solution to today's problem can become tomorrow's constraint
Early in my career, success meant solving the problem in front of me. As I gained experience, a different problem became apparent: a one off component becomes five variations, a workflow gets copied into another part of the product, a designer solves a problem differently from another designer, and eventually the product and the team begin accumulating inconsistency. My work has increasingly focused on preventing that accumulation.
01 · Learning to think in patterns
At Brock Solutions and PEER Group, the primary challenge was learning how to solve individual product problems well. But repeated exposure to enterprise software made something apparent: the same interaction patterns appear again and again. Users need to find something, configure something, understand state, make a change, confirm an action, recover from an error. The product gets better when those interactions don't have to be reinvented every time.
02 · Creating cohesive product experiences
At Netcoins, I applied that thinking to a different type of product. Instead of considering individual screens independently, I increasingly treated the experience as a system: navigation, information hierarchy, transactions, states, and interaction patterns all needed to reinforce one another. A product becomes easier to use when these layers agree with each other.
03 · The scale problem at Videri
At Videri, the need for systems became much more obvious. The product was growing, the number of workflows was growing, the number of hardware configurations was growing, and the design team was growing: two scaling problems at once.
Product scalability
Can the product support new functionality without becoming inconsistent?
Design scalability
Can multiple designers contribute without every decision needing to go through one person?
04 · Design systems
Design systems became one part of the solution, but the important thing wasn't simply creating reusable components, it was deciding what should become reusable.
Common interaction patterns, controls, states, navigation behaviors, feedback, visual foundations.
Hardware capabilities, specialized workflows, enterprise requirements, different content types.
The goal was not uniformity. It was creating a system where designers could make intentional exceptions rather than accidental ones.
05 · Designing for hardware variation
Hardware made this especially important. Videri needed to support different hardware platforms and capabilities. A system built around one device could easily become a collection of exceptions as new hardware was introduced. Instead, I worked toward a hardware agnostic approach: shared product experience → capability layer → hardware specific implementation. This meant the platform could maintain a consistent conceptual model while accommodating real differences underneath it.
06 · Portal 3 as a foundation
Portal 3 wasn't simply another redesign. It was an opportunity to establish stronger foundations for the product as a whole, introducing reusable ideas around navigation, information architecture, component patterns, object relationships, responsive behavior, and device management patterns that could be reused as the platform continued to evolve.
07 · Scaling the design team
The same principle applies to people. As I moved into a more senior role, I began leading design across internal and outsourced designers and mentoring other designers. If I personally solve every problem, I can only increase output by working more. If I create systems, patterns, principles, and context that allow other designers to make good decisions, the impact compounds.
08 · The compounding effect
A good system creates leverage. One decision can influence dozens of screens. One interaction pattern can eliminate repeated design work. One piece of mentorship can improve the work of another designer across multiple projects.
One decision can influence dozens of screens. One reusable pattern can eliminate repeated work. That's the kind of leverage I increasingly look for in my work.
Where this has taken me
My career started with learning how to design individual experiences, then how to understand complex products, then how to design products through change. Increasingly, my work is about creating the systems around the experience: systems that make products easier to extend, that make complexity easier to manage, that let designers work more independently, and that let a product grow without reinventing itself every time. Individual screen → reusable pattern → product system → design organization. The scope of my work has expanded with each step.

