What FS marketers should steal from UX London

Episode transcript

Amelia (00:16)
Hi there, I'm Amelia.

Paul Wood (00:17)
I'm Paul.

Mark (00:18)
And I'm Mark.

Amelia (00:19)
And this is Fin the Week. How are we all?

Paul Wood (00:22)
Good, good, thank you. Yeah, another week.

Mark (00:23)
Very good, thank you.

Amelia (00:25)
Good. Another week, another week coming to an end. And Mark, we haven't seen you for a little bit.

Mark (00:31)
No, no. It's been a while. It's nice to be invited back. Lots to talk about.

Amelia (00:34)
Yeah, welcome back. And you've just returned, haven't you, from UX London. So we're gonna get into some of the key takeaways from that today. But how was it?

Mark (00:46)
It was great. Yeah, yeah. I mean, it's always good to do these events, go and mix with like-minded people, see what people are talking about, keep on top of industry trends. And it was good to be in London. I'd not been down there for a while, so yeah, all good, really good.

Amelia (01:06)
Well, it's nice to do these things in person, isn't it? And we're gonna run through the event in kind of four segments today. So we'll start by explaining a bit about UX London, crucially what financial services marketers should take away. We'll then take a tour through some of Mark's key takeaways. We're gonna devote a special segment just for AI because it's such a hot topic. And then we'll finish up with what ideas…

Amelia (01:34)
…we're all kind of most drawn to. So let's get into it. Paul, you've been doing a bit of reading up about the event. So what is it all about?

Paul Wood (01:42)
Yeah, because I wasn't too familiar with the event before Mark and some of our colleagues were discussing it. So, having read about it, it was founded in 2008. It's a very popular UX conference, one of Europe's headline events, I'd say. It's run by a Brighton-based agency, Clearleft. So they've been running it for the last 17, 18 years, I think. My maths isn't great. But…

Paul Wood (02:12)
And it's a three-day event. So this year, Discovery Day was the first day, Design Day was the second and Delivery Day was the third. And I think, Mark, you attended Discovery Day, didn't you? And I think it's going to be an interesting one for us to discuss today because, particularly in financial services, I think UX has become…

Paul Wood (02:41)
I think it used to be considered as a sort of making-things-look-nice exercise, but it's increasingly become a board-level concern, because with the FCA's Consumer Duty guidelines saying that companies have to achieve good customer outcomes, and their customers have to understand what they're buying into, UX is a sort of board-level risk now that's really tested.

So I think this sort of conference has a lot to give to the industry. So yeah, that's what we'll be digging into today. So I guess the first thing to discuss is, it'd be good to understand Discovery Day, because discovery as a term we use in our industry is the first part of a project where we're doing all of the uncovering of facts and understanding the situation.

But what did Discovery Day look like for UX London?

Mark (03:40)
Yeah, I really like how they split the days based around how a project is set up. Like you say, the Discovery Day, the Design Day, and the Delivery Day — sorry — on the third day. But yeah, Discovery Day was really interesting to go down there and meet

user researchers, UX designers like myself, industry leaders, and see the talks that they were doing based around research and understanding. I think the biggest thing that came out of the day was there was a lot of talk around gleaning, gaining that research, and how you present that research back.

Whether that's validation during a project, or whether it's setting out common core goals, and how that framework is presented back to stakeholders. So I found that was quite important in terms of how we deal with our clients as well. So yeah, it was a really interesting day to go and listen to what people were talking about.

Amelia (05:02)
So, shall we get into some of the takeaways from the event, Mark? Let's start at the beginning — what's the first thing that struck you that you're gonna take away?

Mark (05:15)
Yeah, so one of the first talks was by a girl called Maria Isachenko. Her talk was called "You Don't Need More Time to Research." And essentially her core point was that sometimes research can get ignored, because

it can be in various different places, it can be in the wrong format, it can have low visibility, or doesn't align with the goals of a project. And she says sometimes that can be hard to then validate with stakeholders. So what she was

talking about was creating a strategic framework that links goals, hypotheses, problems and evidence together, to get these granular insights all framed correctly so that they're easier and more manageable to talk through with stakeholders, because you're talking through it with them at the right level.

