Who Funds the Learner?

The Vanishing Entry Level

Empress of Balance – Colored Pencil – Richard Lee (2012)

New Stanford/ADP dashboard data shows entry-level roles contracting 3.8% per year in AI-exposed occupations, while older cohorts (35-50) hold steady. 

Once upon a time, junior designers earned their stripes on the slow and steady path. Depending on their date of entry, that might have been designing websites that didn’t convert, or building flows that confused users. Then they were shown how performance metrics suffered, or they sat behind the glass during usability testing while a senior designer traced the confusion back to decisions the fledgling designer made three sprints earlier.

Junior developers earned it in similar fashion. Maybe it was an accidental reveal of not-ready-for-release site content, or perhaps a 2 a.m. troubleshooting session that traced a production breakdown back to their front-end framework implementation choices. Different rooms, but the same mechanism. The lessons we learned before AI was on the scene? They cost us something, yes.   But it’s that sting that made them stick, and with enough mistakes under our belt and the learning that lies therein, we develop judgment. 

Of course, precisely how that pipeline was configured was never sacred. Just familiar and commonplace. You might even go so far as to call it common sense. 

Calculators erased the requirement to do math in one’s head. Digital layout tools led to no more hand lettering.  CAD erased the bottleneck of hand drafting.

Each time these changes landed on our doorstep, a chorus of practitioners insisted the new abstraction layer would produce generations that couldn’t really do the work, and could only operate the machines that were doing the work. But each time, judgment reconstituted itself one layer up. The “entry-level pipeline” was never a fixed pathway, it’s always been whatever the current domain, team and process kept at the bottom rung.

Why is this time different? I believe that AI advancements and adoption are so visible and widespread, this time we can watch the abstraction layer shifting around. We’ll either see the pipeline reform or see it fade away completely.  We’ll see it clearly in the data, which no one’s arguing we have more of than say, when calculators first rolled out. 

The Fork In the Data

In August 2025, a Stanford Digital Economy Lab team led by Erik Brynjolfsson published a finding that has since grown into a live-time dashboard built with ADP Research, covering roughly 4.6 million workers across more than 730 occupations.

The data’s headline is that employment for AI-exposed workers ages 22 to 25 is contracting at roughly 3.8% per year as of the most recent data, and that the decline has accelerated since the first year of measurement. Workers 35 to 40 in the same occupations are growing at about 2% annually. The squeeze reaches past new grads, as well. The 31-to-34 cohort is down about 1.7% year over year. 

Across all workers, at any age, in any domain and context, AI-exposed occupations are down just 0.2%. Generally, jobs are holding on.

Within the same firm, entry-level hiring in the most AI-exposed roles fell about 13% relative to less-exposed roles. 

It’s the On-Ramp That’s Collapsing

The Fortune piece covering the dashboard put it plainly: AI “absorbs tasks before it absorbs jobs.” It reaches first for retrieving, summarizing, scheduling, formatting. The tasks junior people have always been handed, because those tasks never required years in the seat. 

It’s worth noting that the Stanford team thankfully ran some controls on the research, taking interest rates, pandemic overhiring corrections, and the pervading sense of global despair mostly off the table as competing explanations for this collapse of the entry level pipeline.

ADP’s chief economist, Nela Richardson, points at the operative variable: whether an organization deploys AI primarily as automation or as augmentation. Occupations where AI is brought in and augments human work show durable employment growth. Occupations where AI is introduced and automates tasks outright? Those are shrinking. 

Same Tech, Very Different Outcome

The difference lives in an organization’s collective mindset and in the decisions that company’s leadership makes across several factors (talent training & retention, AI deployment and the usual build/rent/buy decisions). These decisions typically roll out without the “talent strategy” label, though that’s where it appears things are headed. 

Hold that thought, because it’s the crux of everything that follows. Why? Because supervising AI output requires exactly the judgment we are quietly ceasing to train when AI is deployed primarily to automate entry level work vs augmenting those occupations in a sustainable fashion.

