The Law of Common Fate

To create a proper hierarchy. We're going to use one of the gestalt rules called proximity. And of course, if you know the Gestalt rules, you should try to follow all of them. But I believe proximity is the most important one, because in many cases we're using very simple shapes. So the distance between those shapes is what actually makes the entire layout. And this rule says that objects placed close to each other are automatically understood as a group.

So in our case, how many groups do we have here? So we have the group of 12 bluish green circles. Then we have a group of three in green circles and then another group of three green circles. But then we also have a group of all the circles combined. And this is how this grouping and proximity works. You need to be aware that there are groups within groups and there can be groups within groups. So let's take one of our examples from before.

And if we add grouping on top of it, you'll see that we can just by proximity, establish a couple of groups here. The emoji is one group, then the text and the other text is the second group. And then the pattern with the other clickable element is the third group. And of course, you can also consider the emoji being one group and all of the content is being another group. It's not just how you approach it and how you're actually going to work it in.

Additional examples of this design, because it's not just going to be just this one version, but the thing is that we should be able to consistently replicate those groups in other versions of that screen. So if we created those groups and those distances between the groups, they need to be consistent. And this is what you should use basically to create that consistency. So if you have a distance between the two groups, which are just the whole windows, the distance should always be bigger than the distance

between individual elements within the groups, within a group. So the further down we go in a group, the smaller the distance can be. That allows our brain to process it naturally and really quickly. And we'll see that. Okay, we have two separate big groups of things and then they are divided into smaller groups. And then you can use that rule to organize it further. So you can use another smaller square to

place between elements within those groups. Or you can even use the same one because you can see you could use the Red Square here between the large title and the text as well and the bottom and the smaller text underneath. And that would still fit so that or a smaller one would work here. And this is really important because that's the whole rule of clarity and layout that is really important to follow. So those distances cannot be random. They need to be based on something and they need to be based on

the natural hierarchy. So we quickly understand that, okay, this is a group and this is a group within a group, and these things are together as well because that's going to make it a lot easier. Grouping is also important with the distances. For example, this is one of the largest, like more common problems that I've seen in many forms designed by junior designers is not having enough space between the label and the previous field. And that creates an effect where if there is a longer

a forum where coming it through with our eyes and we don't really know which field that label belongs to, so just increase the distance by two or three times between the fields and then four or six times between the title and the form. And by having that consistency with all the other elements on the site, so like if smaller distances extend, the larger one is to extend keep the X and to X across all of the other things to keep that consistent grading of all of those elements.

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.

When you create something, you design something,  you need to know if it works for your users. And you need to get that design in front of them. And the only way that you can make sure that it meets their expectations is to have them actually *play with it*. Usability testing is *the number one* technique for determining how usable your product is. We want to see how *successful* our users are, see if they're on the right track and if we're getting the reactions that we *want* from a design.

'Ah... I'm not really sure what the users will think!'  *Better test it.* 'Uh... too much fighting with our team internally over what to do!' *Better test it!* Usability testing helps you check in with your user expectations. And it's a way of you making  sure that you're not just stuck in your own ideas about a design and actually bringing in an  end-user from the outside to get some *more clarity and focus*. And the reason why this class is going to  help you is you'll benefit from the 15 years of my

personal experience and *hundreds and hundreds of  usability tests* that I've conducted over the years. We're going to start from the very beginning of  *how to create a test plan and recruit participants*, and then go into *moderation skills, tips and techniques*. You'll also learn *how to report on tests* so you can take that data and represent it in a way that makes sense, you can communicate to your team and learn how to *change your design based on the data that you get from usability tests*,

most importantly. I hope you can join me on this class. I look forward to working with you!

To create a proper hierarchy. We're going to use one of the gestalt rules called proximity. And of course, if you know the Gestalt rules, you should try to follow all of them. But I believe proximity is the most important one, because in many cases we're using very simple shapes. So the distance between those shapes is what actually makes the entire layout. And this rule says that objects placed close to each other are automatically understood as a group.

So in our case, how many groups do we have here? So we have the group of 12 bluish green circles. Then we have a group of three in green circles and then another group of three green circles. But then we also have a group of all the circles combined. And this is how this grouping and proximity works. You need to be aware that there are groups within groups and there can be groups within groups. So let's take one of our examples from before.

And if we add grouping on top of it, you'll see that we can just by proximity, establish a couple of groups here. The emoji is one group, then the text and the other text is the second group. And then the pattern with the other clickable element is the third group. And of course, you can also consider the emoji being one group and all of the content is being another group. It's not just how you approach it and how you're actually going to work it in.

Additional examples of this design, because it's not just going to be just this one version, but the thing is that we should be able to consistently replicate those groups in other versions of that screen. So if we created those groups and those distances between the groups, they need to be consistent. And this is what you should use basically to create that consistency. So if you have a distance between the two groups, which are just the whole windows, the distance should always be bigger than the distance

