Workshops in UX/UI Design

(F.S.:) It's like the workshops are a key component of service design in terms of process. Can you talk a little bit more about that and tell us a little bit more about what is the significance of putting that together – different from, say, a usability test readout or something like that? (D.B.:) Sure, so the workshops are really important in helping and it depends on the stage. But

so, for instance, the workshop that we just hosted most recently had been on setting the projects up for research. So, this is bringing stakeholders from across the board to the table. Those who are on the business side, those who are on the technology side, the product owners. So, those who are going to be concerned and worried about the legislative implications.

Policy dictates this. We have to make sure we follow 'X' code, etc., etc. Then, there's the folks who are like: "Well, we can only do this based upon the fact that our technology is X number of years old and – you know – there's a backlog of this long and technology debt." – that kind of thing. So, we have to work with all that, but before we can even get to a timeline and product roadmap on "OK, we want to do this project,"

we want them to help define: What is viable? What is the direct need? What's going to solve for X? So, we want to solve for an issue that's going to be a problem that's going to be able to address their concerns and be a benefit for both the customer and then the business itself. So, in the IRS's case, just make sure that the money that is owed to the IRS comes in.

So, there's a lot of that – and then ultimately I think one of the lessons that we've been learning most recently is don't have too many people in a meeting. I think most companies, many companies and organizations are guilty of inviting everybody because they feel they don't want to hurt anyone's feelings. And it sort of goes to like this era of – at least in the States – we had this tendency in the last decade or two of every child getting an award

when they're part of a sport team. It's the same thing – we don't want to hurt someone's feelings, so we invite them to a meeting. But actually, you're wasting their time and you're slowing down the process. (F.S.:) What do these workshops feel like? Are they like design thinking workshops in terms of do they borrow? Or what are people doing? Is it kind of tactile? Are they – you know – putting up stickies and hands-on with...? Are they looking at reports, going through like a business-level analysis or something like that?

Or...? Talk a little bit more about the feel of the workshop. (D.B.:) It's very much based upon this idea of making sure workshops are interactive, engaging and building upon design thinking methods, using sticky notes and all that; workshop best practices that are across the board whether you're a designer or not. You know – there's been a lot of thought gone into facilitating meetings,

and so – you know – using icebreakers to begin with to warm them up. Sometimes, I question the idea of icebreakers. But, at the same time, it's a practice that for whatever reason is in place. I do think after lunch they're really important to get people moving. If you have an all-day meeting, let's say, you want to get the blood flowing because we've all been in those meetings where we come sit down after a heavy lunch and then

– or if you're having to serve lunch to people, make sure you're serving a light lunch. (F.S.:) Right. (D.B.:) You know – that kind of thing. You just have to be thoughtful, and so all of a sudden – and it's funny; I never thought – when I was starting my career, I never thought that being conscious of how a meeting would flow or whatnot would be a thing I got into. But it harkens back to – again, it harkens back to my days in teaching when I was really interested and passionate about

creating dynamic experiences so that my students could learn. And this is no different. I want to make sure that those who are showing up are getting the most bang for their buck. They're not – you know – constantly looking at their phone or typing on their computer because if we can have them clamshell their computer, have it closed and really engaged in a conversation or an activity with two or three other people so that they're

generating output that can ultimately move the ball forward and get them excited about being a part of this project, it's a win-win, so I don't think anyone's ever been excited about a meeting and a project when they're just sitting there having to listen to someone talk or they're looking and listening to another PowerPoint presentation with a million slides and a million bullet points. But if you're able to make a presentation that's going to set the flow of the day

and it's going to give you instructions on how an activity is going to work, and then people are getting up, moving around, putting things on walls, or drawing things. You know – often I'll print out in advance; I'll make worksheets and have them use worksheets on the wall in a way like a mad-libs type of thing. And that works really well.

So, those are important tools to keep it engaging, because ultimately – as I alluded – if you can get them to buy in by being excited about the idea because they were engaged and feel a sense of ownership in it, and it's not just them being told how it's going to be done, but every individual in that room is contributing, then you're going to be better off.

Brainstorming is a group activity where  people come together to share ideas and   think creatively to solve problems or  generate new concepts. The goal is to encourage free thinking and creativity without judgment or criticism, allowing participants to share any idea that comes to mind no matter how unconventional or seemingly impractical. The aim is to *spark creativity and explore various possibilities* which can later be refined or combined to develop more practical or innovative solutions.

Brainstorming sessions often involve structured or unstructured discussions, note-taking or visual aids to capture and organize the ideas generated by the group. So, how can you structure a brainstorming session? Define the goal. Clearly outline the problem or objective. Create a diverse group. Gather people with varied perspectives. Encourage participation and free thinking. Generate ideas without criticism. Build on ideas. Combine, refine or expand on suggested thoughts. Set a time limit. Keep the session focused and efficient.

And lastly, document and evaluate. Record all ideas and assess their feasibility later. You can spend some time after the session to categorize, reduce and analyze.

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.

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.

What I want to do now is talk about a  few other kinds of divergent techniques. Creativity has two sides to it. There's being *novel* and being *useful*. There's a *divergent* side that's having lots and lots of bright ideas and a *convergent* side that tries to turn those ideas into something that's more useful and buildable.

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

One of the key ways of designing for  experimentation is to build an MVP, or Minimum Viable Product. This is a concept that was first introduced by Frank Robinson back in 2001 and was popularized by Eric Ries and Steve Blank. It's now heavily associated with The Lean Startup methodology, and it's obviously probably one of the most misunderstood concepts that is also wildly popular, which is impressive because there's actually a lot of competition in that category. People seem to have misunderstood what a minimum  viable product is

in about as many ways as you can do it, but the most common misunderstanding  is that you can just cut as much stuff out of a feature or product and then ship it and then – I don't know – learn something, I guess. But the thing is, you *can't learn something from  a really bad product*. You just learn that nobody likes really bad things, which is something that we already know. Instead, what we should be doing is designing and building something that *we can actually learn something from*. Specifically, what we normally want to learn from  building an MVP is whether the proposed feature or product *solves a real problem* for a specific type of user.

The idea is, if the users we've identified really have a problem that they want solved and they try out our *small* version of the product, that they'll overlook some simple missing features or some small problems because getting that problem solved in this way is so important. The great thing is, if we combine this technique with the one where we share our work with a small group of early users, we can end up getting really good data on the exact things that we're missing. This can sometimes mean that we end up building something far smaller than we thought we'd need in the first place.

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.