Project Management

I'm going to talk now about plans, as in sort of largish-scale plans over weeks perhaps, perhaps months, for creativity. Say, for creativity, for innovation – the  words have slightly different meaning, but for things where you need a creative step, but not necessarily – I'm not thinking Einstein here; I'm thinking more the kinds of creative step you need

in your day-to-day user experience, software development, whatever particular aspect you're in, you're after. Crucially, innovation is often attached to risk  and creativity is attached to risk. And typically, when people say 'risk', they're thinking high gain but also a possibility of failure. And that's fine – apart from sometimes you can't afford to fail.

So, what you really want, ideally, are *high-gain, but low-risk activities*; so, things where you're guaranteed to get something but you might get something really good. And that's what I'd like to talk about – ways to achieve that. So... high risks or innovative strategies seem to be risk of failure, conservative ones low-risk but not very exciting.

Can we get the best of both worlds? The typical way, when you think about  plans – if you're going to go and you write your Gantt chart or whatever, you think  of them as not necessarily linear; you might have parallel activities, but lots of small steps where you're saying 'I'm going to do this on these days; these on these days; this person's doing this; this person's doing that.' All pre-planned, guaranteed outcome – you know that you can achieve each of the steps. You know that you do each of the steps, you get to the end and you've got your result.

Brilliant! But maybe a little boring. So, again, can we do something a bit better than that? Well, of course, there is a creative plan. So, a classic – and this is both  something you might informally do, but also I have seen formally written plans like this, which you can think of as the 'spark from heaven' plan. So, you have a series of activities that perhaps happen up front. And then, your plan,

I said you might not write it down, but your plan is basically that you *wait for the spark of creativity*. There's the big bright idea; once you've got your  bright idea, you move on. So, I've seen things like research or development plans that say, 'First of all, we're going to review what's there. And then, we'll invent the new method, the new toolkit, the new way of doing something. 'Spark from heaven' plans: brilliant when they work, disaster when they don't.

So, this is a classic high-risk plan. So, how can you modify this kind of bigger bright idea plan to make some things more likely to succeed while still having the opportunity to produce really good things? One kind of plan that works quite well, I found, are *incremental output plans*. Now, this works, perhaps – well, we'll talk about some examples actually later.

If you're writing, it might be about writing things that come in units so that you can deliver things. If you're producing software, it might be producing something minimal and then additional parts. But the basic idea is you have a linear plan – or it doesn't have to be linear; it can be a branch, but think of a linear plan, *with multiple stages*, where each stage might require little sparks inside, but smaller sparks;

so, smaller sparks spread out; but then crucially at each stage, so you've got those high-risk elements; I said normally they're  dangerous, but because you've broken them up, the likelihood is that one of them will happen.  And this can be highly linearized, so you have to have the first one first. But if it's smaller bright ideas, you're more likely to have it. Or it might be actually you could do things  in different orders and be a bit more speculative about which order you do things.

But crucially, each stage, when you have the spark of insight related to that stage, has a related output. And so, at every point from the first stage or two, you  actually have something that you could *deliver*. Now... from an overall management point of view, from a project management point of view, knowing you've *got something*, even if it's not what you'd really like, is *brilliant*. So, and it's particularly good if you've got a limited  time, so there are different kinds of constraints

in time. Sometimes it's the amount of time you've got to spend on it in total, but often there's a *hard deadline*. If there's a hard deadline, if you have to deliver something by that deadline, then actually a plan that's guaranteed to give *something*, even if it's not the most wonderful thing at that deadline, is a good plan. The more of the stages you go through, the better the plan you have. And if you fail on the last one, so what?

You've missed a little bit, but you've still got something pretty good. Examples of that – in Agile development methods, I'm sure a lot of you have worked with Agile development teams. You're often based around a user story or a scenario-based one where you take a particular user story and say, 'We're going to, this week, this fortnight (2 weeks), this month,' – depending on how long you do your sprints over – 'we're going to implement this slice of functionality.' You implement that one; then you move on to a different one.

You need to have a level of innovation, a level of – I mean, this is true both from the development point of view, from the user experience design point of view. You need your sparks for those (inaudible). But each one is a relatively contained  thing that you can finish. The other thing is that if you have, shall we say, a 'palette' of them, what you might do is during... your weekly review meetings about where you're at,

you might actually choose to do the story where you've got a pretty good idea of what you're going to do. So, effectively use the sparks to drive the order in which you do the stories. So, you have a number of stories that you want to implement. They're part of what you'd like to do; you do those. Now, this is related to the whole idea of a *minimum viable product*. So, is there something you can produce that you can get out there that does the job? And then you've got a roadmap (inaud.) wish  list, that you might do in a particular order, and then it's a matter of waiting to do those  creative steps for each one.

