We stand with Ukraine and our team members from Ukraine.

The Community Of Over 578,000

Home ›› Customer Experience ›› How To Make CX/UX Agile In 5 Steps

How To Make CX/UX Agile In 5 Steps

by Debbie Levitt
Share this post on


How to make CX/UX agile

Transition towards customer-centricity and make your UX/CX agile by following 5 steps

Here are 5 steps to transform however you’re doing Agile towards Customer-Centric Agile, as I’m calling it. This is “Agile UX” or how we make CX/UX more Agile.

Step 1: Hire Fully Qualified CX and UX Pros to Do CX and UX Work

We’re never going to be Agile if we are giving the wrong people the wrong work. In at least 99.9% of the time, we don’t ask Marketing to write code. We don’t declare that data analysts can do manual QA testing after a few hours of training. We hire qualified marketers and QA testers when we need them.

Take a look at the job listings at your company. Chances are your “Junior” UX Whatever required 1 year of experience, maybe 2 years of experience. Yet when UX is spread thin, someone is SURE that anybody at our company can “do the UX.”

Let’s say that again.

  • When CX/UX wanted to grow the department and add qualified people, we’re often told there isn’t budget or we don’t really need that.
  • But when UX work isn’t getting done due to a lack of qualified people, someone decides it’s “good enough” to give the work to unqualified people, teammates who don’t have 1–2 years of UX work experience. They wouldn’t even be interviewed for a UX job at our company.
  • Why do we need 1–2 years of experience when someone is applying but if they’re already a non-UX role at our company, we appear to have no standards?

Step 1 to being Agile is hiring qualified people and having standards for who does UX work. We have these standards for other roles. We have these standards for our own CX/UX candidates. Let’s please stop pretending that our work is easily “democratized” when no other domain is a democracy. Product Management and Engineering aren’t democratizing.

Let’s stop pretending that UX is as easy to learn as pivot tables. CX/UX aren’t quick upskills. If they were, we wouldn’t demand “entry-level” candidates with 2+ years of experience. If UX could be easily upskilled, we could hire people with no experience and train them in hours.

Step 2: Hire CX/UX at a Nearly 1:1 Ratio With Engineering

At many companies, a UX resource is assigned to more than one project. This means that a team of 6–10 Engineers is waiting for a fraction of one person to do research, IA, IxD, prototyping, testing, and sometimes visual design too.

This makes no sense. This is the main reason why we hear that UX isn’t Agile. Oh, UX is SO SLOW because it’s going to take that UX person SO LONG to do that work. Yes, it surely will when you put 1 UX practitioner or 30% of 1 practitioner on the team.

The solution here is to have a nearly 1:1 ratio of CX/UX to Engineers. My model calls for:

  • A paired CX Architect team. Two people proficient in information architecture, interaction design, and prototyping. This could be two seniors (or higher). This could be a senior and a junior or apprentice.
  • Three CX Researchers. Three people proficient at generative, evaluative, exploratory, and other types of research, mostly qualitative. This could be one senior (or higher) and 2 juniors or apprentices.
  • When should these sub-teams have more leads/principals/seniors and when is it OK to have people with less experience? It depends on the company, project, domain, etc. I can’t say for sure, but I would like to see more talented apprentices and juniors given a chance and direct support and coaching.
  • This also means that we have specialized jobs with different responsibilities. Developers and QA feed each other. Researchers and Architects feed each other. We improve Agility when we let specialized workers focus on tasks in which they are proficient and efficient.
  • Even if you hired CX/UX generalists who show talent and skills in research and architecture/design, we could still be more Agile with 5–6 of these on a feature team versus the sole practitioner (or fraction thereof) that teams tend to have now.
How To Make CX/UX Agile In 5 Steps. Presentation slide visualizing what I’m about to explain.
Presentation slide visualizing what I’m about to explain.

