Navigation in UX/UI Design

User research is a crucial part of the design process. It helps to bridge the gap between what we think users need and what users actually need. User research is a systematic process of gathering and analyzing information about the target audience or users of a product, service or system. Researchers use a variety of methods to understand users, including surveys, interviews, observational studies, usability testing, contextual inquiry, card sorting and tree testing, eye tracking

studies, A-B testing, ethnographic research and diary studies. By doing user research from the start, we get a much better product, a product that is useful and sells better. In the product development cycle, at each stage, you’ll different answers from user research. Let's go through the main points. What should we build? Before you even begin to design you need to validate your product idea. Will my users need this? Will they want to use it? If not this, what else should we build?

To answer these basic questions, you need to understand your users everyday lives, their motivations, habits, and environment. That way your design a product relevant to them. The best methods for this stage are qualitative interviews and observations. Your visit users at their homes at work, wherever you plan for them to use your product. Sometimes this stage reveals opportunities no one in the design team would ever have imagined. How should we build this further in the design process?

You will test the usability of your design. Is it easy to use and what can you do to improve it? Is it intuitive or do people struggle to achieve basic tasks? At this stage you'll get to observe people using your product, even if it is still a crude prototype. Start doing this early so your users don't get distracted by the esthetics. Focus on functionality and usability. Did we succeed? Finally, after the product is released, you can evaluate the impact of the design.

How much does it improve the efficiency of your users work? How well does the product sell? Do people like to use it? As you can see, user research is something that design teams must do all the time to create useful, usable and delightful products.

In a world overflowing with information, how do we find exactly what we're looking for, both online and offline? Enter Information Architecture, or IA: the discipline that helps us navigate through vast data landscapes. Information architecture is the framework of organization and labeling we use to structure and categorize content and data, primarily within digital products to make it easy to understand and navigate. Is like organizing a massive global library so you can find that one book without getting lost.

Whether it's grouping Jurassic Period fossils in a museum, or arranging your favorite snacks in the supermarket, IA can guide us through physical and digital spaces alike. At its core, IA focuses on arranging the part of something to be understandable as a whole. In the context of UX design, IA is akin to the blueprint of a building: it lays out the foundation and structure upon which user experiences are built. It operates on the understanding that we perceive information as places

made of language: labels, menus, visuals that can be organized for better navigation. Good IA is shaped by the content available, the context in which it's sought and the users seeking it, forming a complex information ecology. For UX designers, this means starting with understanding users needs, which leads to the creation of intuitive site maps, navigation and user flows that make digital experiences seamless.

After a designer identifies user needs and content requirements, they will create a hierarchy that aligns with user behavior and psychology. This involves defining how information is grouped, how it flows from one section to another, and how users access it through navigation and search functionalities. Effective IA results in a coherent, intuitive user interface that allows users to find information quickly, accomplishes tasks efficiently, and understand the location within the digital space at any given time.

Effective information architecture isn't just an initial step. It's the foundation upon which effective user experience is built, ensuring that every digital interaction is meaningful and easy to navigate.

Personas are one of these things that gets used  in very, very many ways during design. A persona is a rich description or description of a user. It's similar in some sense, to an example user, somebody that you're going to talk about. But it usually is not a particular person. And that's for sometimes reasons of confidentiality.

Sometimes it's you want to capture about something slightly more generic than the actual user you talked to, that in some ways represents the group, but is still particular enough  that you can think about it. Typically, not one persona, you usually have  several personas. We'll come back to that.   You use this persona description, it's  a description of the example user,   in many ways during design. You can ask  questions like "What would Betty think?"

You've got a persona called / about Betty, "what would  Betty think" or "how would Betty feel about using this aspect of the system? Would Betty understand this? Would Betty be able to do this?"   So we can ask questions by letting those personas  seed our understanding, seed our imagination.   Crucially, the details matter here. You want to make the persona real. So what we want to do is take this  persona, an image of this example user,   and to be able to ask those questions: will  this user..., what will this user feel about  

