You Can’t Skip Steps. You Can Only See the Next One.

I was sixteen, maybe seventeen, working the shipping operation for a small publishing house. My job was simple: box the books, run the postage, get the orders out. The books were about process improvement and quality control — dense, technical stuff aimed at engineers and operations managers I’d never met and couldn’t have imagined.

In the downtime between orders, I taught myself to juggle, and I started reading the books almost immediately. Out of curiosity, and a restlessness I didn’t yet have a name for.

But somewhere between the shipping manifests and the packing tape, I absorbed a way of thinking about systems, variation, and process that I had no professional vocabulary for yet — and wouldn’t for years.

I wasn’t actively learning about process control. I was just in the room with books about stuff, right? That distinction turns out to matter more than I understood at the time.


There’s a concept in complexity theory called the adjacent possible. Stuart Kauffman introduced it to describe the boundary of what can come next in biological evolution — not all futures are accessible from a given state, only the ones one step away. Steven Johnson later applied it to innovation: you can’t leap to arbitrary ideas; you can only reach ideas that neighbor your current knowledge and experience.

I didn’t encounter this framework until long after I’d already lived it several times over. When I did, it named something I’d been carrying without language.

That’s the thing about the adjacent possible. From my experience and in the patterns I’ve observed across organizations, you rarely recognize you’re moving into it in real time. You’re just following the problem, the curiosity, the need. The new territory only becomes visible in retrospect.

Most Organizations Try To Leap

Most organizations approach AI adoption the way people approach career planning before they’ve lived enough to know better: they try to leap.

The pattern is familiar enough to be a cliché, but familiarity hasn’t made it less common. Leadership identifies the destination — “we’re getting AI” — and announces it org-wide, often with namedropped companies and models, and almost always paired with vague assurances that this won’t result in layoffs. Then comes the silence. Eventually, links appear, and maybe some basic instructions. Rarely anything that draws a clear line between existing strategy, the gaps AI is meant to address, and how the workforce is actually supposed to use the tools toward that end.

What happens next is predictable. The futurists and early adopters — the people who are curious and adaptive by nature — will engage. They’ll explore, experiment, build local workflows. But their work won’t be aligned or focused, because no one told them what problem they’re solving for the organization. Everyone else pokes at the tool with a stick, gets nothing useful back, and walks away. Adoption flatlines. Leadership concludes the tools weren’t as useful as advertised.

The tools were fine. It’s that steps were skipped.


Don’t Skip Steps

You can’t adopt an AI-native workflow if your team doesn’t share a vocabulary for how AI systems work. You can’t build that vocabulary if people don’t feel safe admitting what they don’t know. You can’t build that safety if leadership is signaling — through rushed timelines, vague reassurances, and the absence of any real curriculum — that uncertainty is a problem to be hidden rather than a condition to be managed.

Each step is only accessible from the one before it. Skipping them doesn’t accelerate the journey. It just means you’ll retrace them later, at higher cost, after something has already broken.

The organizations that move differently do something structurally simple but operationally demanding: they communicate a phased plan that connects strategy to tooling, provides a curriculum that serves every level of expertise and every function, and gives people immediate next steps they can take today. The longer arc includes touchpoints — moments to come together, review what’s been learned, and focus further with more clarity on goals. The plan evolves as the org learns.

The result isn’t that everyone becomes an AI power user overnight. It’s that everyone understands where this is going, how it connects to their work, and what their next step is. Everyone comes along for the ride — or at minimum, knows enough to make an informed decision about how they engage with it.

That’s not a technology problem. That’s an instructional design problem. And it’s solvable.


Closing The Gap Deliberately

Knowing the adjacent possible exists is half the work. The other half is building the bridge to it.

This is where instructional design enters — not as a corporate training concept, but as a discipline for closing the gap between where people are and where they need to be. The best practitioners of it start not with curriculum but with analysis: what does current capability actually look like, what does the next state require, and what specifically stands between the two?

That gap is the unit of work. Not “we need to learn AI” but “our teams can’t evaluate model output because they have no shared criteria for what good looks like.” Instead of the old trope “designers need to code,” the better lens is “designers need enough systems literacy to have a productive conversation with an engineer about tradeoffs.”

In a healthcare UX org, that analysis might produce a capability map showing that clinical researchers can evaluate AI-generated synthesis but lack the vocabulary to specify what they need from a model — which points to the first curriculum artifact being not an AI tools tutorial, but a shared glossary.

The adjacent possible tells you where you’re going. Instructional design tells you how to get there without skipping the steps that make arrival possible.

Organizations that combine both — that map the next achievable state and build deliberate learning infrastructure to reach it — don’t just identify the gap. They close it on purpose, with a plan the whole org can see and follow.


How I Know This Is True

