We're sunsetting PodQuest on 2025-07-28. Thank you for your support!
Export Podcast Subscriptions
cover of episode #58 Should designers learn how to code?

#58 Should designers learn how to code?

2022/9/28
logo of podcast Honest UX Talks

Honest UX Talks

AI Deep Dive AI Chapters Transcript
People
A
Anfi
I
Ioana
Topics
Anfi: 在成熟的设计团队中,设计师通常无需进行编码工作。但在小型创业公司或自由职业项目中,设计师可能会被要求进行编码以节省成本或满足客户需求。清晰地界定设计师的角色和职责,能够避免不必要的编码工作。了解编码能使设计师更好地与开发人员合作,提升沟通效率和说服力,并能更快速地进行原型设计和实验。 Ioana: 早期设计师普遍误认为需要学习编码,这源于市场不成熟或以自由职业为主的背景。在市场不成熟的时期,设计师的角色定义模糊,许多设计师同时承担设计和编码工作。在成熟的设计团队中,设计师通常无需进行编码工作。但学习编码可以提升设计师的自信心,并使其能够更独立地完成项目。在构建设计系统时,了解编码能帮助设计师更好地与开发人员沟通协作,并做出更合理的设计决策。了解编码能帮助设计师更好地理解开发人员的工作流程和限制,从而做出更有效的设计方案。 Ioana: 初入行的设计师不应过分关注编码,而应专注于提升设计技能。在掌握核心设计技能后,学习编码可以作为提升自身竞争力的补充。不同设计领域对编码技能的需求不同,例如市场设计可能需要编码技能,而传统的UI/UX设计师则通常无需编码。设计工具如Figma正在逐渐融合设计和前端开发流程,未来可能实现一键生成网页,这将改变设计师对编码技能的需求。

Deep Dive

Chapters
The hosts discuss the common fear among designers about needing to code and whether it's a necessary skill in the current design industry.

Shownotes Transcript

Translations:
中文

Many designers feel intimidated by developers and the developer might say, oh, we can't do it like that. It's too expensive from a technical standpoint. But then if you have an understanding of what goes into that solution, you can counter argue that and it becomes a conversation. It becomes a negotiation and you basically end up having more design power or more persuasion power.

Hello everybody and welcome back to Honest UX Talks. My name is Anvisa and I'm joined today by my lovely co-host Ioana to talk about do designers need to code? Very classic question. I'm pretty sure if I google right now this kind of query in the Google search, I'll find at least thousands of different answers to this question because it's a very common question. It's one of the fears many entry-level designers are like.

Just even people who are trying to transition to design are asking themselves. It's a common fear that you will have to code. I myself was also worried that, ooh, you're transitioning to IT speciality. Maybe you'll have to start coding. I'm not good at this, et cetera, et cetera. So let's try to dive into this topic and figure out if that's true or it's a myth. And do we have to worry? And before doing that, I'd also like to mention that the sponsor of our podcast is Figura.digital.

Some of you might already know about it. We recently recorded an episode with Dennis, the founder of Figura, and we talked about the common mistakes of junior designers trying to apply for work. Make sure to check it out as well. But for those of you who doesn't know, Figura Digital is the most UX-friendly network and freelancing platform for designers. The magic about it is that they are doing all the hard work with much making you with the companies that are looking for your particular design profile. If you're struggling with finding the

perfect company you're doing a lot of homework checking out the companies reading about them seeing if that's something you want to do basically all you have to do is just do the reflection exercise once discuss it with figura and if you're right fit they will find the perfect company for you and that will be it

So let's get into the topic of today's or maybe let's also quickly check in with each other. How are we doing, Ioana? I don't think we did it for a while now. Yeah. So first of all, hi, everyone. Hi, I'm Fissam. I'm happy we're having the conversation today for anyone who's wondering. It's Sunday, so it's a pretty quiet day for both of us. So that makes me a bit more tranquil or calm than I usually am. But yeah, I think for the past couple of weeks, I've been pretty not stressed out, but very tired. I

I think it's because the end of the year is approaching. And like always, I've had a lot of things on my plate for a long time. So that made me quite, I think, overwhelmed for many parts. And I think it's really interesting that I've been doing a lot of self-reflection. And I realized that I don't have a lot of clarity when it comes to what I want to do next. And I remember very clearly that when we started this year and we were talking about the goals for 2022, I said that the keyword for me is going to be focus. And I think I failed.

