Deep Dive
Shownotes Transcript
We will not just go out of tastes and preferences, but we will actually have criteria to measure our design upon. So the idea of the UX process is that it leads to less risky results.
Hello everyone, how are you guys doing? Welcome on the third episode of our Anvisa and Ioana podcast. In today's episode, we are going to talk about design processes and this is a very, very big topic. So I guess we'll just try to cover some things about our experiences, some processes we've been able to practice in our careers and also maybe just bring us down a
Those different processes can be applied in different companies depending on where you're working at.
So with this being said, before we dive into the topic, Ioana, do you want to say how was your last week? How was your life? How are you doing? Hello, everybody. Thank you for the introduction, Alpisa. I think we're getting the hang of this. I mean, episode by episode, we're getting better at introducing people into our small informal conversation space. My last week was quite hectic.
like all my weeks are but now I'm trying to slow down a little maybe take a break from doing too many things all the time because it it feels uh it's rewarding but it's also exhausting so right now I've closed some projects actually last week which was very fulfilling I had this sense of achievement and accomplishment okay I took this project to its final yeah so now I'm on
evaluating how things went, looking at lessons learned and so on. And so I'm a little bit introspective. On my side, last week I was a little bit sick, so it's not super exciting. Last week I had this epopea or this drama with my past freelance client. I removed myself from the drama, but this week it's actually coming back. So we will see how it goes besides the work and course. Oh, wow.
There is some dramas, but I hope we will resolve it soon. Yeah. Talking about the whole freelancing experience, it could totally be not just one episode. It could be the whole topic of the next podcast. Freelancing is the thing. In my experience, it was just that I had a client and I was, as a UX designer, I was trying to plug in people for the project. I found a developer and then I found illustrator for a project.
And the client was working fine. Everything was great. She was paying in time. She was not creating problems, but
Then at some point, there was some miscommunication with the process and illustrator did. In my perspective, they were really good. The communication was great, but something went wrong between the lines and the client said, like, I'm not going to pay for this. So there was a conflict. And I said, like, okay, I don't agree with these values. I don't want to work in this environment when the time is not appreciated. So I don't want to continue working on this project.
So after I shared it, there was a lot of drama, maybe a little bit of manipulation and stuff like that. And so it was hard a little bit to find a resolution to this. And I really, really don't like those stressful moments when everything was fine, but then out of blue, you know, you appear to not share the same values. So it's just a little bit hard and distracting you from working actually. We're still looking for a solution. So let's see how it goes.
I think it's totally a fascinating subject for a different for a dedicated episode for this because I think that there are so many ways in which partnerships can go bad or things that you can't foresee or maybe for example in your case maybe values should be agreed early on but how do you actually do that so it sounds very ideal but can you do that and I think that um
Yeah, it drains you emotionally. It's consuming. And I think that many designers out there deal with it. And maybe we don't have the weapons or instruments or enough knowledge to know how to deal with it better. So let's make an episode about it. Yes, I think it's worth it. Yeah, we will see. But there are a lot of episodes we want to do also on the mental health, right? And we don't have so much time left, right?
let's see if the baby will be supportive of our podcast and give us the space to record I have a hope in this baby
All right. I think we can just dive into the topic of this episode before we started moving in different directions. So processes, design processes, big topic. Where do we start? So let's maybe, I was thinking we can start from saying what processes do we know and how, what do you think did you, you know, practiced before?
what things maybe changed, did you experiment experimented, experienced, maybe even customly created those processes. How are the things being in your experience with different, you know, years of experiences and companies you were working in? Just a little introduction, I guess, real overview.
Well, I'm going to start by saying that for a very long time, I tried to find the perfect process, if you want, the absolute process that will work in any circumstance that I can also promote inside my company and then promote to the people that are running with Scooties and are asking me about process and make sure that
this is the one size fits all ideal steps that a project should put but then reality hit me every single time and there is no fixed or perfect process that will
solve any problem regardless of where you apply it, of the context you're in. So the context and the circumstances around you, the team, the product, the company, everything has an impact on how the process will unfold itself. So then I gave up trying to find out this universal or the universally applicable right answer
regarding the process and then I became more flexible over time and realized that a process is actually it's useful to be referenced it's useful to understand that you pretty much need to go through some some stages in any design project but at the same time these stages are not fixed by any means so they will be a back and forth most of the times and
it's going to get messy. It's not linear. It's always going in circles. So then I just, I, I, I,
I gave up trying to define and identify and put on the wall this perfect process and I opened up to being flexible, adjusting along the way, making sure that the stages I go through or I propose that we go through make sense in the context of that particular project. So where I'm getting at essentially is probably
at flexibility around process so the design process is very nice to have a big idea in mind but at the same time in reality you're gonna have to be adaptable flexible and adjust the process to the content so that's pretty much the introduction that I feel like giving on this topic okay and so would you say that every time you start a new big project small project average project
you kind of create a new process like you based on the timeline resources we have here is the suggested uh kind of plan for us to go through right is it always custom or do you at least have some structure in mind usually it's a great question i love it uh because it actually gets to the point of our problem so um it's it's actually uh
Custom every time, yeah, in a way. But at the same time, there are some unmissable parts, if you want, some parts that we can't do without. So, for example, we can't skip research. I don't think you can do UX design without having the research phase of the discovery part of the project.
Then, of course, after we find a solution, there's no way of launching it without testing it before that, doing usability testing and so on. Some parts of the UX process, they're always there, regardless of the project, or at least we start with the idea in mind and then...
If you're very keen on not giving up, sometimes clients or even your coworkers might push you into, okay, let's keep usability testing because we don't have the time. We're going to launch it and see afterwards. But I think that we have to push for keeping the important stages in the process. But yeah, so when I start a project, I pretty much think of a high-level outline for the process that I...
process that I want to apply to that particular problem. And in the beginning, in the early days of my career, I actually wasn't able to customize anything because I had no experience. I had no idea what I was doing. So I just applied something that I read on the internet or I knew that it's probably the right thing to do and went through all the stages. And then in time, you realize that some stages may not make sense or that you can add other stages that are relevant in that context.
So I was, I became able to customize the proposals for the process in time with experience from one project to another. So this is another important point.
Yes, you have mentioned that you would, okay, so there are definitely stages that you can't kind of take away and throw away. But there are other stages you might sometimes skip. So I wonder if you can elaborate a little bit on the stages. So what are the stages you would think of every time you want to approach a new project process solving problem? Like if there are those, what are the building blocks in your experience right now?
So in, I think the building blocks are the first let's call it discovery phase. This is what I call it most often in conversation. So the discovery phase, you can't find a solution without understanding the problem. It's,
it's pretty much common sense but at the same time we all know that in real life people tend to come up with solutions and then they search for a problem that solution is solving so it can happen that some people just have ideas that are
solutions and they skip the discovery phase. But in a healthy UX process, in a healthy setup, you will start by understanding and deconstructing the problem. So this is the discovery phase. It's a phase of understanding. It's a phase where you dive deep into the problem. You need it for the UX process because you want to know what
What's the point of all your efforts? What is the problem you're solving? And this involves also doing a lot of research, maybe involving your users, getting, not maybe, hopefully, involving users, getting to understand them. But for example, it may be that some projects don't need a persona.
Let's say this is a small example and maybe most of the projects do, but maybe in one case, I don't know, persona is not that relevant for what
problem you're setting out to solve. But so you can't go on without doing research but you can skip on some artifacts or activities that you normally see in the classic design process if you want. So research is essential and being part of a discovery phase. Also before
choosing a solution, you're going to need to ideate a little so you can't find solutions without the ideation phase. Ideation is also a fundamental part. Then, of course, once you decide on a solution, you iterate on that solution and explore different possibilities or multiple solutions, choose the best one and so on. Testing is also very important. And I think that then implementation
It's also, I mean, implicit. Yeah, I don't see any fundamental stage actually skippable. What I think is skippable or is adjustable are maybe the activities that are involved. Yeah, so that sounds like we really don't want to skip any stage, but we might want to adjust the timing and the exercises we go through in every one of those stages, right? We might kind of...
make this one longer, but this one really short and quick. And maybe even just use one workshop for this stage instead of us doing like two weeks of exercises, right? Cool. Yeah. So in my experience, basically, I would usually go like my mindset and actually I was introduced to it in my university. And I still like really love this mindset and
and want to practice it every time. At least I'm not, it's not like practicing it, but I would say like I always have this structure in my mind, whatever I'm doing. And yeah, this is like the classic, the most cliche, the most always used double diamond. I think that most of the designers know what is this, but if somebody doesn't know, it's like imagine two diamonds.
two diamond rings where you have like four Ds. One is discover, then it's define, then it is develop, and then it is deliver, I think. The beauty of it is that you have those diamonds where you first always have like this first diamond, it's like expanding. In the beginning, it's like expanding, diverging,
And then at some point you have to stop because you cannot learn everything and you have to converge all your insights. And this is like the second part where you define what you have learned. And then there is this middle point, which I usually call the design brief with a strategy or requirements for the design. And then there is this, again, develop where you go through different sets of like ideas, ideations, concepts, testing, etc.
And then there is this deliver when you just, you know, talk to the developer, handoff, support, give answers, reiterate and so on. And usually I would say like testing happens either in the delivery stage or in the develop stage, depending on how much, you know, how much overlap we have with the engineering timeline. Um, and so even though, okay, this is, yes, it's also like a framework. So it's not that, you know, every time you, um,
starting a project, you stick to it 100%. It's not that you would have sort of like outline of the double diamond every time you do a new project, but I would totally always keep it in mind because I feel like it's also essential to, as you said, like it's very essential to do every step of it without,
you know, having research, you're risking to build your project based on the like very assumption, very weak fundamental. You might go directly into the conceptualizing stage, but then it means that you're designing it, you know, you're sticking something to the wall and see if that sticks. So there is a chance it sticks, but there is much more chances that
you throw it and it's not, you know, flying. So you might want to eliminate those risks. So I think like it's really essential for any project to start with the research and still define. I think like for me, it's also important to define stage, even though it's hard in the beginning. It's always, especially when you're a beginner and you try to define everything you've learned. It's this hardest, I guess, for me personally, it's been like this always. And I can see on my students right now that the second stage, the define is one of those highest classes
like peaks to climb because it's always overwhelming oh my god so much information how do I use this information how do I make sure I like take the what is the insights what are the what are those things right you just don't always know what to do with the information and sometimes as the beginner you just can be overwhelmed and even start procrastinating or even want to skip it and directly start with conceptualizing so you might even miss out on this insight that you've collected
So I think I was trying to say that, you guys, there is a second stage. On my personal experience, it's the hardest one, always. Then I would say some sort of design brief where I would just try to specify what actually I'm trying to build. What is this first strategic step we need to do? What are the criteria for the concept? How would I measure the success of this concept? So knowing who is the users, how they will use it, what's the market to its part, knowing all those different things, how
how will I make sure that if tomorrow I start conceptualizing something, we know how to evaluate this design. We will not just go out of tastes and preferences, but we will actually have criteria to measure our design upon and in a rational way try to evaluate this design.
And obviously, yes, so I was talking a lot, but I was trying to say that we have discovered it's important. That's the fundamental. We have defined where it's hard, but it's super critical because without it, you cannot have strategic brief ready.
And then of course there's conceptualizing, which is usually the funniest part, the most engaging part is always about creativity, it's about engagement with maybe other designers. And you during this stage, it's like this part where most of us designers are, you know, usually jumping into because it's fun and exciting and you want to be creative and you want to look for references and try different ideas. So this is this fun part.
But then you still have to stop at some point and evaluate your designs. Either test the concept, is it solving the problem? Or actually, if you're working with the existing product, maybe you need to do the usability testing. So see if proposed flow, proposed solution meets the mental models of your users. I was talking a lot, but I think what we can try to do right now is to also try to understand
How do you think this mindset or this process could be different in different organizations, in different companies, startups, freelancing and stuff like this? So what's your input on this, I wonder? I think that indeed one element that's a differentiator between smaller projects and big projects is speed.
So for me, freelancing projects, I was able to, because I could control the pace of the process and I control the timeline, the stages. So you have more control. Actually, you're more independent. So things tend to move quickly and you get to results faster. You can fail faster if that's the case. And then, yeah.
pivot or find a better solution and so on. In the big corporate world, things are, as you can all imagine, a bit slower because you have to involve, just like you said, everybody has to be at the table and you have to align with different teams, the development team or the product managers or other people from business lines inside a company or product marketing, I don't know,
And so it's pretty much a continuous effort of aligning everyone, which is very useful in building big products and scaling products. And when you have a big challenge or one that cannot be solved by one person by himself, but it's also a bit, it adds time to the process and it adds complexity and it adds another layer of things that you need to manage. So the communication with everyone around you.
I think this is a major difference. So in a way, what it all comes down to is that there's different, the different flavors come from managing different elements inside a project.
relationships more in the corporate world than in the freelancing project but of course in a freelancing project you have to manage your clients so you also have a close relationship at least with the client and then with the developer and so on. From my experience in big companies I was able to accomplish
Things that in the end felt more rewarding in a way, because you have to put so many pieces together. You have to align all these people. It takes a lot of time. It's also a lot of negotiation going on, a lot of convincing everybody that this solution will work.
that these are the findings that we have from research. So you advocate your solution basically. So in the end, it feels very rewarding because you have the feeling that you overcame a lot of elements of tensions, of, I don't know, back and forth and so on and other forces that you managed to control.
control or a line in a way. At the same time, the process and freelancing projects, since it's only, it's mostly dependent on you, so you have better control,
it's great that you feel like it's kind of like your work, your baby. So I had the same feeling or a similar feeling of accomplishment in freelancing projects as well. So I'm curious to hear what are your thoughts on this? How is it different or how is it specific to the company versus a freelance project?
Before I dive into it, I just wanted to also like maybe make a note on what you were saying that with the bigger companies, you definitely need to spend more time communicating. And I also want to point out that maybe for those people who don't have so much experience working with different companies, it's
It's just to make sure that they don't think it's a bad thing, right? That you have to communicate with different people. It's something that is unavoidable the bigger the company is because the bigger the company is, the more is the client base probably or the more it is at stake. So you really need to make sure you evaluate every single part, the vision, the constraint, the, you know, maybe the...
Some of the people already tried different things. Some of the people have already information. Some of the people understand what it means making this change. Even if it's like, you know, moving button from one side to another, it sounds like, you know, come on, it's a button. Just move it to the left, right? It sounds like an easy thing, but sometimes you just don't understand how much
this button can imply. It's a habit. It's a mental model for somebody. It's something that they do blindly on a day-to-day basis. And it also involves a lot of rules and behaviors and, how to say, correlations between different things. So it sounds like a small thing, but you really, even if it's a small thing in a big company, it could be really impactful.
And so it's not to say that if we have to talk to different people to, you know, move button to the left, it's just because, you know, bigger companies more bureaucratic and horrible, but it's really, it's a bigger risk. So that's why it takes longer and you need to really check with everyone in order to make this decision.
And I agree with you that for sure with the smaller companies, smaller startups, it is much faster, much more dynamic. Of course, smaller company is the less stable it is. You're still looking for that business model, investment, et cetera, validating your ideas. So yeah, it's maybe funner to work in it because you're your own sort of boss and you rule the project. You don't have to check with everyone.
It's like everything in your head and you control the scope and et cetera. But it's also the fact that you will spend a lot of time understanding every single thing yourself. And then most likely, I mean, you can definitely work with the prosperous growing startups, but in the beginning, if it's just a new startup where for a lot of work, for amount of work you're doing, it's just not so rewarding as it could be in other companies or bigger companies.
So there is always pros and cons working in different companies and this is something we can also discuss at some point. But for the processes, design processes itself, I would say that
It's, I personally love to experiment with different ways of working and like designing. And even though those are like just, you know, all those frameworks and buzzwords, design thinking, design sprints, workshops, design double diamonds, et cetera. It's, yeah, it's just frameworks. We don't have to be, you know, super oriented on them. But I still, at the same time, I really just love to try things out.
and see if I can adopt something from there. So learn something, try something new and see if that's actually working great. So my new last thing, which I'm really excited about is like, try to go or go more with the workshops. Um,
Before it was like design sprints. Yeah, let's try design sprints. Let's put five people in the room together for five days and see what works out over there. But now it's like, oh, let's design custom workshops. Okay, this is a new challenge. Let's try to put different people at the same room with different knowledge and try to understand what do we know and put everybody on the same page. So for me right now, lately, it's been all about like design workshops, custom ones. And I still like to think about design workshops in this double diamond mindset. So
every time you even design a new workshop, it's like, let's first diverge, then let's converge, then let's try to make a decision, and then let's first
I don't know, diverge ideas and then converge on our solution. So it's still the same mindset. I really like to follow the mindset. And coming back again to the question itself, I like to go astray, but coming back to the question, I think that I agree with you that timing and people is a huge factor that could define processes sometimes.
And also, I think that resources in terms of budget could really define your process. Some of the clients, they, and also like even understanding, putting the client on the same page, what kind of expectation this client could have. Sometimes it could even take another step, which is education for the client. They could come up with you and being sure that they have a perfect idea, but they've never done any research. And it would tell you, hey, please, you know, just make it pretty.
And you would have to take a step back and try to take them through the, let's first understand what do we know, the stakeholder workshop, and try to collect the knowledge and try to see if we have gaps and if we need to do the research. And if the client are not able to answer some basic question, who, why, and what, then let's try to do a step back again. And that would define another stage in our process. We definitely need to do the research and discovery.
So it's like, it depends on what the client has done already so far, at which stage of the project, how much time and budget do we have?
And based on this, okay, how much we can do for this time and money. So we can do a huge project. We can do half a year project. We can learn everything about this field. We can do a perfect, you know, case. But sometimes you only have like a, you know, one month to do it all. And you will need to go out of that and you will not be able to do all those in-depth projects.
usability testings or research stages, you would just need to do something super basic, a couple of interviews, a couple of assumptions to be tested, a couple of ideas to be tested, and we go, right? So the bigger the timeline, the more the opportunities are for us, the lesser the risks for the project, but of course, the more time it takes and also, you know, budget would be higher for the client at the end.
I think you touched on a very important part about the point around processes is that often processes have to be thought of and executed under constraints. So constraints is an important part of the
UX profession in general, the UX role. So we, of course, there's never unlimited budget, unlimited time. Research has to stop at a moment. So you can't always discover and you'll never be 100% sure of anything. But
you operate with constraints and you have to manage under those constraints, which of course, if the constraints are absurd. So for example, the client says, I want this ready in one week, then you have to oppose that and define what's the line between
by which I'm not going to continue. I mean, I think that we have, we also have to, it's our duty to negotiate with clients and help them understand, just like in your example, and the point you made earlier that it just so happens that the client comes with this predefined solution. He knows it. He doesn't want to spend any more time into validating it. And then you have to make sure that you have to start by what's the actual problem that
this solving and many times it's funny that the clients cannot, cannot answer that question. So it's not clear to them what the problem they're solving. So then you have just like you said, to take a step back and go back a few stages and a few milestones if you want and start from the beginning, maybe the discovery phase and so on. And it may, it might feel uncomfortable in the relationship with your client. It might feel like, um,
I don't know, you don't have the energy or it's weird. It's a weird conversation. Hey, you know, I don't want to do things like you want. I want to do them in the proper way. But then if you show them exactly the fact that like you were pointing towards, you
you you you reduce the risk when you do the process right so the idea of the ux process is that it leads to less risky results and i think that there is no client in the world who wants to take risks and risk losing money and that everything he's done goes to the trash and um yeah i
think that another interesting small point that I've noticed in my personal experiences so far is that sometimes when you show clients the process and you show them all the activities that you'll be going through, they kind of get excited. At least some of them, they're also excited. And now, so we're going to do a customer journey. Wow, that's cool. And so they feel like they're doing proper UX. And so you get, they get both.
and even by being introduced, educated, like you said. So by being shown what's going to happen and having predictability and having themselves immersed in the process, then it can even be fun for them and they will not be as reluctant as they would if you would say, okay, you know what, let me handle this and we talk in one month. And if you involve them along the way, then it's going to become easier for you to negotiate. Yeah.
I like this. And I also think that, so first of all, I agree with you. And I also think that it's your duty and responsibility to educate the client and also understanding that businesses, they really hate to lose it all or money and time. And, you know, sometimes it's very important for startups, especially to be in time. So it's your duty and role to communicate that measure pays twice. And if today we go with your, how to say, validated concept and
and, you know, spend all this time developing it and putting it in market to see it fails tomorrow, this is your risk. You're just here to communicate that it's the risk that you're taking. I'm okay. We can do this. But I told you, right? And so...
My tip here, actually, which I wouldn't say it's a life hack, but it really helped me a lot in the beginning, is to try to involve the client in the beginning into this stakeholder, as I call it, workshop. And it's not to just, you know, engage them and explain them, you know, how things are working for us designers. It's really not about that. It's also about asking those challenging questions and
and see if they actually don't have answers. And when they realize they don't have those answers, it's some sort of this aha moment that, all right, it's true. We never thought about it. Oh, maybe in this way, asking challenging questions and being prepared to ask those questions, you're actualizing the need for them to actually spend this time going a little bit backwards. But
figure out first who is the user, why does he need this thing, what's the problem there, what's the mental model, what are the habits, what kind of market are we trying to occupy.
So it's my personal life hack or tip or whatever is to not just engage the client, not just educate the client, but also ask those challenging questions to provoke those aha moments when the client really realizes that, wow, we actually really need to do those extra steps. And that would be really important for the project, right? Yeah. And it can be a workshop and it can also be, so the way I go about it is that
by being usually in big companies or even in freelancing, freelancing with clients that have a big organizational structure and many roles. What I do, I set up interviews one-on-one with the stakeholders involved. So you can even put them all at the table where it's going to be an exchange even between them. You're going to understand how their relationships between them work. This is
also an interesting insight but at the same time I always start by having one-on-one interviews with these people with the questions that in just like you said need to be asked in terms of what do you know about the user who is our user what is the problem
Why are we solving this problem? What are we expecting? What is success for us and what's our vision and so on. And so even this is another continuing on your stakeholders workshop, which is a great thing to do. I would also advise people to have one-on-one conversations because maybe sometimes, I don't know, there are some dynamics between them that
in a group exercise can prevent them from being completely open or, I don't know, avoid saying some things or complaining and so on. And so if one-on-one interviews with cycles, it's also a valuable stage in the process. And I actually never skipped any process in my entire work. Every single time I had this happen. I would totally say this is almost the same thing.
So it's really the same part, right? Understanding what business knows and, you know, putting everybody's on the same page. I think like the stakeholder part I would use when you have like different people in the business and you just need to, you know, put everybody's on the same page. If there are different parties, silos, departments, and they all have very different understanding of things, then it's important to do this workshop. But if it's a small, you know, project,
one, two clients, whatever, a small team, right? In this case, interview would be enough for you to start with. It's less time, less stress, less organization, preparation, et cetera, but you still have all the same questions asked and see if there is answers to them. So I think it's the same section of project,
or part of the project that you definitely need to go through. Also, I would say like small recommendation here is to always in those meetings or workshops to ask from the client about, first of all, you know, how are we going to measure this success of the project? So if we don't put this in the first meeting upfront, if we don't agree on something like what is this perfect project looks to you, to me, to all of us, then at the end, it
it's like everybody would change their expectation. If you don't have it documented, then there would be always, there is a higher chance that they would come up with the new idea, new feature. And they would say like, oh, we have like, we just got this new interview inside, whatever, let's try to do something different. And then you're just shifting your attention and then you can spend much more time on this project.
So you would always be able to refer back to those goals and measurable metrics that you want to check at the end. And if you want to change something, if somebody comes in tomorrow and say, hey, we want this new feature, you say like, yes, all right, but this is a different project, right? It's a different goal. It's a different part. It's a different idea. We can put it on shelf. We can discover it later. Let's first finish this one if we still think it is important for us.
And another small tip here is to always in those, if you do the workshop or like an interview with a couple of stakeholders, is to try to understand who is the main decision maker here.
That's how the workshops are usually helpful because you really have like a main decision maker there because every time you will further present the next stage or the next thing you did, it's important to present it to the right people, not just to people who have an opinion, but also to the people who will be signing off on this.
it's important to get everybody, but it's also important to present 25 times different people. And then when you present the main stakeholder, you're already like, you're like that and you don't want to present it. And you're missing out on important insights because you think that everybody knows about it, but not. So I think it's also important to avoid risks if you start understanding who is this, start by understanding who is the main decision taker, maker or whatever in the project.
This is the bullet points moment. I love the points of
So I liked the fact that we touched on the differences between working as a freelancer and how that impacts your process and then working in a big company and how that process is completely different. And I think that you made a great job at expressing how to kickstart processes in a
in some examples you gave and kick-starting the process and thinking out the process from the beginning and agreeing it just like in your final, in your most recent point, agreeing it from the very beginning so that you don't have a
scope creep or the project changes along the way and then it's a completely different animal that you don't know how to handle it. And so setting up boundaries and clarity from the beginning towards the process is also very important. But getting back to our earlier points, you also need to be adaptable. So there's a balance that you'll be able to reach with experience.
as time passes and from one project to another, but in the end, the main idea, the gist of it is that there are some essential parts to any UX process, to any project that shouldn't be skipped. And then you go around adapting them to the cost you're in. So this is, I think, the main takeaway, if you want. Cool. I love it. Let me see if I would add something there.
I would say yes. It's so as you said, like being adjustable, maybe like as a tip, as if you're the beginner, try to absolutely try different things, different projects so that tomorrow you have a better understanding of what processes might look like and how do you, you know,
Every time you have a new challenge, you don't feel scared on planning and you don't think about everything in a linear way. You understand that it's always about making another critical turn and sometimes adjusting. But it's still important to try absolutely different things. So next time you feel more confident about it, even though most of the times when we plan something, it's just still different and it ends up being an absolutely different process. It could take a turn, whatever. You never know what's going to happen next.
you never know what kind of insight you get from your users maybe tomorrow you validate an idea and you see that it's it's pointless and so on so you never really know but you need to have a plan a structure in mind and you can follow different structures design thinking structure with five stages double diamond with converge diverge mindset like you can have different whatever structure fits your mindset better just pick one and try and always to keep it in mind
in whatever problem you're solving how big the really doesn't matter how big is the problem is it one big problem or is it i don't know one year project right still always try to think and
think within your constraints and limits. So even if you have one week to solve this problem, think how much of a time you can spend doing all those four or five stages, even if you have so little time. Maybe you can even do it in one day. You know, there is this design service jams, right? Like a hackathon and weekend where you actually do the whole design project with all four stages in just, you know, two days. So it's really, really possible to do it really quick.
with limited resources. You can totally do enough research even if it's a very short timeline, but it's important to follow all those steps and to not miss out on important critical stages like understanding, defining, then developing ideas, and then testing those ideas and delivering those ideas.
As a final bullet point for today, as we already discussed today, it's important to set the right expectations for your stakeholders. Even if we know that the process is never perfect, it's never going to maybe even work out in the way you planned it in the beginning, you still have to have this expectation set and be on the same page with your team, with your stakeholders, and really be aligned on the goals and on the success of this project.
that would be also my bottom line. So yeah, anything else we want to talk through today?
Well, I think we've accomplished enough for today for now. I'm hoping that our audiences got a lot of value from this conversation. I feel like I did and I crystallized some ideas I had. I was exposed to new points or new perspectives that you shared. I know it was a great conversation and I'm hoping everyone feels that and looking forward for our next episode.
yes me too me too let's try to define what's our next episode gonna be like hopefully yes we will see we will see but yes thank you so much everybody for listening this episode we hope you have a great day a week a month a life and we'll see you on the next one ciao ciao great design project everyone yes bye bye bye