Let’s visualize that. Imagine a larger project that needs serious research and then serious design. This isn’t a small fix. We’re estimating 370 hours of research work and 210 hours of design and iteration. This isn’t far-fetched or uncommon. My company has done a few of these in the last couple of years.

  • If we put one Jack of All Unicorns on that, it would be 19 weeks of work for them. There is no way anybody will give you 19 weeks to have something ready for Engineering. You will hear that you are not Agile.
  • But what if we use the Delta CX team model and put 2 Architects and 3 Researchers on it? The researchers can probably get that work done in around 4–5 weeks depending on how many useless, time-wasting meetings you make them come to (rather than giving them time to do their work). Two architects should be able to get 210 hours of work done in around 4 weeks, awful meetings permitting.
  • This means we would need 4 two-week sprints to get a pile of stuff into the backlog. When Engineers want 4 two-week sprints, nobody calls that Big Engineering Up Front. Let’s normalize teams of any type doing great quality-over-speed work in “reasonable” numbers of sprints based on the size of the stories, feature, or project.
  • Where our research set us up for design success beyond the feature we’re working on now, we would only need to estimate our time for architecture/design and testing.

CX/UX work is done before Engineering’s work. Since the dawn of time, designing something has come before building something. And we’re populating the backlog. CX/UX are always before Engineering in our Agile assembly line.

Step 3: Kill Most Meetings, Give UX Decision-Making Autonomy

You made it through steps 1 and 2. Now we need to address drowning in hours of useless meetings. Many could be emails or dashboards. This keeps us from our work and keeps us from being Agile. Engineers have their ceremonies but don’t seem to end up in 5 hours of meetings each day like CX/UX often does. Engineering doesn’t constantly pull each other into “collaboration sessions” and the like.

Let’s take a page from Engineering, let’s be more self-managed, and let’s allow UX to make decisions in their own domain. This would eliminate all of these “alignment” meetings where UX pros have to hope someone else doesn’t circumvent, overrule, or ignore our UX decisions.

Imagine an Agile world where UX showcased their work, people made a few comments, and nobody killed what UX decided without a really good reason. You know… the way Engineering showcase meetings work now.

Step 4: Time Estimation and Planning

CX/UX must be involved from the very start of early planning, especially in task-oriented companies, where our research will inform strategies, initiatives, and product (versus someone internal deciding what the product does, and UX is told to wireframe that).

CX/UX can’t get the time left over after Business Analysts, Product, and Engineering take the time that they want. We are an equal voice in planning. If we are task-oriented and doing this right, then CX/UX work feeds everybody else. We feed BA’s so they can write more customer-centric requirements. We feed Product. We feed Engineering’s backlog.

How To Make CX/UX Agile In 5 Steps. You typically see Agile process infographics that start with the backlog as if the backlog magically appears.
You typically see Agile process infographics that start with the backlog as if the backlog magically appears.
How To Make CX/UX Agile In 5 Steps. But it’s really more like this. The phases and tasks we need to do from UCD or HCD come first. They populate the backlog.
But it’s really more like this. The phases and tasks we need to do from UCD or HCD come first. They populate the backlog.

CX/UX must be brought into every planning session at every level so that we are estimating our time and resources. Then we get that time and resources because we are customer-centric and we care about using better processes to create better products and more satisfied customers.

Step 5: Tri-Track Customer-Centric Agile

How To Make CX/UX Agile In 5 Steps. Tri-Track Agile, explained below.
Tri-Track Agile, explained below.

Finally, we must use Tri-Track Agile. Quite simply, this is where there are three streams working at the same time, collaborating, and feeding each other.

The first track might be called Research or Understanding. This is our CX/UX observational research, insights, opportunities, as-is states, optimized future states, and strategies. This track includes all of the artifacts and documents coming out of research work.

Research feeds the second track, often called Design or Discovery. This includes architecting, designing, testing, and iterating. But if you look closely at the infographic on the right side, it’s also showing that requirements and user stories would be created or improved during this track.

This supports the idea that research isn’t just a UX thing for UX workers. Research should feed Business Analysts and Product Managers and Owners. Research is business intelligence and customer intelligence around people, systems, and context. It should feed company strategies and goals, though that’s not on the infographic… yet.

The third track in Tri-Track Agile is Engineering, often called the Delivery Track. Everything that’s Engineering fits into this track. Coding, testing, sprinting, ceremonies, etc. Engineering gets to do whatever they want here. This is theirs to plan and execute based on how they want to work.