My core takeaway from her talk was that getting a working insight at the right time, in the right format, with the right alignment, resonates with everyone. So developers can align to it, but also core stakeholders understand what you're trying to achieve with it.

I did find that one really, really interesting. And ironically it was her debut talk as well. So that was really good.

Amelia (07:01)
And has that changed the way that you think about research, or the way that you might have used research up till now?

Mark (07:07)
Yeah, I'd never really thought about generating this kind of hypothesis throughout my career. We've always explored goals at the start of projects, and it's all quite high-level thinking, and sometimes that can get lost throughout the duration of a project. I've also used user stories as well. And again, those user stories are great at positioning

things that you need to do. But that hierarchy of having a hypothesis and then everything feeding into that — that was a really interesting way of almost giving you a reference when you're talking to people. And that ability to talk to users but also stakeholders as well was really interesting for me.

Amelia (08:01)
How do you think about that, Paul?

Paul Wood (08:03)
Yeah, it's interesting because what I'm hearing from that is it's almost saying that it's not the depth or the quality of the research that's usually the issue. It's the packaging and organisation of it in a way that people can understand. Because as we were just talking there, it struck me that we as an industry use a lot of what could be classed as jargon. Even the term UX

probably doesn't mean all that much to someone who's deep in one of our client organisations, who doesn't deal with marketing and technology day in, day out. If you present them with a UX report, even the name of it might put them off. And then there's user stories. So when we're talking about user stories, what's the layman's definition of that?

Mark (09:00)
Well, a user story essentially is, you're defining a feature as a story. So you position it as a user: I want to do X so I can complete Y. And that very much focuses on a user's task, almost. But you almost need a set of stories based around a goal,

you see what I mean. So the beauty of the hypotheses that Maria was talking about was you could position the stories underneath that hypotheses framework, which, again, just helps keep everything quite broad. But with the refinement of the wording within that hypothesis, equally it can be quite granular

as well. So it focuses the goals. You can build the stories into it, or features and products, and it gives you the ability to go away and do the research but also collate the research around that as well.

Amelia (10:10)
So it's maybe just thinking about it in a different way and presenting it in a different way, perhaps.

Mark (10:15)
Yeah, in broad terms that's right. I think that would be a good way of doing it. And you can align it at scale as well. You can align it with core company goals or values, or anything associated to that that needs to feed down into a project.

Paul Wood (10:39)
Coming back to the core thing that you mentioned at the start, that you don't need more research time. So was the talk getting at the point that, rather than investing in getting more data, you probably want to invest in tidying up what you have and presenting it back in a cleaner way? Because a common scenario that we come across in

finance firms is that they'll be transitioning to a new CRM or something like that, and they'll be trying to tidy up data and not knowing what to use and how to use it. And actually sometimes the best bet is to take the basics and just get those organised cleanly, and you can get a lot of outcomes from that.

Mark (11:25)
Yeah, I think so. I think it's that. Obviously when you're operating at scale, you've got departments doing different things, different insights from different areas. Bringing it all together can be difficult, and getting the right information — if you think of

banking and the kind of stakeholders that you need to talk to at that level, getting something that they can relate to, to then allow them to explore the evidence. If you present them with an individual piece of research, how's that hooking together? How is that delivering or aligning to the company values or goals?

It allows you to position what you're doing as well. So I think it's quite a flexible way forward, and certainly something that at our scale we should be considering.

Amelia (12:31)
And did you say that was the first talk that you went to?

Mark (12:33)
That was the first one. So already, my mind was blown within—

Amelia (12:37)
Excellent, excellent. So what else? What else did you take away? What other talks did you go to?

Mark (12:42)
So there were four in the morning. The first one really resonated with me around that hypothesis. And then the second one was a really interesting talk about validation as a UX superpower. So this was a talk by a woman who ran an agency herself, called Melanin Edda Womney.

And essentially she was preaching to the converted in terms of validation. Her core message was: validation is core, don't build on assumptions. Fall in love with the problem, not the solution. And she positioned her thought really well because she started with a case study where she'd worked with a water scarcity project

