Interview questions, already answered.

I'm a product designer who came to UX through graphic and web design. What pulled me over was the problem-solving: how people think, how they decide, and why they do what they do. I spent most of the last decade at Inuvo working on AI-powered audience and analytics products. Before that, at Verizon, I went from production design to leading design for campaigns and phone launches, and designing user flows is where it clicked.

I started teaching myself design at 13, making boy band fan pages. When I found out people would pay for it, I thought I'd struck gold. I'm still completely self-taught and still learning. What I want is simple: do good work, get paid for it, and enjoy my life with my family.

My role at Inuvo was part of a company-wide reduction in force in May. Since then I've kept designing through client work at my own studio, and it's reminded me how much I like working inside a product team, where the work gets better because you're solving real problems together. So I'm looking for a role where I can do that again, on whichever products the team needs me on.

My role at Inuvo was cut in a company-wide RIF in May. I have bills to pay, and my husband is tired of me starting new companies just so I have dashboards and websites to build. So it's time I go work for one that already exists.

Unifying IntentKey, which never shipped. Inuvo's tools were split up, so setting up an advertiser, reading its model, and managing its segments happened in different places, and people had to hold the connections in their heads. We'd talked about merging them into one product, but the work hadn't started when I was laid off, so I designed the concept on my own.

I made the advertiser the anchor, put delivery failures in front of the people who can fix them, and gave clients a simpler view with no internal jargon.

I worked in marketing at an ad tech company for five years and couldn't have told you what we sold. Then I saw how the sausage got made: a dashboard for this, a dashboard for that. I campaigned for one dashboard to rule them all. We talked about it for a while. Then I got laid off before anyone started.

So I designed it anyway, for free. Some people journal for closure. I design enterprise software.

Our new CEO wanted a fast rebrand, and I understood why: a new leader wants the company to look like the direction they're taking it. I sent a short discovery questionnaire so we could tie the colors and the homepage to what a first-time visitor needed to understand and what the business needed the page to do. I was told it wasn't needed, and I didn't push past that, because the timeline was tight and the decision wasn't mine.

So I kept anchoring my feedback to those same two things, whether a visitor could understand the product and whether they could find their way into it, and I explained my recommendations in those terms. When a decision went another way, I adapted and made the version we shipped as clear as I could. What I took from it: the best way to disagree is to point at goals everyone shares, so the other person can say yes to your reasoning without giving up their call.

Our brand-new CEO wanted to do something big, and the something big was a rebrand on a very short clock. I sent a discovery questionnaire, very politely, and was told we didn't need it. I took that in stride, kept tying every recommendation to what a first-time visitor needed and what the business needed from the page, and let the CEO make the call. Lesson learned: it's easier to say yes to a reason than to a preference, and that goes for me too.

I start with the problem, the users, the business goals, and what's already working. Designers can get so focused on the next big thing that they fix what wasn't broken, so I protect what works and improve what doesn't. Then I show work early and often, even when it isn't polished. Aligning on a few screens up front is much faster than redoing a whole Figma file later.

My process is not a pretty whiteboard of squares, squiggles, and arrows. It's messy, and the magic lives somewhere in the mess. Sometimes it lives in my head, and I have to remember to put it somewhere so I can prove it exists.

Feedback is one of my favorite parts of the process, and I never expect a first draft to be the final one. Some of the most useful feedback comes from people who aren't designers: engineers who see constraints I can't see from Figma, stakeholders who know what the business needs, and people new to the product who show me where it breaks. I try to work out what a comment is protecting, a user's need or a business goal, so I fix the real problem and not just the comment. When I disagree, I explain my reasoning in those same terms, and I'm glad to be shown I'm wrong.

I never expect a first draft to get the final stamp of approval. If it did, I'd be a little concerned.

As a design partner. I use it to brainstorm, find edge cases, and speed up the boring parts, and to build working prototypes so I can test an interaction before it reaches a developer. The important decisions stay mine.

