Dev & UX: How Integrating UX Improves Engineering’s Efficiency and Sanity

User experience (UX) is often misunderstood. Many teams and workers believe it’s just sketching or laying out screens. This would be like saying that QA engineers just “check for bugs,” and anybody can check for bugs. Misunderstanding UX leads to problems in hiring, processes, team culture, product, and customer satisfaction. Today we’ll learn how to start improving all of these by seeing UX as it really is: engineering’s time and money saver.

User Experience and User-Centered Design (UCD)

User Experience (UX) is the experience a user or customer has in using your digital product (app, website, SaaS, etc.). It’s also the term we use for all of the phases, tasks, and artifacts UX professionals work on to research, architect, design, test, and iterate. This means that “UX” is like “engineering”; it doesn’t just mean one type of work or one single task. 

Many people mistakenly believe that UX is about making something “look good,” but with foundations in cognitive psychology and human behavior, it’s really about making things easy to learn and use (“usability”). You know this because we’ve all seen websites and apps that have nice visual design, but are still awful to use. They don’t solve our problems, they make our tasks inefficient, and we shout at the screen. That’s one way to tell UX from UI!

User-Centered Design (UCD) is the most common process used by UX practitioners. It’s a series of phases, with each phase having multiple tasks and documents we can create. Those who assume the process will be long and expensive often don’t understand that more experienced UX professionals approach it strategically. We must examine a feature, story, or project, decide which UX tasks are needed, and include them in our plan. 

Additionally, order matters. Each phase informs future phases. Interaction design is informed by the research, content, information architecture, and other work that came before it. Without that, it’s guessing, and that’s risky for our teams.

The phases include (and this is a short version):

• Research - This is the foundation of our project. What do we understand about users? What are their tasks? How do they do this now? What can we learn  psychologically about them (how they feel, think, choose, combine, simplify, etc.)? Asking the wrong questions, asking in the wrong ways, or asking biased questions will turn our “research” into junk, and set our project up for risk and potential failure. If you have ever worked on a team that was surprised later to find out that “customers didn’t want this,” then you can understand how flawed user “data” and guessing what people will want is an incredible waste of time, money, and customer patience. Bring in UX experts to do great research work at every step: planning, recruiting participants, executing the research, synthesizing the findings, and turning those into actionable insights.
• Content and Information Architecture - Now we need to decide what this site, app, or system says (text) or what media will be where, and come up with ways to organize this information so that it’s logical to the user. What are the steps customers will take to accomplish tasks, and how can we simplify those? Many teams make the mistake of skipping UX steps that focus on organization, or they organize based on what the team likes (versus the customer). There are no replacements for getting these steps right, especially since they set up our interaction design for success.
• Interaction Design - This is what most people think of when they think of UX. These are our wireframes and prototypes, the blueprints of our designs. Asking someone to just sketch screens isn’t really UX work, especially if it’s in a vacuum without the other phases of the process. We must architect and create an experience based on qualitative data on potential and real users.
• Testing - Testing is the QA of UX. You wouldn’t skip QA and just release your code. Similarly, UX concepts and exact executions of ideas should be tested, sometimes more than once, to make sure we’re building the right thing. Nicely-sketched screens will be a giant waste for our company if they don’t truly solve customer problems.

UCD has many variations, and people love to make infographics out of them. You might see “Double Diamond” suggested as a popular UCD variation. Design thinking tries to be a stripped-down variation of UX, but it fails completely. Design thinking is not user experience. If it doesn’t devote serious time and resources to qualitative research, or it favors guessing and assumptions to “save time,” it’s not UCD. It’s also not Agile or Lean.

Do we have to hire people for UX jobs? Can’t anybody do this work?

UX work is highly specialized. It’s not the type of thing anyone can learn well after reading a book or taking a few online courses. It takes years to learn and do well. As a profession, UX is in a transition period right now after discovering that bootcamps and even many university degrees aren’t making people job-ready. If you’re not job-ready after a uni degree, you should definitely not be doing UX work by guessing after reading a couple of books or watching some YouTubers. 

