The Rule of Thirds

The golden ratio, also known as The Golden section or Golden mean, is a mathematical ratio that is closely related to the Fibonacci sequence. It is commonly found in nature and when used in design, it fosters organic and natural looking compositions that are esthetically pleasing to the eye. The golden ratio has been employed for over 2000 years and is still fundamental to both designers and users. Because these forms are so prevalent, our eyes identify them quickly and we tend to process these as familiar and pleasing. You can find beautiful examples of the sequence throughout many

natural elements ferns, flowers, seashells, even hurricanes. Although the golden ratio has been a subject of study for centuries, the medieval Italian mathematician Fibonacci popularized the sequence in which every number is simply the sum of the two numbers before it. The ratio between two consecutive Fibonacci numbers is approximately 1.618, also called Phi. Like Pi, it has a long string of numbers after the decimal point.

Fortunately, we can approximate this to 1.6 or 1.61 or 1.618 in designs without surrounding the esthetic appeal of the golden ratio. But how is the ratio used in design? Think of a rectangle with a short side of length. One. To calculate the most esthetically pleasing rectangle, you simply multiply the length of the short side by the golden ratio approximation of 1.618. So the long side in this instance would have a length of 1.618.

Today we use the golden ratio widely in graphics, websites and applications to create more esthetic designs. In particular, it is very easy to incorporate when building wireframes. You can show that the content you need is prioritized properly and that the esthetic demands of the layout will be met without doing too much design work at first. In this example, the ratio between the content area and sidebar is equal to Phi. If you divide the total width of 960 pixels by 1.618, you get 593 pixels.

You then assign this width to the content area. You assign the remaining 367 pixels to the side bar. As this is a ratio, it is flexible. This means that you can easily apply to make many design layouts as there is no need to use fixed numbers. All you need to do is specify that one area is 1.618 times longer than the other.

As you're designing, it's so easy just to design for the people that you know and for the culture that you know.  However, cultures differ. Now, that's true of many aspects of the interface; no[t] least, though, the visual layout of an interface and the the visual elements. Some aspects are quite easy just to realize like language, others much, much more subtle.

You might have come across, there's two... well, actually there's three terms because some of these are almost the same thing, but two terms are particularly distinguished. One is localization and globalization. And you hear them used almost interchangeably and probably also with slight differences because different authors and people will use them slightly differently. So one thing is localization or internationalization. Although the latter probably only used in that sense. So localization is about taking an interface and making it appropriate

for a particular place. So you might change the interface style slightly. You certainly might change the language for it; whereas global – being globalized – is about saying, "Can I make something that works for everybody everywhere?" The latter sounds almost bound to fail and often does. But obviously, if you're trying to create something that's used across the whole global market, you have to try and do that. And typically you're doing a bit of each in each space.

You're both trying to design as many elements as possible so that they are globally relevant. They mean the same everywhere, or at least are understood everywhere. And some elements where you do localization, you will try and change them to make them more specific for the place. There's usually elements of both. But remembering that distinction, you need to think about both of those. The most obvious thing to think about here is just changing language. I mean, that's a fairly obvious thing and there's lots of tools to make that easy.

So if you have... whether it's menu names or labels, you might find this at the design stage or in the implementation technique, there's ways of creating effectively look-up tables that says this menu item instead of being just a name in the implementation, effectively has an idea or a way of representing it. And that can be looked up so that your menus change, your text changes and everything. Now that sounds like, "Yay, that's it!"

So what it is, is that it's not the end of the story, even for text. That's not the end of the story. Visit Finland sometime. If you've never visited Finland, it's a wonderful place to go. The signs are typically in Finnish and in Swedish. Both languages are used. I think almost equal amounts of people using both languages, their first language, and most will know both. But because of this, if you look at those lines, they're in two languages.

The Finnish line is usually about twice as large as the Swedish piece of text. Because Finnish uses a lot of double letters to represent quite subtle differences in sound. Vowels get lengthened by doubling them. Consonants get separated. So I'll probably pronounce this wrong. But R-I-T-T-A, is not "Rita" which would be R-I-T-A . But "Reet-ta". Actually, I overemphasized that, but "Reetta". There's a bit of a stop.

And I said I won't be doing it right. Talk to a Finnish person, they will help put you right on this. But because of this, the text is twice as long. But of course, suddenly the text isn't going to fit in. So it's going to overlap with icons. It's going to scroll when it shouldn't scroll. So even something like the size of the field becomes something that can change. And then, of course, there's things like left-to-right order. Finnish and Swedish both are left-to-right languages. But if you were going to have, switch something say to an Arabic script from a European script,

then you would end up with things going the other way round. So it's more than just changing the names. You have to think much more deeply than that. But again, it's more than the language. There are all sorts of cultural assumptions that we build into things. The majority of interfaces are built... actually the majority are built not even in just one part of the world, but in one country, you know the dominance... I'm not sure what percentage,

but a vast proportion will be built, not just in the USA, but in the West Coast of the USA. Certainly there is a European/US/American centeredness to the way in which things are designed. It's so easy to design things caught in those cultures without realizing that there are other ways of seeing the world. That changes the assumptions, the sort of values that are built into an interaction.

The meanings of symbols, so ticks and crosses, mostly will get understood and I do continue to use them. However, certainly in the UK, but even not universally across Europe. But in the UK, a tick is a positive symbol, means "this is good". A cross is a "blah, that's bad". However, there are lots of parts of the world where both mean the same. They're both a check. And in fact, weirdly, if I vote in the UK,

I put a cross, not against the candidate I don't want but against the candidate I do want. So even in the UK a cross can mean the same as a tick. You know – and colors, I said I do redundantly code often my crosses with red and my ticks with green because red in my culture is negative; I mean, it's not negative; I like red (inaudible) – but it has that sense of being a red mark is a bad mark.

There are many cultures where red is the positive color. And actually it is a positive color in other ways in Western culture. But particularly that idea of the red cross that you get on your schoolwork; this is not the same everywhere. So, you really have to have quite a subtle understanding of these things. Now, the thing is, you probably won't. And so, this is where if you are taking something into a different culture, you almost certainly will need somebody who quite richly understands that culture.

So you design things so that they are possible for somebody to come in and do those adjustments because you probably may well not be in the position to be able to do that yourself.

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!

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.