A Strong Counterargument

I want to hand over the mic for an optimistic read on this debate, because I believe it has strengths, and a potentially viable path forward. 

A principal designer I respect at a mid-size HR-tech company pushed back on an earlier piece of mine, one arguing that AI adoption orchestration is becoming a dedicated role. Her stance on the ‘emerging role’ question, in her own words: 

“I’m not entirely convinced this is a dedicated role. If the company creates a culture of knowledge sharing, it’s a great way to surface workflows that may benefit others… I think each person should be empowered to build what works for them specifically, share when appropriate, and adopt builds from others if useful.” 

Her org runs on that model today. A dedicated channel, with people sharing AI workflows and skills proactively. No gatekeepers required. Having spent time in the very culture and org this approach is working in, I wasn’t surprised to hear it appeared to be effective in mitigating some of the worst aspects of AI Onboarding Debt.

But beyond a thoughtful, transparent culture where folks share with intention and strategy,  there’s an even stronger case to be made for saving the entry-level judgment pipeline itself.

Judgment Comes from Decision Cycles, Not Keystrokes

The grunt work (design critiques, code reviews, support ticket triage) was never the point. Rather, it’s been the fee those early in their career had to pay to move up, to take on more responsibility and be given more power.

If AI waives that fee, a junior designer who once would have owned five flows across two years can now learn fifty lessons vs. five. They see dozens of cycles go from project to shipped to results in the same span of time. A junior developer sees the same shift, from five branches full of hard-won wisdom to fifty shipped-and-broken cycles. More repetitions, not fewer.

The traditional pipeline wasn’t the most ideal filter in the first place. It selected for who could (and was willing to) endure years of low-leverage work, and for who had the pedigree to get hired into the pipeline at all. Neither is a great predictor of judgment.

The Fork Itself Is an Optimist’s Best Evidence

The Stanford/ADP finding doesn’t say “AI destroys entry-level work, full stop”. It says entry-level work contracts where AI is deployed as automation, vs how entry-level work holds on just fine where AI gets rolled out as augmentation. That’s proof that a viable, extensible path is live right now, and visible in the same data-driven dashboard. An org that deliberately pairs their junior staff with AI as a force multiplier (versus cutting staff and trusting that shiny new agent) is running the augmentation condition, even if they don’t frame it that way.

Where the Counter Doesn’t Hold Up

The verification bootstrap

Today’s design and development veterans catch bad AI-generated decisions because they made enough bad decisions of their own to spot them before they cascade. The next cohort will inherit that verification mantle, but sans the specific quality of cycles that make recognition possible for those who’ve been around the block a few times. Those fifty watched cycles,  blissfully absent of grunt-work and guaranteed sting-free? They don’t have the same stressors, and don’t dish out the pain that spurs judgment the way that five lived-cycles do, at least not in most domains.

A newbie pilot’s required flight-simulation hours compile into judgment because the feedback is fast and unambiguous. Either the plane crashed or it didn’t.  

Design work rarely offers that, and neither does most engineering above the unit-test level. When a junior designer’s flow gets shipped and the confusion it causes surfaces as a slow bleed in adoption metrics three quarters later, attribution is hard because it’s tangled with someone else’s redesign and a rebrand marketing swore was crucial for their Q4 goals. A junior dev’s architecture calls look fine until it’s load-bearing under features they hadn’t scoped and didn’t have the experience to proactively account for.   

Delayed, diffuse, and hard-to-attribute feedback doesn’t write to long-term judgment the same way a simulated stall warning does for that newbie pilot in training.

What the Data Reveals About Choice

Even if we grant the augmentation model everything it appears to offer, that path still has to be chosen.  The ADP Research dashboard is the record of what’s actually being chosen at scale: role contraction is concentrated in the same place as automation-mode AI deployment, with the net effect growing month over month by roughly half a percentage point. 

It’s not a data artifact, it’s the result of deployment decisions by thousands of firms, made mostly by default. A junior IC navigating cycles with judgment-producing stressors (the  augmentation model)  built in is a cost center without a plainly visible, near-term payoff. 