but that's for an episode that we're going to say, maybe say, yeah, but I mean, it's end of September. So I think I can, I can start being honest about it. I feel like I have that clarity and I feel like I really have no idea what would be next steps in my career, what,

the next steps in my personal projects. I don't even understand very well what makes me happy anymore. So I think the keyword for me right now is confusion, which is pretty much the opposite of focus. But yeah, these weeks I'm working on building clarity and doing a lot of sketching, writing, introspection, self-reflection, and so on. That's where I am. How about you?

Thank you so much for sharing this moment of reflection. It's not often that we do it. But yeah, like you mentioned, today's Sunday, so maybe it's the right context. For me, it's actually getting better because tomorrow I'm going for vacation. I didn't do the vacation this summer. Actually, I did like long weekend for four days, but it's not a proper vacation. The proper vacation is starting tomorrow. So I'm really happy about it. So I'm going to Sicily. And literally what I did is rented a villa to do nothing.

So we will see how it goes. Some of the things I still want to do there is to reflect on the discovery I was doing for the last two months. Like I mentioned, I think in a few previous episodes that I started kind of just not even working, but just doing the discovery on the new course. I might do, might not do. We'll see how it goes. Yes, I was doing a lot of interviews with design managers, as well as people trying to search for design jobs.

I'm trying to understand the common problems and common needs for design managers and what they're looking in the candidates. And so I have a lot of insights. I have a lot of notes. I have a lot of kind of like mess of information around me. And one of the things I want to try to do during the vacation time is to kind of organize it a bit. Not that I will have a clear structure because I definitely need to rest. But at the same time, I want to at least embrace the mess I have.

Let's be more realistic. I will not be able to clearly build a curriculum just yet. Other than that, it's all right. I think I still have some struggles. Maybe I'll talk about my current work in the future, but I am not ready to speak about it just yet. Processing a lot of information. We'll see how it goes. But yeah, most importantly, tomorrow I'll go for a vacation, so I'll not think about work.

No, I mean, I just returned from a two weeks holiday. I typically have like three, four days holiday. So it's been a long holiday for me as well. And I think we can be pretty successful at not thinking about work, but not in the initial days. So I think you need one week to stop thinking about work. And then the next week you're not thinking about work and then you start thinking about it towards the end because work is approaching. So it's essentially you might hope for a couple of days of quiet. Yeah.

It's exactly what my husband says. Every time we're taking just one week of vacation, he's like, oh, damn it. It's a six day and I just started having the vacation and tomorrow we have to come back. Very common problem. I usually need like two, three days. So I hope I can make it in one week, but we'll report back on this next week. Anyways, let's talk about coding for designers. Let's start with something like very far distant and talking about your expectations when you were transitioning to design.

Was it one of your fears? Was it something that you thought you will have to do when you're just getting started? It's a really interesting question because it gets me to reflect on the early days of my design career. And I remember something that I completely forgot that in the early days, I started by learning HTML and I thought it's a must have. So I wanted to be a UX designer. So I started learning how to code. Thinking about it, I'm not sure what got me on that path.

But I think it had to do something with my design mentor at that time, who was a person who had been in the design industry for 20 years. So they started doing design in 1995 in a market that wasn't very mature. So that we're talking about the Romanian market where things weren't as established or as healthy as in the U.S. market. So for them, a designer would also need how to code. That was their definition of a designer.

a web designer, basically, right? And many of the UX designers at that point, they were just web designers who are building websites and then started rebranding themselves as UX designers as per the market trend. So that was my initial understanding that I have to learn that as well. And it was pretty discouraging because I didn't particularly liked it and I didn't feel that I was making good progress and it felt pretty...

It felt pretty technical and it wasn't exactly what I was hoping for, like talking to people and being close to the more psychological part of things. And yeah, I made that, if you want, mistake. It's not an absolute mistake, of course. We're going to go into it later. But in the beginning, I thought that I had to learn how to code. And I think it's still a pretty common confusion point in the market. Yeah. So that's how I started. How about you?

Agree, totally the same. I think it's definitely a confusion because in those markets that are less mature, like you mentioned, or maybe that are more outsource driven or freelance driven, like the freelance in terms of, oh, we need somebody who does everything. So no, definitely not the design mature business. In those contexts, indeed, it

