Katie Kuhens

Do good work. Make cool shit. Grow people along the way.

I get into the mess, then I get it done. That means being accountable for whether the right things get built, whether the team around me is growing, and whether the work survives contact with the rest of the organization.

How I lead

Principles that rule things out

Principles written as decision filters, so the same question stops being reopened in every review.

Evidence before engineering commits

Testing moved to the front and made the decision point, not the sign-off at the end.

Leading what you don't own

Building work to be adopted rather than approved, on surfaces owned by teams that do not report to me.

Growing designers on purpose

Mentoring on a deliberate cadence rather than on request, so growth reaches past the people who already know how to ask.

Principles that rule things out

Alignment doesn't hold because a room nodded once in a workshop. It holds because there is a shared way to decide when people want different things later.

When I reach for this

Several teams shaping one surface, nobody actually owning it, and the same question reopened in every review.

What I actually do

Write the rules down before anyone needs them. A principle invented mid-decision is just the most senior person's preference with better wording.

  1. Name the tensions out loud

    Write down the tradeoffs that will drive every decision before anyone opens a file. Named early, they get settled once instead of resurfacing in every review.

  2. Write filters, not values

    "Good design" is not a filter. A principle earns its place only if it can rule a real option out.

  3. Use one to kill something good

    The first time a principle cuts something people liked is the moment it becomes real. Do it early, and do it where everyone can see.

  4. Hold it when it gets expensive

    Principles are free until they cost something. The one that survives a launch-week rollback conversation is the one the team trusts next time.

What this looked like in practice

The same filters did the deciding on two very different surfaces: a global navigation platform and a product page framework.

Show the detail from 2 projects
Protected: Product Page Evolution
  • Consideration tiers written so a merchant or a component owner could apply them correctly with nobody from my team present. The bar was whether the model traveled, not whether it was right.
  • The structural question of whether the experience should change by product type was answered by the framework rather than re-argued per category: keep the structure, scale the depth.
Protected: Header Modernization
  • Three tensions named before any design started: search against browse, B2C against B2B, feature velocity against architectural durability.
  • Five principles written as filters, among them "optimize for top tasks," "one codebase, two experiences," and "performance must do no harm."
  • A wheel-based navigation concept tested well for attention and still got cut, because it failed the accessibility and scalability filters.
  • When launch metrics wobbled and rollback came up, the principle was the standard the decision got measured against rather than seniority.

Evidence before engineering commits

The expensive mistakes are the ones you build first and validate second. I'd rather spend six weeks being wrong on paper.

When I reach for this

Strong opinions from people with real authority, no shared basis for choosing between them, and a surface expensive enough that being wrong means a long and public unwind.

What I actually do

Treat research as the thing that decides, not the thing that confirms. That only works if you are willing to be wrong in public and cheap to correct.

  1. Move testing to the front

    Testing at the end validates a decision that's already been made. Testing at the front is how the decision gets made.

  2. Run cycles, not studies

    Concepts go in within days and findings go straight into the next round, so a weak idea dies in a week instead of getting defended for a month.

  3. Write the success criteria first

    Decide what would count as being wrong before the study runs. Otherwise every result quietly becomes evidence for carrying on, and the research turns into a formality.

  4. Sequence it cheapest-first

    Order the work so the model can die early, and write the success criteria before each stage runs; otherwise every result becomes evidence for continuing.

What this looked like in practice

Three projects where testing set the direction rather than confirming it, including one study I threw out and re-ran.

Show the detail from 3 projects
Protected: Product Page Evolution
  • About 60 customer intercepts with shoppers caught mid-decision rather than asked to recall one, which established the two jobs the whole framework is built around.
  • Four studies sequenced by effort, each with its success criteria written before it ran, so the model could fail before the next stage got funded.
  • The last of them puts the model in merchants' hands to assign tiers independently, with 80% inter-rater agreement as the bar for whether it is clear enough to scale without us.
Protected: Header Modernization
  • 70+ design variations tested with 250 participants across 26 scenarios, run as RITE cycles rather than one study at the end.
  • A 30-day interaction sample showed over 80% of header activity was transactional while the IA was built for browsing, which turned a preference argument into an evidence one.
  • Tree testing moved findability from 72% to 88% before engineering committed to the build.
Contactless Ordering
  • Under real time pressure, cataloged how competitors' curbside had failed (parking, arrival signaling, needless complexity) and designed against that list rather than copying a working screenshot.

Leading what you don't own

Every surface I have been accountable for belonged, in practice, to other people. Authority has never been the tool available.

When I reach for this

