UX Design Processes

In this short video, we're going to look at the *process of interaction design*. Now we're going to talk about the steps you go through in order to create a new interaction, a new intervention. If you talk to interaction designers, they'll all have different ways of doing things. However, the general steps are not identical for each person, and they're not identical for each kind of process. But the general flow is fairly similar,

and we'll talk through a particular example. But you'll see slight differences if you look at it in different textbooks or talk to different professionals. There's basically a flow here from on the left-hand side, looking at the current situation and what the user needs, to on the right-hand side, actually creating some sort of artifact or system or piece of software or website that is actually fulfilling that need. So, that's the general flow. It's from need to fulfillment. There are complications – sometimes it works slightly the other way around.

But we'll take this, the most common flow through. What is it that's wanted? If you don't know what somebody wants, how can you produce something for it? And it seems obvious that that should be the case. But it's easy to *assume* you know what people want without even thinking about it. But there are different kinds of things. Sometimes, you go and watch people, observe what they're doing. You might interview them – talk to them,

look at some of the materials and some of the software or some of the systems they're already using. There are particular techniques – so, interview techniques; ethnography, which comes from anthropology. One particular problem that we often get when looking at the way people do things now is a tension between the current systems and the understanding we currently have and what is possible in the future. And it's quite often difficult for somebody to envisage that future.

So, having decided what's wanted, then there is usually some form of analysis stage, of making sense of that and sorting it, ordering it, giving it some sort of structure. Sometimes, that's more narrative things and sort of stories of how somebody uses a system. Sometimes, it's more structured. So, task analysis is more breaking down of what somebody does into separate steps and sub-steps.

So, there are different ways of doing this analysis, of "making sense" stage. Then you get on to actual design: What is it that we're going to produce? And that seems the most exciting and fun bit! Again, there are different techniques that you can use to help that. There are different guidelines you can use that say what kinds of things work for what kinds of problems. So, if you go to look at a lot of websites,

there are guidelines for how to design those, what are the appropriate techniques to use – some sort of more fundamental principles of design. Things like – for example, a principle might be giving somebody feedback once they've done an action. So, if somebody doesn't have feedback, they'll perhaps think something's gone wrong, it hasn't worked and try to do something else, when perhaps it's happened all along. And also a lot of techniques for managing the dialogue or navigation between pages,

between screens, the ways in which people interact. So, a variety of things happen in that design process. And that's sort of the micro-design – actually producing it. But having got an idea for what it is you want, then the normal next step is not just to deliver that to the user, but to create some sort of prototype system. Sometimes, that's no more than a sketch on a piece of paper that you show to someone. Sometimes, it might be a physical mock-up.

Product designers use blue foam. Or you might use a 3D printer or just cardboard to show somebody what something is going to be like. You might use Flash or some webpages to step through the major views, or even create software that is using programming, using quite detailed work, but it's still not necessarily the final system, but something to give somebody an idea of what it's going to be like. Now, the reason for this prototyping stage is that

*you never get it right first time*. Because people are people – you don't fully understand situations; you don't fully understand people. If you could really early on, then perhaps you wouldn't need it. If you have a perfect understanding of who people are, what they want, then you could just go and create it. But we never do. So, we always need to go through these stages of looking at something, finding out whether it works. To do that, we need what's called *evaluation*. You need to look at it.

And that might involve giving it to a user and saying, "Try it out." Sometimes, you give it to an expert – somebody who has a lot of understanding of the users – and use some heuristics and some methods and rules to look at it and ask questions. OK, that normally leads back into the analysis stage. You reanalyze the results of that evaluation. You use that to modify the design. You prototype again. You go round and round that loop. Sometimes, though, it gives you a more fundamental understanding.

So, the prototypes can just feed back in design. But sometimes they feed right back into reasking that question about what is wanted. So, this is particularly the case when it's a novel technology. So, you've got a new situation. It's not easy to know exactly what might be needed. I've got an example of this that goes back many years; so, you have to sort of adjust people's ideas.

And this was my first job as a practicing computer person. And it involves printouts – not web, not systems on a computer, but printouts from a computer. I was working in a County council – local government. And the Pensions Department wanted to add a few extra columns to the printout that they had each year that was used when they got to the end of the year.

