dev_to_design: Clayton Gray
Bios:
Ricardo Delgado
VueJS Frontend Developer
Twitter: https://twitter.com/ricardod_dev
Github: https://github.com/rdelga80
Dev.to: https://dev.to/rdelga80
LinkedIn: https://www.linkedin.com/in/ricardo-delgado-6ab12a93
www: https://rdelgado-portfolio.web.app/
Clayton Gray
UX Lead
Ricardo: I’m very excited about this because we’re on the same page about lots of things, and designers and front-end developers should be best friends. Unfortunately, we tend to be hidden away from each other, like Romeo and Juliet.
What’s your view of frontend developers? Do you have any experiences or perspectives that come up?
Clayton: Yes, especially because I used to do it! I still do it.
For me design and frontend development go hand in hand — we design something and then we’re dependent on frontend developers to build out our vision.
I respect a frontend developer who has an eye for detail, but a developer caring is the biggest thing. We’re lucky a lot of developers at this company do care, they want to make our product awesome, which is good. I think that’s important.
I think frontend developers have their hands full with getting a feature to work and expecting them to carry design down to being pixel perfect is hard. But if someone cares, that’s all we need.
Ricardo: As a non-designer when I design something I’ll think, “this is such a cool design,” but then I’ll see what a designer is doing, and I’ll realize what I made was from 2003 and that I have no idea what I’m doing.
I really admire designers because I tend to think the more tech heavy you are the less intensely you can pay attention to design detail. Like it rips your brain away from details the deeper you dive into code. That creative side, where designers get to live, gets pushed back.
I think designers are artists, and I also think developers are artists too, but in a different sense. I think we’re artists the same way writers are artists, and designers are akin to visual artists.
Clayton: At certain jobs, or in my side projects, where I’m the frontend developer, if I’m getting very focused on the development part of the project it’s hard for me to do design at the same time. That’s why for all my side projects I usually depend on a UI library like a Bulma.
All the colors are set, for example, and so I don’t have to worry about that element.
Sometimes I’ll be getting into the nitty-gritty of one little thing, and I’ll be like, “I don’t need to be wasting time on this right now, just code it!”
Developers and designers need each other to be awesome.
We need developers to figure out how we’re going to bring our designs to life. Logistics is a great word for it. The logic of it all and then I think we both do a pretty good job of, “does this look right in the end?”
Ricardo: It’s the magic of everything coming together.
And what I wanted this discussion to center around, and we’ve talked about this before, is Component Driven Development, which to me is the secret sauce for creating incredible UI.
Because I focus a lot on unit testing, my development perspective is that everything breaks down. And I think even with design and components that’s what I try to do, and then what it turns into is creating components to be more generic.
Clayton: And by generic, do you mean more general?
Ricardo: Yes, exactly. The counter example is when a UI codebase gets really topic focused.
Like for Sportsbook. Sometimes we’ll get a little bit focused on an active bet versus a standard bet, or something like that. From a design perspective those become two separate entities, and from a developer’s perspective, we have two separate components for them.
But I step back and ask is there a grander concept of a bet? And do those fit in that umbrella? And then, if that’s the case, can we design so that there’s things that are more generic to bets, like is there a title block? Is there a description block?
And then those things can be abstracted out and then we’re not even necessarily worrying about what the bets are but rather what they look like. And then everything pushes towards UI and design.
Clayton: Oh yeah, totally agree. We do that right now with our Sketch library. And that library has different components we can use that we designed.
So even with bets, for example, we do have reusable components within that — such as the money line offer odds component, which we use a lot.
I agree, every bet should look the same. And whether we have it documented or not, our visual language is that. Then the user can get that visual language figured out.
I think there’s a design experience where we want to convey that this is our visual language, these are our patterns and components. And if this is the same throughout then when it comes to handing designs off to developers then we can say this is a component that’s part of a new component, and just reuse and reuse.
Ricardo: The biggest attraction with this whole mentality is refactoring. Because often it’ll come down from somewhere, “we want this to look different.” And I think the flaw of not falling into CDD is now there are 90 places that need to be updated.
And that’s if you’ve documented that it’s in 90 places. There might be changes needed in a bunch of different places that you don’t even know, and then you spend the next year with regression bugs or finding yourself working on something thinking, “wasn’t this supposed to look like this thing we refactored a few months ago?”
Instead, it can be like, I have this one component, this one component is being used in lots of different places, so if there’s a decision to change the border radius it’s a minor issue rather than a time consuming one.
Clayton: And haven’t you found that when you write a component, that at first, it’s relatively small, and it has the title, odds, description, event name, etc., and then in the future, as it gets more complex, when you refactor, and then that bigger component breaks down to two components, and they inherit each other, we kind of end up doing the same.
Sometimes I think, I should take the extra 30 minutes, break it out, reference it back, and do it elsewhere.
Ricardo: I think that’s the “big challenge.”
Making something from scratch is the most enjoyable thing in the world. If I could have a job where I could jump from project to project where all I’m doing is building the beginning stages of a UI library that would be a fun gig to have.
But I think where you really prove your bones as a developer is if you can build something that lasts over time. And is the thing you’re working on now going to be, what’s that word… antifragile? Will this not break once you, or other developers, start messing with it?
Clayton: And things change, and I don’t know about developers, but with us designers we’ll design something, and you look at it 6 months later and it’s like “we need to update this.” Then it takes 6 months to have the time to update it, whether it’s the visual part of it or something else, but it just needs to be worked on more.
Ricardo: I previously did an interview with Jason Krol, who was the first web developer on the project, and we were talking about how the enemy of good is perfect.
It’s important to push out code, you have to work on it, the project has to keep moving forward. But that’s why lately I’ve been personally trying to make a push for this concept of Component Driven Development and abstracting out concepts, because I think when you abstract out concepts, you’re making it so that development gets faster and easier to change.
As a designer, when you are working with developers, during the collaboration process what’s the type of feedback you like to hear? How do you like the process done so it can make your job easier?
Clayton: First, developers are the experts on what’s possible, so that’s always the big one. I know for me, when I’m designing, I think that I need to know if this will be ridiculous to do. I kind of have an idea of what it takes to do web stuff, but most designers have never coded.
So that’s number one, obviously.
Two, developers see what we don’t see. During development you click through it and it helps to know if the flow feels right or if something seems weird.
I’m always open to hearing developer’s feedback on the overall flow, and even the design. Because most of the time if it’s hard to program it might be an indication that something is wrong in the design.
The mix between design and code is a touch and go sort of relationship. It is tough to know where we draw the line of what we can do or not, because sometimes you really want to do something and you’re thinking, “this is such a cool and slick thing,” but then it’s really hard to implement at the same time.
So where do we draw the line? That can be hard.
I’ve found that developers are pretty good about raising the flag that “this seems kind of weird,” “this isn’t consistent,” and those sorts of objections are helpful for us.
Ricardo: For me sometimes my biggest push back is usually the data doesn’t make sense for this, or something doesn’t make sense where it’s being placed.
It seems like it easily happens because we get siloed off sometimes. I feel bad because designers can get so far down a design rabbit hole, and I think “I wish I could’ve been there a little earlier to catch this.”
And since you recently became nested in our Pod [development team], it feels like we’re communicating issues earlier with each other.
This is my Barstool Sportsbook question — are you a sports guy, and what are you into if you are?
Clayton: That’s a great question.
I grew up playing basketball, it was the only sport at my elementary school. If you weren’t playing basketball, you weren’t really doing much. Plus, I’m tall, so I had to play basketball.
I never really watched sports, my parents weren’t into sports, and it wasn’t until I moved to Philly that I got into watching sports. Philly is such a sports nut kind of town, and my friends were into sports betting.
I used to think “oh no, that’s illegal, I’m not getting into that.” But they still did it, and it seemed like they were going through extreme lengths to do it. I didn’t get into it until it was legal.
I watch hockey now religiously, the Flyers, or when football is on, NFL Red Zone, fantasy football.
Previous dev_to_ Interviews:
