Durran Open House for Designers - 1 / part 1

So for us, it's the first this kind of setup, so it will be weird most probably and awkward. As you already noticed, we didn't have any music on because I forgot to update the tool that takes care of that. And when I launched it, the Zoom started to pop on some, some different settings, and it was like, it was just weird.

It just sounded like people under the water.

Yeah, it was like a lot of things to do. So for those of you who completed the first form, you most probably got an email, and I kind of explained how things will happen. What I was mentioning that I thought that there would be like 5 people, so everybody will have time to ask questions. We are not a lot more than 5, but we are a bit more than 5. So we will go round by round if it's okay for you. you will have the place to ask the question. We have some slides with the questions, but we didn't put the name on it. So if you don't want to ask a question, just let me know. But if you are comfortable to ask the question that you sent over, then just please raise your hand. I will give you the spot to ask the question, and then we will talk around the stuff that you asked, and hopefully we'll give you at least a Somewhat decent answer, but you never know. It might be just bullshit. For those of us who don't necessarily know anything about about me or Maria, I'm I'm Daniel. I'm a product designer for like fifteen years. For the last almost four, I started the I would say a boutique design studio, boutique product design studio. We mostly worked with with tech companies or only with tech companies, helping them to redesign products. Kind of that's what we do. And we kind of use a process in which we combine product discovery and UX. I saw that some of the questions were around the topic. So yeah, kind of that's what we do. I'm also quite active around accelerators. So I mentored a bunch of founders in the last 3 years around Romania and then some accelerators in Europe. And now I will leave it to Maria to say a couple of words about her.

Okay, so I'm Maria. I don't have 15 years of experience, so I'm more of a junior designer, so to say. I started my career in a startup, which I learned by myself, but you know how you are in a startup doing everything that you can regarding everything. So yeah, and then I Started working at Duran this spring, so more recent in this area.

Yeah, but she's doing fine. So, kudos, Maria. Okay, and then we— I assume we can just start and see how it goes. The first on my list is Irina. So, Irina, if you want to ask the question that you sent over, that's fine. If you don't want to do it, that's also okay.

Yes, I will ask it.

Cool. That's even better.

Yeah, so, uh, in March I enrolled in a product design bootcamp at CareerFoundry, and, uh, I have a question for you. So, um, would you consider hiring a bootcamp graduate for a junior product designer role? And if yes, what skills would you like them to have?

I hired Maria for a junior product design role. You were not part of any boot camps, right?

Oh no, no, no, only my startup experience.

I don't have a problem with the boot camps in general. I have a problem with the fact that they overpromise and are usually underdeliver. And There are some bootcamps that try to work around this in a way. So they put you with some, like, come put some mentoring sessions in it with like other designers. So they give you feedback. But there is, I would say that there is a different dynamic when you work on a real project versus when you work on a bootcamp project. Like in bootcamp projects, and I kind of found the same thing once designers started to apply when I was looking for junior designers, like everybody sent over the same process of empathize, define, whatever, whatever.

I saw that in portfolios, like they are kind of all the same.

They are the same. And this is where usually it becomes quite obvious that those people either didn't really do those parts of the project, because usually it's not something, you know, that streamlined or that step-by-step process. It's a lot of back and forth. We try to somehow put it in buckets and it works okay for some projects and might not work for other ones, but we don't use the define, empathize, define, whatever words. We use slightly different terminology there. So I don't have a problem with working with people from bootcamps. I also mentored people in bootcamps some years ago. But yeah, it's slightly different when you start to find out how things are working in real projects. And this is why usually people, when people ask these kind of questions, I just tell them to look out for a couple of startups or whatever you can to actually start doing those stuff that you learn about in those boot camps and see how it goes and where you can or have to cut corners and why. So you can in a way understand the difference between the theoretical part and the actionable, actually doing the job part.

Okay, okay. So you have this recommendation for me to start looking for some real projects and apply what I've learned at CareerFoundry.

Exactly. And just see how it goes, you know, it's like, because you will, like, at least the empathize part is like really challenging to actually deliver on. Like how you empathize. It's not like something you just— it's not something you usually can do it behind the desk. And this is why I have a problem with people that just put empathize there. And we've done this kind of research, and that's not nothing like empathize. It's nothing to do with empathize there.

Okay, thank you.

But maybe, Maria, if you have any other inputs, any other ideas on this.

Not necessarily. I feel like it's definitely a good start, you know, because you do get to learn from other people as well, compared to maybe simply learning by yourself and learning how to do those things. But it's exactly how Daniel said, that it's the work, like it's the hands-on experience that counts in the end.

Yeah.

So yeah, in a way, the next step, kind of, that's kind of the next step, you know, find some place, then If there is another designer who can help and just give you feedback, it's even better. But at least find a place where you can test those stuff that you learn about.

Okay.

Because then you'll figure out what's working, what's not working. But if you can find somebody who gives you feedback, that's usually a big boost on the next steps. Because otherwise You don't, like, you can figure out on your own, but it might take more time. And there are places like ADP List or something that, from what I know, they do even free mentoring. Yes, yes, thank you. Okay, I guess we kind of answered, like, skills and characteristics. This was also part of your questions, right? What are the key skills and characteristics when looking in a candidate for a junior role? It was still from you.

Oh yes, it was basically the same question. Oh, about this, somehow you asked—

I'm usually looking for more on the personal motivation, like personal characteristics, and less on the skills.

Okay.

Like skills-wise, I usually expect to have some knowledge in Figma or a design tool, obviously. But we had this issue when I was looking for a different role, like a more mid to senior designer, and we were actually discussing about this with Maria, that a lot of people say that they are learning stuff, but they actually don't learn anything. So I'm looking usually on the junior side, I'm looking for, in a way, that trait that they are eager to learn and open to feedback. Not just for juniors, but especially for juniors. And there are courses, books, and stuff that you can find quite easily nowadays, so it's not a big problem. It's more about if you really want to do the job or not, I would say.

Okay, thank you.

Cool, no worries. Do you have any follow-up questions or anything else?

How can I find these startups?

Accelerators, incubators, they are usually a good place because there are actually not a lot of designers in these startups. Most of the startups, at least in Romania, they are engineer or developer driven. there might be a bit challenging to convince them that they need design in some cases, but otherwise, yeah, accelerators, incubators might be a good idea to look around. Maria, how did you find the guys that you worked with? Oh, she actually worked in a startup.

Yeah, we were colleagues from university, so we launched it together. But yeah, that's a good answer. There are a lot of startups like, I don't know, Innovation Labs, for example, or Innovators for Children was another one, Fix Those are just some of the ones that come into mind, and there are like a lot of teams in the beginning there.

So, okay, there is also depending on the city you live in. If you live in Bucharest, there is a bunch of them.

I live in Cluj.

Just message me and then maybe I, I can look for you.

Yeah, I, I would like, I would like that.

Okay, Innovation Labs, it's in a Some major—

Well, Innovation Labs, it's regional and then it extends on the national level. But yeah, we have Innovation Labs in Cluj as well, so you're good.

Awesome, cool. Then follow up with Maria and she can get you all the other details regarding incubators and stuff.

And thank you, Maria.

Yeah, thehub.se in Scandinavia. Awesome. Thanks, Mihai.

