Designing for Complex UIs with Vitaly Friedman
===

[00:00:00] Hi, and welcome to PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams to improve user experience with session replay, error tracking, and product analytics. Try it for free at logrocket. com. Hey, everyone. I am Paige Niedringhaus. I am a staff software engineer for the IoT Startup Blues, and today we have Vitaly Friedman joining us.

Vitaly is here to cover his latest conference talk, which is designing for complex UIs. He's the founder and the editor in chief of SmashingMag, a UX lead and consultant and a speaker. Welcome to the show, Vitaly.

Well, it's my pleasure to be here. Thank you so much for having me, Paige.

We're very excited to have you here. So before we get into your talk, do you mind telling our listeners a little bit about yourself, your background, and your experience?

Oh, sure. . I've been doing many different things throughout my life. And I guess around 20 plus years ago, I [00:01:00] decided that I love the internet. That internet, the little thing that called the internet, I really fell in love with it.

And I actually loved flash. I'm sorry. I know that at this point, some people might turn off and decide that this is not for them, but I was really excited. And I wanted to do all of this for living. And so I got into this world of the web and then move between places, from front end to accessibility to you, to UX, to DevOps at some point and then back.

So it's been quite the journey. I have to say, I'm just a web master. I think this is pretty much still the thing that I'm doing 20 years later.

So somehow in between moving between different positions and different parts of the web, you also got into actually publishing content for the web, which is the smashing mag part. So how did you get into that from building websites and learning how the internet worked, basically?

To be honest I was a student and I needed the money. That's how it works most of the time. So I was freelancing at the time. And then [00:02:00] I was looking for anything as a freelancing, as a web developer, because I was deeply in love with PHP by then, 

but at that point I realized quickly that when I wanted to move into front end and explore CSS, HTML, JavaScript, and all that, I realized that there was basically no decent resource that I could rely on at the time. At least this is how it felt. So I started bookmarking things and then eventually just writing about them as a tool to understand them, to understand how these things are working together and so on.

And so this is how it evolved over time where we said that maybe it's a good idea to just put it all for everybody to see and to use. And this is how it all started back in 2006. And, 23 years later, still here, 

You're still at it. Absolutely. . So let's talk about your conference talk that you actually gave pretty recently which is about designing complex UIs, which if you've worked in any kind of a company, you've probably come across as a web developer.

So. Let's talk a little bit about the first thing, which is , [00:03:00] how do you define a complex environment? What is that, in your opinion, or your words? Okay.

Yeah, that's a very good question. I think in many ways, this is a combination of very different things that are just unknown to us. This is probably the easiest way to to think about it. Things seem to be complex when we don't understand them. That's pretty much it because it doesn't matter how complex something might appear at first.

Once you start digging into it, once you start playing with the interface, so once you start trying to make sense of the data of controls or filters or whatever it is that you have in front of you, at some point you create this sort of understanding. Doesn't matter how complex something is.

So complexity typically comes from the fact that we might not be fully aware of or not fully understand what we have in front of us. That's usually the result of having a lot of data. at your hands. Just a lot of data. This could be presented in very different ways, be it complex, like huge tables.

It could be data visualization. It could be maps. It could be any sort of [00:04:00] information presented in a very different way. Sometimes it comes from the fact that there's been kind of accumulation of technical debt over time. You just end up with an enormous legacy. And nobody really knows what is happening under the hood.

Nobody even wants to open that big box and see what's inside. And sometimes you end up with people who actually hold or held the keys to the tower to be able to make some changes they already left. And you don't even know how that entire thing operates or works. So I think that there are all those things that are often coming together.

With data, just to be a bit more specific, typically you also end up in a situation where it's not just the presentation of data, but making or creating understanding out of data, manipulating data, importing, exporting, I don't know, filtering, sorting, those kinds of things. And then sometimes you also need to be able to move data from one place to another.

and then merge with something else. And this is where chaos starts creeping in, and very [00:05:00] often these applications, all of them seem to be quite complex because they combine all of those factors in some way or the other. And this is where it can be very difficult for somebody just coming from outside, like me very often working with smaller, bigger companies, working in feels like, Oh, what is this in front of us?

