UX design

Designing data science

Tips for streamlining your UX process — from the Red Hat OpenShift Data Science team design lead

Katie Edwards

Published in

PatternFly

12 min readMay 22

Artificial intelligence (AI) and machine learning are rapidly becoming critical for businesses. From automating customer interactions to mapping the growth of crops to maximize food production, many organizations are beginning to see the benefits that AI and data technology can bring to the table. But what about the people who create the faces of these AI tools and software?

At the forefront of this technology are their user interfaces and the user experience teams behind them. But UX teams don’t only create an easy-to-use home base for powerful technology — they also ensure the entire user flow is streamlined, cohesive, and only includes the capabilities that users actually want and need.

Kyle Walker, the lead Interaction Designer on the Red Hat OpenShift Data Science (RHODS) user experience team, detailed his experience leading the creation of the face and functionality of RHODS — specifically, the inclusion of a pipeline functionality that current users have been requesting.

So, what does the UX process look like, and how do visual and interaction designers, researchers, and content designers work together to make decisions about technology on which they’re not subject matter experts?

Who makes up the RHODS UX team?

Kyle Walker: At the moment, we have 2 interaction designers. We’re responsible for different sections of RHODS and focusing on different areas that we’re designing. Then, we have a content designer as well as a researcher. The UX researcher’s a little bit more part-time, and we interface with him as needed. When we need to hear from our users or get second opinions on decisions, he helps us set up interviews and carry out surveys. The content designer we work more closely with.

Okay, but what is RHODS?

Red Hat OpenShift Data Science is an AI platform offering based on the open source Open Data Hub (ODH) project. Data scientists and developers can rapidly develop, train, test, and iterate ML/DL models with full support, allowing them to focus on their modeling and application development without waiting for infrastructure provisioning.

But what does that mean in plain language?

Kyle Walker: RHODS is a platform that allows data scientists to do their work. They can create models and train them all on a Kubernetes platform — OpenShift. That means that they can expand and contract their workloads as needed, as opposed to doing it all from their own computer or in a set server. You can use as many resources as you want when you’re using Kubernetes as the backend.

As we continue to develop, we’re expanding capabilities to be able to do more than just the model training part — we’re now adding model serving and pipelines capabilities.

Model serving is based around the idea that once you create a model, you need to be able to use it elsewhere. So you do all the work as a data scientist to train it and make sure it’s giving you the data that you want after intaking the data that you fed it. Ideally, you want to be able to use that in production, or somewhere else — like another app. So serving that model is essentially putting it somewhere and creating an API so that other applications can access it. Whether that’s in a production environment or pre-production environment, we’re making it possible to do that.

Current UX work: data science pipelines

In simple words, a pipeline in data science is “a set of actions which changes the raw (and confusing) data from various sources (surveys, feedbacks, list of purchases, votes, etc.), to an understandable format so that we can store it and use it for analysis.” — mprerna802, GeeksforGeeks.org

Kyle Walker: The pipelines feature that we’re working on now is allowing data scientists to do experimentation on the models that they’re training. So pipelines in the data science context are a way to run what you’ve created in your notebook, your model, in a bunch of different ways and with a few different variables to see how it works and to make sure that you’re fine tuning and getting the right information.

And we’ll be adding new features in the future to be able to do other things as well for data scientists. (And other people that are in the data science, AI/ML world. So, data engineers, machine learning engineers, and the admins of those people.)

Open Data Hub (ODH) vs. Red Hat OpenShift Data Science

Kyle Walker: ODH is the upstream project that RHODS is based on. ODH is a community project, so anybody can add anything and it can be as big as the community wants to make it. With RHODS, we’re picking and choosing the features from ODH that we think, 1; our customers want, and 2; fit a cohesive vision and end-to-end flow for data scientists and those developing AI and ML models.

What is your role, and how does it fit into the overall team?

