Designing for the Mind: Using Cognitive Load to Measure UX Effectiveness

I I might just start with I I guess this is a metaphor or a mechanism to explain some of what we're talking about today. So this is probably a familiar scene to to most of you. So you're, you know, you're on your way home from work. What's Friday today? Maybe you're on the way home from a conference.

It's a it's been a busy day, a busy week, and there's a bit there's a bit going on. There's a bit happening in the scene. So you might there's headlights everywhere. You know, there's really bright things that are darting back and forth. Again, been a long day and just wanting to get home. So you have the radio playing.

So, no, that that's a nice thing to do. It can be a bit boring driving home. It's a bit monotonous. You've been you've been that way a bunch of times, so it's, you know, it's nice to have some some music playing. The headlights are still there. You know, you're steering, operating the pedals, hopefully, if you're driving correctly, but there there's a bit going on.

It starts to rain. So it does that annoying thing where you're just trying to get somewhere, and inevitably, you know, it starts pouring down. So you have the rain coming down. It's pretty heavy. So the the wipers are doing the whole wiping thing. The headlights are still darting back and forth. Cars coming through across streets.

The radio is still going, and hopefully, you're still doing the steering and pedaling things so you can actually make your way home. The GPS is speaking. So you you're at a conference like today, so you're not you're you're taking a bit of a different route maybe, and you're not not quite sure how to get back. So the GPS is going.

It's it's doing that thing where it pauses and stops the music when it's saying, Well, turn right here. Go left there. So on and so forth. Still raining. The rain hasn't really stopped. The wipers are still going. Headlights are still there, and you're hopefully still steering and pedaling. Traffic's pretty heavy, so everyone it was a very popular conference.

Everyone was trying to get home at the same time. But it's still raining, the headlight thing's still happening, the radio's still playing, and the GPS is still nattering away. And then a message arrives. It's that thing when you're on your way home on a Friday, and it's your it's your boss telling you, you forgot you forgot this thing. It's a report or a spreadsheet or something that you that you haven't quite finished up.

So you sort of glance over to the the the information panel on your on your car, And, yeah, you sort of see what the message is, pauses the music, it pauses the GPS, but it's still raining, the headlights are still there, so on and so forth. So this leads to a question. So you you need to concentrate on your driving.

So what what would you do in this scenario to allow you to better concentrate on on your driving or any ideas? The radio? Okay. So let me get this clicker working. Here we go. So you turn off the radio. Surprise to to these folk over here. So you make the world quieter, but that doesn't really make sense in some ways, doesn't it?

So it's it's a fascinating phenomenon that we we choose to turn off the radio. So in that scene, we had what do we have? The traffic, the rain, the steering peddly thing, so on and so forth. There was there was a lot going on, but as humans, we choose to remove something from working memory. So there's lots of things we could choose to remove.

We can't really stop the rain or the traffic. I guess we could stop steering or manipulating the pedals. That that that would be bad. The radio seems pretty easy. So switching off the radio is is maybe the no brainer in that scenario. But this is this is something that we all innately do, and I I think something that most of us or folks who drive experience all the time.

You know, there's sort of a wild thing happening, and you'll switch down the radio. And that's that's us intuitively reducing the number of items in working memory, and that's what Cordelia and I are talking about today, this idea of cognitive load theory, which relates to working memory, and how we we as good designers, hopefully design around that and make experiences that conform to the ideals of cognitive load.

So this is the concept of the ideal or the idea that the brain has limits and that interfaces compete for cognition. And so this is where we we recognize that human limits exist and we we all intuitively understand that. But when cognitive demand increases, humans begin simplifying the the experience.

They might simplify information analysis. Their the rate of error might increase. So there's a number of negative things that might happen once limits of cognition begin to reach or be maximized or overflow, and that's something that we'll touch on in this presentation.

But importantly, us as designers and people who are interested in user experience and user interface, there there needs to be a recognition that the human brain does have have limits, particularly working memory. There are limits around working memory. And as I mentioned there, negative things can happen once we hit that limit. As in the the scenario or the metaphor that I talked about then, there was there was opportunity to switch off something that was taking up an item in in working memory, but we don't always have the opportunity to do that as users of products or user interfaces. So us as designers, we need to be cognizant of that and work around that for users because, of course, between humans, levels of working memory differs.

We all hear about that magic number seven plus or minus two. That's I I think as we all know, that's very hotly debated in terms of working memory and capacity. But but, of course, as designers, we need to be cognizant of of working memory and design around it. That brings us to the the title of our talk, which is about designing for the mind.

I I'm my name is doctor Ben Shelton. I have a research background and work as a as a professional member of staff at the University of Newcastle. And I have my colleague here, Cordelia Prangley, who's a user user experience and service design specialist in in the team. So this is about how we can think about cognitive load theory.