Your company should hire UX experts to do UX work. That sounds obvious, yet so many teams imagine that anybody can talk to customers, anybody can sketch screens, and anybody can go ask people what they like. This is the Building Blocks phase of proficiency; anybody can do them, but few do them well. Few do them with skill, proficiency, talent, and the right techniques, which I call the Science and Technique level of proficiency. 

While companies don’t understand UX, they often don’t understand who to hire. Thinking that UX is about “pretty screens,” they mostly hire artists and give them UX titles. But you now understand that UX and UI are separate, and that UX is more about psychology and human behavior. This means we’re often putting the wrong people into important jobs.

If a company doesn’t know how to assess a candidate’s UX portfolio, bring in a veteran UX expert as a consultant. I and others like me can look at a portfolio and know what people are doing, how they are doing it, and if they are a match to the open job. We can also tell from interviewing them. We don’t need to give them a challenge assignment, especially if we don’t know how to assess if that assignment has been done well or poorly. At best, interview challenges can only show how someone would guess at something if they had almost no time and couldn’t really use good process and techniques.

Also, remember that if your BA, product owner, or developer wouldn’t qualify to be hired in your company’s UX jobs, these same people shouldn’t be doing UX work. If it’s people over process, we have to care about which people do which parts of the process. “Getting it done” should be thrown away, and our mantra should be more about “getting it done well.” Let’s please bring quality back into our processes!

How can we apply agile and lean to UX?

The original definition of Lean was about reducing waste. This is more easily measurable when we improve worker efficiency, cut waste from processes, and reduce defects. Defects are anything our potential, trial, or paying customers see as broken, wrong, or not working. These go beyond software bugs. They can be the UX itself. The software might be functioning well, but the user’s workflow summons what I like to call “The Four Horsemen of Bad UX®.” 

The Four Horsemen of Bad UX® are frustration, confusion, disappointment, and distraction. We look for these in the user’s experience as we are architecting and designing, when we test with users, and at any point in the process when we are envisioning how our customer will interact with what we’re creating. How often have you worked on a project where you knew that you were going to release garbage to the customer? That’s not Agile or Lean. Why did we allow that project to continue, knowing users would surely meet The Four Horsemen of Bad UX? 

Lean is not the least we can do to move to the next step. When you took that brand new smartphone out of the box, did you imagine it was created by teams who did the least they could do to “just ship it” or “call it done”? Probably not! We must stick to the original definition of Lean, and focus on where we can identify and reduce waste. Ways that UX can make processes Leaner include:

• Great UX work reduces Engineering efficiency and waste. Gone are the days of Engineering burning time on rounds and rounds of guesses. They’ll be able to better estimate time and have fewer failed sprints when they are working from UX’s blueprints versus working from user stories or Today’s Ideas From That Highly-Paid Person.
• Great UX work means more rubber on the road for sprints, cutting waste from processes. How many story points would engineers like to spend on guessing how customer workflows should lay out and function? Best to leave that to a specialist for whom that is the rubber on the road of their job.
• If your software or system makes people feel frustrated, confused, disappointed, or distracted, don’t congr-Agile-ate yourself just yet. Your product has defects. How much time have we wasted on defects, rushed or untested designs, and releasing garbage we knew would summon The Four Horsemen of Bad UX? All of us must stop quietly accepting when this happens in our project. Speak up! Speak up against the defects we know we are in the process of creating.  

If our definitions of “done,” “working software,” or “good enough” were defined from the customer’s point of view and not stakeholders’ perspectives, our product releases would look very different. We wouldn’t continuously deploy garbage! We would use UX testing to determine if we have built the right features or product, and if not, we would take the time to improve it before forcing it on the public.

Agile is about fine-tuning a process to have a reliable cadence of productivity and quality. It’s not about driving engineers to work faster and faster. Agile Manifesto Principle #1 is: our highest priority is customer satisfaction. That means customer-centricity. Yet what do so many companies do? How often have you heard, “Just ship it, we’ll fix it later,” or, “Release it and people will just have to figure it out”? If you’re selfish for a moment, how often do you like to “just figure out” something that’s not intuitive? 

We must get back to taking the time for real customer-centricity, and trusting that a little extra time and money invested in getting this (more) right the first time pays off over and over. The main ways to achieve this include:

• Get a qualified UX professional on the Agile team. One UX architect is on each feature team. That breaks down silos and keeps people who don’t understand UX from trying to do our work. That helps keep everybody focused on the customer-centricity our marketing claims we care about. The UX architect can be the team’s connection to other roles including visual designers, copy writers, and researchers.
• This means inviting UX to all of the team’s meetings, both recurring and spontaneous. Include us in the showcase and retro. Invite us to the tools and software Engineering is using. Assign JIRA tickets to us when the issue is a UX issue. Now we’re collaborating.
• Agile Manifesto Principle #5: give UX workers the support they need and trust them to get their jobs done.
• UX should also be collaborators, directly involved in all levels of project planning and execution because...

Time estimation is the biggest problem when integrating UX processes into Agile

Imagine that someone is planning a project. What phases and tasks will UX do? How long do they need? On a high-performing team, each member would plan and estimate their own work. When projects and epics are planned, that teammate or their lead would be involved in planning and estimating on a larger scale.

What often happens at many companies is someone who does not work in UX guesses what UX will do, and underestimates how much time they need. I was once brought into a kickoff meeting for a project I hadn’t heard of before, and I was told that they needed final wireframes within 48 hours. This is a clear signal that this project doesn’t care about the user experience. The project manager told me that since drawing screens can take “a few hours,” she was being “generous” by giving me two days.

Since most teams don’t understand what UX does, the guessed estimates are way off. Somehow, nobody had the idea to ask UX what they plan to do and how long it will take. Too often, people who know very little about UX are guessing our tasks and how long we need. Without collaborating with us, they are often underestimating by days or weeks.

Even flavors of Agile get this way wrong. SAFe Agile (possibly the most UX-hostile flavor out there) has a page on their site about the Continuous Delivery Pipeline. On that page, they casually mention that feature definition takes four hours and “design” takes four hours. Sure, bad design takes four hours. If we care about quality, then we need to invest more time in good design. Agile Manifesto Principle #9 agrees!

Guessing UX’s time and resource needs often leads to conflict, culture issues, blame, or rushing out something UX didn’t get to fully work on. Next we’re pointing fingers. Get UX on the team and let them strategize their work at every level: portfolio, epic, program, project, feature, etc. Most senior level or higher UX practitioners are good at strategically selecting which tasks they need to do, and then estimating their time.

What steps can we take to integrate UX into development?

Step 1 is better understanding what UX is. Anyone who thinks that “UX is easy” or “anybody can do it” doesn’t understand UX and doesn’t respect it. Misunderstanding and disrespect between co-workers leads to problems with our process, collaboration, and culture. Step 1 is our foundation for building higher performing teams. I like to call it “becoming conversational in UX.” You don’t need to be fluent or try to learn how to do our jobs. But we should know enough about each other’s jobs and work to have mutual respect and understanding.

Step 2 is better understanding where various definitions of Agile and Lean work well with UX, versus where they have been bastardized, changed, or interpreted to exclude or minimize UX. Agile and Lean are constant works in progress, constant attempts towards improvement. Despite what some Agile coaches lament, neither Agile nor Lean have some sort of holy purity that will be ruined if we work more closely with UX.

These sound like “two simple steps,” but they’re not. They often require a lot of change within a company that has made a lot of mistakes, wasted a lot of money, and created a lot of defects while trying (or pretending) to be Agile and Lean. 

Measure what poor quality truly costs

Let’s imagine we have features A and B. They will be built by the same team, first A, then B. Imagine that A is released to the public, and now the team is working on B. Feedback starts coming in about feature A… customers are complaining, support is burdened with tickets, it’s not solving user problems, or it created user problems. We’ve all been there! What typically happens next is that this team has to delay feature B to rework feature A to solve the problems. Agile would demand it. 

This means time and money are spent figuring out what went wrong, fresh UX work to make improvements, testing, then over to Engineering for their dev, testing, etc. Feature A is finally re-released, patched, however your company does it. But what will your company document about the extra time and money spent to fix feature A?

• Does it get added to the budget for feature A, which will probably make feature A wildly over budget and possibly a failure (as a project)?
• Does it get added to feature B because the team was working on B, even though the work is related to A?
• Does it get hidden in some other budget C so that we don’t have to admit the mess feature A ended up being?