this feature? How will this user use this system  in order to be able to answer those questions?  It needs to seed your imagination well enough.  It has to feel realistic enough to be able to   do that. Just like when you read that book  and you think, no, that person would never   do that. You've understood them well enough that  certain things they do feel out of character. You need to understand the character of your  persona.

For different purposes actually, different levels of detail are useful. So I'm going to sort of start off with   the least and go to the ones which I think are  actually seeding that rich understanding.  So at one level, you can just look at your  demographics. You're going to design for warehouse   managers, maybe. For a new system that goes into  warehouses. So you look at the demographics, you might have looked at their age. It might be that on the whole that they're   older. Because they're managers, the older end. So  there's only a small number under 35. The majority  

are over 35, about 50:50 between those who are in  the sort of slightly more in the older group.  So that's about 40 percent of them in  the 35 to 50 age group, and about half   of them are older than 50. So on the whole  list, sort of towards the older end group.   About two thirds are male, a third are female.  Education wise, the vast majority have not got   any sort of further education beyond school. About 57 percent we've got here are school.  

We've got a certain number that have done basic  college level education and a small percentage   of warehouse managers have had a university  education. That's some sense of things.   These are invented, by the way, I should say, not  real demographics. Did have children at home. The people, you might have got this from some big  survey or from existing knowledge of the world,   or by asking the employer that you're  dealing with to give you the statistics.   So perhaps about a third of them have got children  at home, but two thirds of them haven't. 

And what about disability? About three  quarters of them have no disability whatsoever.   About one quarter do. Actually, in society  it's surprising. You might... if you think   of disability in terms of major disability,  perhaps having a missing limb or being   completely blind or completely deaf. Then you start relatively small numbers.   But if you include a wider range of disabilities,  typically it gets bigger. And in fact can become  

very, very large. If you include, for  instance, using corrective vision with   glasses, then actually these numbers  will start to look quite small.  Within this, in whatever definition they've  used, they've got up to about 17 percent with   the minor disability and about eight percent  with a major disability. So far, so good. So now, can you design for a  warehouse manager given this? Well,  

you might start to fill in examples for  yourself. So you might sort of almost like   start to create the next stage. But it's hard. So let's look at a particular user profile. Again,   this could be a real user, but let's imagine  this as a typical user in a way. So here's Betty Wilcox. So she's here as a typical user.  And in fact, actually, if you look at her, she's   on the younger end. She's not necessarily the  only one, you usually have several of these.  And she's female as well. Notice only up to  a third of our warehouse ones are female. So  

she's not necessarily the center one. We'll come  back to this in a moment, but she is an example user. One example user. This might have been  based on somebody you've talked to, and then you're sort of abstracting in a way. So, Betty Wilcox. Thirty-seven, female, college education. She's got children at home, one's  seven, one's 15. And she does have a minor disability, which is in her left hand. And  it's there's slight problem in her left hand.  

Can you design, can you ask, what would Betty  think? You're probably doing a bit better at   this now. You start to picture her a bit. And you've probably got almost like an image   in your head as we talk about  Betty. So it's getting better.   So now let's go to a different one. You know, this  is now Betty. Betty is 37 years old. She's been a   warehouse manager for five years and worked for  Simpkins Brothers Engineering for 12 years. She didn't go to university, but has studied  in her evenings for a business diploma.

That was her college education. She has two children  aged 15 and seven and does not like to work late.   Presumably because we put it  here, because of the children.   But she did part of an introductory  in-house computer course some years ago.   But it was interrupted when she was promoted,  and she can no longer afford to take the time.   Her vision is perfect, but a left hand movement,  remember from the description a moment ago,   is slightly restricted because of an  industrial accident three years ago. 

She's enthusiastic about her work and  is happy to delegate responsibility   and to take suggestions from the staff. Actually,  we're seeing somebody who is confident in her   overall abilities, otherwise she wouldn't  be somebody happy to take suggestions.   If you're not competent, you don't. We sort of see that, we start to see a   picture of her. However, she does feel threatened  – simply, she is confident in general – but she   does feel threatened by the introduction of  yet another computer system. The third since she's been working at Simpkins Brothers. So now, when we think about that, do you have a better vision of Betty?

