Can UX solve software performance issues? Spoiler: Yes, we can!

Alessandro Contini at UXDX Community: Innovation, Performance and Branding. Video: https://youtu.be/izaPbNR1bzs

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Can UX solve software performance issues?

[00:00:00] Okay, great, thank you. Today I tried to answer this question: can UX solve software performance issues? And I guess you know the answer already, because I added a spoiler to the title of this presentation. Yes, of course UX can solve technical issues, but the question then is how? What I really want to do today is share with you a product story that will not only touch on the great success achieved by my team, the Red Hat UX team, but also on how we managed to get to it, maybe in a way that some might find a little unconventional.

[00:00:46] Without any further ado, let's dive right in and do the important talking first. Here you can see what we achieved in a nutshell. We managed to reduce page loading time on the homepage of one of our products by 96%, which is a pretty awesome result and not something you would hear of every day. In the chart you can see that we were able to reduce this page loading time to 1.5 seconds on our latest release, as opposed to a much longer time that it would take to load that page on previous releases, or that it actually took.

[00:01:22] But wait a moment, you might wonder what this has to do with design, and how we managed to do all of that. That's a question I've asked in a couple of previous presentations that I gave on this topic, and I got a bunch of interesting answers, starting with the most common solutions that you would think of to solve performance issues, like you refactored the code, you improved caching, you removed dependencies. Maybe some more interesting, creative ones, like you refreshed the UI, you redesigned the information architecture, or you sold your soul to the devil. And yeah, we considered selling our soul to the devil, but he looked pretty busy already. So we actually redesigned the information architecture instead.

[00:02:16] Now, you might not be too familiar with this term, information architecture, but don't worry, I'll get to that in a few slides. For now we can just say that it's one of the disciplines of user experience design. Which brings me straight into my next point, that despite what many people think, user experience and user interface, UX and UI, are not exactly the same thing. And so now I'll spend the rest of this talk to prove it to you.

Where it all started: a customer case

[00:02:50] But I promised you a story, so let's go back to where it all started. You might remember the good old days when we used to go to this place called the office. Actually, this group of people in the picture is not us, it's not my team, but it resembles one of the most common office scenarios. Try to picture this. I was there at the office with my coffee, checking my email in the morning, recently hired and assigned to a new product team. And so I overhear this conversation about a recent customer case that was open, where the issue was that it took very long to load our product's homepage.

[00:03:35] I listen carefully and then I do what everyone at the office does. I get closer and I just throw around my personal recommendation. Hey, why don't we paginate everything on that homepage and reduce the API calls to the back end? And if you remember about the office, then you should also remember what happens next in these kinds of situations. Basically everyone just goes back to their desk. That's what I did too, because other priorities were waiting for me. So I just went back to my to-do list and left the engineer dealing with it, really.

[00:04:15] Talking about the customer case, here is an extract from that customer case, a screenshot that I took. As you can tell, the customer was not very happy. You see how I put it together here: I decided to put it up on the wall virtually, in a golden frame, because I felt like this is one to remember. The reason is this is an important sign that things have changed. More and more, when users are complaining about something, they finally know what it is that they want and they know how to call it: a better user experience. That strikes me more every day.

The product: API management

[00:05:04] Back to our customer. Let me maybe just spend two slides, I swear no longer than a minute, to give you some technical and contextual information here. The product I'm talking about is an API management service, and it was acquired by Red Hat in 2016. After the acquisition, more enterprise customers started using the product. So different customer base equals different needs. This specific new customer is a high-profile customer from the public transportation sector. They're of course offering a public service and so they're looking for a pretty solid solution. For that reason, the customer is running a series of stress tests of their infrastructure and of the service itself. They're trying to integrate 150 APIs here.

[00:06:00] But wait a moment, maybe you're wondering what is this API management thing I've been talking about. I really don't have the time to deep dive into technical details today, but maybe I can spend 30 seconds trying to frame this. Let's put it this way. I'm pretty sure you have some kind of maps app on your phone. Most probably the maps app is also giving you some more info than just maps, such as public transportation info and updates. What happens there is that the maps app doesn't have the data. Most likely it's leveraging external data published by, let's say, the local public transportation authority. An API is what basically makes it possible for that data to be surfaced in the app.