Nobody is budgeting for the learner, and four years of data have revealed the preference for the vast majority: nobody is about to.

Even If Augmentation Wins, There’s a Cost

Say augmentation wins outright and judgment keeps forming. It’s still worth naming what that victory actually costs, because the maturation process isn’t instant.

The advancement of digital layout tools produced designers whose judgment formed differently, yes. However, it formed no less rigorously than those who did hand lettering and used rubylith.  It also resulted in a period where the in-between cohort absorbed the digital disruption, without a playbook and with a dual learning-and-practice load. They carried both digital and analog knowledge and techniques, without any extra for the trouble. 

The 2023–2030 workplace entrants are in that awkward phase right now, whether you fall on the pessimistic or optimistic side of this topic.  And while I don’t have a confident estimate for how long this phase will run,  5-7 years would be my guess based on prior precedents and the degree to which AI seems to confound precedent entirely.

The Category Error

Here’s where the real question and the designer’s sharpest observation come together. Her sharpest observation wasn’t the culture argument, but a question she raised in passing about the hard part of AI deployment and adoption. 

“The socialization, governance & trust that comes along with it… whose responsibility is it?”

Organic knowledge-sharing culture solves for process and tooling diffusion. In an org doing things right, relevant and effective workflows built by one person quickly reach the rest of the org, even without a dedicated role driving that outcome. That’s a real problem, a real source of pain I’ve had several seniors convey to me, and one that the model her org practices addresses well.

That said, formation of judgment is a different problem wearing similar clothes. A shared channel of AI workflows may tell a junior how to build something, or perhaps even what to build. 

But it doesn’t put them through the cycle of thinking, building and shipping, then watching the consequences land. It doesn’t knock them down, make them wince and then clamber up and step back to the drawing board. 

We need to find new ways of building in the reps the verification bootstrap shows us are nonnegotiable. While conscious diffusion can move artifacts between people who already have judgment, it doesn’t manufacture judgment in people who don’t yet have it. An org can run a flawless sharing culture and still have zero judgment formation happening underneath it. 

In this scenario the collapse just happens quietly, even inside companies with excellent knowledge sharing. A few years on, there won’t be any juniors capable of exercising judgment and independently making calls that require it.

I’m not claiming my designer friend’s model is wrong, and it answers the diffusion question well. But her own “whose responsibility is it?” still sits on the stack one layer down, where the artifacts stop and the judgment has to kick in.

Who funds the learner

If the fork is real, and the data says it is, simply naming your org’s AI deployment strategy as “augmentative” doesn’t mean the judgment-formation pathway will build itself, even inside the best sharing cultures in the industry. Someone has to figure out what a junior must do across those fifty watched cycles so that watching turns into judgment.

The apprenticeship cannot consist solely of watching fifty data points of exposure. There must be real stakes. There have to be consequences a junior human gets to feel, and real accountability for catching what the AI gets wrong. 

Someone has to build the structured apprenticeship interlaced with using AI to speed up and automate what doesn’t contribute to building judgment. That’s a role missing from most headcount plans, and the revealed-preference data says it’s losing the budget argument every quarter the dashboard reports.

So the age-old mechanism survives: entry-level to senior decision maker. Judgment can still form on the far side of this AI transition, the same way it formed on the far side of every transition before it. But it won’t form by default, and the question every org is answering right now, whether by strategy or by default, is the one this piece can’t answer for them: 

Who funds the learner?

UX Had to Beg. AI Didn’t Even Knock

A Long, Long Time Ago

It’s 2013 in beautiful Knoxville, Tennessee and I’ve just been hired by a healthcare software company to build up a UX design team. The focus? Physician-facing and care team facing  applications and workflows. The kind of context where deep knowledge of how clinical users actually think and work isn’t a nice-to-have, it’s a requirement. 

