Key Performance Indicators (KPIs)

So, how do you craft your UX strategy plan? First of all, make sure you're building the business case. This is a mistake that a lot of people make. Make sure that you're clear about what your ROI is and what it *can* be, right? What are you currently getting from your UX efforts, or *lack* of efforts? Even if you're measuring Google Analytics, what are the KPIs that are relevant to *your* user experience?

And then, what *should* they be or what *can* they be? And you may need to define these as you're starting to build your practice if you're new to UX and you're just getting started. But think about what that is and make sure you define that as you go along. Don't get too excited and just start doing user testing or start doing some type of UX activity and then forget about this. You know, it's really important to remember, remember, remember. Cost-benefits analysis, as we talked about, can be helpful, but *create a template*

and *a practice for costing* so that you're requiring that as part of your project plan. We start all our projects at Experience Dynamics with *business objectives*. So, we're laying that out so we understand what we're building the UX on top of. It's important to *identify your KPIs* (your key performance indicators). *Start with small measurements*; so, don't try and boil the ocean, but start with a few small metrics to measure

– things like success rate in usability testing – as a way to kind of start gauging where you are. Success rate is the main metric from usability testing, so it makes sense that you would measure that and track that. And then, make sure to *share and review those metrics monthly*, at least. It's so important to keep your eye on the metrics, to socialize them and make sure that they get out to people who need to hear about them. So, to start with your UX strategy, you want to *map your current state*.

So, create an *assessment* of your usability and your UX practices and methods. You know – What are you doing? What are you calling UX? And that means taking a look at your product Iifecycle, your management, your staffing attributes and, of course, your UX maturity rating, which is something that you can get from a scorecard I'll be sharing with you soon. So, UX readiness and agile experience are also important to measure in terms of usability and

the UX resources that you currently leverage and the techniques, you know. Essentially you're trying to figure out how things are *done today*. So, this is a current state. How are things happening from a process map? And then, from that – and so, what's important about that is that you get the picture of where your organization "is at". This is not about forcing your organization to act in a way that I want you to act in or that – you know – some guru or some book or some video or something or some voice of Forrester or a voice of Gartner analyst group.

It's not about that – it's about what works for *your* organization. So, a *UX maturity roadmap* is what you're going to end up with. It's going to have detailed guidelines for how to grow your UX competency. And it's going to have things like staffing positions or roles that are required, specific requirements for, again, *your* organization exactly, not somebody else's, and not the organization that you worked at *before* you came here. Don't try and bring that culture over to the organization you're in. It's *so* important that it's *custom-fit* to the

conditions, to the vibrations, if you will, to the frequency of your organization. because every organization is different. It is shaped by the founder, the CEO, the senior managers, the shareholders, the industry – the specific industry, the niche that you're in. So, *UX organization next steps and action plan* are going to be what you create in this ideal state

– so, where you're marching to, where you're going, essentially.

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.

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.

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.

John Nielsen found that there's an average of 83% increase in key performance indicators from UX. UX improves KPIs. If it's not improving KPIs, then it's not good UX, right? And there are a lot of usability people who don't have an ROI background, who don't have business acumen, who don't get this.

They're busy trying to make the user feel good. That's important. But you also need to connect to key performance indication. Like, you know, write to improving your business metrics. In terms of e-commerce, you can expect to spend 10% and that 83% conversion conversion rates are normally 2%, and that's normal to have a 2% conversion rate. So we're seeing up to 15, 18, 22% and then the jumps up to 80% and 90%,

which which are just, you know, gangbusters returns intention to return. So if a user says I want to come back 60% from Forrester and stat market studies have found that and interesting to compare that to the you know how much would you be willing to spend while intention to return is incremental revenue on the back side right when they're coming back. So typically spending between 10 to 12% of dev budgets in order to get these ROI

returns. So the deal with how much you spend and how much you get back, it's the 110 100 role spend a dollar on research to make the six upfront. That's that early on user research $10 to change it during design or spend $100 to change something in development. So once you start baking and coding, you know, all the interrelationships of JavaScript kind of this and that it's actually easier to

learn about users prototype without much effort and figure out what the requirements are and validate it. Get the outside in validation before you start coding. It just makes sense. It makes financial sense. And that's why UX has become a staple in software development teams.

Ah, well – it's a lovely day here in Tiree. I'm looking out the window again. But how do we know it's a lovely day? Well, I could – I won't turn the camera around to show you, because I'll probably never get it pointing back again. But I can tell you the Sun's shining. It's a blue sky. I could go and measure the temperature. It's probably not that warm, because it's not early in the year. But there's a number of metrics or measures I could use. Or perhaps I should go out and talk to people and see if there's people sitting out and saying how lovely it is