Cool.

The next one then is Slobodan from— hopefully I don't butcher your name. Sorry.

No, you didn't. It's just fine. I mean, we kind of have a similar language. Yeah, a bit similar. But it's the pronunciation. It's just fine. I didn't have any questions regarding this. kind of things, but I was more interested in your process that you made for evaluation of startups when you were starting a new job for someone that already had a project. You mentioned something on LinkedIn regarding that, and there was just a few slides floating around and switching quickly. And if there's a chance, uh, you could share more about it.

And, uh, when defining MVPs or something like that? Uh, not only when defining an MVP, that's interesting too, but, uh, more of an existing product that needs, uh, redesign or, uh, yeah, Yeah, yeah, yeah, you know, so most of the projects that, like those kind of projects, we kind of split them in 3 big chunks or 3 big milestones. And the first one is, I usually call it context. The second one is solutions and testing. Third one is design. The context is, as it's where you can suppose, it's basically figuring out stuff around the product. Like that can be challenges, that can be stakeholder stuff. And there we do a bunch of things. So if the product is already on the market, then usually you have access to 2 very important things: customers, or at least users if not customers, and some data. Now, this data part is really tied to if it's set up correctly or not and who set it up and how much they trust the data.

Yeah, you have some data, some data almost.

Even if you don't have data, but there are still, there are already some people that tried out the product. What we try to do in these situations is we actually try to interview those people and we at least create 2 different groups, people that are still using the product and people that use the product and churn. It's easier to talk with the first one, obviously, because they are still interested in a way in the product. It's a bit more challenging to talk with those that churn, but in some cases you can incentivize them with some Amazon gift cards. We've done this for some products, started usually around $25 or something, but it depends on the niche. If it's something more specific like for doctors or whatever, then the gift card should be higher definitely because it's more challenging to find those people. For the interview part, in a way, the frame that we use is tied to the jobs to be done interview sequence. So basically we try to understand why they chose this product, what other products they looked at, what was the problem they wanted to solve, what was the trigger when they started to look out for products, and if they're still using it, how they are using it, and how they find a product. And if they are not using it, why they didn't use the product. It's like very high-level stuff. This is the first part, and from this you already have some assumptions regarding the challenges that are in the product. So you can kind of start drafting out the customer journey map or something similar with some feedback from the customers. The second part, it's 2 workshops that we do with the key stakeholders, usually founders because we work with pre-seed, seed stage startups quite a lot. But there might be, I don't know, product managers or CPO or stuff like this. So usually people that are in charge of that, either the product, either that area of the product, and they can make decisions. And in those, we map some key information regarding the product and the business itself. So like, what is the product, the definition of like the value prop and stuff like this. We map out the user personas, also the customer journey maps if it's an existing product that you already started drafting probably after the interviews. If it's not an existing product but a new one, then we do user story mapping. We also do Assumption mapping. Well, I probably missed some stuff. Yeah, competitors and like high level kind of, that's it.

Of course, competitors.

And most of the, like, we spent quite some time on mapping out the assumptions actually. And that's something that we started quite recently to do. Before that, I wasn't focused that much on that area, but it gives you a bit of information of like how the stakeholders think about the product and what are the blind spots there. And then you have some assumptions that you can think about how you might test.

Oh yeah.

And if we continue working with them, then we can actually test those things together. But if not, we just like create a list of, look, these are the key assumptions that you had that are not tested. These are some ideas on how you can test them. Some of them are quite easy, some of them are complicated. So we had even in one of the projects, we had something that was not quite testable. It was more like a friction between the stakeholders and it was a big friction between the stakeholders. So I just highlighted the whole area, look, just like sit in a room, you 3, and talk about this shit. Because otherwise it's like, well, I don't know what we can do. Like everybody was on a slight, like there wasn't a big difference, but there was slight difference in some key areas and that's a big problem already. And then you have the user personas that you define. For the user personas, I slightly modified the standard stuff that are templates that are used because I'm not that interested usually in demographics. So I went a bit towards the jobs to be done framework, and I'm more interested in triggers, motivations, fears, frustrations, stuff like this. And the customer journey, that's quite easy. So once you have all this information, then you kind of have mapped out the context and you have a somewhat good understanding of the business, the business case, and the challenges they face. And from that, we go towards a workshop that's similar to— it's quite similar to the design sprint, basically. So we gather the team together, we create the prototypes, then we go and test the prototypes with their customers, we collect the feedback. Now, in the last sessions, we worked with a UX researcher, so we uploaded everything in Dovetail, extracted all the insights, through Dovetail created even video highlights of what the people said and at one point and the heat map of like task and customer so you could see quite easily where were the challenges occurring in the flow. We present all that information back to the founders and then we usually make some decisions about what we will change, what we will change in the design. Like high level kind of this is the process. The design process is quite the standard stuff. We do the design system and— or the UI library, name it as you want, and the screens and the flows that's needed.

Yeah, yeah, thank you. I was asking because I had similar challenges with a couple of projects similar to that. So especially something that customer already had something, and I kind of had a hard time selling them The whole research, the whole user experience process.

Yeah, people usually don't buy research. I don't sell research separately. I don't say like we do research. It's like, oh, this is our process and this is how we are doing it.

Not really like that. I mean, they need to understand it takes some serious chunk of time to not only to do the research, to interview the, the users, or, uh, everything in between. They consider the deliverable exclusively the, the UI. And, uh, I had a challenge to, to, uh, explain that and, uh, how this influenced that and why and how, etc.

Yeah.

So I, I even had a Problem with one, like, yeah, I need users, I need some information, some data. Oh yeah, we have data, here's our Google Analytics.

Yeah, in some cases it works.

Let's go to UI.

In some cases it works. It really depends on also how big the problem is, how well they understand what's happening. Like for For me, what worked the best is when we were doing this stuff with clients that they already tried the way that you mentioned, like we just need the UI, don't care about the rest of it. So that in that case, it was much easier to explain, look, you tried that version, it didn't really deliver. Let's try this version now and see how it goes. But yeah, it It's not working for everybody. So I don't know, I don't have a magic answer for this. Usually I don't say that we can do it without research. You don't have. It depends on a couple of things, you know, depends on the clients, it depends on you in a way. And even for us, sometimes the question is like, oh, we can say no to the project and like not do anything on it, or we scope it down. In some cases, we scope it down and we do research in a different way. So it also depends on how much you want to impact the product. So there is a couple of things that you have to think about. But yeah, it's not— oh, what worked at one point, and I'm actually thinking about doing this again, and with some clients, especially when I was doing this in the beginning, I actually booked a 1 hour 45 minutes, like, uh, presentation, and it was like a couple of slides. We went through the whole process. I explained why we are doing the stuff as we are doing it and the inspiration that they come and the whole stuff. So it was almost like running a presentation, or as nobody nowadays— everybody calls it a workshop, but it's not a workshop, it's just a presentation.

Yeah, it's just a presentation. Yeah, that might work actually.

I remember that I've done that for my first client in this process, and we've done like a 1-hour presentation with a Q&A at the end, and I explained like the whole process and how the process came to life. So it's not something that I invented overnight. It's like, this is all the inspiration, this is how other people are using it, and this is why we are doing it in this specific way.

Thank you.

You're welcome.