Do you feel you might be in a position to start talking about..."Yeah, if I design this sort of feature, is this something that's going to work with Betty? Or not"? By having a rich  description, she becomes a person. Not just a set of demographics. But then you  can start to think about the person, design for the person and use that rich human understanding you have in order to create a better design.

So it's an example of a user, as I said not  necessarily a real one. You're going to use this as a surrogate and these details really, really matter. You want Betty to be real to   you as a designer, real to your clients as you  talk to them. Real to your fellow designers  as you talk to them. To the developers around  you, to different people. Crucially, though, I've already said this, there's not just one. You usually want several different personas because the users you deal with are all different.

You know, we're all different. And the user group – it's warehouse managers – it's quite a relatively narrow and constrained set of users, will all be different. Now, you can't have one persona for every user,   but you can try and spread. You can look at the range of users.   So now that demographics picture I gave,  we actually said, what's their level of education? That's one way to look at that range. You can think of it as a broad range of users.

The obvious thing to do is to have the absolute  average user. So you almost look for them:   "What's the typical thing? Yes, okay." In my  original demographics the majority have no college   education, they were school educated only. We said that was your education one,   two thirds of them male – I'd have gone for  somebody else who was male. Go down the list, bang   in the centre. Now it's useful to have that center  one, but if that's the only person you deal with,   you're not thinking about the range. But certainly you want people who in some sense  

cover the range, that give you a sense  of the different kinds of people.   And hopefully also by having several, reminds  you constantly that they are a range and have   a different set of characteristics, that there  are different people, not just a generic user.

And my favorite example of this is – has anyone ever heard, especially someone who is maybe older say, 'Hey, I need to look something up at *the Google*. I need to go to The Facebook.'? And there's been jokes about it and memes and people sort of laugh about that. But if you really break down what they're trying to say there, what happens is that, what's the mental model of someone who is maybe 100 years old when they need to go and look something up? What do they do? They go to *the library*. They're going to a physical place.

So, the mental model of the search for knowledge involves *going somewhere*. And so, it makes sense that when they're talking about Google, they're going to go to 'the Google'. It's the mental model of how *they* search for information. So, they go to *cyberspace*; it's a place they go.

Imagine walking into a room filled with countless doors, each leading to a different destination. Where do you begin? This is how users feel when faced with a new and confusing interface. To combat this, designers use progressive disclosure, a user centered design method that carefully reveals information and features to users as they are needed. The purpose here is to avoid overwhelming the user with a cluttered interface. We are talking about this beast. How do we fix that, right?

Well, there is a very simple way of fixing it. First of all, for tables, you usually would have not that many options In customize and sorting, you would have, you know, probably some hopefully not hover actions, but a button saying actions, which would be a dropdown opening things on tap, on click, have us you know, the checkboxes on the left allowing you to select things. We have 49 filters. We have 49 dropdowns with approximately 300 options living within those dropdowns.

Now imagine that you're working on Finviz. That means that you are, you know, you have your screen application, so you might be managing a portfolio with 60 different assets, right, of sixty different customers. You also want to kind of understand trends of what you know, what is going on. You also want to navigate the table to understand what is going on there. Right? So maybe there are some companies that are performing really badly. Some companies are performing better. You kind of monitoring it. And very often you would be looking at this interface for 6 to 8 hours a day.

Right? Speed is important here. Dropdowns are the worst thing you can give for people who want to be fast. Dropdowns are the slowest mode of interaction. And you know what is the fastest? Buttons! There is nothing wrong with just 200 buttons. Give people 200 buttons. Just organize them better. And they'll be happy because this is going to be much faster. How can we do that? Well, if we think about the filtering experience,

well, surely enough, we have 49 of those. So we better organize them in some way, like this. So we have this different groups of filters, right? And then we basically need a search engine or like a little search autocomplete for filters. We do it in two steps. The first step is we select what filters we want to have. Right? So we go for the sections. We just have a couple of checkboxes to mark the filters that we need. And in the second step for each of those filters, we define what the properties should have.

