The Business-To-Consumers (B2C) Model in UX/UI Design

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.

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.

I wanted to just spend a little bit of time on the *user journey*. So, we can see how important user research is to creating really compelling value propositions and creating value for organizations that are trying to use service design to innovate, improve, streamline and smooth out. Well, there's nothing better to tackle that with than the user journey.

I wanted to just spend a little bit of time on this technique in case you didn't have that much experience with it or maybe you were doing journeys in a way that was different to the way I'm going to present to you. At least, I just wanted to share a template with you that can give you better access to what you're looking for. For me, now, a journey is something that you *build on*. So, first off it's your *customer journey*.

And on that is your service blueprint. And remember that the journey is going to reveal those cross-channel like, say, *breakpoints*, *pain points*, *disconnects* that you can map in the different *swim lane diagrams* – is the official term for a journey map. So, it comes from that – these swim lanes. And so, you'll have like maybe your channels here – you know – you'll have your user tasks here, pains and gains, or you can just have positive (+) or negative (-).

And I tend to change my user journeys, try and improve them, try and improve them. One of the problems that I find with journey maps – and they became very popular, I think around 2010, maybe, was the heyday of user journeys – 2010 / 2012, maybe. It was all about this beautiful big visualization. Let's be clear: A customer journey map is *not* about impressing your team

with really cool, big swim diagram visualizations with tons of little icons. It's a document like all deliverables in a human-centered design perspective. It should work for the internal teams that are using it as a decision-making document *as well*. The thing about the journey map that's particularly of value to the service designer is that it's happening across time

or across stages or across goals. So, the stages of, say, the life cycle – you know – you might have Research, Compare, Purchase, then the Return shopping. In other words, it's not just the purchase. A lot of conversion optimization and approaches to selling online just focus on this part here: the compare and purchase, or the funnel – if you will – the purchase funnel. And I think it's important to have the acquisition as much as the retention.

This is the conversion here. So, these two steps are the conversion steps. It's important to have *all* those steps represented. *Happy / sad moments* – you can have a little smiley face; *disconnects and breaks* – you know – so that you're like: "Ah! This is a break right here. They're on their phone, and they're researching, but the site's not responsive or it's *partially* responsive. And then, compare – when they go to compare, it only allows three items. So, it's like "Ohh!" – and then we have a quote from the user going:

"Why does this only allow (imitated mumbling)?!" – you know – something communicating the pain point. The other thing it's going to have is your reflections from your ethnography, from your personas. It's going to have those real-world contexts, basically. Instead of basically making it up and doing it internally, you're going to base it on user data. You'll also want to have *recommendations*. So, down here at the bottom you can have a list of recommendations

as well. This is an example of a journey map we created. And you can see the touch points we've added along the way. So, we have these different stages. We've got this – as the user walks through. So, we have Pre-apply, Apply, Post-apply. This is an online application journey. And we have the various channels that are occurring there. We've got the pain points represented. And the steps are:

Discover, Research, Apply, Manage and Dream. Discover was important because a lot of people didn't know that the offers were there. This is for getting an account. And basically the value proposition is you're going to have these offers – targeted offers – sent to you. So, the key is to find out how people are currently applying and at what stage makes sense to offer them these upsells, basically. And that's the value add that's being offered here.

There's a part of the brain where emotions are processed. And if that part of the brain has damage, people can't decide at all. It's the ventro-medial pre-frontal cortex (vmPFC). And sometimes this part of the brain is not working because of perhaps disease or injury. And when that happens, people don't feel emotions; they just don't feel anything emotionally. And interestingly, when that happens, they also can't make any decisions,

like not even deciding what they want for dinner. So, we know that there's a *connection between feelings and decision making*.

Qualitative is primarily about words, is about what user say and what we observe users doing. And we tend to write those notes down. We don't tend to count them very much. Sometimes we do in reports on qualitative data say “n users did this”, but really we have to take that with a pinch of salt. The numbers just aren't large enough to be statistically relevant. We should be focusing much more on what people are saying and the kind of

feelings and behaviors are involved rather than how many did certain things. Qualitative research is sort of the norm in social research and certainly has been in most user research. It is primarily about attitudes and behaviors. It's usually done with fewer than ten participants. The standard number for a day of user testing on the usability side of things is around six, six or seven, which is also partly to do with the fact

that that's how long it takes you. You need to allow about an hour per participant to do any meaningful amount of testing of a new product or a new iteration of a product, useful sources of ideas and explanations. This is what we get out. People of stumble on a particular task and they have said certain things that we've observed them doing certain things like they clicked on a vague word or icon and ended up on the wrong page and then realized their mistake

and went back. That's the kind of things that we get out of qualitative research. We cannot get that from quantitative. All that we can know from quantitative in most cases is that they went the wrong way and we don't know why. They won't have given us any explanation of why they won't even we won't even in some cases know what it was they were trying to do. Now, that's not true in testing tools like Early Early-Design Testing, fFrst-Click Testing is an example of that. Tree Sorting is an example of that. We can see where they were.