Could be some of the misconceptions there, I guess, is that some clients would reach out and ask you to do everything because they just want to say, right? That sometimes still is happening. I can see some people are saying it's our business. We need to make money. So we need to do everything. And you want it or not, you have to do it. But honestly speaking, I do think that it's less of a trend right now. The different side of the story is that I'm seeing that design market, design tools are becoming more and more front end oriented.

which is a different topic we can talk about a bit later. But coming back to the original question is that I had a fear. It was like 10 years or something around 10 years ago. And back then there was not too many resources. So the problem was different than today, right? You have too many resources today. Back then it was not enough resources and there were just few articles around it. And UX as an industry was not even defined well yet. And so half of the designers out there were like front-end developers being web designers. So they would draw something in Photoshop and build it in HTML CSS.

and then the other half of it were like those I would call it visionary designers who are thinking double diamond who are thinking very much like innovation how to revolutionize the world apple style and stuff like that so those are two camps I have seen back then I didn't know which one to stick should I do both which one to go for so one thing is I started doing design because I accidentally enrolled into the program called product design and we did not have any coding classes we did

all the design thinking kind of workshops and stuff like that. And so from one side, I was like, this is a design, right? I'm learning it. So this is supposed to be a design when we have tutors that were practitioner designers. But at the same time, you open internet and everybody tells you you should code. I was slightly confused and I didn't want to code. I had like a very strong, not to say manifesto, but I was like, this is not for me. All my life, I was saying, I'm not going to be a technical person. I'm very bad with technical stuff. So I'm not going to do that. I'm going to do my design thinking stuff.

And so I was sort of denying it. But luckily, in Estonian market where I was located at that period, it was not even requested much. So internet tells you one thing, but in reality, I would see a lot of clients reaching me out, asking me to do basically no coding. That was a good thing.

So at the end of the day, I never did it. And market like drifted me towards never doing it. But I still had a little bit of an imposter syndrome thinking that probably I'm not qualified enough designer since I don't code and probably need to do this at some point. I probably need to take courses. It was always in the back of my mind that, you know, I have to learn how to code.

Let's dive deeper into what happened next. So you started working or we are transitioning towards design. What's the reality? Did we ever need to code? Was it ever your reality that somebody asks you to code whatever you designed? It wasn't. It

It wasn't because I feel that I've always been lucky enough to work in pretty mature design teams and in a setup where the design role was well understood. And I feel that there were some moments, especially when I was doing freelancing or when I worked with early stage startups as a consultant or as a designer sometimes, that there was that

understanding or preconception that the designer does everything and they also build it. So I remember when I started working with one of the startups that I've worked with for the past couple of years as a side gig, for them, it came in as a shock that I'm not also building the things that I'm designing. For some people, it was outside the design space, right? There's still this misconception that designers are the ones who also build things. But inside the design world, I don't run into that.

And even when I'm dealing with the situation where somebody would expect me to code on a side gig or freelancing project, it's pretty easy to clarify things and show them that they also need a front end developer or a developer to help them bring that solution to life. And then I spend more time trying to show them the value of what I'm doing, which is not building.

but it's obviously designing. But what does it mean to design? So that's something that whenever that comes up and I feel like, oh, maybe they're expecting me to do more work and I'm not delivering on that pillar as well. And then some people might start to feel bad, like they're not doing enough. Then I move the focus on here's what I do.

And then I show them the research process. I show them how we ask questions in research. I mean, not in an interview, but the research questions that we ask and how we try to unpack hypotheses and try to de-risk the work that we're doing. So, and then they understand the value of design pretty easily. So once you get good at articulating what it is that you're doing, then

nobody will be, ah, so you don't know how to code. I'm not going to hire you. So I didn't really need it in my work, but I have to admit that I've seen designers that have pretty good grasp of coding and some of them could code. And it really came in as an advantage. And I don't know if now is the right time to dive deeper into that, but I'm going to go ahead and do it. It can be a big advantage from multiple perspectives. So the first one is that you are

a better collaborator to developers. You get to speak their language, you get to understand what goes into their work, and that makes you more empathetic, as little as I like that word, but it makes you more understanding of what the people on the team are doing, and it helps you communicate better with them, right? So if you're able to speak the same language, have the same vocabulary, have a similar understanding, then it's easy to get your ideas across.