[00:06:50] Now imagine that you are the public transportation authority. You do want third parties to display your data, but you don't want to receive zillions of calls per second to your system, which would basically kill your servers. So you want to protect from attacks and only have authorized requests getting through, and that's what an API management tool can do for you, among other things that I don't have the time to dive into. So the kind of UX and UI challenges we'll be discussing today are the ones that some company who wants to manage their APIs is facing, like the customer that I was mentioning a moment ago.

What the UI looked like, and why it was slow

[00:07:33] Back to our customer case. Here is what the product UI looked like when many APIs had been integrated into our system. Nothing too fancy, a very functional dashboard UI, the kind of UI that gets the job done, which is honestly what our users want most of the time. No fuss, no frills. You have a minimal navigation menu at the top that includes a filter to find your API. And then, scrolling down the page, you have the upper half of the page that's taken by this widget that displays customer engagement. Below, you'll find a list of all your integrated APIs, each with their own details and traffic data points, kind of like an API preview.

[00:08:20] There's nothing wrong with it really, until you scroll below the fold and you notice that if you had integrated a lot of APIs, they're all listed there, and each and any of those APIs would have a preview that would send multiple requests to the back end. So more requests, more time to process them. It's maybe a pretty good user experience when you only have a handful of them, but probably not really the best user experience when you're scaling up to processing, say, hundreds of them, like our customer was trying to do.

[00:08:57] And so the engineering team is on it. They really try it all to fix the issue. They follow a few of the approaches that we mentioned at the beginning, such as code optimization, caching improvement and so on. They do actually improve page loading time a little bit, but not significantly. At this point a few weeks have passed, and here is when the customer writes that comment I showed you earlier.

[00:09:30] Now, I have to be fair. This GIF doesn't give the right credit to our engineers. We have an awesome engineering team, I love them. It's just that this is basically what happens when you're prompted with an impossible ask. At that point no code optimization could have solved the issue that we were facing. And so the ball is passed to UXD, aka us. Again, to avoid any misunderstandings, I swear this is not what the PM said, but we knew for sure we didn't have room to plan any full-on design research study. We had to act very quickly.

Asking for data, and the first attempt

[00:10:11] So what do you expect designers to do when they jump on board? They ask for data, and that's what we decided to do. First thing, we asked for telemetry data. At this point the engineers had created a mock environment and they were now testing our platform against a thousand APIs, because that's a good reference number for larger enterprise customers. As you can see here from the screenshots of the browser data, it turned out it would take more than 40 seconds to load the dashboard, aka the homepage of our product, which meant no good news for us.

[00:11:00] We had to act quickly, I told you that already, and we take a first stab at it. We do that by doing what everybody would probably expect: we try to patch it, which for us means we just try to rework the UI. As a first iteration, we paginate the table. But as happens very often, I would say, with UX work, we realize pretty soon that it's not as easy as it seems. Paginating the table actually improved the performance a little bit, but it deteriorated the user experience, because it made it harder to access the full catalog of APIs. Also, maybe you remember that I just mentioned that as part of the navigation menu we had an API filter, and so that was still loading the entire list of APIs in the menu. So we didn't really solve the problem here.

Defining design goals and redesigning the information architecture

[00:12:02] So we decided to step back. We get together and we decide to define what our design goals are. We decided we want to first create a homepage that's a dashboard and not a hybrid between a dashboard and a navigation tool, which is what the homepage looked like, because it included the list of all your APIs. As a consequence of that we also want to simplify the navigation, of course, and we want to help users understand the logic behind the application, the platform architecture and all the various components. Last but not least, we'd love at that point to establish a pattern that we could reuse to fix other known scalability issues across the UI.

[00:12:57] To do that, we go back to an idea that was shared a few months prior to that, and that would involve redesigning the information architecture of the product. Now we're back to information architecture here. In case you're new to this, information architecture is basically where the information is displayed and how it is organized across the UI. You can see in the screenshot here that we were prototyping a low fidelity version of an alternative menu, and that's how we really started all of our design process.

[00:13:34] Let me now show you the outcome of our design iterations and give you maybe a little demo. Here is the new information architecture that we designed. We basically decided to move the exploration of APIs into two distinct sections, and out of the main navigation menu. You see that there are two new items in the menu, one for products and one for backend APIs. Maybe that terminology doesn't make much sense for you, but those are two different kinds of API objects, so we had one for each specific API object.

[00:14:21] You can easily reach them from the menu, and that would lead you to the paginated full list of APIs that you see here in the screenshot. Of course that table will be filterable, searchable and so on. Then we identified the most important API details that we wanted to surface in the table, and also decided to keep the shortcuts for pro users who wanted to access specific API features right away without going through the API overview page and so on.