This is a beast. And I have no idea where to start. And that's then often how I perceive things to be complex.

I'm nodding along as you're talking about legacy systems and people who have since left the company or the team. And taken all of that knowledge of how those systems worked or were built in that way with them. So yeah it can be an overwhelming and a daunting task.

So how can developers make this data more understandable? How can they make it less complex? And why is that often missing in UIs? 

I think the main reason is that this is maybe my personal opinion, but I think that in many ways when we think [00:06:00] about any sort of complexity, we try to think about tooling first. So I see a lot of teams thinking, okay, well, we'll have this really non functional dysfunctional search. This is just really not working.

So what do we do with it? Well, let's try another search engine because of course the market is evolving. The tooling is evolving and so on and so forth. So we're going to jump from solution A to solution B. As a result, usually nothing changes. If anything, things get worse. The reason for it is not because of the tooling it's mostly because of this structure or the shape of data.

Very often it's not structured or not properly structured. You might not have a proper metadata or maybe you just don't have enough. Categorization or some sort of a way of really having data in bright places at right times. And whenever you get flows of information coming from different places, they might be having different formatting in which they're coming in.

And there needs to be some cleansing happening, [00:07:00] which is happening, but then it can corrupt the data as well. And so this is where things are happening, which really in the end bring. Confusion at best or big mistakes at worst. And so what we probably need to be really careful about is how do we organize whatever content, whatever data we have in front of us, how do we structure it, how do we make it available?

How do we design our API endpoints to make it available to others? To not mix or at least keep data. Clean in one way or the other, because we don't know where this data will go and what it will be merged with or how it will be connected with something else. 

Um, 

And sometimes you will find a lot of different restrictions where as a result end users go along and they come to a form on the website and then they try to type in the full name, but then because of this limitations of us trying to be too clean, in what is stored in the database they type in the full name.

But then excellent characters are not getting approved because, you're not meeting the [00:08:00] requirements. And so this is always this balance. We need to give people pretty much the free space to basically type in whatever they feel is right, but at the same time keeping the data in order. I think that if we could find that balance, then we would be in a good place already.

So in your talk, you mentioned Tesler's law and the conservation of complexity. Could you elaborate a little bit on those two things?

Yeah. So I think in many ways, when we're looking into how things are working, the conservation of complexity basically means that whenever we're dealing with any sort of complex interface, and again, we could be, looking at things like healthcare or education or complex insurance. Companies and, things where they take and flowing from one direction to another.

There is this very common expectation, almost an instinct that many designers have when we start working on complex projects like that, that the best thing we could do is simplify, but this is also a very dangerous part [00:09:00] because very often the users, while the end users of those applications are expert users, they do not want simplification.

If anything, they want more features. They want to have more advanced ways to explore data or to edit things or, whatever it is that they do in the application. So the worst thing we could do is oversimplify because this literally removes value from those end users or those customers. And in fact, we cannot really simplify properly because again, we look at the.

A conservation of complexity, the law is pretty much saying that whenever we're looking at any complexity in any product, we can not just dissolve it in some way. We can not remove it. If something is complex, it will remain complex unless you remove features, unless you remove something that people might need.

So what we need to do there is. Maybe hide complexity at first, but then reveal complexity when needed. So there is absolutely no way to just, turn something that's inherently [00:10:00] complex because the world around us is complex into something that's simpler, the best thing we could do is to give people a few chunks that they can progressively disclose complexity.

That's something that you can manage and then create. UI that seems, well, usually experience in general, that seems to be simpler, but then it is still advanced enough for advanced people, advanced users to keep going and do whatever it is that they need to do. So this is what these two things are mean in terms of.

Complex systems or complex interfaces.

Yeah, so don't actually take away the ability to do those more complex tasks, just maybe hide it or keep it to the side until the users are actually ready to use it.

Yeah, absolutely. Or another thing that they could do, of course, depending on the type of users that you have, you might want to prioritize some features for some people, or maybe for example, some presses or filters for some people and then some others for others, it doesn't mean that you need to have different entry points.