and even negotiate sometimes because developers will push back on many things that you propose. And if you have a basic understanding or a pretty good understanding of their work, then you're able to kind of challenge that, right? Many designers feel intimidated by developers and the developer might say, oh, we can't do it like that. It's too expensive from a technical standpoint. But then if you

have an understanding of what goes into that solution. You can counter argue that and it becomes a conversation. It becomes a negotiation and you basically end up having more design power or more persuasion power, right? That was one thing. And then another thing was that sometimes even with personal projects or side gigs, so not in a big company where everybody had their role established, I've seen designers that know how to code be able to

experiment quicker, sometimes even prototype their solutions in high fidelity. They were more comfortable experimenting and putting things out there. So because for them, it came more natural, right? If they could also build the things that they were designing, it was like there was a speed there and a

courage, if you want, that I've observed these people had. So I think it's a strong advantage, but it's one that's pretty costly to acquire. So I wouldn't spend so much time learning something that's difficult to learn. But if you have that knowledge or if you're passionate about it and want to invest more in it, then it will definitely be helpful. Yeah. So sorry, I think I answered questions ahead of time. What about you? Did you ever need to know how to code?

My answer is also no. It was just my fear that I still have to, I still probably need to find courses. And I did sometimes do some workshops. I went to a few, not to say podcams, but like quick offline courses where you would have to sit for like two or three days and do a quick project.

And it was empowering, but at the same time, I didn't get a hang of it. So it was just, look, look what I did. Like a little baby showing the first pictures they did for the mummy, you know? So I never been asked to do that, but I still felt I have to. I agree with you. In the beginning, I did work with a lot of startups. And of course, some of them need to save money. They don't have much investment. So they would ask, oh, maybe you can also code it and it would be great. And, you know, they would look for ways to save money. And apparently it depends how you position yourself. It

If you position yourself like, I don't care how I just need to make money, then maybe you will end up in a position where you will try to do both, right? And it's tricky because if you're embracing two specialities or two industries at the same time, you'll learn slower. It definitely are the industries that you will benefit from both in the future. But if your goal is to find a job and develop speciality and professionality in one of the areas, it's better to focus

wasn't one and only once you establish foundations if you build your confidence and you know how to solve a problem as a designer using design tool set and knowing how to build things then you can add extra specialities or deepen your knowledge in one or another extra things that will make you a better designer but it shouldn't be a

parallel thing that you're learning because then you will be learning two different areas and it's better to be pro at one to start from at least to start making money and to start being confident as a professional and then you can definitely expand your horizon in my work even with the startups I was like you when I was trying to articulate what I can do better so here are my core strengths I

I can help you with doing the research, understanding the business, building the product strategy, quickly testing concepts, workshops, you know, all of that stuff. So I would more position myself like not the pixel pusher, but like, hey, I would be a rather strategic partner for you. And if you're looking for somebody who will be building things, let me find somebody who can do it better than me. And that was working. Or otherwise, I would just say, I'm not the right fit for you. And that is okay.

Coming to the topics you were also trying to start and elaborate on was the value of knowing how to code. So for me, it was kind of similar. I agree with you that it's a huge benefit knowing how to do things. It's definitely a conversation or open there. So I did a few startups and I was doing it mainly with developers. And when I would sit next to my colleague or co-pilot,

partner in a startup who would be a developer and they would sit in like in front of five monitors and do a lot of like metrics coding I have no idea but I see metrics numbers for me it was like magic I had no clue about and I didn't even try to understand it now moving forward now I

see that I was a miss on my side because of course I would probably try to have a conversation to some things or at least ask what's happening there. So if I would be more curious, it would be better if I would start understanding what is he doing? How is he doing it? It doesn't mean that I have to do it or even that I have to fully understand it, but conceptually I would benefit more by asking questions, especially since I had a lecture of sitting right next to my developer co-founder who knew much more than me. But

I think only after four or five years being a designer, I started being more curious. And maybe I worked through my imposter, I guess, and built some confidence in design. And then I had my mind space open to new things. And that's when I started exploring Webflow. And I needed to build a website for my course. And definitely it was a bit of a struggle because Webflow is one of the tools that it's not that Photoshop and you're throwing circles, but you do need to understand how to build stuff

It's fundamentally the same thing in your building or flex boxes there, right? And you have to know how to build the website at least conceptually so that you, based on that structure, can start throwing circles and boxes into your Canva. And it took me a while to understand how it works, but I figured it out on my own. And once I built my first website, I was like, whoa, I've just learned something new. It was like cracking it.

