We stand with Ukraine and our team members from Ukraine.

The Community Of Over 640,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
7 min read
Share this post on
Tweet
Share
Post
Share
Email
Print

Save

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.

Tweet
Share
Post
Share
Email
Print
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

An inclusive process leads to experiences that improve lives and develop their full potential on the market which is beneficial for both business and people. Learn how to widen accessible products to inclusive ecosystems by using 5 simple methods. 

How to Design for Human Aging: 5 Methods for Inclusive Digital Experiences
  • In order to reach age-inclusive solutions, designers need to adopt an inclusive mindset, make empathetic decisions and apply practical methods.
  • 5 methods for inclusive digital experiences:
    1. Inclusive, in-person research and testing
    2. Focus on behavior instead of demographics
    3. Tailor accessibility guidelines
    4. Map product demands with capabilities
    5. Question interface conventions
  • An inclusive process leads to experiences that improve lives and develop their full potential on the market which is beneficial for both business and people.
Share:How to Design for Human Aging: 5 Methods for Inclusive Digital Experiences
7 min read
How to Design for Human Aging: 5 Methods for Inclusive Digital Experiences

Design tokens aren’t just something that you can easily retrofit into your existing wardrobe. They require an entirely new way of thinking and working. Learn how to start thinking in design tokens by completely changing the way you work with design systems.

Design Token Thinking
  • Design tokens require an entirely new way of thinking and working.
  • Designers can be documenting their design system, but the documentation will always be a step behind their design file.
  • The author unpacks the idea of an alternative design system and names it “the way of the future.”
  • Design tokens need to become a primary method for how you talk about and interact with your design system, both internally and externally.
  • In the end, you can get a design system that is:
    1. Future proof
    2. Accessible
    3. Able to be easily changed.
Share:Design Token Thinking
5 min read
Design token thinking

Typing search queries is gradually becoming an outdated artifact of the past and voice tech is becoming more useful and promising by the day. So what other prospects await for voice tech and why is it so special? We’re about to find out!

Voice Search and Voice Interfaces 101
  • This article covers some essential voice search statistics, how people interact with voice interfaces, what can users do with voice and why startups should care about all of this.
  • Typing search queries is gradually becoming an outdated artifact of the past.
  • The author believes that the overwhelming consumer shift towards voice interfaces will inevitably lead to the mass adoption of this technology among startups.
  • How to Design a Voice Interface?
    • Pre-design Stage
    • The Main Design (user research, customer journey mapping, VUI competitor analysis, gathering requirements, prototyping, usability testing)
Share:Voice Search and Voice Interfaces 101
8 min read
Voice-Search-and-Voice-Interfaces-101-

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