Tag: product

A New Job Is Lurking Inside Your Design/Product Org

AI capability inside a design org doesn’t distribute itself.

Enthusiasts will adopt it, of course. They build their own local workflows and see some gains. They may hoard the knowledge — not out of malice, but because nobody’s asked them to share it around. Everyone else keeps working in more traditional fashion, often quietly ashamed of their (self-diagnosed) ignorance.

This is AI Adoption Debt. And it’s not a training problem. Training can build knowledge, but it doesn’t build systems.

The role that builds those systems is forming right now inside mature design and product organizations. It doesn’t have a consensus title yet, and in most orgs, it doesn’t exist at all. Many don’t even know they need it.

What the role is not

It’s not a prompt engineer. It’s not an AI evangelist. It’s not a design technologist in the traditional sense, and it’s not a product manager for your AI tooling budget. Those roles exist and they matter — but they’re not this.

What the role actually is

The role’s primary responsibility is managing organizational AI adoption infrastructure — ensuring that knowledge compounds across teams rather than concentrating among early adopters. It sits at the intersection of DesignOps, systems-level organizational thinking, change management, and technical depth (without requiring engineering-level skills).

AI doesn’t speed up decision-making. Decision-making is still the bottleneck. This role builds the systems that distribute AI leverage equitably across the org so that the bottleneck doesn’t also become a single point of failure.

Building that infrastructure calls for a specific mix of skills

    • Deep familiarity with design practice
    • Systems-level organizational thinking
    • Change management expertise
    • Technical depth (not engineering-level, but fluent)
    • Accumulated judgment and pattern recognition

The 5th dimension: A foundation of judgment

The first four are table stakes. The fifth — judgment — is what separates someone who can describe this role from someone who can actually do it. It’s the ability to read an organization’s readiness, sequence interventions correctly, and know when to push and when to wait. It accrues slowly, can’t be hired in from scratch, and is what makes this role genuinely hard to fill.

Where the role is “beaming in” right now

It’s appearing most visibly inside organizations that have already built mature DesignOps functions. Those teams have the operational muscle memory. They know how to run programs, own shared infrastructure, and manage change at scale. The AI layer is new; the organizational pattern is not.

It’s also showing up in product orgs — particularly in companies where product operations has developed enough structural maturity to absorb a new domain.

Why it doesn’t yet exist

Because most organizations are still in the tool-buying phase. Leadership approves the budget. Individuals experiment. Ninety days later there are a dozen parallel workflows that don’t talk to each other, and one or two enthusiasts burning out trying to carry everyone else toward the goal post.

Nobody paused to ask: who owns the system?

What to do if you’re building a design or product org right now

    1. Audit honestly. Map who’s using AI tools, how, and what’s been shared beyond their immediate team. The gaps will be obvious.
    2. Assign ownership. Not enthusiast ownership — organizational ownership. Someone with design knowledge, organizational authority, and an operational orientation.
    3. Start with vocabulary. Shared vocabulary is what makes it possible for a new hire to be productive in weeks instead of months. It’s the cheapest, highest-leverage infrastructure investment you can make before building anything else.

The organizations that recognize this structural gap early will have a compounding advantage over those waiting for the formal job title to arrive before they act.

The role is forming. The question is whether it forms intentionally inside your org, or by accident.

Originally published on LinkedIn on June 2, 2026.

This Isn’t Even a Unicorn Role. It’s Just Gibberish.

As a usability professional, the struggle with recruitment communications is real. I want to share some requirements from a recent UX job “description” — in quotes because it’s more of a laundry list of hopes and dreams than a coherent role definition.

Preface

Before I get into it – many items here are better suited for dedicated roles, or too broad for any single UX hire regardless of seniority. Some items are just… odd.

Here’s what this posting actually asked for

    • Establish the company’s technical vision — lead all aspects of the company’s technological development
    • Direct the company’s strategic direction, development and future growth
    • Do workshops internally and with customers
    • Conduct technological analyses and research
    • Open up new whitespaces for us
    • Help in pivoting our image from being an “executor” of designs to a “design & strategic” partner
    • Management of sales process and product delivery
    • Experience in overall transformation of Front/Back end systems for digitization
    • Experience in Mobile First Methodology to ensure internal systems are supported on all devices
    • Expert skills on Project management
    • QA/Test experience
    • PR/marketing experience

Breaking it down

CTO/VP Engineering territory: establish tech vision, lead technological development, direct strategic direction and future growth.

Niche or dedicated role territory: PR/marketing, sales process management, product delivery, project management, QA/Test.

Genuinely odd: “Open up new whitespaces for us.” I’ve been in this field a long time. I still don’t know what action I’m supposed to take on day one to accomplish that.

My Analysis

This isn’t a unicorn role. A unicorn role is a real job that asks for a rare combination of skills. This is a job description written by a committee that never stopped to ask: what does this person actually do on Tuesday morning?

Every touchpoint in your recruitment process is a signal about your organization. A job description this incoherent tells strong candidates — the ones with options — exactly what working there might feel like. They read it and move on.