[00:11:00] This is an entry point for users of, Oh, I don't know, frequent users and infrequent users and so on and so forth. But instead it means that maybe we could just bulk kind of group some filters based on what this group of users likes or needs, and this group of users and this group of users, they can go ahead and actually select whatever it is that they want selecting with a few buttons.

instead of selecting every individual filter every single time. So that's a way of hiding complexity while keeping it at the same time.

One of the things that you mentioned in addition to, making it less complex for any of our users are design KPIs. And that is something that I've actually never heard anybody discuss before. So how does someone go about creating design KPIs? How do you define them for a business and how do you actually measure something like that?

Actually, that's something that came up over the last couple of years from a projects where I was involved in. And it came from the need, [00:12:00] to explain and visualize the impact of design work. On business, because when you look around, actually, many teams will have their own KPIs or definitely business KPIs that they usually very much established.

And, you find your OCRs and all kinds of goals that different departments will have. But we never really spoke about design KPIs and how to measure design, because we often feel that design is this floor to everything. It's like a personal, almost artistic expression.

But. It shouldn't be, I think, because in the end, when we are designing anything, we're basically addressing a particular need, be it user need or business objective or business need. And so that means that we should be able to measure how well we're doing that. Just how well our design A makes that meets that objective or meets that user need versus design B that kind of does, tries to do the same thing.

[00:13:00] Yes.

that you see maybe sometimes, I don't know, five designers versus a hundred of developers in teams.

It's not because designers are at the heart of the organization. It's because this is one of the satellites that impacts business as well. So when it comes to design KPIs, I try to find a way to really define some metrics and which then flow into KPIs that will actually show or visualize the impact of my work.

Just to give a couple of ideas or examples here, there are typically five that I would always pick up, always use if I can. First, that would be the top task success rate. Meaning what are the tasks or the things that people are who are using a product, service an application? What are the most important ones?

What do they do most of the time, frequently or all the [00:14:00] time? Well, if they, if we know what things they're doing, we can also track how successful they are in completing those tasks. What is the failure rate for doing, I don't know, to importing portfolios in bulk on a financial visualization screener?

Are people successful 100 percent of the time? Probably not. That's rarely happens. 40 percent that's pretty bad. Maybe we should improve that so we can track for the top tasks that people are doing on the, on a site and application on the page, what they're doing and then how successful they are.

At the same time, the other thing you could measure is how much time they need on average to do that. It can be done differently. It could be qualitative testing where you bring in people and you run some usability study or the ability testing with them and give them some tasks and you see how much time they need to complete them and where they struggle.

Or it could be implemented on the level of the application where you're basically tracking the time needed when somebody starts a process and completes that process, right? So, for example, top down success rate. Okay. [00:15:00] Great. The same goes for the time on task. Great. But then another thing that could be helpful is how frequent errors are.

How often do errors occur? And any kind of errors, be it, filling in the web form or being zero results pages in search, right? Everything really. And then if errors do occur, how quickly and how often people actually recover from those errors. That would be then the fourth one and the last one that I like using just because it's really very close to a specific need of an application or product, it would be time to the first success.

So that means somebody goes through onboarding. Go through entire thing. And then eventually they're there to do something. how much time and how much effort do they need to put in to actually get to the first success, whatever that first success means. And so those KPIs is something that I would always try to establish and then track over time.

Probably, trying [00:16:00] to come up with, again, maybe 10, 12, 20 different tasks that people could be completing in usability testing and track just how successful they are, how often errors occur, and so on and so forth, continuously, maybe. Every four to six months,

it seems like that would actually probably work pretty well with whatever your team's already established KPIs or OKRs are, because you'll always be trying to build out new features or improve things for users anyway. 

Yeah, I think so. In many ways, it's just something that's really missing because very often it feels like we were working on a particular feature was suggesting maybe a particular improvement, but then we really need to be able to track the impact of that and how well. It really drives the goals that we actually want to drive.

So do you have any advice then for how to track these KPIs? Because I know a lot for websites, we have things like Google analytics and other analytics tracking software, but how should [00:17:00] designers keep track of their KPIs?

I think there was a, it was Jared Spool who wrote an article once where he said that there is no universal metric that will actually work for everything. So that's usually going to be a mix of different metrics. So I think in many ways I like to. Combine different metrics, depending on what the needs of the of the company applications are one of them, for example, would be search.