Cool.

Then if you need anything, slides or stuff, just message me and I can send over stuff. So, or we can sync after the call.

Yeah, sure.

Awesome. And who's next?

Let me see. Let me see.

So we have— do we have Vlad? No, I guess it's not Vlad here, right? Then Daniela is the next one. If you want to ask the question, if not, it's not a problem.

Yes, um, do you hear me?

Yeah.

Okay, um, so I joined, um, a little later, and I hope that, um, I will not ask something that was already answered, even though you just answered, uh, what I was about to ask.

Okay.

In parts. And so just to explain why I am asking this, I started working as a junior designer a few months ago at the beginning of the year, and I consider myself a junior, but I am actually the only one, like the only designer And I am in a team with a product manager and 2 developers, like a front end and a back end. And my question is about presenting the designs. And after getting feedback and iterating, presenting the new designs, and how do I present them more confidently, and how do I defend them? When I get feedback normally from the developers, and I get a bit confused because when they tell me that, for example, it's not that easy to implement something, I don't know, should I just try to push and try to convince them or just to agree? Um, and also, uh, when I don't have enough, um, experience, let's say, I try to look for inspiration and for best practices in different places and in the competitors. And normally, uh, when I suggest something, it's based on some competitor or some assumption, uh, and I think this is where my my lack of confidence comes from. And also, the product that we're working on is still non-existent, so there are even more assumptions.

Okay, uh, non-existent in the sense that it's still developing and it will be launched at some point, or—

Yes, yes.

Okay.

We have, um, we have, um, a few, um, people who we are using to test the, the prototypes, uh, but we haven't launched yet.

Okay, and the testing part, it's up to you? So you are testing the prototype, or is somebody else in charge of that?

Um, everybody is in charge of it. Um, We are split in a few groups, and I suggested that we are at least 2 people present when somebody is testing, um, and the others agreed. So we are like 3 groups from 2 people in a team, and we are just observing how the user is Going through the prototype, and then we just ask some questions to clarify what is not clear. So it's really early, but sometimes when we notice that people get confused and we try to iterate that, then everybody starts to suggest different things and we cannot get to a decision how to make the product look or the flow. I don't know if I explained it.

No, that's fine. We can unpack it. It's no problem. You know, there are a couple of things, like usually when developers say that something takes more time, a lot of times it happens that they use some kind of libraries. Most of the developers use at one point some kind of libraries. So it might be a good idea to talk with them before and just see what kind of libraries they are using so you can design on top of that. And then the speed of implementation, it's kind of off the table if you don't make some crazy moves there, but otherwise it's kind of off the table. Regarding the research phase, it's normal to make research on the competitors. I would actually highly suggest to do for most of the stuff, not just for the bigger tasks or something that's not that obvious, because what a lot of designers end up doing, especially in the beginning, is that they almost try to reinvent the wheel in a way. Instead of like just looking out what's already existing and working and tested, they just try to make something that's like I don't know, new or innovative or whatever. And then, yeah, it might be a problem with how that's implemented, if that makes sense for you.

Yes, it does. We had more of that problematic stuff at the beginning. Then we, like, they showed me what libraries they're using and I do have some references.

Mm-hmm.

And also about the other part where, how do I present the iterations? Usually what we do is just go straight to the new designs, but just now that you mentioned about this presentation, that you made with, um, like the, the different, um, not different—

As a process?

Yes, with, um, with the different, um, parts, like where the customers have problems, uh, and where the personas, uh, where the personas, um, are and How these connect. Um, do you think that it's a good idea for me to do something like this, for example, with the old design?

I can tell you how I ended up doing this process because that kind of answered the question. Like, I was doing design kind of the same way as like everybody's doing this. Most of the people were doing design back then. Uh, you look up the internet, you just go to Dribbble, Behance, Google search, and YouTube, and just look at what others are doing and you try to replicate that. Now, usually when you're doing this combined with the fact that there is not necessarily a strategy behind the product and like most of the things are kind of up in the air, then the discussions on the design side end up being something like, I don't like this font, I don't like this color, I think the button should be bigger, like stuff that you can just waste a lot of time on and the impact overall on the product, it's up to mostly nothing most of the case. So because like the whole discussion is very subjective, you just discuss about what I think or what I like, but you don't discuss about what you are building and why you make those decisions. Now in this situation, in a way, you have to go back towards like what you are building and why you are building it that way. So you have to honestly It might not be justified, the right word for this, but you have to explain to the developers or who critique your design how you made the decisions that you made and why you made those specific decisions. And here you come back to the research phase and these kind of stuff that you can anchor in a way your decision in. So do you have a defined user persona or not? Do you have defined guidelines or stuff that you have to know regarding the development phase or not? Do you have a customer flow or user journey or customer journey map or something similar or not? Because if you don't have anything like this, then most of the times the discussions will be just around the fact that I like or I don't like something.

Yes, we do have some of these materials, but they are not very rich, let's say. We don't really know the customers and the users yet, and the idea was to get to know them while we are designing and developing.

And it's really expensive to learn about the customers while you're developing a product. It's cheaper to do it while you're designing a product, uh, and this is also faster.

This is starting to be a problem now after a few months.

What—

how much— I don't know how much you can tell us about this, but what At least what kind of domain is the product in?

It's like a platform for people to register and make a profile and connect with recruiters and HRs. So it's not like a complete Um, CV profile, or like you don't upload your resume or anything, just your interests and whatever kind of background you want. And you can connect with other people in the same industry and some recruiters who are interested in people in this.

So it's kind of like a networking platform?

Yes, something like this.

Okay, and kind of what's the problem that you want to solve with this, or the owner or the founder wants to solve this with this? Because there are a bunch of networking platforms.

Um, yes, but not in our country, not in our language. So we want to have something that is, uh, like in our native language for the people who do not speak English and are not— like, for them it's not necessary to know English. Uh, but we have a problem with how much, um, like, people who are not speaking English are actually using digital networking platforms.

Oh yeah, you are in a similar situation as Romania, most probably. Yeah, yeah, yeah. We had this kind of like— I remember when I was mentoring in, in incubators around here that people wanted to create these kind of products that they in a way digitize something for the non- digital native people. The problem with some of them were exactly like this. Yeah, they weren't on the internet in some cases, so you have to figure that out first. And then in a way it goes back to the fact that, okay, let's assume that those people, that there are a large amount of people that are interested in this, they are not necessarily English speakers, then you have to figure out how you can reach out to them, because if you don't figure out how you can reach out to them, then you can't figure out how to actually onboard them in the product. So it might be a good idea to talk with the founder or owner who's in charge of the product to see if they can connect you with this specific type of people that they target, because otherwise it might end up just building something that nobody will actually use because you don't know Like, who's in charge of this won't know how to target those people and how to find them.

Yes.

Or they might not be a big enough problem. That's the second part. It might be not a big enough problem or a big enough market.

Yeah. Um, I, I think that, um, this is, um, that's why it's hard for me to recognize, am I sometimes like, do I lack confidence sometimes because I really don't know, like, the user, the users, and I cannot back up, like, my suggestions so much with information, but just with some assumptions and observations of the competitors? Or is the lack of confidence coming from the fact that I am new and I Like, I don't have that much.

