Category: Usability

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

Welcome

Hello. I’m Richard Allan Lee.
If you’d like to connect, I may have time to talk. 

I’ve spent 25 years getting closer to the intersection of people, technology, and outcomes — moving along a through-line that started with making things look right, extended to making them work right, and now hovers in the space of making entire organizations work well.

At a more granular level, so far I’ve been an artist, designer, design manager, software developer, revenue ops manager, software engineering manager, ux designer, program management director, commerical drone pilot, podcast host, voiceover actor and musician.   

“That’s nuts!” you might be thinking… Nope. I’m just a life-long learner, a bottom-up thinker, and a systems-builder who’s endlessly curious and utterly unafraid to admit he knows nothing about a topic – and then sets about to fix that!   

The through-line across my life is creativity and problem solving – and always looking for the win-win… for organizations and humans alike. Want to learn more?

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?

Thoughts On Proprioceptive Feedback

The literature:
Spatial Updating Of Self-Position And Orientation During Real, Imagined, And Virtual Locomotion (1998)

For efficient navigational search humans require full physical movement but not a rich visual scene.

The research done by Klatzky, Loomis, et al. as well as that of Ruddle and Lessels both indicate that proprioceptive feedback is a crucial factor in our ability to accurately gauge distance, size, heading and rate of movement. While my own experience echoes their findings, the reading left me with a couple questions.

First, what are the differentiating factors that separate those of us with what appears to be a more developed innate sense of direction (or perhaps a more advanced and accurate sense of place) from those who have difficulty with even the most rudimentary way finding operations when removed from familiar environments? Are there biological factors at play, or are the differences primarily acquired through life experience? Can we train to be more receptive to proprioceptive feedback, learn to interpret it more accurately, or are we consigned to our genetically disposed navigational fates, as it were?

Second, what are the implications of this kind of research on purely digital mediums, in which physical feedback is minimal or nonexistent? Are there natural corollaries between physical locomotion or visual perception and our navigation of pages on the web or through various states of an application? Could connections between these modes of ‘navigation’ be yoked more efficiently, enhancing a user’s innate ability to find their way about within a complex application?

What do you think?

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.

Using Vision To Think (a nod to Stuart Card)

In an HCI class I’m taking currently, we’re studying the cognitive science behind the long human history of visual-spatial displays. We’re talking caveman drawings up to the latest in Minority Report-style virtual interactive displays – fun stuff!!

Here’s an article to soak up if you’re interested in this kind of stuff: The Cognitive Science of Visual-Spatial Displays: Implications for Design

And here’s some thoughts of my own about that article:

More than anything else, this week’s reading of Mary Hegarty’s paper on the science of visual displays made me realize why it’s much easier for visually-minded folks like myself to understand something best when we’re able to interact with a subject on a visual level.

“Representations that are informationally equivalent (contain the same information) are not necessarily computationally equivalent”…
“task performance can be dramatically different with different visual displays of the same information”…

These are dead on. Whenever I’ve encountered a complex problem, whether facing it alone or in a small group (or mentorship, etc.) I often kick off the process or discussion with something along the lines of “Are there other ways I/we can look at the issue?” This is helpful in many cases because in representing the object or process with an iconic, relational or complex display allows us to augment our thinking, to enhance our understanding and to bring additional inferences or insights to bear.

Displays allow us to externalize both the storage and the organization of a massive amount of data, freeing up our fragile and limited minds to process that data in different ways. It also lets us explore the relationships between groupings of related elements, i.e. chunking – freeing us to a degree from the limitations of short term memory by compressing these complex associations or concepts into a fewer number comprehensible objects.

I understand the world through my visualizations of it, both in reality and in my internalized efforts to understand the world around me, so my favorite blurb by far was the author’s reference to Stuart Card’s sentiment “Using vision to think”.

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