Or it might be that if you've got a road map, a wish list of things to do, when you sort of realize 'Ah! That's how we can do that one!' you get on and do that one rather than the rest. So, it's like having a *menu* of things that require *creative steps*, but each one of which when you do them, you can add to that minimum viable product, make it a more extensive one, something that's more appealing. A similar – well, it's similar in the sense that it reduces risk, although actually very different –

is what you think of as a *back burner activity plan*.  So, the idea here is you have your classic 'spark from heaven' plan where you've got something and you're waiting for the big idea. But what you do is, in addition, you have a *parallel activity* that you can get on with. Now, *sometimes that's related but not the same*. So, imagine you've got actually an application idea of your own you're trying to develop, and you think it's going to be great, but it takes time

and you certainly need a certain amount of insight to hit your head. So, what you do is you're doing consultancy work; it's in the just same general area. So, it helps *feed your brain with ideas*, but pays for your bread and butter – allows you to live and to pay your rent and everything while you develop your new bright idea; so, that might be it. Or it might be a *low-risk path to the same outcome*. So, you have a project you have to do.

And you'll think – again, we'll go back to the to-do list application; so, you have to develop a to-do list app. You know you've got to do it. You know what to-do lists look like – applications. There's a gazillion to-do list apps; so, you could just do yet another to-do list app. So, what you do is you *get on with doing that*, but at the same time you're *thinking about novel  and different ways to do it*. Because you're doing something related, it's feeding in. So, as you get on with the bread and butter

to-do list app that's sort of just doing its job but in a fairly boring way, it's keeping your mind thinking about to-do list apps. And if – and hopefully if, that will, one is, make it more likely and then if the sudden 'Ah yes!' idea comes, you then effectively shift into doing the more creative but high-risk activity. It's quite nice too if the steps that you're doing  in the high-risk activity can

feed back into the low-risk one. So, you might – I mean, that's less true if there's like one huge big idea, but the low-risk activity might itself be a bit more like the incremental would have a series of things and you might perhaps having done one of them, be able to feed some of those ideas back into your more day-to-day mundane plan for producing the to-do list application. So, the idea is to have something that you just know you can get on with, will produce a result;

you know – that result might be earning your money so you could live; it might be producing the application at the end, but something else in parallel which sort of sits there and is it what you really want to do? And when the ideas come for it, you  get on with it. Okay, that's a *back burner activity*. The other thing you can do, which is sort of  essential for the incremental one but is a general strategy, and it's sort of blatantly obvious, this, is

take that one big idea – can you break it down? Can you think of things that are smaller, but when you've done them all, either means that you've done the big activity or sometimes are just preparatory, but each one of them is of value in itself, and often the last small idea you need is how to pull them all back together to bring them back into the big idea? So, ways of breaking things down:

So, you can think about activities. I mean, there are multiple dimensions, and I'm going to push it down to two because otherwise you can't see it on a slide. Let's think about the things that you're doing in terms of two axes. One is in terms of *complexity*. How complex? Is something really simple or is something a really complicated thing? And in terms of the *amount of creative energy required*.

How creative do you need to be to do the task? Now, there are some things that are both really simple in terms of complexity and don't require a lot of creativity. So, I can go out and make a cup of tea for myself anytime. You know – that's low creativity, a low-complexity task to do. If you've got a load of those to do, one – I mean, sometimes they can be a useful back burner activity, but one thing particularly often I find myself trying to do is clear the decks of those

because they can take over your life. In the pebbles and boulders model, they're the *pebbles*. So, one is they can take over and there's too many of them. But often, the fact that they're sitting there on your head, you know you've got to do these little tasks. I often find if you can, spend a bit of time, get them out of the way – that's useful. So, there's *strategy* – so, again, you might have different strategies, but they have a particular strategy for dealing with them. Or you might say, 'I'm going to schedule a day a week for doing these,

or an hour in the morning for doing those tasks. That's it.' I mean, I prefer to produce biggest possible ones; so, I might go for the day a week. But I said it does depend on your schedule, where you work, how it's going to do. The other kind of thing, you might have *things which don't require much creativity but are quite complicated*. Now, I mean that's weird because – but things can be biggish and yet you just know that if you get on with them, they'll happen. For those, if you're wanting to do something creative, two things you can do with those:

One is you can *deliberately schedule them for later*, so you can move them off into the future. I sometimes talk about *Micawber management*. The use of procrastination, but as a positive thing. And this is an example of Micawber management. You're saying, 'I know I've got this; there's this complicated thing. It's going to take a lot of effort. What I might want to do is just say, "But I know because it's not going to require huge

amounts of creative insight, that this will take  me a day, a week, an hour; where's its deadline? When do I need to do it?"' ... pushed off; so, into the future. The other thing you might do with these is use them in that back burner model as the parallel filler activity; so, the thing to do whilst you're waiting for the big idea, basically. The thing you have to be a little bit careful with these, using that is

