#72 Design processes: expectations vs. reality
34:56 Share

All processes involve problems and the way you unpack those problems, the solutions and the way you explore those solutions. A big chunk that is the conversation around all of these things and then a lot, a lot of collaboration. And that can happen in the shape of critiques or just things or weekly meetings or daily stand-ups or stigma comments.

but that's what you'll be running into in most of your design roles. Conversation, collaboration, problems and solutions. That's the core of a design process. Hello everyone and welcome to a new episode of Honest UX Talks. As always, I'm joined by Anfisa and today we will be tackling a topic that's super interesting for junior designers, mid-weight designers, senior designers, probably all designers out there. And

the question we will be unpacking today is what are the differences between the expectations for the design process and the reality? So expectations versus reality when it comes to design processes. It's a topic that probably we've all had to navigate in our careers.

Because we've all seen the frameworks, design thinking, double diamond, design sprints. We are in a way sometimes socially bombarded by these options. And then how do they actually work? And are they actually linear? And how's the reality of designing? This is what we're going to be discussing. But before we do that, our weekly, how was your past week, my dear?

Hello, everybody, and welcome to the next episode. My past week... Huh, actually, what was happening last week? I think I started being much more active at working on my course, so that's the highlight of the last week. And it's getting a bit crazier and crazier to mix it together with the work, so my work become...

more and more intensive and based on the new process, actually another relevant part of the topic today. Based on the new design process we are working on, in fact, it's not design process, it's collaboration process with the development teams. So based on that, the whole process becomes more intensive.

And so I handle or juggle a lot of deadlines right now. At the same time, I'm trying to focus on my course so I can actually build it and deliver it hopefully in April. That's what I'm targeting. So yeah, it's a bit of a messy period. Barely keeping it up, but...

But yeah, the good thing is that this week I'm going for a vacation in a couple of days. So I'll be able to take some time off finally and actually rest. Because I think I mentioned it before that this winter I didn't have an opportunity to take some time off and rest due to the home renovation project.

Anyways, how about you? How was your week? My week was also pretty intense, I think. Although I was just posting on LinkedIn a couple of days ago that I'm in some sort of social media burnout or like just not very creative and inspired to keep posting and I'm not as active as I used to be. That's because as our regular listeners might know, I'm very keen on my design craft right now. I've been doing a lot of design work, which is

exciting at this moment. I feel like this is what I want to focus on like 90% of my time and it's turning out pretty nicely. And then also I was able to catch up with a dear friend of mine. He's moved to Amsterdam recently and now he was in Bucharest for the weekend. He's working at Meta as a senior product designer. So we're

we kind of walk through how the design process happens at Meta. So it's pretty timely to have this conversation about design processes and in different types of organization. My mind is fresh with these ideas. And also I have some conversations ongoing for different new projects and new opportunities, and we'll see what comes out of that. So, but keep close.

So that's it in a nutshell. Let's move into our topic for today. I would say the first thing that I would look into is what are some of the design processes that we've been most exposed to? What is a design process anyway? Oh, yeah, that's a big question. I think like we as designers definitely came up with our own bubble, came up with a bunch of amazing processes, to be honest, fantastic and on the paper, let's say, processes that could work.

Processes that actually do work mainly in design agencies, on my humble opinion. And then processes that we teach, but when it comes to working in the bigger corporations, enterprises, bigger companies, establishments, then it's when it becomes tricky because the process we have invented for ourselves, preached, talked a lot about

being always aspired to, it's not always easily fits into the bigger companies, right? Because there are multiple, multiple disciplines within one organization. They all follow their own processes. Everybody has their own bubble. Everybody believes that their process is the most important one. And eventually, whoever is the most opinionated, maybe hierarchically high person or the critical mass of people, whoever is taking over will be the process that most likely will have to be spent

spread throughout the whole cross-functional company or department. So the process is always tricky, especially when it comes to bigger companies. Coming back to the original question, though, the processes per se, I think the most common processes are those that we love and always preach are design thinking, double diamond, maybe agile, design sprints, like you already mentioned today. So like all of those pieces either together or separate or depends on the project. This is something we all preach.

I personally, a big believer or sort of promoter of the double diamond, but for me, it's not even the process. I always try to frame it not as a process, but as a mindset where it's really all about diverging and converging, no matter the project or the challenge. Because for me, the trick is that when you come up with a very rigorous, very specific step-by-step process, it's very hard to be one size fits all for all the projects.

