Questions Addressing What I Think, How I Work, Why I Build
A Simple, honest, introspective.
Before that - A glimpse at my work
coming soon
Q1: What does your design process look like?
Honestly, I’d say my design process is somewhere between organized chaos and inspired recycling. I don’t believe in rigid frameworks. Sometimes I’m sketching low-fidelity ideas, sometimes I’m jumping straight into Figma with a reference or an old file I can remix. A lot of my process is built on recognizing patterns — a layout I’ve seen before, a structure that worked in the past or a component I’ve used 10 times that still works. I’m mostly not reinventing the wheel, only picking and choosing when to reinvent it—and maybe make it a little prettier.
Q2: Do you follow a set methodology like Design Thinking or Double Diamond?
Not really. I mean, I get the value of those models, but I treat them more like reference points I use to build my own custom roadmaps. Each project has its own texture, and forcing every idea through the same funnel might not be very realistic. Sometimes you start with research, sometimes you just know what needs to be done and jump into prototyping. It’s all fluid.
Q3: How do you balance creativity and constraints?
This is where my frontend knowledge is advantageous. I’m always thinking, "Can this be built? Will this scale? Is this performance-friendly?" So even while I’m pushing the visuals or doing something experimental, I have this little dev whisper in my ear asking these questions. Constraints don’t limit me—they actually sharpen the work and make collaboration better.
Q4: Do you have a signature style?
Nope. I kind of avoid that on purpose. I’m not trying to inject me into every project(sometimes I do). But the goal is mostly to extract the essence of the idea, the brand and the people behind it—not make it look like it came out of my personal template. That said, my only “style” is simplicity, intention, and a little edge where it fits. I work hard to get to the kind of simplicity that’s not just minimal, but meaningful. Disappearing into the background and letting the brand speak. That’s the goal. Not aesthetics for aesthetics’ sake. But something well researched and built so thoughtfully—even the back panel nobody sees is solid wood.
Q5: What role does speed play in your process?
I like to get to something real, fast. A screen, a flow, a mock—something we can look at and respond to. I don’t believe in waiting for things to be perfect before sharing. I push for speed because momentum matters. I like to test ideas, prototype quickly, and keep moving. If something flops, cool—we haven’t wasted weeks perfecting the wrong thing. This might be a leftover instinct from the tech side of me. But it’s also philosophical. You need to keep going to get to the good stuff. Jobs once said, “The first solutions you come up with are very complex... but if you keep going and peel the layers, you get to something elegant.” A simple approach: build fast, learn fast, refine. Calculated speed and not just haste to get to mediocre results.
Q6: Where do you draw inspiration from?
Everywhere. Conversations, old books, random UI patterns I screenshot at 2am. But mostly—I draw from context. I ask, “What makes sense here? What’s the right tone for this?” I don’t wait for inspiration to strike like lightning. I go looking for it. Steve once said (maybe i’m quoting Steve a little too much but bear with me😂), “Creativity is just connecting things.” Looking back at some of the things I’ve designed, I realize most of it didn’t come from thin air. It came from noticing things, absorbing them, remixing them with intention.
Q7: How does your coding background influence your design?
Massively. Knowing how code works means I naturally design with constraints in mind. My designs are structured, responsiveness aware, and have implementation realities baked in from the jump. The fluency in both languages helps me speak between dev and design without needing a translator. Performance, hierarchy, spacing— all of this is the experience and the experience is the product.
Q8: Do you work better alone or with a team?
I thrive in both. Solo, I move fast, explore, and go deep. With a team, I grow. I love bouncing ideas off people, getting challenged, and seeing blind spots. The sweet spot is usually starting alone to generate momentum, then syncing with others to refine and improve.
Q9: What happens when a project doesn’t go as planned?
I’m okay with scrapping things that don’t work. I’m not perfect. If something’s not sticking, we pivot. I’ve learned not to get attached too early. Process is messy, and that’s normal. The goal is always forward.
Q10: How did your hybrid role as a designer/frontend dev come about?
I was originally on the software engineering track—deeply drawn to the idea of building systems that solve real problems and create real value. That builder instinct has always been core to me. But early on, I hit a wall. I realized I could build functional things but those functional things had interfaces that needed to be designed and not just templated. So I turned to studying design—almost as a necessity. I wanted to be able to cover the full spectrum from design to dev solo. I picked up a Figma course and the journey to self taught designer began. It slowed down my software engineering track slightly (because you’re learning two different things - technical and creative - simultaneously) but I have zero regrets because now I don’t just think like a developer—I think like a product. That’s how the “hybrid” role happened. Not by title, but by necessity. And I’ve leaned into it quite well ever since.
Q11: What do you value most in collaborators?
Honesty. The ability to say "I don’t think this would work but let’s figure it out." I appreciate working with devs who care about the experience, with PMs who respect creative mess, and with founders who trust but also challenge. The best work I’ve done came from spaces where everyone had a stake and wasn’t afraid to speak up, learn and challenge standard conventions.
Q12: What's one thing people misunderstand about design?
That it has to be flashy or new to be good. Sometimes the best design is invisible. Sometimes it’s boring. That’s okay. Design isn’t always the hero—it’s the glue. The system. The thing that makes everything else make sense.
Here’s how it all comes together
This mindset—of thinking in systems, moving between pixels and code, and focusing on how things feel and function—is baked into everything I work on. From brands finding their first visual identity to products designed to scale, I approach each project like a collaboration between designer, developer and stakeholders … because that’s what it is. Have a look at some of my selected work.