Kyle Walker: I am the lead UX Designer, or lead interaction designer, depending on the day and who I’m talking to. I’ve been working on RHODS the longest, so I have a little bit more background knowledge, but I think everybody else is catching up pretty quickly, which is great. It’s my job to understand everything that’s happening in RHODS, and talk to all of the different people and teams.

So I make sure that we are coordinated in what we’re doing from a design standpoint, and that it matches what the engineering team and product management are trying to accomplish. Along with working in the projects view and pipelines area and figuring out who should be doing what work, I have to make sure we’re focused on features that our customers actually want and need.

Next, we have Vince, who’s the other designer. He is focused on a lot of model-serving design work right now and adding some of those features to the UI. So I have the general focus, and Vince is doing all of the model monitoring and model serving. We’re adding a lot of those features over the next year too.

It’s also my job to make sure I’m talking to Katie, our content designer, and Marc, the UX researcher, at the right times to make sure that they’re plugged into what’s going on in the team. And we are asking them in a timely manner for the help that we need, from their specialties.

The content designer helps ensure all of the content within the UI is consistent, correct, and easily understandable. Our researcher helps us test the usability of the UI by running surveys, user interviews, etc. Being able to predict what kind of content and research assistance we need is important because they both work cross functionally, and need more of a heads-up than members of the team that only work on RHODS.

Identifying design priorities as a team

UX teams can be faced with a challenge. Design priorities often come straight from product management — but product management doesn’t always have the insight that makes for great user flows and experiences. So, how do you balance business requirements with good UX?

Kyle Walker: We work with product management to figure out what things they want to add to the UI that will need UX work, and how much work that will take. However, design requests and updates often come from engineering as well. So we’re all working off of the larger roadmap that product management has created.

Sometimes we will think something doesn’t require much UX work, but then once development gets to it, they realize that we need a lot more UX work than was expected. Sometimes they’ll notice inconsistencies within a flow, or missing functionality — things like that. So we’ll work with engineering to figure out solutions to those problems too.

Then, ideally, there is a larger view as well that we are always paying attention to and trying to keep an eye on from a UX standpoint. Product management has a lot of contact with customers and they provide a lot of valuable feedback, but we also want to make sure that we are focused on the vision of the whole product. We don’t want the product to look like, you know, a bunch of features smashed together. We may want to add this new feature over here, and this other new feature over there, but it can’t look or feel like 3 different things. It should all look and feel cohesive. And so for UX and planning priorities, that is the largest part of what we’re doing.

What has the process looked like so far for pipelines?

Kyle Walker: It was probably about a year ago when we first said, “okay, we need to have pipelines”. Pipelines were a requirement raised by PM, but they identified it because our users need pipelines for 2 reasons.

First of all, we want to meet our users’ expectations. A lot of our functionality is backed in the background by Kubeflow, and Kubeflow has a pipelines capability within it. So we want to make sure that we’re giving our users the capabilities that they would expect from the underlying technologies that we’re using.

The second reason is functionality. We need to provide solutions that match our users’ existing workflow, and Data Scientists need pipelines to be able to do their experiments and develop their models in a good way. That’s a feature that our customers have been asking for and that is expected of an end-to-end data science solution.

Like I said, about a year ago we identified it as a priority and I started doing research on what exactly pipelines were — because I didn’t know anything about it. That started with just a Google search. What are the different types of data science pipelines, what do they do, and what are the pipelines that we need to implement?

That was difficult because pipelines are an idea that also exist in the app development space. There are Openshift pipelines, Tecton pipelines, and a million other variations. So I had to first understand what all of that was and take a look at what those tools look like. OpenShift pipelines and Kubeflow pipelines were the ones that I focused on the most because that’s the technology we’re using.

From there, there were ups and downs because there were a lot of other requirements that needed to get done first. We had to pause pipeline work for a while and make sure that we were getting designs done for other aspects of the product as well.