And many challenges require a very personalized approach, depending on the team. Really depends on so many variables, such as team size, the deadlines, the goal, the challenge, the stack and stuff like that. So not always one size fits all process that is very well documented will fit in. So for me, double diamond would be the answer. Divergent, convergent thinking, no matter what's the challenge, I always try to make sure there is a space for learning, understanding,

and framing, then converging it into some sort of design brief, and then exploring again the options, diverging again onto different design solutions and concepts, and then converging again into some sort of

specific tangible design and off so the design process per se is something that we less designers love to talk about but yeah the trick is when it comes to working in the bigger companies how about you how would you define the design process how would you frame it and yeah how do you approach it usually

I would start by saying that I grew up as a designer looking at these very simplified, abstractized versions of the design process. You go through the first step, you empathize, and then you discover, and then you do this, and then you ideate, and then you test. And so there's always this linear representation that's just not true. The design process is rarely, probably never linear.

There is a lot of messiness most of the times. There's a lot of back and forth. You have to revisit some of the previous steps most of the time. So it's never this idealized version that we see on LinkedIn or Twitter or whatever we hang around. So that's my problem with talking about processes too much. And you made that point as well. It's different from one company to another, but even from one project within the company to another. So I might start unpacking a problem space from zero, from nothing,

And then I'm going to go on a different route than a problem that's already been, like we're just refining some feature that we already launched. So different problems, different times and places. It's always different. That's my point. So, and I think that as a junior designer, you do need to grab and occupy some structures. Like just know that you kind of need to know

where you're going, where you're starting, what's your next step. I mean, you do that all the time as a designer, even if you're a senior. But as a junior designer, I think you rely more on structures and on these processes in general. While as a senior designer, you get better at trusting the, let's say, educated guess intuition slash knowledge

your gut and you just do things because you understand what might be the most intentional or smart thing to do at any particular time in a project. You always need a plan, but you are able to articulate better plans as you move on in your career. So

What's the takeaway in whatever I'm trying to say here is that you start off by needing processes. And I think that junior designers have a fascination with understanding processes. From all my research as a junior designer and also as a senior designer trying to teach junior designers, I've learned that probably the one representation that will

kind of always makes sense is the double diamond. So you would just start by unpacking the problem space and then have some problem statements, problems that you want to solve at the end of this problem space exploration. And then you go ahead and unpack the solution space, diverging, throwing multiple solutions and then choosing the best ones.

or one. So that's the kind of mindset that I think we can keep from processes. And I mean, everything kind of makes sense. Even the design thinking process, sprints might be great in some setups, but they're not a universal solution for doing design. And they have a lot of downsides to them. So what I would do is like, even as a junior, I would take processes with a grain of salt

and try to think more about problems and solving problems, right? And how do you do that? It's not an easy question to answer as a junior, but I think it's the right mindset. Those are my thoughts around it. Do you want to add anything to that? Yeah, it's actually interesting because once you were saying that junior designers do need the process, and it's true that in the beginning, and we always preach it and discuss it, and as a trained interviewer,

design, I always talk and preach the double diamond. But when it comes to reality, it's never this polished, beautiful process. And it comes down to how you think. So it's always recommended that you start with some sort of framework. It guides you, it helps you, navigates you. But every time you try something new or try the new design process that is like

boxed out and you know what to do step by step, always reflect and try to critically think through why you're doing this. Does it even make sense? So don't stick to the processes as it is like written in the Bible and you have to follow it blindly, but no, really try to always critically think, do I even need this step right now? Do personas is something that we in this project

Or is it just something excessive and takes up our time and we better focus on ideating this time? So again, it's got to be easier and easier what you just said, Ioana, with the time, with the more practice you get, the more reflection you have and with more creativity.

critical thinking through the process. So it will be easier and easier for you to tailor each process to different projects. But yeah, it's recommended to start with those processes as a guide. And I was lucky to try out different types of those processes. For example, when I was a freelancer, I would always kind of try to mix both design thinking and design sprints. And then in a university and my companies where I would work, double diamond would be more common approach to it. Design sprints would be always like a

sort of here and there, like in startup context and then enterprises context. Good thing about the design process is that they always come up and there is always something new to learn and to try, but then it's up to you how do you understood it, how it went, how you reflected on this and how it really helps you. There is a chance it might not help you and then next time you're not even using it. So it's just process is like a tool for us to understand, to learn, to start using. Your thinking still is the core while the process is the tool that you hone in

and then hopefully use to navigate the project into a better, more structured and like you said, intentional direction. Yeah, I totally agree with everything you said. I would move it a bit into like, you've been lucky enough to explore different processes and you've had a room to experiment and try different things in different projects. So how do things typically happen in