Except that’s not quite what happened. Over the following months, through a series of smaller decisions and quieter conversations, the picture changed. The team never materialized and the role drifted. What they actually needed, it turned out, was someone to evaluate vendors and manage design relationships. An art director, something I had done before, pretty extensively. And yet…

The contextual knowledge that healthcare UX requires, the kind you build through research and iteration and repeated proximity to actual users? It got treated as a secondary consideration. Engineering was the center of gravity. Design just orbited it. I trained my replacement and left exactly one year after I started.

Two years later

At Siemens Healthineers, I’m sitting across from an engineering manager who has politely but clearly already decided this meeting is a formality.

We’re talking about PET scanner workflow software. The screens that a nuclear medicine technician uses to dial in radiation sensitivity, read radiological event data and confirm what’s been captured and what’s still pending. Heady stuff. 

The screens are all in black and white. Dense gray scale without much visual hierarchy. No color cues and no summary of present state. Just numbers and toggles that the technicians had been memorizing for years, because the alternative was slower.

I had some questions, and with tech constraints onboarded, I soon had upgrade proposals:  better resolution, colors to encode and depict radiation sensitivity ranges, a progress summary surfaced where it was actually needed and changes that would reduce the cognitive load in workflows where errors had real consequences.

The engineering manager looked at the mockups, and then at me, then back again at the mockups. “We’ll think about it,” he said.   That quarter, I ate a lot of catered lunches at my own brown bag events talking to engineers, clinicians and physicians as well as product managers, sales and marketing. 

Doing Reps – UX Adoption

Here’s what UX adoption actually looked like in that era, from the inside. 


Perhaps you were in a new practice trying to earn a seat at a table that had been set without you. Engineers and executives didn’t dismiss UX because they had evaluated it and found it wanting, but because it looked decorative. Soft and touchy-feely. The frou-frou department, one executive at another company once called us. (I’m not making that up.)

The resistance lived at the top and in the middle and the people with institutional authority were the skeptics. Which meant that one of the most promising paths forward was bottom-up proof. 

Meaning what? Patient, persistent and high-quality work that kept raising the bar. Usability testing session videos where engineers sat and watched real users struggle with interfaces they had built. HCI fundamentals explained in terms of sensory memory and visual processing, in the language of people who thought in systems. Brown bag lunches and hallway conversations. Prototypes that were better than anything anyone had seen before from a design function.

One full quarter of pursuing this at Siemens Healthineers and then…Then a YES.

Two companies, two shapes

They both circled the same problem: UX climbing uphill against institutional skepticism, converting the powerful through evidence they couldn’t easily dismiss.

There’s a documented failure mode worth naming here, one which Debbie Levitt wrote about in 2022 in UX Magazine: UX practitioners who responded to that skepticism by democratizing their work, running design sprints and workshops that invited everyone to “do UX,” inadvertently taught organizations that UX was something anyone could do. The tactics designed to build buy-in ended up hollowing out the credibility they were meant to establish. 

The ones who navigated it well held the line on expertise while still opening the door. Proof positive rather than participatory theater.

AI arrived differently

It didn’t send a calendar invite. It didn’t ask for a pilot program. The budget showed up first, and then the mandate. Then the all-hands where leadership explained that we were going to be an AI-forward organization, effective immediately, and wasn’t that exciting?

The resistance to this new influence flipped from technical and leadership to creatives and engineers in the trenches. 

We’re talking Design and Development, the people closest to the craft. Everyday users who had been handed tools they didn’t ask for and told to use them. These are the skeptics now. Not the executives, and not much engineering leadership. The people with institutional authority are already sold while the unconvinced are the practitioners.

Same adoption problem, with an opposing polarity.  So what does that reticence actually look like up close? Some of it is displacement anxiety, which is real and reasonable. Some of it is quality concern, also real. Some of it is ethical unease about training data, authorship, environmental cost. Some of it is something harder to name: the feeling that something is being done TO you rather than WITH you. That the conversation started without you and ended before you arrived. That last one sucks, doesn’t it?

Resistance Vectors