So a theory that comes from the field of psychology and how us as hopefully good designers can can take that theory and use it to mold and meld our interfaces and experience and services that we offer our customers to hopefully offer experience that are human centered and that don't lead users to a state of cognitive overload, which we'll we'll we'll touch on shortly, just what what cognitive overload is, how users get to a place or a point of cognitive overload, and how, hopefully, as good designers, we can we can avoid that and steer them down a different path.

Well, I hand over to you Yeah. Cordelia, we're gonna touch on some of the complexity around modern systems, and what that means, within with within what is a noisy world.

Fantastic. Thank you so much, Ben. As you mentioned, modern digital environments continuously compete for high attention. Notifications, dashboards, messaging platforms, AI copilots, alerts, and fragmented workflows are all competing simultaneously, and this brings us to cognitive load theory. Most interfaces today are designed for functionality and engagement.

Far fewer are designed around human cognitive limits. So what exactly is cognitive load theory?

Okay. So I've talked a little bit about this and how it its origins and and where it's come from. So this is a a theory that's been around for a number of decades now, so coming from the the field of psychology. My background, and I guess my interest in this, came from human computer interaction. That's that's the field that I work in from a from a research perspective.

And this is, I I guess, one of the attributes of human behavior that we can we can think about and be cognizant of when we're we're designing interfaces. So cognitive load, it's not it's not a general term, and I I I've got some content on this in a in a couple of slides' time, where I think we we all hear about cognitive load or cognitive load theory in the context of service design or user experience, but there is a background to it.

And at its core, it relates to working memory, the number of items that someone can store in working memory at any given time, and how that relates to their performance. So there's this this idea of overload, and we'll touch on that in a few slides time. So before I leap into that, I might just talk about and this is this is almost textbook style information, so I won't I I won't go into great detail on this.

But the the three types of cognitive load, Siri, and I think as us as designers or folks interested in design, how we can be aware of each of them. And I'll just start by saying not all cognitive load is bad. There's this idea of intrinsic cognitive load, which is in somehow, in some ways, inherent. We can't always design around this, but we need to be aware of it.

This relates to the complexity of the task itself. So this is the doing of the tasks. So, of course, there's tasks that we as humans naturally find easy, and others not so much. So, you know, low intrinsic cognitive load, maybe that's doing something simple that we do all the time. So there's this idea of schemer acquisition as a concept in psychology also, where you and we're all familiar with this.

Of course, if you do something repetitively, get better at it. But, you know, the example here is something like filing your tax returns. We we don't do that all that often, hopefully. And there there's, of course, intrinsic load related to that. This idea of extraneous reload load. So this is probably the the one for us that we need to be most aware of.

So this is cognitive effort caused by poor design. So this is something that we can hopefully control. So this might be a cluttered or confusing interface. And again, if we think about cognitive load, it relates to memory. So if this is an interface where you have to you have to remember something between screens or you have to hold a piece of information and move it between parts of the application, or if the user feels lost or it's not clear where they are.

And there's this idea of germane load, which load that supports learning. So working at a university, this is interesting to us. And you can see the core of cognitive load theory comes from learning sciences, and that's where it started. So and early on in the the research here was about, instructional design. So this is about load that supports learning.

So this might be helpful guidance or visualization as someone's moving through an application or a piece of learning. So load's not inherently bad. So we'd call something like germane load good. Extraneous load is in some ways clearly bad. It's something that we can control and be on top of as designers. And I view intrinsic load really as somewhere in between.

So I touched on this a few slides ago. This is my me sort of getting up on my soapbox in in some ways that we hear about cognitive load all the time as folks who are interested in user experience, UI design, so on and so forth. So I'll start by saying it's not a it's not a general term.

It doesn't describe a general annoyance or frustration with a thing or a product or a service or an application, so on and so forth. So what cognitive load is, is you can hear me, I've been rabbiting on about memory and demand, so it relates core to memory, relates to information processing burden, so the effort required to encode and process information effectively and hopefully quickly relates to the allocation of attention. So we can see that back in the car driving example.

We were we were choosing to allocate attention to, well, hopefully, the road and not the radio. That becomes important in the in the driving scenario. There there there is some consequence if overload happens. If overload happens when you're, you know, manipulating a spreadsheet, maybe it's a bit of a so what thing.

You you might make an error or your app your information analysis might become simplified. But if you're if you're flying an airplane or something, if overload happens, it's obviously catastrophic. And it relates to the mental load during task execution. So so that's what it is. It's not always a symptom for bad user experience or, I I guess, a general term or a general descriptor of frustration from the user. They a user might not always report frustration when they're as their load's increasing. Doesn't really or doesn't always relate to visual complexity.

