User-Centered Answers

UX Researcher Marta Cuciurean-Zapan spoke with Writer Jess Sattell about the relationship between social science and design thinking, how a user-centered approach to building software gives products competitive advantages and what makes Uptake’s approach unique.

At Uptake, just as our product is cross-discipline, so is our team. UX Researcher Marta Cuciurean-Zapan spoke with Writer Jess Sattell about the relationship between social science and design thinking, how a user-centered approach to building software gives products competitive advantages and what makes Uptake’s approach unique.
 
Jess Sattell: Let’s start by defining “UX.”
 
Marta Cuciurean-Zapan: Do you have a definition in mind when you think of it?

See how Uptake Created $160,000 in Potential Value Per Locomotive Per Year for a Leading Class-1 Railroad

I tend to think of it in emotive, communicative terms, and with the lens of design thinking. That is, all of the decisions that go into making a product or an experience the most effortless and comfortable to use. And it involves knowing who your user is, down to the bottom line.
 
Absolutely. UX also creates a real sense of purpose for a company and for a team. If you’re user-centered, you have that touchstone. It’s not about your own personal feelings or emotions; it’s about making your product the best that it can be, and being your own critic. If you don’t step back and unemotionally critique and iterate on your product, then the market will critique it, and that’s a much harsher reality.

Emotive, visual and intuitive are all parts of it, but I’d add that when we’re in as complex of a space as we are at Uptake, when our subject matter is often about things breaking down—that’s not necessarily a pleasant experience. But it’s one where other criteria, such as trust and augmented decision-making, come to the front, which provide confidence in a predictive analytics platform.

UX and user experience or user-centeredness are related, but not quite the same thing. What’s the difference?

It comes up in a number of ways. The Uptake team has both researchers and designers who work closely together, and the designers break out across interaction design, product design and front-end development. These are all skill sets that tend to get conflated the further away you get from the discipline, but I think it’s an important distinction to make because of the value that everyone provides. You can’t just do UX research and not do the design part—they live hand-in-hand. Both researchers and designers think about that end experience, but they approach how they input and output that knowledge in different ways.

Another piece is the difference between UX and being user-centered. UX, along with its counterpart UI, user interaction, is often associated with deliverables: use cases, wireframes, clickable prototypes, user flows and so on. That’s certainly an aspect of it, but again, you have to think about what those deliverables are for. They’re not deliverables for deliverables’ sake, or artifacts for just the sake of having them. They’re tools. We want to think of deliverables as a set of possible tools to get the outcomes we want.

When you think about being user-centered, you think about the “why” behind the “what.”

How do you get to that “why” from the “what”?

You need to keep some of the challenges of conflating UX and UI with UX and explicit user needs alone in mind. For example, let’s say I ask you, Jess, “what would you like this tool to do for you?” And you would answer, “when I click on it, I need to see everything because I want to make sure I’m accomplishing my tasks for the day.” I certainly take that into account, and advocate for that, but then I go a little bit further. I ask myself, “why does Jess want to see that?”

So, I ask you, and then I look at your workday, the tools you have on your desk. Maybe you have a notepad by your computer. If I’m lucky enough to shadow you for a day, I see your interactions and what they’re like, I look for non-verbal cues like emotion and body language. I realize that I wouldn’t need to make something that shows you everything at once, like you explicitly said, but that it’s important for you to not miss anything. That’s responding to the “why” behind the “what,” and then providing a series of options.

You can make your best hypothesis based on aggregating all of your sources of user data, and then you try it out. In this context, it can take the form of a wireframe, or a prototype, or even a flow that you run by the user. Then you iterate on that, ensuring that you’re responding to the problem space that you’ve defined through the user-centered approach of “I don’t want to miss anything.” That’s how you avoid the issue of building something for an explicit request of “I want to see everything” that would result in a non-optimal user experience and ultimately detract from your product or prevent its potential adoption.

It’s essential that in whatever you’re building, you ensure that it’s responding to the right problems. You might build the greatest piece of software in a vacuum, but if you haven’t taken into account what the actual problems and needs of your target end user are, then no one is going to buy it, and no one is going to make any money.
 
How does Uptake’s UX research help industry?
 
We look across time, across users and across industries for key patterns that can inform a platform so that all can benefit. What we find might be qualitative, but it’s not anecdotal in the sense that you rigorously look for patterns and outliers, and themes, and then you synthesize it all. What does it mean for our users? What do our industries need? And how does all of that play into what we’re building? That takes really close work between UX researchers and designers, product managers and engineers, among other teams. Everyone needs to have an understanding about what the users want.

We’re building the company, the team, and the practice of being user-centered, and we’re co-creating with our partners to build great things that they or their customers would need. And we make sure that we’re not pre-defining the solutions without defining the users.

For example, we recently spent a day at a railroad maintenance shop, and we interviewed and shadowed potential users of our platform in order to observe and really dig into how they do their jobs, the general flow of their workday, the kinds of tools they’re using—really looking at how they spend their day in order to develop software in a direction that is most useful and useable to them. It’s not about replicating what they currently use; it’s about understanding how they currently do things in order to provide them with a tool that is the best it can possibly be at addressing their day-to-day challenges.

It’s about providing value to people with all sorts of difficult jobs, and how we can augment their decisions and help them do their jobs more easily, confidently or effectively.