Durran Open House for Designers - 1 / part 2

Um, okay, hi! So this is the second part of our, um, ask me anything session. Um, there were some questions from people that weren't able to attend, but we still wanted to answer their questions, so this is what we're doing. Um, in case you didn't see the previous video, I'm Maria and I'm a junior product designer. Um, and Daniel, I will let you present yourself.

And then I'm Daniel, I'm a senior product designer and founder of Turan. I guess we can just jump in and just go through the questions. It's the easiest, right?

Let's go. So the first question is, as a product designer, what skills should I improve and what steps should I take in order to become a growth designer?

Oh, that's a good question. Do you have any ideas on this? I have some, but I'm not a growth designer. I just have some ideas on it.

Actually, when I wrote, uh, read the question first, uh, I actually Googled it myself to look a little bit on to search the topic, so I'm not really informed either.

Uh, like usually growth is very tight to numbers, so definitely some analytics. Yeah, or a way to extract the numbers. It's definitely stuff that you should look into, but it's also about, uh, testing, setting up ways to test different initiatives, and there are various tools for that. So I would kind of poke around those 2, actually, setting up stuff to get the numbers, extracting the numbers that you need, understanding the numbers from there, and then finding ways to run some testing, some assumptions.

It's very dynamic in order to run a lot of experiments and figure out what works best. So jump on that as well, I feel like. No?

Yeah, also there are some resources. I remember that back in the day I was reading some website, Growth Designers or Growth Designer, something like that, and there were a bunch of resources from, uh, from people that were doing growth design back then. Uh, so that would be probably the place to start with this.

Yep.

Okay. We can go to the next one.

Let's go to the next one. Okay, so, uh, how do you see the future of the UX industry and what should we learn in order to adapt to this future?

Well, I guess in the last 15 years I went through a bunch of these trends and stuff, uh, it's quite obvious that AI will impact what we are doing up to a point, but I honestly don't know how besides the stuff that people are testing out now with creating layouts and stuff. So I would— I think that it might be commoditized, some of the stuff that people are doing, which in a way already started with like the whole UI kits and libraries and that whole stuff. So probably the low-end of the design job will be in a way commoditized or automatized up to a point. And then, I don't know, it's just a learning process.

The best way to adapt to it is to be aware of it and try to stay on top of your game and what's happening and be open to the idea that things are going to change. So just have an open mindset regarding learning and continuous development, maybe.

Yeah, I would say that either way, if you are in tech in a way or the other and you want to be up to the top of what you're doing, you kind of have to adapt and learn on the go because there is like— it's not just the design industry that's in a way impacted by, by new stuff, but like in general tech, it's impacted by a lot of stuff. So Yeah, besides AI, like, we can also say that all of those— I remember back in the day we were talking about interactions and micro-interactions and like the whole stuff, and never really happened.

Okay.

It was like you found on some websites and it was nice and interesting, and but kind of that's it. It didn't really catch up, and it was for quite some time and it was the same thing. Oh, this will happen or this will happen. Or skeuomorphism or neomorphism or whatever morphism.

But there's trends.

Yeah, there are a bunch of trends. I guess it's kind of the same, you know, it's not the same with AI, but, you know, everything has a hype cycle and like we are probably on top of the, or on top or around the top of the hype cycle. And when things start to settle down, then we'll see how how we will actually use those tools. Um, but yeah, learn and adapt, it's like ongoing either way. Being around other designers and design communities also helps to just see what people are doing and what they are aware and what they are reading and learning about. But kind of that's it, I would say.

Good.

Nothing else to add?

Um, Not particularly, no.

I would say that it might be worth also looking a bit towards product in general, not just the UX itself. So if you are a UX designer, it might be worth even expanding a bit towards understanding the product and business side. Yeah, and that gives a bit more context and resources to play with. In, in a market because it's like the industry itself is changing in a way. We'll see how, but there's also a lot of people coming through boot camps. Then there's also people that were— that lost their jobs. So it's definitely more designers and more like tech people in general in the market now. So In a way, if you're looking for a new job, you kind of compete with those either way, or with part of those either way. And yeah, having a better understanding of how what you're doing actually impacts the overall of the business and the product might be a good idea. That's slightly off the question. Okay, let's see the next one.

