Subscribe
Share
Share
Embed
Get a seat at the table and build the design career you want. This podcast is for designers looking to break in, level up, and take control of their careers—whether you're freelancing, climbing the corporate ladder, or just trying to get noticed. Every two weeks, we dive into career fundamentals, design best practices, and the hottest topics in the design community.
So the the more senior developer told me, and I'm very happy that they that he did, like, okay. Go fix it. You know? Just I'm not gonna do it for you. At at first, in my mind, I was like, no.
Nick:Please do it for me. I am scared to break something. But now I have that skill because I did fix the merge conflict and it was accepted. So, yeah, my you know, next to the design skill, my developer skill level also went plus one.
Tyler:And we're officially live.
Nick:We are officially live. Exactly. I mean, this is just an experiment. Alright. So I have something really practical for today, something I struggle with, and something I know many other designers also struggle with.
Nick:And I'm just curious what you think and if you have some pointers and if that's is something you if if that's something you have in in your work as well, which I expect you do given your the size of your company, and that is working on a feature or a design request with multiple people at the same time. You know, more than one designer or, you know, even more challenging, a designer, a developer, and and maybe a few extra nondesigners. You know? Different opinions, different versions, you know, being in mailboxes, in Figma, in, you know, prototyping tools. I always get a bit lost there.
Nick:You know? I'm not sure what the latest is. You know, people change things without you knowing it. Yeah. Is that relatable?
Nick:If so, what do you do?
Tyler:Yeah. I think it's very level. I think I it could I've struggled a bit with it. So I've worked in mostly startups for the majority of my career. And, like, the benefit there is that you get to wear multiple hats, and then you have control over multiple things.
Tyler:So you like, ownership is a really big in a smart at a small startup. And as companies get bigger, more collaboration is needed because you can't do everything. But, like, your first instinct is like, oh, let me just do it. Just give me the keys. I'll do everything myself, and I know exactly how it's gonna be done.
Tyler:As you just kinda scale up and and maybe a larger company, even even at a small one, it's like, you have to delegate and collaborate and just believe in your team because that's how a lot of work gets done quickly is if you're not the one doing all of it. It's like as a soccer analogy is it's the ball is faster than you running.
Nick:Yep. Yep. Yeah. Well, that's as a as you know, we say football over here. But as a soccer slash football player, enthusiast, I yeah.
Nick:That makes sense. It's also smart to not run the whole time yourself. You know? It's so, yeah, that makes sense. So what does that mean in practice?
Nick:So let's say you work on a design on your own mostly, and at some point, you feel the design is mature enough to start collecting feedback. You know, you think this is something. I'm curious what colleague a, b, and c think, and let's grab a bunch of users. But then it's starting to live a life of its own. You know, you get feedback.
Nick:People start talking about it. You're not in control as much anymore as you were in that safe first phase where you were the the only one knowing even about this work. Yeah. Do you have any any practical advice?
Tyler:I think it's as you grow in your career, it's very import an important skill is to learn how to let go and not to be emotionally invested in your idea or the thing that you created. Right. In a previous episode, you had mentioned that, like, in workshops, it's just about shooting ideas at the wall, and it doesn't have to be the greatest idea because that bad idea can can pivot the entire room to kind of double click on a really good idea. So I think
Nick:Yeah.
Tyler:One practical so I think it's just not being emotionally invested. The thing you create is just the start of the conversation or midway through the conversation, how it pivots between different conversations, whether in this example, if it's a user interview giving you feedback on this prototype or this design you've created, creating negative feedback, that's good feedback as well because we're gonna have to pivot and change. And if you have multiple stakeholders in those sessions, they're gonna have they're gonna be receiving the same type of feedback as well. So it's not you can't shield your your great idea because it's being exposed in multiple angles.
Nick:Yeah. That makes sense. That makes sense. I feel like designers are emotional about their work. You know?
Nick:It's my thing.
Tyler:It's, like, to the level well, it it makes sense. I mean, you you know this as well as I do. Like, you are in the weeds, in the details, zoomed in at 1000%, making sure that
Nick:Mhmm.
Tyler:Everything is kind of manicured. Yeah. At the beginning stages when you're sketching or prototyping, it doesn't matter. But, like, once you've really kind of invested time and effort to kind of manicure your design because you you you're you're really trying to push it, you get really emotionally attached. It's like you know every freckle on your on your baby's butt for another terrible analogy.
Nick:Yeah. Yeah. Yeah. Well, I have to with the twins on on the way. I have to find something to know which one is which.
Nick:Anyway yeah. So okay. You know, what I do is when let's say, you know, I think the most common example is a developer coming up with an idea, you know, some designers. And this has happened to me too. Designers get a bit protective.
Nick:Like, no. That's something I do. You know? You shouldn't come up with ideas. You shouldn't design something.
Nick:It's something I do. I'm a designer. But I I I'm starting to really realize that that's kinda selfish and stubborn. You know? It doesn't really matter where ideas come from.
Nick:And the new way that I handle that is to to just really go through that workshop and and and see if we can grow that idea regardless of who came up with it. And then at the end, just to be sure that everyone knows, like, okay. We have this idea. It's very rough now. Let's polish and fine tune and validate and do all that kinda designery stuff with it.
Nick:And then they know they have to, you know, give it to a real, quote unquote, real designer to to do that type of work. So that circle gets bigger. You know, I it starts with me, but then people have ideas, and that's all fine. It's far away from me. But then at some point, it circles back to me because they know, you know, in a startup, I have the design eye to to really make it, you know, look good.
Nick:And I think that's that's that's good for me, I think. You know? So what yeah. What do you think?
Tyler:Yeah. I mean, it's a good like, that's the insight. Is it, like, eventually, the person who wears the hat of that skill needs to do their job. And in this case, like, the designer needs to do the polishing or the the real design work. Everyone can create their collateral pieces to to resemble a final piece, but, like, developer needs needs to do the edge cases.
Tyler:Designer needs to do their product thinking hat That still needs to be done. Like, we do that as well. Like, PMs are prototyping and using Figma Make and creating high fidelity kind of prototypes, but they are they are thinking business lens, not edge cases, design components, spacing, hierarchy, all that thing. They're just spitting out a thing that's not that may not align with the heuristics that, like, design team is kind of sticking sticking with.
Nick:Yeah. I, you know, I I think designers mostly are just concerned that something gets shipped where they didn't do the design skill, but then it comes back to them. Like, how can you ship this? You look at the design. It's terrible.
Nick:How could you do this? And then they're like, no. But wait. I didn't do it. You know?
Nick:So
Tyler:That that's a real that's a frustrating moment regardless if you've touched it or not because, like like, what we do is, like, we, like, we kind of hand things off and it depending on if you're doing the development piece or not. But, like, in most cases, you are handing it over to a developer and they're implementing it. So whatever communication or handoff process that happens between you and the developer, that's that's what has to be done, and then they have to translate your idea in code. Yeah. But what's important there is that you do you still do your, I call it, visual QA or design QA to make sure that it's it stands.
Tyler:Because, like, inevitably, when you when it comes back, it's not like a bug where you can do a a hotfix, like, as developer. It's like, it's the con it's the whole concept of itself. Does it work or does it doesn't work?
Nick:Yeah. Yeah. That's true. I like the the visual QA. I think that's a a great way of putting it.
Nick:That should be a skill, I think. You know? You having the design eye to just be able to see, like, this is good enough, you know, design wise. I'm not talking UX or user or business wise. We're just, like, is everything in place?
Nick:You know? Are, like, the hover states, accessibility, responsiveness, all that stuff? Is is it present, first of all? And then secondly, like, if present, is the quality high enough? I you know, that should be a skill, or that should be something people pay for.
Tyler:Well, it's the it's very valuable. Like, oftentimes, if it's like it's the those kind of my micro things, those final polish things are are seen as, like, a nice to have. Oftentimes, the developers say that it's, well, it's visual. It's nice to have. But, like, you can like, those are giant consequences.
Tyler:So those reflect poorly or or positively or negatively on the brand as as users are navigating the product. Like, if something's off, if the bar is not there, that's that's the quality that's gonna be perceived from the end user.
Nick:Yeah. And they they feel it in their gut. You know? That you you can sense when something is, you know
Tyler:Yeah. Like like, there's so, like, to your example, if something ships without a design touch, like a design let's say you're you've you've feature ships, but you didn't have any part. I'd say in Figma, for example, you didn't do any Figma ink, whatever the verb is, to that feature. The at the very least, you should do that visual QA or design QA step to make sure that it passes the the designer bar that you've kind of set within within that project enterprise, etcetera. Because, like, that's what matters.
Tyler:Like, people are getting better. Like, cross collaborative team members are getting better UX, better at this, better at product, etcetera. But, like, you're still wearing the design cap. Make sure that it passes the sniff test.
Nick:Yeah. Sniff test. Yeah.
Tyler:Was is there a situation, like, that came up, like, in in that realm where
Nick:For for me?
Tyler:Something, yeah, something shifts, but it didn't didn't go through your fingertips.
Nick:It it not not very recently, but it it has happened. I'm also always looking out for, you know, things I see in within the design community. But for me personally, it sometimes you do let's say you return on a Monday, and the thing you see is different compared to what you the way you've left it on on a Thursday or a Friday.
Tyler:Mhmm.
Nick:You know? And not, in your view, not for the better. You're like, okay. I've made this look and function a certain way because of, you know, reasons that, you know, I've done research on and, you know, talk to users and business wise is all. You know, we I I think this is the direction to go into.
Nick:And then on Monday, you see it's different. Turns out that, you know, Sarah from HR has changed the whole thing because of yeah. You know, because of yeah. Or or, you know, John from marketing. You know, that that's fine too.
Nick:You know, as someone is you know, has changed it because of a hunch like, oh, man. You know what would would be awesome if we made all the buttons, like, twice as big. You know? Just random example here. Yeah.
Nick:You know? And then and then everyone's like, yeah. Wow. This is going to be great. You know?
Nick:Let's just do it. And then they do it, and then it's life. And you're like, what? Why? You know?
Nick:And then I think designers at one end, it's it's a bit childish perhaps. Like, this is my toy. You know? I I don't want the other three year olds to play with it. It's mine.
Nick:You know? But on one end, it's also you having the best interest of the company. Like, there's no visual QA. Just a random person just did something random.
Tyler:Mhmm.
Nick:And that doesn't sit well with me because I like, you know, I I like the the crafting and the building and making something and incrementally improving it. You know? And randomness, I think, is an enemy to that process. So I get really nervous when something like that happens.
Tyler:Yeah. Especially if the randomness isn't measured, if just doing it for in your example, doing it for the sake of doing it. Yeah. And then you also mentioned something there where, like, you have, like, research and that you validate you went in a direction based on some some insights that you've gathered along the way. Like, those things matter.
Tyler:And, like, that's why I think documentation is more important now than ever to document those ideas or document, like, the design decisions that are made so that when those things happen, if they happen, you can point to a Let's roll that back because I this is against this long confluence or notion document of of of research that's been validated and you're changing against that artifact.
Nick:Yeah. You know, I I I really don't want to make this episode super depressing. I think that the the I think with my sentence starts from the comma, but art, you know, documentation and that kind of stuff. I think that really works in theory, and we all should do it. Like, we should have Notion documents about how to do an AB test, how to do this and that and, you know, design rules.
Nick:But I also feel and and we're gonna talk more about this in the next episodes, but I feel like people only care about speed currently. I see so many designers struggling mentally and just, like, on the job. Like, my manager wants me to do everything twice as fast, and I'm I'm just really cutting corners here just to keep up with the deadlines they force me to to make. You know? So what I'm thinking is, like, nobody really is allowed the time to sit down, read the rules, read the documentations, think about something, and then come up with a direction or suggestion or design experiment even.
Nick:It's just go go go ship ship ship. Do you see that too? Do you have documentation in your work? Do people have time to maintain it? Like, cure my depression, please.
Tyler:I'll try to. I think something that I try to implement when I started here was the idea of creating a DRD or a design requirements document, which is not the same thing as like a product as a PRD or a product requirements document. It is to it is a place to kind of document all the design decisions. So, like, when you when you start off a project, if you're working with a product manager, they're doing some they have an insight or they've done some high level discovery work, and then all that ends up into this PRD document that's used as, like, the source of truth for every for both engineering, design, etcetera. Like, this is the thing we're gonna be building.
Tyler:But I think it's valuable for designers to create a document of themselves to, like, to highlight to to basically put pen to paper or ink on a screen of documenting all the things, all the explorations, all the different ideas so that they're noted somewhere. And Right. I think what's more more important is when things are cut out of features, that they're documented somewhere. So, like, we have we wanted to develop the stream version, but we had to get it out in a month instead of two months. So there was things that we have to kind of descope or leave out for that release.
Tyler:Make sure that those are documented somewhere because, like, those things that were removed, they're probably tied to research, probably tied to, like, some kind of usability study that'll be valuable for the next iteration if that next iteration comes. So the next time that feature comes up, you can kinda pull that little piece out of the of the drawer and then, like, reimplement it as is. So it's not lost work.
Nick:I think that also would work for, you know, the scenario where we started at this episode where multiple people work on the same thing, you know, and documentation can really help, you know, guide your decision making. Like, should we make this button twice as big? I just read here that Tyler had this reason to make it a text link instead because Mhmm. You know, paragraph of explanation. Like, oh, well, let's just not do it.
Nick:Before we continue, if you're feeling stuck in your design career or if you feel like you're doing solid work while no one really notices, we've got a bunch of extra stuff on our website.
Tyler:We're building a community for product designers to actually learn, grow, and get hired, not just scroll and collect more inspiration.
Nick:There's also articles, checklists, and courses.
Tyler:All based on real world experience from both of us. No fluff, just what actually works.
Nick:Check out designtablepodcast.com. The link is in the description. You know, I maybe that helps.
Tyler:It like, on like, to go one level deeper on, like, documentation, like, documentation can be automated as well. Like, part of, like, our process are for most people, like, you have, like, a session like, a Loom recording or granola, etcetera, in every one of those, like like, product design engineering meetings. And those are kind of like, for us, those all those are kind of documented in Confluence automatically. So because, like, because all those conversations are documented and it's kind of the source of truth, which is Confluence, there we can pull those up quickly.
Nick:Right.
Tyler:So you can do a quick if you if if your if your Claude's connected like like we do, our Claude is connected to our Confluence, you can do a quick search. What in x feature, did we talk about I? And then you can bring that up. And, like, you can point to a yes. That conversation did happen.
Tyler:It wasn't an illusion. So that
Nick:It feels like that sometimes. So is that something you do live while collaborating? Like, when you're brainstorming, like, you know, you have your, you know, claws collect things to help you not do things twice or just to help you brainstorm some more, or do you do that on your own?
Tyler:I I think it's, like, often like, in the theme of moving quickly, like, oftentimes, you're jumping from project to project, so there's a lot of context switching. So a lot of information could be lost if it's not documented anywhere. Yeah. Yeah. So inevitably, it's like you're working on, like, the third iteration of an of a feature.
Tyler:There's some a topic comes up, and then it was like, oh, didn't we talk about that that one time? We talked about this edge case that was that we're gonna table, but now it's revealing its ugly head again. What was the conversation? And then no one remembers. But the great thing if it's Right.
Tyler:Every all those sessions are recorded, you can go back. You can do a quick search or query to Yeah. To bring that conversation back up again so you're not having to do double research again.
Nick:Right. You know, I I think it really helps when it's when it is a starting point. You know? So did we talk about this? Yes.
Nick:Oh, Tyler talked about it. Okay. Well, let's bring him in and then talk about it some more. Mhmm. Because I noticed, like, if you want real, like, conclusive answers, I think, for me, at least, the trust isn't there.
Nick:Like, you it it gets, like, human intent and little annoying things and body language, of course. It gets it wrong. So my confidence isn't high enough to just use it as the primary and only source, but as a starting point for Yeah. Like, real collaboration. I think it's really powerful, and I think that's something we should do personally for your personal brand, but also, you know, within any company.
Nick:Yeah. So at some point, I think we should talk more about how you guys have set it up because I think it's it sounds very useful.
Tyler:Yeah. I mean, like, we're creating everyone is creating more than they can remember. Like, at some point, you're gonna have to outsource that that thinking or, like, the annotation the annotation of of of those things that were talked about. But, like, that's That's true. That requires the back to the collaboration piece, someone to remember.
Tyler:Whoever remembers the thing doesn't matter.
Nick:Yeah. Someone. Some
Tyler:we all have to be in conversations together.
Nick:Yeah. Do you like, how much of a gamer are you? Do you like video games?
Tyler:Not a big one. I do place I actually got double o seven on the weekend.
Nick:Mhmm.
Tyler:It's a Father's Day gift.
Nick:So Same. It's very, very cool game. Reason I'm asking is because many games have, you know, skill levels. Like, doesn't matter if it's a football game where you have, like, your shooting skills and passing skills, but also, like, RPGs where you have, like, stealth and strength and defense, that kind of stuff. In the beginning of this episode, you mentioned, you know, the someone with this skill hat on.
Nick:Yeah. I'm curious if that was on purpose where you didn't say role, but skill. Because I feel like, you know, in today's age, like, we have skills outside of our traditional role. If let's say you out of 10, you are a nine out of 10 designer, but you're also building your developer skill. And maybe it's a two now, but with all the AI help, it can be a six or a seven in in you know, due time.
Nick:But, like, did you say that on purpose? Like, skill instead of role?
Tyler:Yeah. I think I've just like, I've had these conversations before about, like like, we we early in my career, was it was about it was about being a generalist and then a specialist. Now we're back to this generalist thing. I I think moving forward, it's just it's just about being a team player. So, like, if if you have a team is basically gonna be a collection of people who have a set of skills, not to be overdramatic or copy that movie line, but, like, as long the our goal is really to help the business succeed regardless of what your traditional background, like, your education is.
Tyler:Like, you can Yeah. What you learn in school is, like, the baseline, but education continues, like, as you're on actually, more education. You get more education on the job than you than you ever received in school anyways. So, like, you're gonna be a level of skills whether you started as a designer and you pivot to product or pivot to engineering, you still have that foundation. So, like, the the skill tree that you have to go back to that if you do a game analogy Mhmm.
Tyler:Like, you can Yeah. You can morph into this new thing that doesn't really resemble a traditional design design person.
Nick:You can multi class if, you know, just for the the gamers listening to this. You can be two things mixed in one, which brings, you know, their own benefits. At the same time, I also think, like, if you were a, like, a village and you have to survive, like, the the one with the highest cooking skill should probably be the cook. Yeah. Right?
Nick:Doesn't mean no one else should cook. It's still something people different people can do. What I noticed recently is that, you know, with me doing more PRs, I'm learning more developer skills that nobody, like, really talks about. Like, everyone's talking about, oh, I shipped this thing. I built this thing.
Nick:But I I had my first and second in the same week merge conflict while trying to to get my PR back in. And Talk to me about it.
Tyler:It's been The more senior by one of those.
Nick:Yeah. So the the more senior developer told me, and I'm very happy that they that he did, like, okay. Well, go fix it. You know? Just I'm not gonna do it for you.
Nick:And at at at first, in my mind, I was like, no. Please do it for me. I am scared to break something. But now I have that skill because I did fix the merge conflict, and it was accepted. So, yeah, my you know, next to the design skill, my developer skill level also went plus one last last week.
Nick:Yeah. So yeah. I mean, that that's going well.
Tyler:That that's not a small one. Like, I like that you highlighted that one because that's it's been maybe ten years since I've done one of those, and those are always
Nick:Yeah.
Tyler:Stressful. Because that's
Nick:Yeah.
Tyler:Like, to let maybe just explain what a merge conflict is for people who aren't, like, as technical, like, what that actually means.
Nick:Okay. Yeah. So usually when you work in software, I assume most of our listeners do as a designer, you have your main code base. You know? Usually, they call it main in in in most cases.
Nick:And when you want to build something, you usually you have your own branch. You know? It's like a tree, and you go to the site. You can safely build your own thing without breaking the main code. Right?
Nick:I mean, that's so far so good. But at some point, it has to go back into the main area of code, you know, when it gets approved. So that's a PR. You know, they ask you, like, hey. This code is ready.
Nick:Please review and see if it's all good to merge back in. And, usually, that's fine because, you know, you I work on onboarding. Nobody else works on onboarding. So when I return, nothing on onboarding has changed except for the thing I did, so there's no conflict. But sometimes, someone else also made changes.
Nick:So you have your main coding area. I have made changes to it, and someone else made changes to it. And then the code doesn't really know, like, should I take a or b? Like, which one's correct? And then you have to figure out, you know, what should stay, who's winning, and how to proceed.
Nick:Like, the most challenging time is when both are right and you have to make them work together. But luckily, I had a light case, you know, not not not a severe one. You know, it was very easy to pick the winner.
Tyler:Mhmm. I think that's a good that's a really good example of collaboration. I think the engineering team has historically done really, really has done collaboration really well because in that example, like, you'd wanna avoid merge conflicts as much as possible. So the idea is if you're starting a sprint or starting on this feature, the engineering team is usually divvying up the works depending on, like, the section of the app that it affects so that they're not Yeah. So that can work at the same time, but they're not overlapping in terms of, like they're not all working on this same component at the same time because that'll trigger one merge conflict.
Tyler:So there there's a lot of coordination. A lot of communication has to happen, whether it's on Slack or in person. Like, I'm working on this thing. Wait till I this one has a dependency on this, so let me do this first, and then you can jump on it after. You can pull my chain, etcetera, etcetera.
Tyler:So it's a really good example of how collaboration happens specifically in the engineering space.
Nick:Mhmm. Yeah. And now today with more designers also. You know? Yeah.
Nick:Because designers are also stepping into the engineering space. And, yeah, I mean, it's the first time in two years of working together that it happened to me. So, yeah, I think they did a did a great job. But these things happen. You know, you can you run into an issue.
Nick:You're like, oh, that that's a quick fix. Let's just fix it. You know? But then you're not really collaborating. You're like, well, this is just small.
Nick:Can be done in fifteen minutes. And then maybe it was better to just, you know, take a moment to talk to, like, in in your group Slack. Like, hey, developers. I spotted this. I wanted to work on it.
Nick:Is this safe to work on? And then maybe someone would have flagged it, like, let's just wait. My PR is almost back in. Probably, we'll save us some merge conflicts. But, yeah, all good now.
Nick:But my original point being, I enjoyed learning that. It makes me a better designer slash developer.
Tyler:Mhmm.
Nick:And that's not something AI can just tell you. You know, it's something you have to experience and collaborate and and just just do, and then it becomes second nature.
Tyler:Yeah. I love that they let you swim a little in the ocean. Like, you figure it out because that's the only way you're gonna learn.
Nick:Yeah. And, course, because yeah. Yeah. Of course. And and that was was also safe, you know, because I was on my own branch, and if I messed it up, they would just not not, you know, not pull it back in and, you know, give me comments during the review and and and, you know, save me from drowning.
Nick:But luckily, I was able to to figure it out. It's something I enjoy about this age that we're in. You know, we are, you know, doing so many new things, and you can always ask for help for one of our AI friends. Yes. It's just so much easier and and also fun to just learn something new, and that's something I enjoy.
Tyler:Well, yeah, I like that it's made it more accessible to, like I guess in that example, did you use the helpful AI to kind of decide like, help you decipher which what are the different changes, or is it a really classic terminal? Here's the red. Here's green. Which one do we take?
Nick:I I asked ClothCode for help. Mhmm. But in that that study mode, that that that's that's you know, I asked it to, you know, walk me through it and let me let me figure it out. But, you know, but, you know, because the the first thing I did was normally, you put your branch into Maine, but what I did first now was to bring Maine into me, into my branch, you know, just to make sure I was all caught up because Yep. Less if if eight people work on the same thing and you work on your own branch and it's a little bit complex, it takes a bit longer, other people are doing things that do get pushed into main, so you get behind, you know, and that could cause the the merge conflict.
Nick:So I just wanted to make sure I did that very first basic step right. You know, what's the correct command I have to put into the terminal? So that's the kind of AI help I got because I Yeah. Never had to do it before, so I just didn't know. And I'm not googling anymore like a crazy person.
Nick:You know, I just cannot stand all the cookie banners and the advertising and the SEO fluff. Mhmm. You know? So I just asked, like, what's the, you know, what's the merge main into my branch command? What should I do?
Nick:So yeah. And then, you know, figuring out red or green, like, what like, a or b, like, who's right? Like, that's something I had to figure out on my own because, you know, AI tool will say both are right. You know, it's a matter of, you know, decision making.
Tyler:Russell will pick who did it first. First come, first served.
Nick:Yeah. Yeah. It's, you know, it it turns out we we did our own things, so I took a bit of theirs and then kept the rest like I did it. You know? So we we were in the same area, but not really touching the same thing in a literal sense.
Nick:Let's say, if we we if we would have had a a red circle, they made it blue, I made it square. You know? So that's both kind of fine. You know? Yep.
Nick:I see I see you being a bit confused, but it's not like we had a red circle. They wanted green, I wanted blue. And then Yeah. Which one should it be? Like, both could exist together in a sense.
Nick:You know, the metaphor is getting away a little bit from me, but, you know, going back full circle, it was great to learn. I can recommend this to any designer trying to become a design engineer. You know? It's, you know, creating code slash writing slash generating, that's the easy biz. You know?
Nick:It can anyone can do it. Even marketing people or HR people can do it. Yeah.
Tyler:Exactly. It's it's those little nuances that you that you don't normally encounter. Like, I had one recently where I pushed I had to push something live, but I forgot to turn on an environment variable, which was the crux of the entire experience. It's like, I pushed the changes live. I don't see it.
Tyler:Why isn't it why isn't it working? I think, well, there's this little thing called an environment variable, which is essentially like a feature flag to turn something on or off or make something invisible, and I didn't know that I had to do that. Did it AI hit.
Nick:Did it break did it break anything?
Tyler:It just didn't show up at
Nick:all. Yeah.
Tyler:Yeah. Like like, my work our workflow is basically I push something to GitHub, and then the developer pushes it to the live site. So in that translation, like, you didn't push my changes, but no. Actually Yeah. You did.
Tyler:I just AI created an environment variable on my behalf, and I didn't know it. So I wasn't paying attention. Yeah. That it needed to be on
Nick:Yeah. You just clicked commit sync done. Yeah. Yeah. And it happened happened to me too.
Nick:I how many times I struggle with ENV files, also because different people do the same thing. Like, they just make a few changes. Mhmm. And then I I can see my my floating tiler hat appear in the clouds again. Like, you just need to communicate, and documentation is your friend.
Nick:I'm like, oh, yeah. Of course. I should write down that there's a new ENV variable. You know? It's collaboration and communication is key.
Nick:There's no AI tool that can take it away.
Tyler:No. I think we have to we have to overly you have to double down and overly communicate on things.
Nick:Yeah. Yeah. I think it's needed. I think a willingness to learn and being a nice person and and communicating well, you know, grammatically with capital letters and exclamation points and just being friendly all that together is a skill, a very important skill. You know?
Nick:It gets you through the door also when you're looking for a job. You know? Just write yourself.
Tyler:Yep. Part of your brand. So, like, all the all the things need to be all those environment variables of your personal skill that has to be on.
Nick:Very good. Impressive.
Tyler:That was that was sloppy, though.
Nick:Yeah. No. No. I mean, this it's I I got it. Alright.
Nick:Let's let's try something new, you at the end of the episode, you know, the thing at the end of the the the thing I noticed during a week, you know, design related. You know, be it a a good thing, a blooper, something silly. I have something. I saw as in my banking app. So at the end of a bank transfer Mhmm.
Nick:At the bottom of the page, you know, where it used to say, well done. Return to home screen. It's, oh, by the way, get an iPhone 17 Pro at a discount now exclusively for, you know, bank name. And that that didn't sit right with me where, you know, personal finance, that's something so, you know, sensitive. It's your thing with ads appearing there.
Nick:It just felt out of place. I didn't like that.
Tyler:Yeah. I feel there. Because I'm in that space, and it's something that we're exploring, but it has to be a bit tasteful because you're dealing with people like, you're dealing with people's money, and then you don't wanna be too salesy. I had a similar experience in Wealthsimple. It's like, transfer all your investments, and we'll give you a Apple AirPod or whatever it is.
Nick:Yeah. Yeah. I think if you need to to you have an Internet provider here. They're struggling. So what they're doing now is, like, if you sign a twelve month contract with us to give to get Internet and TV, you get a PlayStation five.
Nick:Like, if you need to do that to convince someone, like, get this unrelated thing, I think that really speaks to the the desperation and also the quality of your service. Because if the quality is good and you have a good name, good brand, you don't really need to, you know, trick people with silly gifts. Yeah. And I really think, you know, this is mean, this is a short section, but I I I think it's you know, there's a design lesson there for sure, you know, strategic about how people see you and how you can easily ruin it.
Tyler:Yeah. That's a big brand mistake because that you'd probably wanna be more delicate and lead with value, and then the the value all after your promise should be, oh, and you get a a thing afterward. It's like an it's not the first thing that you're going with. It's like, you have a problem. We have a solution, whether it's a a new savings account with a lower lower fee or, like, an whatever it is.
Tyler:And then, oh, you also get this thing as a nice bonus.
Nick:Yeah. Yeah. Yeah. Exactly. I mean, that's that's that's it.
Nick:So be better orange bank in The Netherlands. Orange not being a
Tyler:Shot fires.
Nick:I can I no? No. I I mean, I can say that because we have multiple banks in Netherlands with an orange color.
Tyler:Oh, okay.
Nick:So it's not it's not orange as a brand name, but, you know, it's our national color, so everything is orange.
Tyler:I figured. I figured.
Nick:So for all thousands of listeners that we have, you know, if you have orange in your bank color, you, you know, you should think about your choices a bit more.
Tyler:Fair enough.
Nick:Yeah. Alright. On that on that bombshell.
Tyler:Alright. That's another episode in the bag.
Nick:Yeah. Great episode. By the way, if you're stuck second guessing your work or trying to figure out your next move, drop a question in the comments or leave a review. We might actually feature you in one of our future episodes.
Tyler:And if you got any value from this episode, hit subscribe wherever you're listening. It helps more than you think.
Nick:You can can find everything else, resources, articles, and more at designtablepodcast.com.
Tyler:Thanks for being here.
Nick:See you next time.