The Coming CX/UX Correction and Shift

Expanding from my previous article on my 2-year prediction for how UX has already started splitting and will continue to split…

The Great Correction :) looks like this:

1: There are really two types/buckets of jobs in our CX/UX/UI/XD/whatever-you’re-calling-it world.

Job A is typically an order taker and production designer to “just make wireframes.” Job A might believe that “defining the problem” or “understanding customers” is a day of sticky notes in a design thinking workshop or design sprint. Job A is solution-focused. Don’t focus on the problem too much. We need those solutions! Engineering will get them to the public, and then Marketing can tell us if people like them.

Job B is a problem finder and problem solver to look at solid qualitative research (or do the research first) and go from there. Job B wants to do 200+ hours of observational and interview research and analysis… or work from it to be research-informed. R&D, R before D, business and customer intelligence from qualitative research before we shoot for solutions. You have to deeply understand people, problems, systems, environments, and more before you can hope to come up with the right/best solutions.

That will split the production designers (Job A) from the people who I like to call The Children of Don Norman (Job B). We need both of these jobs and the workers who tend to prefer each. There are places for both of these people in all companies.

2: The personalities required for Jobs A and B are different.

Job A typically needs highly talented and creative people who are happy to take expert care of what’s being asked of them. They feel rewarded when they can complete concrete work expected of them. Job A workers are less likely to challenge teammates’ assumptions or ideas; that type of challenging isn’t really part of the job. Job A workers might hear:

• Here’s a list of requirements. Please make the best screens that match them.
• Please wireframe the Product Manager’s idea.
• Here’s the winning idea from a design sprint, Lean UX, or some other design by committee adventure. Please clean it up and improve it.
• Please get us some screens (even though we don’t have good or any research and might not do any usability testing).
• Surveys or NPS told us this, so please come up with some fixes (research and/or testing not required).
• Conversions are down, so please make a better landing page (research and/or testing not required).
• We know our customers, we know their problems, let’s just find fast solutions so Engineering can get them out. Then we’ll learn if they were the right solutions.

Job B typically needs highly talented and creative people who don’t want to “take orders” or “just make a thing.” These personalities are typically change agents, whistleblowers, advocates, and standing up against the status quo. Critical thinking and challenging assumptions are required. Teammates and managers might tell them:

• We should create strategies and initiatives based on the business intelligence that deep customer research can provide.
• Before we decide on features, we need to better understand customers and the market to decide what we should or shouldn’t build.
• We shouldn’t wireframe or prototype anything without being informed by well-executed and well-analyzed observational and/or interview research.
• Products and features that don’t match customers well are risky and wasteful for our business. Let’s make sure we are thoroughly researching, architecting, and testing before Engineering spends weeks or months pushing it out.
• Customers don’t want minimally viable anything. How do we prioritize the most important features or changes based on real user tasks, workarounds, knowledge, and obstacles?

You get the picture.

This is why Job A is unlikely to be a starting point or gateway drug into Job B. Very often, different personalities gravitate to each job. Therefore, there’s nothing wrong with being a Senior Job A or Lead Job A who never wants to do Job B, and just wants to keep rising in the ranks of Job A. Both jobs require skill and talent, but they are somewhat different skills and talents.

There’s nothing wrong with a Job B personality who never wants to do Job A, not even as an entry-level job. Please see my February 2020 Medium article, “No, We Don’t Want To Make UX Juniors Be Production Designers,” which was a response to some (typically) bad advice from Jared Spool. He seems to think that Job A is a great place for Job B people to start, and I burn that to the ground, in detail.

Quick side note: an early version of the Job A/B concept is in my 2019 “Delta CX” book. I called Job A “Order Takers” and I called Job B “Interface Scientists.

3: The requirements for each job are fairly different. A and B candidates are assessed differently.

Job A wants X years of Figma or Sketch. You must know “how to wireframe.” Visual design portfolio required. You will be assessed by how pretty screens are. You might not be asked about process since it’s all really about using the right software and tools to produce the work quickly.

Job B might specify tools, but they will be way more hung up on the level of proficiency you show with each of your required skills. Assessing for process, approach, methodology, and the critical thinking going into those will be at the core of determining if this candidate is a fit. Employers will want to check that you have studied cognitive psych, human behavior, and/or behavioral economics. Perhaps anthropology. Accessibility training is a must, not a nice to have.

• If you’re a researcher, they will want to assess how you plan, recruit, execute, and analyze research. Why do you choose certain methodologies over others?
• If you’re more on the architecture and design side, they will want to see portfolio work that shows you understand information architecture, good visual hierarchy, heuristics, trust signals, interaction design best practices, etc. How did you use research insights to inform interaction designs?

4: Education for A and B are different.