Now this was on old, green-and-white-striped, 132-column paper. The head of the Pensions Department came to my office, and we talked about this for approximately one hour. And we were after three additional numbers; it wasn't that complicated. We decided at the end exactly what we wanted. And he was satisfied that I understood what he wanted. However, several times during that conversation I'd asked the question, "What is it that you use these numbers for?" Now, he must have answered, but I never felt satisfied to myself that I understood.

So, I knew what was wanted in terms of the printout, but not what it was for – not how it fitted into the bigger picture. Some time later, I modified programs. I produced a fresh list. I had an example list out – this is the prototype. And I rang him up and I said, "I've got the list out." And he said, "Oh, shall I come to your office?" And I don't know why – I didn't know the right things at this stage; I was very, very naive, very new to it all.

But I, perhaps by accident, did the right thing and I said, "Shall I come to *your* office?" So, I went to his office, which was himself plus a group of sort of clerical assistants who did work around. And I asked, and he looked at the printout and he looked at the numbers, and he said, "That's great!" And he was happy. He would have gone away happy at that point. But I asked again the question "What do you use it for?"

And he said, "Ah!" There was a big case of little filing cards; it had drawer after drawer of little 5-inch-by-3-inch filing cards. And he said, "Oh, we've got one card for each person: for each pensioner in the local authority. And what we'll do is we'll take out the card, we'll look at the line on the listing." And, pointing at the listing, he said, "We'll add this number to this number, take away that and write it down."

And I said to him, "Would you like me to give you that number?" And he looked at me and said, "Can you do that?" He didn't understand listing technology. Nowadays, it's a different set of issues. But even then, I think there was a – one of the problems, which is the common one, is the difference between what you see on the screen and what's inside the system. And it was a variant of that issue, so I think it's an issue that's still live. However, the crucial thing was *in his workplace*,

in the place where things were happening, he was able to articulate – and also, with the example in his possession. So, the prototype, in the context, enabled him to make sense of how it could change his work practice in a way that when we discussed it in the abstract, he couldn't do. So, that's line printers – a long way ago. But this is an example of what's now called a *technology probe*. This is when you create an artifact that allows people to see the potential.

So, for instance, on the island I live on – Tiree – I've been working with people on the island to produce a mobile application for the local historical archives. One of the first things we've done is created a small, handcrafted – not using back-end data, but handcrafted – not really what it will be like in any strong sense, but something to give an idea of what it will be like to have that mobile application

– so that, by having that, you can *begin* to have the conversations about what's possible. They change your view by – it's probing people, giving them the *tool* to see what's possible through giving them a technological artifact. OK and finally, having decided that you've got it good enough – not perfect, perhaps, but good enough – you then want to go on to implement and deploy it. Now, for that you *do* need a precise specification.

Early on, things can be a bit fuzzy. But in the end, as you deploy you need to know what you're going to deploy. Otherwise, what's going to happen is somebody who's going to be programming the system – it might be yourself; it might be somebody else – is creating that system, programming it or making the hardware around it: the physical hardware. And if you have not made the design decisions, they will make them without realizing they are. So, it's very important that they know precisely what they should be producing.

And there are additional things that often happen at that stage. There's the underlying software architectures that are crucial; documentation and help systems, although arguably you should be thinking about that during the design stage; maintenance – you know – are there going to be help desks? And recall it was the *intervention* that ultimately you design. So, in some sense, at the end of what's written here as the design process, and after you've implemented it, what you have is the artifact.

It's all these other things that go together to create the intervention in people's lives that changes it.

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.

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.

AI can hallucinate and its behavior cannot be predicted most of the time. We can't anticipate what the user will be presented with as we can in a traditional interaction system where we design the interactions and the messaging step by step conventional user experiences are controllable. We understand and decide what happens next.

With AI, we have to accommodate surprises and equally important, communicate the risk for upfront setting the right expectations about performance, indicating whether the product learns over time, clarifying that mistakes will happen and that user input will teach the product to perform better and so on. Don't omit this transparent initial communication as AI systems operate with uncertainty, and if your users expect deterministic

behavior from a probabilistic system, their experience will be degraded. Another major problem is trust and transparency. People have a hard time trusting objects that feel magic. We can't trust what we can't understand. AI systems are not transparent to us for multiple reasons. For once, most of us lack the technical knowledge to actually understand what goes on under the hood. Second, and more importantly, many times with generative AI,