Okay, so let's talk about lead generation strategies and pricing. How did you figure it out?

I wouldn't say we figured it out. It's still, in a way, it's tied to the, the answer from before regarding more people being on the market now. So the competition even in this area is higher. Yeah, uh, but there is a kind of a rough patch for a bunch of services and service businesses nowadays. So most of them, at least the people that I talk to, they kind of in a way have challenges in these areas now, even if before that it was somewhat stable or better. Um, for us, what worked, it was mostly referrals, which is not necessarily— it is not a sustainable way to work. It's not scalable, it's not sustainable. And it also comes with the fact that usually founders— or like, we were working with founders, but usually the clients recommend similar clients. So if you switch business model or offering, it might be a problem. And it happened to us as well, uh, some time ago. Um, that's one. So referrals worked. I'm also part of accelerators, some Some discussions occurred around those as well. But yeah, I don't know, we are trying out different stuff. I would say trying out content, there are discussions around the content and people coming from content. We tried out some cold outreach, which doesn't really brought in a lot of stuff yet, but it's also a numbers game. We went quite on the low end of people that we contacted through that. So yeah, there are different ways to think about and try out, but in the end, it's like I usually think about this stuff as where is your leverage in this discussion and what you can use. And this is why it depends, because there are even in the field of like agencies and service providers, There are agencies and service providers who just work with only one client or one client, one big client and this really small one which covers most of the costs and brings in profit, but it might be a challenge if they leave.

Yeah, and try to find another agent.

Somebody to replace that or one or two other ones to replace that might be a challenge, especially nowadays. So I wouldn't say we figured out lead generation strategy, any kind of lead generation strategy that really, really works. We are trying out different stuff. We have some other ones in planning phase and we will probably roll out some ideas later on. But in the end, everything goes back to, you know, cold outreach, warm outreach, paid.

Yeah.

Kind of, that's it. We don't have a lot of answers.

Regarding the pricing and how you— it's very important to be aware of the services that you are offering and to see what's needed. Maybe that's something that doesn't work in the first place.

So yeah, for us it is still one of the things that I have to work on, and also probably with you we will work on this in a way or the other. Because in the end, when you start working with a new client, it's like a trust transfer in a way or the other, especially if it's a cold one. The trust transfer, it's harder, it's more challenging. So when you have a high payment upfront, that might be a turnoff.

Yeah.

And this is like, we still have, or yeah, we still have a high payment upfront. And that's one of the things that we have to work on, either split it in a way, either find a different way to price it. And it's also regarding the context, like I was discussing with people that like they almost went 50% off on their usual pricing today just to like bring in stuff.

Yeah.

So it's also regarding the market, also what you offer, what people are looking for. It depends. I wouldn't say that there is like— I definitely don't have clear answers for this, and I don't think if that is— there is something that it works for everybody.

Yeah, clearly.

I'm though a big— I'm a big opponent of value-based pricing, but it's a very different discussion, I would say. For some reason, I'm not a big fan of that. I don't see it. And I know that in the design industry, there was a lot of discussion on value-based pricing.

Okay.

And everybody was, oh, we do value-based pricing. And when they explained it, it was nothing like value-based pricing. It was nothing to do with value-based pricing. And it's also really hard to actually make it work if you are not a well-known service provider or something like that. So you have to have leads in that you are okay to lose if you want to play that game. Kind of, this is how I think about it. I don't know, nothing very specific.

Let's go to the next one.

The next one.

The next one. Okay, so we have a lot of questions.

Oh, we have 4.

Yeah, we have 4. So first things first, how do you hold a discovery session remote?

And then we can maybe—

the other ones are also kind of Uh, tied to this because it's about the process. Are you preparing the client previously? And if so, what are you showing them? What's— what are the steps that you are following? And what's the resulting document of discovery?

Okay, okay. So when we are doing remote discovery sessions, uh, like tool-wise, we kind of use any kind of tool that gives you access to share screen. So in our case, we most of the time we use Google Meet. We use Miro. Miro. Yeah, it's Miro.

Miro.

And kind of this is what we mostly use in that setup because like everything that happens during the workshop is stored in Miro. We work there with the clients. It's also the link that we share with them.

So Sorry, do you have to have this session remote? Do you find it easier to have it online?