in freelancing versus big companies, small companies, maybe just this triad of options, right? Agencies have a particular type of process. And I think it's very specific. I wouldn't go too much into that, but I'm very interesting. And I think the audience might be interesting to understand how do things differ between a startup, a big company and your own freelancing gig?

Yeah, I agree that let's probably focus on more product design specifics rather than agency when it's more like UX, UI or specialities. I would be actually coming back to the point that I made earlier at the beginning of our conversation was the fact that the bigger the company, the harder it gets simply because you would have multiple functions within your company and they all have their own processes, best practices, recommendations. They're all double diamonds or whatever. And they all want to follow it.

And so the process in which I was put in would always depend on that company. So when I was working in the enterprise companies, actually, I worked in two. In the first enterprise company, it was very much waterfall. And usually waterfall, it gives you the space for the classic double diamond or design thinking, if you wish, to go through all the stages.

So yeah, like the bigger the company, the more waterfall-ish it is. At least it was like this in my experience. And then the smaller company, the more agile they are. And I guess the agile usually correlates with the speed of development, with the fact that you always build and test and iterate and you go through those loops.

versus top-down, start, analyze, develop, test, put it out in a couple of months and stuff like that. So, right? It really depends on the context you're in. So, first enterprise was very much waterfall-ish and our process was super double diamond, but there was a lot of problems. And I think there's still a lot of hate towards waterfall

even though I feel like it's not the worst process in the world. But it works for the big companies because every department has their own turn and there are some crossovers for collaboration. But at the end of the day, everybody has their own process they could practice. And because there is not so much conflict in the collaboration, many, many departments would be happy

However, obviously, the typical critique is that it creates the sea-load environment, not enough space for collaboration, everybody's going through their own process, there is a lot of misunderstanding and misalignments in the process, and that creates this kind of hate for the waterfalls.

The other company I worked for was using, I believe it's called SAFE, which is like Agile for Enterprises. And that was interesting and new thing for me because I used to work with startups and Agile way of working, typical Kanban, was my way to go about things. And I thought like, great, Agile for Enterprises, that should work. That should be very iterative. That should be always build and test. I like it. Let's try it. So I started working in the SAFE environment and

And then very soon I've learned that it's also not the great process. In fact, I think it's the least productive process I've ever worked within the company. The company was a big organization, thousands of people, critical mass of which were developers. The developers would be then driving how things are built, what is built, what is picked up, how things are sort of prioritized and voted for.

And so for me, when I was going through this, because designers were like this shared service, we were centralized under design. So we had our design structure hierarchy. We were a small team. We had our product teams, but we were like one or two designers per product where

you know, we had like 50 developers and one designer. And so we were sort of a shared service depending on the project. We would just jump here and there. And because the developers were critical mass, it was very, very hard to build the case, to build the design culture, to build the sort of design maturity within that company. Even though our hierarchical department, centralized department within design was pretty mature, I would say. We had great processes. We have

really great designers, a lot of thinkers. The double diamond was really present and we had a lot of like design collaboration, but when it came to implementing it and making a case in front of the developers, sort of them making them picking these things up, it was very hard.

So for me, you can build whatever you want. You can build all the beautiful castles as a designer. If it's not, if your design unit is not strong enough, it's not presented enough, it's not, let's call it, have a seat at the seat table, it's going to be very hard. And unfortunately, SAFE put me as a designer in that position. And I remember it was just not effective at all. So yeah, like for the portfolio, the projects would work, but then in the product, it would never make a cut. And yeah, that was a bit of a trick.

And then recently, as I started working at Mews one year ago around, I was really interested in this new kind of how company is organized and works. So we work in the product tribes. Our teams are much smaller. We have a concept of product trios. So let's say one product department would have 10 people. Product trio would be consisting of PM, developer, tech lead usually, and then designer. And this product trio would

Always prioritize, do the research, kind of do the digging and prioritize what should be built. And as a designer, you always have the seat at the table, right? And that makes you as a designer be able to make a cut and sort of prioritize what is important for the product while you can practice your whatever process, right? It could be double diamond design thinking, whatever, whatever.

I started working in this sort of decentralized way when I'm a part of the product rather than the design structure. I was still in design structure, but I was more embedded in the product.

that give me a chance to make a case, to be heard, to kind of prioritize the right things. And that was much better. But now, as I'm working in this kind of environment, I am missing collaboration with designers. So I'm more cut out of the design culture, of the design process, of best practices we could all learn from each other, and much more embedded into like, what's developer doing? We're a little bit more agile. So we kind of follow the