if they're *complicated but are taking mental energy*, then they get in the way of the creative thought. However, that by very definition pushes them up into the bigger emotional or creative energy tasks. So, if they're low creative energy, if they're things you can just get on with but are quite complex, then you might do them as your back burner activity whilst you're doing the things that you  have to sort of perhaps wait for that moment when it's 'Ah – yeah! That's right! Get on with it.' Okay, let's look at the top left of this thing now. So, things which are

*low complexity but require a substantial amount of creativity*. So, these are little puzzles – you know. It might be as simple as 'What name should I give for this menu item?' – you know; it's that kind of thing, or... but they're things that – you know – you do have to think about, do require a bit of processing; so, they're eating up your creative thinking, but they're relatively small. These are often little fun tasks, actually, because  you know you're going to get them done;

you know they're not such a huge thing that you think,  'Oh my goodness! Will I ever think of that many (inaud.)?' – you know. You know you're going to do it; you might have some strategies for helping you doing it. There is a category of things up here, though, that are *not fun*. And... You know – you'll have different ones,  but I'm rubbish at like sending – certain emails. Some emails are fine, but there are ones where I'm just worried about how to *phrase it*;

so, it's not so much creative energy as *emotional energy*. And what I will do is I can spend a day not doing that task. So, for those things, these things which are more problematic, again you either want to try and clear the decks of them, so I'm going to push it down to the bottom. Or, even though it's quite small, put it off, schedule it so that it's not  forgotten – you know it's not forgotten, and it may, but hopefully by scheduling it into the future, it makes it less of a weight on your mind. Okay, now the *gap* – the yawning void here on this diagram is the things that

*require creativity but are also complex*. There, I said we're not talking about complex in the Einstein general relativity sense, but in the new idea of how you're going to organize this new application in some way that's going to be different from your competitors and yet it's going to be easy to use; it's going to be immediately attractive when they first see it, and it's going to continue to enthrall them for weeks and years to come – you know.

So, this is non-trivial stuff. You know – this is the Nirvana up here; this is it, right? But it's hard – these are the *hard things*. What good planning should do is help you to break that down into things that either actually require *no creativity at all*, or are these *lower grade things*, these things that require those creative insights but are more fragmented.

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

Let's now talk a little bit about roles in creativity, taking on a role. We'll start off by looking at de Bono again and the thinking hats. So, I think the two things if you've heard of de Bono will be lateral thinking and thinking hats. So, de Bono talks about *six hats*. One of the hats, what he calls the *white hat* is the information-seeking hat.

I think the white is supposed to be like the blank slate, blank piece of paper you write on. So, you're seeking information – you're finding  out about things that are similar and related, and doing that kind of thing; it's a gathering stage. Then there's the *yellow hat*, which is the positive, bright, looking for the pros in everything, as opposed to the *black hat*, where you look at all the negative things, all the cons, all the reasons why something is bad. So, with those positive and negative, again – with the bad ideas, recall deliberately how do you think about what are the positive things about this idea?

What are the bad things about this idea? And then actually, once you've thought of the good things to critique those; so, alternating you between taking this sort of positive, active role of thinking what are good things, and taking the negative role. Then there's this *red hat*, which is about listening to your feelings, trying to get that gut reaction to something, getting that out without necessarily thinking about why you think that, just getting it out there. You can use some of these others to question it. The *green hat*, which is all about bright ideas,

thinking of just lots and lots and lots of ideas. And then, finally, and possibly most important the *blue hat* – the role management hat, actually looking back and saying, 'Have I actually thought about all of the (inaud.)? Have I spent time thinking about the positive aspects of this? Have I spent time listening to what I feel about this?' Actually, I'm going to pop back to that feeling one because I've – one of the techniques that I often suggest people use when they do qualitative research is

to deliberately do things that incite  those gut feelings. So, what I suggest doing is if they've got some sort of model, some sort of vocabulary, is to look back to the original data to use their model to describe their data  or use their vocabulary to describe their data. Perhaps it's something that somebody said,  something that somebody did, and then say, 'it's just a...' – you know – so, 'it's just a...'

and then the words will be vocabulary. And see how much that rankles inside. So, effectively what you can do is create  situations. And this is the role management thing; it's saying, 'Can I create a situation where I can apply the red hat, where I can generate feelings?' So, I think it's a quite useful set of –  they're not the only things you could have. And there are different roles you can have; you might have roles which are perhaps more to do with – should we say – customer-focus or client-focus roles.

You know – so, one of you might say, 'I'm going to be thinking about – I'm going to be the problem owner.' And another person might decide to act as the technology provider, another person as perhaps the management role, and then think about each, taking that viewpoint to look at a problem. So, there are different ways you might choose roles. So, why are roles useful – taking a role on at times? Sometimes it's to help you *notice that you've neglected something*.