You know what? What properties every filter should have. I'll show you an example in a moment. And there is nothing wrong, again, just show buttons. A lot of buttons. Just show buttons. There is nothing wrong with showing buttons. It's fine. In its simplest form, it could look like this. You search your filters. It's kind of a filtering for filters, where you go for all the different groups. Then you select what filters you actually want to have. And then for each of them, you actually define the properties that you want to define.

Now, in example, this is what it looks like on Financial Times, which is a great example of equity screen. You have exactly the same amount of filter actually, but it looks differently. We have a core audience. We have the split menu. We saw this already, right? You select what attributes you care about first. You have buttons so you can actually tap on those quickly, relatively quickly. And if we open equity attributes right, not only do we get this button kind of giving you this overview of what is the most common kind of area where you should be expecting those results, you also can add

or change criteria, and this is how it works. Balance sheet. Okay, I need to add cash per share. Boom. And I need to add price, boom. And I need to add 52% receivable turnover. Right. And so I kind of always show what you need and you never show what you don't need. Which I think is actually pretty cool and pretty useful as well. So that's actually very, very helpful. And I guess this is actually what it needs to be, right?

You show what you need when you know that people need it. And most importantly, you do not show things that are likely to be irrelevant to people. We just say, “here is everything we've got, all the navigation, you've got, you figure it out”. Or “here are all the filters you've got, you figure it out”. No. We need to show things that matter to people when they matter and nothing else.

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.

Visual hierarchy refers to the arrangement or organization of elements within a design in a way that guides the viewer's eye through the content in a specific order of importance. It's about creating a clear and logical structure that helps users navigate and understand the information presented. You can use size and scale, color and contrast typography, white space

alignment, repetition, proximity, visual elements such as icons, images, textures and graphics and reading patterns. By using these principles effectively, Designers can guide the viewer's focus, ensuring that the most important elements are noticed first and create a more intuitive and engaging experience.

Now, when you do journey maps or you create personas, and when you think about content strategy or improving your content and making it more useful, more desirable for your users, it's important that you get that guidance from user research and specifically doing field studies, sitting down with users, going to their homes;

if it's B2B, going to their office place, sitting beside them. I once was doing an internal intranet study for a big hospital. I would go from desk to desk talking to different users. When I would come up with an artifact, so when I would discover an artifact, in one case it was a list of telephone numbers of – you know – frequent people to call; you really need to dig deeper and discover *all the opportunities that exist*. And I ended up carrying a stack of papers.

And one of the users said, "You know, it would be really nice if I had a list of frequent people to call..." And I pulled it out for my stack of papers and said, "Oh, you mean something like this?" And she went, "Yeah. That's exactly right!" I'll tell you another story from a store – it's like a country store. So, on the West coast of the United States there are a new generation of farmers. The focus of this study was to discover what the experience was for younger, for Millennial farmers,

and in particular what content they might need to go along with an e-commerce experience. So, we went out to farms and interviewed people – actually we recruited through, we joined groups on Facebook and we could actually see from the Facebook groups that people were recommending our client's brand and other brands, and they were asking questions like "Where can I sell chicken eggs?" because when you start farming at home, out in the countryside, like chickens are a popular one, goats are the other one; you start developing the byproducts of those of those things.

So, we talked to a lawyer – she's a lawyer by day, when she goes into Seattle, the nearest biggest city, she takes her Nubian goats and sells them to people that buy the goats. It's really interesting. Then the other thing she made was soap with the lard she was making with the extra fat that she was getting from her pigs. She was making her own soap and then selling her own soap as  kind of a cottage industry. So, we could see this – we heard from the users that kind of stuff; we saw them doing this online as well.

So, we had a kind of the social side of it, and Facebook groups are extremely important for certain communities like this. They also act as a way to sell products if you have excess products. But one thing we found out is the users said they want to be able to do this at the stores as well. They said they like the physical events, the social events that stores put on. So, you know, come to the store – a little music, a little bit of food: community essentially. They really liked that, but they wanted more of them. We also discovered that a lot of women