[00:14:54] And back to our infamous homepage dashboard. We finally turned that into what is the first step towards being a real dashboard. Not there yet, but in the process. We do that by first removing the list of all the APIs and creating two widgets that you see here. The upper half of the page is unchanged, the audience widget is still there, but below there are these two new widgets listing the five most used APIs for each kind of API, together with direct calls to action to either create new APIs or explore the full list of APIs, by leading you to those sections that I showed you a couple of slides ago. And yeah, that's it in a nutshell.

The outcomes

[00:15:44] In terms of outcomes, this is actually the fun part. In a few weeks we basically generate all the design artifacts, we hand them over to the engineering team, who implements them rather quickly really, because we are leveraging our PatternFly design system. And so then we ask them to repeat the tests. Here we are with our success numbers. As you can clearly see, on version 2.5, which is the version that the customer was currently on at that point, it took 44 seconds to load 1,024 APIs. It was a little bit faster with the latest stable release, with 2.9, but still unacceptable. And with our better release it took only 1.5 seconds, which is definitely an acceptable time. Which brings me back to the first slide I showed you, where we can see that there was basically an improvement of 96%.

[00:16:58] But let me maybe take a moment to recap exactly what happened there, and share with you a little bit more of our process. We first asked for telemetry data, so collected the data, and then, well, first quick iteration, but then we defined what our design goals were. Only when that was done we started designing and iterating on our prototypes, and when those were ready we implemented and repeated the tests and collected more data and restarted with the process. This is probably not rocket science for most of you, especially if you are used to standard design thinking practices, but maybe this is something new for your stakeholders to try. It was in our case, at least.

Lessons learned

[00:18:03] As a matter of fact there are a few lessons that we learned as a team, and when I say as a team I mean as a product team. So let's see if I have convinced you of the powers of UX here, because this is really just one of the many success stories that the UXD team can share. It's not that my team was any special. This is the kind of challenge we face every day with our work as UX designers. But despite that, I guess that they are not always prioritized as they should be, and as a consequence we very often don't get a chance to work on them. So yeah, let's jump into the lessons that we learned.

[00:18:51] Starting with, as we mentioned in the beginning, UX is more than UI, and UX can actively contribute to solving technical problems. As much as this looks pretty straightforward, it is not a trivial one. Which brings me to the second lesson that we learned: backing UX work with data validates the effort in the eye of the business unit and the engineering team. In fact, we were able to kick off a second round of UI scalability improvements across the entire UI this time.

[00:19:30] And most importantly, as a product team we modified our project workflow on Jira, so that most issues, after being defined by the PM, are now reviewed by the UX team before moving them over to the engineering column. I guess you're familiar with some kind of ticket management tool. We do have the PM defined column, then it gets into UX review, and then eventually gets into ready for engineering. By doing that, by reviewing those technical issues together with engineering, there's a good chance that UXD can now spot opportunities for improvements pretty early in the process, and eventually propose solutions before even one line of code is being written, which is pretty good.

[00:20:24] Third lesson, last but not least for sure. At the time we had just put on hold, mostly for lack of prioritization and resources, a project for the overhaul of the UI, basically just to make it consistent with the newer version of our PatternFly design system. And so we took this opportunity instead to introduce all new components from the latest version of the design system little by little, when adding new UI elements to the new pages that we were creating, which is something that's still in progress too. So we're changing the UI not all at once, but changing little things here and there.

Recommendations you can take home

[00:21:17] I always love when I can take home a few action items after attending a talk, and here are just a few of my recommendations that you might want to consider adopting in your day-to-day. Maybe this one is a little bit obvious, but still worth repeating: always try to have design involved from day one. How do you do that? We just talked about modifying the product workflow. That's actually a good thing you might want to try, but that might not be enough, or maybe it's too soon for you and your team.

[00:21:51] So I would say if you're a PM, just invite your designers to business unit and road map meetings. Give them space. It's really as simple as that, just make them part of the conversation. If you're a designer instead, I would say try to identify who the right stakeholders are, PM, directors and so on, and ask to get invited to their meetings. You join the meeting, you stay quiet and absorb knowledge, and then when you spot a design opportunity you add an agenda item to the next meeting agenda, that you want to discuss that. When the day of the meeting comes you make a proposal, you illustrate the design opportunity you have identified, and you call out what kind of business improvement it will bring to the product.