And at that moment, I started working at the company called NCR. And we were doing a huge design system project that I was leading. And that was the moment when I realized it's a huge benefit for me understanding how things are built. Because building a design system, it has a huge crossover with coding. Because whatever components you're proposing, you will need to have a discussion with the developers. You will need to understand the fundamentals, the

The tokens, the tokens will be shared with the developers. Tokens meaning like small things like colors and typography and spaces and shadows and stuff like that. And then you start building together the components and maybe the breakpoints and the layouts and stuff like that. And there it's when you start having a lot of, not to say conflicts, but yeah, there will be moments when you will disagree on things. You would have to say for design it's better this because we need to make it scalable, etc., etc.,

And then they would start saying, but it's longer, it's more complicated, let's do it quick and dirty. And if you don't have an understanding how they build things, you will not be able to rationalize or articulate the need for why it is important. Not always the developers will be signed on to the user needs.

or even if they will be, they will still say, oh, but we need to build it quickly. So just like hack it and let's not do it right now. And again, if you know how they build it, you might even think of better ideas on how to do it sustainably. How about we splitting it up right now? Let's make the first version that will be aligned with our vision. It's cheap for you,

but it's also aligned with our needs. And so you will start being able to have the rational conversation, just like you said, Ioana. Yes, long story short, from my experience, I was a bit scared of the whole coding thing. Luckily, it never came up. Or even if it came up, I did say probably I'm not the right person for it.

And when I realized I was missing out, I started doing some side projects with Webflow. And that's when I realized it definitely gives me great benefit because I don't think I will be able to pull off the design system project we were doing for one year, which was like 100 developers and two designers kind of team. I wouldn't be able to push for the decisions we did if I were not able to articulate and understand how they're doing things there.

Why else do you think designers maybe could benefit from understanding how to code and maybe in which applications we can benefit from knowing how to code? I think you touched on some of the points that I also had in mind and wanted to mention. I think I would build on the story that you shared with us that it felt very empowering when you built your first website and then

It also has to do with the confidence that we have as designers. So when we explore new areas of the design work or just the work of building products, so if we understand some product management, if we're able to, I don't know, build up, let's say, minimal website, then there's that win.

in our self-esteem as designers that helps us be more confident and helps us feel that, hey, we could do anything if we set out to do it. So that's a great win that I feel it's not perceived as direct, right? So you don't think communicating better with developers is something that feels in a way more tangible than the benefit that the boost that your self-esteem gets when you learn something new. But that's also applicable for anything, not just coding, right?

And then another thing is that exactly like you've mentioned, I think when it comes to building design systems, this really reminded me of an experience that I've had in both of my full-time roles. So I've worked for 10 years with ING, not all of them as a designer, just the last couple of few years. And then for the past couple of years, I've been with UiPath. And in both of my permanent roles, we were building design systems. And that's where

Things got sometimes very tense with the developers and for established engineering teams where things were done in a very efficient way, if you want. The design system didn't really come as a win. It didn't really come as something that would revolutionize or help them. It felt like we're just going to do a lot of work for something that we don't need because we're doing things in a certain way that's working. And for some parts, they were right.

But there were also some, let's say, more fine tuning kind of wins, more sophisticated kind of wins that if I feel that if I would have had a better understanding of their work, then I would have been able to advocate for a design system and be able to tap into the things that might still be pains in their workflows. But I didn't have that understanding. So our debates were very long and very intense, but most of the times they were more philosophical.

They were more abstract. They were a bit generic because I wasn't able to go in the weeds with them and kind of show them how their work would be impacted very tangibly. Right. So that's also a setup in which understanding how their work works would help you. And I

I think just in general, like having the confidence that you can rapidly try something. Like I said, it's that feeling that you're independent in a way that you could do everything in the design process from the discovery word to actually building and implementing your solution. I think that's a

feeling that would empower anyone. I've seen designers that start building their own products or have their own side projects, passion projects, and so on. And that's where they get to do everything. And for some parts, it's scary. It's frustrating. It's inefficient, if you want, because you'll never code better than someone who does that for a living. But for most parts, it's just empowering. So I think that's something that we're missing out when we're not exploring this area. Yeah.

