Make an IIIMPACT - The User Inexperience Podcast

Welcome to another episode of Make an IiIMPACT - The User Inexperience! 

I'm your host, Makoto Kern. In today's episode titled "Meet The Team: Jackie Lampard - Sr. UX Design Lead," we're diving deep into the world of user experience design with our special guest, Jackie, a Senior UX Designer who's been leading transformative projects for the past decade. We'll explore the exciting journey of our application's internationalization for markets like France, Germany, and Portugal and discuss the essential role of Product Owners in balancing business, design, and development needs.

We'll touch on some of the challenges and risks faced during feature development, and how Jackie and her team have improved their workflow through regular design meetings, an established design system, and efficient communication channels. Learn about the vital elements of research, wireframing, testing, and iterative design that Jackie relies on to create user-friendly interfaces.

We'll also hear Jackie's take on the future of UX in a world increasingly influenced by AI, and her passion projects that go beyond her design career. Whether you're a budding UX designer or a business leader looking to enhance user experience, this episode is packed with insights that you won't want to miss. So sit back, relax, and let's make an impact together.


Timestamps:
00:00 Passionate about UX and problem solving constantly.
05:27 UI overhaul succeeded; positive feedback despite minor bugs.
07:20 Lack of communication caused significant technical debt.
11:09 Questionable investment due to non-representative user feedback.
15:12 Team collaboration ensures consistent, autonomous design updates.
18:59 Design systems ensure consistency, reduce tech debt.
21:57 User testing and design streamline development process.
26:06 Collaborative design effort led to prototype development.
27:33 Facilitating quick UX ideation unites 16 viewpoints.
32:21 Never wanted to write; AI replaces junior work.
33:56 Unique, custom designs; AI for menial tasks.
36:40 Reads French, can't speak; loves animals.


BIOs

Jackie Lampard - is a Sr. UX Product Design Lead @ IIIMPACT and has helped with redesigning consumer and enterprise software applications for the past +5 year with our company. She is a dedicated product design professional who has played a pivotal role in transforming how companies approach user testing and design. Initially confronted with a mindset that saw testing as an unnecessary expense, Jackie was instrumental in advocating for its importance. Through persistence and building strong client relationships, Jackie managed to shift the perception, demonstrating the tangible benefits of thorough user testing and best UX processes. As a result, clients grew to trust and appreciate the process, leading them to invest more in developing comprehensive user flows and journeys. Jackie’s expertise ensured that every click and action was thoughtfully mapped out, leading to seamless and user-friendly experiences. Thanks to Jackie’s efforts, more companies now recognize the value of proper testing and are committed to integrating it into their development processes.

Makoto Kern - Founder and UX Principal at IIIMPACT - a UX Product Design and Development Consulting agency. Makoto Kern is a leading expert in the design world, recognized for his proficiency in creating and implementing design systems. These systems are crucial for ensuring consistency across various teams and products within a single application, preventing discrepancies that can increase cognitive load and technical debt. Makoto emphasizes the importance of using specialized tools to accelerate the development of cohesive design systems, thereby maintaining uniformity and efficiency in the design process. Through his work, he has become a pivotal figure in fostering streamlined, consistent user experiences. His team has successively launched 100s of digital products over the past +20 years in almost every industry vertical.

IIIMPACT has been in business for +20 years. Our growth success has been rewarded by being on the Inc. 5000 for the past 3 years in a row as one of the fastest-growing private companies in the US.  Product Strategy to Design to Development - we reshape how you bring software visions to life. Our unique approach is designed to minimize risk and circumvent common challenges, ensuring our clients can bring innovative and impactful products to market with confidence and efficiency.  IIIMPACT helps clients get from the 'Boardroom concept to Code' faster by reducing risk and prioritizing the best UX processes through their clients' teams. 

Follow along for more episodes of Make an IIIMPACT - The User Inexperience:    https://www.youtube.com/@makeaniiimpactYT

What is Make an IIIMPACT - The User Inexperience Podcast?

IIIMPACT is a Product UX Design and Development Strategy Consulting Agency.

We emphasize strategic planning, intuitive UX design, and better collaboration between business, design to development. By integrating best practices with our clients, we not only speed up market entry but also enhance the overall quality of software products. We help our clients launch better products, faster.

We explore topics about product, strategy, design and development. Hear stories and learnings on how our experienced team has helped launch 100s of software products in almost every industry vertical.

Speaker 1:

Design systems is such a big thing in the design world, especially using certain tools that help you accelerate and create a design system. But we know that, you know, if you're gonna have different teams, different products, and this is all within one application, which can be huge. If you don't have a design system, you we know things will be inconsistent. If you have people going rogue, all of a sudden, this drop down over here is going to look different than the drop down on this page, and and that consistency is going to just add to the cognitive load, more tech debt, things like that.

Speaker 2:

Being the only designer, there's nobody else that is the guardian of the design. There is no one, the gatekeeper to the UI, that makes sure that if I'm going to click the save button on page 1 and hit the save button on page 75, it's going to behave exactly the same way.

Speaker 1:

Hello, everybody. Welcome to to the podcast. This is another episode of make an impact. Today, we're doing another another episode of meet the UX designer or an interview with a UX designer. And today, we have Jackie Lambert.

Speaker 2:

Hello.

Speaker 1:

She's been with us since she's been with us since 2020.

Speaker 2:

Yeah.

Speaker 1:

She's been a senior UX designer. She's been lead on multiple projects, helping clients out with enterprise and mobile applications. And so today, we wanna hear her story and hear a little bit more about what she's she does as a designer. Welcome to the show, Jackie.

Speaker 2:

Hi. Thanks for having me.

Speaker 1:

Definitely. So just to get us started, you know, what inspired you to pursue a career in UX design?

Speaker 2:

I've just I love to understand how things tick. I have a huge, like, passion for solving problems. My my writer friends say, don't ever say passion, but I guess it kind of is. So I I'm actually half almost left and right brained. So my father was an engineer.

Speaker 2:

My mother an artist. So it kind of just smacked in the middle for me almost perfectly. I started in the design industry. I wanted to be in advertising. I wanted to make TV ads.

Speaker 2:

That's dead and gone now as an industry. But I started working in agency, and I was was designing, you know, everything from a 160 page coffee table book to a map to social media posts. And when I started to get into the digital aspects, I really enjoyed that because I really enjoy understanding the technical aspects of things as well. So when it comes to looking at, okay, I've got a book in front of me. I need to understand, okay, this is going to be as quick to read as possible.

Speaker 2:

I'm gonna get the point as quick as possible. What is gonna be clear? What is not? So when I was just starting out in publication design and basic graphic design, that was always more interesting to me that I need a flyer. Why do you do you need a flyer?

Speaker 2:

Are you sure you need a flyer? I think I need a flight. No, you don't. So it's like telling people what to how to solve their problem and like, what do you actually want to do with this than say, what? And that kind of led me into this journey of UX, where I really, really enjoy just going into what is the problem and how can I solve it?

Speaker 2:

And I mean, I build puzzles, I've placed a docu. I do crosswords, problem solving 247 as a hobby. So if I was in any kind of industry in a working environment where I'm not doing that, I would feel like I'm not challenging myself enough. And then that's when I get bored. So I need to be busy in order to be happy.

Speaker 2:

And I really enjoy that.

Speaker 1:

You go to school, like, for graphic design? Or

Speaker 2:

Yes. I did a a degree in visual communications, which covered marketing and design, as well as multimedia copywriting, creative communications on an interesting level, like critical studies. You had to break things down and understand why they were the way they were and analyze it and argue it. It was actually really interesting subject.

Speaker 1:

Okay. You definitely have an engineering mindset.

Speaker 2:

It helps a lot with the development team as well, because I'm quite embedded with the projects that I work on. I don't come come in as an as a contractor that's just going to do the work and then pass it on. I QA it myself as well. I get involved in the conversation with the developer. We'll mark, like, meet kind of on and one with engineering and engage with them to find out where the limitations are.

Speaker 2:

So, like, we have a e stories, where I get involved with the developer on calls and chat through the limitations. What do we want? And then from there, we get something that is both user focused, business focused. K. That's 3 things.

Speaker 2:

And, makes the application, the best it can be for work.

Speaker 1:

I'd say let's talk about a recent project because you're about to. Let's let's dive into something that you can, you know, I guess, specifically, highlight a success story, any challenges, strategies, and things like that being a UX designer, whether you're you've been a team of 1 and you've been on on a team of multiple designers. Can you tell us a little bit about a certain client story?

Speaker 2:

So I'm not gonna mention any client names, but when I started on this this, very large project, which is more than 70 features, it is an enterprise application as well as a mobile application, which is a diminished version. So it's not as many features, but it is quite quite regularly used on-site by the user.

Speaker 1:

And it's a it's a old it's an older application that was redesigned

Speaker 2:

from It's it's it's a complete overhaul of the UI, of the UX, but not in the

Speaker 1:

the text value.

Speaker 2:

The calculation engines are very much the same Mhmm. Logic. So the the entire application has been brought over into a new brand. And with that came a lot of challenges in the sense of alter change averse, product managers as well as users. So the feedback we've gotten since the change has been really great.

Speaker 2:

People that are long term users and brand new users that have never used the original product before, have raving reviews. And even the QA teams that work on both the old product and the new product, they don't wanna work on the old product anymore because it's more frustrating for them to do basic testing than it is to just click through and work in the new product. So it's been really positive. Obviously, there's a few bugs and there's a few things here and there that we work on, and we meet regularly with products to iron those out. That's why as a designer, I also assist with QA to make sure that what we plan, with product is what is executed and that the developers are able to fully get all the questions they need answered quickly, because sometimes these things are safe re urgent and have to go out.

Speaker 2:

Someone's in unable to use their software to do their day to day work, it can become quite limiting quite quickly, and they might have to get that done within a day or within 3 hours. So sometimes these things are quite on the shopping block, but it's been a great experience working with them as a team. It's very integrated. In the beginning, it was a real struggle. I admit it took about 3 years to get a process going that also had a variable change and high staff turnover at first.

Speaker 2:

They started out with a very different design leadership strategy, and eventually we found that we didn't need a design leader. It was more of a

Speaker 1:

We were the design leader.

Speaker 2:

Yeah. I think it was a designer in the end. But it was it was like a bottleneck in a huge way because there was no communication between us as the designers. At the time, it was myself and 3 other designers. And then the development team, we were very cut off.

Speaker 2:

And when that was happening, there was massive disjoint in the actual output, which led to a lot of technical debt. And we're still trying to get rid of that technical debt today. It was a bit rushed, to go into production from a leadership perspective, but now we've come with a proper process and a strategy to get through everything that's in the backlog and start moving things along. And some things are sometimes feature orientated. We wanna get a new feature out for the new client that's coming on board, and they specifically use a feature.

Speaker 2:

Otherwise, we're gonna focus on bugs in a large aspect and sort of streamlining and improving performance.

Speaker 1:

Okay. And right now, they have the the new design live or a new application live with with certain clients.

Speaker 2:

Yes.

Speaker 1:

It's getting more has been received pretty well.

Speaker 2:

Yes. So we've got, 2 or 3 new users that have never used the original product. When I say users, I mean companies. They're quite large organizations that are multiple locations, and they're not only in the US. It's international.

Speaker 2:

We're actually internationalizing the application for various languages and browser. So French, German, various different Englishes as well, Portuguese are all coming on board for, internationalization, which is quite exciting. And, it's been it's been an interesting journey, learning and uncovering all of that. And, yeah, I think it's been a good a good process so far. The developers that are working on this are also quite well versed in this area.

Speaker 2:

So

Speaker 1:

We're from a so it sounds like, you know, obviously, communication is a is an important point, especially between teams. What do you see let's get into maybe some of the aspects of the the business side of things of where where do you see some of the the learnings or some of the mistakes that were made from a business strategy standpoint to the to the basically, from, you know, ideation to the design. Let's take that first stage. What what mistakes do you see them kinda making or what risky decisions have they made so far and how they've improved or what can we do to improve on that?

Speaker 2:

When you're not familiar with design, working with a UX team or person, your mindset is more engineering than user. So it took it took quite a bit of conversation and coaxing. And and, you know, you plant a seed and you hope it grows, and eventually it did. That we kind of moved them into a different mindset, where they became more user focused in the end.

Speaker 1:

Versus feature focused.

Speaker 2:

Yes. More tolerance of of I don't want my logo to be the biggest thing on the screen because it's not for me. It's for my user. The user must be happy with what they're getting. It's not about the business entirely.

Speaker 2:

Obviously, there's business goals that have to be achieved. We have a new feature coming up that has a very steep business goal, and we've had conversations about the MVP, which is the minimum viable product and what that's going to involve. So from a starting perspective, from the design side, we looked at how we could solve the major problems, which were people who were running costs through the system in the old in the old application where they could charge twice for the same thing. And this is a very big risk. So we wanted to try and solve that with the least amount of cost involved in time first before rolling out the entire new feature.

Speaker 2:

But when we spoke to the CEO, he wanted to roll out the entire thing from scratch. He luckily said time isn't an issue, which is amazing.

Speaker 1:

Sounds a bit risky.

Speaker 2:

Yes. So there's there's a lot of money and a lot of time going into something that might not be adopted or might need a lot of rework. We don't know. We did some basic user testing with it, but the users that we got were not actual end users for the most part. There was a quite a bit of resistance on people because this is quite a time intense business as as a whole.

Speaker 2:

It's people that don't have a lot of time to spend, and they don't have a lot of time to do their day to day job. Now to go and spend time doing this was something they weren't really available for, all that willing. And the feature itself is also quite it's it's data intensive, and it's really interesting. It's great reporting data. It's it's kind of if you don't populate the data, you don't get the result that would benefit your business.

Speaker 2:

But if you do, you know, you you can really help yourself. It's just the time. The time is a lot. So we wanted to test how time intensive it would be. And business goal was to make money as fast as possible and not to solve the user problem.

Speaker 2:

And because of this, we haven't been able to prioritize solving this huge risk over pushing out a massive feature that allows people to invest in something they haven't actually tested properly. So that's the Yeah. That's the risk. It's we did convey the risk to them. They've made the decision regardless.

Speaker 2:

It's now going through the journey mapping process and user story mapping. So we're starting out designing the actual, MVP now, which is they now well, they've said time isn't an issue, but then some of leadership is also saying, oh, he wants it by the end of the year. So that's in 6 months. It's it's, a lot of work for such a short time. And Russia

Speaker 1:

Doesn't sound too agile with the time constraints.

Speaker 2:

It's Yeah. Agile. This yeah. It varies.

Speaker 1:

We know that product owners, you know, UX used to be the glue that kind of brought everything together between business, dev, and design. But now product owners are pretty much that glue between business design and development. What have you seen as far as what is what makes a successful product owner? Because from my experience, we've seen, you know, that can make or break your product is a good or bad product owner. What have you seen?

Speaker 1:

I'm sure, you know, as a UX designer, we always try to tell our product owners to take innovative risks. But kinda tell me a little bit more about your experience and how you've, you know, you've worked with the product owners and how you've tried to get them to change their mindset if you needed to.

Speaker 2:

We've had a few product. Few of them. Yes. I said, staff turnover. It's a little higher than it should be.

Speaker 2:

There were some that would kinda go rogue and just do the ones, which was really interesting. So you'd build a whole design system. You'd work to a cohesive process, and then they would just go, oh, let's just go and do this on this page even though there's a pattern of behavior for this.

Speaker 1:

Mhmm. Like They won't ask designers even though they have one on their team.

Speaker 2:

Yeah. So this was also a lot of, change diversity. It's people that have never worked with designers before. They've not used to UX. They just want to get engineering happy quickly, and they just push on accelerator without putting it into thought.

Speaker 2:

The problem with that is there's a lot of rework, and it just created a very dense backlog. So for that role, you need somebody that's decisive and that is able to take feedback. Somebody that can work in a team, not somebody that works in the silo. You need to be able to accept constructive criticism, be able to take ideas, be able to give ideas, and be a collective, again, communicate. We now have a really great process.

Speaker 2:

The current product owners are are really good. I'm quite happy with them. We've got a great team going. We now have everybody is in a meeting every week about anything design related. You anybody in that meeting can choose the agenda, so you can anyone can add a point they wanna discuss, and everyone listens, which is great.

Speaker 2:

And everyone gives their opinions and their feedbacks. And, obviously, the these people that can veto, but you have the right to say and you actually get autonomy, which is amazing. So in the beginning, it was more perceived that as a as a team as impact, we were external and we don't have a say on the design, but being the only designer, there's nobody else that is the guardian of the design. There is no one the gatekeeper to the UI that makes sure that if I'm going to click a save button on page 1 and click the save button on page 75, it's going to behave exactly the same way. And a lot of that lives in my head, which is Yeah.

Speaker 2:

I think. But it is also documented in a very vast, design system, which took more than 8 months to produce, and it's constantly updated. So constantly updating that also takes time, which is part of my responsibility. As well as every time we do make a big decision where something is going to affect the way something works, not just what it looks like, then that has to be updated and it has to be agreed upon between the different team. It was the product owners have to be involved in that decision making as well as the engineering department and myself.

Speaker 2:

And then from there, product owners have actually found the design system, helped them a lot because they could just go, okay. Search a word that they were looking for in a story or that engineers ask them, and they could go and find it. And if they didn't know, they could just message me, and I'd be like, oh, hey. It's over here. And also with that learning and development, creates all the help information, they're using Zendesk for that.

Speaker 2:

So they create all of the documentation that goes around with the screenshots and everything, and they say, what is this icon called? I need to refer to it in the documentation. So now we have an open chat where I just go, hey. It's this. And it's as simple

Speaker 1:

as that.

Speaker 2:

And there's no more waiting for emails or long ask you ask you ask you ask you. It's just it just asked me directly, and that's been a lot better. But just to get not having a bottleneck of multiple leadership roles in a a necessary flowchart of Hireup.

Speaker 1:

Yeah. I think an important point here is that even though a company is a software company or has software, maybe they created 10 years ago or 5 years ago, doesn't make them an expert in creating new software. And, you know, whatever got them there to begin with, what we've seen, and I'm sure you've seen that, it doesn't make them an expert to get them to the new place or innovate to to a new product. And it seems like it's it's rife with bad habits. And like, this is what we did before, so let's try it again.

Speaker 1:

Or, you know, this is what I think I'm comfortable with, so I don't want to change the way I do things. And so I think this is a good kind of segue into maybe what, you know, from the things that we do and the processes that you've been involved with. What what do you believe sets our company apart from others in the industry or the places you've been?

Speaker 2:

I see us as not just a contractor. You're not just somebody that's coming to work on a project and disappear. It's you become part of a team. You're embedded. You're a bum in a seat in the team itself without the HR hassle.

Speaker 2:

So you don't have to as a company or as a client in this case, have to deal with labor resourcing impact. Does that for you? It takes a risk for you and you get a person that's fully embedded in the company as if they were employed. So it's, it's a really nice option for clients, and it's really nice for us as as designers because we get a stable, consistent work with a team that you actually build a relationship with. You build a rapport, you have a respect between the team members.

Speaker 2:

It's not like, yeah. I'm gonna ask your opinion, but I'm not gonna take it. It's autonomy. It's stronger. It's it's lasting, and it's also great for your portfolio.

Speaker 1:

And I think you made a good point too. You know, design systems is such a big thing in the design world, especially using certain tools that help you accelerate and create a design system. But we know that, you know, if you're gonna have different teams, different products, and this is all within one application, which can be huge if you don't have a design system. We know things will be inconsistent. If you have people going rogue, all of a sudden, this drop down over here is going to look different than the drop down on this page.

Speaker 1:

And that consistency is going to just add to the cognitive load, more tech debt, things like that. And I'm sure as you're building that design system, is there any other, I guess, ways in which you you've created, especially being a team of 1? You know, if there's a bigger team of designers, you know, tell us a little bit more about how you manage from that ideation to actually creating wireframes, user testing, and then design system management.

Speaker 2:

There's a lot of research that goes into it. So looking at obviously trends that are going on forums, discussions, articles, that sort of thing, looking what other applications do, typical best practice, following obviously the basic rules of UX as well, and then looking at the patterns within the application that already exist. So do not change that in one place instead versus another. And, from there is just, yeah, wireframing low lo fi. So basically, like a blueprint you will see for a house when you first start.

Speaker 2:

From there, you start coloring it in and adding detail, and you start testing it yourself. So as you start testing it yourself and you start asking yourself, where am I gonna get the data for this input field? Then you start looking at, okay, how someone would populate this. Then I tend to get someone to play with it and see where they struggle. Don't really tell them too much information.

Speaker 2:

Just see what they do. And then from there, I go into, if I can get actual users, it very much depends with my current situation in this project, there's a very big struggle with getting users that are actual valid users or end users. Mhmm.

Speaker 1:

And also They're giving the right feedback too, I bet.

Speaker 2:

Yes. It's quite they're quite averse to user testing. In the very beginning, it was almost a waste of money in their opinion from the feedback that we got. So they just wanted to push everything out and then say, oh, you can play with it in the sandbox. So now that we've actually gotten more trust with the client and build a stronger relationship and planted some seeds while ago and they've grown, they are now like, okay.

Speaker 2:

This is actually beneficial. We've learned. We should do this more often. So it's really interesting how you kind of have to prove it in a way because they're not familiar with the whole concept of what does a user want? They just go, how can we build this quickly?

Speaker 2:

So it's a it's a different mindset, but I I find that the the testing part is something many companies overlook. It's not just this kind of line. It's it's quite a common thing to have to try and negotiate to get them to buy in. And then, yeah, once we've done the user testing, then we'll start implementing, like proper screens. And obviously, there's a user flows and user journeys.

Speaker 2:

So if you've got something that, like, if I click this radio button, it's gonna do this, and you're gonna have a spider diagram that goes off and off and off and off. And that's really helpful as well for the product owners that have to write stories for the developers because then you've already solved all of the problems. They don't have to really think. So it saves them a lot of time. And then when you walk through the whole process with them, they have a lot of input and questions and get that all out there before it goes into the developer's inbox.

Speaker 2:

And, yeah, once everything is agreed upon between development and design and product, then it goes into the design system. And the design system at the moment is broken down by components, the, templates, the templates being, like, much bigger. So this is a whole page. That's what all page would look like. Components being things like buttons, checkboxes, radios, that sort of thing.

Speaker 2:

And then we've also got brand. So brand is like colors, shadows, fonts, BOGO regulations, and then we've got content. So the content comes down into validation rules, how we write, how we speak, tone of voice, accessibility rules. Accessibility is also something product owners do not prioritize. They tend to we've actually got a colorblind product on it.

Speaker 2:

So that's been really interesting. So we can learn a lot from him and grow the product and then a bit more accessible because we've actually got a product owner that cares about accessibility, whereas majority of my experience has been accessibility. It's very low priority, even for keyboard usage, which is quite common in the current old application. They are not prioritizing keyboard usage as an accessibility means for the new application.

Speaker 1:

I know we've been involved in a few different I don't wanna say workshops because they usually have a bad rep, but more of a we call it an immersion sprint and a design sprint. You know, these are these are exercises in which you get to something that that's an outcome Mhmm. That's that's a concrete outcome, whether it's more of identifying an MVP, a road map to actually creating a prototype to test with with users. How's your experience with working with those sprints on your side? How do you feel about those?

Speaker 2:

Well, at first, like, we were starting with the future, which is quite big. It's very vast. It's it's going to take a long time to build. They wanted to discuss that over a spreadsheet and a phone call. So that was their original plan.

Speaker 2:

And we had to convince it took a bit of convincing, I admit, that a sprint would be the best solution because there were a lot of stakeholders that had a lot of opinions and there was a lot of uncertainty from product. So it wasn't just uncertainty from from me coming into the project not knowing what they need, but from them themselves, they didn't know what they need. So they agreed to a a design sprint, but it was not the 5 day sprint that we are normally doing. It's the 3 day. It's 3 days.

Speaker 2:

No. 2 days. 2 days of in a boardroom the whole day with 16 people. So it was a lot more stakeholders that we would have normally worked with. So there's a lot of distractions and people running off topic, but then there was also a really good cohesive output.

Speaker 2:

People got to get, you know, you kind of just vomit out all the ideas first and then the real ideas come out. So we got a lot of that out quite quickly. And then we yeah. We went through a great process. Scott facilitated it, and he he's wonderful.

Speaker 2:

I really commend him on his ability to never show

Speaker 1:

Heard the cat.

Speaker 2:

Frustration. He he looks like everything's going perfect all the time, even when time is running out and people are waffling. So, I quite enjoyed doing a session with him. I learned a lot from him as well. And yeah, it was really great hands on drawing.

Speaker 2:

We all drew ideas. We had leadership drawing ideas. We had product owners and account managers and heads of capital projects, drawing ideas, and everybody was designers for a day. It was amazing to see how people came up with and people voting and tending to have similar opinion about what they voted on. It's very interesting.

Speaker 2:

And, yeah, we came down to at the end of the week, we had, everything drawn up, and we had a a storyboard for what we were going to do, which then I took home with me. And over the next few weeks progressed into the wireframe for, the test prototype. No. It wasn't obviously the final thing. It was just to test what we could because we were supposed to do all of that in the design sprint in a week, but it took them about a month to get us to start getting users.

Speaker 2:

So Yeah. That there was quite a delay in the process, which dragged it out quite a bit. The tests that we got were about 8, so it wasn't a lot. And then only 2 of them were real users. So we did meet with them afterwards almost to try and have the last day session of the 5 day, which was 3 months later, to discuss, you know, should we still keep testing?

Speaker 2:

What do we want to do for an MVP? And they said they didn't want to test any further. They wanted to start producing and getting out, and they wanted to do the full thing from start to finish. So it, it was not a 5 day. That would be, I think, one of the most interesting sprints that Mhmm.

Speaker 2:

Kind of compromise between the businesses plan and the actual process that it should be.

Speaker 1:

Yeah. I think I think you make, you know, obviously, a good point is that you get to at least the ideation and the story, what you want to test, and the and the big chunks that you want to understand from your users. And it's and it's something that if you are going to each of these 16 people, these people's ideas, talk to them meetings, hey. What do you think? And going back and forth, that process, what people think that's what you should do, would take far longer to get to a story map ideation, what we need to test versus putting people into a room, putting them on the spot, being able to to facilitate that kind of discussion.

Speaker 1:

Like you said, it's it it it is an art form to get 16 different viewpoints and kinda consolidate into a story within 2 days. And, yeah, that's something that I I know that that helps us stand out a bit from what people think UX should be. And us being involved in that type of, facilitation has been pretty powerful with with the clients. So they they get to see that firsthand, especially when you've got you know, companies usually they're gonna be dysfunctional if they need consultants in some way. So for us to herd those dysfunctional cats into a better process

Speaker 2:

Yes.

Speaker 1:

Faster is always a good feeling when we do that.

Speaker 2:

They had great feedback. They loved it. Yeah. The clients absolutely enjoyed it. It was also really nice to meet people face to face.

Speaker 2:

Yeah.

Speaker 1:

You flew in from South Africa.

Speaker 2:

Yes. So remote working is I mean, it's got its great benefits. But when you've been working with a team for 4 years and you haven't met them, it's like, hi. This is what I look like. And when you're actually looking for a person and you don't know what they really look like, but you could tell them from their voice, and you're like, oh my gosh.

Speaker 2:

I know who you are. That was so funny for me, but it was a lovely opportunity to meet everybody. And, actually, we spent social time after the sessions in the evenings together, getting, little catch ups. And we all have our own little inside jokes, actually, as well.

Speaker 1:

Oh, yeah. And we're not gonna talk about any Christmas signs either. That's a story for another day. How do you stay so let's let's get to maybe some kinda tips and tricks for any other UX designers that might be listening. But, you know, how do you stay up to date with the latest trends and what kind of lessons that took you a long time to learn in your career that you could kinda give advice to?

Speaker 1:

You know?

Speaker 2:

So I I belong to a really great Slack channel, Zed A Tech and Zed A Prod. So it's a forum of freelancers, developers, designers, copywriters, a mixed bag. And if I honestly don't know something, it's an open environment to ask. I've met some really great people on there that are very willing to help. I've also got some friends from working other web that have actually been on that group too.

Speaker 2:

So if I've got a technical question and it's 9 AM in the morning and my clients were asleep, I can actually just go ask and they help me. It's really great. And, otherwise, I read a lot. I look at social media, UX trends that I follow. I follow a lot of on on social media as well.

Speaker 2:

And then team members, I ask questions. There's the other designers that have a lot of them actually have more experience than me that I enjoy chatting with. And we've actually both learned from each other. And then we have our monthly knowledge share sessions where we discuss how to learn

Speaker 1:

Stop canceling and postponing.

Speaker 2:

I've heard great things from from Jamie on there as well, and Nikki. So it's, yeah. And there's also lots of tips and tricks that, I get just from medium articles and playing with lots of applications. I I I download strange applications and I play with them. It's just using using it and then understanding what's annoying and what's lovely.

Speaker 2:

And then when I find something that's lovely and I just take note of it, and and I'm like, I'm going to build something like a calculator. I'm gonna play a lot of calculators. So Yep. Kind of how I go. I do.

Speaker 2:

I learn by doing. Okay.

Speaker 1:

Where do you see obviously, AI is is getting big. I guess, where do you see the field of UX and design going in the next 5 to 10 years?

Speaker 2:

I think UX and UI only has really fallen away. I like to think that AI will be a tool for getting rid of menial work, like image sorting and message writing. And I got the amount of error messages that I have to write is a lot. I feel like I'm a expert in error messages at this point.

Speaker 1:

You're an expert copywriter?

Speaker 2:

Yeah. I I never wanted to be a writer. I worked actually at a newspaper for a few years, and I never wanted to be a writer. I even I even found, you know, when you see those Facebook memories of things you wrote when you were, like, 21, and you were like, I wish my boss would just realize I'm not a writer. So prove myself wrong there.

Speaker 2:

And, yeah, I mean, for junior work, I think that's gonna take away a lot of junior work, which is sad for juniors that are upcoming and wanna learn because there's not so much that they can take on because people are just gonna use a free AI or Canva or something instead of paying a junior. So Mhmm. There's that. But, also, I don't wanna do that work. So Yeah.

Speaker 2:

It's it's definitely gonna save the hassle. And some of my colleagues, former colleagues and friends in the industry, they use, AI to write blogs. They use that to do all their writing. So I kind of feel sorry for actual copywriters, journalists, and the like that. All you're gonna be doing now is fact checking and proofreading.

Speaker 2:

So Mhmm. It it is gonna take a big toll on making everything look the same. It's definitely gotta find a way to be unique. Otherwise, you're gonna end up with a very theme based world of digital products. Every phone is gonna be the same.

Speaker 2:

Every website's gonna be the same. Everything is just gonna look boring. And

Speaker 1:

That drives us designers crazy.

Speaker 2:

Yes.

Speaker 1:

No uniqueness.

Speaker 2:

I as a designer who started out in publishing and moved into all the other areas, I've worked in pretty much everything, branding, all of it. I don't ever work in templates like website templates. I'd work in from scratch, completely unique designs just for you. And in that, there is a sense of, you know, this is this is my website that I paid for that I know is mine. It's not the theme forest that someone created.

Speaker 2:

And AI is just generally gonna be, in my opinion, doing a lot of the tasks for the next few years. I think I mean, take advances very quickly. So after that phase is out, I mean, already you can make photos, generate photos out of anything, although sometimes they have 6 fingers. And it's a little risky, but it's gonna it's gonna be smoothed out and it's not gonna take too long to do that. The more people input feedback, the better the AI generation is.

Speaker 2:

And I mean, things like gardening applications, which I've sort of played with, are really interesting because it can identify your plant again, but it's going to get it wrong a lot at first and then it starts to get better. So people are starting to respond and say, no, it's actually this. And then it's going, okay, now when I see this maple tree, I'm going to say it's a maple tree. I'm not going to say it's a sweet gum. So it's gonna learn because of human input, and that's when it's gonna start to get more advanced.

Speaker 2:

I don't think that the robots are gonna take over the world, and it's not gonna be like fallout. It's a contradict the future.

Speaker 1:

Or Terminator. Yes. And we'll we'll leave with one final question. If there's a passion project that you could could do, which what would that be?

Speaker 2:

Really enjoy education. I I also have, I've got a real love for helping people and doing the right thing. Animal welfare is a big cause in my heart. Education in South Africa is really bad. It's a lot of unemployment because people are not educated.

Speaker 2:

I'm somebody that self studies a lot. I'm currently doing a diploma in psychology that I just decided to do last year. Yeah. Cool. I'm very learning.

Speaker 2:

You know, you do those 5 strengths assessments. Learning is one of the Mhmm. Top 2. The other one is since don't build empires. It's kinda commander.

Speaker 2:

When I'm deviating. So, I've lost my point. What was this?

Speaker 1:

It's a passion project.

Speaker 2:

Passion project. So it's something like educational app, something like Duolingo, but works because Duolingo doesn't work. I've been doing it since 20 well, and I still don't know how to speak French. So something like that.

Speaker 1:

I only know a couple French words Yeah.

Speaker 2:

If I

Speaker 1:

don't think they're clean. It's

Speaker 2:

I can read it. I can read the shampoo bottle when it's in French, but don't I can't speak it. I mean, it's great for internationalization right now because I know what things are supposed to say, but I don't know how to speak it, and I can't speak to a French person in French. And it's very difficult language. But, yeah, education, health care, also very important, and anything to do with animal welfare.

Speaker 2:

I love animals. If I could just work with animals, I don't even know what I would do, but animals is like Yeah.

Speaker 1:

In danger. Or

Speaker 2:

Yeah. Anything like that.

Speaker 1:

Maybe AI will get us to be able to talk to certain animals once we decide for that.

Speaker 2:

Well, there is that more speaking about AI. They were interpreting the language of dolphins and that they could actually That's

Speaker 1:

what I heard.

Speaker 2:

Yes. And they actually found dolphins and orcas have a language that they speak to each other. So they have a mixed language that they use when they talk to each other, but they actually speak different languages. So they have a second language. So that was really interesting.

Speaker 2:

And that's cool things about AI that are really interesting.

Speaker 1:

Yeah. So Duolingo for dolphins and orcas is Jackie's next passion project. Well, I think with that, we'll wrap it up. Definitely, anybody listening, you know, do the like and subscribe and all that great stuff. Thanks again, Jackie, for coming to the show.

Speaker 1:

It's been great hearing your story. It's been awesome. And everybody, thanks for tuning in and, you know, check us out on our next episode. With that, have a good day and see you later.

Speaker 2:

Thank you.

Speaker 1:

Bye. Alright. Bye.