Q&A

Q&A with Debbie Levitt on UX Research and Design

• By David Ramel
• 03/24/2023

User experience expert Debbie Levitt provided some saucy answers about an upcoming Visual Studio Live! presentation with an even saucier title: Fast Focus: WTF UX - UX Research and Design AMA.

Levitt -- who has been a UX strategist, researcher and designer for decades -- is sure to share some thought-provoking insights in a 20-minute ask-me-anything presentation in May in Nashville, where she will provide free advice on topics that might include:

• Is UX Big Design Up Front?
• Can UX be Agile?
• Why did my Designer do this crappy thing?
• Can I do UX work if we don't have enough Researchers?

"Whatever you ask is what we'll be talking about," she said in promising the audience will learn about working smarter and better with UX and "UX... WTF?"

To learn more about UX design and research and her presentation, we caught up with Levitt, who has earned the nickname "Mary Poppins" from clients because she flies in, improves everything she can, sings a few songs and flies away to her next adventure. We don't know about the singing, but the AMA is sure to be entertaining while being informative.

VisualStudioMagazine: So, in an ask-me-anything presentation on UX research and design, what kinds of questions do you expect to come up?
Levitt: I expect to hear a lot of "UX isn't Agile" and "why do we need these people?" I expect to hear that "Big Design Up Front" is bad, though I might ask that person why it's so bad, and if they prefer the design after Engineering codes and releases. 😊

Are team UX concerns usually related to staffing or processes?
Whether you're asking what Engineering's concerns are or what UX's concerns are, I would say both and beyond. UX teams and departments always want more headcount so that one UX practitioner isn't stretched across multiple product areas or Agile teams. Engineers often don't understand what UX even does, so they wonder why UX can't do more with less. They seem to forget that Engineering rarely wants to do more with less; if Engineering were a bottleneck, they'd hire! UX needs to also.

Processes are a much longer conversation. Remember that Agile wasn't invented for UX or Design. It was an attempt to make Engineering more efficient by (and this is greatly oversimplified) breaking work into smaller pieces and releasing software to people more frequently than we used to. But the assumption is that Engineering is starting with designs that are ready to go, or someone is going to slap together any old screen that seems to meet requirements. Which opens so many more questions about the quality of our solutions and ideas.

How about some quick answers to example questions: Is UX "big design" up front?
Sure! Since the dawn of time, design has come before building. In nearly every area outside of software, we model and test things first. We model and test cars and parachutes before they go to the public. Design comes first. If you fired all of your UX experts, design would still come first. It would probably just be more guessed at than having experts do it. It would be like the old days when developers spent time laying out screens based on requirements documents.

Someone who wanted to disempower UX came up with "Big Design Up Front," which is a shame.

If 10 Engineers want 2-4 sprints to do something, you don't hear UX calling this "Big Bloated Engineering Keeping Us From Finishing This." You see what I mean. Misunderstanding what UX's jobs are is a tough start. Picking on people (whose jobs you might not understand) for trying to take the time to produce quality (when our company claims to want quality) is just a morale killer and a crappy culture.

Can UX be Agile?
Are Agile teams Agile? 😊 I so rarely see Agile implemented well in companies. Perhaps Agile should look in the mirror first! But again, Agile wasn't invented for UX, so it seems strange to take an Engineering approach and try to superimpose it on another domain. Do we care if BAs or PMs are Agile? Should Marketing be Agile? What would that mean or look like?

Similarly, should we hold Engineers to HCD (Human-Centered Design) standards? This is the main process UX uses (or should use). It's included in ISO 9001 and has its own set of standards in ISO 9241. Should we hold Engineering to UX's standards for UX work? If not, should we hold UX to Engineering's standards for Engineering's work?

Ultimately, the best way to get UX to work more quickly (which is what most people really want when they say they want UX to be "Agile") is to hire way more UX professionals. At many companies, teams have zero UX professionals or a fraction of a person. Where I used to work, I was often split across 3 projects at the same time. I'm suggesting that 5 UX professionals work on every product team: 2 Architects (what you think of as a Designer) and 3 Researchers. That's the core team. There are others in the UX multiverse who will be on projects more part-time.

We do this at my company now, and we're fantastically efficient. I can also estimate a project that runs weeks or months, and not be late a day. We did a retro today for the CX/UX team. Someone might even say I'm Agile! 😊

If it's Agile to have 6-10 Engineers working on something for weeks (or longer), then it's Agile for 5 UX pros to work on something for weeks or longer. Hire qualified pros when you have a UX bottleneck!

How does a team do UX work if they don't have enough researchers?
We're only as good as the evidence and data that we have. When companies don't invest in researchers, we have little or no evidence. This normally leaves teams guessing, assuming, and working from opinions and personal preferences. This creates a mountain of risk for our project and product. What are the chances that we guess correctly exactly what our customers need?

Agilists often think that UX work just needs to get done, and the quality doesn't matter. Or we'll learn if we created anything decent weeks or months after we release it. If we had good qualitative research, especially early generative research, we wouldn't work from opinions or guesses. We wouldn't hold workshops where we guess how to solve a guessed-at problem, and call that empathy.

Without good research, UX Designers are left guessing what to do. UX is highly strategic and scientific. We want to guess as little as possible. You would want us to guess as little as possible. But yet, project after project wants minimally viable UX work just to check a box that it was "done." We need to focus on quality and doing things well.

Have you seen inroads being made in bridging the traditional developer/designer divide?
Yes, but for a bad reason. Years ago, companies were very Engineering-dominated. Engineering had a lot of power and UX was on the bottom of that ladder. Now, Product seems to have all the power. Engineering and UX are now together in an often-disempowered place. That has reduced some of the conflict between Engineering and UX, but mostly because we are focused on a common pseudo-enemy disempowering the rest of us.

The swing now is to be "product-led," but I mostly see a lot of product guessing. That might be product-led, but I suggest that we be value-led: how much value can we frequently create for our users and customers. That should match what's at the core of Agile. Hopefully devs and designers can team up, and push for quality code for quality solutions.

What are a couple techniques that teams can use to work smarter and better with UX?
My main advice is to start by understanding what UX and HCD are. UX is a scientific discipline based on psychology and behavior. It's not artsy-fartsy. If it is at your company, you either hired the wrong people, or you're giving them the wrong work. Great UX pros are problem finders and solvers.

Include UX in early planning. Focus on user-centricity and customer-centricity. Building a stakeholder's idea might be "lower conflict," but if we don't make customers happy, we might not have jobs next quarter. UX are your risk identification and mitigation team. We deliver customer intelligence and the evidence the whole team needs to make better decisions. Shift away from guesses and assumptions. Stop making excuses like "we'll fix it later." If it needs fixing, we don't release it.

Let's shift to quality over speed. There is nothing in Agile that says you should never do a little more work up front to save you from mistakes and problems later. Agile and Lean would want to see you making smarter decisions and avoiding rework later.