Kanban. In Kanban, it's also tricky because it's very, very focused on development. There are two things about Kanban. There is an upstream and there is a downstream. And the Kanban downstream is when you pull those tickets, whereas the upstream is when you're shaping the priorities. So as a designer, I'm mainly working in this upstream when we're prioritizing things. But when it comes to everyday routine and guys like developers going through the tickets, it's very downstream and I'm usually not embedded there.

Long story short, there are so many processes, so many companies, so many ways of working. Obviously, when you're a freelancer, it's so much more agile. You just put your trail or Kanban process. You guys agree on the priorities, quickly agree or decide on things. Sitting in the same room, communication is easy. So you can follow your process and your small team could follow their process in your everyday sync. That's always the easiest part.

The hardest part is how do you implement the proper design process that is not hectic, that doesn't sacrifice the quality that is manifested in the organization and still keep up the collaboration between everyone. That's always the hardest formula to balance out. How about your experience? Sorry for taking so much time speaking about all those companies and their processes. No, I think that's great. I think it's what our listeners were hoping for.

A real life experience. Yeah, I want to do a short comment on an interesting article that I recently read by a designer Yamila from Instagram. And she has a very interesting article that I want to share in the show notes. You'll find it there. It's fascinating. It's similar to what we are sharing here and her experience working at Instagram and other companies, big tech companies.

and how the process happens there. I think it's a gem. So getting back to my own experience, things are pretty similar in big companies and very different in startups in similar ways, right? So in big companies, you typically have some rituals, some routines, let's call them ceremonies. For example, my work with ING Bank, we had design critique sessions every week. We met as a design team and we showcased our work and we would

get feedback from one another. Maybe we could work on some projects in design pairs and have two people working on a problem and so on. And so collaboration was very formalized in a way, but also very informal as well, right? We weren't just talking in the office all the day about design things.

We're working agile. I'm not a big fan of the development process and how it reflects in design. We all know that agile and design, it's a very controversial topic. I'm not going to go into it. But I think that in bigger companies, you kind of need structures because you have to ensure collaboration. So now I'm in UiPath. I've worked with them for a little over two years before I went on maternity leave. And then now that I'm back, I'm working on a project where I'm working with other designers as well. So I have

another designer I work with from Seattle, and we have a principal researcher helping us constantly. And we also work with a design manager and the VP of design. So we're pretty much a design team of five right now on this project. And it's very collaboration, especially across different time zones. And it's a challenge. It's interesting to find the right balance, the right recipe between how often do we meet? Where do we talk? Do we talk in

Figma directly in comments? Do we talk on Slack all the time? Do we just talk in the meetings? How do you control the conversations? Do we document everything in Jira? By the way, documenting is part of any design process, wherever you'll be going. Even if you're in a startup, you'll have to document your work in a big company even more so. So documenting is part of any process that's

Double diamond in the design thinking process, design screens, people don't talk so much about the importance of documentation and socializing, everything you're discussing, doing, and the artifacts that you produce. So those are an important part of the process and pretty common, right? So you will be producing things.

that facilitate design conversations. That's essentially what we're doing. We're creating wireframes and then everybody's talking about them, looking at them, thinking about them. And then you get to make the final decision because you're the designer, but the conversation is part of the design process.

So where I'm trying to get at is that I'll be very different. So a big company and a startup. I also co-founded a startup that I currently do design for as, let's say, a contracting role right now in terms of effort. It's different. It's different because I'm the only designer. I have to organize myself. It's hard to like be...

very careful about naming my layers and like collaboration. And then I'm more like in a freelance mood. So in a startup, you're more in a, like in a freelance position. I think startups and freelancing are in a way similar in the way that you are most of the times a design team of one, and you have to organize yourself. You have to find the right way of collaborating with

cross-functional roles and everything. In big companies, things are sort of laid out for you most of the times. Sometimes not, but most of the times you'll have some structures that you can tap into and blend into that process. So bottom line is that all processes involve problems and the way you unpack those problems, the solutions and the way you explore those solutions is

a big chunk that is the conversation around all of these things, and then a lot, a lot of collaboration. And that can happen in the shape of critiques or just things or weekly meetings or daily stand-ups or stigma comments. But that's what you'll be running into in most of your design roles. Conversation, collaboration, problems and solutions. That's the core of a design process. I think we can start wrapping up and maybe sharing our top three findings. Or if you have another question or point, now's your chance.