we have no idea where the information is coming from. Tools like GPT and Bard have the power of constructing answers that feel legitimate and sound very pertinent, but can be entirely made up and inaccurate. AI doesn't tell us how they've constructed an answer which would help. And maybe as designers, we should push for this transparency in generative AI, exposing a high level thinking process that gives us the information sources

and general reasoning that's behind an answer. Another reason that adds to the mistrust is how AI is communicated in the media. A Google algorithm that classifies people of color as gorillas, a Microsoft chatbot that decides to become a white supremacist in less than a day, a Tesla car operating in autopilot mode that resulted in a fatal accident. We've seen these isolated but terrible experiences. Sometimes the AI systems are described as black boxes,

so maybe the solution is opening them up. Companies such as Google, Airbnb and Twitter already released transparency reports about government requests and surveillance disclosures. A similar practice for AI Systems could help people have a better understanding of how algorithmic decisions are made. The last problem I want to mention is ownership and intellectual property. This, for me is a fascinating, a very important debate.

I want to start by saying that with so much AI generated art, what we'll all witness is a significant shift in what we value as a society. And to illustrate this argument, I want to give the example of Mona Lisa. Borrowing this from Mark Rolston. If you think about it, AI could basically recreate a one on one replica of Mona Lisa without any identifiable differences. Could actually make it better, more symmetrical, more technically impressive, and so on.

But it won't be Mona Lisa. If we know and in the future, AI art will probably be labeled as per regulations that are not yet in place but are needed. Adobe is already adding those labels. More will follow If we know that it has been generated by AI and we look at it, we probably won't feel too much. But if we're in front of Mona Lisa at the Louvre, we know this was made by da Vinci 500 years ago.

We can see the fascination of the people around us, their excitement. We ourselves can experiment our own version of interpreting and looking at it. We're humbled by being in front of this work of art that has been worshiped by humanity for hundreds of years. It has the potential of being an almost religious, fundamentally human and very touching experience, which is very unlikely to be experienced towards AI art. We will value what is human made.

We will know that something was created from a person's experience, suffering, imagination, hope, scarcity is not what will make art valuable. Its creator is. And then there's another layer to this debate. If AI creates art based on everything it knows from the work of other artists is that such a different expression of creativity from that of a person who has been in art school, studied Picasso, Matisse, Mondrian.

And then their style is influenced by the art history and the works they studied. Something to think about. I'm not saying theft is acceptable, which takes us back to the need for a more transparent, cited, source exposing system for generative AI. But I want to give a different angle on how art is built.

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.

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

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

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

In the very beginning, when I first started  becoming a designer, which was the 1980s, I was concerned about the early adoption of computer systems which were really almost impossible for anybody to understand. Even the experts who designed them were making errors in using them. And there's a famous case where the early Unix  systems had a text editor

that was called 'Ed', for 'editor'. You could type away and type your program  or your text, whatever you were doing, and spend several hours typing it. And you'd have this wonderful document. And then you (say), 'Ah, I'm finished!' and you turn off the machine and go home. And you come back the next morning to continue, and... it wasn't there. Well, why wasn't it there? Because you *didn't save* it. And, well, you mean... The system doesn't bother to tell you when you try to turn it off that 'Hey – you want to save the information?'

It was little things like that that were so frustrating. In the early days, what we did was we tried to study the people who used these complex systems. And it was not just computer systems; I actually started off studying *nuclear power systems*, some of the nuclear power accidents where the control rooms were so badly designed that if you wanted to cause an error, you could not have done a better job in designing something to cause errors. And then *aviation safety*,  where lives were at stake; many lives were at stake, and there were a huge amount of research and work done.

And that was a really good place to work. I worked with the American National Aeronautics and Space Administration (NASA). Most people think of NASA as shooting rockets up into space, but they forget the first two letters, 'NA', are 'Aeronautics'; and so, NASA is the world's leader often  in aviation safety. And that's where I started. So, we were looking, though, at the *users* of these systems, and so we called them 'users'.

MVP as you know is *Minimum Viable Product*, the Lean Startup kind of idea. The idea with minimal viable product is that you create something that has the highest value proposition that you can put out as quickly as possible that will kind of meet the business objective, but that you can also engineer very quickly, that you're not trying to build this huge complicated thing.