or if they're all huddled inside. Now, for me, this sunny day seems like a good day. But last week, it was the Tiree Wave Classic. And there were people windsurfing. The best day for them was not a sunny day. It was actually quite a dull day, quite a cold day. But it was the day with the best wind. They didn't care about the Sun; they cared about the wind. So, if I'd asked them, I might have gotten a very different answer than if I'd asked a different visitor to the island

or if you'd asked me about it. And it can be almost a conflict between people within HCI. It's between those who are more *quantitative*. So, when I was talking about the sunny day, I could go and measure the temperature. I could measure the wind speed if I was a surfer – a whole lot of *numbers* about it – as opposed to those who want to take a more *qualitative* approach. So, instead of measuring the temperature, those are the people who'd want to talk to people to find out more about what *it means* to be a good day.

And we could do the same for an interface. I can look at a phone and say, "Okay, how long did it take me to make a phone call?" Or I could ask somebody whether they're happy with it: What does the phone make them feel about? – different kinds of questions to ask. Also, you might ask those questions – and you can ask this in both a qualitative and quantitative way – in a sealed setting. You might take somebody into a room, give them perhaps a new interface to play with. You might – so, take the computer, give them a set of tasks to do and see how long they take to do it. Or what you might do is go out and watch

people in their real lives using some piece of – it might be existing software; it might be new software, or just actually observing how they do things. There's a bit of overlap here – I should have mentioned at the beginning – between *evaluation techniques* and *empirical studies*. And you might do empirical studies very, very early on. And they share a lot of features with evaluation. They're much more likely to be wild studies. And there are advantages to each. In a laboratory situation, when you've brought people in,

you can control what they're doing, you can guide them in particular ways. However, that tends to make it both more – shall we say – *robust* that you know what's going on but less about the real situation. In the real world, it's what people often call "ecologically valid" – it's about what they *really* are up to. But it is much less controlled, harder to measure – all sorts of things. Very often – I mean, it's rare or it's rarer to find more quantitative in-the-wild studies, but you can find both.

You can both go out and perhaps do a measure of people outside. You might – you know – well, go out on a sunny day and see how many people are smiling. Count the number of smiling people each day and use that as your measure – a very quantitative measure that's in the wild. More often, you might in the wild just go and ask people. It's a more qualitative thing. Similarly, in the lab, you might do a quantitative thing – some sort of measurement – or you might ask something more qualitative – more open-ended. Particularly quantitative and qualitative methods,

which are often seen as very, very different, and people will tend to focus on one *or* the other. *Personally*, I find that they fit together. *Quantitative* methods tend to tell me whether something happens and how common it is to happen, whether it's something I actually expect to see in practice commonly. *Qualitative* methods – the ones which are more about asking people open-ended questions – either to both tell me *new* things that I didn't think about before,

but also give me the *why* answers if I'm trying to understand *why* it is I'm seeing a phenomenon. So, the quantitative things – the measurements – say, "Yeah, there's something happening. People are finding this feature difficult." The qualitative thing helps me understand what it is about it that's difficult and helps me to solve it. So, I find they give you *complementary things* – they work together. The other thing you have to think about when choosing methods is about *what's appropriate for the particular situation*. And these things don't always work.

Sometimes, you can't do an in-the-wild experiment. If it's about, for instance, systems for people in outer space, you're going to have to do it in a laboratory. You're not going to go up there and experiment while people are flying around the planet. So, sometimes you can't do one thing or the other. It doesn't make sense. Similarly, with users – if you're designing something for chief executives of Fortune 100 companies, you're not going to get 20 of them in a room and do a user study with them.

That's not practical. So, you have to understand what's practical, what's reasonable and choose your methods accordingly.

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.

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.

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.

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.

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.

So feelings clearly matter in a user interface. That's why we worry about user experience. But depending on the kind of product, the kind of service, the kind of system you're creating, then feelings matter in different ways. So I'm going to distinguish two major ways this can be. So first of all, where emotion is the primary goal of what you're designing.

So eliciting that emotion is the very purpose of the product. So think about art. Think about games, entertainment applications in general. What you're trying to do is create a *sense of emotion* in the person. That's the primary goal. Other things are secondary. Now, in order to satisfy that primary goal, you often need to get *good functionality* and *good usability*.

So when you’re wanting to choose what movie to watch, you want to be able to find, perhaps, the box set that you know is there and the right episode of it as efficiently as possible. So you still have these fundamental usability requirements, even if the primary goal is emotion. But it's often the things that serve that. So think about again, if you're going to share a picture you just taken a picture of, whether it's a meal you're eating

or your cats or whatever else you're wanting to share, the sharing is about the emotional impact that you're wanting to pass on to other people, to your friends, and to your family. However, when you take that photograph, you want a very efficient, slick and easy process to actually get that shared on your social media channels. So, again, although emotion is the primary purpose of what you're doing, you still need the usability and functionality in order to support that process.

