I started designing almost by accident, long before “UX” or “product design” were established terms. In the late 90s I was teaching myself to build websites, initially drawn to the visual side but quickly more interested in how things worked rather than how they looked. Early on, design was mostly about aesthetics, but I kept noticing that the real problems were structural: clarity, hierarchy, and whether people could actually accomplish what they came to do. That curiosity pulled me away from pure visual design and toward systems, interaction, and user behavior.

Over time, through work at places like IKEA and later startups, I learned that good design lives at the intersection of people, business, and technology. I didn’t follow a formal UX career path—those barely existed when I started—but instead grew into the role by solving real problems and staying close to the work. Writing became a parallel practice that sharpened my thinking and helped me articulate decisions.

My responsibility as a designer is to make sure we’re solving the right problems, not just executing solutions well. That means understanding users deeply, but also being fluent in the business context and technical constraints shaping the product. I spend a lot of time clarifying intent—what we’re trying to achieve, who it’s for, and what success actually looks like—before anything gets designed.

On a practical level, that includes research, defining flows and systems, shaping interaction and content, and often building or prototyping things myself. But just as important is communication: explaining why a decision was made and aligning teams around it. In leadership or solo roles, the responsibility expands to setting standards, making trade-offs explicit, and protecting focus. Ultimately, my job is to reduce complexity and uncertainty so teams can move forward with confidence and users end up with something that feels obvious and humane.

One of the biggest difficulties is navigating ambiguity while others are looking for certainty. Design work often starts before problems are fully understood, so a lot of the effort goes into framing the problem in a way that’s honest rather than prematurely tidy. That can be uncomfortable for teams that want quick answers or visible output.

Another challenge is resisting the pull toward over-production—more features, more screens, more “progress”—when restraint would lead to a better outcome. Good design often looks like doing less, which can be hard to defend in growth-driven environments. There’s also the constant translation work: turning user needs into business language, and business pressure back into humane decisions. Finally, staying close to the craft while taking on leadership or advisory responsibility is a balancing act. It requires protecting time for thinking and making, not just reacting.

I treat apps as instruments, not destinations. They’re there to reduce friction in my thinking and making, not to define the process itself. I usually start outside of tools—writing, sketching, or outlining—because that’s where ambiguity is easiest to work through. Once intent is clear, I use design tools to explore structure, flows, and systems rather than polish.

I also rely heavily on tools for speed and feedback: prototyping to test assumptions, and AI-assisted tools to summarize research, draft copy, or sanity-check ideas. That said, I’m careful not to let tools collapse thinking too early; high fidelity too soon is a common trap. The goal is always to move between tools and judgment deliberately. If a tool doesn’t help me think more clearly or communicate better, it doesn’t belong in the process.

I’d tell my younger self to stop chasing tools and start chasing understanding. Software will change constantly, but the ability to reason about people, systems, and trade-offs compounds over time. Spend less energy trying to look like a designer and more time learning how things actually work—products, businesses, and human behavior.

I’d also say: write earlier and more often. Writing will force clarity in a way pixels never can, and it will make you far more persuasive than your portfolio alone. Seek environments where you can own real problems end to end, even if the work looks messy or unglamorous. And finally, be patient. A meaningful design career is built through repetition, judgment, and restraint—not acceleration.

I don’t have major regrets, but there are things I would have done earlier. I wish I’d trusted my judgment sooner instead of over-indexing on validation from titles, companies, or louder voices in the room. Early in my career, I sometimes stayed too long in environments where output mattered more than understanding, which slowed my growth in hindsight.

I also underestimated how long it takes to build real taste and conviction—you can’t shortcut that, but I did try. Writing and articulating my thinking came later than it should have, and it changed everything once I committed to it. That said, most of the missteps were necessary; they taught me what kind of designer I didn’t want to become. The journey only really made sense in reverse.

I don’t rely much on traditional design inspiration anymore. Dribbble-style polish fades quickly, and it rarely helps with real product problems. Instead, I stay inspired by paying attention to how things actually work—or fail—in the real world: bad forms, great tools, frustrating services, and moments where something feels unexpectedly humane.

Writing is a big part of it. It helps me turn vague reactions into clear opinions, and opinions are far more useful than inspiration. I also stay close to users; a single honest conversation will out-inspire a hundred trend reports. Finally, I protect time away from screens—walking, reading, building things slowly. Inspiration, for me, comes from clarity and curiosity, not volume.