I would say that the second one is a lack of confidence. The first one is a lack of knowledge. But even for the founder/founding team, it would be quite challenging to give you feedback other than I like or I don't like this if they don't know who will actually use the product.

Yes. I agree.

So it would be better to somehow find a way to talk with the people that will use the product, or they think that they will use the product, and then just work it backwards from there. Because otherwise the discussions will be just around, I like this, or I don't like this, or this product has this feature or this whatever, and ours didn't.

Yes, I, I agree. Thank you.

And for that phase Yeah, you can, you can basically maybe create a small workshop or something with the people in charge and like try to map out whatever they know regarding the users. And even if they are not users, it might be just a target customer profile or something like that because they might not be users yet.

Mm-hmm.

So I would start with that, maybe map out some competitors, like figure out kind of what they are thinking the competitors are. And then if you want to go like ballistics, you can do assumption mapping.

Okay. I haven't— I am not sure if I know what assumption mapping is. I will search for it, but is there some—

Just message me on LinkedIn. I will send over a link about assumption mapping.

Okay, thank you.

You're welcome. Any, any other questions?

Uh, no, no, I think that you gave me pretty good direction.

So if you just want to work on the confidence part, tie it back to research, but it's hard to do the research phase correctly if you don't know who you want to target, what kind of customer, and what kind of problems you want to solve.

Okay.

Thank you.

Thanks. Next one, it's Ana.

Oh, hello.

I'm happy that I'm going after Daniela because I wanted to continue something on the same idea. She mentioned that developers often use component libraries that don't always align with the design. I'm also a developer, and that's my concern as well. Well, in my experience, when our UI/UX team introduces a new, like, fancy component, I'm excited about that because I enjoy building UI components from scratch.

Mm-hmm.

Yeah, not everybody likes it. And maybe there are also some time constraints. I need I think you need to establish that in the beginning. So do you have enough time and resources to build a design system which is 100% original and fancy and whatever? Or can you also use some predefined component libraries? That's a pretty important aspect.

Yeah, there is also one thing just to mention, one more thing regarding this It's not just about building it, but also maintaining it.

Yes, and that's a pretty important one. Yeah, and testing it. Yeah, but one of my questions, I think, were regarding this design system file and when exactly is it created? Because in my current job, I I still do encounter a lot of buttons or fonts or, I don't know, simple things like these components which are not included in the design system file. So after a few months of development, I do have a design file in my project which includes the buttons, the fonts, and—

Mm-hmm.

I don't know, cards and so on, borders, spacings, and things like that. And I do have semantics bounded to them. Like, this is a small button, this is the medium button, and, you know.

Yeah.

I don't really know what should we do when we encounter a button which theoretically it is present in the design system because it has the same name and a link to it, I'm talking about Figma here, but it has a different size and a different color and a different border, let's say. So it is kind of reused, but it's a variation of that component.

Good question. I don't have the best answer. I can tell you, in my opinion, what's the problem, but I'm not necessarily— I'm not an expert on design systems. I think that There are designers that in a way overdo this at early stage when you actually might just end up working on useless stuff. So if the project is something that's big and you need a design system, that's fine. Also, it depends on like some people use design system for different stuff, not just the standard design system, but some call it even the UI kit design system. Sometimes the UI kit is good enough. In the beginning, and you can start with that. Sometimes you need more. Usually these kind of problems occur when there are, in a way, a lack of discussion between developers and designers, because if I, as a designer, I introduce a new component, whatever it's a button or whatever it is, there should be a reason behind why I've done that. It's not just the fact that I didn't like the 4 other ones that I already had in the design system.

Okay, such that the developer will know then, is this component reusable or do I need it?

Exactly. Yeah, yeah, it's just here or we will reuse it from this point on. Why you created another button if we already had X amount of buttons? Does we— do we really need this? Because it's not just the fact that you create a button, it's also you have to maintain that button.

Yeah, and how perfect should this design be the Figma designs that you provide to our— to your clients, for instance, to your developers? I mean, to your colleague developers.

We don't have developers in the team. We work with the development teams either depending on—

yeah.

I'm not a pixel Nazi, so it's really hard to answer this.

Okay, but let's say you have, um, most of your cards and your components has a— they have a border radius, let's say.

Yeah, yeah, yeah.

I think that's an important one.

Yeah, if, if you have a UI kit, basically you define everything in the UI kit and then you reuse it. And it's the same if you have a UI kit slash a design system because you define the elements the components, the styles for buttons, text, colors, whatever you want, and then you basically just reuse them. You might have slightly different radiuses depending on the size of the element the radius is on. So like for a 32-pixel height button, you might have, I don't know, 4 pixels, but for a 56-pixel height button, you might have 6 or 8. just to proportionally to be the same. But even here, you can— it's a discussion if like, does this really add value at our stage or not?

Mm-hmm.

Because as anything, even it's the same thing I would say for design and development, you kind of have to have a reason and some border, some guidelines. What's important for us? Do we need like a pixel-perfect design or we need to ship fast? Do we need something that's like reusable, scalable in development, or we need to, I know, push this out of the doors however we can as fast as possible? So those guidelines in a way will help in defining this stuff because you can't have pixel-perfect design and everything standardized if you don't have time to do it. But I assume it's kind of the same for developers as well. You can't have perfect code and like tested everything if you don't have time to do it. Or budget or whatever.

I think the communication is the cause for this little friction between the UI/UX team and the development team.

Usually it's the communication.

I don't know why, because yeah. I have another question if I may.

Yeah, sure.

It is about the context discovery phase that you mentioned earlier, the one where you reach out to both current and former clients. Or users of your, um, how do you do that? How do you find them? How do you reach out to them?

Um, through email, because if they are already users, you kind of have the email address, so we can reuse that. Sometimes in, in other products, we put up, uh, modals in the product, so they were triggered at specific events. That's another option to do it. If you don't have either of these, then what you can do is ask around. I saw some people, we don't really do that. And in some cases we've done, what was it, usertesting.com, where you can define what kind of people you want to interview and you interview those people. But it goes back to what you actually want to learn. Because if you want to have info on how they used your product, then you definitely need your customers or your users or Userlytics.

Yeah.

Good one.

Oh, okay, I didn't know about that one.

So what we most of the times what we do is when we work with founders is they especially early on they have access to customers and we talk through the founders with the customers. In other cases, we email them.

Okay, I was more curious about, I don't know, those startups where you have like business to business to client, and how do you reach to their clients? But I assume—

I assume it's kind of in a way it's similar. It might be slightly like you first business to business to client, the business resells or somebody from the business uses the product?

Resells, let's say.

Oh, okay. If they resell, then yeah, it might be a bit trickier.

Resell, or I don't know, maybe, let's say, for an HR application.

Yeah.

It's a very common one. Let's say you have a client which is building an HR application, and then they have like 100 users. I mean, that one is a simple case because you have the info, they have accounts.

Yeah, we usually use these 2 approaches most of the times. Emails, actually emailing them, or the founder emailing them, or the other one is pop-ups in the app.

Okay, that's—

And for that we used, I forgot the name of that one, but I can look it up. We use the tool for those models, get site response, so get site Something.

Okay, thank you.

No worries. Any other questions if you have? No, nothing else. Get Site Control is the tool.

Okay, I'll search it. Thank you.