The difference between that and *MDP* is that in UX we think about this problem as it doesn't matter if something is viable unless that is viable from a user's perspective. So, desirable or minimal desirable product, also called minimal happiness product, minimal happy product or minimal usable product – there are different spin-offs of it – but I like the MDP, because desirability is really important in UX, and if

the functionality has what a user really wants and needs, that is then from a UX perspective a good minimal viable product or a good minimal desirable product. So, first we want to specify user needs and bring those into our sprints, bring those into our backlog and to help inform what constitutes a good task to work on so that it helps the user, and so that's the spirit of an MDP,

and really drives home the need to focus on what *users* consider important as opposed to what engineering can do the most quickly and the most efficiently.

In order to really understand Agile,  it's important to know what Agile *isn't*. Agile didn't just appear from a vacuum; it was a  reaction to the way software was being written in the '80s and '90s. Back then, most of us did  something called Waterfall. I mean, Waterfall was really the best-case scenario because sometimes  there was absolutely no process at all. But when there *was* a process, it was often Waterfall. And even Waterfall had a lot of different versions, but we're going to look at the most optimistic  one that actually... included some design.

When you look at Waterfall, it makes some  sense. Somebody, probably a product manager, comes up with an idea for what  needs to be built and presents some requirements. These could take a lot of different  forms, but frequently they were in something called a product requirements document, or a PRD, or  sometimes a marketing requirements document (MRD). These were frequently *extremely long* documents  with a *lot of detail* about what a product should do. In the best-case scenario, that detail was drawn  from research and an understanding of the needs of 

both the user and the business ... and in reality, maybe not quite so much. Once the product managers were done, then we entered the design phase. Now, design was often its own little sort of mini Waterfall, but again, in the best cases, it was a good, solid user-centered design process – one that you're hopefully familiar with. It involved lots of user research to understand users in their context and lots of ideating and iterating and  prototype testing and all of that good stuff. In the worst cases, well, we drew a lot of pictures  of things that would never get built, to be honest.

The thing is that with these long cycles, the  requirements gathering and design process could last *a while* – almost always months, sometimes a  year; it depended on how big the product was. And a lot of times this was all before a single  line of code got written. That's because when you look at Waterfall, each little drop-off  is really what's called a *staged gate*. What that means is that after the process happened, the  requirements document or the design or whatever,

there would be a review process of the output  before it moved through the gate to the next step. Development couldn't happen before design ended, because the design had to be fully vetted before resources were committed to building. After all, you wouldn't want to spend a lot of money writing code if everything was just going to change, right? Again, this all sounds really reasonable – everybody agrees what we're building before we start building it. Who could be against this? Well, we're not done yet! Since requirements gathering was done *before* the design process, often things would show up in the design phase that invalidated  something from the requirements doc.

Maybe something changed in the six months that  product management took to write up 300 pages. Maybe we learned new information in  user research... who can say? Things change – which meant going back to redo the requirement ... and then back again once the requirements were fixed. Also, since design worked *independently* of  engineering most of the time, even after the design phase was "over", it was not  unusual for engineers to send the "finished" designs back with a nasty note saying, "This is a  pipe dream and will take us 400 years to build." or

something like that. That's always what it sounded  like to me, anyway. The same thing happened with quality assurance team at the testing step, except they would just file bugs for the engineers to fix. Anyway, what all of this means is that the  diagram often looked more like this. And it took a really, *really* long time. In a lot of cases, there wasn't any way to get around this process since at the end of the waterfall, we'd be printing a  bunch of CD-ROMs or even putting things directly into hardware, so there was really no going back and fixing stuff later like you can with internet-connected software.

The real problem, though, lay  in the *complete separation of the departments*. Engineering often didn't get much input into  the process until requirements were already set, despite the fact that requirements could be  drastically affected by engineering decisions and requirements sometimes changed, even from  the time that the 300-page document was written and approved to when the engineers  finished working on it. In other words, market forces could change or we could learn  things from the users or the engineers would find some really hard problem that couldn't be solved,  and then *everything* had to be changed

because it was incredibly hard to change one thing in that  300-page document without everything cascading ... because of *the waterfall* – get it? If something on page 28 changed, it meant that everything from page 29 to 300 *also* needed to change, and that was what we liked to call an enormous nightmare. Let's not even talk about feature creep, which happened  when people from step one realized that they'd forgotten a whole bunch of stuff and tried to  squeeze it in around step three or four, causing

