A designer's answers
to the real questions.

I'm a full-stack developer and designer with 18 years of experience across both disciplines. That dual background isn't a split identity — it's a perspective. I see interfaces the way an architect sees a building: structure first, then skin. I know why a design decision will or won't survive contact with code, because I write the code too.

I've spent years designing and building for wellness, health, and performance platforms. I understand users who are trying to change — to move more, eat better, recover faster, focus longer. That shapes how I think about friction, motivation, and the emotional arc of a product experience. When someone is trying to build a new habit, every unnecessary tap is a reason to quit.

I also make abstract digital art. That's not separate from my design work — it's where I work out questions about color, emotion, and visual language before they become UI decisions. The same instinct that led me to name a painting Worthy shapes how I think about what a user should feel when they complete a goal.

And I use AI as a thinking partner. Not to generate output and ship it — to think faster, explore further, and stress-test ideas before committing. Knowing how to collaborate with AI effectively is itself a design skill. I know how to push it, redirect it, and recognize when its output needs my judgment to become something worth building.

My process is non-linear — and I've stopped apologizing for that.

Most design methodologies move from simple to complex: define the problem, sketch a few ideas, pick one, refine it. My process runs the other direction. I start by making the problem bigger, not smaller — every possibility, every constraint, every edge case — and then I work toward clarity. The complexity comes first. The simplicity is what I have to earn.

That means early work looks messy. Multiple directions happening at once, threads that don't connect yet. That's honest — that's what a complex problem actually looks like before someone has solved it. The danger of starting too simple is that you skip the hard questions and call it clean thinking.

I trust the happy accident. Some of the best decisions I've made emerged from a constraint, a limitation, a wrong turn that revealed something the right path wouldn't have shown me. I've learned to notice when something unexpected is better, and to follow it even when it breaks the original plan.

I prototype to think, not to present. An early prototype isn't showing you what the product will look like — it's asking a question. I'll build three versions of the same flow not because I'm unsure, but because the differences between them teach me something no document ever would. Some of my best design decisions came from noticing something unexpected in an early build. I also look hard at analogies — the best solutions to design problems often come from completely different domains, and I actively look outside the problem space for frameworks worth borrowing.

I use AI the way you'd use a smart collaborator who has read everything and needs your taste to make any of it useful. Not delegating to it, not generating from it — thinking with it.

Here's what that actually looks like: I describe a problem, AI explores the space, I evaluate the output. Not just "yes" or "no" — but "yes, and—" or "no, because—" and then we go again. The iteration is where the value is. One pass rarely produces anything worth shipping. Three passes with good redirects usually does.

Day to day, AI shows up across every phase. Early on, I use it to map problem spaces and generate competing approaches faster than I could explore alone. In design, I collaborate with it on copy, microcopy, and error states — the writing designers often rush at deadline. I use it to explore color systems, pressure-test layout decisions, and argue the other side of my own thinking. In development, I use it to scaffold components and debug edge cases, where the feedback loop is tightest because code is immediately testable.

What I never automate is the synthesis — the moment where you look at everything and decide what this product is actually going to be. That requires taste, domain knowledge, and real understanding of the specific users you're building for. The skill isn't using AI — everyone uses AI now. The skill is knowing when to trust it, when to push back, and when to throw out what it gave you entirely. That instinct is the work.

I start with a question: how should this feel? Not how should it look — how should it feel. The visual system follows from the answer.

Color is the fastest signal a design sends. Before a user reads a word, they've already received an emotional message from the palette. My approach is shaped by making art — when I work on a painting, I'm not choosing colors that are correct, I'm choosing colors that carry a specific emotional weight. I bring that same question to UI: what does this hue communicate? Is it calming or urgent? Trustworthy or energizing? Warm or clinical? The brand color isn't just a color — it's a promise about the experience.

For typography, I think about personality and hierarchy simultaneously. The typeface you choose tells users what kind of product this is before they read anything. I look for pairings that create contrast — one voice for structure, one for editorial content — and test them at both large display sizes and small body sizes before committing.

Beyond color and type, I'm drawn to generous whitespace, editorial hierarchy, and motion that means something. Space is how you direct the eye without pointing arrows at things. Good hierarchy is invisible; bad hierarchy is why users give up. And animation should orient the user or confirm an action — movement without purpose is noise.

A design system is a language. Users learn its grammar unconsciously: this color means action, this weight means important, this pattern means navigation. Consistency isn't a constraint on creativity — it's what makes the creative moments land.

I paint emotional states. The works in my art portfolio have titles like Worthy, Deep Pain, Peace, Trust, Affirmation — color and form are doing specific emotional work in each one. That's not separate from my design practice; it's the same practice in a different medium.

In UI, emotion moves through color before words. A calm blue communicates something different than an urgent red before a user reads a single label. When I design an experience, I'm thinking about the full emotional arc — how does the user feel when they open it? When they complete a goal? When they fall off their routine and come back? Design shapes all of those moments, not just the happy path.

Action comes from hierarchy and contrast. The thing the user should do next needs to be the most visually obvious thing on the screen — not through gimmicks, but through clear contrast between primary, secondary, and tertiary elements. When hierarchy is right, users don't decide where to look. They just look there.

Friction is the enemy of behavior change. I've spent years designing for users who are trying to do hard things — move more, eat better, build new habits. Every unnecessary step is a reason to stop. User-centered means starting from the user's goal, not the system's capabilities. The question isn't "how do we expose this feature?" — it's "what is this person trying to accomplish, and how do we get out of the way?" I think carefully about progressive disclosure, default states, and the moments where the design either earns trust or loses it.

Structure before skin. Every time.

I think about information architecture before visual design. How do you organize content so users can find what they need without having to think about it? What mental model will users arrive with, and does the structure match it — or does it need to teach them a new one? I default to shallow over deep: fewer levels, clearer labels, honest language rather than internal terminology that means nothing to the user.

My background as a full-stack developer shapes these decisions directly. I know what certain architectures cost to build and maintain. I know which patterns create technical debt that eventually surfaces as user-facing bugs. A design that looks right on screen but requires a brittle data structure underneath will fail eventually — and it will fail on users. I try to make decisions that are honest about those downstream costs before they become someone else's problem.

The question I always ask: what should a user be able to do from anywhere? Some actions are so core to a product they should never be more than one step away. Surfacing those correctly is an architecture decision, not a UI one. Get it wrong in the structure and no amount of visual design will fix it.

I start with situation, not persona. Personas can flatten users into stereotypes. The more useful question is: what situation is this person in, and what are they actually trying to accomplish? Situation is specific. Situation is where real behavior lives.

For wellness products, I've learned that stated goals and actual motivations are often different. Someone says they want to get fit. What they actually want is to feel capable again, or to have energy for their kids, or to prove something to themselves. The surface goal is the ticket in. The real motivation is underneath — and the design that serves the real motivation is the one people come back to.

I use prototypes as a research tool, not just a deliverable. An early prototype isn't polished enough to impress anyone — it's specific enough to ask real questions. Does this feel right? Is this the information you'd actually want here? Can you find what you need? The answers tell me things no interview alone would reveal.

I listen to what users do more than what they say. In interviews, users are often generous — they tell you what they think you want to hear, or what they wish were true about themselves. The real data is in the behavior: where they hesitate, where they ask questions, where they go back. Watch that closely enough, and the design tells you what it needs to be.