Then, we took feedback from the research so that we could have a better understanding around, “What if we’re using the Kubeflow pipelines functionality? What do we need to take from that to make it a cohesive experience?” We looked at the requirements that PM created, making sure that we are putting those into different pages and screens within our view, to make sense of how you create, edit, view, and update pipelines.

What has been the most frustrating part of the overall design process?

Kyle Walker: I think we all work together pretty well, so we work through our issues pretty quickly and are able to resolve them fast.

Often, the biggest issues are around how much work needs to get done. Can we get it done in the time that we want to get it done? There’s a lot of back and forth between project management and engineering and UX about, “Okay. What’s coming up next? What work do we need to get done in order to make the feature? Can the engineering, UI, and front-end development teams do what they need to do, and how does that fit in with what product management wants?”

I’d summarize the biggest frustration as the difficulty balancing getting the feature out fast, with getting the feature to the right level of usability. When it’s something small you can improve in increments. And we’ll improve larger features incrementally too, but there is a basic level of functionality you need to have for it to work out-of-the-box that takes time to do right.

Looking back, is there anything about the design process that you would do differently now?

As with many UX teams, the nature of working on RHODS is that there are always a lot of cooks in the kitchen, and they’re always working on new recipes. Making sure that all of those dishes work together in the end is the biggest challenge, and requires a lot of active communication and good time management.

Kyle Walker: There were definitely some hiccups along the way, and it would be nice to figure out how to avoid them.

We have a meeting every week where a bunch of stakeholders get together to discuss the current design topics. These are the UX designers, engineers, architects, and people that interface with customers. All of us join to talk about what we’re working on, if there are any questions around it, and show off our designs and get feedback.

Those meetings are helpful, but were also the source of a lot of headaches. There were more than a few instances where I demoed a mockup for pipelines, and somebody said “That’s wrong.” Not wrong because I designed it badly, but wrong because something had changed about the PM requirements or the back end process. In these cases, I was unaware of those changes before I presented or created my mockups — and it would be great to be able to prevent those issues.

How exactly to prevent it is another question, because requirements change as you’re working, especially if you’re designing at the same time that backend engineering is researching requirements and development is happening on the engineering side. It can be difficult to anticipate those but figuring out a way to prevent that in the future would be great.

That said, these hiccups make for exciting meetings.

How did this project make you a better designer, and what lessons are you carrying forward?

Kyle Walker: I think it certainly made me better at taking criticism!

I think working on this project has definitely made me focus more on making sure I’m planning for the time it takes for all of this work to get done ahead of time. Some of it’s out of our control, as I mentioned earlier, but we definitely could have gotten the timing better. It’s good to take into account how much all of the “little things” add up and disrupt the bigger picture and overall plan. Now, I’m more realistic about timing, and factor in all of the inevitable disruptions.

More on the team

One of the most important factors that helps the RHODS team work well together is their ability to focus on a shared goal and put personal feelings aside when necessary. When an entire team is genuinely invested in the success of the product, everyone is open and willing to participate in conversations — whether their opinion is a popular one or not, and whether the timing is perfect or not. Encouraging team members to reserve time during meetings for feedback on their work, as well as allowing them to set their own deadlines around set milestones, are two ways that the RHODS team cultivates a feedback-centered and positive work environment.

Kyle Walker: This is probably the most exciting project or product I’ve ever been on in my career. I love being in an exciting and quickly expanding area of technology, and the team is really great to work with. I mentioned our weekly meetings, and they really are awesomely fun. Probably too much fun.

It’s hard to say exactly why the team works so well together, and I have been thinking about it a lot. I started the meeting, but I don’t know how much I have to do with making it as fun and exciting as it is. I mostly just manage the agenda and let people talk. I think it’s a lot to do with the people, certainly, and we’re all excited to be working on technology that is new and interesting. I would say the most important part of helping a team work well together is respecting everyone’s opinion. At least in relation to design, everyone has experience using a product, so all input is valid and can be useful.