the requirements to balloon out of control, and  all of the deadlines – which were ridiculous in the first place – would just get missed. Anyway, is there really any wonder why the engineers of the time might be interested in something a little bit more flexible – something where maybe every single decision didn't get made up front and then changed later; something where we *admit that we don't know everything*, so we're not going to bother trying to specify everything out to the last bit and byte, and we're going to build  some stuff and get *feedback and adjust as we go*. Throw in the fact that around this time websites  and web applications were really starting to take off;

and it was getting a lot easier to  get feedback directly from customers and make *continuous changes* rather than having  to chisel everything into stone before packaging it all up and sending it to the store  to sit on shelves – which is how people used to buy software; I mean, not the stone part, but the store part. Obviously, this wasn't everybody's experience of Waterfall. Between you and me, a lot of really good stuff has been built Waterfall-fashion – it's not a horrible system. In fact, most physical products and large civic projects like bridges and skyscrapers are built in a *mostly* Waterfall fashion.

But it's also not surprising that a lot of high-level engineers were not huge fans of it and they'd come up with something that was significantly less frustrating for them. And it's *really* not surprising that it would catch on.

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Wireframing is like creating a blueprint for a website or app. Imagine you want to build a house before the builders start. An architect draws a simple sketch showing where the rooms will be, where the doors and windows go, and how everything connects in the same way when making a website or app. Wireframing is the first step. It's a basic, no frills outline of how the pages will screens will look. It helps designers and developers plan with things will be placed like buttons, images and text. It's not about the colors or fancy details.

It's more about the structure and layout, like arranging the rooms in a house. Wireframes help make sure everything fits together well before the actual building or coding begins. Creating a wireframe during a UX project involves several steps. Understand goals, know the project goals, and user needs. Sketch ideas roughly sketch layouts on paper or digitally create low fidelity wireframes. Use a tool to make simple grayscale wireframes showing basic structure and placement.

Get feedback, share wireframes. Gather feedback and make adjustments. Refine and iterate. Make improvements based on feedback. Focusing on functionality. Create high fidelity wireframes and colors. Fonts and images for a more detailed look. Test and validate. Conduct usability testing and refine further. Finally, ease and hand off complete high fidelity wireframes and handoff to the design and development teams. Wireframing helps to plan and visualize a user friendly design before diving into the details.

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

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

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

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

How We Can Communicate Better So, the first thing is that we need to establish some *ground rules*. When developers get a design, they know nothing about the product, usually, or almost nothing. And you designers know everything – you are the authority. We just lay the code bricks here and there.

So, *your job is to share your knowledge, share the context with us*, and *our job is to listen, to absorb it*. And this is a moment where there are the most problems. And I think that the reason is that we often *share some misconceptions* about each other's work, and designers often think that their job is to create a design, hand it off, and their job is done.

They also tend to believe that developers are lazy and don't do a good enough job with the designs. And, actually, that's often true, unfortunately. Even in my company – my company started as a design-only agency, and my partner is a designer, but he's seen over and over again how developers  execute the design

and that the design was a totally different thing than the final product. And this is a realistic example, to be honest, so the colors are more or less fine but it doesn't look how it should at all. So, it really happens. And it happens a lot. And also, developers have many problems with designers, especially with some changes in the designs

that we are not aware of and they are made. And also, many times designers think that something is just a minor change. You have to do it, and you have to do  it fast – and, for us, it's a huge thing and not possible to change in a week or even  a month sometimes. So, these accusations are sometimes true but it shouldn't really matter

because we both have our flaws and we have to recognize those flaws, and focusing on that  creates a really toxic and unfriendly work environment. So, I think we don't have to avoid making mistakes and talking about them, but *embrace* them. So, I think there are two important mindset shifts that can help us.

One is to *change the way we think about handoff*. So, handoff – I don't even like the  word 'handoff' because it sounds like a one-time thing, and it really isn't, especially now. It's more of a process. And I really like the term that Brad Frost coined about handoff: He calls it a 'hot potato' process. And the difference between – I called it 'waterfall' here – but the old way when the designer works,

hands off the design, and then the developer works, and the hot potato process is  that 'hot potato' process. In the 'hot potato' process, we work at the same time. So, usually the designers start work, they create some screens, they give it to developers, and we start building them, and we start exchanging information, communicating, improving, working in iterations. So, most digital products nowadays are created like that.