I was trained as a designer — classically, at art school — and somewhere in my first decade of professional work I drifted into engineering. Not because I planned to. Because the problems I was solving kept pulling me one step further into territory I didn’t have a name for yet.

Design gave me the vocabulary for how things should feel and function from a human perspective. Engineering gave me the vocabulary for why things behave the way they do at a system level. Neither one was a leap. Each one was adjacent to where I already stood.

In college, for gas and grocery money, I took a job caring for three disabled adults in their home. Long shifts — sometimes a full weekend, 24 to 48 hours at a stretch. It was unglamorous work in the way that most essential work is unglamorous.

Caring for someone who is wholly dependent on you — for meals, mobility, dignity — compresses your awareness in a specific way. You stop taking your own capability for granted. You develop a constant low-level inventory of what you have, what they need, and what the gap is. Not as a burden, but as a discipline. A practice of noticing.

The adjacent possible of that work wasn’t a job skill. It was an orientation — a habit of accounting for the advantages you’re operating with instead of moving through the world blind to them. Gratitude, yes, but the kind that makes you more capable: functional, not decorative.

Neither transition was planned. Both were adjacent to where I already stood.


What This Has To Do With You

If you’re navigating a career transition, a role change, or an org-wide transformation right now — and in 2026, most people in design and technology are doing at least one of those things — the adjacent possible is a more useful frame than almost anything else I know.

The question isn’t: where do I want to end up? The question is: what is genuinely one step away from where I am right now? What capability, relationship, or context sits just at the edge of my current reach?

That’s the step worth taking. Not because ambition is wrong, but because the steps you skip have a way of showing up later as gaps you can’t explain.

I spent time as a teenager running the shipping operation for a small publishing house — boxing and sending out books about process improvement and quality control before I had any professional context for what those books contained. I spent weekends in college learning what it means to be responsible for someone else’s wellbeing, happiness, and safety. I moved from design into engineering without a plan to do so.

None of it was linear. All of it was adjacent.


Originally published on LinkedIn on May 11, 2026.

Design Operations & Shiny New Tools

Your AI tools are ready. Your design org isn’t.

Design organizations have adopted a remarkable number of tools in a short window — Figma, FigJam, DevMode, and now AI layers on top of all of it. The tools work. That’s not the problem.

The problem is that nobody owns what happens next.

AI adoption isn’t a tools problem. It’s an ops problem.

There’s a pattern I keep seeing: leadership approves the budget, individuals start experimenting, and within 90 days the org has fragmented into a dozen parallel workflows that don’t talk to each other. One or two enthusiasts are burning out trying to carry everyone else toward the goal post. Everyone else is either quietly falling behind or quietly waiting to be shown the way.

This isn’t an AI-specific failure. It’s the same challenge DesignOps has always addressed — just with a new surface area and a much shorter adoption curve compressing the timeline.

What “ready” actually requires

Sustainable AI adoption happens across three layers:

    • Layer 1: The Tool — where nearly all budget concentrates. The licenses, the subscriptions, the pilots.
    • Layer 2: The Workflow — how the tools actually integrate with how people work day to day.
    • Layer 3: The System — the infrastructure for capturing what works, sharing it, governing it, and iterating on it over time.

Most organizations invest heavily in Layer 1, lightly in Layer 2, and do nothing about Layer 3. Then they wonder why adoption stalls six months after launch.

The shared vocabulary problem

One of the earliest symptoms of missing infrastructure is vocabulary fragmentation. Teams develop local language for the same concepts. New hires have no map. Knowledge stays locked in individual heads — and leaves the org entirely when those people move on.

Shared vocabulary is what makes it possible for a new hire to be productive in 15–30 days instead of six months. It’s not glamorous work. It doesn’t make the demo reel. But it’s the foundation everything else is built on, and it’s the cheapest, highest-leverage investment you can make before building any other system.

The governance gap nobody wants to talk about

AI tools introduce new questions that most design orgs haven’t formally answered yet: What’s confidential? What’s a quality standard for AI-assisted work? Who gets attribution? What are we not using these tools for, and why?

Without explicit answers — in writing, owned by someone — teams will answer these questions differently. And inconsistency at that level compounds fast.

DesignOps is the function that builds the guardrails

I’ve started calling the accumulated risk of inadequate adoption practice AI Adoption Debt. Like technical debt, it’s not visible until it’s expensive. Unlike technical debt, most orgs don’t even have a name for it yet — which means they’re not tracking it, not measuring it, and not paying it down.

DesignOps is the function positioned to own this work. Not because it’s glamorous — it isn’t — but because DesignOps already owns the operational infrastructure of the design org. AI adoption is just the newest domain in that scope.

Who owns this?

Right now, in most organizations: nobody. The enthusiasts do their best. The stragglers fall further behind. Leadership looks at tool adoption metrics and sees green.