Here’s what I keep returning to… That the tactics that worked in 2013 were designed for a specific direction of resistance.

Brown bag lunches work when the VP needs convincing. They don’t work when the VP is already sold and your creative director is the holdout. You can’t mandate your way to bottom-up trust. And you can’t run a workshop that teaches skeptical practitioners that “AI is good, actually” without recreating the exact failure mode Levitt described. You’d be running AI evangelism theater, basically going through motions that signal organizational enthusiasm while building neither genuine capability nor genuine confidence in the people you most need to reach.

So what does the reverse playbook look like? I don’t think we have a settled answer yet, but some hypotheses are worth examining.

Proof by invitation, not assignment. Let skeptics choose their own first use cases rather than handing them one. The brown bag that worked at Siemens wasn’t mandatory. It was catered, which is different. People showed up because they wanted to, and left having seen something they hadn’t expected.

Honest failure visibility. Show where AI breaks, not just where it succeeds. Calibrated trust is more durable than converted enthusiasm. The usability testing videos that moved engineers at Siemens weren’t highlight reels. They were uncomfortable to watch, and that was a big part of the point.

Craft preservation framing over craft replacement framing. What does AI protect practitioners from, rather than what does it take? That reframe isn’t just spin, and more often than not it’s a more accurate description of what’s happening in the workflows where AI is genuinely working well.

Peer signal over executive signal. Who in the skeptic community is actually using these tools well, and are they visible? In 2015, the practitioner who moved me forward with engineering management wasn’t the VP. It was a senior engineer who had sat through a usability session and couldn’t stop talking about it afterward. Credibility traveled laterally before it traveled up.

None of these are prescriptions, and obviously the playbook for these tactics is still being written.

Next Generation Adoption Attitudes

One more layer of this problem is being built right now, and it’s further out than many folks are looking.

On a recent road trip, my teenager told me about AI at school. Compulsory exposure. Tools introduced without much context for why. Classmates who had concluded, from their first extended contact with AI, that it was something to be skeptical of or dismissed. Not because they’d evaluated it carefully, but because their introduction felt like something being done to them.

Sound familiar? The adoption problem isn’t just in current workplaces. It’s being reproduced downstream in a generation whose first impressions are forming right now. That’s a longer conversation and it deserves its own article. But it’s worth naming here: we’re not just behind on the current adoption curve. We may be behind on the next one too.

Wrapping Up

In 2013 the question was: how do you convince the people with power that this practice has value?  Well, we figured that out. Imperfectly and slowly, with more catered lunches than anyone should have to sit through. But we figured it out.

The question now is different. How do you build genuine trust with the people doing the work, when the people with power already believe?

I don’t think we’ve found the answer yet, but I’d love to talk with the bright minds working on it.

—–

#AIAdoption #AIAdoptionDebt #DesignOps #UX #Leadership #ProductManagement #EngineeringLeadership #FutureOfWork #NextGenerationTalent

The 30-Point Sprint: How Leaders Hoard Capability Instead of Building It

A staff engineer at a scaling tech company told me about their managing director — someone with organizational authority, access to the best AI tools, and apparently a lot of enthusiasm for using them. The director had assigned themselves 30 development story points in a single sprint. The rest of the team was carrying 6 to 16 each.

“They vibe code everything,” the engineer said, shaking their head. Their team was left babysitting that output.

I’m not here to cast shade, and I’ve seen enough versions of this pattern to know it’s rarely malice — it’s excitement without governance. Glee without the long view. AI makes execution feel effortless, and when that feeling hits someone with organizational authority, the natural instinct is to run with it and stay in motion.

But I keep thinking about what a different story that could have been.

Imagine the same director, the same tools, and the same gap in formal coding skill. Instead of assigning themselves 30 points, they walk into a team standup and say:

“Here’s the problem I was trying to solve, and this is how I approached it with AI. Show me how you would do it the traditional way — and then show me how you would do it with the AI tooling we’ve implemented. Let’s talk through the strengths, drawbacks, and leverage opportunities for all three approaches.”