that had an amazing mission, it had an expertise team, they used sophisticated tech. And during the project they'd spoken to these external scientists and they all thought that they were going to change the world. And the project completely failed because they hadn't done their validation with their users. So there was this

kind of glorious start where everything was great, and they'd all assumed that their product was going to work perfectly, and it didn't, because it didn't resonate with the users in any way, shape, or form. So essentially, she was talking about this: good validation means talking to real users, involving real users at the start, and not just

presenting things to them — actually getting down to the nitty-gritty of exactly what users require, doing all that as a phase up front. Which I'm like, yes, this is what I need to hear. And I went up to her afterwards and said, this is great, because I suspect so many people in the room here feel seen based on what you're saying.

Because sometimes it's quite hard to deliver that in projects at various different scales. That ability — sometimes you have to move quickly. Sometimes you get the opportunity to do this, but people don't buy into it. And this was a discussion I had with her in terms of how do you deliver that at scale? And she said it can be quite difficult to sell that in, but when you do sell it in,

the outputs are a lot stronger, based on that validation, because essentially you can do all that before you touch a design or you touch development. You've got your core idea. Users have used it, users are behind it, users are built into it. So yeah, I found her talk really interesting. And she was one of the only ones who spoke about AI, actually. So

kind of digressing slightly — because it was a discovery day, there were light touches on AI — but she talked about using AI and how helpful it is to help build prototypes quickly. You've got an idea, you're validating that idea, you can build something and put it under a user's nose and get that tested really quickly. Which, again, I think works really well.

And something we've done on projects in the past at Indulge. So yeah, really, really interesting talk.

Amelia (16:31)
And it sounds like, Mark, you're sold on this idea straight away. What do you think, hearing that?

Mark (16:35)
Yeah, it's always something that I believe in. Throughout my career, I've worked with users at various different points on a project. I've worked with customers who don't feel like they need to involve users, and the success is based on

getting user engagement up front. It just leads to something that people are bought into. If you're investing an awful lot of money in a product, it's worth proportioning the right amount in terms of getting user engagement straight from the get-go. And again, like I say, it's something that we're doing on our projects,

which only adds value because you have that validation. You can reference that throughout a project, you can reference it when you're building and testing. It's all extremely useful information.

Paul Wood (17:44)
I really liked what you said at the start: fall in love with the problem, not the solution. I've never thought of it that way, but it makes perfect sense, because you can just imagine a scenario where a company comes to you with a brief that says we need an app. And so all of the focus goes into the app, what it should do, what it should look like, how it should work,

when in actual fact there's been no attention given to the actual problem, like, why do you need an app? What are you trying to achieve? Because an app might not be the answer. This is quite typical of a pensions company. With workplace pensions, a lot more people are saving into a pension, and the default response of companies to get people engaged with those pensions is to say, we need an app.

And maybe they do need an app, because that might be the way people want to learn about their pension. But actually, it might be that the annual statement that you send to your customers has the information they need, but it's just not cleanly enough presented in a way that the person understands and can engage with. So devoting more time to that central problem, which is that we need people to engage with their savings, rather than…

they just need an app and it needs these features. You can't really answer those things until you really get to the bottom of the problem. I was going to ask though, in terms of validation, it strikes me as one of those things that's easier said than done. Because if you sit down with someone and you ask them, what are your thoughts on this? They often give you the answer they think you want, rather than what they genuinely would do in the wild. Did it address that at all?

Mark (19:22)
Yeah, completely. I mean, that first case study that she presented about the water scarcity product really highlighted that. And then she backed it up with a case study that was successful, about a social housing app. Because of the deep research that they'd done with the residents, it revealed all the clear

pain points. She also said another thing about using early testing to try and kill the product. What does good business mean, but also what does bad business mean? How operational is something, what kind of financial scenarios do you get into? It also elevates edge cases. I think fleshing things out at the start, prioritising your time,

doing that — it just leads to success. So yeah, I found it really interesting in terms of that exploration process. But Paul, I completely agree. I think sometimes that can be a difficult point for clients to get their head around. And also, it's being able to back that up with where those successes are: this piece of work has led to that.