Okay, awesome. Then we don't have Isaac. The next one, it's Corina.

Hi. So I wanted to ask you, what are the biggest challenges you faced in your design career and how did you overcome them?

I will leave it to Maria first because her list might be shorter.

I feel like we sort of already covered this topic right now. It's like, as a beginner, you kind of feel weird about your confidence and maybe also how you handle feedback and how you get to detach yourself from what you're doing and don't take the feedback personally that you did something wrong. And that's exactly what Daniel said, how to fix that is just do your research and think about your user, not about like something that you want to build necessarily and how you want it to look, but how it's meant for the user and how it will affect them. So I feel like maybe that was one of the biggest I don't know, challenge that I had initially was just thinking, oh, maybe it's not good enough. Maybe, um, yeah, but that's— I was like, they're the same steps that everybody follows. So I feel like it just comes in time as well, that you fake it till you make it. Yeah, so that's for me at least.

Yeah. Oh, I don't know, there was a bunch of them. It really depends on like just as a designer, because that's slightly different.

As a designer, as, um, I don't know, talking with the clients, um, from the product side.

Like when, when I started, it was like 15 years ago, we were using Photoshop. So that was by default one of the challenges. You had no components, uh, you have something they called, I don't know, some mask or whatever. I even forgot the name. And basically every time it just freezes, so you can't use anything from there. And even like just talking with, like, putting that in a way in the hands of a developer was a complete different story than now with Figma or Zeplin or I don't know, whatever tool you use, because we just sent over a PSD and they have to open the PSD and they have to like look into it. It was like a whole chaos. So to, in a way, to manage the chaos, we created documents and documentation. So I wrote a lot of shit on documentation, a lot. Like, this is a button and the states of the button are the following, and the size of the button is this, and if you click on it, it looks like this, and if you hover on it, it looks like this. So you had to kind of explain everything, and we were thinking that we were working Scrum, we were working waterfall by the book. But we were calling it Scrum or Agile, I guess. We figured this out when we started to go to an Agile course or workshop or what was that, and it was nothing like we were working. So processes was one of the problems, I would say, and one of the challenges. It's also like a lot— I would say that nowadays is a lot of information and a lot of buzz, and it's really hard to make sense of some of the things and really hard to make a call on like what you want to follow or trust versus what don't follow or don't trust. So in a way, the information overload, it might be a problem. It's still for me, but it's a slightly— in a slightly different area. But yeah, that's one of them. Articulating the design decisions that Also, it was also part of the, the, the whole process of, I know, growing as a designer back then. And I was doing also shit work, so also figuring out how to improve as a designer was a different story.

So how do you articulate your design decision? Do you back up with research? Yeah, that you have.

So this is why I actually ended up changing the whole process of how how I work on a product and I went more towards the product than just the UI part of the product because then when we have the discussions with our clients, it's usually around the fact that, look, these are the customers, these are your competitors, this is the flow, okay? We tested this thing with your customers, the customers said this, so based on this, we've made these changes. But it's not—

do you prioritize user needs over business goals, or how do you—

That's a very tough one.

Um, I usually present with your customer.

No, I never push solutions. I, I presented my version of it, but I'm, I'm on the mindset that it's not like— it's not my business, so it's not my— in the end, it's not my call.

So you're kind of in a consultation.

Yeah, exactly. So this is the best I can do. This is what I think you should do. If you think otherwise, it's up to you. So it's not like, do this, do this, because if you don't know this, you're stupid or whatever. No, like, you do whatever you want. It's your business. But in my opinion, based on my experience and what we've done together, this is the way to go. But also this has to be very articulated because you can't do this like, oh, I've done this UI stuff and it has this shiny button and like, I think you should implement this shiny button because people will like this because it's shiny. That's nothing, like no articulation. And unfortunately, I saw designers doing a lot of those stuff. Oh, I created this very beautiful UI and it has X amount of likes on whatever, Dribbble or Behance. And let's do this because it's nice. Nice is not a business value.

What advice would you have for a designer that is asked to do only the UI and not—

I don't—

He wants to do the part of the research, but the company doesn't want so.

So it's really hard to do UI if somebody doesn't do the research. Even if not the design, there are companies where they split, so they do UX and UI separately, or they have a researcher and the UI designer, or a PM doing the research and the UI designer. But if nobody does the research, then what you end up is like a beauty contest.

Yeah, I know, but how would you convince— what advice would you have for a designer that is asked to do this? He's the only designer and he—

Find a better job. What I can tell you is like, find another job. I don't know, uh, it depends on the company. Some companies are eager to test these things out, but they don't know how to do it. And then in a way, you have the way to like, let's try with something small and I will do some, some research and I presented that way. And the other way is to create exactly what they asked for. And then if you have some spare time, and usually there are spare times, you create your version of it with the research and everything. And when you present it, look, this is what you asked for. And this is what I created because I've done this research.

I think—

can I say something?

Yeah.

Sorry to barge in.

Go ahead.

Go ahead.

I usually said, I was usually selling it by, uh, this, uh, gives me an informed decision on how to do this or how to do that. So information being the key and, uh, what Daniel said, uh, uh, uh, uh, bring— bringing them a decision. Okay. So I'm a master of my craft. And, uh, I'm doing this, I'm doing it this way, and, uh, if you don't want to do it other way, okay, it's your choice, your company.

Yeah, but this comes with the fact that you are the master of your craft, so you have to own your shit. It comes with that, you know, in a way. So this is why what, what some— and it's not just for designers, it's like a lot of People sometimes forget about this. When you recommend something, you have to recommend it in a way based on something. You've done the research, you know why you are doing the recommendation, and then you can articulate the recommendation. So it's not just, I recommend this. If you don't take this, then I don't know, whatever. You have to articulate why the option that you present is better.

And maybe in this case, something that Daniel also said in the beginning, that how he was holding a presentation about everything that we are doing and its purpose, maybe something like that would work initially as well, just to point out the benefits of research and how it impacts a product in general, or also specifically on an example, as Daniel said.

Yeah, you might just do a presentation like, look, this is how usually design processes are working on bigger companies. These are the roles they have. this is how they impact and stuff like this. I wouldn't go full on like, if you invest $1, then $100, that kind of Forrester research stuff, which I don't know, it was probably from the '50s or something, basically. And so I wouldn't go that way, but there is still research that's relevant and you can use it. But this also goes back to the company's style and what they value and the maturity of their UX. And usually— processes in general regarding the product. Because there are comp— and the budget. Yeah, there are companies where you can do this stuff and they are okay to try out new things, and there are companies who say, I don't care, like, just do it the old way, that's fine, it worked. So yeah, thank you.

No worries.

Okay, then we don't have— we don't have— we don't have Bianca. You're the last one in the call with a question. The other ones didn't show up.

Hello.

The problem is that I actually don't remember my questions because I did have them.

Oh, we probably have them somewhere.

I know I do remember part, uh, part from them, something about creativity.

That's something I'm interested in.

I have them here if—

Okay, can you share your screen? And I think I can let you share your screen.

So sorry if you see me here, uh, changing the rooms, but I'm with my daughter and Yeah, oh, no worries, it's fine.

Just a second.

Okay, I can just read them. I don't know something.

Yeah, sure.