How different would that be for the team? For that leader? For the org’s health as a whole?

That’s not a weak play. That’s one of the highest-leverage moves a leader can make — using their own ignorance as an opportunity to build a structured learning platform. The team gets to teach. The leader gets to learn. The org gets a three-way comparison that surfaces assumptions, tradeoffs, and best practices that would otherwise stay locked in individual heads — or leave entirely when those people move on.

It becomes a running growth exercise. It compounds, to the good, for a change.

Instead, the reality

30 story points for someone who should be focused on meta-level engineering concerns. A team stuck babysitting their leader’s output. And an opportunity for something genuinely great quietly wasted.

AI gives leaders without deep technical chops a real reason to lean in — not for the first time, but never has it been so readily accessible. The question is whether they use that access to hoard capability or to build it.

The answer is what separates a manager from a leader.

Originally shared on LinkedIn.

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.

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.

Thoughts On Medical Decision Making

Original article by Jerome Groopman

We all fall victim to habitual behaviors, and more so when we are unable to focus sufficient attention on tasks at hand, believing (consciously or unconsciously) that we can accomplish some process or task without conscious thought, instead thinking about ‘more pressing’ matters.

What is more difficult to detect are those biases not based on habit, but instead on other factors. Groopman’s article on medical decision making explored this issue in the light of decisions made every day by physicians in practices and hospitals across the world.

Several types of errors were explored, including Representativeness error (thinking that is overly influenced by what is typically true), Availability error (the tendency to judge likelihood of an event by how easy relevant examples come to mind), confirmation bias error (cognitive cherry picking – confirming what you expect to find by selectively accepting or ignoring information) and affective error (making decisions based on what you wish to be true).

The stories he shared demonstrate how a very skilled and educated doctor can make incredibly dangerous mistakes, due in some cases to the fast-paced world of medicine but in other in reaction to common human urges such as the desire to be merciful and spare a patient embarrassment or further fatiguing tests.

At my workplace we are tasked with making medical industry communication more secure and much more efficient – resulting in better patient care and increased physician and clinician satisfaction. After reading this article and having learned a great deal about how complex the communication needs of a hospital or practice have become, I have to wonder how many mistakes are made due to the very real problems of workflow dissolution and workplace communication breakdowns. How many errors of the classes described by Groopman could be avoided or reduced in severity through more frequent and higher quality peer-to-peer interactions in the medical industry?

GapMinder Data Analysis

In my HCI cognitive science class we’ve been studying visualization and how a given interface can enhance our mental processing power, bringing more of our wits to bear on a challenge. Here’s a look at comparing a few layers of data as reported by two very different nations.

Denmark vs. USA – Charitable giving related to income & life expectancy

I chose to compare the nations of Denmark and the United States, examining their respective records of charitable giving and comparing that to each nations’ income per person and their life expectancy. The data available ran from 1960 to 2008, and so it’s worth noting that the period studied spanned several wars with worldwide impact, numerous financial recessions and a gradual but accelerating trend of climate change.

The United States
The United States in 1960 was quite a charitable one, donating 0.54% of the gross national income (GNI) while only reporting $18,175 in income per person. We had a change of heart it would seem, as the % of GNI given to charity fell steadily for 37 years before finally ending at 0.18% of GNI in 2008.

During this period, while our incomes rose by $24k and our life expectancy by 8 years we gave 0.54% less to charities.

Denmark
Denmark in 1960 was a hard place, donating only 0.09% of their GNI while reporting only $11,569 in income per person. They seem to have buckled down and gotten industrious, as the % of GNI given to charity rose for 21 years to 1.03%, with a high of 1.06% before finally ending at 0.82% of GNI in 2008.

During this period, their incomes rose by $20k and their life expectancy by 6 years. In the end Danes increased their charitable giving by a staggering 0.97% over the period.

Reflections
An interesting measure to add to this comparison would be an index of reported happiness & contentment – does charity or income have a greater effect on happiness?