So selling that in case study form is the best way of doing it.

Paul Wood (21:04)
One of my favourite quick-win methods of getting some user validation type information is, when we're running a search marketing project, keyword research is a big part of what we do. And there's a type of keyword research that you refer to as navigational. So you use the company's brand name, and then you use research tools to look at what people search for

in relation to that brand name. You could choose, say, a bank, and you use the bank's brand name as the seed for the keyword research, and it will show you everything people search for about that brand. What it will do is highlight common issues. If you find a large volume of people searching for "brand name customer service phone number,"

and that outweighs every other type of search, then you know your customers have an issue finding your customer service contact details. So that immediately gives you something to work towards. The same can be applied to if a bank has an app. What are the things people are searching for in relation to that app? Is it that they can't find out how to transfer money from one account to another, and things like that? And it's a nice, easy-to-get-to form of validation, because

people, when they're searching using a search engine, they're not really performing for anyone else. They're not being asked by an interviewer, what do you want from this app? So it's just their genuine actions that are telling you something. So that's quite a nice little hack really for people.

Amelia (22:49)
And presumably — sorry, I was just gonna add — presumably quite an easy thing to present to a client. You know, that's quite straightforward; anyone can take that idea and understand what you mean by that.

Paul Wood (22:55)
Yeah, absolutely.

Paul Wood (23:02)
That data is out there. It's available. Every brand has it.

Mark (23:08)
Yeah, and I think lots of people jump into workflows and they're looking at getting from X to Y. And because we've done that, that ticks the box. And sometimes, when you're looking outward, that's not necessarily the right format.

Users will tell you certain bits of information. I remember working on some UX for a banking app, and the best people we spoke to during that whole process were the help and support people, because they were telling us what people were phoning up with and what issues there were.

And some things you have to take with a pinch of salt, but that's where, if patterns are created, that then can flow into an application, and you're instantly resolving pain points for multiple usage. So it's so interesting.

Paul Wood (24:13)
Yeah. And on that actually, because that's quite a common scenario — interviewing the help and support team is a really good way to get information. And companies are increasingly rolling out AI-driven support chatbots where you can engage with it via the app or via the website and ask it questions. And the focus has so far been on, how do we make this chatbot really useful and able to deal with all different types of

customer scenarios? But one thing I haven't heard people talking about is how useful that tool could be as a source of user research as well. Because the questions that people are asking that chatbot are going to be a gold mine of, here's everything challenging about being a customer of ours. And that almost delivers your roadmap for your service and how you should design what you're doing.

So that's something that a lot of brands will have access to now. And as long as you structure it in the right way, that could be a gold mine of information.

Mark (25:21)
Yeah, absolutely. But I think if you think about what search engines are doing at the moment, lots of people are going to them where it's not necessarily searching for a keyword these days. It's almost like a problem is being input into a search engine. And if you can surface your content as part of those

Mark (25:47)
results — if your content is structured in a way that it's delivering a resolution, or it's piquing someone's interest to get them to the website, it's that valid approach, isn't it? It's always been the case that someone's always gone

to Google with a problem in their head. They've got a task, but now it's a lot easier to go, how do you do X, Y and Z? And Google presents you with clear, structured results from that kind of AI management, and feeding your content into that — whether it's structure from AI that you've gleaned yourself —

it gets you seen.

Amelia (26:42)
So what next, Mark? What was your next takeaway? What was your next talk, perhaps?

Mark (26:47)
So the third talk that I went to was by a girl called Louisa Berta, and her talk was about turning failure into opportunity. And this one again resonated with me because it was really interesting. And again, I think a core part of UX is

nothing is ever gonna be right first off. And I think what her talk was about was making sure that people in your business are comfortable with failure, and make it a necessity for learning and progress. And again, I think this is talking at scale, and obviously at smaller scale it can be quite difficult to do that.

But sometimes research can validate the idea, and sometimes people use research as reassurance. It's being comfortable enough to use failure in a way that then you can flip the switch on it and create some success with it as well.