Alternatively, emotion might be a secondary goal. So the primary purpose might be something that's more, shall we say, business like. It might be about your work. So like I'm doing now, producing this video, it might be about office work, might be using a spreadsheet, using a database, might be about getting your money from the ATM and get the money out of the hole in the wall.

It might be about paying using your card in a restaurant. But the thing you're trying to do at that point, the primary goal is to get the thing done efficiently and effectively. However, typically, emotions help. They help in the sense that if you're doing, say, a repetitive job, then being alert is important. You know, this is true whether you're a policeman on the beat and watching out, or a soldier in a battlefield situation.

Whether you're driving your car and needing to sort of have a little bit of peripheral awareness. So emotion helps you do that. It helps you keep alert so that you're ready for things. So if you think about online shopping. Some of online shopping is about getting the job done and getting the thing purchased. But there's also an aspect of shopping, this is particularly true of offline shopping. Of when you go into a clothes shop where

the actual process of doing the shopping is part of the joy of the shopping. It's harder to do that online, incidentally. But there are some brands where that is the thing you’re trying to do. You're trying to create a sense of identity in the brand, a sense of joy in exploring it. So within the same kind of application area, online shopping, depending on the brand and depending on the person's need at that moment,

you might want to emphasize one or the other.

*When and Why to use Analytics* Primarily, we're going to need to be using  analytics on existing solutions. So, if you're talking about *green field* – which is a brand-new solution, hasn't been built and delivered yet –  versus *brown field* – which is something that's  already running but perhaps we want to improve it – then we're decidedly on the brown field side.

So, we're looking at existing solutions because it's only existing solutions that can provide us with the analytics. If you haven't got an existing solution, you're going to have to use another technique. And there are obviously many other techniques, but they're not going to provide you with much in the way of *quantitative data*. We do have early-research methods, which we'll  be talking about very briefly as an alternative, but predominantly analytics for existing deployed  solutions.

Having said that, then if you're looking at a rework of an existing site or app, then looking at current analytics can tell you a lot about what you might like to address; what questions you might like to raise with your team members, stakeholders, users. So, those are important considerations. A good starting point in organizations or teams with low UX maturity is analytics because analytics are easier to sell – to be honest – than qualitative methods.

If you're new to an organization, if they're only just getting into user experience, then trying to persuade colleagues that they should be making important decisions on the basis of six to eight qualitative sessions, which is typically what we do in the usability lab, then you should find by comparison web analytics a much easier thing to persuade people with. And the other issue particularly relevant to qualitative methods

is that quantitative methods tend to be very,  very much cheaper – certainly on the scale of data, you are often having to talk in terms of  hundreds of dollars or pounds per participant in a *qualitative* study, for various expenses; whereas a hundred dollars or pounds will get you potentially hundreds or thousands of users. And, in fact, if you're talking about platforms like Google Analytics which are free, there is no cost other than the cost of understanding and using

the statistics that you get out; so, obviously  it is very attractive from a cost perspective. Some of the things that we'll be needing to  talk about as alternatives to analytics or indeed *in addition* to analytics: Analytics can often *highlight* areas that we might need to investigate, and we would then have to go and consider what alternatives we might use to get to the bottom of that particular problem.

Obviously, *usability testing* because you'll need to establish *why* users are doing what they're doing. You can't know from analytics what users' motivations are. All you can know is that they went to *this* page and  then they went to *that* page. So, the way to find out if it isn't obvious when you look at the pages – like there's something wrong or broken or the text makes no sense – is to bring users in and watch them actually doing it, or even use remote sessions – watching users doing the thing that has

come up as a big surprise in your analytics data. A/B testing is another relatively low-cost approach. It's – again – a *quantitative* one, so we're talking about numbers here. And A/B testing, sometimes called *multivariate testing*, is also performed using Google Tools often, but many, many other tools are available as well; and you show users different designs;

and you get statistics on how people behaved and how many converted, for example. And you can then decide "Well, yes, putting that text there with this picture over here is better than the other way around." People do get carried away with this, though; you  can do this ad nauseam, to the point where you're starting to change the background color by minute shades to work out which gets you the best result. These kinds of results tend to be fairly temporary. You get a glitch and then things just settle down afterwards.

So, mostly in user experience we're  interested in things which actually really change the user experience rather than getting  you temporary blips in the analytics results. And then, finally, *contextual inquiry* and *early-design  testing*: Contextual inquiry is going out and doing research in the field – so, with real users doing real things to try to find out how they operate in this particular problem domain; what's important to  them; what frustrations they have;