Cost of Poor Quality (COPQ) is a helpful Lean Six Sigma concept that addresses part of this situation. It reminds us that when we release something to the public that the public perceives as poor quality, there are expenses and consequences. Remember that to our customers, poor quality isn’t just software bugs. It’s also badly designed software. 

I don’t have to tell you about poor quality websites, apps, SaaS, and other systems. You’re surrounded by them. You’re already thinking of some of them while reading this! It’s harder to think of ones we love than ones that summon The Four Horsemen of Bad UX.

We have to do something to wake our companies up. They have been complacent about pretending to be Lean and Agile while being wasteful and not caring about quality. COPQ can help us by shining a spotlight on what most leaders in our company care about the most: money.

COPQ reminds us that when we hand garbage to our customers, we pay for it. There are internal costs associated with delays, support having to deal with complaints, analyzing what went wrong, UX rework, Engineering rework, other teammates’ rework, UX and Engineering re-testing, downtime, and morale. Workers are less loyal to companies than ever, and nobody wants to stay too long at a company that keeps handing customers garbage.

COPQ also notes external costs including creating bad will with customers, bad word-of-mouth, and even the environmental costs created by this waste.

Help the people at your company who control the money to see that without better UX, we are burning time, money, and customer satisfaction by releasing defective, frustrating software. 

The benefits of investing in user experience

There are a number of benefits investing in UX can bring to any company, team, or project. Here are six:

1. Improving customer satisfaction. We might not have a job if we don’t make customers happy. Remember when Yahoo made you happy? And then remember when you started leaving Yahoo services because you liked other ones better? Customers dream of shifting to better systems every day. If we do not prioritize customer value, we run the risk of our customer moving on or starting to dream of moving on. 
2. Reducing our COPQ by improving our quality. When we better understand our target customers, and we care about building the right product, UX is your fast, new R&D team researching, architecting, designing, testing, and iterating on everything we’ll release to customers. Instead of only calculating the time and money you will spend by adding highly-qualified UX practitioners to a process, estimate or calculate what you will save by being more customer-centric and reducing defects.
3. Assigning the right work to the right people. It makes as much sense to ask BA’s to do interaction design or for engineers to run contextual inquiry studies with customers as it does for me to do a little coding. I did some coding in 1979, but I’d never get a job as a dev. And chances are that neither your BA nor your engineers would qualify to get a UX job anywhere. Let’s stop giving specialized UX work to people who can’t do it well. There are no trophies for “done” when it was “done poorly” or “done wrong.” 
4. Improve efficiency and productivity. By giving UX work to UX pros, you’ll free up other roles to get more of their work done. Agile and Lean fanatics will love that! There will be more story points getting done during the week versus Engineering pausing their Engineering work to stab at UX work.
5. Predictive and proactive risk mitigation. Every company wants to be aware of risks and work to avoid them. Highly-qualified UX practitioners have processes they can put in place to prototype, test, measure, and iterate before Engineering writes lines of code. This should reduce the risks associated with having Engineering build, test, integrate, and launch features customers dislike. We can learn what the public thinks of something by investing in the UX process.
6. Improve culture. If you’re a fan of DevOps or you just happen to care about company or team culture, then let UX practitioners do their job. Give them trust, power, and the ability to make decisions in their own domain. Don’t overrule them unless absolutely necessary. Don’t give them a leftover crumb of time or budget. Don’t overprescribe requirements to remove their ability to build the best execution of the best concept for our target audiences. Help us all love our jobs!

For those wondering if this is worth it: if your digital or Agile transformation is worth it, improving your customer’s experiences is worth it. If you care about process and product quality, it’s worth it. It will take time and there will be bumps. But correctly integrating UX will help you become more Agile, Leaner, and find your teams fresh new ways to save time, money, and sanity.

About the Author

Debbie Levitt, CXO of Delta CX, has been a CX and UX strategist, designer, and trainer since the 1990s. She published two books in 2019: “DevOps ICU” for non-UX roles and “Delta CX” (for everybody). Learn more or get in touch at DeltaCX.com.