I would also have enjoyed seeing an overlay of world events across political, economic and climate scopes, relating those factors into the changes in life expectancy, income and charitable giving.

The animation was quite helpful, and illustrated the rate of change between compared parameters over the lengthy collection of data ranging over 48 years, clearly calling out the rapid rise of Denmark’s charity while the USA gave away less and less each year.

It’s purely correlative, but it appears that given the much larger percentage they gave to charity (from their noticeably lower income) the Danish were not overly burdened and lived to nearly the same age. Many factors could have been at play, but I’m given to lean towards the old adage that money CAN bring happiness as long as you spend it on others.

Notes from GiantConf 2014′s “Building a Whole Team UX Design Team” presentation by Phillip Hunter

In his presentation on day two of GiantConf 2014, Phillip Hunter talked to us about “Building a Whole Team UX Design Team”. Here are my notes from his talk.

Phillip Hunter – Building a Whole Team UX Design Team
@designoutloud
http://www.minotaurdesign.com/blog/wp-login.php

His belief is that in the UX community, team building is much like early days in baseball scouting.

The focus on stereotypes:
on rock Stars in the industry…….
(is that a person w/ diseases and who trashes hotel rooms? lol)

On Ninja’s….
(is that the person who kills people in the night? lol)
Focus on design mishmash – (beanie/knit cap and glasses, lol)

– Stereotypes don’t help us build better UX teams. Avoid them.

(slide of the major pieces of most companies) – All these people are ENABLING the user experience.
– most of us are in Product development team.
– so it’s silly to think of one small piece of the org as wholly responsible for the UX of a company

4 primary capabilities (as a grid):
– engineering leading technology
– maintaining strong teams
– running a successful business
– enabling great experiences

The practice of creating experience is a SERVICE – look to service design for cues

Strategy means defining and inspiring before hiring

Hiring a dev, designer, tester because you need to developer, design and test is premature.

Context + capability to help you know the best way to create that holistic UX mindset.

OAQH- Orient, Assess, Question, Hypothesize

Setting the team-building CONTEXT:
– what are our goals, values, constraints and principles as a corp?
– what do we need to get done?
– why?
– how much/how fast?

Setting capability requirements:
– What do we need to be god at?
– How good? How will we know?
– What are our priorities?
– Not who…. (yet)

Liz Bacon’s infographic on her definition of user experience design
– pie chart of sorts
– ranked herself within each facet

Building effective structures within the company:
– Complementary strengths vs homogeneous development
– Breadth and depth of skill across people
– Increase participation

Beyond hiring and skills:
Shape align and inform with biz goals
Aim for impact, scope, scale, diversity, resilience, sustainability

Crazy list of necessary skills (all of which mapped back to the grid of 4 above)

Atomic elements of necessary high level skills

Have the right project members been identified?
In what areas will augmentation be the best thing?
What kind and from where?

Building Your list of necessary Skills
Skill name
-skill 1, 2, etc becomes `> color, line, shape 2. Latent need identification, ebrand integration, prototyping, etc.

Gathering list items:
Ask your UX leaders and ICs, your UX enthusiasts, your Product owners, your Execs and sponsors.

(ranking 1-5 etc)
Skill name – Current Level – Desired Level – Priority
– – – –
– – – –

Perceived skill gap
– gap value on its own wasn’t that compelling/illuminating
– Gap value multiplied by Priority – this really surfaced the true GAP in context

Conversations that can come out of the above types of analysis?
Who does that already?
How can you get them involved?
What do your colleagues want to be good at?
X is how we need to craft our job description for HR!!!

sixboxes.com
framework for aligning people’s desires with their roles, and ultimately their ideal internal path that also benefits the company

– issue challenge to add UX to everyone’s job
– Let people find their point of contribution

HIRING (since sometimes you just have to…..)
– understanding and implementing the strategic framework from above
– involve the team to determine fit and talent
– Hire the inspired

Phillip’s slides (Thanks, Phillip!) – http://www.slideshare.net/philliphunter/building-a-whole-company-ux-team

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.