ARTURO SALEK ← Back to work
Cross company · SYS·03 · Design Systems

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.

Companies
Netcoins, Videri
Focus
Design systems, hardware abstraction, team leverage
Central question
Can the product and the design team both keep growing without reinventing themselves every time?
01
One decision
02
One reusable pattern
03
Multiple workflows
04
Product system
05
Design organization
StandardizePatterns, controls, states, feedback
Allow variationHardware, enterprise edge cases

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.

Standardize

Common interaction patterns, controls, states, navigation behaviors, feedback, visual foundations.

Allow variation

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.

See it in practice