Ergonomics in UX/UI Design

Personas capture what your users are like. They're a way of representing to you and to those you work with, who your users are. Scenarios do the same job but are about *how* people do things. Scenarios are *stories* for design. They're ways you can use your understanding you've gained

from talking or observing users, to others. To capture it for yourself, to retain it yourself, but also to communicate with others. They can also be used to validate other kinds of models. So, if you're doing a detailed task analysis or perhaps doing a walk-through, a cognitive walk-through for evaluation later, they're a way of validating that. You can say "Does this actually agree with  these scenarios, these scenarios that have come from my experience of users? Do the way in which we play these out in more detailed forms actually accord to it?"

They also help you to understand the dynamics of design. So, it's very easy to think about static images or static states of a system. Scenarios are about helping you understand the dynamics, the way something moves from point to point. They have limitations; they are linear. They capture just one view through. But they are very, very rich. So, what will your users want to do? These are questions that scenarios are going to help you do.

How do you do this? You create a step-by-step walk-through. What can I see? If I'm a user using a new piece of technology, what am I seeing? What am I hearing at  this point? What's the immediate perception? What can I do with what I've got with me? So, again, what are the steps? Is somebody going to pick something up? Are they going to press something? Are they going to say something? What's their potential actions? What are they thinking? What's going on in their head?

So, can you capture these, within a story? If you do a sketch on a system, that captures one point of time, but this is about looking... and that perhaps might help you answer the "what can they see?" question, but of course not "what can they do, what are they thinking?". The scenario's about capturing this rich view of what  users are doing or could do or might want to do.

So, an important consideration in AR is *safety*. What do I mean by 'safety'? I mean *physical safety* – falling, tripping, crashing or endangering others. I'm also meaning *social safety*. So, data sharing, stalking, bullying – anything that could endanger someone socially. When we think about AR engagement and immersion and keeping someone's attention,

we have to think about safety because there are limits to how much immersion or attention stealing we can take. And it really comes down to managing *task load*. So, how much can you take away from someone's attention while they're performing a task? Because they've got the physical environment to deal with and the social environment as well. So, outside of the data issues of the system  leaking information like that,

let's talk about how you as a designer can prevent that. Adidas was exploring a virtual try-on mirror. And they decided that there were many, many safety concerns with scanning a person's body size, keeping that record on a server or potentially  sharing it with other people, and the violation that that might have to that person's identity. And they didn't want

to create that feeling. They just wanted to use it as a sizing guide. And it kind of gives you a moment to pause and ask with your design, are you designing for safety? It's really about *reducing harm*. And I think about this as having, there's a *physical body* that you need to protect. That's so you don't fall into things, stub your toe or hurt your face or your head if you're walking into a wall, for example.

There's also the *social body* – you know – your identity, the way you express yourself. And finally, an *emotional body* or your feelings and the way that you express your feelings with AR, for example. And so, how we're portrayed or how our identity is used and how we feel are the things we're protecting. When we talk about safety as well, we're also  talking about *inclusion*.

And making sure that we've included folks from underrepresented communities. And this includes folks with disabilities. And so, the main disabilities that we should be thinking about with AR inclusion are: blind, low vision, mobility impairments, deaf, hard of hearing and cognitive or neurodiversity as well. So, these are important areas to be careful of in terms of design.

But there are also opportunities to *innovate  and create more interesting AR experiences*.   And one of my favorite examples is the Hololens for blind users. And what it does is it uses the technology of sonification to detect objects because sound can detect objects, the density of an object, and it can be used just like a cane can be used to detect objects in space.

And this is an example from a bus stop  detection. So, the problem is blind users don't know where bus stops are. And in this case Hololens is being used as a way to give blind users *audible cues* about where bus stops are as they walk out in their neighborhoods.

Accessibility ensures that digital products, websites, applications, services and other interactive interfaces are designed and developed to be easy to use and understand by people with disabilities. 1.85 billion folks around the world who live with a disability or might live with more than one and are navigating the world through assistive technology or other augmentations to kind of assist with that with your interactions with the world around you. Meaning folks who live with disability, but also their caretakers,

their loved ones, their friends. All of this relates to the purchasing power of this community. Disability isn't a stagnant thing. We all have our life cycle. As you age, things change, your eyesight adjusts. All of these relate to disability. Designing accessibility is also designing for your future self. People with disabilities want beautiful designs as well. They want a slick interface. They want it to be smooth and an enjoyable experience. And so if you feel like