We given them the task and so we can see what it is they're trying to achieve and we can see where they went and we can get some feedback from that. We can kind of derive our own feedback about perhaps that term being a little bit misleading because 30% of our hundred users went the wrong way on the first attempt. So quantitative can be important, but typically when we're talking about face to face user testing, we're focusing on on qualitative and we expect

to have quite a rich set of results in terms of what people said. We typically, in qualitative research, ask people about the experience, which can also be very helpful in terms of where do we go now? How do we change this solution to be better for our users? And in many cases, the qualitative research is a precursor to much larger scale quantitative research. So it's a good plan. Typically to have some ideas about what's going to happen

when we launch this particular research project on a thousand or several hundred of our unwitting participants. Quantitative. Well, obviously the focus here is on numerical results and described using statistics and making sure that when we have got differences between Group A and Group B, maybe Group A are the people who converted, they checked out or donated to our cause and Group B that the difference is a large enough that we actually can call them statistically significant.

Normally when we're talking about quantitative results in the order of around about 30 participants or more, in some cases you might get away with 20. But 30 is really a good starting place for quantitative. And of course, when we start to talk about AB testing and web and app analytics, we will have available to us statistics from thousands, if not tens of thousands of users given a large enough period. So numbers don't need to worry us there, but they can be a concern when we're

trying to recruit enough participants for particular kinds of testing.

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.

We're going to be looking at how analytics  fits into the user experience profession. It's been around for a long time. Analytics have  been around for as long as the web, obviously. And so has usability and user experience. They've been around since before – *long before*, in fact, if we're talking about usability. But the two have really not come very much into contact with each other until fairly recently – I'd say in the last five or seven years,

we're starting to have much more interest in analytics from a user experience perspective. And bear in mind that analytics is really quite a big topic and that  there are people who spend their entire lives looking at analytics. We're obviously going  to be skimming the surface somewhat, but from a user experience perspective. So, the kinds of things that we're hoping to get out of analytics, whether we're talking about web  or mobile app – I'm not going to differentiate

between the two very much. In fact, Google Analytics treats them pretty much as   equivalent. But the kinds of things we can get out  are largely around the area of behavioral data – which is obviously of great interest to us from a user experience perspective. But we'll also be looking at some of the other kinds of data – typically demographic – which also can be useful for user experience. So, *bounce rates* is a number that is often quoted in analytics circles.

It's how *often people appear* at a page on your  website and then *immediately disappear*. So, they've bounced. Obviously, it's very disappointing for  web designers to see that they've got high bounce rates on certain pages; and, of course, it can be a  variety of issues that leads to that happening, and that's really one of the challenges facing us from  a user experience perspective: Is it the content? Is it stuff that directed people to our site without our particularly being aware of it?

Is it faulty information? What kinds of things go on? *Conversion rates* – really the queen of statistics from an analytics perspective: Are people doing what you want them to do? That's what a conversion is. Are people coming to your website and buying stuff? Or subscribing to your newsletter? Or voting for your candidate in whatever kind of organization this might be? Those are all examples of conversions. And, from a UX perspective, we tend to think of those as achievement of goals, and

there is also the question, which we'll be talking a bit  about later on, of our organizational goals versus users' individual goals; hopefully, those are aligned, but they may not be; and sometimes the analytics can help us with that. *Repeat usage* – how often  people come back; obviously very important for most websites – we don't want people just dropping  in and then disappearing forever. We really would like them to engage with our content in most cases.

*User profiles*, *demographics*, *platforms* – these are all the kinds of things that the analytics tools can tell us. And some of this information has been available since year dot in the web arena – information that's passed back to a web server by the browser, for example. But it has become much more elaborate and much more sophisticated of late, especially with platforms like Google Analytics  doing a lot of that work for us. *Search behavior* – this has become a little bit complicated in recent years,

mostly because the search information used to be passed in with the request for a page. So, if you went to Google or Bing and you typed in a search string and then clicked on one of the resulting links, the search page would very kindly tell the server what the user was searching for at the time, but for various reasons that isn't happening so much now – some of it for information privacy reasons.

So, search behavior is dealt with slightly differently these days. We're not going to go into great detail on that particular topic, but if you're working with Google Analytics, which  is what we're going to be using as an example of an analytics platform, then rest assured that  you can get to the search behavior, but it involves integrating Google's search analytics with the web analytics for your interactive solutions. *User journey* is obviously very interesting from a user  experience perspective –

Where are people going? What kind of people go where? How long are they spending at various locations? Does visiting one page or another improve or decrease the chances of them actually converting – buying something or signing up, what have you? Analytics is a really huge field,  and we're going to be just kind of skimming in and looking at some of the highlights there and  trying to understand how it all fits in. So, how this data is collected and reported

– what's good about it? What's bad about it? There are inherent weaknesses in some of the data that we're going to  be looking at, and you obviously need to know and understand that. And that is one of the things that  I'm planning to do for you – is to point out some of the really important weaknesses and obviously some of the important strengths, too, but a lot of this data can be very helpful when it comes to locating and possibly even fixing user experience problems.