What’s needed is an explicit owner — someone with design knowledge, organizational authority, and an operational orientation. Not the most excited person. The most equipped person.

Three concrete starting points for org and design leaders

    1. Audit your current AI adoption honestly. Where is it happening? By whom? What’s been shared beyond the team that built it? The gaps will be obvious once you look.
    2. Assign ownership thoughtfully and explicitly. Enthusiast ownership is not organizational ownership. This work needs someone with the authority to set standards and the skill to build systems.
    3. Start with vocabulary before building systems. A shared glossary is not a small thing. It’s the connective tissue that makes everything else transferable.

The tools are ready

They’ve been ready. The question was never whether the tools would work. The question is whether your organization is built to absorb what they make possible — and whether you’re willing to do the unglamorous ops work that separates sustainable adoption from AI Adoption Debt.


Originally published on LinkedIn on May 5, 2026.

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?

Design Constraints Are Awesome

While reading some material recently I was particularly struck by a correlation between the sentiment of “designing for monochrome first” (for color deficient users) and the design movement termed “Mobile First”.

In both cases, the designer aims to build their interface elements such that the largest % possible of users will have accessibility to the data, based on the real and perceived limitations of the environmental factors imposed. After baseline accessibility and usability you can worry about nuances and aesthetics.

Monochromatic vision strips the designer of color-based tools and techniques, forcing you to fallback to the use of shape, contour, contrast and pattern. The Mobile First design sensibility forces the designer to carefully prioritize what elements of the design are truly needed to accomplish the goal(s) of the product, framed within the limits imposed by a smaller display. You also have to consider the contextual differences in usage between a mobile device and a desktop computer, and within the vastly different feature sets of modern devices.

I often hear about project constraints in terms of drawbacks, of obstacles to building the perfect widget. It’s much more helpful to think of constraints as helpful wayfinding elements on the road to successful project definition. If you know what they are, you won’t waste time in rabbit holes and you’ll be able to focus your time and attention on crafting the best product possible – one that will meet the unique needs of your users, whether or not they can see colors and regardless of what they’re using to access your offerings.

Notes from GiantConf 2014′s “Embracing the Suck” presentation by Chris Harrison

In his presentation on day one of GiantConf 2014, Chris Harrison talked to us about “Embracing the Suck”. Here are my notes from his talk.

Chris Harrison – Embracing the Suck – 10:45a Thursday, June 12

@cdharrison
cdharrison.com

Embracing the Suck: Military phrase meaning to make the best of whatever situation you’re in..

Background:
– Weight loss – 529 to 377
– weight gain due to being depressed, hating what he did, etc.
– Making sites since 1996.
– Former fulltime freelancer
– now: frontend dev for Morris Communications (magazine division)

2013 state of the workplace
30% engaged and inspired
18% actively Disengaged – sabotage their coworkers (cost 450-550 million a year)
52% permanent case of the mondays – do just enough not to get fired

Sometimes you just gotta suck it up.
– Consider the alternative – it could be worse.

– dan willis, “great takes work”
– choose your battles and spend your energy wisely

Negativity is a cancer! (this could be a talk topic!)

Sometimes complaining takes more effort than just getting things done.

Don’t fear new. New = opportunity. (he was told he’d be doing all joomla and drupal work. This was not happy news)
– learn on the companie’s dime
– doubtful he could have learned this stuff as a freelancer (no time/money in it)

Everything you do is a learning process for everything.

– thomas edison’s quote about opportunity and how it looks like work.
– fabio at mailchimp, lead html email designer. was hired to do ui/ux, but they approached him to do HTML emails.
– we know as an industry that html emails suck.
– when he heard this, he embraced the challenge.
– 5 years later he’s an innovator in a field where it was thought there was no room for innovation left.

Opportunity opens doors…

Help your team…
– concept of jumping on hand grenades (someday you’ll need help from the person you help today)

Small wins are still wins. (make it something awesome despite the scope)

Make learning a priority
– learning about sass etc and givng talks about it.
– things suck less when you share what you know with your coworkers
– codeschool etc. as good options for continued learning.

“Sneak” new technology/techniques into projects, but strive to get buy-in from your coworkers (if not management)
– Demonstrate the benefits of incorporating these new techs into an existing workflow

Find creative outlets
– draw more.
– starting doing illustrator avatars for friends
– take pictures! (vader, ninja turtles)
– lilvaderadventures tubmler

Scratch your own itch – side projects rock
– itembrowser.com – his first responsive project
– learned media queries, etc.

Start using your powers for good
– jingle jam (10k) benefiting safeHOMES charity
– design + development + marketing
– someone could really use your talents!

Happiness depends on ourselves – aristotle
Even sucky work can make you happy. Give it a chance.