The people who have to carry a decision do not report to me, are not measured on my outcomes, and have their own roadmap. Approval from above does not move them.

What I actually do

Build for adoption, not approval. Authority would be faster, but I have never had it, and work that depends on it does not survive the org chart changing.

  1. Find out who actually owns it

    Map ownership before designing. More than once the binding constraint turned out to be governance rather than craft, and finding that out late cost real time.

  2. Make it teachable, not just correct

    A model that has to travel is simpler than a model that could be exactly right. Every simplification is precision you give up on purpose.

  3. Count the people missing from your metrics

    The stakeholder with no seat at the review is the one who absorbs the cost of the decision. Finding them is part of shipping, not a retrospective step.

  4. Negotiate rather than specify

    When a design changes somebody's actual shift, a specification is really a request. Treating it as one is the difference between adoption and a document.

What this looked like in practice

Three surfaces I was accountable for and did not control, including one where the people the work affected were not users at all.

Show the detail from 3 projects
Protected: Product Page Evolution
  • The team accountable for the page owned less than 40% of what appeared on it, with roughly ten component teams owning the rest.
  • That reset the work: a specification would have been received politely and ignored, so the framework had to become shared language instead.
  • It traveled: the recommendations team, which I have no authority over, independently started building a configurator on the framework's logic, without being asked. That is the whole test of whether this way of working succeeds.
Protected: Header Modernization
  • The header was shaped by teams that shared neither leadership nor a roadmap, so the work got reframed from a redesign into a governance question.
Contactless Ordering
  • Drivers were not users of the app and appeared in no dashboard the team reviewed, so the harm a successful launch did to their earnings was invisible until someone went looking.
  • Most of curbside lived in a parking lot and behind a counter, owned by store operations, which made the rollout a negotiation rather than a specification.

Growing designers on purpose

Scaling design is not just scaling systems. The work outlives any one project, and so should the capability of the people who did it.

When I reach for this

Mentorship usually happens by accident: whoever asks, whoever is nearby, whenever there is time. That produces uneven growth and mostly reaches the people who already know how to ask.

What I actually do

Standing time rather than an open door: bookable outside my org, recurring inside it. Thirty designers so far, and the ones who get most from it are rarely the ones who would have asked.

  1. Hand over the work that stretches them

    Growth comes from scope, not advice. Hand over the visible project with real consequences, stay close enough to catch a fall, and put their name on it when it lands.

  2. Teach career-changers to re-read their own work

    People moving into UX usually have the evidence and don't know it counts. I came from branding. Most of this is helping someone see the judgment already sitting in work they wrote off as the wrong field.

  3. Be specific enough to be uncomfortable

    Vague encouragement is the most common thing a mentee gets and the least useful. If I can't name what's holding the work back in one sentence, I haven't done my half.

  4. Aim at the next role, not the current one

    Career-changers optimize for the job they have. The useful question is what the next hiring manager needs to see, and which of their existing work already proves it.

How I partner

We settle what is in scope before anything gets designed. On the header that meant cutting two features people were excited about, because neither was the problem we had been asked to solve. I would rather have that conversation in week one than week ten.

Six functions, no shared roadmap, and no authority over any of them. What holds it together is alignment on how decisions get made, not consensus on each one.

The principles behind it

Mentorship

I mentor emerging and transitioning UX designers directly through ADPList: portfolio reviews, career-change coaching, and the occasional gut-check before a big interview.

View my ADPList profile View Mentorship Resources

Katie is a UX mentor's dream! She has this incredible ability to meet you exactly where you are in your UX journey. She can offer fantastic suggestions in bite-sized chunks that keep you from feeling overloaded. Plus, she's consistent and reliable. I met with four other mentors before finding Katie, and she's been a breath of fresh air. She helps you move forward with confidence!

Jody H. UX Specialist, Kansas City

I asked for a portfolio review from Katie and it was a wonderful experience! Her ability to identify and suggest enhancements on the finer details truly elevated the overall quality and presentation of my work. She came to our meetings prepared, ensuring no time was wasted. Her feedback was clear and concise, offering excellent guidance and actionable next steps. I highly recommend Katie to anyone looking for portfolio reviews!

Cindy R. UX Designer, John Deere

Highly recommend! I had a wonderful talk with Katie, which was productive and insightful. I truly appreciate it! She gave me amazingly constructive and practical suggestions on job-seeking strategy and my portfolio. Additionally, Katie's skill in prompting deep reflection with simple yet powerful questions was particularly impressive and enlightening. I am looking forward to more meetings with her!

Yi H. UX Student