A value proposition is a clear statement that  explains how something, like a product or service,   or someone, solves a problem or meets the need  of someone else and provides an opportunity for   a specific audience. So, basically, it should  answer the question: why should people care?   Why should your product or your service be more  interesting than others and the competition? And  

if you're a candidate, thinking about your value  proposition again compared to other candidates,   and thinking about what sets you apart, maybe  you have some specific skills that employers   will need, or maybe you have some specific  experience that others don't have. For example,   if you worked in international markets and  maybe you know the behavior of certain types   of customers, this is something specific  that many of the designers may not have.

Having a content strategy is the opposite of  designing or writing something at random.    When you have a content strategy, you will study, plan, and  develop the content so that it aligns with your   goals and your target audience. For example, if  you want to be hired in the fintech industry, you   will want to show more of the dashboard work that  you've done or anything done on complex design.

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.

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.

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

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.

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.

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.

This new narrative starts with *identifying your audience and intent*. The way you pitch an idea to a client, peer or executive requires an *adjustment to your language and approach*. Client – they're more of an occasional traveler. They don't know the system; they don't know the ins and outs. They're less likely to share your language.  I mean, you're probably speaking design. They speak business and outcomes and results. So, you may need to establish a basic level of understanding.

Clients and executives are also less patient  and don't want to waste 20 minutes going through every single detail just to get to the answer. Karen's what you would call an occasional traveler. She expected high-fidelity visual comps and just had a bottom-liner approach. Karen's one of these busy executives. She doesn't have time for – nor does she need to or want to hear – all the details. She just needs to know *why she should care*, *why it matters to her line of business*,

and then she can decide to support your proposal ...or not. Now, the last time the team had presented to Karen, they spent the *entire 60-minute meeting* walking  her through *their process* and *justifying their decisions*. If you know anything about executives – a 60-minute meeting; *not* a good idea. Here's the rub. They never addressed the value of the business, and the team didn't come in with a clear ask.

In the own words of the team, it was the most grueling 60 minutes of their entire careers at this company. So, what do we do? Well, this time around, we started with audience and intent. We changed the story and wrote a new  narrative and developed a new plan. We started with the *intended outcome* with Karen, shared a few *stories* and then highlighted the *value* that our approach would bring to her business – and quickly gained approval from her. And I'll never forget the moment; it was like eight minutes into my presentation.

I actually looked down at my watch to check, when Karen interrupted me mid-sentence and said, 'Okay, Todd – I get it. You've done your homework; you've clearly shown how the solution solves the problem and how it's better than my original idea. What do we need to do to move forward?  What do you need from *me* to deliver this?'

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

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

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

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

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

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

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

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

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

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

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

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

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.

Do you know this feeling? You have a plane to catch. You arrive at the airport. Well in advance. But you still get stressed. Why is that? Designed with empathy. Bad design versus good design. Let's look into an example of bad design. We can learn from one small screen.

Yes, it's easy to get an overview of one screen, but look close. The screen only shows one out of three schools. That means that the passengers have to wait for up to 4 minutes to find out where to check in. The airport has many small screenings, but they all show the same small bits of information. This is all because of a lack of empathy. Now, let's empathize with all users airport passengers,

their overall need to reach their destination. Their goal? Catch their plane in time. Do they have lots of time when they have a plane to catch? Can they get a quick overview of their flights? Do they feel calm and relaxed while waiting for the information which is relevant to them? And by the way, do they all speak Italian? You guessed it, No. Okay. This may sound hilarious to you, but some designers

actually designed it. Galileo Galilei, because it is the main airport in Tuscany, Italy. They designed an airport where it's difficult to achieve the goal to catch your planes. And it's a stressful experience, isn't it? By default. Stressful to board a plane? No. As a designer, you can empathize with your users needs and the context they're in.

Empathize to understand which goals they want to achieve. Help them achieve them in the best way by using the insights you've gained through empathy. That means that you can help your users airport passengers fulfill their need to travel to their desired destination, obtain their goal to catch their plane on time. They have a lot of steps to go through in order to catch that plane. Design the experience so each step is as quick and smooth as possible

so the passengers stay all become calm and relaxed. The well, the designers did their job in Dubai International Airport, despite being the world's busiest airport. The passenger experience here is miles better than in Galileo Galilei. One big screen gives the passengers instant access to the information they need. Passengers can continue to check in right away. This process is fast and creates a calm experience,

well-organized queues help passengers stay calm and once. Let's see how poorly they designed queues. It's. Dubai airport is efficient and stress free. But can you, as a designer, make it fun and relaxing as well? Yes.

In cheerful airport in Amsterdam, the designers turned parts of the airport into a relaxing living room with sofas and big piano chairs. The designers help passengers attain a calm and happy feeling by adding elements from nature. They give kids the opportunity to play. Adults can get some revitalizing massage. You can go outside to enjoy a bit of real nature.

You can help create green energy while you walk out the door. Charge your mobile, buy your own human power while getting some exercise. Use empathy in your design process to see the world through other people's eyes. To see what they see, feel what they feel and experience things as they do. This is not only about airport design. You can use these insights when you design

apps, websites, services, household machines, or whatever you're designing. Interaction Design Foundation.