It brainstorms with me at 2 a.m., it never gets tired of my edge cases, and it builds prototypes faster than I can explain them. But it still needs someone to tell it what good looks like. So no, it's not replacing me. It's my intern. A very fast, very confident intern who is sometimes very confidently wrong.

I can come across as quiet, and in a corporate setting that can get me undervalued at first. I'm an introvert and a thinker, so I'm rarely the first one with an idea in a meeting. But the fastest answer isn't always the best one. I make my thinking visible by following up with ideas that are more considered than what I'd say on the spot. I'd rather say one thing that moves the work forward than five things that fill the silence.

I'm an introvert. In a lot of meetings, the loudest idea wins by default. Mine tend to show up about twenty minutes later, in a message that starts with "Okay, I've been thinking…"

I cover more of the problem than most designers: brand, UX and product, and enough development to hand off work that gets built the way I designed it. At Inuvo, I was the only designer on IntentKey, and I led the platform design and a rebrand that landed in the middle of it. And teams keep me. When I left Inuvo for a year, they kept me on as a contractor the whole time.

As a certified introvert, I find the interview process roughly as fun as a root canal. So if you hire me, I'm going to be a really good employee and do the best work I possibly can, so you'll want to keep me as long as the company exists and I never have to do this again.

A team that values direction before design, gives real feedback, and trusts its designers to shape the work, whether that's one product or several. I want room to grow into more strategy and leadership. And somewhere I can stay. I spent most of a decade at my last company, and I want to make that kind of commitment again.

Good work, a good team, a paycheck that clears, and enough life left over at the end of the day to enjoy my family. I'm not chasing a title or a ping-pong table. I just want to do work I'm proud of somewhere I never have to leave.

I'm very self-aware. I can tell quickly when I don't know something, and I'm not afraid to say so or to own a mistake. Nobody gets everything right all the time. What matters is catching it early and figuring out what to do, whether that's learning it, fixing it, or bringing in someone who knows more, before it affects the timeline or the scope.

I know what I don't know, and I'll tell you before it becomes your problem. "I'm not sure, let me find out" is a wildly underrated skill.

Early and often. I bring engineers in before the design is settled, because they'll spot constraints I can't see from Figma. I understand front-end development well enough to design things that can actually be built. And when Figma can't show how something should move or behave, I build a quick working prototype so developers see exactly what I mean instead of guessing from a redline.

My title once had "engineer" in it, so I know exactly how annoying a vague redline is. I try not to send those. I send working prototypes instead.

On the IntentKey Platform, I assumed that if the design was clear and explained the product well, it would make its own case. I was wrong. When decisions about the homepage came down to opinions, I had no data behind my recommendation, so the conversation became my judgment against everyone else's. I realized that grounding my reasoning in what users need wasn't enough on its own. I also had to show it served the business, and a number is the fairest way to do both. Now I build in a way to measure from the start, even something small like a quick comprehension test or tracking how many people finish a key flow, so the next conversation is about what the evidence says about the customer and the goal, not about whose preference wins.

I used to think good design would win the argument on its own. Then I met a room full of opinions, mine included. A number lets everyone argue about the same thing, so now I bring numbers.

Running a brand and web design studio lets me work across lots of different products and be really creative. Working in-house lets me use both the analytical and creative sides of my brain, and stay with a team's business goals and the experience of the people using the product over time, across whichever products it owns. If a role needed my full focus, I'd close the studio. Otherwise, I'd keep it going on my own time.

The studio scratches my creative itch. A product team scratches my analytical one. If you need me to close the studio, I'll close it. If not, it goes back to being what every designer has: a side project I work on after the kids go to bed.

Real words and the unhappy path. Placeholder copy and a perfect happy path make every design look finished. I ask to see the screen with real copy, and what happens when things go wrong: the error, the empty state, the slow load, the person who doesn't have access. That's where people actually get stuck, and it's where the business tends to pay for it, in support requests and abandoned flows. It's usually the part nobody designed, so I ask to see it before we call the design done.

Show me the error message. Everyone's happy path looks great in Figma. I want to see what happens when the payment fails.