So, for instance, I mentioned the feeling one or it might be that you spent so much time thinking about positive things, you've not actually considered some of the negative features. So, by thinking about the roles, by putting a role hat on, you force yourself to think about things from *different  viewpoints* and to not neglect some aspect. Particularly on that positive and negative hat, if you say, 'I am going to be the devil's advocate for a period,'

by stating that, by saying 'I am  putting that hat on, I am taking that role on,' it can avoid a level of rancor in groups. So, if you're doing a group, if you're working together and somebody's being the proponent's idea,  if you start saying negative things about it, everybody gets upset. If you say, 'Not because I think it's a bad idea, but because I'm going to take this negative role,  I'm going to try and think of all the negative aspects about it,' it can make it a little bit easier. I mean, they still might hate you if you do it. So, it's a good idea to rotate the negative hat  around. Everyone will love you while you're taking

the positive hat on; they'll hate you when you have the negative hat on, but by *knowing* it's a hat, it can help allow you to be – particularly in this critical role – without causing ill will. It might also help you to *go beyond your norms of behavior*. So, if you tend to be the sort of person who always sees the negative aspect, then actually deliberately taking the positive role, or vice versa, if you're the person who just, particularly if you don't like hurting people's feelings,

you might tend to encourage people. Think of all the positive things, think of things that help them, but actually sometimes it's *more* helpful to be critical, and so actually saying,  'Okay, just for a moment, I'm going to take that devil's advocate role, take that negative role and see where that leads me.' And it can help you to escape the patternings that you have. And particularly we mentioned the stepping back, the way that roles, actually thinking

'I am taking on a role' helps you think about the role. It makes you think that there are different roles you can take and that they can apply. So... thinking about roles helps you to step back from the problem, step back from you as a solution (inaud.)— whether it's a team or it's you as an individual, you might alternate roles yourself within a project; you might choose to take roles if you're working as a group. But that stepping back is quite an important bit and *seeing that it's a role* and therefore helping you to adopt them.

And they really make a difference. Taking on roles helps you think in *different* ways. So, this is seen particularly in  work on gender studies and also work on issues to do with racial bias in things like job markets and examinations and things like that. And this is partly about the bias – we  talked about bias earlier – but also about the way in which you tell stories to yourself. So, I come from a working-class background.

So, one of the stories I might tell myself if I'm not careful is – you know – 'Working-class boys don't do this' – as a child going to university or whatever it was. And I went to Cambridge University. You know – 'Working-class boys don't go to Cambridge University. Posh kids go there, not working-class boys.' We tell ourselves stories. What you find is when you do experiments and you get people to think just before an examination or a test about  different kinds of roles

– now, that might be gender-reversal roles, it might be trying to think – of boys to think about more female things and vice versa. It might be about social background, a variety of things. You find it actually makes a substantial difference in the test scores. So, by just having people *think about different roles*, they suddenly *behave differently* because it's so easy to get trapped in the expectations we have of ourselves

built up individually over time;  sometimes it's about our social situation. This also works for creativity. So, if you ask people to think about things that, shall we say, are creative things (inaud.), and it might be you spend time thinking about Einstein or DeRidder or Picasso, as opposed to, say, thinking about  a foot soldier who's ordered what to do all the time or somebody who's sleeping – you know. So, if you think about creative things and then go into a creative situation,

that can actually help you be more creative. Throughout these videos, I constantly emphasize that we're all individual and different, and one of the most powerful things you could do  is understand the way you are and then use it. But part of that is also – it's a bit like seeing outside the box – by understanding that, sometimes you can create these things and roles, and building these roles

for yourself is one of the mechanisms that allows you to for a period, for a purpose to actually reinvent yourself so that when you're addressing a particular problem sometimes you can literally address it as a different person.

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.

You're probably familiar with these;  they're a really good way to track progress on any sort of project, and there are tons of tools to help you build them, although – you know – plain old Post-it Notes and blue tape work just fine. Your Kanban board will have some columns. At the minimum, there will be columns for things you're *going to do*, things you're *currently doing* and things that are *already done*. Sometimes there will be columns for other things like *review* or *release* or something called an *ice box* for things that have been suggested but that aren't ready to be done yet. The idea here is that things move from column to column

as they move from planning to in-progress to finished. There are lots of other stages as well. The process set up by your team will determine what columns you use. Sometimes we have multiple projects going on at once. In that case, we might have something called *swim lanes*. These are horizontal lines across the  board that let you separate out different projects. So, if your team was building both a website and an app, you might track progress for the website and the app separately but on the same Kanban board. Sometimes designer research is tracked in its own swim lane. Again, it varies

depending on the needs of the team. Ideally, it allows everybody to see a quick overview of what's currently being done, what's going to be done and what's been finished.

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

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.

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*?'