Yeah, okay, so the first one was about creating the portfolio and how long it should take, how much time we should spend on that regarding like 3 to 4 projects and the design for working on the website. Of the portfolio.

Yes, yes, because in my situation— why, why, uh, I wanted to put this question— because in my situation, I'm a full-time mom, part-time job, and if I have some free time, most of it's dedicated to my daughter. And if I have time, I work on my portfolio, and this is the challenge now. And I don't have a specific time. I don't know, it takes me a little bit too long, I think. And I don't know what is the normal time in which you should do that.

Maria, do you have a portfolio?

Sorry, she was asking if I have a portfolio. I have a portfolio based on my previous work in the startup, so what we did, but that's Okay. Yeah, and also, but I understand what you feel because you also feel kind of stuck because you're just creating something that may— it's not real like that. Daniel was saying in the beginning, it's not the same work that you do normally. So I feel like everybody faces this kind of issues, and you have to be aware that your process, you don't have to follow all of those steps whilst you're designing project at home because you don't have the resources to do all of the, all of the steps as well. So yeah, maybe just don't be so picky about like every single thing and just do the research and the, the logic behind of it. But maybe it will never be perfect. It will never be perfect.

I understand. The problem is that maybe if you find a job from networking, it's okay, you don't need that much portfolio. But when you try to apply to new jobs, they don't know you and they want to see what your creativity looks like in projects, and it's a big deal there.

Personally, what I did at a certain point, I was so done with the fact that, oh, I keep on postponing my portfolio. I was like, oh no, we have a deadline, so up until next week I have to finish it and I will send a version of it and then send Also, another thing that I did was using Behance as a portfolio. So if I keep updating it, they will see the updated version. So don't just send your work as a PDF, or like you said, you can have a website, but that takes time. So I decided to just scratch that and put the work on Behance where everybody can see it, and if I work on it, they will see the new version. But okay.

Yeah.

I'm big on deadlines, kind of the same. Otherwise, we never got things done.

Okay.

And I'm not necessarily a big fan of Behance, but it's like more a personal taste. You can use— basically, you don't have to build the website. That's the idea. You can use different platforms where you can put up the work, so you don't have to maintain the website as well. And that takes a lot of time to actually create it. And usually the problems are around the projects in itself more than creating the projects, not creating the portfolio in some cases.

Okay.

I would say there are maybe 2 buckets. There are designers that don't have a portfolio, so they have to create— they don't have projects, so they have to create the projects and then just work on that, create, I don't know, 2, 3 projects and put it somewhere, wherever. You can use Behance, Notion, UXfolio, or some other platforms as well. If the second is like you have to create the website itself, then just at the moment don't do it. It's like upload it somewhere and send it over. It's still better than PDF, and then you have time to work on the design. Okay, thank you. Projects you can find kind of the same way as we discussed, accelerators, incubators, NGOs, Friends, colleagues, whatever works.

Yeah.

There were more questions here. Should I go through?

There were 4.

Okay, so the next one was regarding how do you find your inspiration for design concepts? How much of it is research and how much of it is creativity?

I'm not very creative. Most of it is research.

Okay, because why I'm asking this, because you look on Behance, on Dribbble, on awards, You see all kinds of crazy things.

I have a whole discussion about those websites, and I assume they don't work.

Okay.

And regarding components, you can't be so creative if there are some specifications, or I don't know, where's the creativity left here?

I would say that most of the designers try too hard to be creative, and they end up doing something that's worse than if they would just research and create something that's common. But that's more like a personal opinion. It is a personal opinion. I don't defend it. It is a personal opinion. I don't say that there are no—

Junior, you try to impress with your designs.

Yeah, but they usually try too much.

Okay.

So it also depends on the project. So if you have—

yeah, sorry. But honestly, when you're hiring a junior, you're not looking for those kind of skills. At least I wasn't looking for those kind of skills.

Okay.

I like how I— sorry, I just one more thing and then I'll give you the space, the floor, whatever you want. When I was looking through the portfolios, even for mid-designers, it was like I just like scrolled through the whole thing like really fast. I don't read almost anything. I just scroll through the whole thing, see if they can deliver Besides the blah blah that's in between. And if the work is shit, I don't read anything, honestly. I'm not interested in the process of shitty work.

Um, I've heard different opinions. As you said, other people said that with experience said that I'm actually looking into creativity because the UX process, everyone can do it without—

yeah, that's not true—

doing anything. And information is everything. So I want to see your creativity in a project. So that's why it's a little bit confusing.

There is, like, if you look through most of the, I don't know, apps, web pages, whatever, you might see that they kind of look very similar because the web itself, it's kind of quite standardized in a way. So I don't say there is no space for creativity, but it's not like creativity is not just the UI part.

Yeah, okay.

And I'm more interested in how somebody can solve a challenge or how they think about it or the research they've done and they can replicate it. It wasn't just one spark that they created for something they loved and they never can do it again for something else.

Okay, thank you.

And now, Maria, it's your place.

I will also add something and then go to the next question. So I feel like it also depends on the project. Like, if you have a really serious project and you have to— you have a lot of information there, and the purpose is for that information to get to the user, it's not to have a lot of animations and to be so pow pow.

I don't know.

For example, uh, actually today I was looking on the website of other, um, design agencies, and they were, they were amazing. Like, they were so creative and they looked very good, but I was trying to look for specific information and it was so difficult to find it. And the purpose of that, their website, is for me to get that information. But because of all of the extra stuff, it was somehow difficult to actually get to that point. So I feel like you did— you just need a balance in between everything. And in terms of like sparking creativity, I feel like it just helps even that you said that you're looking through other projects and you get inspired by the things around you. So just keep being curious. I feel like that can help and it can spark up different things. Yeah, so that was my, uh, answer for that question.

And for example, customers who do not know anything about UX, they are easily impressed by UI and very fancy stuff, but they do not understand, um, the process behind. And this is why I also think that it's important, the creativity, but it's messy in my head.

It really depends on what you mean by creativity, because some designers mean by creativity actually getting up to the craft of the current UI designs, and that's doable. It's just you have to consume a lot of content. Okay, in a way that's like training your eye, so you kind of stay on Dribbble, Behance, and a lot of pages to see what other designers put out, and you also check out actual products to see how, how those things are implemented in, in real products.

When you say to— what is the expression with the eye?

Sorry.

To train your eye.

Train your eye. You mean the structure or the components or everything?

Structures, components, colors, shapes, the hierarchy of different elements, everything. Okay, this is why, like, back then— I don't know if, like, I didn't really follow now a lot of those content, but I remember back then there were designers doing like the daily UI challenge, and they basically were rebuilding existing stuff just to train yourself on how to think about those elements and how you put them on a page.

Maybe that's for your algorithm on Instagram, and when you scroll, you're just going to find some Figma tips, some recreation.

Follow a lot of designers and then you have jobs.

I was trying to figure it out a little bit from you.

Thank you.

Um, the other things were, um, I don't know if, um, what's your opinion using AI in design and people's fear of losing their job in this domain?

I don't have an opinion on AI. I don't know, it's very fuzzy.

