Code & Pixels
A couple of UX Engineers, navigating the intersection between design, development and everything inbetween.
Code & Pixels
1: What is an UX Engineer?
Join us for our very first episode of Code & Pixels, where we talk about who we are and what we mean by “hybrid” roles.
Links:
Hello? Hello? Hello. Welcome to the first episode of code and pixels. yeah. So this is the first episode. So things might sound weird, but we're going to, it's like a product it's going to get better over time. So we're going to do some intros
Kelly:hey, what's up morning. I am Kelly Harrop I am a senior UX engineer working on the Intuit design system. I'm in Dallas, Texas. And, yeah. Welcome to the first episode
Adekunle:hello? Hello. My name is Adekunle Oduye I am a Brooklyn based UX engineer. Currently I am funemployed. But, there's some things in the works. I've been doing design systems and UX engineering for the past 10 years. And, yeah. Welcome to the first episode and today's topic is going to be around what is a UX engineer? Kelly, what do you think when people say an UX engineer, what do you have in your mind?
Kelly:I know I have something in my mind, but I think everyone is confused when I put these two terms together and they're going, so wait, design, or do you write code? And honestly, I first heard the term, from an article from Emma Boston. And I was like, what is this? This sounds interesting. What I gathered was it's about using UX principles, design thinking, user experience. And combining that with the skills of a front end engineer to build out experiences. So it's less about, having a design, giving it to someone and then they code it. It's more like working together. You're working with designers, working with engineers and you're translating all these design decisions into. Experiences. So I like to emphasize the UX part because it's not just design into code it's about a whole experience that people get to see at the end of the day.
Adekunle:Yeah. I like what you said about UX principles but with the split of front end development or engineering, I don't, I think I was technically a UX Engineer without even knowing the term. I was just like, I just like to get things done. I think it started my early career where I was like, I was thinking of, I was designing, I was mostly a designer when I first started out and I was like, oh, let me pass it off to an engineer. And the engineer was like, oh, this thing impossible to do. And I was like, what impossible I don't know what that word is. So I started just like building, like getting into like front end and, the good thing was like that kind of allow me to better communicate engineering. And, when I started making shifts, you engine like doing more, for an engineer, I still had that be able to talk to designers. So I always say that it's like that area where design meets development, to say, but I've had molded like definitely, multiple roles in, in the past. So I had the term UX engineer and, design technologists, And they're different, but the same, I will always say that like ux engineers more in the case of the hybrid role, working in, the engineering department and then design technologies, that is the hybrid role that works in design. There's like things around prototyping, design systems that I think often do. But yeah. I'm wondering, what do you think is the a good skillset for background for an UX engineer.
Kelly:my background is pretty much design have been pretty much a UI slash UX designer, which I know is already controversial with the flash and combining the two. But honestly, I felt that with a design background, you understand what potentially could change. And in the future. Today's four pixel border radius is tomorrow six pixel border radius. And so just understanding, visual trends and, someone does some cool box shadow effect, and then it's cool. How do I make that? And just going, just learning, being curious, I think is one of the things that we just take for granted. I know like I'm always just surfing Twitter going. Oh, cool. What's that code pen? Or like what how'd they do that? I'm fascinated by the one div CSS art stuff. I see all the time. It's I it's, I think it's witchcraft. It's amazing. I'm very jealous of those folks and just that learning and being curious. I know, like for me personally, I write a lot of CSS and I read a lot of throwaway CSS. It's more important. And so just not being married to the pixels or the code, I think is really important and always adapting, always finding out a better way of doing things I think is one of the key parts of the job.
Adekunle:Yeah, I think, I also agree with that. I also started, I guess I started as an art background. Art and design is different. I learned that in, art school. Cause I was like, oh yeah, I could just answer. But art is more, I would say. and design is more objective. But they share some of the same principles. So yeah, I did art throughout, elementary school to college. And then I started out, my goal was to do like print design. Again, this is like throwback. Cause you know, I want to say printed designs yet. I was like, yeah, I'm working at a magazine, a fashion magazine company, and I'm going to work on editorial design. And then I got introduced to the web. And the key thing was like, I was deeply into focused on design first. And then when I started to, work in the industry, I was like, oh, the front end stuff. This is sounds pretty cool. My first coding class was actually. I took a dreamweaver and I hated it. And I was like, Ugh, I never want to touch code again. But again, that's not real like real coding per se.
Kelly:a much different experience for dreamer? Because when I learned to code, it was through notepad plus, and I was like, how do people make websites, music? And then finally, one day we were introduced to Dreamweaver and just, it was like, you've been holding this back this entire time. You're telling me I could see all of this happen in real time.
Adekunle:But the what, but the one thing I remember was like, they were like, all right, how do you like adding link? And so I was working on like my own portfolio side and it was like, okay, if you have to add images and whatnot. And I wanted to change the image from left to right. And it was like so much work to do that. And I was like, what, why is it so hard? Do people actually build sites? Is this like how it is? And I was like, oh, and it didn't work. And it was just like, and again, it was just me. It was me being a new cause I was like, oh, I thought it was going to be faster. But, little, I know 10 years later I'll be like doing. Full time, but, yeah, my background's in art and design and I think, it's pretty helpful cause I do believe it's easier. It's harder to learn art or design versus, programming or development. And I'd say that because like sometimes art, you break the rules and sometimes you don't break the rules. And sometimes like people were just like good art and that art is like very subjective. But with engineering, there's like a set of practices that you can just follow. And usually everyone's going to follow me again. There's like different tastes or whatnot, but, that's what I believe. Cause like I've tried to help engineers learn how to design they're like, I just don't get it.
Kelly:I think it's the opposite. I'm on the struggle bus constantly. Just things that everyone's oh, it's so this concept so simple, Kelly, why don't you like it's so simple. I think the latest thing that I was thinking about the other day was dependencies versus dev dependencies. I couldn't, they think of a better name to separate those two, but like they're both dependencies. Why do I have to know if it's Devin? And I remember like some of that stuff we take for granted, like now after we set up, the hundreds of repo, you're just like, oh yeah, it's like this, but for a new person, it's just these things sound the same.
Adekunle:I agree with that. Cause. Because I do. I do think it's like the learning curve. They have to learn the language. But,
Kelly:Yeah. You have to learn a language and not all of us are. Holland linguists.
Adekunle:You learn English and then you could have. You could basically speak other languages too, which is like kinda the case of like you in one programming language, then you can go to another programming language, but the syntax might be different. So that's what I was kinda thinking. And I was like, that's not the same with like art or designer. Cause like I can learn how to build websites, but I'm like, all right, I want to be, I want to build a building now. I'm like, okay, I could do that easy. It's not going to be the case or let's say interior designer. I think there's like some principles that are the same but. Like it's like the physical world. So you have to learn, how to work in that space. So that's what I got to say, because it's sometimes again, there's like a lot of what they call like design patterns in engineering. And you use the same design. In any program, language is always this is actually pretty good, because you could still have those same standards and whatnot, but you try to do that in art, like that, or design, that's probably not going to work because like you were like, okay, this is I'm going to go with this. Very modern look. But then again, depending on where you work or even who your audience is, they have different tastes and like you have to test it out and see what works. So I think actually both of them are, but. I just remember my journey, like trying to learn design. And again, it took me and there, it took me like 20 years to get get good at it.
Kelly:Yeah, I just, I just browse dribble like every day and that through osmosis and just looking at dribble, I just gradually just, I was like, how does, like, how do they do that? And I would just pull in something in, I think it was like sketch at the time and just like, how do I recreate this? And then I just did that for, I think I did like daily UI. For months until finally I was like this the same terrible.
Adekunle:You said the magic were a dribble, which could get you in hot water.
Kelly:Oh, no.
Adekunle:I, again think dribble is good for inspiration, but I've seen some stuff and I'm like, all right, I want to see the actual product that uses this, especially rare. Like the UI looked like a rainbow and I'm like, all right, I want to be able to use this. I want to see it, like even using this to say, oh, this is pretty good. Because I think that's the one thing I would say is it's good for an inspiration, but like some of them stuff is like very out there. And I'm just wondering if it's like real product UI, but it could be good resources if you use it.
Kelly:There should be, it should come with a warning, like careful at your own risk.
Adekunle:He was like, be careful, this is not a real product. This is more for inspiration.
Kelly:Speaking of product, maybe just quickly go over design systems and what the connection is between not in hybrids.
Adekunle:Yeah, for sure. So I kinda define design systems as a collection of components, guidelines that basically, are used to create a product UI. And I would say was like the perfect place, as a hybrid because, it has, a design and development aspect of it. So you could do the design, you want to be able to make work so that anyone can actually use this. And I think a good article, Jina Anne had a good article about like why hybrids are perfect for design systems, more in the notes. But, I would say that's like the perfect place because, I know early in my career, like there was not many, resources for design systems, and usually, sometimes it usually started within the actual design department. So you have to get creative and be able to take whatever you design and actually make it code. So I think that's like the perfect place, to, as hybrids to thrive in. I know like my first design system experience, I only did it because, I was frustrated that there weren't pre defined components that I could just take and plug it into my, to my work. And this is the time where I was working with. W the main artifact designers we're producing we're like front end prototype. So it was like we had designed stuff and then you have to code it. And it was like, if I want to be able to like prototype very quickly, I needed these kind of have predefined components. But, I think it was the perfect place to thrive because I think, you work on these small, isolated, elements, but they have big, impact because there could be used in multiple places. Looked into actual products. But yeah, I wonder you, what's your thoughts on like that?
Kelly:So for me, my experience has been primarily with a design system it's for multiple products and brands. And so thinking about like, how do we have, one component. That can support all these different personalities and look and feel. And so working on theming and just having a base set of components is critical because you essentially need to be as efficient as possible and understanding the limitations. Like what could someone want to insert their own brandable? And thinking through how that extends past space functionality. And so design systems for me is about, just thinking through like the modular aspects of an experience. Like I like micro interactions. And so when I first got started and I was still learning how to even. Create a box on the screen, just having these little small little micro interactions and I would just post them and how do I even stuff we today is just, walk in the park. At some, at one point, I didn't know how to make a button change, color on cover. I didn't even, I was still trying to figure it out stuff out. And so we start getting into, learning. Pseudo classes and all these different pseudo elements and all these different ways of working with styling. And I think, in, in envisioned the components with design systems, there's like tooling and content and a bunch of other things that. Aren't as visible to an end-user cause end-users like, oh, cook components. I can build things. And there's just like a lot more to it than that. But that's usually what gets most of the attention when someone releases a design system, it's oh, shiny components. And for me personally, am interested in what can I customize out of this set of components? Are there design tokens? Are there utility classes? Like what else comes with it? And I think that stuff is really exciting.
Adekunle:Yeah, I agree. I think, you mentioned micro-interactions, that's I, one thing. That works well within design system. Is that that's probably the only place where you able to tell that story and like, how do you use, animations or micro interactions and then see them in action. Especially when you're working with more complex, patterns and components. Based on my experience, like that's the one thing like. Designers struggle with, especially if the amount of animation, a person is like, what's the right amount of animation and where should they use it? Because you can definitely go to like many applications and sites and they have like emissions all over the place. But again, there's like reasons why not to do this. And usually having a, a good design system that kind of not only shows you how to do it, but it's more a case of educating you about the best practices, is super simple. And this is where, from the standpoint of like hybrid, like you understand like, all right, from the design aspect of like, why it works, but then learning about the implementation helps you really, build empathy for the engineers. And then you're able to figure out how can we make this knowledge? Like, how can we package it up that like anyone can use it, without thinking about like the implementation, which I think is. I think that's probably like the whole thing about like design systems. It's how should people use this and just make an easier for folks? Because I think that's, the biggest, Shalom I've seen, when tackling a design systems,
Kelly:Have you, have you used a no code solution before?
Adekunle:It's principle, no code. No, that's not it right?
Kelly:Yeah, like love flow or.
Adekunle:Oh, yes. Yeah. What flow is for you, Austin? I'm not gonna, I ain't go. I have hesitations about them because no code have been out for a while. And for people that remember, I think FireWorks, was supposed to be like a no code solution. And then. When you look at the, their coat is, again, some of it works and sometimes it doesn't work and you have to be like, do yourself. And I was like, all right. If I got to go in here, like every once in a while to see like, why, like this thing is not working, then I should just build it myself. But I've heard things about good things about a web flow, especially from a lot of, designers. I could just build this up. Okay. And it's like actual using like the latest, greatest technologies and whatnot. And, it makes it super easy, but I don't have that much experience with that, but I'm wondering, do you have a workflow or any other no-code solution?
Kelly:Yeah, I played around with that for a bit. I like that. It helps from like an education standpoint, teach some of the, like some front end principal. And things, and it teaches the limitations of the platform, which I think is really nice to, and there's like a UI aspect of it, it's not just someone having to like, read a bunch of stuff and figure it out. Like they're playing with the icon, the icons they're setting values. You're seeing like what possible values that they can use for, anything from oh, I didn't realize you could customize it. Borders and shadows and learning, like what the different numbers mean from a shorthand aspect. I think that's something that is really nice. And I like how you don't have to build out separate things to show responsive experiences. Cause I know a lot of folks, like we're building out things, in Figma and you have multiple frames for different break points and I and what flow, how you have the different toggles for the viewpoints. And so you can just figure it out. You can just build while you're designing it in your head and not have to worry about like duplicating this over, changing it, duplicate over, changing it. And I don't know about you, but when I'm designing I've I just, I can see it in my head. So I don't have to do all those different. Ports if I'm coding it. But I know part of the struggle is like, when you're talking about having someone else code a design, like sometimes it just, some stuff just gets lost from the original person working on it. So do you have any stories or like things that have helped you when, in terms of working with another person and like collabing on. Making something into like from design into code, like what's useful for you.
Adekunle:I have so many stories, but I'm going to stick with one. Actually rented the issue before, like when the first, when we're like responsive design was getting popular. It was like, everywhere like that. And I was like, okay, cool. Like I want to design it. And then I remember the first time I was like, all right, I have a desktop view. And I got it was a tablet or I don't know what it was the time, but it was like, basically I had to do three different screens. So I did it for the homepage and I was like, wait a minute. I got to do this for every single page. I was like, oh no. This is this is not how it's going to like, and I just saw like the inefficiency of that, because first I have to, and this is what I work in an agency. So usually it was like, you design it, then you hand it off. And then to the engineer and the engineer were like, okay, yeah, like this could work. This doesn't work. And you can make, basically plans for anything that comes up. But I was kinda thinking about it cause I was like, all right, I think it was like 10 pages on this, like a website. So 10 pages, times three that's 30 pages. And if I have to like, make one little change, and this is before like sketch, like reusing like Photoshop. So I just looked at my, I did a calculation in my head and I was like, okay, this is not going to work because I'm going to have to like, literally, if there has to be a change, I got to do it like for 30, like instances and whatnot. That's when I started to get familiar with some sort of like coding best practices back to skin. And I was like talking to engineers, I was like, Hey, do you like writing code? And he was like, I don't like doing front end. And I was like, okay, cool. So I basically was just learned it and depending on where I went, like usually, the engineers would be grateful. They're like, oh, wow. You really have this cut it up. So they could just cook the back end or whatever like that. And I truly believe not all designers have to code, but I think if you do, and if you want to do it, that's super beneficial because there's a lot of repetition that you can remove from your process where you don't have to like, have this 30 page mock. And then also, I remember back in the day I was doing a lot like annotations and we'd be like, okay, the user clicks, here you go. I was like, I don't want to do none of that. So I like having, that's why I liked like doing like friend and person, because it's like one place that like shows like the whole experience from start to finish. And a lot of it's it's telling the story and it's showing like how the animation, like I'll hold all that stuff. And as it, as a front end engineer or back stack engineer, you can take that and be able to use it and you don't have to start from scratch. So I that was like one story, because I think, in most cases, it will make your life easier, but also you're able to iterate quickly. So I'm always thinking about what makes the process easier? Not only for me, but like people around me, but yeah, that's my story.
Kelly:Yeah, I, you talking about going back and forth between like code and design tool. I know I've struggled in the past where something gets updated just in code and then the designs behind or something gets a day design and then like the codes behind. And then it begs the question, what is the source of truth? Like which one do I follow what's? W where was the where's the last place that the decision was made? And so I think for me, I love docs, like documentation, just having, like a log of all the things that have happened and keeping track, but I know, on a few teams like that can be. One person's responsibility, but really like the whole team should be committed to making sure that things are recorded. Just so you know, a new person joins the team. They don't know what's going on. Like having something for them to, water onboarding, check out to get a, it, figure out what's happening. And I think tools like, storybook zero hype. Things that are making documentation easier for folks to contribute to is super important. I think we don't spend enough time onboarding folks to, documentation practices and learning how, like, how to contribute. And I think, like when you think about where's the ass coming from, is the ask coming from an engineer, a designer or product manager. Customer, like so many people want change and you do all this work you put in the effort, you changed all that stuff. How do you measure impact if you don't like keep track of the journey? So I think that's something that we, as an industry can improve on.
Adekunle:Yeah, I agree. And I also agree from, not only from a design system perspective, but also a UX engineering, because if you look at designers, one of the things that's super important is like being able to like, document like your decisions and findings. So if you do any like usability testing, whatever like that, you have a document that says like you never know. And that same thing for, in development, because usually if you're like building something and you want to leave documents for anyone in the feature, because you might have to do specific things and it's always good to communicate why. And, I've been in some code bases where it's. You go in there and there's no documentation. And you're like, okay, like, why is this thing here? Like, why are you using this? And in some cases there, there's a reason why it's there. And you're like, all right, I don't need this. So going to delete it. And then, something that explodes and you break like the production and whatnot. I would say documentation is important because it not only educates folks, but also tells a story just in case. The person that created it, isn't there, or maybe they're working on a different project would have liked that helps share that knowledge and whatnot. I D I definitely, wasn't a big kind of documentation, cause I was like, I want to be a designer. I don't want to write in where it's just I want to just know design UI, but I suddenly realized like, from like the great designers that even engineers, like they're very good at. Documenting stuff or even like writing copy, which is like something new. If you've thinking about it from a product design standpoint, people are not using your product because, or your UI because of like the, how it looks, they using it, because the information that it gives you, then sometimes you have to be able to like design words and some people are not fortunate to have a content designer or a strategist on their team. That plays in a role be able to write, in a way that, it's clear and concise. Again, for me, I definitely got better because early in my career, I was like usually working by myself. So I didn't have to like, definitely to too many things, but as you work in bigger and bigger teams, that becomes more important because you're basically writing documentation for everything. You will create a PR you have to write some sort of, documentation for that. If you're. Writing code, you have the right documentation. So it's like everywhere and it's a good skill, I would say, to have, because if you're able to like, it will open so many doors for you, which is, again, I wasn't a strong writer, but I think I've gotten better over the years.
Kelly:If no one reads it, this is documentation actually exists. I am like, oh, you read my words. That means a lot. And, it makes it better, right? Someone can give you some feedback and I, now your docs are way, way better. Speaking of like better and, our impact on the team. I wanted to talk a little bit about, what success looks like, being a hybrid, working on, design and code and what kind of change, like what kind of change happens to a team when you have that kind of skillset? And so for me personally, when we started hiring more UX engineers on the team, we know. Significant improvement on our QA processes. And part of that was just less time going back and forth because previously it was. Oh that padding's off by two pixels. That font size, it's still, it's a little bit off. Just everything. That's just a little bit off. And then those things would get updated and there'd be another round of QA. And it's oh, this time, these other things got highlighted to fix. It's okay, it's just around and around you go.
Adekunle:Yeah, it makes the QA process, streamline, because as UX engineer, you're empowered to make those changes. So if you see if there's a discrepancy between. Like the button component. You could change it from the code perspective, but also you can change it from within Figma. In some places I work, whereas like the engineer is not comfortable with like design, they have to reach out to someone else. And you think about the more people add as long as it's gonna be. The QA process becomes more shoe line, but also just the idea of being able to be more proactive with fixing things is, a good thing. And I would say another thing is around just like language, cause like again, design is, it is, it has the language engineering has. And when you had these hybrids end up happening is that you becoming like a bridge or kind of a communicator where it's you're able to speak these two languages, and you could break it down and you understand how like designer things, but you also understand how engineer thing, they become super helpful when you're building a new think. Cause I've been in multiple scenarios where. No designers are like doing like explaining stuff, but then the engineers are like, wait, what? I don't understand what you're talking about. And, sometimes it's hard to communicate that unless you can break it down to by the third terms. And it's the same thing with like engineers. Cause like sometimes they're talking about oh, like it was like, I remember we were talking about Webpack and whatever like that. And engineer was like, wait, what is Webpack? I enjoyed trying to explain it, but they explained the way where it was like still technical. So I was able to explain it how he's like to use food. I forgot the example I had, but it was something with like
Kelly:I want to hear this word pack food analogy, please.
Adekunle:Wait, what was it? So I kind explain it where it's like, all right, you're at a restaurant and, Instead of, let's say they, there, you could order like any type of food. So there's like African food is Chinese. Food is there's a whole bunch of it. And I want to order like Chinese food. So in a traditional way, if you already, Chinese food comes with all the other foods together. So it was like, all right, like you got, I want this one. Dish, but it comes with like this, all this other food that I don't want. And it's like pretty wasteful because I can't, I just want this one thing. So entry, Webpack, where it's okay, it'll take your order. And then it basically could just say like, all right, what do I need for this specific order? And then it was just delivered to you. So it's more efficient, and it's, and you get what you want and it's faster. That's another. Again, that probably is not like the best analogy, but I explained a lot of stuff with food because it's just, or even like the restaurant industry, I think there's a lot of like correlation between that and like engineering, because, if you understand like HTTP requests and all this stuff, like they use a lot of like restaurant analogies, but that was my way of explaining it again, that might not be a hundred percent perfect. When you explain to someone that has no knowledge of like how the, whoever else they're like, oh, okay. That makes sense. It makes things more efficient and, you get what you want and it's faster. Okay. They got it. But I think that's it, unless you understand, the, like the language that each of these like disciplines speak on, you're able to better communicate. Then the competition becomes better. Cause I know like when I work in specific teams, especially where there's a couple of hybrids, like the project just goes very smoothly. It's just it's like effortless and it's it's like music. It's you work in and it's like, all right, I got this. And then they know how to lead and you know how to follow it's just like a beautiful thing. I will also add as a UX engineer or. You have to be like, selfless to a certain extent, because again, since you're able to do multiple things, you want to be able to, for others to work or whatever they want to work on, and then you just figuring out how to like work on the rest. But, but yeah, that's like my thought of it, because again, it's a unique position. It's a hard position, but I think once. Get a good grasp on it. Like it's just a super fulfilling.
Kelly:Yeah, for sure. I think the most rewarding part for me is just this like sense of relief at the end when we're shipping out, really make releases and. Seeing like the work, like everything falling in line and, you can, if it feels good, like it's like a good feeling where, you know, everyone like understands what each other, like what developers understand the work that goes in from a design standpoint and science understand the work that engineers have to go through to make that come together. So I think just like that understanding and education. All the compromises have to happen along the way. I think people feel better. Like it's not about winning or losing. It's about can we meet in the middle and like how something that's both, catered to a customer problem, but also isn't, 5,000 lines of code to get there. I think there's like a nice, happy medium. That's. What I really enjoy about working with both is seeing that alignment happening.
Adekunle:Yeah. I feel like it's more relief on the design side than the engineering, because anytime I really something. I was like in my break, something. So I like add this like daughter I'm like, okay. If you make an update to some sort of, like your UI, library, Nope. That's internal. So that's easy to deal with, but like anytime you make a change, especially if. Something that everyone's using, there's this like relief, but I'm like, oh, like I might've broke something and it's happened before. I say, I don't, I'm never leave relieved until probably like a couple of days after a major release, because then I know that I didn't break something, but, I've been in it where it's alright, I'm done. And then just see all these slack messages about oh, like this thing is not working or this thing is out. And I was like, oh crap. So I think depending on what you're working on there might be some anxiety and whatnot.
Kelly:Yeah, for sure. All right. Do you want to wrap up.
Adekunle:yeah, so that was our first episode. Again, This is probably going to be, a product. So we're probably have featured guests in the future. But yeah, this has been a great first episode, Kelly, what'd you thought about the first episode?
Kelly:I think there's only, we're only going up upwards from here.
Adekunle:That is true. I was anxious because, I never done something like this before, and it's I'm learning a new skill, we'll see how this goes. And if anyone has any feedback and whatnot, feel free to reach out to us. But yeah. So then it's been a pleasure, Kelly.
Kelly:You Too Adekunle
Adekunle:See ya.