how they expect a solution to be able to help them. And early-design testing – mostly in the web field these days but can also be done with software and mobile apps; approaches like *tree testing* which simulate a menu hierarchy. And you don't actually have to do anything other than put your menu hierarchy into a spreadsheet and upload it – it's as simple as that; and then give users tasks and see how they get on.

And you can get some very interesting and  useful results from tree testing. And another early-design testing approach is *first-click testing*. So, you ask users to do something and you show them a screenshot – it doesn't have to be of an existing site; it can be just a design that you're considering – and find out where they click, and is where they click helpful to them? Or to you? So, these are examples of early-design testing – things that you can do *before* you start building

a product to work out what the product should look  like or what the general shape or terminology or concepts in the product should be. And both of these can be used to find out whether you're on the right track. I have actually tested solutions for customers where users had no idea what the proposition was: "What does this site do?"; "What are they actually trying to sell me?" or "What is the purpose of it?" – and it's a bit late to be finding  that out in usability testing towards the end of a project, I have to say. And that was indeed  exactly what happened in this particular example

I'm thinking of. So, doing some of these things  really early on is very important and, of course, is totally the opposite of trying to use web analytics, which can only be done when you finish. So, do bear in mind that you do need  some of these approaches to be sure that you're heading in the right direction *long before* you  start building web pages or mobile app screens. Understand your organization's *goals* for the interactive solution that you're building.

Make sure that you know what they're trying to get out of it. Speak to stakeholders – stakeholders are people typically within your organization who have a vested interest in your projects. So, find out what it's supposed to be  doing; find out why they're rebuilding this site or why this mobile app is being substantially  rewritten. You need to know that; so, don't just jump in and start looking for interesting numbers.

It's not necessarily going to be that useful. Do know the solutions; become familiar with them. Find out how easy it is to use them for the kinds of things which your stakeholders or others have told you are important. Understand how important journeys through the app or website work. And get familiar with the URLs – that's, I'm afraid, something that you're going to be seeing a lot of in analytics reports – the references for the individual pages or screens,

and so that you'll understand, when you actually start looking at reports of user journeys, what that actually means – "What do all these URLs mean in my actual product?" So, you're going to have to do some homework on that front. You're also going to have to know the users – you need to speak to the users; find out what they think is good and bad about your solutions; find out how they think about  this problem domain and how it differs from others and what kind of solutions they know work and what  kind of problems they have with typical solutions.

Also ask stakeholders and colleagues about known  issues and aspirations for current solutions. So, you know, if you're in the process of rebuilding  a site or an app, *why* – is it just slow-ish? Is it just the wrong technology? Maybe. Or are there things which were causing real problems in the previous or current version and that you're hoping to address those in the rebuild.

A portfolio is a collection of  work and projects curated by you   to showcase your skills, experiences, and  achievements. Think of it like a friend:   it's your best advocate. It tells your story,  it introduces you without you being around,   and, if you're looking for a job, it's  a key tool to get noticed and hired.

Cross-functional teams, unlike silos, have all the people necessary to build a specific thing together. Let's look at an example. Imagine you're on a team that is supposed to build the onboarding flow for a new app that helps connect job applicants with jobs. You can't build the whole thing with just designers. Or with just engineers, for that matter. I mean, you probably could do it with just engineers, but it's a terrible idea.

A cross-functional team for this onboarding work might include a few engineers, perhaps some for the front end and some for the back end. Might include a designer, a researcher, a product owner or manager, maybe a content writer or a marketing person. In an ideal world, all of these folks would only work on this particular team. In the real world, where we actually live, sometimes folks are on a couple of different teams and some specialists may be brought in to consult. For example, if the team needed help from the legal department to explain some of the ramifications of a specific decision,

a cross-functional team would have a dedicated legal expert they could go to. But that legal expert might also work with lots of other teams. In agile environments, the cross-functional team generally sits together or if remote, has some sort of shared workspace. They all go to the required team meetings. They understand the goal of the team and the users. They're experts, or they soon become experts, on that onboarding flow. Contrast this to how it might be done in a siloed environment. In that case, you might have different people assigned to the team depending on need, which can seem really flexible.

Until you realize that you end up with five different designers working on the project all at different times and they all have to be brought up to speed and they don't really understand why the other designers made the decisions that they did. Same with the engineers. And do not get me started on legal. Silo teams tend to rely more on documentation that gets handed between groups. And this can lead to a waterfall project where project managers or product managers work on something for a while to create requirements, which they then hand off to designers who work on designs for a while

and then they pass the deliverables on to engineering, who immediately insists that none of this will work and demands to know why they weren't brought in earlier for consultation. You get it. By working in cross-functional teams instead, the people embedded on the project get comfortable with each other. They know how the team works and can make improvements to it. They come to deeply understand their particular users and their metrics. They actually bring engineering and even design and research into the decision making process early to avoid the scenario I described above.

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.

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.