If Job A mostly requires X years of Figma and a visual design portfolio, then every bootcamp is OVER-TEACHING you. You don’t need 12 weeks of anything to push out Figma things you think are nice. You don’t need months of a bootcamp or a long online course to tell you how to “design” what other teammates want to see. Learn Figma, be good at visual design (formal education is optional), get it done!

Bootcamps could instead teach you how to be a good cog in the fake Agile wheel. Or maybe someone can make a video series on that, and you don’t need a bootcamp.

Job B will require actual education and practice. It might be university education. It might be bootcamp education. It might be years of education and not weeks. It will focus on core principles, critical thinking, and problem finding before problem solving. It will require apprenticeships so that you are trained on the job by leaders and experts with many years of experience. You will have to level up a bit before you are left to do this work without oversight and without tough love work reviews.

In that case, every current bootcamp and sadly many other programs and uni degrees fall way short. They’re not getting you ready for Job B. Not even close.

This is where the correction starts happening.

We now have to correct for all of the people who took bootcamps, self studied, and got “certified” under a “previous” educational system that was mostly designed to create Job A workers. Hey, just get upskilled really fast and fill seats. Companies need people who say they do UX! You’ll get a job fast.

The industry will have to correct for all of these people who were sold the promise of a fast path to big salaries and a good job. When we have Job A and Job B more clearly defined, and we have standards for what you need to learn to do each, educational systems will have to change. Programs will have to specifically make you ready for Job A or Job B. Job A’s core education might be “learn Figma fast” or “mini art school bootcamp.” Job B’s core education might be years of a more intense program with a one-year paid apprenticeship at the end.

The correction also has to happen in workplaces.

Companies will need to figure out who they really have… Job A workers or Job B workers… and which ones do they really want. Which ones match the processes and priorities at this company? Are we customer-centric? Or are we speed over quality? We might have to “correct” for who we hired and how we utilized them.

People faking it (whether or not they eventually make it) wouldn’t be hired for Job B. Faking probably wouldn’t go over well for Job A either. Change agents (accidentally) applying for Job A would be rejected, unlike now where we hire them but try to make them Job A types.

Job descriptions will have to change. How we assess candidates will have to change. We’ll essentially have a whole new category of labor. Well, it’s an old category coming back from being hijacked, compromised, and diluted.

When job descriptions change, there will be a correction for all of the people the previous education system claimed were making “job ready.” Employers already corrected for them by making a junior/entry-level job require at least 1 year of real work experience. That shut the door on those people, but it didn’t stop the flood of them into the market because bootcamps hadn’t changed their sales pitch. It didn’t stop all of the people not ready for Job A trying to get a Job B job.

This is why there will be a series of changes and corrections when Job A and Job B are separated, clearly defined, and have shifted.

5: What we call A and B will then completely diverge.

They can’t both be “UX Design” or “Product Design.”

What are the right terms? I am still working on that. What I do know is that we have to find terms that are hard to hijack, compromise, or redefine later. For example, UX/UI meant Job B until people made it also mean Job A. Product Designer was Job B until people made it also mean Job A. Now we see people with these titles, and we genuinely have no idea if they do Job A or Job B.

Here’s where I am as of mid-July 2021.

• We often think this is just a problem for “UX Designers” and “Product Designers,” but it’s a problem for researchers too. Some people calling themselves researchers just want to run surveys, ask stakeholders what we know about customers, or hold a focus group. That won’t match Job B.
• Adding words like “knowledge-driven” or “task-based” might not help since Job A might imagine they are both of those. I can see those being hijacked.
• I previously suggested that Job A keeps “UX” and Job B uses “CX,” but that’s imperfect. Job A could hijack “CX.” Same for “XD” and “Experience Design.” “Experience Design” isn’t different enough from “User Experience Design” to make anybody understand that someone thinks this is something different.
• I’d like to give Job B titles something related to “business intelligence” or “risk mitigation” since that’s at the core of what we’re doing, but there are already jobs with those words. Same for “consumer intelligence” and “customer intelligence.” We don’t want to hijack them!
• I am recommending the word “Designer” come out of Job B titles for everybody except visual designers. People hear “designer” and they assume pretty and fonts and brand and colors and please make it pretty. So many who want Job B don’t focus on making things pretty, so it’s not the right term.
• “Architect” might be hard to hijack since a production designer might not have a great answer for how they are “architecting” something. I guess they could try to hijack that.
• Words related to “Strategy” (strategic, strategist) and words related to “Analysis” (analytical, analyst) are hard to hijack since you can assess a candidate for: are they doing anything strategic or analytical. Job A’s perception of strategy and analysis won’t look anything like Job B’s definition of those words. The problem with calling titles “Strategist” or “Analyst” is that you imagine they are strategizing or analyzing but not necessarily researching or architecting.