So if you have, let's say a task, improve search, how would we actually find the right metrics or KPIs in the end to measure the quality of search now, very often you would say, well. Search is maintained. The search engine is up to date and that's it. But this is not quite user centric. And if it was a design KPI, we would be doing it differently.

For example, we would say, okay, so we'll have search. Now let's take a look at how effective our searches. Let's take a look at all search queries that came our way. In last year, let's take a look at top hundred, maybe. And then let's go to our [00:18:00] experts in this domain in which we're operating, and let's ask them, working on that product and let's ask them.

So, what should appear in search when people are asking those queries? 

Mm 

And maybe you could give us two to three. Pages or views or whatever it is that we're having that should appear when people are searching for it. So they would give us a list. And in the end we end up with maybe two, 300 or else.

And then we just do a simple match. We just see, okay, well for the top 100 search queries, let's. Plug in the first one and let's see what are the results. And if we actually are getting anything from this expert select, select the curated results in the, search results. And usually you can generate a percentage out of that.

Just what is the overlap between the two? Very often in many organizations, the overlap will be less than 1%. And that's a really poor quality of search. And so we can drive it over time and try to improve it. And that would be again, another design KPI right there. And if you want to establish [00:19:00] something like that, well, first of all, you need to make sure that this KPI is getting a sign off because you cannot do everything alone.

So usually what I would do is creating the so called design KPI tree, where I try to connect the business needs of an organization with the design activities, the design initiatives.

Usually design initiatives are not coming out of thin air. We're brainstorming, coming up with an idea, which is going to impact something that's going to impact something that's going to hopefully impact something that's going to eventually, address that OKR that we have in front of us.

So let's visualize it. Let's write it down. Let's put it together in one place. And then once we have that, we get a sign in or sign off or buy in for it. And then we're distributing this kind of ownership across different parts of the organization. That might be a long process, but you don't have to do everything at once.

You can also do it slowly and then initiate some KPIs at some level. And then it's just propagating [00:20:00] and this can be, seriously, it can really not only seriously protect designers in or help them defend their design decisions. And explain their design decisions. But it also creates this shared understanding and alignment between everybody on boards, right?

What are we doing and why including business, PMs, developers, and whoever else is involved, that can be very powerful.

yeah, I've been in development teams before where. It almost seems like design is an afterthought, and even though they're advocating for something that probably would improve the user experience, things like time and development resources and just needing to get a feature out and go on to the next one often take precedence, so.

Like you say, having the ability to ladder back up to this is going to impact our OKR as a team and improve its potential for succeeding seems like a great thing for designers to be able to bring to the table [00:21:00] and have it their backs. Thanks. 

I think so. It's also a matter of. Who is going to be brought into this conversation? Because I think that design KPIs are in many ways also something that well, developers should participate in when shaping and defining, because once you define a particular, once you are thinking that, this design, this feature will be helping us to meet that goal or objective.

We desperately need feedback from people who are actually going to implement it later. Maybe there's this feature is beautiful on paper, but it's not viable giving our legacy. So this feedback, early feedback is actually very much needed. And then if we could also bring somebody from the business side to explain it, Oh, well, we can not dedicate this effort or this resources to this project at this time.

That's also very valuable. In the end, I'm trying to be very pragmatic. And see what we can do given the scope of the project and also given the budget and resources we have at our, in our hands.

, so one of the things that you talk about for designers is needing [00:22:00] to value content over navigation. So can you discuss a little bit more why the content needs to be prioritized and how that can be implemented into a design?

I think in many ways, when we're looking into content the main problem that we often have with it is that it's not properly structured and definitely not properly written. There is still a lot of I would say many issues around that. That are very much yet to be discovered, I think. The problem is that very often we end up creating very complex navigation structures, which rely on the fact that people are following a particular path and they understand how it works.

What I see is that very often people either go with search right away, or they would actually try to use navigation, but then they abandon it altogether. And if you have good content, eventually people will fall back to good old friend, Google trying to find it.

And so while I see a lot of people struggling a lot, [00:23:00] trying to find a better way to design better navigation very often you'd be much better off if you actually just go ahead and improve your metadata. , 