There are pros and cons. Like, uh, if you are working in location, sometimes clients prefer to do it there, and it's— it might be more engaging in some cases. But on the, on the other side, you don't have all the artifacts. In Miro, you have all the artifacts. You basically work on the boards and you have the boards.

Yeah.

So what we are doing in a way, slightly touching on the 4th question, is one of the documents that we send over is actually the Miro board itself. We export it as PDF, we give them as a backup. That's just like one of the documents that we send over, but everything happens in Miro. We share the screen and there we invite the people that should be in that specific session. And regarding the preparation, we don't really do preparations that much. Kind of explain on the call what will happen, like on a call before, what will happen and all the tools that they will use. It's basically explained in a document. Nobody read that so far from what I know. So it's one of the things that we will have to work on. But Yeah, and in some cases I actually did like a presentation of like, this is what we will do, this is how our discovery session happens, and these are the steps, and these are the people that should be in this, and this is kind of the output. So that happens as well.

What part of the team do you usually find it necessary to be in the call?

It's very tight to the challenge that we want to solve. So in the beginning, right, I guess we kind of go through the 4 questions answering like randomly stuff.

Yeah.

That's fine. So we have a— well, our process has— I usually call them 3 milestones. The first one is about the context, and when we are talking about the context and basically business context, product context, we usually do those sessions with people that are in charge of either the company, either that specific section. It might be founders, it might be managers. And if that's the case, we also try to limit to 2 or 3 people max, because otherwise it can be like a very long discussion and it doesn't really lead anywhere. This is the first part. When we are switching from this to the second second milestone, which is about creating solutions and testing with customers, that's where we invite a larger team up to usually 7, 8 people. And then we select those people based on the area that we target and who can add value. But usually we have one, at least one developer or engineer besides the founders. So So besides the founders, we usually have one developer or engineer, somebody who's in touch with the customer if the founders are not in touch with the customers. It can be marketing, it can be a designer as well, and it depends on the team setup. But usually kind of these are the people that we had on the calls.

Mm-hmm.

And yeah, we work together basically to define, do a bit of our research. Like first we align them, then we do a bit of our research, then we create some concepts. And after that, we kind of take it over to create a prototype and test the whole thing with 5 customers. So in this stage, we follow a somewhat design sprint methodology. Yeah, this was regarding the people. Yeah, and process. And yeah, and the third milestone is actually the design. So once we have Once we have the prototype and the prototype is tested, that's where, where the UX researcher also comes in and helps us with extracting insights and stuff. Then we have a call with the founders and we make some decisions about next steps, how much we will impact the prototype, in which way, and what we should focus on for, for the design phase. But we tie this back to the prototype that we tested and the insights extracted from the testing phase. And yeah, the 3rd milestone is basically design where we create a design system or a UI kit, depends on the project, and then we design what's needed and prepare it for handover for our developers. Yeah, kind of that's it. Regarding the documents, there are a couple of them. So all of the workshops are Exported. That means that they are basically in a PDF format, and also the clients get the Miro board backups as well. We have also a summary document, which is also a PDF.

Do you find it useful to also record the meeting in order to look backward on it, or do you find it that's enough to have the Miro board?

Some customers ask for it, to have all the recordings because they want to share it with their team, but some didn't. So how we are doing it is usually if they don't ask for it, we don't record it. If they ask for it, we record it and send it over. Because if you have the Miro boards and if you have the summary document, you kind of have the knowledge there. And we sometimes record that call actually. the handover of the summary document call. That's usually recorded. But otherwise, like, you have a bunch of videos which are like 2 to 3 hours long. Most people won't watch it.

Yeah, they won't watch it back.

So it's just stored there. We still have a bunch of these on Google Drive, but I don't think they will actually watch it ever, ever. And also, what we give, like, lately what we started to do is We extract video insights from the testing phase, and that's actually something that they sometimes, they watch it, they go through it, and helps to contextualize in a way the insights that we extract from the testing part. And yeah, obviously the Figma document also goes to them. So basically the design files, they get that as well. Kind of, that's I guess we kind of covered everything.

Simple. Yeah, very simple process.

Yeah, there is a separate video for the process and stuff. We didn't really talk about the documents, but like the process, it's explained a bit better on that video, I would say. Okay, let's see what's next.