Back to our favorite conversation topic, design market terminology and confusions. We have a lot of specialties in design, right? When you're just transitioning to design, you're thinking everything is user experience, and it is actually. But then as you start working as a designer, you develop specialties and applications. And you can be a product designer in a product company. You can be a marketing designer.

be the product company or agency. You can be a web developer, web designer. You can be just as simple as a freelancer, contractor who is working with top-notch clients, et cetera, et cetera. And it really depends on the context. So I think with me and Joanna, we are mainly referring back to the classic UX designer title that works a lot with discoveries and conceptualizing and validation, so design thinking stuff. But then there are also other contexts like marketing design, right?

In my company, for example, we have a marketing design department. We don't overlap with them a lot, but they create all the marketing materials and that includes web pages, mini web pages for different events and stuff like that. So I don't exactly know how they work. I don't want to kind of mislead anyone, but I know that in some companies, I've seen that marketing designers would actually use Webflow and other coding tools for building websites. And so in that regard, they first design things and then they build themselves, especially if you're a

web designer, you position yourself as a web designer on the market. And if that's something you want to do, you can actually do coding, but that's your choice. That's your positioning. We're talking about the classic UX designers on the market, your classic UI roles. In that context, if you see in the role description a requirement to code for us, it would be a red flag because it's not something that

classic designers do. But again, if that's the speciality, like marketing designer, UI designer, design system designer, that could be a part of your role. Something for you to discuss with the company you're applying to, if that's the role. Now, I also would like to talk about the market today, right? So we have established that for like classic UI designers and product designers, coding is not the part of responsibilities and you rarely will be asked to do this unless you want to volunteer and make it a part of your

of your job or your maybe extra strong skill. But one thing I couldn't help but notice is that today, if we're thinking about tools like Figma or Adobe, should I say right now,

When we think about the design tools we're using on daily basis, more and more I can start seeing that at least Figma is moving into the direction of merging same structures, right? So in Figma, we all probably use auto layouts, which maybe you disagree. But as for me, very similarly, it reminds the flexbox approach. And it may be it's me overthinking stuff, but I have a feeling that they try to at least like progressively...

unite how we design things with how the front end works. So maybe in the future, it will be just the same platform. And then once you design things in Figma, it could be with whatever one click or few tweaks be able to be converted into the web page or anything. So I'm curious, do you think that our classic design tools will soon become web design tools in general? Do we have any progression in that direction? Or is it just me overthinking that AutoLayout is the next Flexbox?

No, I think you're right. I think it's an interesting point that I didn't really give much thought to. I'm not an expert at understanding the design market trends, but I do feel that what we'll see more of is more autonomous, independent designers. So tools that facilitate us becoming more and more independent and independent.

Examples are even AI-based tools like UI Wizard, where you simply draw some sketches and then it automatically turns it into high-fidelity design based on a style guide. So this is something that we'll see more and more of. And I think the future, from my perspective, is just that we'll design and then it's going to get built automatically. This is where I think we'll get to eventually. So that will kind of make some progress.

of the jobs that we have or some of the parts of our jobs a bit redundant, but in the same time, it will create new possibilities, new opportunities. And then eventually I think people will be able to build anything like with the low code or no code tools that we have today, which in a way democratize web design and web building. I think designers will be able to achieve their solutions quite quickly for simple projects, of course. So if we're talking about a complex product, a B2B product,

enterprise and all the systems that need to communicate, we won't be able to translate that into a workable solution easily, like never, or I don't know, not in the foreseeable future. But for smaller projects, like for building your online shop or designing something for your side project, I think that there's going to be a very blurred line between where we stop designing and where others start building or where we start building. And so I think it's going to be more

streamlined if that makes sense. I think that's where we're heading to. And I think it's possible today as well, but we'll see more of that. I agree. I think also even design system tools today are starting to blur the line already with like some of the common approaches or at least even the tools I see that try to make it one space for all and one click merge or something like that where maybe in the future you don't even need to do the

click it's all the same system that would be very interesting to see but I'm just I think I'd ask this question to the point that maybe there is no need for us to worry about learning code understanding it building stuff and stuff like that because maybe in the future whatever you do even in Figma or Fido and Figma it's

it's going to be already very similar patterns that you do or that you have to embrace in the coding. And at some point, you will not even see the difference. So maybe today is still a fear. Maybe it's legacy of previous decade. But in the future, moving forward, I do believe maybe it's not even going to be a big thing. And we will be thinking alike with developers, with the front-end developers particularly, with the back-end that's slightly different. But who knows?