Yeah, yeah. No, actually I was just going to say, because I remember it and this is something relevant. Only last week on Friday, end of the week, we were doing the workshop called Let's Understand Our Design Process. So we have the unit called Design Operations, Design Ops. And they were trying to understand what each product designer that's embedded in the product trio or product squad, how they are treating their design process. How is the design process actually manifest itself?

What is interesting for me is that so we were having this exercise, we were mapping out every step, every collaborator, every tool, problems and opportunities around our processes. And as you zoom out on that Miro board we were using and look at every single product designer process, even though the framework under it was always double diamond, diversion, conversion thing, the process looked absolutely different for every single product designer. And that was so interesting for me because

If I looked in my process, it was like always linear, linear, and then a couple of like branches. And when I looked in other processes of different people, they would have like circles around and loops and like moving back and forth. And it's so interesting to see because if you even do this exercise and map out how you usually work in particularly your context, because context or organization always shapes things.

the quality of work, and sometimes even the quality of your thinking, you will notice that is really interesting. It will be always very different. And that's back to the point that even though we constantly preach our frameworks and processes, in the reality, it's always, always different. And if you map it out, you'll see how variable or diverse it could be. So it's pretty, pretty cool. We have started working in the new process that is called ShapeUp.

I believe it's the process suggested by Basecamp. There is a book around it or videos you can watch. It's pretty quick. And their key idea is that you have a product, it works, and then you start developing something and it's never ending and you never deliver, never develop. There is always the problems with the classic Kanban and Agile processes.

And the problem is that you never really build meaningful next features or updates or redesigns. And that's the process that structures you to work into six or three-week cycles. And by the end of the cycle, you must deliver something. So the collaboration should be very strong from the beginning. And then there's this cool-off period when you shape up the next priorities and kind of build the case around value for the business and for the customer.

And then again, very intensive six or three weeks period when you just design, build, quick, quick, quick, test it, collaborate, constantly communicate with multiple people, buy in, buy off here and there. So it's very intensive, but it's very interesting. This is the first time I'm going through this intensive six week

cycle. And it's, again, it's another process for me. When I'm looking at my design process, I'm still trying to squeeze in the double diamond. And even though you have six weeks in which you have to build something very complex, I'm like, okay, in the first three weeks, I'll go through my double diamond. How much can I afford to spend time on, let's say, research or validation and stuff like that, you know? So it's interesting. We're so dependent on the environment and so much in the context we're working with.

And the context we are working within that I guess I'm constantly circulating about this point that the design process we teach, we share, we talk about is fluid. And it always will take different shapes depending on the context.

in which it is on. That's my last point. I think we could have like an episode two on this topic, because I feel like we still haven't explored so many angles to this question. And maybe we should. But for now, I would say let's wrap up this conversation. I'm going to start sharing my top three findings, which are like essentially just the main ideas. As our listeners know by now, sometimes they're new. So they're not even like takeaways. They're like just totally new ideas. But in this case, I think they will be takeaways. So I just want to

point out that I loved your last point about fluidity. I think the design process is always different and it sort of flows based on the recipient that you put it in. So the recipient being the context, the team, the problem, the industry, the company size. So all the things that make up a context in a design conversation, that's what will

dictate the process, but you still have to be in charge of how things unfold. So I think that we should start thinking less about structures and more about intentionality. What do I want to get out of this process and this work I'm doing? What do I hope to achieve?

what is the problem we're trying to solve and what are the ways, the instruments that we have available? What can we do? So the thing is to reframe from just following blindly steps, which sometimes you might want to do as a junior designer because you don't really understand where to start and move into a mentality that's more focused on intentionality and problem solving.

And I think that's the first step. And then second two findings are that don't have too many expectations as to how the real world will be. Just come in with curiosity. I've seen designers struggle to reconcile some differences in like, of course, the expectations they have when they join a job or a company or whatever, and the realities of that job and role. And it's a

personal struggle many times. I've seen that. And I think that you should just learn to sort of adapt and come in with curiosity and don't expect too much clarity. So this is a point that we keep making in our podcast that as designers, we sort of have to learn to operate with ambiguity, to thrive in uncertainty and not knowing like we are

uncovering the unknowns. That's what our job is essentially. So just come in with curiosity and don't get too fixated on processes. So I even had an interview recently with someone in a very senior role, a leadership role. And they were like,