Next. So I feel like this is Also, so what's your process in working with clients? Onboarding, communication, design exploration, feedback. So they're kind of tight and testing the product.

Okay, so onboarding, communications. Yeah, um, it would be a lot to discuss about all of the steps. And in some cases, it's not quite standardized yet. But when we start working with somebody, like once the contract is signed, the first invoice is paid, we start inviting them to the accounts that they will use. And that's usually a Notion page with, or a Notion space with everything that they, that we're gonna share with them. And it's also a Slack channel. where we will have all of the discussions. Design explorations is slightly different because we don't do a lot of design exploration, I would say, and this is because we do kind of the research together with the clients and because of the process.

Mhm.

And collecting feedback, this depends. We collect feedback and testimonials from our clients through a form But if we are talking about the design testing phase, then we do that through calls that are recorded, and then we use Dovetail to extract the insights, and we actually take a bunch of notes during the call as well.

Kind of, I don't know, this also points to what we were speaking the other day is that it's important to always be open about feedback as a designer as well and continuously ask them. I mean, not necessarily continually ask them, but just to do a check-in with the client if—

Connect them.

Sorry?

Connect them.

I feel like it's a good practice to also ask for feedback as you're developing, feedback on the collaboration. In order to improve aspects that can be improved, not only—

Oh yeah, and we also have— I forgot about this, but it's on my calendar today. This is why I remember it. And we also send out a weekly status on the work in general to the clients. We have to do that today.

Yeah.

Okay, it's on my calendar. This is why I remember about it. Yeah, we try to be as connected with the clients as possible. So even when we work on the design phase, we We have almost daily check-ins or in a way a discussion or something, either to get feedback, either to discuss next steps or blockers or what's there. And that helps a lot with moving forward and like not just wasting time but actually delivering value.

Yeah.

Okay, I don't know what's pitching a past project.

I was hoping that you have, that you know what it refers to.

If it's about If it's about the hiring process, because I know that people tend to give out test projects, then I have an opinion. I don't know if that's the thing though, but I remember when we were hiring, not for us, but for another company, and we had a discussion regarding using test projects or giving out test projects to designers. And my take on it was that we can do that, but it shouldn't be tied to the actual work that we do. And even in the interview process, we didn't use anything regarding the product. We used some fake projects.

Mm-hmm.

We actually had a list of fake projects and we just wanted to see how people are going through those things, how they think, what questions they ask and stuff like this. If you give it out to actually work on it, like That there might be something tied to a real project, to the real project that they— you hire for, then at least I assume it should be paid because they do work. So yeah, but otherwise, I don't know if this was the questions, but this is, this is how we answer it.

So the last one from here, where should you focus on your growth as a designer regarding coding, business, marketing? I feel like coding is a bit— it's a lot to go in that direction. It's important to understand the development part and be aware of what can actually be implemented and don't just create pretty things. But I feel like it's a completely separate area if you go in.

Kind of, yeah, I agree with that. I know that I remember that a few years ago there was a huge discussion in like the whole design community regarding if designers should actually code or not. And there was all— there were also some jobs where they required, at least for the UI design part, to have a knowledge to code it in HTML, CSS.

Yes.

But it kind of faded. I don't know if there is anything like that anymore, though it might come back in a way or the other. Especially now when, you know, there are more people on the market and companies try to cut costs. But yeah, I'm kind of on the same page with you. I don't— you should know about it, you should understand how it works and the limitations, but I don't see the need for a designer to actually write the code.

And I assume with ChatGPT and stuff like this, on the business side though, I feel like that's Really useful. And it's kind of tied to what you said in the beginning, in order to expand from just being a UI/UX designer to more on the product side and understand the whole business.

Yeah, business and product, definitely. Yes. And it's, in a way, I also prefer to learn about this than coding, though I know some stuff about coding. I've also did something like that when I started. But business and product, I would say, are in a way more, are closer to what we do as designers because you kind of shape what's coming out of those sessions and discussions and stuff. And you have to actually understand how you will impact the business, how you'll impact the product, how would you generate revenue if it's that side. Um, so yeah, I would definitely go business.

It's an important part in the whole process anyhow.

So yeah, yes, marketing, I don't know, like it's good to know about it, but I don't know how much you would swing that way.