[00:22:45] I understand that might not be your cup of tea, but you do have allies with that. Just try to involve the engineers you're already working with as soon as possible. You know them, they know you. For once, maybe instead of inviting them to a meeting where you're sharing design requirements, book them for an open conversation and ask them about issues at the technical level that are related to the design opportunity that you have identified. And also ask them, back them if necessary, to capture tangible data that you can then share with your stakeholders.

[00:23:29] Last recommendation, last but not least again: you should really strive to stick to low fidelity and get constant feedback from stakeholders and peers, engineering included of course. A proposal for a new feature doesn't need a drop shadow on your tables to be understood. It's probably more useful to show user flows and then just a makeshift idea of a UI. Especially, I would say, if your product team is leveraging a design system, then you don't even need to clarify every single detail. The engineer can pick up your low-fi wireframes, start coding the backbone, and then apply design system components on top of it. This will for sure save you time and probably frustration too.

[00:24:22] For instance, and this might need a separate talk really, but let me just touch on this: as a long-term consequence of the project I just walked you through, we also created a low fidelity library of our own design system, and it's been a success on the UXD team. So now we're always going through wireframing first, low fidelity wireframing first, before, and trying to get feedback based on that.

[00:24:51] All right, we are at the end of the presentation. I just wanted to take the opportunity here to underline that this success was only possible thanks to more colleagues, our product team. Here you see the mandatory head shots, or yeah, team picture. You have designers, engineers, managers and PMs all together. And more importantly, I just touched on a lot of different aspects of the project here, because we only have a certain amount of time. But if you want to learn more, first, you're always welcome to contact me. Second, we wrote an article that we published on the Red Hat official blog, and that includes a lot more details about the story. Here you can find a link to it, and maybe I can share it with Rory so he can paste it in the respective chats or channels. So yeah, this is it. Thank you for listening. I'll be happy to take any questions now, and as usual, feel free to connect with me on LinkedIn.

Q&A

[00:26:10] Rory: Excellent, thank you very much, Alessandro. That was really interesting. I love the case study approach. I just have one or two questions that I've thought of as we've been going through that, but if anybody has any questions out there, please feel free. You can either put them in the chat box on UXDX or, if you're watching on YouTube, LinkedIn, wherever you're watching it from, please just enter the questions that you have there. But the first thing that I thought of as you were going through your presentation: did you have any negative feedback from the low usage people, that the redesign made things a little bit more difficult? Or was it generally seen as a positive thing?

[00:26:58] Alessandro: It was seen as a positive thing. That's a good question. I mostly focus on quantitative data. I showed you how we improved the experience by showing you, in terms of percentage, how long did it take for the page to load after we brought our design changes. That's because we don't really have clear qualitative insights that we can share. We got them, but they're very hard to quote, because we don't have, unfortunately, a direct connection with the customers. The support team has a direct connection with the customers, and so I really begged them to give me that sentence that I wanted to put there. But in general both the customer itself and other users, like internal users and other customers, were pleasantly surprised by the changes in the information architecture. So it worked.

[00:28:10] Rory: Excellent. Yeah, I guess if it's down to 1.5 seconds they're probably seeing it. Even if you're low usage you're probably seeing a performance boost as well.

[00:28:20] Rory: You mentioned doing some informal chats and trying to bring engineers into design, bring design into engineering. But is there a risk, if it's not formalized, that it just comes down into the engineers: this is a performance problem, okay, we don't even need to talk to the designers because this is performance. So is there a way of trying to make it a bit more formal, that yes, we get everybody involved, instead of relying on more of the hoping people bring each other in?

[00:28:57] Alessandro: Yeah, my takeaway with the project is that the way to make this process a little bit more formal is to show what can be done. And in order to show what can be done, what can be achieved, you want to do it talking the same lingo, and so you show data, you show real tangible improvement. That is our experience. Before being able to formalize that, we did it informally first, and then we showed the results, and then we were able to say hey, maybe this could be our standard way of doing things. So my suggestion is start informally if your team is not used to these kinds of practices, and then bring tangible results to get buy-in and turn it into a more formal process that then you will just embrace as a larger, wider product team.

[00:30:11] Rory: Excellent. Well, thank you very much for sharing your case study. I found it really interesting, and it is incredible to see that data, the drop in load times, because that's quite a significant drop. So thank you, Alessandro, for sharing.

[00:30:30] Alessandro: Yeah, thank you for inviting me. It was a pleasure.