your design has gotten worse after you've included accessibility, it's time to start actually iterating and think, How do I actually make this an enjoyable interface to interact with while also making sure it's sets expectations and it actually gives people the amount of information they need. And in a way that they can digest it just as everyone else wants to digest that information for screen reader users a lot of it boils down to making sure you're always labeling

your interactive elements, whether it be buttons, links, slider components. Just making sure that you're giving enough information that people know how to interact with your website, with your design, with whatever that interaction looks like. Also, dark mode is something that came out of this community. So if you're someone who leverages that quite frequently. Font is a huge kind of aspect to think about in your design. A thin font that meets color contrast

can still be a really poor readability experience because of that pixelation aspect or because of how your eye actually perceives the text. What are some tangible things you can start doing to help this user group? Create inclusive and user-friendly experiences for all individuals.

"The term affordance refers to the relationship between a physical object and a person." — Don Norman   Sometimes it can be difficult to know how we  can interact with an object if its affordances   are invisible. Some affordances are  perceivable; others are invisible. Affordances exist even if they are invisible – it's your job as a designer to make them visible. Let's look into invisible affordances; let's  look into *glass*.

Glass affords transparency – we can see through glass. Glass affords seeing through. We can pour water into glass – glass affords containing water. We can use glass as a table because glass affords support. That's because glass blocks the passage of air and physical objects. Well, okay, atomic particles can pass through glass, but that's not our focus here.

It's an *anti-affordance* that water, fingers, air and all other physical objects can't pass through glass. Glass prevents that interaction. When you design, it's your job to ensure that affordances and anti-affordances  are discoverable and understandable. People have to be able to perceive them with their senses. If not, people will not know what the design affords. It can be tricky to create a design where the  affordances

and anti-affordances are *discoverable*. Let's take a simple example. One of the reasons we like glass is that it's almost invisible. However, since it's almost invisible  Birds often try to fly through windows. But glass does not afford passage – in  that manner, glass is an anti-affordance.  Anti-affordance: Define what actions are impossible. Glass does not afford passage of objects.  

Affordance: Define what actions are possible.  Glass affords seeing through. When birds and people don't discover the anti-affordance, it's a messy affair. "The presence of an affordance is jointly determined by the qualities of the object and the abilities of the agent that is interacting." Now, back to your job – if people cannot perceive the affordance and anti-affordance, it's your job to design some kind of *signifiers* to help people understand that it's there. 

Signifiers help people perceive the  affordances and anti-affordances. Here, you see that some designers put arrows to signify the anti-affordance of the glass door. The arrows signify that the glass door blocks the passage when it's closed. Likewise, when you design apps, products and services, it's your job to help people discover the affordances and anti-affordances.

Where can – and should – they press, tap  and scroll to fulfill their goals?   It's your job to make it as easily discoverable and understandable as you possibly can. Interaction Design Foundation

Now, just to start off by saying responsive is a default. Responsive is not an option – *do it*. And the reason is because that's where the world is at. Everyone expects things to be mobile-optimized, and responsive just means that if I switch from my laptop to my tablet to my phone, the site's going to fit to that resolution; it's going to kind of follow me.

And we know that users do that; that's the default. So, by doing responsive design, you're supporting device switching, and that's why it's important. You're also potentially making things a little bit more accessible and SEO-friendly, which is a factor for Google's algorithm that prioritizes responsive sites.

User Interface Design Patterns are recurring components which designers use to solve common problems in interfaces. like, for example, when we think about those regular things that often are repeating themselves to kind of appear in, you know, in complex environments We need to show things that matter to people when they matter and nothing else. Right. it's just really sad what we see. Like, for example, if you look at Sears, right? Sears is just one of the many e-commerce sites, you know, nothing groundbreaking here. So you click on one of the filters and then the entire interface freezes

and then there is a refresh and you're being scrolled up. And I always ask myself, is this really the best we can do? Is really the best kind of interface for filtering that we can come up with, or can we do it a bit better? Because we can do it a bit better. So this is a great example where you have galaxies and then galaxies, you have all this filters which are in rows. Sometimes they take three rows, sometimes four or sometimes five rows. That's okay. Show people filters, show people buttons if they important show them.

Right. But what's important here, what I really like is we do not automatically refresh. Instead, we go ahead and say, "Hey, choose asmany filters as you like", right? And then whenever you click on show results, it's only then when you actually get an update coming up in the back. Which I think is perfectly fine. You don't need to auto update all the time. And that's especially critical when you're actually talking about the mobile view. The filter. Sure, why not? Slide in, slide out, although I probably prefer accordions instead.