Have on your work as well.

It helps definitely in like knowing how you tell your story and stuff like that. So knowing how to do proper storytelling definitely helps. But yeah, otherwise, I don't know, a bit lost on the marketing side.

Okay, good. Then I think this is actually the last slide. I'm not sure, but— It is.

It is the last one.

Oh, okay. So how do you define a product MVP?

Oh, we briefly talked about this regarding the process. Like, the process that we use, it's kind of the same for MVPs or existing products. The main difference is in kind of 2 areas, I would say. When we do an MVP, we do user story mapping. When we do an existing product, we do customer journey map. And this is because we on the MVP side usually don't have any kind of feedback on the product. And I use the story map, it helps to map out the sections and figure out how you will actually plan the release. This is why we use that. And also you don't have usually metrics, any kind of metrics or data on that side you don't have. So on the MVP side, we don't, we don't have that thing to actually look into. On the other side, we have it and we try to to get access and to understand and extract the information that we need. But otherwise, it goes on, it goes kind of on the same process. So still 3 big milestones: context, creating a solution, testing it with customers or possible customers in this case, or people that match the ICP or the target customer profile. And then creating the designs.

Yeah.

And yeah, basically you try to iterate as much as possible in the design phase and de-risk again as much as possible in that phase. I wouldn't like— we can go very in-depth of like what's an MVP actually. There's a— I don't know, I remember that I've done workshops and presentations on MVPs and people have very different opinions on what's an MVP, if it should be something that generates revenue or not, if it should be something that's just testable or not, if it should be coded or not, if it should be low-coded or not low-coded. So there's a lot of stuff. Uh, I kind of go with Marty Cagan's version of this, like minimum viable prototype instead of minimum viable product, in the sense that I— you want to test something and you want to test your critical assumptions. That means that you have to have a a good understanding of what are those assumptions. This is why we actually do assumption mapping.

So yeah, uh, next, what was the hardest thing to master about UX?

Yeah, imposter syndrome, probably. Getting feedback, it's like, I don't know, it's one of those things that you have to get used to. in a way to get slapped in your face with a chair. But yeah, probably that in the beginning. It depends on, like, it depends on the phase that you are in. In the beginning, getting feedback and/or getting feedback, it's challenging. Asking for it, it's probably even more challenging than that. And there is also the There is also this thing that a lot of designers, and I've done this as well, so this is why I know about it, they don't really ask for feedback.

Mm-hmm.

And then it's a bit too late to make changes. So yeah, kind of that's the hardest thing. I don't know. What about you? You are kind of on that side, like beginning.

Um, yeah, I think we actually talked about it yesterday as well.

Yeah.

Um, yeah, mostly regarding the feedback, I feel like in the beginning it's more difficult to detach yourself from the design. Uh, but what helps there is making, uh, informed designs, let's say informed choices, and, um, yeah, to just back up your work. And I feel like that kind of helps. So probably that. Okay, well, last, last but not least, if it were to name a thing that yields, um, 80% return with 20% work from a UX process, what's that? So a magical, a magical trick.

I don't know if there is anything that I can— I just say that, okay, do this. And it will come up around these percentages. In a way, you have to start with understanding the problem that you want to solve, but that's like a given, I would say. And if you don't know that, then basically whatever you do after that, it's kind of chaotic.

Yeah.

So yeah, this is why we start the projects most of the times, most of the times, most of the times. Yeah, we kind of start most of the projects with like a small kickoff workshop, at least when we don't do the whole shebang with all the workshops and stuff. So yeah, understanding the challenge, the context, probably that, though I don't know if it's like 80/20, but it's definitely a good start. Yep. I don't know. Do you have a better answer for this or another opinion on this?

No, no, no, I was actually very curious on the magical trick.

There are no magical tricks for anything. No shortcuts. Yeah, this should be like our motto, I guess. No shortcuts.

No shortcuts.

Yeah, cool. Kind of, I think kind of this is it, right? This is the last slide we have. Yeah, this is the last one. Good.

Well, hopefully they were useful tips. to the people who weren't able to attend the meeting.

Yeah, and yeah, most probably we'll do something similar in the near future as well. So yeah, keep in touch, leave comments, leave questions, and let's see when will be the next one. Cool. Cool.