Job A Titles

To be clearer and more honest, Job A should have titles like:

• Marketing Researcher, for people who mostly want to run surveys, NPS, or focus groups. They would sit under the Marketing department, and have a Marketing manager.
• Product(ion) Designer, for people who are doing production design. Keep “UX” and “CX” off these titles. Who manages them is more complex. If you have a department with Job B people, then they are teammates and possibly assistants to the Job B people. They would be managed within that department. If the organization has basically done away with Job B, then Job A people can sit under the Product department, and have a manager from the Product department as their manager.

That would be clear. It would be best to remove “UX” or “UX/UI” from these titles since the user is so rarely involved and so frequently guessed about. It’s not UX without U. It’s typically production design without U.

However, I believe that these jobs will continue to use “UX” since that sounds like prestige and higher pay. “Production Designer” doesn’t have that prestige sound. Therefore, I believe that these jobs should just push towards “Product Designer” so that we can keep the word “design” while making sure they don’t say UX. And most of us will know that Product Designer is short for Production Designer.

For Job B, how about…

• Strategic CX Researcher
• Strategic CX Architect
• Strategic CX Visual Designer

Technically, if we remove CX, UX, and UI from Job A titles, Job B could keep these terms. But that’s hard because of how many years “UX Designer” has meant “production design.” We are unlikely to re-teach companies and co-workers that now a “UX Designer” is not a production designer or order taker. We have trouble explaining that now and getting companies to care about research, good interaction design, testing, and customer outcomes. We also have many Agile coaches, Scrum masters, and engineers who are sure they can “do the UX.”

I suggest we abandon our most misunderstood and hijacked titles, and find something better.

I haven’t decided on the best titles yet. I only know that jobs are really diverging. There are definitely Job A and Job B. You can’t always tell them from the job description (yet), but you can certainly tell them once you’ve been working there a month.

This shines a light on evangelism and how we try to fix the problems at our jobs.

In my May 2021 article, “UX and Evangelism: Undoing What’s Undoing UX,” I talked about how many people have brought in crap methodologies and evangelism to try to fix processes and jobs. With a fresh perspective, we can see that most of the problems at our job probably fall into two categories, stated from the perspectives of the workplace (not you or me):

1. We don’t understand what UX really is or does. We’re kinda a Job A organization/team. We allow non-CX/UX domains to control UX. Product, Engineering, Marketing, and Business Analysts define what UX is, who can do it, how much time we spend on it, etc. We don’t really need UX people since all of those roles can “do the UX,” but we hire them. It looks good to say we have a UX team, and it gives us someone to do grunt work like wireframes and paper prototypes.
2. Job B people work in our Job A jobs. Those Job B people were either desperate, we sold them a false bill of job description goods, or they read our crappy description of a Job A job, and (like the change agents they are) they figured they could change our company. Even though the job descriptions give them no power or authority to create organizational change, it’s in their blood, and they hoped they could do it.

So what’s next? What do we do now? Other than coming up with better names for Job B, I have 4.5 hours of ad-free content on my YouTube channel on how we get out of this mess. You can find that as a long 2-part series (though you could listen at fast speeds):

• Episode 115: Breaking The Addition To Aspirology Workshops — This is about how design thinking, design sprints, Lean UX (which is neither Lean nor UX), democratization, decentralization, and trying to train/upskill/retrofit non-UX roles into doing UX work hurts our profession, jobs, and customer outcomes.
• Episode 116: Customer-Centric Agile: Making CX/UX Lean and Agile — This is about the basics of Agile and Lean, and how we can use those principles to improve our work. I cover how certain flavors of Agile and Scrum use pretzel logic to explain why they get to control us, and how our #1 priority needs to get out from under Engineering’s control. I explain how we need to use dual or tri track Agile, and how to staff/build our CX/UX teams to be more Agile and Lean (hint: it’s not one unicorn trying to do all the things in series). And I cover how to speak the business’s language so that you are more likely to be taken seriously, seen as creating value, and eventually get that seat at the table.

While these are on YouTube, the video is secondary. They work pretty well audio-only. You can find the Delta CX podcast in audio-only form, and these episodes through Google Podcasts, iTunes, Spotify, and Audible.

Coming up with better names for our roles won’t really matter if we don’t get out from under Engineering’s control, get ourselves on our own track (as every other domain is), and utilize principles of Agile and Lean (but maybe not the ones you imagine) to improve our work and efficiency.

Need help with any of this? Please contact me and let me know what I can do for your company. I’ve been coming into companies and doing various lengths (including longer and shorter) of the 4.5 hour podcast episodes as private training including Q&A, often for free. I can also help with strategizing a roadmap for creating this change on your teams or at your company.