UX Designers & Data Scientists: United in Job Misery?

Does this look like you at work, trying to do the UX/data science job you were hired to do?

Are you one of those people saying, “My org doesn’t support me doing my work. They don’t want to give us the time or the budget we need to do things properly. They hired me to do ____ and I just want to do my job!”

What goes in the blank?

Well, candidly: I hear this from UX professionals and I hear it from data scientists too. I’ve heard this from secondhand/intermediaries before, and I’ve read similar inferences in Kaggle surveys and the like. Data scientists who are tired of standing up pipelines, dealing with over-inflated expectations, not having clear problems to work on, “no data” to work with, lack of resources/budget, assumptions that POC models can immediately be deployed to production, and the like. UX professionals who “can’t get the time/resources to do research,” only have time to “make things look pretty after it’s too late,” can’t do any “user testing,” are not valued because engineering is using “Agile,” and the like.

I find this quite interesting both groups share common struggles. Two observations initially come to mind:

1. If you’re managing these people, you should really consider why you have staff that are begging to produce better value for your organization or team, and yet you’re either in their way, or your not supporting them. It’s possible you don’t fully understand their work, and perhaps need to give them a chance to drive value.
2. If you’re one of the people saying the quote above, then maybe you’re too focused on your problems, your domain issues, your “lingo,” and YOU. Ultimately, it’s not about you if you’re in a service business, service group, or building a product — stuff that serves others.

What should you do if you’re #2? Here are a few options:

1. Quit and find a place that already cares and values your work and doesn’t need to be sold on it. or,
2. The harder path, but perhaps the more fulfilling one, is being able to stay, influence, and create the change that needs to happen

So how do you approach making the change? Some of these likely won’t work for you, or will rub you the wrong way, but they’re all options:

1. Ask forgiveness, then permission. Proceed as far as you can with the steps you can do, and try to show some value early, so that when you hit a wall, you can bring your boss or stakeholder “along with you” for the rest of the ride. If they can see the value potential, their more likely to support you. I realize you can’t “make a budget appear” out of nowhere, but you could, for example, paint a picture of what a lack of investment might cost the business.
2. Find the people in charge of innovation at your organization. Develop a relationship and ally there. See if you can approach the problem w/ their help, influence, or guidance. They may also know how to help you negotiate with the right people.
3. Really important: stop talking about your own domain, your language, your issues, and your process. Focus on the downstream outcomes, getting agreement on the desired outcomes, and how you’ll measure progress along the way. Note: you may have to relax your expectations and you may not get to do everything “the right way” the way that company down the street that you admire does everything.
4. Focus on identifying and executing SMALL WINS, where a “win” is in the eye of the customer/user/stakeholder. This is an important distinction: “following the process” perfectly may be a “win” for you, but if colleagues or stakeholders don’t see what is in it for them, they simply will not care. Assume that a lot of the stuff you care about may just sound “slow and expensive.” So don’t talk about that, until somebody is ready to listen to it.
5. Be open to being “wrong.” You may be shoveling your process or way of doing things into a setting that isn’t appropriate. Maybe the biz needs a dashboard TOMORROW. So, if you’re a designer, go DESIGN one with your best guess. The answer shouldn’t be “we can’t do anything until we talk to 10 customers.” That’s too late. Help the stakeholder make progress on the immediate pain. If they want “better,” then that’s your doorway to opening a conversation about “how I can help de-risk this project and increase the value and chance we don’t build the wrong thing.” The key point here: your “guess” may be good enough to help alleviate the current need/challenge. (Remember the small win we talked about?)

Customers and stakeholders of data products, analytics, or decision support apps/solutions rarely care which cloud service or streaming platform you use, how many lines of SQL, Python, or application code you use, the model you chose, the UX process or framework you used, and the like.

“I love taking rides with Uber because they did usability testing.”
Nope. They “love it” because the traveling experience is good. How the app was made is irrelevant to the riders.

​“I love Google Translate because they use machine learning.”
Nope. They like it because people like me can talk to my father-in-law in Poland when I travel there-without my wife to assist.

An empathetic approach that puts the customer and stakeholders first focuses you to envision solutions that are “good” forms the basis of trust, confidence, and likely, some more runway for you to run the next project “the way it should be done.”

So, get out there, and try to show a small win-sooner than later. When you start putting the “them” first, the lights will go on, and things will likely get easier. If not, well, maybe it is time to quit and take the adventure elsewhere!

Photo by FuYong Hua on Unsplash

Originally published at https://designingforanalytics.com on April 29, 2020. My name is Brian T. O’Neill, and I help product management and data leaders turn analytics and ML into indispensable decision support applications. For weekly Insights on how create more useful, usable, human-centered data products, you can join my Insights mailing list and get Experiencing Data podcast updates at https://designingforanalytics.com/list .