between individual elements within the groups, within a group. So the further down we go in a group, the smaller the distance can be. That allows our brain to process it naturally and really quickly. And we'll see that. Okay, we have two separate big groups of things and then they are divided into smaller groups. And then you can use that rule to organize it further. So you can use another smaller square to

place between elements within those groups. Or you can even use the same one because you can see you could use the Red Square here between the large title and the text as well and the bottom and the smaller text underneath. And that would still fit so that or a smaller one would work here. And this is really important because that's the whole rule of clarity and layout that is really important to follow. So those distances cannot be random. They need to be based on something and they need to be based on

the natural hierarchy. So we quickly understand that, okay, this is a group and this is a group within a group, and these things are together as well because that's going to make it a lot easier. Grouping is also important with the distances. For example, this is one of the largest, like more common problems that I've seen in many forms designed by junior designers is not having enough space between the label and the previous field. And that creates an effect where if there is a longer

a forum where coming it through with our eyes and we don't really know which field that label belongs to, so just increase the distance by two or three times between the fields and then four or six times between the title and the form. And by having that consistency with all the other elements on the site, so like if smaller distances extend, the larger one is to extend keep the X and to X across all of the other things to keep that consistent grading of all of those elements.

All right, so now it's time to take a  look at some common UI patterns and how to use them. So, we use UI patterns as a way to help users not have to relearn, and there's a really great example here from Down Dog. And in particular, their onboarding, their visual design, their affordances, their contrast, it's all just beautifully executed.

It's actually one of the most popular apps for yoga and other types of fitness training. *Gestures* – of course, this is a gesture-based medium. But gestures are classically difficult to  learn. And so, they've kind of become standardized on all mobile operating systems, more or less. There may be some unique gestures, and there are some gesture hints you can give. So, you can say, "Swipe up to begin." So, you can give like a hint like that. But just be familiar with the fact that gestures in the very beginning of mobile

had all these different variances across  operating systems and most users just did not learn and did not take the time; they don't care. So, the most basic – you know – tap, swipe. There are some gestures like the Tinder gesture that was made famous, like was it: swipe left, swipe right. The other pattern is *integration*, that if you send them to email to validate and they click on email, it should take them back to the app, hopefully.

So, there's a little bit of technology there in terms of opening the container. Some apps do it really well; other apps don't. They send you to a website. Click on another button; then that launches the container. I think that's okay, too, as long as it makes the connection  and the app actually opens. But you should have seamlessness between notifications, the websites or email and the app itself so that if anyone is on any of those touchpoints, they're fluidly able to jump in between.

*Back buttons* are important. It's important that the back buttons act like back buttons and a user can go back to previous content or to a previous section, and that they're *not lost*. And that's actually another point about if you're using accordions and the accordion opens up, the user might get lost inside of the accordion menu. So, you want users to be able to control where they left off, especially if it's a lot of content and to be able to go back and kind of have

more control over that. There's nothing wrong with accordions – they're great – but they can lose their robustness in terms of lost in navigation. Also remember *contrast and affordance* so that – you know – the open / close, whether it's an arrow or plus minus sign, however you illustrate that affordance, that that's visible as well; unless you're deliberately giving the user some kind of focus where they need to be like on that particular page,

it's better if you show navigation and let them quickly bail out because remember you're in that micro  interaction, that clipped attention span. *Hamburger menus* can do without actually the three bars is what the research showed, so a menu with a square around it. And putting that little square or that line around it really helps. Be sure to *test*, of course, to make sure your users can get in there. Be sure to *tag* it from an accessibility standpoint, in other words, so that

a screen reader can know that it's a menu that can be opened. *Use search diligently* – in other words, let users search your mobile app or your mobile site, but if you're letting them drill into a search – say that it's for this section, so this is a news search or this is an archive search or this is – you know – so a lot of sites will just use search and just assume that users know, when really it's like a global search. The key to using different UI controls such  as presenting information in a carousel

or in a bigger menu like a mega menu for mobile is to give people visibility. Don't make them look at each single item. Let them actually get a glance of it and so that they can go on to the next screen. *Videos*, of course, are popular content, but videos force users to sit and watch them.

So, maybe tell them what the video is about and let them scan it quickly, so you might put *markers* in the videos. Make sure those videos are *captioned* for accessibility, for deaf and hard of  hearing users. And the same with *infographics*; if you use infographics, make sure that the infographics have good described by Aria tags. So, Aria is perfect for mobile and can  be used on mobile to make it more accessible. So, it's really important, that customization, personalization.

Giving users *control* of their data is a really good idea. Be *careful of random features*.  Make sure that your features   are based on desirability and from  observed user behavior.  Remember *touch target size and placement and tappability signifiers* so that users know they can tap certain objects and *watch out for accidental touches*.

You know, you can support undo or you can have good error handling to deal with that. Think about how you can help take a user to their task, give them what they need, build motivation, build momentum and have them, you know, essentially convert or engage if it's not an e-commerce or transactional type of thing.

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*.

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.

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.