were making the buying decisions. One of our personas was the manager of the farm. A lot of these people have just learned how to do farming off of YouTube; they call it the University of YouTube. So, that small content about how to make your own sauerkraut, how to raise goats, how to make a fence that is deer-proof so the deer don't come and eat your vegetables. All these kinds of things they rely on YouTube, so that was a content discovery source for us. We realized as well that these women were one of the primary personas; they kept coming up.

The irony here was the CEO of the company was actually a woman, but they didn't tell us to interview women – they didn't tell us anything about the gender side of it. We went and did some research just because it was one of our findings and it turns out that in Oregon, anyway, 50% of new farmers are women. This is a huge cultural shift from the 1950s, '60s, where it was like 85 to 90% men.

This is an inclusion and a bias story of discovering bias. Women were complaining that the jeans were designed for men. Women said that after going on a horse for like 20 minutes, the jeans would rip. Then the crotch would just rip out, so they're throwing away, wasting money on clothes that were not designed for a  woman's body, for her physical needs as well as social and other in these. In other words, they were made cute, so little tiny pockets that you can't put anything in – no tools, no phone.

Whereas the men's clothing had that functionality. And there's a bias on clothing, in particular work clothing, and there are actually brands that cater specifically to women that understand this, and there are two  or three brands. But it's still very niche; it's very like edge case. Yet up to 50%, in California, close to 35 to 40% of farmers are women now. And these are government statistics,  and it matched kind of our study.

So, it was a finding that we stumbled upon by making sure that we interviewed the right users, that we listened to – we didn't just assume that farmers were men. We kept an open mind when we created the study. The content ideas that poured out of this  gave us all the types of things that users were saying they needed, and we were able to tell our client to have their social media team and make the kind of content that would work, that would resonate emotionally with the kind of problems that users were trying to solve, in addition to the e-commerce.

And actually when that site launched after six months, (there was) a 10x increase in sales from that site. So, they did something right, and a lot of it had to do with just doing one of these very open baseline professional field studies that can give you all the content and desirability insights that you need to make the right decisions.

If you just focus on the evaluation activity typically with usability testing, you're actually doing *nothing* to improve the usability of your process. You are still creating bad designs. And just filtering them out is going to be fantastically wasteful in terms of the amount of effort. So, you know, if you think about it as a production line, we have that manufacturing analogy and talk about screws. If you decide that your products aren't really good enough

for whatever reason – they're not consistent or they break easily or any number of potential problems – and all you do to *improve* the quality of your product is to up the quality checking at the end of the assembly line, then guess what? You just end up with a lot of waste because you're still producing a large number of faulty screws. And if you do nothing to improve the actual process in the manufacturing of the screws, then just tightening the evaluation process

– raising the hurdle, effectively – is really not the way to go. Usability evaluations are a *very* important tool. Usability testing, in particular, is a very important tool in our toolbox. But really it cannot be the only one.

A/B testing is all about changes in behavior. We present people with alternative designs and we look to see how much that alters their subsequent response. So in the simple A/B case, we show them design A, we show them design B, and we measure typically a completion goal, which a lot of subject areas in user experience we refer to as conversions.

So signing up to a newsletter, adding an item to a shopping basket, making a donation to a charity. These are all things that are important to their respective organizations. And typically for the interactive technology that we're working on. So websites and and apps, for example. So these are the things often that we're measuring, but they're not the only things that we can measure. We can measure really straightforward stuff like time spent on page, time spent in the site and also bounce rates.

For example, we'll be looking at some of those a bit later on. Just a reminder that because A/B testing is done very late in the day with live sites and large numbers of users, you really want to make sure that your solution is sound before you get this far. You're not going to be able to test everything that is possibly worrying you or possibly causing problems to users. It's just too long involved and potentially expensive in terms