well, one thing that I really enjoyed from watching your talk was you showing off different navigations with hovers and disappearing, drop downs and menus and things like that. And I wanted to ask you, do you think that we should completely do away with hover menus? It seems like that's where you were going, but not 

yes, that's right. I think the issue is, well, if I have to be honest, I did see projects which are very successful when they were testing hover menu versus click menu. This is especially useful when you get a lot of navigation many, many different levels, and you want to expose all of them or most of them to users.

And that happens typically in e commerce sites, right? Where many categories need to be visualized and people need to be able to quickly navigate between all these different sections, right? But in most [00:24:00] applications. I've never seen a big benefit of having hover menus if anything, there is a big benefit of using click menus because it's just better for accessibility.

And if you have a hover menu, you still need to do something on mobile. So, you could just go ahead over the click menu and call it a day. In general, you will see people, especially if you have nested levels and nested menus, where you go from one. You hover over a menu, then the items show up.

You go hover over another one, another sub and the sub menu shows up. That's typically results in frustration because people tend to be very inaccurate in tapping, hovering and everything in between. So frankly, I would say, well, dear friends who are going to listen to this later, don't throw stones at me, but I would say, yeah, maybe we don't need hover menus anymore in 2023 or 2024.

Should we? Just, let's be a little bit lazier, maybe let's just have a click menu and then it will work on mobile well, it will work on desktop [00:25:00] as well, and you can code today.

Alright, so let's talk about another thing that you took issue with, which was breadcrumbs, and how breadcrumbs are in all different shapes and sizes and placements on the page, and probably are more confusing to users than they are useful.

Yes. So, breadcrumbs, I have a strong feelings for breadcrumbs, I know that some people don't share them, but I have very strong feelings for breadcrumbs. Typically they are very helpful, especially when people come to a particular page, let's say from search, right? That's very helpful because it indicates where they are in the hierarchy of the site, right?

The problem with breadcrumbs is that very often because we're relying on hover menus, you end up with some items that are disabled because there are no sections that represent some the kind of that represent where you currently are. So . You might be going to the homepage and then from that homepage, you hover over a menu.

Then another sub menu shows up and another sub menu shows [00:26:00] up. So you could potentially go from the homepage to level four, but then because those sub menu sections don't exist, you end up with disabled buttons or sorry, disabled breadcrumbs, which can be very confusing to people. They just don't understand it.

So I would say that breadcrumbs are helpful, but we can make them even more helpful. Because potentially, if you're looking at, let's say a sidebar navigation that usually takes quite a bit of space, you can actually comfortably turn simple breadcrumbs into something much more beautiful, where every single step in the breadcrumb could become a drop down of sorts, indicating all the neighbors of, or items that are living on the same level.

So it's very much like what you get in, I think it's Google Drive. That's pretty much this, where you go from one folder to another. But whenever you are in folder 5, let's say, level 5, you can always jump between the siblings of level 2 and 3 without having to go to level 2 first, which can be actually quite helpful.

So I think that [00:27:00] breadcrumbs are underdogs. We can do so much with them. And dear friends who are listening to this later, I would highly recommend you to go to the best website ever, which is the website of the Swiss Statistical Office in Zurich. It's 

Um, Mm 

ch. It's admin. ch. And, oh my, these are the best breadcrumbs in the world.

I would say so also another option, just, I have this really strange hobby where every single Friday I would pick a random topic and I would pick a random country and I would type it in and just see what kind of websites appear. 

You just pick a random website and then you go. I was spending quite a wonderful Friday exploring carousels in Turkish newspaper websites. That was an adventure, I have to say. This is way better than any horror movie can be. Trust me.

Well, let's talk about carousels, then. What kind of carousels did you see in these Turkish websites? 

Oh, this was a, I think in many ways, this is a, [00:28:00] if there was a museum of carousels, I'm sure that most of those websites would be there because sometimes you see the carousels with thumbnails. Sometimes it's vertical, sometimes it's horizontal and as it's with numbers, like one of the really confusing parts to me was while in our world, we're used to having carousels with dots in between.

