Should designers learn to code?
What happens when designers get closer to the code behind their work? A conversation about design engineering, collaboration, and the future of UX.
Hosted by Nick Mann
TO PRODUCT.
From design to the real thing.
Think beyond
the handoff.
Understand how your designs get built.
Technical understanding can help designers judge feasibility and have more useful conversations with developers.
Explore design engineering.
Frederick describes a design engineer as a designer who works in code, creating things like coded prototypes and production-ready work.
Keep talking to users.
AI can support research, but it cannot replace firsthand insight into people and their context.
Learn one useful thing at a time.
Choose a tool or skill that helps you do your work better, and give yourself room to experiment.
Good ideas deserve
to make it through.
A design can look clear in Figma and change considerably before it reaches the people who use it. Deadlines, technical constraints, and decisions made during handoff can all shape what eventually ships.
Frederick Andersen, founder of Copenhagen-based design engineering studio EDL, joins Nick Mann to explore how designers can work closer to development and what design engineering looks like in practice.
They discuss whether designers should learn to code, how teams can collaborate more effectively, why UX research still matters as AI tools improve, and how designers can keep learning without trying to master everything at once.
“A design engineer in my mind is a great designer who works in code.”
FREDERICK ANDERSEN / Founder · EDL
Explore the
conversation.
From design handoff to working with code and AI.
- Frederick’s path from development into design
- What gets lost in the design handoff
- What design engineering means
- Should designers learn to code?
- Research, design systems, and AI
- Presentation skills and collaboration
- Learning new skills without getting overwhelmed
- What Frederick looks for when hiring
Frederick Andersen
Founder · EDL
Frederick Andersen is the founder of EDL, a Copenhagen-based design engineering studio. He began his career in development before moving into design, and now helps teams connect design decisions with the products they build.
Resources mentioned
Design engineering
Bringing design thinking closer to implementation through work in code.
Design systems
Shared components and guidance that help teams build consistent products.
UX research
Learning directly from people to understand their needs and context.
EVERY WORD, AT YOUR PACERead the Full Transcript
This lightly edited transcript is from an earlier version of the conversation and may differ from the final audio.
UX Growth Podcast:
Frederick Andersen Interview Transcript
Lightly edited for clarity. Wording and meaning are preserved as much as possible.
Nick: Hi, this is the UX Growth Podcast, a podcast that helps people learn and grow in the UX design industry. I'm your host, Nick Mann. Today, I'm joined by Frederick Andersen, the founder of EDL, a Copenhagen-based design engineering studio that helps teams to close the gap between design and production. Thank you for being here, Frederik.
Frederick: Thanks for having me, Nick.
Nick: Yeah, so let's begin by how did you first get into design?
Frederick: Oh, boy. I got into design, let's say, 16 years ago, roughly, and my entry to design was actually development. I, uh … the classic, uh, runaround of family members or friends needing websites, and you being the IT person in the group of people. Making a website was kinda, a thing you, you- … learned th- through just simply having to do it, honestly. And so increasingly you made more and more websites, and then you figured out that some websites also need to look a certain way, and maybe they needed a nice logo for that company you were working for, or you had to make some design decisions, essentially- as the developer making that WordPress website. So my transition into design was actually, um, not knowing that design was a profession really, and at the age of around 20, I got my first, my first gig as a digital designer at an agency here in, here in Denmark. Uh, so development was actually my entry.
Nick: Wow. And how did that progress into building your own design studio?
Frederick: Well, I, throughout my career … eDL has existed for five years, uh, roughly, and I started it five years ago, um, because the, the handoff— I talk about handoff a lot, but the handoff from design, being on the outside working with some exciting tech companies, giving them some, uh, design files in Figma, some pixels specced out, annotated very nicely, uh, handing it over, and then, hoping for the best to some extent because you're on the outside looking in. And I was kinda sick and tired of that, to be honest and I thought- … maybe we can look at it from a different perspective or just establish a studio which is, has some very core beliefs and stick to them in terms of how they work and the kinda work they wanna do within design. And that's kinda where things kicked off for me, honestly, and then I moved to Copenhagen to start it, a bigger city here in Denmark. Um, but that was the, that was the initial, you know, frustration of, of seeing my design work not really getting translated into the hands of the users the way I wanted it to be translated.
Nick: Hmm. Ca- can you go a little deeper on that? I'm very curious to know what are some of the things that other design teams are just not doing a- as well as you would like?
Frederick: For sure. For me, I can speak from my own experience. So I've, I put a lot of effort, of course, into maybe some initial user research, figuring out who are we designing this thing for. Uh, that turns into some, hands-on design work within, uh, Figma first. There could be wire framing turning into product design, fully fledged annotated design ready for handoff. And then no matter how much effort, uh, I put into that handoff, uh, to development, uh, something always got lost in translation, and I think- Where what I see at least with a lot of agencies in general and in design in general p- for many reasons, for, because of, uh, pressure from stakeholders, timelines, the way the team is structured, whatever it might be, that handoff and that transition, a lot of things get lost. And- … that, that's, that's the main, main issue. Because all that intent, uh, the end product is essentially in the hands of, of the developers, uh, to some degree, because they are in control of the output, and we just lose a lot of the, the effort, time, and resources that design and research does to get it to that point, which is, which is a shame.
Nick: Yeah. It is, and I know I've been in companies that are like that, especially because they want such fast turnarounds all the time. Mm-hmm. And in order to make those, uh, demands meet, there has to be, or you have to cut corners, and I feel like that's very unfortunate because a lot of the users suffer for it.
Frederick: Mm. For sure. Yeah, and that's, that's the thing, and I think design engineering, which I think we'll go into a bit later on in this episode, but d- design engineering is really this unlock, from my perspective at least, in terms of bypassing a lot of that, a lot of those decisions being made in the corners of the business or, stakeholders having a certain opinion in terms- of timelines and budgets, and like it really, it empow- powers designers to get beyond just the normal sprint process of saying, "Okay, we can only fit this within this scope or this sprint," and then the rest goes into some sort of backlog that we'll never look at again. And to your point, that hurts the user experience, but I think design engineering enables designers to then do certain things on their own that ends up in the output in the design system- that we just haven't been able to before, uh, recently.
Nick: Mm-hmm. Yeah. To someone who is, uh, new to the term of design engineering, what does that actually mean?
Frederick: To me, design engineering is… It depends on how you look at it but it could be both ways in terms of either you're leaning, um, more on the design front and you're leaning- into touching your toes into engineering, which is personally where I think we see the big- the best outputs in terms of design engineering, where we have a designer who have learned their craft, who is- who's excellent at producing really good pixels, has great taste, uh, understands intention and, what drives the business forward, why are we designing this new feature. Yeah. All that is locked in. And then maybe 30, 40% of the work they do now, which, is a scale that slides all the time, but that happens in code. So s- … things still happen in Figma, maybe more so in Figma initially exploration-wise, but then turns into some sort of coded output, uh, through whatever technology they care to use. But the idea is simply that a, a design engineer in my mind is a great designer who works in code and a lot of the artifacts, and the, the output that ultimately ends up from their work is coded prototypes- Production-ready, uh, feature specs in that sense.
Nick: Hmm. I'm also curious, how does that, uh, change the relationship between designers and developers?
Frederick: It's, um, it's something we're, we're talking a lot with our clients, uh, about because all our— the, the nature of the structure, how we work with clients is we— we're, uh, originally a design studio, so we have designers. Uh, we're leaning over the last two years, we've become a design engineering studio, uh, through various ways. Uh, and our clients remains the same structure, which is they have- … a development team, they have a product development team, and we still hand off things to them. But this, this— if you look at the, the sliding scale of design to development, the, the gap between the handoff has kinda slimmed down, and it has enabled, from our perspective, developers to push forward and do more innovative work. So they're still doing development work, of course. Uh, there is more check, and they know that from their own work too because they're also relying a lot on AI these days. But we- we're just moving them to become more innovative in terms of thinking more broadly about their business instead of them, making buttons or variants to that component or maybe updating the documentation in that storybook. It has become, um, a dance, I would say, in terms of designers moving, uh, a bit more into what developers have, traditionally been doing, but freeing the developers up to do more meaningful work- … uh, I would say, simply put.
Nick: So I know with the, the involvement of AI that's now currently increasing, like, all the time now, so do designers need to learn how to code, or do they mainly need to understand how products are built?
Frederick: I think I've f- for the, since, I don't know if it comes from the fact that I started, as a developer and had to understand basic HTML, CSS in order to construct my own designs, but I think I've always been a big, uh, fan of designers, and I've always looked for designers when I hired, uh, for my studio, uh, designers who had some sort of- technical understanding. Uh, at least they had a, a, an under- understanding of what is feasible. Is this a small thing to do, or is this a difficult thing to do in terms of resources when we design some pixels in Figma, which goes very fast, but that has to translate into something, uh, on the other side. So I've always looked for, technically smart people in terms of, especially designers. Uh, so- Mm-hmm … they know what they're working with ultimately. Um, so I think that is important, and that helps. It's a big bonus if you wanna get into design engineering as a theme, as a focus. Uh, it will speed that process up for sure, but a lot of it comes from also just understanding these new technologies, AI, LLMs, how they work, prompt engineering. Like, how can we get- … good outputs? Uh, how can we consider our token usage? How can we write good rules, guidelines, constraints, guardrai- Like, all these things become increasingly more important too, and we experience that with evolving design system work especially, and UX research, which I'm very excited to talk about too in terms of that feeding into the whole process. When everybody's using AI, how do we make sure that the AI also understand the intent from the users? Uh, but to answer your question, y- design, a designer who's been technically sound in terms of what's possible has always been my focus to find, and I've always, encouraged people to do that. But to some extent, just understanding the technology and AI- … is just as important these days.
Nick: Yeah, you, you raise a good point about UX research where this goes into it because I feel like a lot of teams are also relying so much on AI to now do that for them. Sure. I'm curious to know your thoughts on that.
Frederick: Yeah. It's, it's, it's ter- it's terrifying and terrible, uh, because the… for many reasons. But I, I'm, I'm a strong believer in, um, in humans talking to humans. And I think we, i- i- in general we- I don't like speculating really but I have a lot of speculation going on in my mind. But, but what I, what I do know is that, what I do know is that AI, the, the LLMs, the, the datasets they have, they, they know what they know. And, and in our field as a design studio in, in, in some fairly complex technologies where the AI might not be too mature, there's not a lot of public information on how a telecommunication company, uh, designs enterprise level SaaS software for huge telecommunication companies, like you can't find a lot of good stuff on that. And then relying on AI to do your desk research for you means that either it's gonna be super mediocre and not really fit the purpose, or like worst case scenario, it's gonna guide you in a direction that is completely off, and it's gonna offset the rest of the work that comes after you in terms of design work and, validation and development. So in that way, it could be detrimental for other organizations or in other contexts. Um, so humans doing the research will obviously always give you some, some unique insights, hopefully. And if not, that's fine, then we just validated our assumptions, and we can move on but you've gotta make sure for sure. Uh, but AI has its place though, in that process.
Nick: Mm-hmm, mm-hmm. Now, do you think every designer should become a design engineer?
Frederick: I do not, no. I, I, I think, uh, and I just know that from my own design studio here, that there is, uh… What we need, I think, is changing in terms of, classic job titles and disciplines, capabilities in design. That is changing, for sure. Teams have many product designers, um, doing good product work, and that is great. Less UX folks working on really hard UX issues, uh, even less people going, talking to users, doing a lot of deep research. And I think we're seeing a shift in terms of what, what provides good value when it comes to product development because I think product design to some extent becomes… It's not a commodity, but we can do so many things with an established design system, for example- Mm-hmm … in large organizations. So AI, to some extent, with the right setup, technically strong setup, and, and good design documentation, and, and great user research, can help us a ton with new features, which previously, you know, a designer had to open Figma, move a lot of pixels around, and that was fine. Mm-hmm. Yeah. And then give that to a developer. But I, I do see a shift, and I do think it's more important that some of these product designers, not specifically them, but that UX research and design system, um, work becomes the pillars of what we do- Mm-hmm … as designers because that ultimately creates the best return on investment, in my opinion, but also creates the best output that the users, you know, feels i- in their hand when they're using the application or clicks around on their desktop computer, which means that some people, some designers need to evolve into engineering to control the design system work. Mm-hmm. But we still need really good UX work, and I think that's more important than ever.
Nick: Yeah. Uh, now looking at, like, all these different skills that it takes to be a great UX designer, what would you recommend to a beginner that they should learn first?
Frederick: I think, like, I interview a lot of, um, of UXers and I, and I do get a sentiment that there is a lot of us, of UX designers looking for good jobs, uh, in meaningful positions. And, and it's very hard. I do see a, a, a tendency that- I might, like I'm— I don't have an education in this. It's worth to s- like worth saying, but I, and I also, like in, in design. Um, and I've never really felt like that was, uh, needed, uh, in general in IT because a lot of us, we just, you know, learn on our own, uh, when we were younger. Um, but I do th- see a tendency for people to lean a lot on methodology, UX, and- Mm-hmm … and especially in a lot of job interviews I have, and I understand it because, you know, the universities teach what the universities teach. Yes. And it's hard, it's hard for universities and teachers to be completely on top of all the new stuff happening, especially now. Like I can't imagine. So I don't have any— I'm not naive to think that, oh, they should know the latest things. But I, I see a tendency for methodology to take the front seat, especially in UX. And I do think it's, to some extent, can be a bit damaging, uh, because we rely too much on it, and if you've been in the industry or worked in certain companies or most companies, you know that's just not how things are made. We- Yeah … we do not sit with these different diagrams, and we try not to spend too much time on this and this because we simply don't have it. So to your, uh, to your question, um, I actually answered what they shouldn't, but, uh, I, I, I think A- AI technology obviously is a thing that they, they need to grasp. Um, and I think showcasing that they're able to run good user interviews, I think is, uh, good organizational skills because I think a lot of UX is really just keeping track on everything that happens within the product development, outside of j- data collection, and making sure the right people know the right things, and then presentation skills. I think my biggest thing is presentation skills, honestly, for any designer, but especially UX. If you need to con- convey a message and convince stakeholders that the work I'm doing here is meaningful, like it's important for me to speak to five people who does not like our product or, churned or love our product, give me that time and those resources to do that, and that comes through presentation and, selling, honestly.
Nick: Yeah. I, I agree with a lot of that. Uh, I talked to a, a design professor at a university a while back, and he s- he spoke how much he already wants to teach AI in school, and he hears it from so many other professors of other departments how they're so against it, and they don't actually wanna teach it at all. And it just feels very frustrating to hear that they're gonna learn the world is— like what they have learned and what companies value are not gonna be the same thing.
Frederick: No. It's unfortunate.
Nick: I know. It is. Um, I know you're bringing up the important skill of presentation. I also agree. I f- I feel like not enough people are talking about that, though. I'm curious to know, like, how can a designer get better at presentation skills? Or even as a person in general. Doesn't even have to be a designer.
Frederick: Uh, no, for sure. Presentation skills is a great life skill in general, but especially in these meeting rooms with stakeholders, I think I think I can tell you what, how I learned to become somewhat decent at it. And I think it came from obviously exposure, experience- … doing the thing and doing it over and over again, no matter how uncomfortable it is. I think some people, uh, have, are more okay with just starting out, and they're not as- uncomfortable. Sure, it can be tricky, but they just do it. Other people are obviously more reserved and really scared, and I think I was more in that category, because I like to overthink all my sentences before I open my mouth in those, important design meetings. So I have my … My boss was doing the presentation work for me, and I was in the room. And then, slowly, one meeting after another, I get 20% of talking time, and then I get 50% talking time, and then at some point I'm actually presenting everything on my own, uh, with him in the room still. And that was really important, I think, for my journey. Um, add to that having somebody who checks in on you. Like, somebody who's, even though they might not be talking or speaking in those meeting that you are presenting in, just listening in and then giving you critique right after. I think one of the best things I've learned is, getting negative critique right after my sessions because I was just in it, and I can correct myself for the next one. I think that helped me a lot in terms of the small things of uh, uh- … uh, and how you look and feel, your body language. You can't really see all of that yourself, and I think that is a quick major unlock to just have somebody, give you some candid feedback honestly, uh, besides the exposure. And then for some, I've learned at least that sitting down before the meeting, 15 minutes just going through your presentation over and over again, that's great. That works wonders. It works for me, too. I think for me, I was really scared of not being able to tell all the things I wanted with my design work, and you're obviously not gonna write everything in your slides, but having- Mm-hmm really good slides is really underrated. Slides that you feel comfortable with a- and, able to… I'd rather have 10 more slides than have one slide that is full of bullets, of course, but that just guides your conversation, and that has really taught me a lot and enabled me to do better presentation work, honestly.
Nick: Mm-hmm. Yeah. I don't do a ton of presentation work, uh, but thing I always learned about is the s- uh, the slides are supposed to help show what you're talking about and support, it gives value to your words or more context.
Frederick: For sure. Agree. I think, uh, especially with the design work we do, but, uh, what, in terms of, showing off your design work specifically I think, telling, giving your work time to breathe. The biggest mistake I see at least in terms of showing off new design work to people who haven't seen it is jumping directly into showing it. People is gonna have assumptions. They're gonna think about the technical implementation. They're gonna think about the color you chose- … the word you chose. They might not even understand what they're seeing in that Figma canvas. So I think in all of my presentations and my colleagues usually make fun of it, too, that I spend 10 minutes just talking about intention, what the, the stakeholders told me the last three meetings, uh, what is important KPI-wise or business-wise for this- to make sense. All of this lead-up, which seems trivial, but all of this lead-up, just repeating that before you show anything to dis- so they're not able to dispute what you're showing them has been one- … of the best, techniques, if you wanna call it that, in my presentation work.
Nick: Yeah. I think that's very powerful to know. Yeah. And I'm also curious, uh, to know, um, so l- looking back at your years, uh, now working in both design and engineering, what's something that you believed about early in your, earlier in your career that you no longer believe?
Frederick: And now it is that designers shouldn't code. I think that, that thing was, that was a big debate, uh, uh, a few years ago, uh, maybe even more years ago, that, uh, designers should stick to their bread and butter, which is, design- Yeah and in, in finding solutions i- in a piece of software. Back then it was Sketch, and now it's Figma. And I think that, that thing is completely obliviated, of course. We see the discourse online, we see people moving in directions, we see studios- … like our own that have transitioned completely and have designers in code bases now
Nick: Mm-hmm. That, that is true, and I think, like AI, man, that really has changed a lot of concepts of career projection where everyone thought of what they would be doing.
Frederick: For sure. Yeah, it changed everything.
Nick: I know. I know. It's, it's funny. Like I, I remember, um, watching, uh, Blade Runner, the 207- uh, uh, 2077, um, about five years after it came out, and that was about like 2023, right when AI really started k- uh, appearing. And I'm looking at it, I was like, "I wonder how many people thought this would happen in their lifetime?" They would probably say no. But now it's like with, now like with AI technology, I'm like, "Oh, this could happen like in 20 years."
Frederick: For sure. Yeah, for sure.
Nick: Oh, I know. It's crazy. Uh, so Frederik, uh, what do you think designers can learn from developers?
Frederick: Ooh A lot, honestly. I think it definitely goes both ways, but I think my, my biggest— The thing that made me a better designer was being able to talk to, uh, and collaborate very closely with developers, understanding what tech stack are we using. Are we using Tailwind for this project? Why are we using Tailwind for this project? Why are we not just doing something else? And understanding the frameworks and the limitations and the frustrations and all of these things that goes into building something. I think you as a designer, as an architect, uh, i-in any field really if you are doing the blueprints for things, you need to understand, the tooling. You need to understand the bricks that you're working with in order for this to withstand, you know, wind and water or I'm trying to go into a uh, an, uh, an architectural, um, similarity here. But the, the idea of you being able to talk to the person who ultimately builds the thing you're painting i-is super crucial, and it's gonna affect the way you think. It's gonna affect the way you move things around in that canvas, the way you start using Flexbox in your design or auto layout in Figma. Those things are crucial, and for some reason, we're very— We've been on that for a long, like always. I've been very adamant about, naming your layers and grouping things correctly, so it represents the DOM structure in a web browser. When a developer goes in and looks, even though he might not look, he's probably not gonna look, but we did our job in terms of naming things right, structuring things correctly, so it fits with the output in a style sheet. I think if you learn that, you become, especially with AI now, it takes a bit of it off, but just you knowing it as a designer, junior designer is impressive. It gains respect, and it just helps with collaboration overall, I think, between design and development.
Nick: And now, what do you think developers can learn from designers?
Frederick: If they're working with great designers, I think There's a lot of assumptions usually i- in conversations with anybody. We all have assumptions about- … the audience we're designing for, or the users who's gonna use it, accessibility requirement. We have all these assumptions, all of us. And I think, and this is not strictly a developer thing, but there is a lot of us and them mentality. I see that sometimes. There is. I see it a lot. Yeah. Yeah. And I think that us and them mentality is obviously terrible, and there's a lot of ego in all of this. And in general- … you should just, remove your ego completely. But if you're working with good designers who understands the user audience and who's, who has more, uh, exposure to who's actually gonna click around in this product 24/7, I think you owe yourself as a developer to leave that ego at the door, listen to what they have to say, and try to put yourself in the shoes of the user instead of just, building the things you get served. Uh, that, that is at least a thing that has, plagued my career, uh, previously.
Nick: Yeah. I know. The… I always like to say simply is to, I tell developers, "Trust the process."
Frederick: Trust the process. That is true. But, I, I s- I say the same thing, but y- a developer has one bad experience or, sees- Sure a, a Figma canvas that is completely unbuildable, they l- they lose that respect immediately. And, and the beautiful thing I've experienced is that when they then get exposed to, let's say, some of my colleagues who, who know their stuff when it comes to this, they just- … they just ex- they become so happy. They become so r- respectful. And it's a beautiful process, uh, to witness, too. But, like, I g- I get the, I get the-
Nick: Yeah. I, I also, I, I do get where you're coming from, too, because it, yeah, it all takes is one bad experience. And-
Frederick: For sure …
Nick: you know, and there's alwa- I mean, there's always gonna be some healthy amount of, um, ske- uh, skepticism to things- that are, seem unclear. But also, we always ask questions. It's always okay-
Frederick: You should be curious, for sure.
Nick: I know, like we, I know we t- we tell designers to always be curious, but I feel everyone should be more curious.
Frederick: For sure. I- if anything I get so, uh, sad when people are not curious about the thing they seem so, passionate about building and, putting so much of their time into. It's sad that they're not curious to ask those questions or understand that thing better. Uh, so I agree with you completely.
Nick: Es- especially w- with designers because asking questions is a part of the job.
Frederick: It is. It is literally in the job description because… And, uh, sure, in terms of asking your users "What do you like?" Sure, that is great. But even, the business I'm working for, the thing I'm building, why are we actually making this feature? Or what are the objectives of this, uh, business commercially, and, like, why are we- … even hired? What is the return of investment of me sitting here? You should be asking all these questions. That also seems to be this is out of my scope. This is not my place. But all of this is your place. As a UX- … I think, and I've talked to a lot of people about it, that the UXers who really get deep into it, they feel the weight of them having to wear all these different hats, and I agree with it. I think that is the job description if you wanna be a good UXer who gets that famous seat at the table to make those decisions and move things- … forward. You really have to dig deep in a bit of everything because you have to collect all of that holistically across a suite of products, uh, in front of, uh, stakeholders who have no idea what what's happening.
Nick: Mm-hmm. Mm-hmm. And now with so many technical skills, and it feels like it's all very useful, I'm just curious to know, like, how can someone not be so overwhelmed with trying to learn it all?
Frederick: That's a great question. I think, um, I don't thi- I don't know the answer specifically, but I think honestly a lot of it comes down to leadership, just to- to throw the ball on somebody else. D- designers should be curious, and they should be learning and, maybe should spend a bit of free time if they're actually curious about the, their career and the way it's moving. Watch a few YouTube videos, go on Reddit, wherever they consume their knowledge if they like the stuff- they're doing. But ultimately, I think leadership needs to be able to create that space, that pocket of, learning on the job and trying things out. And there is a lot of— I hear there is a lot of leadership saying, "Oh, Claude, I r- read this on LinkedIn the other day. We all need to be doing this. You learn this now." And that is obviously the wrong way of going about things, because that creates that stress, that FOMO, that, yeah, it's horrible. But-
Nick: I, I've seen those.
Frederick: Yeah, same. But I think, um, y- taking it step by step and just trying to figure out wherever and what context you're in, like what is the thing that potentially could yield the most benefit for me to learn? You don't need to learn everything. You can segment- Yeah … your way into… If your niche is research, I think you owe yourself a favor to sit down and just evaluate, like where do we think that this new technology can benefit me and the output that I'm producing to help my career, or to help my colleague, or to help the company I work for? I think that is a good starting point, and you can even do that with AI. I think AI is a great sparring partner too if you're a bit lost in all of this, where should I actually begin? Um, but, but finding your niche, I think w- I, I just said that UXers are very generalistic, which I do think they are, and I think that- is great. Uh, but I think you need to find a niche within the technology if you really wanna learn something valuable. Uh, because- … knowing a bit of everything in terms of AI, everybody already does that and they're self-proclaimed experts. But if you actually show up to that meeting or in, in that work environment with some niched down knowledge for that technology, I think you will be, um, I think it will be noticed.
Nick: Mm-hmm. Mm-hmm. And also, um, Frederik, if you were to start everything all over again, what would you do differently?
Frederick: Like right now, if I had to start, like I would obviously get- Yeah … consumed. I would get consumed in AI. I spoke to a colleague the other day in terms of i- if I wanted to … If I wanted to start a successful design studio now, or if I wanted to do anything really in IT, I would obviously, um, try to go into all these organizations who've heard of AI, and I would try and, uh- I would try and consult them on, on AI maturity, honestly. Uh, because- … everybody is, uh, obsessed and, uh, and scared, but nobody really knows what to do. Um, I would, I would take that AI knowledge, and I would go into, um, just design system work, honestly, what we're doing right now. Um, I think there is a general I think it has been this, it's been the case for a long time, but it's really the case now in terms of design systems. Like that buzzword had been around for a long time. Sometimes it meant a component library in Figma, and other times it meant a fully coded everything, right? But now- especially with AI, design systems become this foundational piece of, um, of how does the AI actually work within our product? How does it, uh, make UX decisions? How do we make- … new features? Um, so I think take, taking ownership of design system, uh, work from a UX perspective, from a technical perspective, from any perspective really is, uh, is the place to be if you care about the output. Uh, taking that ownership, I think, uh, that's where I would put my effort. That and understanding how AI consumes design systems, consumes restrictions and dos and don'ts and UX patterns and so on. That's where I would put all my effort if I were to start.
Nick: So now when you look at AI workflows, um, I'm wondering where is the, where, where do you think the direction of that should be for a lot of companies?
Frederick: Direction in terms of how they should apply or create their own workflows?
Nick: I would say apply.
Frederick: Apply. I think obviously starting by educating people on … Let's we use Claude a lot here, so I'll use that as an example. But, uh, obviously just enabling people to have access to Claude is a good first step. Uh, doing a bit of educational knowledge on, uh, sharing a bit of educational knowledge on Claude and what it can do- … and general UI, and if they're they care about the console, then they can go into, or the terminal, they can go into that. But just generally using the UI is wonderful. Then I think just ensuring that- Anybody in the organization, and, it depends on the organization type, and there is a lot of compliance layer, like can we actually give people access- to the GitHub? But let's just, uh, for the sake of this, uh, assume that it's actually okay that the UX designer has a, a GitHub account, and they have access to the repository, and they can pull down the code on their local machine. And- … I think that is step two, making sure that there is no blockers, there's no gatekeeping in terms of the final output of the thing we're building. So getting access to a tool, uh, getting, uh, access to the code, the final output, and then really just communicating that within, AI is here. Uh, but taking a step back from a leadership perspective and saying, "We know this technology's here. We know it's super powerful. We're not really sure what we can achieve with it. We think we can achieve some good stuff with it, but we're not really sure entirely what it is. We would love for all of you to start, experimenting a bit. It could be a few hours on a Friday. It could be whenever you do a new thing. It doesn't really matter. Whatever fits into your culture." But the idea of a UXer being exposed in their pace, in their speed- whatever they feel curious enough to do, to try and fix that annoying UX, uh, bug or, the button placement of that thing, uh, in the UI, in code- … and then, making that pull request and having a developer review it, say, "Oh, this is pretty fine. Let's push it and let's go in production with it," I think that, that is the workflow I would love to see more of, and I see a lot of great companies doing exactly that. Linear, for example is, uh, I think on the forefront of doing some really cool stuff within design, of course, but also now with enabling designers. And I think that is It's simple stuff really. It takes a bit- … of man hours, of course, but, I think it's worth it.
Nick: Yeah. One, one of the biggest questions I get from my listeners is, how do I get hired as a designer? Uh, I'm very curious to know, what are some of the ways they can stand out in their application if they wish to work in your, i- in your, uh, in your team environment?
Frederick: I think I'm— I've looked at quite a lot of CVs, but obviously a lot of people have looked at a lot of CVs. But there is, to be fair, there is a very quick— When you get 200 applications for a UX designer position at a small Copenhagen studio it's overwhelming, uh, within a few days, so you gotta— I-if you don't go the AI route of, you know, using software to scan all the CVs and just auto-reject, which I don't then a human looks at it. And the first thing I look for when I'm hiring a designer, no matter if it's a UX researcher or, a design engineer, or it doesn't really matter what type. If the role is design, which it is, I'm looking for design. I'm looking at aesthetics. I'm looking at line height. I'm looking at typography treatment, and like that's the very first thing I see, right? I open that PDF, I see design. So within the first five seconds, I am super quick to, uh, determine whether or not this person is relevant based on just aesthetics of the CV. And it— to be honest, it's a great indicator because this artifact, this CV, is one of the most important assets you have currently. And if you don't put— or maybe you don't have the capacity to, or the skills to do it, and that's completely fine. Um, but in that case, you know, I would expect some sort of, um, care put into it. Uh, at— If not, get somebody to help you or use AI, uh, to make it. Um, the second thing I look for is obviously what's written in the CV, uh, like grammatical errors, like all these small things that is very avoidable, uh, in terms of, uh— I'm giving you a very detailed rundown here, Nick, because I care- Oh, yeah a lot about CVs.
Nick: Yeah. Please do. A lot of people need to hear this.
Frederick: Okay. Amazing. Like grammatical errors is, is— uh, despite you might be speaking a different— We have, uh, my team is— I'm the only Danish guy in the team. Uh, so we obviously is very international and we're not all native English speakers, but I do expect a CV like this to be like there's no grammatical errors, for example. That's like just the baseline. Um, I think, uh- The way you present, like that's the CV. So if this, if those two things checks out and you're actually applying for the right thing and you seem proper I click on the portfolio. And if that portfolio, it can lead me different ways, and people are very creative these ways, uh, these days. I'm getting into Figma files. I'm getting into websites of course. I see, um, some technical domains sometimes. I see it's hosted on Vercel or, it's made in Claude and just host that. So I see a lot of that, which also gives me an indicator that, okay, you're doing some, some techy stuff. You know what you're doing. But obviously if you have a nice domain and I land in on a proper website, that's a green flag. If I land in a Figma file, sometimes that's good. But if the Figma file is massive and I have a hard time kind of navigating around in it to figure out what should I be looking at, that's a red flag. I, I- Mm-hmm … I don't have the mental capacity in that process with 200 applications to be really like, "Let me zoom in," you know? I'm zooming- … in at 8%. Let me zoom into 100 to see this thing up close. Um, but I've seen nicely made Figma, uh, portfolios though, uh, to be honest. Um, but I look at the quality of the work of course, and depending on the role I'm, um, I'm, I'm hiring for. If it's a junior it comes with, different eyes than a senior of course. Um, but I'm looking for intent. I'm looking for general understanding of the product they're trying- … to solve. I'm looking for like decent to good visuals. I think visuals is being, becoming good at producing really great visuals is tricky. I at least as a leader have a hard time teaching it. Uh, I think teaching good UX is potentially a bit easier for me. Um, and that might just be because of my career. Uh, but, uh, so I look for visuals that, again, line heights, color combinations, spacing, like simple things, but, is it consistent? Is there a bit of taste? And if that all checks out, I'm on board. Um, websites are commonly not very good and that's okay, but at this point the, like I don't mind it's an AI gener- generated website. I can see it quite easily, but I obviously love when somebody puts some time and effort into making it personal. It could be quirky, it could be fun, it could be all sorts of things that is simply just not, a template. That is a green- … flag too, uh, but not a requirement in itself. But a lot of things sticks out in that process because it also happens quite quickly. Um, but it's also super important like that, uh, that the care is put into it
Nick: Yeah, like anything that helps to stand out is is going to be like a net positive. I even heard from some designers that where they will purposely use an incorrect word or a misspelling Okay … to, to do that to not appear AI generated.
Frederick: Mm, right. Okay. It's so funny. You know what? Yeah, I get that, for sure. I am… Last hiring round we had here where I had that exact, uh, experience, like everything was so great, but there was just one grammatical error. And I was like, okay, then for, first of all, we know it's not AI, and second of all- Yeah … like everything else checks out, so sure, they're just over. That passes through the, the Frederick check too, uh, if everything else is solid, but that's funny.
Nick: It is funny. I, I know. It's, it's cra- it's crazy the things… Like, I think that's a little bit of an overthinking problem
Frederick: Potentially …
Nick: personally.
Frederick: Potentially.
Nick: Yeah, especially with, uh, oh, you, p- I know like hiring managers, like you, you go through so many all, uh, like applicants, as well as like on top of your full-time job. Especially, and for an owner, like it's more than a full-time job. And it's just people also have to remember that these things are gonna be, uh, skimmed through. They're not gonna be- … just sat down and read. And I'm curious, do you, do you ever r- actually read through a case study, like ever during the hiring process?
Frederick: I quickly, like I, I look at the, the visuals and I obviously scroll through it to see if I- … can quickly find some sort of, um, outcome. Like in term- if I'm hiring for a visual person, I'm looking for the end product. I wanna understand the, the UI. Um- … even in, in, in UX that might be the case because there is obviously a final product. So I look for that and see c- does this look all right to me? If yes, then, I continue. But the presentation- You know- … of it is not.
Nick: I know, and I wanna say to the listeners, like if you're using a persona, like there's two easy ways to solve that issue is where are you getting the persona information from, and how did that affect the final outcome? Like- As long as you fit those two things, like you can persona away.
Frederick: For sure. I like personas. I like when we use personas as a communication device internally and with our clients, but it usually becomes like they like to play football or they like hanging out with their friends and, and- I know that's just, you know, we don't, we don't do that. I know. It's like I don't care they listen to Taylor Swift. I… This is information you're just giving me for no reason. Exactly. Exactly.
Nick: Uh, so Frederik, as we're, uh, drawing close to this episode, what's the best way to support what you're doing or anything you want, uh, the listener to check out?
Frederick: We do have, on our website, on our newsletter we're working on a report actually currently, uh, that is how big teams, how big software development teams are making decisions, how they, how those decisions come to life in the product too. And we're talking, my colleague, uh, Stephanie and Philippa, UX designers, are both talking to and interviewing a lot of, uh, professionals, h- uh, craft people here in Denmark currently at, at large, uh, fintech companies, health tech companies and they're figuring out what does it take, from idea to production? Are you using a lot of AIs for your decisions? Is it waterfall decision-making? Are you even involved in decision-making? Are you just, participating in making pixels? So we're Trying to, because we're super curious about it too, uh, we wanna s- essentially sell research. Uh, but we also have a hard time selling research because UX research are oftentimes looked as a blocker or something that we have to get through to do the real thing. Um, so we're very curious about these big, successful companies. Are they successful because of UX research, or are they, just gut-feeling their way through things? Um, so that thing is coming out, um, around November, and we're gonna talk about it on our newsletter, uh, as, as we get closer. So I think that's the most exciting. That's the thing I'm most excited about right now, at least.
Nick: Okay. Yeah, so you can be able to check out Frederik's newsletter in the show notes. So absolutely. So Frederik, any closing words you'd like our audience to know about?
Frederick: I think we're at a, at an interesting time, like industry-wi-wise as, as designers, and I think, I, I, I think there's a lot of FOMO, as I said. The- people are scared, people are getting laid off, people are having a hard time finding a, a decent job within our industry, and I think all of that is extremely sad. But I also do think that with this technology The technology shift we're seeing with AI, I do think, uh, there is an opportunity. I think, uh, if you're curious, uh, if you're, you know, adamant about owning the final output of what you love to build so much, which is the user experience, I think you owe yourself to, to get into engineering, design engineering as we call it, to get closer to that space and take more ownership within that. Uh, because the intent and the, the thing you care about when doing user research or making pixels in Figma, those things are just gonna translate much easier, and you're gonna be much more attractive in this job market too, uh, if you're able to spar with developers or even, provide some value to an existing coded design system or a coded product experience. We wanna see that intent. I wanna see that intent because it… there's so many terrible experiences, and it could just be so much better if a designer with a bit of curiosity just had, you know, were able to poke their feet into, uh, into the code.
Nick: Yeah. Any, any additional skills you have is just gonna make you more valuable, and, you know, like, and we also, like, need to show that in your case studies. You know? How- For sure … how do you apply it, and stuff like that. Like, I know, like, anything, I feel, like, like the bar for bad applications is, like, on the ground you know, you can easily, like, rise up if you are just properly showing your skills and the results that gives it,
Frederick: for sure.
Nick: Yes, you can stand out for real. Yeah. All right. Thank you so much for being here, Frederik.
Frederick: Thanks, Nick. It was so fun.
Nick: All right. Please do support our guests. Until then, you just listened to the UX Growth Podcast. I'm your host, Nick Mann. Thank you for listening.
Great work deserves
a better story.
Your portfolio should help people understand the decisions behind your work, not just the finished designs. Explore how UX Growth can help you tell that story more clearly.