And you just click on show products and it's only then when you return back to the other selection of filters and only when you click okay, show all products, then you actually get to load all the products, right? Designing good UI patterns is important because it leads to a better user experience, reduces usability issues, and ultimately contributes to the success of a product or application. It's a critical aspect of user centered design and product development.

Universal design is a design practice that is generally considered to be a design that has gone through all the design processes while hoping to take everyone into consideration. You just would have to design it in a way that everyone can use it. The *problem* with the approach of universal design is, though, that *you cannot really design for everyone*.

To design with 8 billion people in mind is strictly impossible: a design that is utopian or more academic or more a discourse subject rather than something that we can really and truly design. But you can do *inclusive design* as a part of design practices that strive for inclusion. The difference is that inclusive design is the umbrella above,

for example, accessible design because accessibility is an accommodation. It is checking boxes whether your design is truly accessible. And if it serves the purpose for your audiences. Inclusive design is the same umbrella. Universal design is more of a juxtaposition, but it's more battling against inclusive design because if you think of everyone, you think of no one.

And in this inclusive way, we can look towards architecture, we can look towards city planning and also how buildings are built in the past decades because they have taken aboard the inclusive approach. They do all the accommodations they can think of – for example, no stairs, ride towards those who have to take a wheelchair. Or it could be beneficial to people with a trolley or with something heavy that they have to carry.

So, thinking of this benefits everyone. And now imagine the internet being a public space, and how we can learn from city planning and architecture and interior design, that we are *accommodating those who need accommodation*. And that's what the inclusive approach is about. So, to sum this up, your research cannot be universal, because you cannot serve that, but it can be personalized and it can be also tailored to the needs of the audience you are serving.

So, why do you need prototyping? Well, we never get things right first time. It's about getting things *better* when they're not perfect and also *starting in a good place*. Maybe if I'm going to make a wall for a house, I know exactly how big the wall should be. I can work out how many bricks I need. I can make it exactly the right size.

So, I can get it right first time. It's important to. I don't want to knock the wall down and retry it several times. However, there I have a very clear idea of what I'm actually creating. With people involved, when you're designing something for people, people are not quite as predictable as brick walls. So, we *don't* get things right first time. So, there's a sort of classic cycle – you design something, you prototype it,

and that prototyping might be, you might sort of get a pad of paper out and start to sketch your design of what your interface is going to be like and talk through it with somebody. That might be your prototype. It might be making something out of blue foam or out of cardboard. Or it might be actually creating something on a device that isn't the final system but is a "make-do" version, something that will help people understand.

But, anyway, you make some sort of prototype. You give it to real users. You talk to the real users who are likely to be using that about it. You evaluate that prototype. You find out what's wrong. You redesign it. You fix the bugs. You fix the problems. You mend the prototype, or you make a different prototype. Perhaps you make a better prototype, a higher-fidelity prototype – one that's closer to the real thing. You test it again, evaluate it with people, round and round and round. Eventually, you decide it's good enough. "Good enough" probably doesn't mean "perfect", because we're not going to get things perfect, ever.

But "good enough" – and then you decide you're going to ship it. That's the story. In certain cases in web interfaces, you might actually release what in the past might have been thought of as "a prototype" because you know you can fix it, and there might not be an end point to this. So, you might in delivering something – and this is true of any product, actually – when you've "finished" it, you haven't really finished, because you'll see other problems with it, and you might update it

and create new versions and create updates. So, in some sense, this process never stops. In one way, it's easy to get so caught up with this *iteration* – that is an essential thing – that you can forget about actually designing it well in the first place. Now, that seems like a silly thing to say, but it is easy to do that. You know you're going to iterate anyhow. So, you try something – and there are sometimes good reasons for doing this –

you might have *so little* understanding of a domain that you try something out to start with. However, then what you're doing is creating a *technology probe*. You're doing something in order to find out. Of course, what's easy then to think about is to treat that as if it was your first prototype – to try and make it better and better and better. The trouble is – if it didn't start good, it might not end up very good at the end, despite iteration. And the reason for that is a phenomenon that's called *local maxima*.