So, that's the first mindset shift. We should  stop thinking about handoff as a one-time thing and *start to think about it as a process*. And the second mindset shift is *giving others the benefit of the doubt*. And I already mentioned that we will make mistakes that happen; we can fix them, we can improve them, and in my experience not thinking about designers as someone who's just an evil overlord

who changes designs when they want, but like another human being who has their problems, too, and their job is very hard. It helps a lot in cooperation.

Great agile teams commit to iterating on features. Now, it's interesting. When we did a bunch of  research on agile teams back in 2019 and 2020, we found one of the biggest complaints  people had was that their teams never went back and improved things that they'd already built. They would ship something, move it to the Done column and then never look at it again. Sometimes, they didn't even look at metrics to see if anybody was even *using* the feature.

The really unfortunate thing was that teams often shipped small or stripped-down versions of features just to get them out the door and then they *still* never went back and approved them. Obviously, this led to absolute nightmare products full of half-finished things that were inconsistent and didn't really make sense as a whole product. The thing is, that's one of the least agile  things you can do. The whole point of lightweight methodologies is that we're constantly getting things in front of users, getting feedback and improving them.

Do we sometimes ship things to  people that aren't quite perfect? Yeah – all the time. But we do it with the understanding that  we're shipping it in order to learn something, and once we learn something, we're going to go back and improve the product based on what we learned, and then we'll do it again... and then we'll do it again. That is iteration, and it's pretty much the core of agile. Great teams learn from their users and keep improving their product by iterating on features. They don't just keep churning out new half-baked features like they're some kind of widget factory.

So, teams that are truly committed to agile methodologies should be iterating and improving their user experience and their codebase *constantly*.

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.

Well, because if you look at what let's say the Alliance does on the right is actually faster. It's actually better. So they're using accordance and they're using vertical accordance with three levels of nesting. Right. That allows you to very quickly navigate between all these different levels. But on top of that, what you also have is whenever you open one of the menus, they only show the most important one, the top tasks

or the, you know, the most important task that people have to perform. Sometimes it's two, sometimes it's four, sometimes it's four. It's five. Right. But sometimes, you know, if you have way more than that, you will be clicking in this overview link that you have over here, right? So you see clearly a difference. First level, second level, third level, right? And you can jump in and explore more on the third level as well. But if you want to jump, let's say from this to another second level on, I don't know another item, right?

That's very, very fast. You don't have to go back. You just go forward. That's the only thing that really speeds you up, because if you compare it with the sliding slide out right, kind of right and left and left and right, this is really giving you a big speed boost. So if you test, you will see that performance in terms of speed works much better, but clarity in both situations usually going to be similar, but still with accordance you will never get a kind of a mistake there that's just really, really working. Right.

So if I had to choose, I'd probably go with accordance first. But that's not the only option because you can also do something else. So this is Licester City, football club from the UK. So what we have here is also a menu. Not surprising. Who doesn't have a menu these days, right? But, while will open the menu, this is what it looks like. Well, we could be expecting more information, right? We don't know exactly what's going to happen, but we probably are expecting you know, the next level of navigation or the page.

We don't know that yet. We don't have to know. Right. But we are expecting, you know, something matches now instead of driving people to the matches page, instead of having this slide in, slide out. Why don't we do this instead? Why don't we split the screen vertically right. And give people access at the same time to both current level right and the level that lives within it? Right. Then if you're not interested in this right, you can just jump to say, Teams and then move on from there.

So you can see two levels at the same time, very much like you do with accordions, right? So if you do have a slide in, you could do this, right. The best part about it is it can work if you have, you know, even a lot of items, but they must be short.

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.

I've been talking to a lot of people in agencies, startups, even from the GAFAs, to Google, to Apple, et cetera. And I realized that we share the same frustrations – from people who don't get design. They may sound familiar. We'll see. The first one is, 'Can you make it *pretty*?'; 'Can you do the 'UX' (whatever it is)?'; and, 'Can you add this *wow* effect?'

And if you're like me – so, this is me – when you hear that, you would cringe. And I've heard them a lot. Because what we really want to hear is... 'Can you make it *usable*?'; 'Can *we* do the UX *together*?'; And the last one: 'Can you *tell me what's broken*?'