Maybe, again, I see the tools like Bravo also making it very accessible for designers to experiment with databases. Anyways, I guess we discussed interesting points. So maybe let's dive into the takeaways for today's. Would you like to start? Let's do it. Yeah. So I think the main takeaways would be that I'm going to start with a conclusion, right? A general conclusion. No, you don't need to learn how to code. Designers aren't supposed to be asked to do that. So you can definitely push back on those kinds of requests. But again,

It's an advantage. And I think we've explored different facets of why it might come in handy as a designer and how it can enhance your work and enhance your capabilities and even mindset, right? If you want to grow as a designer and you feel, of course, there are so many things that pertain to design only that you can learn and improve.

learning is never over. You're never going to find yourself saying, OK, now I've learned everything about UX, so I can start learning how to code. That's not going to happen. But it's an area that's interesting to explore. And I think especially if you need a boost in terms of experiencing that beginner mentality, the beginner feeling when you start something completely from scratch in a way where you don't know anything, that you can have that experience, that learning and growth experience by exploring coding. Yeah.

Another takeaway, I also feel that I really loved our last part of the conversation where we're talking about the blur lines between design and development. And I think for many moments of our careers and even in the history of the design industry, I think things were sort of in a competition or there was like these two sides that were not in conflict, but in an interesting, sometimes even healthy tension. But now I feel that

we will see more and more of that cooperation and that streamlined flowing kind of experience where design and development are merged and sometimes directly, right? So yeah, I think those are the things that kind of stick out for me. What would you want to add to that?

I think in my case, like you said, right, it's an advantage. But I think one thing I want to clarify or make it a takeaway for me as well is that, and maybe this sounds controversial, but don't get distracted by coding in the beginning of your career. Because if you think you have to know how to code and you spend a lot of time obsessing with, I need to know how to code because that was my obsession. I thought I need to do it.

You take away the energy that you could spend understanding design. If you want to be a designer, maybe first understand how to be a designer and become a designer. And then, yes, you could make it an extra advantage or benefit to your portfolio on skill set by knowing how to code. But that's not the core. It's definitely not something you will be doing in a normal...

pretty UX mature environment. So don't get distracted by coding in the beginning, but if you work with developers hand in hand, make it sort of an advantage for yourself and ask them questions if the opportunity comes. Also in the beginning, you will be spending a lot of time maybe like embracing the complexity working with PMs and design leads. So there will be a lot of things for you to handle and just adding coding to that

I guess, backlog will make it slower for you to embrace it. Because, you know, coding also requires a lot of, a lot of time spending and understanding the concepts and practicing it. I will just back up Joanna's answer is you don't have to code, but once you feel confident and ready to explore new specialties, so to say, feel free to do this. I think you will definitely not regret spending your time on it.

once you know how to use it and it will be a great addition to your articulation portfolio or whatever package. Other than that, it's not a takeaway, but an important thing to remember is that this industry is still figuring itself out. It's not established yet, not regulated.

And so in some contexts, be that marketing designer, the design system designer, web designer, you might be asked to code. And if that's how the company works, that could be it. But again, do the reflection for yourself. If that's something you want to do, then maybe focus on other specialties in design. If you're not, if you're like me and Ioana, we were not very interested in being the developers.

We never really embraced it in the beginning. So maybe then pick the line for yourself and that will help you understand do you need to code or don't bother about it and don't start with it. So that would be my last takeaway for today. If we have nothing else to add, then I'll just wrap it up and tell you thank you so much for listening through this episode. We really, really appreciate the time you spent listening to it.

If you have any questions or hardships in your current role, or if you're transitioning to UX design and have specific questions, don't hesitate to ask us. We have Instagrams where you can DM me or Ioana. We have also Honest UX Talks page. So feel free to reach us out. Otherwise, you can also submit your questions in the Spotify stickers under this post or under this episode.

and in the anonymous forum in the show notes. So pick any anywhere where you want to submit your questions, just do it. It's definitely makes this podcast more valuable for you because if you have this question or problem, most likely chances are that somebody else has the same problem and it's worth discussing it. All right, that's it. Thank you so much. Don't forget to check out our sponsor and we will see you on the next episode. Bye-bye. Thank you. Bye.