If you’re writing a job description right now: start with what the person will own. Then what they’ll influence. Then what experience makes someone good at those specific things. That’s a job description. Everything else is a wishlist.

Originally shared on LinkedIn.

It’s Users All The Way Down

Sometimes in the process of defining your users, you’ll discover that, much like turtles, there are layers upon layers of them just waiting for their stories to be told.

Background

Joining a company late in 2014 as their new UX professional (and founding member of a growing team) has been an eye opening experience. Not only have I been able to finally practice what I’ve been preaching and learning the last few years, but I’ve been exposed to the healthcare industry – which is entirely new to me. Tons to learn = tons of fun.

Anyone in experience design must carefully consider their users’ goals, circumstances, capabilities and habits. This is one way for us to get out of our own heads and as far into our users’ heads as possible – avoiding the trap of designing for the users we’re most familiar with: ourselves.

Identify the users we’re serving is a great place to start. This sounds simple and it can be – but it can also be a complex puzzle (with all the edge pieces hiding and the corner pieces eaten by your dog.)

What my company does

At a high level, we provide a secure and efficient communication platform for the healthcare industry. The platform helps patients, practice staff and hospital staff efficiently contact physicians.

The problems we solve:

  1. handling the bazillion ways that physicians within a hospital or practice setting need to be contacted depending on situational context.
  2. sending information to a physician in a way that is secure and does not violate laws around the privacy of protected healthcare information (PHI).
  3. maintaining a fine balance between the needs for privacy and accessibility on the part of the physician.

Who are our users?

User (Turtle) #1: Our external users

This group includes doctors, nurses, acute care staff and hospital / practice management. They’re the obvious answer to the ‘who is our user’ question – the system was designed to meet their needs and everything revolves around maintaining and enhancing the capabilities that our platform extends to them.

If we push out a buggy feature or misjudge the utility of an enhancement and sacrifice something more vital, these are the people who feel it the most. We should be in close contact with representative members of this group, testing things out and gathering feedback constantly. This group will (and should!) receive the highest prioritization when it comes to evaluating features, to doing user research and to planning and executing usability testing. That said, don’t stop here!

User (Turtle) #2: Patients

Our healthcare professionals are themselves serving another group of users: their patients at member hospitals and practices across the country. These are the folks that our external users are under oath to care for, and who they went to school for a dozen years to serve.

This is the group who pays the price for inefficient communication practices. It’s the folks who have seen their premiums and deductibles climb year after year and who in too many cases don’t have insurance at all. They pay dearly for any healthcare they receive. This is you and me, when we visit our family doctor or when we land in the emergency room after falling off the roof in an ill-advised attempt to save money on chimney repair.

While we can’t prioritize designing for this group over the others, we should always consider the impact of our decisions on these people.

User (Turtle)#3: Internal Users

We have another group of users not immediately obvious to the naked eye: our internal users. These are the folks that use a suite of applications to onboard new external users and that support their needs on a 24/7 basis, 365 days a year.

They don’t use the exact same set of tools as our external customers, but they’re touching the same data and hitting the same systems. Their needs are also much more diverse since they service every type of external user and must become experts in the task flows for those users. This is no small feat, as the training required for these folks to become proficient runs from a full week to a staggering 3 months.

When considering the needs of this user group, striving to avoid introducing further complexity is a big priority. Beyond that, a large part of your backlog might revolve around taking steps to reduce that complexity even further (and therefore lighten the cognitive load of using the system).

If you’re in this situation, your company’s bottom line could be affected nearly as much by internal facing changes as it is by changes that affect your external users.

User (Turtle) #4: Executive Team

You’d think we had all the bases covered, but there’s actually one more group of users to touch on. Let’s call it the owner/executive team, made up of company ownership and senior leadership in both your external users’ companies and your own organization.

The goals and tasks of this group tend to be pretty straightforward, and sometimes seem pretty far removed from what the other three groups of users are concerned with. That said, while I don’t recommend placing too much weight on designing for this group, I do believe it’s a mistake not to consider their needs. Pulling off a win-win effort that enables this group to hit their goals tends to be a self-reinforcing success for a company.

Wrap Up

If you only take one thing from this article, know that accommodating anything less than every group of users in your designs is a Bad Thing.

Imagine that your executive team has seen the effect that your team’s UX design and development work has had on the bottom line – and so they foster a culture that values and encourages such efforts on an ongoing basis. This belief is folded into the company’s core values, and soon the sales, support and product development teams are all on the same page.

Your external users consistently see improvements, enjoy using your product and feel that their feedback is valued and acted upon. Inevitably these happy professionals pass those benefits on to their own customers . For our patients user group that manifested through cost savings, less time in the waiting room or waiting on a surgery date, and better quality of care.

Your internal users don’t have to jump through hoops to support the customers since the support tools they have been given are performant, intuitive and easy to use.

Wouldn’t that be a beautiful place to work? Are you ready to make it happen?