rolling their eyes when the conversation reached processes, like forget about processes, we're just doing work, right? But the thing that has to be there is intentionality, like what are we doing and why? And then the last point I want to make is that it really helps to learn the theory, really helps to read the different case studies, but the

one way you will understand most about how to make design decisions and how to thrive in whatever company you're going to work in is through experimenting on your own. So my point is that reading about design sprints is great. Reading about double diamond is great. It really forces you or exposes you to new perspectives, new angles, new questions. But the thing that will make you

better at articulating processes and just defining what path a project will take is just doing a lot of projects as much as possible. So process is practice, if that makes sense.

So those are my three random, totally random ideas. I mean, they're not random. Thank God they pertain to today's topic. But yeah, they might feel a bit messy. What are yours? I think that your points actually greatly encapsulate the whole thread of this conversation. I think I would only add to the processes again, the values of having the processes, is that I think processes...

is a great communication tool, especially when you work for the first time within the team or the company. They really help you to communicate how you go about solving problems, sometimes even educating your partners. So I would mainly look at it if you have an experience, if you know how to solve problems, like Ioanna said, intentionality, problem solving, really, again, problem solving, not checking the boxes, which is always the problem. And I understand it's convenient. We all want just to check the boxes. I went through that stage.

great it fits nicely into my case study that's all great however it doesn't really does the job it doesn't create the outcomes it creates the outputs and outcomes it's actually what solves the problem and helps your business company growing the second takeaway i look back into processes and i always try to think of them as a communication tools especially when i'm working with the new team i'm only trying to inform everybody what i'm doing why i'm doing but it

It's on me to come up with that process and to come up with that plan, right? I even think of the process as a plan. You don't have to stick to the plan in a rigorous way, but it's helpful to come up with it. It's helpful to create expectation.

expectations on how you're working, how much time it takes, and even helpful for you to plan your time. Because let's say now I'm working in this, let's say, six weeks or three weeks cycle. I really need to be conservative in my planning. I need to know how much time I actually have to do my discovery to understand the problem. Do I have a lecture of one week of doing it? No, let's actually spend three days on this.

sharp, finishing it by three days and moving on to the brief stage and kind of communication stage when I'm trying to create the alignment among all the stakeholders, right? So planning and process for me are almost equal and they help me to communicate, prepare the expectations so my partners also know when to pick up things, when things will be ready, when they will be communicated, when they have an opportunity to speak up and challenge whatever I'm working on. That's, I guess, the first takeaway.

The second takeaway, I don't even know if I have a second takeaway, but I would just sort of strengthen down on that point that process the liquid that you put into different cups.

depending on the cap, it will look different. There are so many variables that will define it. Coming back to the specifics of it, I will say how many people you have, how big is the company, how much communication you have to do, what are the deadlines, how big is the challenge, how many constraints do we have, what are the practices in that company, right? The more you ask mature company, the more collaboration you probably have,

the more collaboration you have with designers, with stakeholders, with partners, with, I don't know, support sales, et cetera, et cetera. It really would define your process. Maybe sometimes even inspire a process to come up with better results. But sometimes you work in a very hectic startup-ish environment

environment when all you have is one room sitting together, brainstorming quickly, whiteboarding together, quickly solving problem, no time for the communication and buy-in. You just push those pixels as soon as you come up with a solution or hypothesis that you want to test. So fluid, different, depending on the context. Don't expect to practice perfect

process in a rigorous way, check those boxes because it's probably never going to happen to you. Those bootcamps that, and actually my even course, that goes through the beautiful process, it's for you to try to experience, to one time go through the perfect process with all the box checked.

but to not stick to it. It's only for you to experience it. And then I guess that's my third takeaway for today. Experience it, but critically think if next time you need it, what actually this step gave you? Did it give you the insights you needed for that project or for that context? If not, now you know that next time probably for similar context, you won't need to use those personas, right? So yeah, like critically think every time, especially in the first couple of years of your work,

critically think of every single step you do in that process, and then start assembling your own processes from frameworks to your own kits when you create those recipes based on the project needs and the context you're in. I guess that's my last takeaway for today.

I just want to say that I love the idea of a toolbox. So processes should be just that, a toolbox of things that you learn how to use and combine and pick and choose based on what you're trying to achieve. So with this final idea in mind, I want to invite everyone to rate our show, send us messages with whatever ideas for future conversations you have or problems you're struggling with or interesting questions. We want to discuss things that are relevant to you. Don't forget to rate us and follow us on Instagram, honestuxtalks.

And yeah, we're here to support you and super friendly. Thank you so much for joining and see you in the next episode. Bye-bye.