And again, it resonated with me in a way that, at scale, I think failure is a good thing, because you learn about the problems and pain points, and you can do things with it. It's great. But obviously some people aren't comfortable with that as well. And I think it's how failure is positioned,

in a story, I think works really well. You could talk about vulnerability and mistakes, and then that starts to shift the perspective towards getting something that works and resonates. And I think,

talking about app design and stuff like that, failure is what you want to see. And if we frame it in a way where we're talking about the validation approach, spending that amount of time up front on validating an idea before something is developed, I think this thinking is really useful, because it just aids good user research.

Looking for friction, confusion, hesitation, that kind of thing is a really useful thing. So again, I think what she was trying to teach people — and I think a lot of UX people think that way anyway — but just hearing someone do a talk on failure was really quite an interesting spin.

Amelia (29:53)
How do you go about that, Mark? As you say, you can identify with that and agree with it, but how hard is it to get the rest of the team or your clients on board with this idea?

Mark (30:03)
Yeah, I think you have to be quite resolute. You go in hugely enthusiastic, you're talking about something, you test it and it fails massively, and everything's gonna point back at you. People just have to be comfortable with that. But it challenges your expertise, and you—

as long as you frame it — I think it's presenting everything, you see what I mean? In terms of going, we tried this, it failed, it didn't work, but that's okay. Moving forward from it is probably more useful for the business. But yes, absolutely, when you're trying to justify time,

it's quite a difficult thing for people to appreciate. Why is this guy jumping around because something failed? We want it to work.

Amelia (31:05)
Yeah, very much a case, I guess, of trusting the process, right, Paul?

Paul Wood (31:09)
Yeah. The way it's pitched there, failure is almost like trying to encourage a testing mindset to everything. We'll often work on projects where, during the course of planning, there'll be lots of features and ideas and approaches kicked around, but it's not realistic to put them all in at the start. So

you start to develop this model where you're delivering version one of a solution very much with a view to working on version two and then version three and so on. So we try and create this environment where everybody in the project — client side and our delivery team side — is mindful of the fact that this is version one. It will have things that aren't optimal.

But that's okay, because version two will come and look at how things have performed, and we'll deliver that. And that's probably the way to pitch it, because I suppose for the people who are maybe paying the bills at the end, they're not going to be involved in the day-to-day. So the concept of failure isn't one they want to hear about, but the concept of testing and optimising probably is.

Paul Wood (32:31)
And that's probably the way to think of it, or it's the way I think of it anyway.

Mark (32:36)
Yeah, 'cause she also spoke about documenting what didn't work and creating an insights bank. And she was talking about normalising sharing without blame. I think failure does lead to blame, and culturally that's just a natural thing.

But treating failure almost as the opposite of success — it's not the opposite of success, sorry. It's part of a process that leads to better thinking, is a much better way of framing it. Especially if you're talking about people who are very black and white in that situation.

Amelia (33:25)
Yeah, it's just a way of proving, perhaps, that something doesn't work. And that's the good thing, isn't it? So you can land at the place that it does.

Paul Wood (33:33)
Yeah, and it makes me think of something I think of as the print mindset, that you still see even though we're so far from the days of print being the main media. Where people would prepare something in a way that was like, well, once it's done, it gets printed and you can't change it. And that mindset still hangs around today. But actually when you're preparing something that's digital,

Paul Wood (34:01)
it's never really done. You can prepare it, you can launch it, and then you realise, we made an error there, and it's really not that hard to go and resolve it. And it's true of content, it's true of features, it's true of the way it looks and works. But it's funny how much that print mindset still hangs around today.

Mark (34:22)
No, you're completely right. I mean, you can deliver projects and people just want to draw a line once something goes live, and that's just not how digital products should work. Things need to evolve, things can scale, and it's that constant loop of iterating beyond a go-live date.

But having a good relationship with the client to discuss where things are falling down or not quite working, and being able to introduce new features, focusing on evolution rather than drawing a line under it and leaving it, just letting it sit there dormant. That's just such an old-hat way of thinking about products.

Amelia (35:13)
Absolutely. Now, we're going to get on to chat about AI in just a moment. Is there anything else you wanted to mention?