So you have the first image and then you have dot in underneath. And you click on the dots and you go to the next slide, not in Turkey. This is not a thing in Turkey, by no means, at least not according to my research, because in Turkey, every single dot is replaced with the number you can reference.

So you can ask somebody, Hey, go to slide number 17. 

Mm. 

fact, there are usually carousels where you'll find 20 and more slices in the carousel, which you can go

through. So you can go to number 17. That's interesting. So that's that would be a very unusual pattern. I saw there, I would say, but overall if you think about [00:29:00] carousels, I would say the most important thing is to turn these dots into something that's more meaningful.

That would be either thumbnails or labels or plain text, turning them basically into tabs. That's infinitely more useful than just having lifeless dots.

Well, one thing that you mentioned or you showed when you were discussing carousels in the talk was that people don't tend to click through them. Everybody sees the first image that shows up and then immediately it drops off to very low levels of interaction beyond that. So if people aren't really interacting with carousels by and large, should we bother to have them?

Are they useful?

Well, that probably also depends on the use case, because if you think about the product pages or any websites that are selling an experience, I would say, if you think about booking a hotel room. For your trip or booking a vacation, really maybe this is what carousels work remarkably well, because if you want to highlight some features let's [00:30:00] say.

People want to see what the lobby is going to be like. They want to see what the swimming pool is like. They want to see what the breakfast is like. They want to see what the gym is like. So yes, this is actually quite common that in this kind of environments, where you want to sell something or you want to advertise something, this has a very high click through rate for the carousel.

But if you're, let's say, a university website. You should not expect people to click through the carousel because again, , there's probably nothing that entices them to do that. So I would say it heavily depends on the use case. Still in both cases, you will see a quite abrupt drop off after.

Second, third, fourth, fifth, it's just going to be a little bit more steady, maybe with e commerce, but it's really abrupt in many other environments. So should we be doing it or not? That depends probably on the case study, on the use case, what you have in front of you. But if you can show important things, you probably should, because [00:31:00] the worst thing you can do is actually hiding things that really matter.

That usually does not work well with anybody really.

Good advice, so we've talked a little bit about why carousels are iffy. But one thing that I've always wondered and that you touch on is where do the arrows go? Because people always want carousels, not just with the dots or the numbers or the whatever tabs underneath to help you navigate through them, but they want arrows. Where should we actually put these arrows for carousels?

Oh, yes, I have opinions on that, and I think that some people would disagree. The most important thing that we tested is that when we look at how many carousels are implemented, very often you will find arrows distributed across the carousel on the left edge and on the right edge, assuming that, well, like you go to the right, so you click on the right, you go to the left, you click on the left.

The problem is with that is that whenever people want to move back and forth, and this is actually quite common, [00:32:00] right? Because they first want to see what is available and then they want to choose , what of that is more relevant to them. They go back and forth quite a bit. But then every time they use these controls on the left and on the right, which are often vertically centered, you end up in a situation where you, your mobile, your thumb that you're probably going to, or index finger depending on the right,

Mm hmm. Mm hmm.

The arrow left or right, and then you will have to lift your finger in order to explore that content. And then if you want to keep navigating, you have to put a finger back on that sclera cell and then keep going left and right. That's usually just unnecessary and takes time. So if you group arrows instead, be it and, at the bottom right, for example, which is great, because again, that means that your thumb will never cover the content, right?

Then people can navigate left and right very much like they do with the remote control in TV. [00:33:00] If anybody's still using a TV, of course, at this point or joystick or anything like that, because they're close so you can navigate left and right quickly without covering the content that you want to consume, 

Mhm. 

is just a small little thing, right?

But if it avoids or reduces time that people need to spend on the carousel, well, then I probably would go for it. That's, it doesn't have any disadvantages and it's pretty much straight most straightforward thing ever on desktop. It would be different. Because on desktop, we usually cover a lot of space.

We we occupy a lot of space with a lot of content. So it is actually more common to find these arrows also grouped, but in the right upper corner. Not at the bottom of the carousel.

That makes a lot of sense and it seems like it would be easier to design for if you're just keeping the buttons grouped together wherever they might be on the page.