One, one thing that I read at a certain point and I found that that was a good thing was that if you're truly thinking about UX and about designing, you're trying, you're talking about empathy and about understanding other people and how they feel and interact with your product. I feel like maybe we're still, there's still some way to go until AI would reach that point. If you actually go to the point of fully doing the UX, UI, not only the interfaces and guidelines.

Yeah, one thing that I would add on top is like, I don't think the interface of chat, the way to go for AI because you just— the friction itself is too much. You have to know what you want to ask, you have to know how to ask it. The outcome, it's like almost like a lottery a lot of times. So it's like, it's just a lot of unknown in the process. So I don't think that the way— and this is, I was actually talking with a friend who's a founder, and he mentioned that in his opinion, actually, there's a lot of need for UX designers in the future because the AI tools now that we have today, they are not UX-friendly in a way. Because chat in itself, it's not the interface.

It's the—

in some way, it's a lazy interface. It's just posting it.

Okay.

Like, I don't know if how many of you remember MS-DOS. I've It's basically for me, it's like MS-DOS again. Like we went from MS-DOS where we were like writing prompts if you want to get out something to having an interface where you click on stuff. And now we go back to the place where we have to write down something in a very specific way to get an output. So this is why I don't think that AI, it's the interface that we have now for AI. I don't think it's the way to go, but you can see it like there are products that started to incorporate AI in the product. So it's not just prompts anymore. And I guess that's an interesting way to think about it, like how you incorporate something in the product in a way that users can— like almost any kind of user can interact with it and extract the value.

Okay.

I also see this period a lot of courses with design and AI.

Yeah, because it's buzzy. Everybody wants to buy it. There is like a huge buzz on this, so Okay, yeah, there is AI-generated website pages.

It's a lot of fear also because everyone promotes that AI will take all the jobs, and as junior you think about it, you know, maybe not.

It speeds up stuff for sure. Okay, it definitely speeds up stuff. Uh, on the design side, I didn't really try out a lot of products honestly on the AI side. I, I tried out basically Miro's stuff and Notion stuff, but they are not necessarily design related. I once tried to work around the UIizard or Wizard or whatever the name is. I didn't find it that interesting, so I just dropped it. And also there was a Romanian product that was doing almost the same thing from what I know some years ago. So it's not that a new thing. But yeah, kind of that's it on the AI side. I don't know if anybody has a better answer for this. You're more than welcome to just unmute.

Anybody? Oh, okay.

No.

Okay, cool.

And the last question from Bianca here was, what are some common mistakes you noticed junior designers make?

I would say that they try to overdo it and they don't know how to explain why they make decisions.

Okay.

And that's quite common. So they, you know, it's like you want to like show everything you can do, so you throw everything on the page and it just doesn't make sense anymore. It's like just a lot of noise. And this is very common for like, they add shadows and borders and nothing really makes sense and everything, it's almost like pops and screams at you. And then you kind of— it's obvious that there is not a hierarchy in between. So they try to compensate in UI in a way, stuff that they don't— they lack in knowledge as hierarchy and layout. And most of them focus too much on the UI side, on like UI side means pixels instead of like the the concepts in itself, because that's easier to— it's easier to copy something that you see on Dribbble than to understand the concept behind it. And this is why training the eye is actually about the concepts, not just the visual part. It's like how the page looks, why it has this specific way of the layout, why we have buttons in these specific areas, because most of those decisions are made consciously or unconsciously based on some stuff, on some information or some rules or things that you consume maybe for years and you might not even be aware of. So yeah, overdoing, that's one of them. Overdoing and not knowing how to explain their decisions. I would say those are— These are the Design related. There are a couple of ones that are person related, or some don't know how to take feedback, they are not open to learn, and some of them are looking for shortcuts, but there are no shortcuts. Okay, cool. Yes, we answered all of the questions for the people that were in the call.

No, actually, Georgiana, I think she's here.

Georgiana, sorry, Georgiana.

Okay, no worries. I enter a bit late, 10 minutes late, because of job and, um, no problem. I didn't know if you, if you went through my questions already.

No, no, no, no, we went person by person, so no.

Great. Um, honestly, as I was listening to everything, it I kind of have another question that, uh, I think it's more important for me.

Sure, you can change it, it's no problem.

So, um, when someone asked about the challenges that you went through as a designer, uh, you pinpointed that, uh, improving as a designer is a different discussion, and this is what This is exactly what I kind of wanted to ask.

Yeah, because— yeah, just ask the question and I will answer. Sorry.

I kind of have a— I don't know what to tell you about my background story, just to have, um, an idea. Um, I work at the startup, a trading startup, and I have 1 year experience, and I would call myself a visual designer, so I'm not really, um, not saying interested, but I'm not in the UX part yet. So I'm still learning about the visual. And, uh, as I go through my career and I also improve a bit on my visual skills, I'm also interested in improving my UX skills as well. And I'm not quite sure how to do it, honestly, because, um, in parallel I also started working on my portfolio, but it's also about the branding and the visual stuff. And I think for the future me, I'm kind of missing a lot of things, so I'm not sure how to integrate more exactly the UX part into my design process and make myself more usable in that part, let's say it. I think that would be my question, though it didn't sound like a question.

Yeah, no worries. So basically the question is how you integrate or learn on the UX side to compensate the UI part— or not compensate, but improve on the UI side.

Yes, because I'm mostly on the visual part. Okay.

Well, there are like, when I started, I actually started with some up— what was the— oh, come on, I forgot. There were some courses and it's not Coursera, it's the other one. I forgot the name of it with the green logo. Udemy. Yeah, Udemy. It's Udemy. Thank you. I think it was green some years ago. It might not be, but whatever. So yeah, so there was a bunch of courses on Udemy. I bought some of them and also read some books. The books were Rocket Surgery Made Easy and Don't Make Me Think. They are written by the same guy. And I started with those 2. And that kind of lays the foundation of how you think about the UX and what UXs and these kind of more, in a way, the more philosophical part. They are kind of old books, but the rules or the stuff that's inside them didn't change that much. I would say it's kind of the same thing that you have inside. And then the rest of it, it's like actually doing the work. And given that you are in a startup, it's a good place to learn and try out this stuff. When I started, it was a similar setup. I worked in a company that had different products, and I was a designer on one of the products, so I had time to actually try out these things. Because what a lot of people do is like they learn, learn, learn, learn, and they never actually do the stuff that they learn about, so it's kind of useless. The best thing that we can do is like read. Eventually you can read these books and maybe go through basic— even on Coursera there is the Google UX design, whatever, right?

And that's actually free. If you can Live. Normally it's paid, but you can apply for— yeah, for example, I just said, hey, I'm in a startup, I want to learn more. I was like, okay, you can get it for free. And you have to apply module by module, and they present very nicely a lot of the topics. So that's great.

I started with it when I— it's difficult Situation for me. It's a long story, but, uh, one year ago I started with it and I, I didn't feel like it told me anything. This is why I'm, I'm not sure, uh, if it's right for me right now, the course, but maybe it will speak differently to me now.

I mean, I feel like they present a lot of concepts more. Some, maybe you use some of them, maybe you don't use all of them, but they give an overview. Another thing that I did as I was trying to learn more was just looking online on a lot of the forums about this or on the Interaction Design Foundation website just to— they have everything so nicely put out in videos and in writing as well. And they cover a lot of things and a lot of them are for free. So we don't necessarily go for the courses, just allocate time to do that. And I feel like in time you get to know more on the UX part as well.