Mark (35:18)
No, other than I did an amazing workshop in the afternoon. So all these talks were the morning, and then in the afternoon they split it and did some workshops. And I did a really cool workshop with a guy called Chris Howe. I think he's the lead content strategist at Clearleft. And he called it "Yippie IA."

And the workshop essentially was explaining a LATCH framework for organising content. So LATCH is location, alphabet, time, category and hierarchy.

And essentially those core principles feed into an IA when you're structuring either website content or filtering, applying those methodologies. And he did a really funny exercise which was really cool. He showed us a picture of a record shop with all the records listed down, and he was like, I want you to apply the LATCH principles

to the organisation of this record shop. But I want you to do it in the least helpful way possible. And that really got everyone thinking conceptually about how to organise this record shop. And it was really fun because everyone was thinking of really crazy ways. You could go into a record shop and everything could be organised by album cover colour, for example.

Completely useless, but it would make the place look really good. So yeah, kudos to that. That was a really fun workshop to be involved in.

Amelia (37:10)
I like the sound of that. So yeah, we are gonna talk AI now. Of course we've spoken about it at length on the podcast, but Mark, how did UX London treat AI this year? What was the conversation around it?

Mark (37:11)
Yeah, so like I said, the talks kind of used it, they referenced it, but no one implied this is how to use it or structure it in any way. But the conversations I was having with people were very much around, how do you use AI in your processes? So

I was talking to a couple of the guys from Clearleft, because I was interested in understanding their approach. And Jeremy Keith, who is one of the founders of Clearleft, had a very theoretical way of thinking about it. He's like, well, artists and designers, we want them to do their thing, and we can use AI

to do jobs that we already know, so we're not having to — it's easier for us to integrate it. Which was interesting, because a lot of the talk about AI is creating efficiencies, but actually you still want your creative people or your thinkers to do the work that they want to do. So

AI allows them to be efficient with things that they know how to do, but it opens up time for them to do the thinking and the creating as well. But yeah, lots of talk about integrating with Claude, and how people are using that as part of their development processes. Not so much around design, in a

— obviously I was there on the Discovery Day, so it was more focused around the users and the research side of things. But yeah, lots of interesting chats, and lots of people with question marks around their heads just trying to work out how this new world is gonna pan out for them.

Amelia (39:31)
And it's quite specific, isn't it, with FS and with your clients? It's not just about speeding up those journeys, but explaining decisions, evidence, fairness, and avoiding bias as well. So what are the challenges there?

Paul Wood (39:45)
I think part of the challenge is, there's so much data available, it's knowing what to take notice of and what to maybe ignore, because there's just so much noise. And I think that comes back to the original talk that you mentioned, Mark, where something that often holds up a process is that there's just too much stuff.

And it's hard to organise it in a way that the people making decisions can really act upon. So I suppose the challenge for FS firms in particular is, you're dealing with high volumes of often sensitive information. You really need to invest the time in to just have someone set a few parameters to say, here's what we're actually going to use, and here's what it tells us.

And then just focus on that, and ignore all of the other stuff you could look at, because really you just want to cover the basics, and that's where you need to focus that effort, I think.

Mark (40:55)
Yeah, absolutely. There's minefields of data, meta information. Just to organise that and structure it — it just allows people to do their creative thinking as well. Lots of these tasks would have been done manually previously. So yeah, it buys you so much time.

Amelia (41:20)
And let's kind of end talking about — we've spoken about all those key messages, key ideas that you've taken from the event, Mark. But if you had to pick one thing that you would steal for your clients, what would it be?

Mark (41:37)
I mean, I spoke about the hypotheses, but I think the validation is the key thing. The point I was making about that validation up front is so valuable for projects. That's the one thing that I want to take away and introduce into my workflow,

so that I can position that to the clients that I'm dealing with. I think that's core to our process.

Amelia (42:14)
How about you, Paul? Anything that you have taken, you could nick from Mark?

Paul Wood (42:18)
Yeah, I agree. I think the validation point is really worth highlighting, because like I mentioned before, it's one of those things that feels like it's easier said than done. But in actual fact, we're entering a bit of a golden age of this type of thing, because you do have access to customer support team information. You also have access to,