I think so. But again, I think that many designers, page designers have been very opinionated. And so I think that there will be people saying [00:34:00] no, they should be on the left and on the right. Well, that's just test. Let's just test and see in my personal experience, a grouping is always a good idea.

. Like you said, let the numbers dictate how users prefer their carousel arrows. . So another thing that you touched on was infinite scroll. Personally, I'm not a huge fan of it. I like to be able to find the bottom of a website as I'm scrolling, not have it continuously just load new products into it.

So how can we tame infinite scroll in your opinion? How can we make that experience better?

Yeah. Well, that's interesting that you're saying that. I think, I don't think that many people love infinite scroll, to be honest. I think that there is a big anti infinite scroll community in many ways, and there are good reasons for it from accessibility and performance to, the URL is always weird or wrong.

And yeah there are many reasons. I think it's interesting that Google, I think at this point, experimenting for the search results with infinite scroll and I think it's been live now for a week or maybe two. This may have been [00:35:00] longer I'm not quite sure. Which was a bit surprising to me because I've always been used to pagination instead.

The problem with pagination that you will find in many usability testing sessions is that people often experience pagination as being a very slow mode of interaction. 

Hmm. 

often feel like they need to click on number two, and then they need to wait for the page to load, and then they need to start exploring it.

And then they do the same for number three. It's not necessarily slow. It just feels like waiting. A little bit of waiting. When infinite scroll, you don't get that. But you have other problems, right? You have problems that people don't feel like they're in control of that infinite stream of data that comes their way.

And they often feel that they cannot reach the footer. That's another problem, but who needs the footer anyway? It's just somewhere out there especially with Google search results. And there are plenty of issues with accessibility as well. It's not very clear what the new segment of information that just comes in.

And what is the old that you have seen already, but you can fix it. Like all of those things you can fix. [00:36:00] I wouldn't answer the question, should you fix it or not? Infinite scroll, you can make it better, but it still can be an accessibility nightmare. But it requires a lot of work to get right.

So what you can do, and that would be very useful, and that's probably the first thing you could do, is to have a sticky footer. So that would give people access to the footer whenever they need. They can open it at any point. For screen reader users, they would also need to have a skip link to the footer, so they can jump in there or open it.

That's important. And then you have your footer whenever you need it, right? It just needs to be clear how to open it, right? So that works. The other thing you can do is to create the sense of bookmarking a location in that stream. That means as somebody starts scrolling down, well, at some point you could prompt the button or show the button saying, Hey you can continue here later, and that means that when they click on the button.

What you basically do is you keep the [00:37:00] information or stored information about what they have seen already with the sorting that they applied to it, right? So when they come back to the same page later, you need to show them, okay, so you have seen this already, right? You continue now, but then if of course there are, there is a lot of dynamically generated data that needs to be clearly visualized as well with an option also to see previous stream.

So bookmarking allocation and being able to get to it, or you can even simplify it more and say, you know what? So this is the, these are the parts that you have seen already. You can click on that link and it will open exactly that segment that you have seen in a separate page. And you can send it to your friend and colleague and so on and so forth.

So they can actually view the same part of that stream. That can be quite helpful too, right? So this also solved this problem of people not feeling like they're under, they have it under control. So that also is helpful, right? And overall, I [00:38:00] would say one thing that we shouldn't be forgetting when it comes to infinite scroll is that when people scroll, sometimes they would just think that, okay, I want to continue here later.

So keep in mind to adjust or refine or update, I would rather say, the URL as they keep scrolling. So if they do choose to copy paste and send it to somebody the other party isn't getting surprised of why they're seeing everything or something else or everything from the very start. So these three things can do magic when it comes to infinite scroll, but I wouldn't say that they're very straightforward to implement.

I was just gonna say, it sounds really good in theory but I'm even trying to imagine how I would have an infinite scroll and keep updating the URL, and it doesn't sound very easy to implement, just off the top of my head.

That's right. But you also find sometimes incredible implementations where lazy loading of those items in infinite scroll [00:39:00] and pagination are combined into one with infinite scroll. This is unbelievable. So basically as you scroll down at the bottom, you see this little pagination that gets updated as you scroll down.