It, of course, can, but that's not always the the cause of the symptom. Doesn't relate to general discomfort or emotional stress alone. So it is the concept is much more complicated than that. So I've talked about overload a little bit through the presentation, and the way I like to describe it is to use this this cup filling up metaphor.

So like in the driving scenario, we have this this vessel, and it's continually filling with items in memory. So I've I've sort of bucketed this into three categories here. So we have optimal capacity where we're focusing within or we're operating within our cognitive limits, and then something happens.

So something gets added to memory, the cup begins to fill. So we approach our capacity, and then we get to this point of overload. So this is when the cup's overflowing. And when the cup begins to overflow, we see a number of negative effects, which again, as designers, will hopefully be aware of and avoid. So again, it depends what the user is doing if this matters. But of course, we want our users to be satisfied and happy and our customers to return to our applications, and they perhaps won't do that if they're reaching the point of cognitive overload.

Again, if we develop systems for transport or for aviation, so on and so forth, the effects there are much greater. But of course, it still relates to products that are used every day. So we might see things like reduced attention, so important information getting missed because, again, we're overflowing, memory's overflowing, and we're having to reject things from working memory.

We might see increased errors. Again, may not matter depending on the application, but, of course, that can be frustrating for for a user and for and for the where wherever the error error is landing. If it's a you know, you're working on a spreadsheet for your boss, hopefully, there's limited errors. Slower decisions. So I I guess back to the car example, there there's lots going on there.

So your decisioning may be slower. And, of course, in that scenario, that's not all that ideal. I've mentioned simplification of information analysis a couple of times now, and that's that's really a classic example or sign of of cognitive overload. Reduced recall. So, again, this is a concept that relates to memory and cognitive fatigue also.

Cool.

Thanks, Ben. So good design protects cognitive capacity, and great info interfaces reduce unnecessary demand on working memory. They help users stay orientated, focused, and confident. But how do we know when this is happening? So interfaces do more than just display information.

They shape cognitive effort, and every interaction either supports cognition or competes with it. Our challenge as designers is to design around inevitable complexity. It's always gonna be there. So how do we make it manageable, and how do we help our users retain control? There's some ways in which we can achieve this across UI, UX, and service design. So the UI design, visual clarity, information hierarchy, scannability, and attention guidance are all very important here.

In UX, we wanna think more about the process. So reducing cognitive load could be considered in the interaction flow. So reducing the number of steps in tasks and supporting decisions with clear options and feedback. And finally, in service design, this can look like a journey of continuity, cross system coherence, and reducing handoffs. If cognitive load influences interface effectiveness, how can we actually measure it?

So there's a few ways we can measure workload. So there's three categories typically. If we were to pick up the academic literature, these are these are the three that we would see. So there are self reported measures, what we call physiological measures, and then performance based measures. So I'll just touch on each of these three briefly because I think, again, as folks interested in UX, folks interested hopefully interested in measurement and and research regarding your your products or your systems.

These are these are tools that we can pull out of the toolkit to measure, well, is this is this system or this application or this screen, is it cognitively loading our users? I'll start with self reported measures. These are the most, I think for us here in the room, these are the pros, perhaps the most reasonable to start with.

These are, as they say, self report measures. So typically come in the form of some sort of self completion survey or questionnaire. So this is about participants' perceptions of their own levels of of workload. There there's, of course, challenges in in that. Like, if I was to ask anyone in the room now, how cognitively loaded do you feel right now?

I I think that's a hard question to answer. But there are there are standardized methods and measures to to help us through that. The most famous of these is a is a measure called Monassa TLX. So it is it is created by the people who send rockets into space, and it was created a number of decades ago to measure or to measure just that instrumentation within aviation scenarios and how how cognitively demanding they are.

So this this is a a number of scale styles questions that a participant will answer, and then you end up with a single number at the end that that represents their their workload. So this is a, I guess, a fairly typical or common way to measure workload, I I suppose, you know, a quick and dirty and cheap methodology. Next are the physiological measures.

So this works on the assumption that one's level of workload is externalized through some sort of physiological process within the human body. So we're probably all familiar with, use of polygraphs or lie detector testing. That's that's another example of physiological measures.

So in terms of cognitive load, there's a number of ways to do this. So there's theories about behavior of the eye, particularly ballistic movement of the eye, which could be tracked to reveal one's level of workload. Pupil dilation is another area or or response from the human body that's measured.

Heart rate variability is another area. And you can look at the the source directly through something like fMRI is another method. But, of course, very, very, very expensive, specialized, and technical methods to measure workload. Next are performance measures.

This is probably my my preferred way to measure workload, and this is where we would typically get a participant into a dual task scenario. Again, we think back to the car where they're they're doing lots of things, and at that point, the point of work overload occurs when they're turning off the radio.