Notice that the first two tracks are not controlled by Engineering or any Engineering-focused methodology. They do not require working in sprints or holding Agile or Scrum ceremonies. CX/UX can join some or all of those as a part of collaborating with Engineering. But left to our own devices, we probably wouldn’t choose to work this way. And we shouldn’t be forced to.

post authorDebbie Levitt

Debbie Levitt, Debbie Levitt, MBA is the CXO of Delta CX, has been a CX and UX strategist, designer, and trainer since the 1990s. She’s a change agent focused on helping companies of all sizes transform towards customer-centricity while using principles of Agile and Lean. Clients have given her the nickname, “Mary Poppins,” because she flies in, improves everything she can, sings a few songs, and flies away to her next adventure. Her “Delta CX” book and “Transforming Toward Customer-Centricity” training teach companies how to improve customer satisfaction, predict and mitigate business risk, and increase ROI by investing in great customer experiences. She has other training programs that teach non-CX roles about CX, why it’s done by specialists, and how to integrate it into teams and processes.

Ideas In Brief
  • Debbie Levitt suggests her 5 steps to transform however you’re doing Agile towards Customer-Centric Agile:
    1. Hire fully qualified CX and UX pros to do CX and UX work
    2. Hire CX/UX at a nearly 1:1 ratio with engineering
    3. Kill most meetings, five UX decision-making autonomy
    4. Estimate time and plan
    5. Tri-Track Customer-Centric Agile

Related Articles

The overview of current challenges and opportunities design faces and how BBC team can help designers out to enhance digital experience and understanding of the world.

The Evolution of Experience Design
  • Dan Ramadan, Creative Director for UX Architecture & Content Design at BBC, tells about the current challenges and opportunities design faces by describing 3 stages of ‘the web’:
    • Challenges of the past (document retrieval)
    • Challenges of the present (control and contribution)
    • Challenges of the future (pervasive and ubiquitous)
  • Technology is as capable of solving problems as it is of creating them.
  • The team at BBC can explore how digital experience can enhance our understanding of the world, develop empathy for others, instill pride and commitment to the importance of the individual and the inherent value of shared values and cooperative society.
Share:The Evolution of Experience Design
5 min read

As organizations grow in their conversational maturity, there’s an increasing demand for conversation designers. Explore 7 skills to learn for conversation designers in 2022.


7 new skills to learn for conversation designers in 2022
  • Conversational design requires far more than having got all your convo design courses nailed, completed all the challenges on VUI-challenge and finished re-reading Pearl, Evanhoe & Deibel and Cohen, Giangola & Balogh for the umptieth time.
  • There is a number of new skills that can up your career as a conversation designer:
    • NLU
    • Entities
    • Entities on steroids: ontologies and graphs
    • Building conversational teams
    • Open source movement
    • Mastering conversational AI platforms
  • It’s time for conversation designers to develop t-shaped profile: specialize in one or two particular conversation design skills and systems , and mastering skills that allow us to connect with people from neighbouring disciplines.
Share:7 new skills to learn for conversation designers in 2022
7 min read
7 new skills to learn for conversation designers in 2022

There are different ways participatory design can influence young people with cognitive disability. Read reflections on co-design methodology and ways it can help.

Reflections: Co-Designing with Young People with Cognitive Disability
  • In this article, Jax Wechsler, Principal Designer at Sticky Design Studio, shares:
    • Facts about Young People with a cognitive disability that may be useful when working with this group
    • Discussion and reflections about her methodological choices
  • Things to know about Young People with cognitive disabilities:
    • Ability levels can be very nuanced, every Young Person is different
    • Life Tasting not Life Wasting!
    • The level of advocacy of parents impacts experiences and opportunities for Young People with Cognitive Disabilities
    • Social inclusion and relationships are keys to wellbeing
  • Reflections on Co-Design Methodology:
    • Recruitment is hard!
    • Using referrals and ‘snowball sampling’
    • It’s important to build rapport
    • Understanding ability and research design
    • Cultural probes/diary studies are gold
    • Parents mediating participation
    • Flexibility is key
    • Value in participation
Share:Reflections: Co-Designing with Young People with Cognitive Disability
10 min read
Reflections : Co-Designing with Young People with Cognitive Disability

This website uses cookies to ensure you get the best experience on our website. Check our privacy policy and