like I say, the AI chatbots that people can use on websites to figure out something that's wrong. And if you put a bit of effort into capturing the stuff people are asking those teams and those AI chatbots, AI is really, really good at crunching that information. Like, we're doing it now for reporting that we do for clients. We'll take large volumes of keyword data that

covers a couple of years' worth of time, broken down by month. And AI is great at just analysing that and picking out the trends. And you could do that with data that comes in from your customer support channels. If you can get it into a spreadsheet and just show what people are asking, AI is going to be amazing at picking out: these are the common challenges that keep coming up.

And there's been a spike in the last couple of months in this type of request from customers. And that to me is a really good way to get simple customer validation on something. And then it moves you in the direction of that thing that you mentioned, Mark: falling in love with the problem, not the solution. You're immediately getting there a report of validated problems that real customers are facing, and you haven't had to get them to fill in a questionnaire.

Paul Wood (44:12)
It's just stuff they ask because they need to. I would bet a lot of money on the fact that most companies have this data available. And actually they just need to organise it. And that would probably give them a year-long roadmap then, to say, ignore everything else that you were planning to build — this is what you should be building.

Amelia (44:34)
So it's already there. It's already there for the taking.

Mark (44:37)
Yeah. Knowing how to use it, yeah.

Amelia (44:41)
And just a final word on UX London in general, Mark. Sounds like you took a lot from it. Will you be going back next year?

Mark (44:48)
Yeah, I'd love to go back. I always like going to these events. I always feel like you learn something — someone's got something quite innovative to take away. The guys at Clearleft, they know how to run these things. They're really well structured. I would recommend it to anyone, even if you, just like me, do a single day. I think all days would have highlighted lots of

cool information that resonates with people in our industry.

Amelia (45:19)
We'll get you to do a testimonial, Mark. Five out of five, we'll go again. Shall we play a bit of Jargon Busters before we go?

Paul Wood (45:25)
Yeah. Give it a go, yeah.

Amelia (45:31)
Do you remember how this goes, Mark?

Mark (45:32)
I think so. I'll give it a try.

Amelia (45:34)
Yeah, so I've got a list of industry terms, bit of jargon, and we see if you guys can work out what it means. Today's term is "dark pool." Any ideas?

Mark (45:47)
Dark Paul? Or dark Paul — grumpy Paul?

Paul Wood (45:49)
It's not an evil version of me, is it?

Amelia (45:49)
Pool. Yeah, P-double-o-L.

Paul Wood (45:55)
It's my evil twin.

Paul Wood (45:59)
Go for it, Mark.

Mark (46:01)
I have absolutely no idea. Breaking it down — is it a long period of time where, I don't know, finances aren't doing very well or something like that? I'm not sure. No.

Amelia (46:20)
Not quite, Paul.

Paul Wood (46:20)
It's another one that makes me think of investments. And a pool is, I suppose, a collection of — is it a pool of assets, that "dark" would suggest is either not good or it's unknown? Maybe it's an unknown element of a collection of investments.

Mark (46:25)
Where do these come from?

Paul Wood (46:49)
Yeah, that's the best I can do. I genuinely don't know.

Amelia (46:53)
I mean, you are sort of on the right lines with the unknown, the private. So it means it's a private exchange for trading securities, not accessible by the public.

Paul Wood (47:03)
Oh, okay. So it's, yeah.

Amelia (47:05)
So, I mean, not the best. We haven't had the best few weeks in this, have we, Paul?

Paul Wood (47:10)
No, no. I suppose this is why we do it. We want to learn.

Mark (47:13)
Yeah, we need to read up on these.

Amelia (47:13)
Exactly. Now, well, now we know. We've learned so much today. Mark, thank you so much for coming on, and hopefully we will chat to you again soon. And of course we will be back next week. Thanks for listening. Have a great weekend.

Paul Wood (47:16)
Yeah, it's not failure. It's a test.

Mark (47:19)
We need to embrace it, that's it. We need to learn from our failings.