So if we can get a participant into a dual task scenario, so they might be interacting with our system or application that we wanna test, we might ask them to do something simultaneously. But as their performance reduces in the primary task, we know they've hit the point of of overload. So as we saw when the radio was being turned off.

So we can we can look for tells in human behavior through performance to to reveal workload also. So things like task completion time, the number of errors made, the interference from a dual task, so if they're doing multiple things at the same time, and delays and heat maps in behavior too. So we we see things like cursor tracking, click tracking, things like that in applications.

So when we think about our interfaces and some of the, I I guess, some of the levers that we can pull as designers, and I'm just suggesting now that perhaps there are some predictable ways that cognitive load becomes apparent in interfaces that that we might design. So, again, it relates to memory.

So if there's too many simultaneous choices, we might have this idea of decision burden, this dichotomy of choice. It's almost like that thing where we all open the Netflix screen and there's too many things to to pick, so we just don't pick anything. So this this decision burden that may happen. Fragmentation of information. So information being spread across multiple places, multiple formats, or where we force choice.

If there's hidden system logic, so if the the state of visibility isn't clear or if there isn't a clear mental model displayed. If there's constant attentional competition, so if this thing is competing. I Cordelia had a good slide at the beginning demonstrating really the noisy world that we live in now, where the phone's going off, the watch is buzzing, that we're getting notifications here, there, and everywhere, and if there's excessive recall requirements also.

So, again, relates to memory, and if there's a need to recall things across time or across tasks, that can that can represent a burden also. In terms of how we can design around this, so if we're cognizant of examples like that, we we can think around that. So if we're to reduce unnecessary decisions, So if this is around progressive disclosure, having smarter defaults within an application or more obvious defaults, or more linear pathways, this could be very simple if it's having, you know, having breadcrumbs available in an interface or something like that.

If we can support recognition over recall also. So if we can have persistent visual cues and labels, guidelines and hints through an application. If we create attentional hierarchy, so if there's a clear visual hierarchy in our content design, white space and grouping and some priority signaling throughout our content also, and if we preserve the flow across systems, so if we're moving folks between systems, this is important in our context at the university, if there can be consistency or shared navigation or state preservation between those systems or dialogues.

Brilliant. So I'd love now to talk quickly to an example, where I guess we sort of utilize some cognitive load theory to make an experience better for our primary user group, which is our student cohort. So we had a case study within the higher education sector where we have quite a difficult platform to use.

It's very terminology intensive and it's quite a difficult process for our students. So what we found through user research was there was probably unnecessary and extra friction across a user journey where students actually needed quite a great level of detail to be able to complete the administrative task. So applying some cognitive load theory, we used a little bit of help material.

So we actually built some custom help material through a digital adoption tool and embedded that in the primary platform that we were having those challenges with. And we used, I guess, like, we applied the theory in ways around progressive disclosure of information and preselected elements to guide our students through those required steps. So not just, I guess, helping them get to the goal, but also teaching them how to get to that goal again in the future. So the impact does speak for itself.

Latest stats. So within the last ninety days, that help material has surfaced to 23,000 students, and the accompanying self help module within that has answered over 900 inquiries, diverting that away from our primary inquiry center.

So in beginning beginning to summarize, I guess, in terms of what we're trying to take or in taking all of this together, we're saying that good design hopefully protects our ability to think, and that great interfaces protect memory for what matters most. So I I wanna leave you with with with just a few things to remember or hopefully a few takeaways out of this talk.

So one, that working memory is limited. So when you're when you're designing, or you're assessing an interface or a system or a process or service, think about that think about that cup metaphor. How many things they might need to remember or recall or be cognizant of through throughout their journey? And think about that cup overfilling and perhaps the effects that might happen once that occurs.

So again, hopefully a takeaway for you all is that working memory is limited. And the second takeaway for you all, that cognitive overload changes behavior. So again, back to the cup, it's overfilling and what that means for our users, that they're going to simplify information analysis, that they may make errors, that they may feel more frustrated.

So these are the things that we, as custodians of of systems and processes, that we, of course, want to avoid. So let's let's be cognizant of that also, that overload affects decisions, attention, and performance of our users and our customers. And finally, that good design reduces unnecessary cognitive work.

So back to some of those examples, which are in some ways straightforward and and may be obvious, but they can be they can be easy to forget in the in the process of design and iteration and so on and so forth that they're simple, but we need to remember them and that good design can prevent unnecessary unnecessary cognitive work and hopefully lead us to a place where we're not cognitively overloading our users, and that the best systems help people think clearly. So I'll leave it at that.

I'll thank you all for for being a great audience and and listening through today, And happy to take a question or two if there's time, of course. Thank you both very much.