So, what I've got here is a picture. You can imagine this is a sort of terrain somewhere. And one way to get to somewhere high if you're dumped in the middle of a mountainous place – if you just keep walking uphill, you'll end up somewhere high. And, actually, you can do the opposite as well. If you're stuck in the mountains and you want to get down, the obvious thing is to walk downhill. And sometimes that works, and sometimes you get stuck in a gully somewhere. So, imagine we're starting at this position over on the left. You start to walk uphill and you walk uphill and you walk uphill.

And, eventually, you get onto the top of that little knoll there. It wasn't very high. Now, of course, if you'd started on the right of this picture, near the *big* mountain, and you go uphill and you go uphill and you go uphill and you get uphill, you eventually end up at the top of the big mountain. Now, that's true of mountains – that's fairly obvious. It's also true of user interfaces. *If you start off* with a really dreadful design and you fix the obvious errors,

*then you end up* with something that's probably still pretty dreadful. If you start off with something that's in the right area to start with, you do better. So, the example I've put on the slide is the Malverns. The Malverns are a set of hills in the middle of the UK – somewhere to the southwest of Birmingham. And the highest point in these hills is about 900 feet. But there's nothing higher than that for miles and miles and miles and miles.

So, it is the highest point, but it's not *the* highest point, certainly in Britain, let alone the world. If you want to go really high, you want to go to Switzerland and climb up the Matterhorn or to Tibet and go up Mount Everest, up in the Himalayas, you'll start somewhere better, right? So, if you start – or on the island I live on, on Tiree, the highest point is 120 meters. So, if you start on Tiree and keep on walking upwards, you don't get very high.

You need to start in the *right* sort of area, and similarly with a user interface, you need to start with the *right* kind of system. So, there are two things you need for an iterative process. You need a *very good starting point*. It doesn't have to be the best interface to start with, but it has to be in the right area. It has to be something that when you improve it, it will get really good. And also – and this is sort of obvious but actually is easy to get wrong – you need to understand *what's wrong*. So, when you evaluate something, you really need to understand the problem.

Otherwise, what you do is you just try something to "fix the obvious problem" and end up maybe not even fixing the problem but certainly potentially breaking other things as well, making it worse. So, just like if you're trying to climb mountains, you need to start off in a good area. Start off in the Himalayas, not on Tiree. You also need to know which direction is up.

If you just walk in random directions, you won't end up in a very high place. If you keep walking uphill, you will. So, you need to *understand where to start* and *understand which way is up*. For prototyping your user interface, you need a *really rich understanding* of *your users*, of the nature of *design*, of the nature of the *technology* you're using, in order to start in a good place. Then, when you evaluate things with people,

you need to try and *really deeply* understand what's going on with them in order to actually *make things better* and possibly even to get to a point where you stand back and think: "Actually, all these little changes I'm making are not making really a sufficient difference at all. I'm going around in circles." Sometimes, you have to stand right back and make a *radical change* to your design. That's a bit like I'm climbing up a mountain

and I've suddenly realized that I've got stuck up a little peak. And I look out over there, and there's a bigger place. And I might have to go downhill and start again somewhere else. So, iteration is absolutely crucial. You won't get things right first time. You *alway*s need to iterate. So, prototyping – all sorts of prototypes, from paper prototypes to really running code – is very, very important. However, *crucial to design is having a deep and thorough understanding of your users*,

*a deep and thorough understanding of your technology and how you put them together*.

I'm working at the TAPP Transit System; this is a made-up transit system app. And it says, 'Oh, we need a notification for when someone's payment method has expired.' So, first I do the strategic work and I say, 'What's the *point* here?' What's the point for our user, and what's the point for the business or the organization? And what are our *voice concepts* that we want to make sure that we're landing so that it's in our brand?' So, I take it and then I start including *purpose*.

And it gets longer and longer. And I just *iterate and iterate*,  and I keep all these iterations. Thank heavens for tools like Sketch and Figma where I just make artboard after artboard after artboard or frame after frame and keep them all. I choose the best of those, and I work on making it *more concise* – more concise and more concise, and you see it's getting shorter and shorter. It gets so short here at the end, it's not particularly usable. So, I'm going to go with the second to the end and go forward.

I'm going to make it more *conversational*: is this something a person would actually say? And I make more iterations. And I have my favorite among those. And then I look at all of them together, and I say, 'Here's my best ones,' and that's what I'm going to tell my team about. I'm going to say the original message doesn't follow the  voice and really doesn't meet the purpose. I'm going to say which one I recommend and why and give them another couple of options.

The secret here is: *I'm happy with all three of these*; I don't care which ones they choose; and, frankly, I'd prefer to A/B test them against  each other and learn more about the language.