of user loyalty and also the amount of effort you'd have to put into it. So we are looking at using A/B testing to basically polish the solution rather than to rework it. Bear that in mind and make sure that you've done adequate testing up to this point. Also, bear in mind that A/B testing tends to be focused on individual pages, so it is possible to have multi-page tests, but

it's a more complex area than we're going to be looking at in this lesson. So experiments have research questions that basically the things that you're trying to answer and because A/B testing focuses on changes in behavior, the research questions are going to be centered on defined goals. And as I've mentioned already, typically conversions. So will as an example, moving the add button above the fold improve sales conversions? I would imagine it would actually do something. I always find people

are making the mistake of getting too talkative on the first screen of the page and the actual “buy this” or “add to basket” button gets pushed further and further down until users actually don't even see it. Will a more clearly worded charitable purpose increase donations? If people have a better understanding of what your charity's about or where this money is going, would that improve conversions for those users? So both of these can be A/B tested by using goals that you almost

certainly have already defined in your analytic solution. So these are very good candidates for A/B and multivariate testing. But I'll give you some examples of bad questions too. So obviously I will repeat the words “don't ask this” when I've mentioned them because they're not meant as examples that you should be taking away. Conversely, research questions that are not directly related to improved goal completions tend not to be suitable for AB testing.

And a kind of vague question like “will better product photos reduce questions to customer service?”, don't ask this, is the sort of thing that you simply cannot effectively test in A/B testing. And the reason is that there are all kinds of channels to customer service and only some of them are through the website and only some of them can be effectively measured as goals. So it's just not a suitable scenario for A/B testing. There is a related question you could ask though,

which might be just as good, although not exactly equivalent, and that would be: “Will better product photos improve sales conversions?” Because if it reduces queries to customer service, it's almost certain that people are going to be much more confident about placing orders, adding those things to their basket. So that is a very easily measured outcome in terms of A/B testing, and that is the kind of question that A/B testing is very good at.

So simply rewording or rethinking the question in terms of defined user and business goals is one way of getting to a satisfactory conclusion, even if you have a slightly squiffy question to start with.

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.

Most people are really excited about this stage of making their portfolio and indeed it's time to work on the visual identity of your portfolio. I'll introduce here the main visual elements that you need to define and although those elements need to reflect you and your identity, I will also cover the good practices of making your portfolio easy to navigate for your visitors. Fonts and typographic scale are usually made of the following: a heading for your page titles, subheadings for your section titles,

lead text for bigger text sizes like in hero areas, your intros or quotes, body text to use for most of your content, and caption text to use as captions for your images or embedded elements. I'd like to mention that it's usually okay to choose one font that is different for your headings compared

to your body text, but I would recommend using a standard font for your body text. These fonts are standard for a reason: they are easy to read and you actually don't want to strain the eyes of your reader, especially if they've been looking at portfolios all day long. Colors I use for the following elements: text color, usually black or dark gray, don't go too light as it may make your text difficult to read and not accessible. The reverse applies if you want a portfolio in a dark

theme. A dominant color for your main call to actions like buttons and links, a supporting color for your secondary actions, usually less vibrant and less saturated than the dominant color. An accent color, if you're including illustrations or pictures, you can be intentional and choose an accent color and use touches of it for your portfolio. Some background colors, usually a combination of white and grays, to organize your content sections. Again, if you're doing a dark theme, they will

be a combination of black and dark grays. And unless you're an expert in visual design, don't go crazy with colors. Use online palette editors to help you choose and calibrate your colors. A grid system. If you're designing your portfolio for the web, you will also need to define your grid system, similar to when you do it for your digital projects. Things to consider are, for example, what's your maximum width? Do you want to center your content on one main column or use

layouts and organize content into two or three columns? You can also play with grid offsets to structure your content as long as it's consistent across your portfolio. Responsiveness, again, here for the web, you need to care about how your content is displayed on various screen sizes, usually desktop, tablet, and mobile. You can rely here on the web builder tools that you choose to use and their behaviors, or if you have code knowledge, you can do it with media queries and flex boxes.