Thank you.

But applying those things in, in work, that, that will help a lot if you can actually like learn something, apply, learn, and apply. Because then you can poke around, you know, what's working, what's not working, how you can solve some of the challenges that might occur. Because like we even talked here, oh, you just define the user persona, right? It's easy to define it when people know about it, but when they don't know anything about it, then it's a different story. Or you have to create a customer journey map, same story, you know. It's easy to do it when you have somebody to talk about this kind of stuff, and a different story when nobody actually knows how to define it.

Exactly, this is what I was thinking, because, well, I can do it on my own and things like that, but I'm not quite sure if it's okay because I have no one to give me feedback on that. So I have no one to also discuss on that. But yeah, I was thinking of also looking for a mentor on the ADP list, I think.

Yeah, that might be a good idea, but also you have to involve somebody who's in charge the company, because user persona, customer journey map, these kind of stuff usually in their head. You just have to extract the data, put it some in, in a way systematized in one place.

Yep.

So up to a point you can get feedback if the theoretical part, it's okay, but if it's actually actionable in the company, that's something that you will get feedback from the people that you work with in the company.

Thank you. I also have another question that I kind of ask every senior designer, but I'm also wondering how a designer can bring value to a company.

How? In which sense?

I don't know, to be important to the company, to be seen, feel seen, things like that. I'm not sure if it makes sense.

Well, it makes sense. Depends— the value in itself depends on the company, in a way, in the company setup. But I would argue that it's quite complicated to create a product when there is nobody in charge of actually doing the UX in a way or the other. And it might be a UX person, it might be a PM, but you can't just throw something over to the developers and hope it will end up in a good way on the other side.

Okay, great. Thank you.

Yeah, you're welcome. Uh, it depends, like, the value in itself, I, I don't know. For me, it's really hard to articulate. I, I know what a UX person can bring to the table, but it depends, as I mentioned, from company to company. Because if you have a good UX person, it— some of them it's monetary, but a lot of those things are not necessarily tied to actual value in monetary count, if you want, because you save a lot. You can save a lot of time on the development process because you won't develop shitty stuff and then you rework it and rework it and rework it and rework it. So you have, you have that part, you have the opportunity, obviously, and these two are very tight together. If you're working on something that's not okay, then you are not working on something that's it might be okay. Then you have, these are also tied to product discovery. In my world of view of UX, UX and product are going a lot together and product discovery is very tied to this topic. And then the UX comes close to defining how the product operates, works, and maybe even looks in some cases. And it's really hard to just put all this burden on the engineering side. It doesn't mean that you can't or you shouldn't work with them in defining the product, but these roles are in companies for specific reasons. And with the competition that's out there, it's quite obvious that you need somebody in charge of this side as well, not just the development side.

Making sure that you are building the right version of your application and it actually fulfills its purpose and meets the user's needs.

Oh, you put it so nicely. But yeah, that's exactly what I wanted to say in a lot of other words.

Great, thank you for your answer.

You're welcome. Do you have any, any other questions?

Uh, I for one, no.

Cool.

Any others maybe, say, or I don't know what time it is. Well, 3 minutes over, but we can stay like 5 more minutes if anybody has other questions or anything else that they want to say.

Hi, Daniel.

Hi.

Um, I, I've been listening to you about AI in your job. It seems that you are not using it.

We are using some basic stuff, but nothing very complicated yet.

Which are the use cases you use AI in your process? Like research, wireframing?

Extracting insights from research sometimes. Content, yes. Wireframing, no, because I'm a very big believer in pen and paper stuff yet. And also because in during the workshops, the concept in itself, it's pen and paper and we are doing it separately. So each of the person that are taking part of the workshop, they create their own concepts. So this is why we don't do the, the any kind of AI wireframing stuff. I don't know, do we do anything else with AI, Maria, besides content research? Extracting, mostly extracting stuff from research.

In terms of research, it's very important though to like also not only rely on AI entirely because you don't exactly, you don't know for sure where that information is coming from and if it's the real thing as well. So maybe as Daniel said, to like extract information from the research that we previously did. So don't maybe rely entirely for AI is the source of— for the research. Does it make sense what I just said?

Yeah, yeah. I, I use AI quite often, um, and I, yeah, I, I find very frequently, um, incoherent data or suggestions. Many times it's not data, it's just suggestions, but Um, I think you work with the specific use case, like let's tackle the rotation. Let's— yeah, well, you, you, you don't start— maybe you start, but I know you mostly because you reshape things, you reshape solutions. Um, uh, and that comes with a use case and with a, well, with a persona, with a— eventually with a customer journey, or well, whatever. But, uh, when you start from scratch, have you, have you done, have you done it, uh, do you use it like for trying to have the first idea or the first, uh, understanding?

Okay, so that's scratch, like coming up with ideas? No, no, still not.

All right.

Like even when we are working, like I was working with incubator-level startups some years ago, like 1 or 2 years ago, and even for them we kind of tried to work it backwards. So if they had an idea of a product, we went backwards, you know, who can use this? And in these cases, like ideating on maybe who can use kind of product, it might work. But back then it wasn't widespread, the AI use case, so we didn't use that. But in a way, it's kind of the same process. So you can use it in ideation, but in the end you still make the calls based on your best knowledge, I would say.

Yeah, I have seen some presentations of people who start like native AI native completely AI native. They start by just a problem, understanding the persona, all AI-based. They do the, like, the information architecture, then they do a wireframing. Uh, um, I've seen this development process completely AI-based, excluding backend. And well, I've—

I think I know what you're talking about. Honestly, from what I saw, most of those are like concepts of This would be a nice thing to have, but nobody actually implements it because in the end you go back to basic stuff. You know, it's like a problem needs to be solved. Somebody has a problem. You still have to talk with those people, though there is the synthetic user research stuff that's out there in the AI side. I'm not a big believer on that because I don't know, it's like if that would be the case, like, and that would work, In my opinion, what costs for Airbnb or the other large ones to just internalize the whole thing?

Yeah, I understand.

You know, so I would say it's an interesting playground yet, and definitely there will be improvements there because even like Dovetail and these large user research tools, they are using AI up to a point. So there is definitely a lot of information they will extract and they will train the models that they have, but I don't know how good they are working yet.

Like synthetic users, you have been using them?

No, no, I'm not. I'm very against that. Yeah, I'm very against synthetic users. That's personal.

All right, thank you.

No, no problems. Thanks, thanks for asking. Cool, then I guess that's it for now. We still have some questions, but we will answer them with Maria probably tomorrow for people that didn't show up. And yeah, we will put the recording on YouTube and send it over to each of you. And with the recording of tomorrow's or next day's or whenever, when we'll do that one, we'll do the same.

And also, if any other people that, I mean, didn't sign up with the questions and if They have— if you have any questions, just send them as well and we can record those too.

Yeah, well, thanks. Awesome. Thanks for your time. Thanks for being here. Hopefully you got some interesting answers for your interesting questions. Probably we'll do something similar in a month, I assume. We'll see how it goes. Cool. Thank you. Take care. Bye-bye.

Thanks, guys. Bye.

Welcome. Bye.

Bye.

Bye.

Bye.