Design Agencies

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

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

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

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

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

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

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

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

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

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

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.

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.

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.