Accessibility. Your website must be accessible. If your case studies showcase your work on accessibility but your portfolio is not, well, it may constitute a red flag for hiring managers. And finally, a logo. A well-crafted logo can be a big plus for your portfolio's visual identity. However, it is not mandatory at all. If you don't have a strong background in visual design, I would even recommend not to have any logo at all as it can be badly designed and play against you.

If you are a UX designer with no visual background at all or maybe a UX researcher with no visual background, then I would actually recommend you to use templates online. Choose one that you can customize, again using palette editors to make sure that your colors are consistent. But you can play around with that and also, as usual, get feedback on your work and iterate from there.

Design thinking is a non-linear, iterative process that teams use to understand users, challenge assumptions, redefine problems, and create innovative solutions to prototype and test. It is most useful to tackle problems that are ill defined or unknown. In a rapidly changing world, organizations must be able to adapt and innovate quickly to survive. Design thinking is a powerful tool that can help organizations to do just that. By focusing on the user and their needs, he can help teams to develop creative solutions

that meet the real needs of the people they serve. The end goal of a design thinking process is to create a solution that is desirable, feasible and viable. This means that your product should satisfy the needs of a user, be feasible to implement and have a financial model as well. During the bulk of your design thinking process, you'll focus on desirability as you are concerned with testing your ideas and validating your hypothesis about your users.

Towards the end of your project, however, you should bring the focus to feasibility and viability so that your solution can be sustainable.

Most people are really excited about this stage of making their portfolio and indeed it's time to work on the visual identity of your portfolio. I'll introduce here the main visual elements that you need to define and although those elements need to reflect you and your identity, I will also cover the good practices of making your portfolio easy to navigate for your visitors. Fonts and typographic scale are usually made of the following: a heading for your page titles, subheadings for your section titles,

lead text for bigger text sizes like in hero areas, your intros or quotes, body text to use for most of your content, and caption text to use as captions for your images or embedded elements. I'd like to mention that it's usually okay to choose one font that is different for your headings compared

to your body text, but I would recommend using a standard font for your body text. These fonts are standard for a reason: they are easy to read and you actually don't want to strain the eyes of your reader, especially if they've been looking at portfolios all day long. Colors I use for the following elements: text color, usually black or dark gray, don't go too light as it may make your text difficult to read and not accessible. The reverse applies if you want a portfolio in a dark

theme. A dominant color for your main call to actions like buttons and links, a supporting color for your secondary actions, usually less vibrant and less saturated than the dominant color. An accent color, if you're including illustrations or pictures, you can be intentional and choose an accent color and use touches of it for your portfolio. Some background colors, usually a combination of white and grays, to organize your content sections. Again, if you're doing a dark theme, they will

be a combination of black and dark grays. And unless you're an expert in visual design, don't go crazy with colors. Use online palette editors to help you choose and calibrate your colors. A grid system. If you're designing your portfolio for the web, you will also need to define your grid system, similar to when you do it for your digital projects. Things to consider are, for example, what's your maximum width? Do you want to center your content on one main column or use

layouts and organize content into two or three columns? You can also play with grid offsets to structure your content as long as it's consistent across your portfolio. Responsiveness, again, here for the web, you need to care about how your content is displayed on various screen sizes, usually desktop, tablet, and mobile. You can rely here on the web builder tools that you choose to use and their behaviors, or if you have code knowledge, you can do it with media queries and flex boxes.

Accessibility. Your website must be accessible. If your case studies showcase your work on accessibility but your portfolio is not, well, it may constitute a red flag for hiring managers. And finally, a logo. A well-crafted logo can be a big plus for your portfolio's visual identity. However, it is not mandatory at all. If you don't have a strong background in visual design, I would even recommend not to have any logo at all as it can be badly designed and play against you.

If you are a UX designer with no visual background at all or maybe a UX researcher with no visual background, then I would actually recommend you to use templates online. Choose one that you can customize, again using palette editors to make sure that your colors are consistent. But you can play around with that and also, as usual, get feedback on your work and iterate from there.