So you can always click, let's say, to page eight, or even jump to page 13 or 27 if you really wanted to. Although I don't know a single person who wakes up in the morning and hopes to get to page 27 that morning. That usually doesn't happen, but you could. And then as you scroll, so pagination gets updated, URL gets updated, and it is infinite scroll.

So

That's

I'm sure it's not that straightforward to implement, but it solves infinite scroll problems. So if you want to build one, good luck. 

. So, are there any other patterns or systems that you might recommend that can help for complex navigation in particular?

Yeah, I would say that's probably one of the most important methodologies that we are applying. And I think methodology is actually more important than design patterns or kind of design systems in that case, [00:40:00] because in many ways, what I realized, I think over the last couple of years is that , I'm ending up spending a significant amount of time in spreadsheets and my notes and, any Excel, oh my God, Excel before I start designing a single pixel on the screen.

So in the past, it was much different. In the past, I would just jump in and think, okay, I think I know the world. I understand the world. I'm just going to iterate and explore and brainstorm right in a design tool of choice. But these days it's really more about the process before that. So I spent a lot of time elaborating or evolving ideas and then testing them with users.

For example, using tree testing or using again, top test methodologies. Anybody's interested, there is a wonderful book by Jerry McGovern on top tasks. The idea there being very simple, you identify the most important things that people do. Then you basically identify this big selection of tasks that people perform on the site and application.

Then you actually ask people to [00:41:00] prioritize them. Users, actual users and then group them and then you find names for them. And then once you have those names, they basically represent the new navigation that you're going to have. And then you go to users and you do tree testing where you basically give them a couple of tasks that they can perform by just saying, okay, you want to find information about X.

Where would you go in this new navigation? And they would give you a number. And then you give them maybe 40 tasks like this. And by the end you get a, you get an understanding about whether they, that navigation works or not. And it's only then when you went through all of it where you actually end up designing your drop downs or mega menus or fancy breadcrumbs or what not.

Because this is just an expression of a good navigation.

Okay. 

But if you do, let's say a couple of rounds of testing, you can get to 80 percent success rate with the new navigation before designing anything on the screen at all. This is just a regular UX information architecture work. That [00:42:00] might appear to be a bit boring to many designers.

I think including myself when I started, but I couldn't imagine jumping in design right away. Now that's just really changed my world view, 

well, Vitaly, it has been a pleasure speaking to you today. Is there anything that we haven't really talked about in when it comes to designing complex UIs that you'd like to touch on?

Well, I think the critical part is really not to oversimplify. I think this is a little bit of a dangerous part that I see many of my colleagues and myself, including in the beginning, doing, because we have this instinct to make the world better. And that's a good instinct. I totally appreciate the instinct, but this also has a danger of really removing value from a product.

And the reason for it is I think that we don't know everything about everything, right? And very often we end up in very complex domains, which are. Really messy and really complex and [00:43:00] evolved processes and people that are really difficult to understand even for expert users.

So the only thing that we need, and this is something I would always argue for is to spend enough time in user research in any sort of UX research, if you can do UX research, if you can ask for more UX research, this will help you to solve the problem. We need to know how to solve it first.

And of course, 

we need to know what the problem is, and then we will figure out how to solve it.

That's great advice. So, if people want to get in touch with you, if they want to learn more about how to design complex UIs or just talk about their own complex UIs, how can they reach you?

Well, I'm here online, right? I live on the internet. I was told it's a pretty cool thing. 20 years ago. I still very much believe that it's true. You can find me on LinkedIn. Usually I post there almost well, very regularly. Also write articles on smashing magazine. We also have a new video course where you'll find a lot of stuff around complex [00:44:00] design patterns.

That would be smart interface design patterns. Maybe that would also be in the notes later. There's also a little blog right there where I try to put all the frustrations around UX and how to make things a bit better every now and again. So, I think, and I would love to be connecting with you.

So if anybody's listening to it, I would love to connect and explore and share. This is always fun. The more complex, boring enterprising and corporate your experience is the better. I love those kinds of conversations.

Well, that is excellent. We will be sure to link to all of those in the show notes and thank you once again for joining us. This has been a great conversation.

Thank you so much for having me page. Always a pleasure.