Harris rejoins the team and we talk to the Infinite Red designers about the challenges and aspects of designing for React Native apps.
Harris rejoins the team and we talk to the Infinite Red designers about the challenges and aspects of designing for React Native apps.
This episode brought to you by Infinite Red! Infinite Red is a premier React Native design and development agency located in the USA. With five years of React Native experience and deep roots in the React Native community (hosts of Chain React and the React Native Newsletter), Infinite Red is the best choice for your next React Native app.
Helpful Links:
Connect With Us!
Todd Werth:
Welcome back to React Native Radio Podcast. Brought to you by Brawndo. It's what plants crave. Episode 206, Designing for Mobile with Justin Huskey and Jenna Fucci.
Jamon Holmgren:
So I finally bought a new iPhone, actually. It's an iPhone 12. Robin, you have an iPhone 12, right?
Robin Heinze:
No, I have iPhone 10.
Jamon Holmgren:
Oh, you have a 10. Oh, that's right. You didn't want to get rid of it because of 3D Touch.
Robin Heinze:
Yeah. You were complaining how 3D Touch is gone. So now I don't want to get rid of it.
Jamon Holmgren:
Yeah. I don't know. I'm getting used to it, but it's not... 3D Touch was annoying at first, but then I discovered how you could manipulate texts by moving your cursor around and selecting things.
Robin Heinze:
Well, apparently, the software functionality part of it is still there, but not the little vibration, the haptic feedback, which is what I like about it. It's very satisfying. So I don't know why they took that out.
Jon Major Condon:
It is satisfying.
Jamon Holmgren:
Ironically, they actually call this Haptic Touch.
Robin Heinze:
Which there's no haptic. That doesn't make any sense.
Jamon Holmgren:
I don't get that either, but you can hold on the space bar and still move around. And then I did discover you can tap on the keyboard and select texts as well. So it is possible to do what I used to do. It's just not quite as convenient.
Robin Heinze:
Oh, no. I'm so attached to my 10.
Jamon Holmgren:
I was attached to my 10 as well.
Robin Heinze:
It doesn't feel like it slowed down at all. So I'm not motivated to get a new one.
Jamon Holmgren:
I was having a few little issues with it. Mainly with when I would call people, they would sound garbled, which I don't call people all that often, but it was just a little garbled. And then my daughter, her phone was going bad and she was pushing me, "Hey, dad, get a new phone." So she could have mine. So it was interesting. I did like my 10 though. I kept it for four years, but I named my phone Mimir and there's a story behind that. Or is it Mimir? I don't know how to pronounce it. Yeah, it's a Norse-
Robin Heinze:
Like a mime?
Jamon Holmgren:
... mythology. Actually Mim is another name for him. But he's a figure in Norse mythology, okay. And so there's a little bit of a story behind this name. And I have actually named all of my devices after Norse characters. This one was particularly good because he was a figure in Norse mythology, renowned for his knowledge and wisdom, who was beheaded during a war, okay. And then afterward, the god, Odin, who's the top dude in the whole thing, carries around Mimir's head and then it recites secret knowledge and counsel to him. So I thought that was pretty appropriate, I'm carrying around... I don't know. My kids think it's really weird.
Robin Heinze:
That's weird.
Jamon Holmgren:
My kids think it's so weird.
Robin Heinze:
Less do you think this is the podcast about Apple hardware and Norse mythology.
Jamon Holmgren:
I'd listen to that. They have a very narrow audience. This is the React Native Radio Podcast.
Jon Major Condon:
Question.
Jamon Holmgren:
... and I am Jamon Holmgren. Yes? Go ahead.
Jon Major Condon:
Can you change Siri's name? Because if you can, then you should change it to Mimir.
Jamon Holmgren:
Mimir.
Jon Major Condon:
Yeah.
Jamon Holmgren:
Hey, Mimir.
Robin Heinze:
I think you can change what Siri calls you, but I don't think you can change what Siri's name is.
Jamon Holmgren:
You can change it on Amazon.
Robin Heinze:
Yeah, Echo. I don't think it could be custom. I think it's just either Alexa or computer or something else. Echo. Something.
Jamon Holmgren:
If anybody's listening to this in their living room now, their Alexas just went off.
Robin Heinze:
You're welcome. I got to throw in an okay Google just for...
Jamon Holmgren:
Yes. Okay. So I'm Jamon, I'm host. I'm happy to be joined by my talking head co-hosts Robin, Jon Major, and we actually have Harris back today. Harris, welcome back.
Harris Robin Kalash:
Thank you.
Robin Heinze:
Oh, my God. Hang on. Sorry. Hey, Google. [inaudible 00:04:17]
Jamon Holmgren:
Nice.
Robin Heinze:
There we go. Sorry.
Jamon Holmgren:
That's hilarious.
Jon Major Condon:
It is hilarious.
Robin Heinze:
It actually triggered My Google Home.
Jamon Holmgren:
I'm done.
Robin Heinze:
Karma.
Jamon Holmgren:
Okay. Harris, you're back.
Harris Robin Kalash:
Yes.
Jamon Holmgren:
How you doing?
Harris Robin Kalash:
I'm good, I'm good. Thank you. Yeah, it's been a while. I missed you guys.
Jamon Holmgren:
Yeah. We missed you.
Harris Robin Kalash:
Yeah. The first time I'm in this one with Jon.
Jon Major Condon:
Yep.
Jamon Holmgren:
Yeah, Jon Major's joined us in the meantime to kind of bolster our ranks a little bit, but now we've got you back, which is awesome. So we've got four-
Jon Major Condon:
Double bolster.
Jamon Holmgren:
... of our hosts here. Are you back in Montreal?
Harris Robin Kalash:
Yeah. I'm in Montreal for now.
Jamon Holmgren:
Harris is a coding instructor at Concordia Bootcamp in Montreal and a React Native contractor for Infinite Red, is currently working on one of our projects. And of course, we have Jon Major, who lives in Janesville, Wisconsin, who's a senior software engineer here at Infinite Red, also the editor in chief of the React Native newsletter. What's going on, Jon Major?
Jon Major Condon:
Well, as you can see, I just got a new audio set up this week. So my audio should be sounding a whole lot better.
Jamon Holmgren:
And actually, I think it's the same setup I have, right? The same mic, same boom?
Jon Major Condon:
Same mic, same boom, deck and everything.
Jamon Holmgren:
And yet you sound way better. So it must not be the setup. And we also have Robin Heinze. Robin, you're running on two hours of sleep, I hear.
Robin Heinze:
Yeah. Toddler life.
Jamon Holmgren:
Toddler life. Yeah. Well, we'll try not to trip you up too much. It should be interesting.
Jon Major Condon:
Were you saying toddler, our CEO or...
Jamon Holmgren:
You know he listens to this, Jon Major.
Jon Major Condon:
Totally forgot.
Jamon Holmgren:
And we also have two special guests today because the topic is going to be designing a React Native app, Jenna Fucci and Justin Huskey. Justin is our lead designer here at Infinite Red. And he's been on the show before in episode 200. What's going on, Justin?
Justin Huskey:
Hey, everyone. It's good to be back. I have only been gone for a few episodes, but before you know it, I'll be running things here.
Jamon Holmgren:
Well, you can see how well-oiled this machinery is. And yeah, there's a lot of room for improvement.
Justin Huskey:
I'm glad to meet the two people in the world who use 3D Touch.
Jamon Holmgren:
Ouch. Jenna Fucci is a senior designer at Infinite Red. Specializes in mobile app design. She lives in Denver. What's going on, Jenna?
Jenna Fucci:
Hi. It's going good here. Finally done with all of the rain in Denver, which is uncharacteristic of mild desert climate. So yeah.
Jamon Holmgren:
Yeah, we don't know what that's like over here because it's just always... Actually, it hasn't been raining here, but yeah, that's interesting. Now, you may notice Jenna does not have a Denver accent. Where are you from originally, Jenna?
Jenna Fucci:
Yeah. I may drop in a few y'alls here and there. I'm originally from Louisiana, but moved to Denver about six years ago now.
Justin Huskey:
Does Denver have an accent?
Jenna Fucci:
I don't know. It's a pretty big transplant city.
Robin Heinze:
Yeah, I think it's one of those neutral accents places.
Jamon Holmgren:
So you'll be hearing that as we go through this episode, which is sponsored by Infinite Red. Infinite Red is a premier React Native design development agency located fully remote in the US and Canada. We have years of React Native experience, deep roots in the React Native community. We are the hosts of Chain React, publish the React Native newsletter to over 12,000 subscribers. It's 12,000, right, Jon Major? Somewhere in there?
Jon Major Condon:
Yeah.
Jamon Holmgren:
Getting close to 13?
Jon Major Condon:
It's pretty close. Halfway there.
Jamon Holmgren:
Nice. Infinite Red is the best choice for your next React Native app. Hit us up. hello@infinite.red. You can also email me directly, jamon@infinite.red. My inbox is a little deep right now though. So you might want to hit hello and talk to Missy instead. You can learn more on our website, infinite.red/react-native. And don't forget to mention that you heard about us through the React Native Radio Podcast. We love that. All right. Oh, we are hiring senior React Native engineers in the US or Canada. Go to careers.infinite.red, fill out the form. And Justin, we are also looking for design freelancers, right?
Justin Huskey:
Yeah. Quick plug here. We're looking for design freelancers for a few projects we have going on and you get a chance to work with our awesome team, which you'll hear more about as the show goes on.
Jamon Holmgren:
Pretty cool. I don't know how many designers we get listening to the React Native Radio Podcast but...
Justin Huskey:
For that one that's out there, we're looking for you.
Jamon Holmgren:
Or I guess if there's developers who could [crosstalk 00:08:55]
Robin Heinze:
Hey, if there's a designer listening to the React Native Radio Podcast, that's the one you want, right?
Justin Huskey:
It is, right?
Jamon Holmgren:
That is true. Holy cow. Yeah, we really hit our market right there. Let's get into our topic and kind of move into this, which is designing a React Native app. And when we're talking about design, we're talking about the visual design, we're talking about the user experience, we're talking about those ends of things. I asked on Twitter about this and people are like, "Do you mean architecture design?" I'm like, "Wow, I've got a lot of developers following me, don't I?" Our audience is, as we said, mostly React Native developers. So we're really speaking to them about this topic of design. What I want to do is give our audience a greater appreciation and understanding for what designers bring to the table and what good design looks like, as well as what maybe bad design or maybe bad design process or whatever. What can be improved between designers and developers, communication wise or process wise or anything like that.
Harris Robin Kalash:
And I guess also, as a developer, when I work with a designer, I care about the handoff, right? So I think focusing on talking about the designer to developer handoff is important because I feel like also, not all designers are necessarily very experienced at that or sometimes I find that I get very different types of handoffs from different designers, right?
Robin Heinze:
Basically, this is Justin and Jenna's chance to tell us everything we can do differently.
Jamon Holmgren:
It should be interesting. I kind of want to launch into the topic here. I'll start with you, Justin. What do you notice when you kind of... And we're not going through a project from start to finish. We're talking, there's a lot of different things we're going to be hitting on here. So I'm just going to hit the first one, which... But what do you notice that developers tend to do on projects that you kind of, I don't know, you feel like increasing the communication or the bandwidth or the process with designers would help fix?
Justin Huskey:
I have a unique perspective, a little bit on this because most of my professional career at least, has been at Infinite Red. And before that, ClearSight, which was your company, Jamon. And so it's been kind of developer-centric since the beginning. And coming into that early, I've kind of had a give and take relationship with developers for a long time. I kind of go through starting where I'm trying to figure out how to best to help them and how to kind of make sure that I'm handing off correctly when I'm giving them designs and stuff like that. Over time, the confidence builds as a designer at the same time. So you start to think, "Okay, design is not just what the visuals look like, but it's also, we like to say kind of around here, where goals and practicality kind of meet is where design is." One issue I've noticed as I keep going, especially with kind of younger developers, is the kind of just jumping in without a idea of where it's going overall.
Justin Huskey:
And actually, what's interesting is I think designers do run into that, a lot of junior ones as well, where you're kind of instead of taking a step back and trying to figure out, "Okay, here's what we're doing with this screen. Here's what we're doing with this app. Here's what we're doing with this website." They launch right into, "I think it'd be really cool to have this feature here and this feature there." And then over time, you start to build something that has no vision. And where design can really help is to help people kind of take a step back and look at it from more of a holistic point of view, which I know sounds really buzzwordy and yeah, but it really is true. You can kind of take a step back and get a whole vision for the app or website you're designing.
Harris Robin Kalash:
As a developer, one of the reasons that I think it's really important for clients to understand that they should invest in a designer is also because sort of the design phase, when you make mistakes and you iterate on design phase, it is cheaper for the client, in the long run, to make those mistakes in [inaudible 00:12:58] of design phase. Development time is much more expensive when you have to redo stuff, right? So I think sometimes clients, I guess either don't have the experience or don't realize that. I actually had this client a few years ago that the client themself was an engineer. So he thought like an engineer and kind of decided to skip the entire design phase. So I think we had recommended to them to get a designer, but they didn't want to do that. And they sort of pay way more because they accept to make certain mistakes and just iterate it. Like, "Okay, we have this UI element. Let's just use a switch even though switch might not make sense."
Justin Huskey:
I kind of liken it to if you were to design a house, for example, he could look at it and you say, "Okay, I need a living room, I need a bedroom, I need a kitchen." All this kind of stuff. You start to start putting it together, you push it out and it's good for the moment and then you start realizing, "Oh, what I designed here is not up to code, but I already pushed it out." And so you have to kind of go back to the drawing board and that's where having a designer up front can kind of help because they know all these things and they can kind of guide you along and actually talk to you about where do you see this kind of being 10 years from now? Are you planning on selling the home or do you plan on growing into it? And that's not something that usually gets thought about if you just jump right into building.
Jon Major Condon:
A lot of what the designer seems to be doing is building out the consistency at scale. As you mentioned, the house example. What I really like about that is it's pretty relatable for us. We have been living in a farm house for quite some time and we want to have a different style, but we kind of walked ourselves into this corner to where we can't have maybe a more modern or different take of a style. So what I'm getting at is, the design system is the consistency, it's the foundation of the application.
Harris Robin Kalash:
Yeah. I would also add, it's also the source of truth for me. When I look at what we should do, I like to refer to the design because developers can interpret things in so many ways and I've had that happen to me. And this actually, in the same project that I'm referring to, where me and the other developers that were working on it, we had three different interpretations of something that would have been solved had we had a design.
Jamon Holmgren:
Yeah. And just before we get too far, what exactly is a design system for people maybe who have been living under a rock for the last 10 years? Sorry, maybe who haven't heard of it.
Jenna Fucci:
I mean, I think this can vary depending on project as well, but typically, a design system has all of the reusable components within the product, as well as documentation. I know on some projects, they're smaller, can be more simplified. So you would have design library, which just reusable styles and some basic components as well. But overall, it's just a lot of reusable styles with some documentation that not just helps developers, but also other designers working on the project or in the agency setting where if you stop working on the project for a little while and you come back to it, it's kind of like a refresh on the different styles that you were using.
Jamon Holmgren:
Every project that I've worked on and helped work on that has had a design system has been much better. I've been doing this for a long time and in the early days... Well, in the early days, we didn't have designs whatsoever. And then we kind of moved toward we would have designs, but they would be completely custom. I remember every single page would be completely different. You had to just start from scratch on these websites. And then people are like, "Oh, that's not very good." And then we kind of went to Bootstrap, which was everybody had the exact same design system in the whole world. And then we kind of have moved more to this better spot in the middle.
Robin Heinze:
Yeah. The project that I'm working on now has a really impressive and thorough design system built out by their designers. And it's really nice because I feel like the designers have the bird's-eye view of the app. And so they know where things are going to be re-used and when it makes sense to share components. And so they're sort of the source of truth. And then I can just trust, "Okay. Hey, is this screen using a design system component? Or am I in charge of just building a custom one?" And I don't have to make that decision myself as a developer and get it wrong.
Justin Huskey:
Right. I know for me, personally, it's been nice having designed systems for our team... I can't prove it, but I think Jenna brought in design systems in Infinite Red because of the way I designed.
Robin Heinze:
She would never admit it. But, yes.
Justin Huskey:
I very much get all the ideas out first and then clean up later. And unfortunately, the cleanup process wasn't always as thorough as it probably should have been.
Jamon Holmgren:
One thing I appreciate about Jenna is she approaches... Even the Sketch file has really well-defined symbols and layers and well-named things. And I mean this as a compliment, she approaches the structure of her files in a technical sense, like a good software engineer would. And I think that's good because it meshes well with how we think over on that end of things. And I'm not saying you don't, Justin, but...
Justin Huskey:
No. I got the message loud and clear.
Jenna Fucci:
But you kind of are.
Jamon Holmgren:
Justin brings different things.
Robin Heinze:
Justin brings different talents to the table.
Jamon Holmgren:
He does. Yeah. Actually, Justin, I got to break them up for a bit here. Justin started with me way, way back in the day when we were both pretty new to the whole thing. And what I love about Justin is he brings more of a business side of things to design, which is another piece of this too, because you have the design interfaces between the engineering side and the business side. And it's really important that you accomplish both goals. And so our design team is awesome because we do get both. Jenna has that sort of the technical connection with the developers and then we have Justin's business side of it. So he's able to bring in, make something that looks beautiful and is easy to program, but it doesn't accomplish the business goals. That doesn't work either. You have to be able to achieve all those things.
Robin Heinze:
Every project I've ever been on, the designers are constantly interfacing between marketing and product and changing their designs to match what the business needs.
Jon Major Condon:
They are the glue.
Jamon Holmgren:
Yeah.
Robin Heinze:
They are the glue.
Jamon Holmgren:
Absolutely. And we feel it when we don't have that. Harris and I were talking about a client they had many years ago where it was kind of client driven design, right, Harris?
Harris Robin Kalash:
Yeah. Well, that's the thing, right? Again, we can't force a client to buy into, "Hey, you should build a design system. It's going to help you in the longterm." Sometimes they don't see the value of that, but yeah. A client driven design in the sense that the client would get on a call and be like, "Yeah, let's use this. This looks good." Right, kind of on the spot, but going back to what we said earlier, they never have that bird's eye view, right, because they're kind of making these decisions. They're winging it, right. They're making these decisions on the spot. So it's interesting. I think I would have a question for Justin or Jenna, how do you sell a client on actually adopting a design or design system?
Robin Heinze:
Or just telling them they need [crosstalk 00:20:33] have designs, period.
Justin Huskey:
Sorry. I was trying to think. I'm like... I don't know if we necessarily sold design system itself, but...
Robin Heinze:
Well, haven't we had to convince a client that yes, you need to do design before you do development?
Jamon Holmgren:
Yeah. So I can take this maybe a little bit just because I'm in a lot of those calls and there is actually a pretty good answer to this. It's not really a sales technique. It's more just putting it in perspective, because as Harris, you said earlier, it's so much cheaper to move pixels around on the screen in Sketch or Figma or whatever, than to be rebuilding components. That's just expensive. Not only are developers expensive, but you also have a lot of more time built in there. If Justin or Jenna wants to move this box over to this side and stretch it that way or whatever, often, we're restructuring our JSX, right, to do that. And there's implications around data flow and things like that. Where designers, there's just more freedom in that. So what I tell people is that if you have a good design team, they will actually pay for themselves, 100%, all the way through the project.
Jamon Holmgren:
You will actually get savings on the development side of things that more than offsets the design. And every project we've ever done, where we've had design involved, it's been the case, where I know that we're redoing things far too often on the development side because the client looks at it and says, "I don't like this." If they'd seen it in the design side of things, it would have been much better. Now, a design system specifically, you get savings through reuse of components, because you're actually reusing styles, you're reusing components, you're reusing all these things. And so that translates into efficiencies as well. And so from my perspective, there's no way that I would ever build an app, if I was building one for real, not just on the side, where I didn't have a design and a design system. I would absolutely pay the money for that upfront.
Jamon Holmgren:
But a lot of times, people are like, "I don't know. That's some money upfront. Maybe we could just build it. We kind of know what we want." And it's just not true. And going back to when I actually used to design homes, that is a previous life I had, we would charge $2,500 to $5,000 to design a home, which seems really cheap, right, for us in the tech industry. But when people were budgeting their houses out, they would often put a budget together that didn't really include design. And it was always like, if you came to us and said, "Okay, here's $5,000. Here's our budget that we're trying to hit. And here are our priorities." We could actually achieve their full budget, including our part and all of the things that they wanted to have happen within that, within the home itself rather than them just kind of buying something off the shelf that kind of sort of fit but didn't quite. That was sort of the thing we were up against. So I feel like there are a lot of parallels there.
Robin Heinze:
Having done a lot of client projects now, every single one sort of starts with this estimation phase and it's everybody's least favorite part, partly because as you're going through and saying how long everything's going to take, especially if it's been designed by the client or sort of kind of designed by the client, not really, you know in the back of your head, everything's going to change as you go and your estimate is going to be way, way off. Especially working with our designers at Infinite Red, we joke about how everyone wants to be on a project if IR is designing it instead of the client. But the benefit is, if you start with a really good design, the development phase can really just be picking up tasks, build this screen, build this screen, build this screen. And everything's been thought out holistically already, and you have this confidence. And so it's just so much more efficient, like Jamon said, and ultimately, less expensive because you're not changing your estimate and doubling it and adding scope.
Jamon Holmgren:
I feel like we've made a pretty good case for why you would want design, why you would want design systems, but let's move into the nuts and bolts of the relationship between design and development here. And we will get to more React Native specific content in a bit, for those of you wondering. But a lot of this applies to more generally across even web and mobile and React Native, et cetera.
Jon Major Condon:
Question for either one of you, when dealing with design and data, what are some techniques to make sure that the design covers all the different states and data that's available?
Jenna Fucci:
I know from design standpoint, it's super helpful and probably really important as well to sort of know upfront what type of information and data that you're working with. It can be as simple as do we have profile photos? And you're designing out a profile page. And so I usually take a object oriented approach to design. Might be-
Jamon Holmgren:
I told you she was a programmer.
Jenna Fucci:
I was going to say, that might be a very familiar term for developers, not so much on the design side. So just as high level explanation, it's just sort of going through the different content that's available in the app, listing out, "Okay, we're going to have profiles. So what does a profile include?" Profile photo, their name and stuff like that. And so when we're designing out screens, we know what type of metadata we can pull, because there's nothing worse than having a full design and half of your content isn't available from the API.
Robin Heinze:
It's interesting, because that's pretty much exactly what developers are going to do when they're building out a screen is, "What types of data do I have? What does this data have on it?" So it's really important that design sort of parallel that thought process, and it can make things go a lot smoother.
Jenna Fucci:
Mm-hmm (affirmative). Yeah. It also has been a really great way to kind of define relationships between content even before you have even a wire frame. So you can start to see patterns within the app as well, as far as what you're going to be creating.
Jon Major Condon:
Do you ever focus on states like loading? Is there maybe a few error states, few of this data available, a lot of this data available, just all these different kinds of cases with data?
Jenna Fucci:
Yeah, definitely. I mean, that is definitely a really good way to find those areas where you might have a lot of empty states or loading. I know there's projects we've worked on before, where we could have possibly thousands of results. So we know that upfront and we can make sure we can have pagination or something like that and make sure all of that works. And then definitely, empty states, I think, are a big one. Going back to profile photos, I mean, that one's a pretty common one. If you're going to have profile photos, you automatically know you need a state for a user that isn't going to add one. Stuff like that.
Robin Heinze:
I know you both have done a lot of work with Webflow recently. And I'm wondering if your experience using Webflow has changed your approach to design or your methods at all? Since, obviously, working with Webflow versus working with Sketch, you have the ability to work with sort of real data collections and real empty states and things like that. Has that sort of influenced the rest of your design approach?
Justin Huskey:
I think so. With Webflow, I've noticed that it kind of really drives it home when you make a style update because everything's kind of connected and using the different CSS styles and stuff like that. So for me, when I'm in Sketch and I'm running into a deadline and I got to move quick, sometimes it's a little bit easier just to disconnect a symbol and be like, "Okay, I'm going to come up a little solution here and then I'll put it into the design system later." Then I forget to do it and it kind of erodes a little bit. But with Webflow, what's so great and how it keeps you humble, is that if you change a style and you think it looks great, you start going through the rest of the website and realize you broke everything. So it has definitely made me more intentional about having to change styles. And now, when I go into Sketch, it's starting to click a lot more because I know how it has a big effect throughout the entire project.
Harris Robin Kalash:
Do you guys ever design animations? Because, I guess we could build them in React Native.
Justin Huskey:
I have designed animations. So actually, the way I got into design was through motion graphics and After Effects. It was the one piece of software that seemed to intimidate everybody. So I thought, "Well, if everybody's intimidated by it, I might as well learn it and be the person you go to. Try to make money off of it."
Jamon Holmgren:
That's a great career strategy.
Justin Huskey:
And what I noticed is, as I was using it, I did learn a lot about it, but I wanted to figure out how to make my After Effects animations not look like garbage. And so that took me into typography color and all that stuff. And through that, I really got into, at the time it was web, and through that mobile. Because of that experience, I've actually been able to use After Effects quite a bit here at Infinite Red. We had a few different apps that we did where... I wouldn't say we did major animations on it, but we did do loading animations and little things that look really cool for a branding effect. And we did that through After Effects. We put it through Airbnb's Lottie. I think it's Airbnb's, right?
Harris Robin Kalash:
Yeah.
Justin Huskey:
Airbnb's Lottie. Yeah. And it actually turned out pretty good. Implementation wise, I know it was a little rough for them, but actually, the more they kept updating it, the more seamless it got, and it was just a plugin you put into After Effects and exported and you kind of look like you have a, I don't know, you've got a more high quality, more refined app.
Jamon Holmgren:
That's really cool.
Justin Huskey:
And actually, Webflow's got integration with Lottie now as well. So you can put it even on the web.
Jon Major Condon:
So as developers, we have a review process, normally through GitHub pull requests. What's the review process for designers?
Justin Huskey:
That's a good question.
Robin Heinze:
Which means?
Jamon Holmgren:
Dot, dot, dot.
Jenna Fucci:
I think I can answer that one. So I mean, there's a lot of different ways to approach this. Right now, our main process is Sketch and Envision. So we'll update our art boards on Envision and we have commenting. And so basically, the screens that are all up on Envision are our most recent versions of everything. I know, in the past, we have used, I think, Abstract. We used Abstract alongside with Sketch, which is pretty much exactly like GitHub for design. So you can create branches and then merge the master. We used that with a few projects in the past where we had multiple designers working together. And so we could iterate on designs, especially within the same file and make sure we weren't overriding each other as we were going.
Jon Major Condon:
That's pretty cool.
Jamon Holmgren:
Let's talk about the interface between designers and developers a little more here. What is the designer handoff to developers look like? What types of things do you like to do? What things sometimes get missed? What things do you feel like maybe developers should be asking for more? What do you think in those terms?
Justin Huskey:
We always start every handoff with kind of three basic things. One is a Google doc of just where everything's at. So we handoff a Google doc and it's got links to our Envision prototype, which is one, it's got a link to the assets, which are already exported and compressed and put into a zip folder for them. And then it's also got a link usually to the actual Sketch file that we're using, just because a lot of our developers know how to open that up and interact with it and see different things. Then also, in that same handoff document is a bunch of notes that we've taken along throughout the project on what the clients like to work with, what they're really looking for from this project, and also, just the errors and things that we've run into that we know might need some communication later on down the road.
Justin Huskey:
And we always tell developers too, that you can't really bother us too much when it comes to communicating with us about how do I translate this into actual code and things like that. And one thing I will say, as the project kind of goes on and deadlines start getting closer, that's generally when things start to break down a little bit with communication, but that's generally where the difference between an okay project and a really solid project can... That's where the difference is made there, is when it's frustrating and there's a deadline coming up to actually reach out to the design team at that point. And let's get on a Zoom call and talk about it and figure it out. And that's generally what I recommend when it comes to handing off is always be getting on Zoom and talking with your design team.
Robin Heinze:
I have memories of one of my first projects at Infinite Red. And it wasn't really a handoff, it was more like, "Here are the designs." And then pretty much every day, Derek, one of our other developers that I were in Zoom with Justin or Cindy clarifying, "Hey, what about this date? Hey, the data from the API doesn't match up with this quite, what would you prefer?" Pretty much a daily conversation. And so it was really important to keep that line of communication open and not just sort of say, "Here's the designs. Let's go."
Jamon Holmgren:
Yeah, I think that's something we've gotten a lot better at is just kind of the designers knowing what the developers need and the developers also understanding the designers better. Actually, I want to bring this to a React Native question here. Have you noticed any limitations when you're designing specifically for React Native versus for a native mobile app? So we used to do native mobile apps back in the day, and then we switched to React Native in 2015. And so you've been doing that ever since and React Native, while it is a normal fan of... You can build normal mobile apps with it, it is a specific technology. So I'm curious, and we did get this question on Twitter as well, what sort of constraints or limitations or even advantages do you kind of keep in mind when you're designing for React Native?
Justin Huskey:
With React Native specifically, I can't really speak to where native is now and Swift and stuff like that. I remember since I've been doing this, Swift kind of came after I started learning mobile design and stuff like that. But I do remember at the time, one of the issues with designing specifically for native was that there wasn't a ton of open source stuff that I could find. And I had trouble finding a lot of experimentation and things that would work for our actual projects. I did like though that it was backed by... I mean, Swift is backed by Apple. So it does have really good defined guidelines. I know exactly what I'm looking for and where that documentation is at. I think with React Native, we got into it early and at the beginning, it was a little bit of a struggle to figure out where to go with different styles, if we need a different feature, trying to find those.
Justin Huskey:
But I noticed lately, especially as bigger companies have gotten involved in it, they've kind of helped with it. Not to do a shameless plug here, but Infinite Red got into it and brought in Ignite and that has helped clean up styles. It's helped create kind of an arc around it. And it's also, as a designer, when I have a feature that I need to design, I want to go out and make sure that there's a React Native library for it first, so that I can take that and developers aren't going to have to create from scratch and then I can customize it to the client project afterwards. And that's actually gotten a lot better as time has gone on as there's been more available. And as Facebook's ramped up, they're supportive, it's gotten better as well. So there is a learning curve to it. It's a little bit of the wild, wild west sometimes out there, but overall, I do appreciate all of the open source and experimentation that's going into it.
Robin Heinze:
And we definitely appreciate when you do that, because there's nothing more frustrating than having a design in front of you and needing to go out and find a library, especially ones that have UI components that are customizable enough, that you could make it look what the designer wanted. So if a designer has already found one and knows that it will work within the parameters of their design, it's really, really helpful.
Jamon Holmgren:
And Justin and Jenna are really good at also about saying, "Hey, I found this component library. Do you have any issues with this? Because we're planning to bake it into the design." And they check in because sometimes it's like, "Yeah, well, the last commit was in 2015, so maybe we shouldn't use this."
Robin Heinze:
Yeah. It's funny. React Native is getting so mature now. Yes, there's a ton of open source libraries now to support it, but it also means there's a lot of really stale ones. So that started to become more of a problem as React Native gets sort of more mature.
Jamon Holmgren:
What are the primary differences between designing a mobile website and designing for a React Native app?Because obviously, you're using JavaScript on both sides, but there are different paradigms.
Justin Huskey:
Using a hamburger icon versus an actual tab bar.
Robin Heinze:
Sums it up.
Jamon Holmgren:
That's actually a really good, concise way to talk about it because that is true. Who uses a tab bar on mobile web?
Harris Robin Kalash:
I was just about to say, that's a pattern I've been seeing that's becoming very popular in web. Twitter uses a tab bar. I don't know if you agree, Justin or Jenna, but I've been seeing it more often now.
Jamon Holmgren:
Although Twitter is React Native Web. So they're actually using React Native there.
Robin Heinze:
So basically, their website is their mobile app. So that's why.
Harris Robin Kalash:
Yeah, but I'm surprised at how well it works though. I would have expected it to be pretty bad because of the keyboard and stuff, but...
Robin Heinze:
Well, their aim is for their website to be primarily a mobile experience rather than a full page desktop experience. So that makes a lot of sense.
Jamon Holmgren:
So there's some convergence there. But for sure, there would be some differences though.
Harris Robin Kalash:
On Twitter, there's very little. I'm actually on it right now, just checking. I'm impressed by their web…
Robin Heinze:
I've definitely worked with a client or several clients that their primary business focus is their website. And they've kind of hired us to sort of make it mobile, make a mobile app that does the same thing without really going through and identifying what things need to behave differently because you just have so much more real estate on the web that it can be easy to forget that things need to have rules for wrapping and things need to have rules for when to overlay or when to go to a new screen versus when to just open a drop down or whatever.
Harris Robin Kalash:
That's a good point. That actually reminds me of one of the things I really, I think, helped me improve when I started doing mobile development is I used to do and I think in the... Correct, me, Justin or Jenna. I think that the design term is graceful degradation, where you go from desktop to mobile. I think that's it. Anyway.
Harris Robin Kalash:
Yeah. Okay. We'll go with that.
Jamon Holmgren:
Used to be progressive enhancement
Harris Robin Kalash:
Progressive enhancement. Thank you. So it's much harder to go from desktop to mobile than it is to go from mobile to desktop. So working on mobile apps made me realize you should just always start with mobile and then progressively enhance to desktop. Most customers are on mobile these days, right.
Robin Heinze:
Which is a really great use case for React Native Web.
Harris Robin Kalash:
Yes, exactly.
Justin Huskey:
Jenna, you can correct me if I'm wrong, but one thing I've noticed that's primarily different is that I think with websites, it's definitely more of a longer term kind of thing. You're thinking about just how it has so many different screen sizes, thinking about how they all break down, what's being hidden, what's being shown. I do know, especially the iOS and stuff like that, that you can scale up for iPads. And they're even kind of starting to support on the M1 Macs, they're starting to support even scaling up for Mac apps, but at least so far, up until now, what I've noticed is that web is very much like I'm constantly thinking about what's being hidden here? How's it going to change when it gets to mobile and we're designing on desktop? And vice versa. And with mobile, it's a little bit more of a unique kind of tailored experience to what's on the device. Whereas with web, it's really focused on trying to make sure that it's functional on almost every screen size imaginable.
Jon Major Condon:
So I would imagine there'd be a lot of conversation around what are the important pieces for on mobile to show versus on web?
Jenna Fucci:
So I would say probably the biggest difference between designing for general websites or mobile apps is really just pattern recognition and knowing when to use one pattern over the other. People expect certain things to function a certain way if they're familiar with that pattern and stuff like that. There's a lot of repetition, I think, with mobile apps.
Robin Heinze:
Kind of related to that, how do you sort of incorporate the differences between iOS and Android in terms of the sort of familiar design patterns or gesture patterns that those users expect? And do you do a separate design for iOS-
Jamon Holmgren:
With 3D Touch.
Robin Heinze:
... and then another one for Android?
Jamon Holmgren:
That's really what she's asking.
Robin Heinze:
Right. So as designers who designed for React Native apps, how do you sort of balance the two platforms and those design patterns?
Justin Huskey:
We start with more of a cross-platform design, I think is the right way to call it. And then where we differentiate is with the things that most of their users have gotten used to over the years as the default system. So a good example might be the back button on Android. We don't necessarily need to put in back buttons on Android apps because they already have one built in. On iOS, they don't. They've gotten rid of a bunch of that stuff. So there's some small differentiators there. Placement of the navigation is even a little bit different sometimes. There's a pattern in Google's material design where the tab bar is kind of up at the top sometimes. They also have the action button kind of floating in the bottom right, which can sometimes be a little bit different for iOS. So what we try to do with our designs is try to get 95% of it to be cross-platform and universal. And then where we really want to make the difference is in the 5% that is built-in ingrained habits that people have, depending on the platform.
Jamon Holmgren:
We have a ton more questions still in our notes, but I think we're running out of time. So I'm going to ask one more question here before we wrap things up. As designers, what do you wish developers would do more often when they're working with you?
Jenna Fucci:
I guess, tie it back to communication and just being more upfront about constraints. So if something's not going to work and that it needs to be changed, I would rather know that upfront versus a change in development, because even though the original design might not work, there still could be a solution that doesn't compromise the user experience, but also is a lot more realistic for development to achieve.
Robin Heinze:
Yeah, definitely. I think we've been trying to get developers sort of involved in the early stages of our design projects to try and sort of get those things out in the open early.
Jamon Holmgren:
Yeah, that makes sense to me. Very cool. Well, like I said, there's so much more that we could cover, but we don't have time today. So we're going to go ahead and wrap up. Thanks so much to Jenna and Justin for joining us, sharing your knowledge and very much appreciate it. Where can people find you, Justin? I know we have the ir_designers Twitter out there, but designers don't just live in Twitter. What other platforms do you live in?
Justin Huskey:
On Twitter, you can hit us up. It's @ir_designers. There's Dribbble. So you can go to Dribbble and find us under Infinite Red, and then we're also on Instagram, but I have no idea what our handle is. Do you, Jenna?
Jenna Fucci:
I think it's infinitered_designers, if I'm not mistaken.
Jamon Holmgren:
You'll find us. Very cool. Robin is @Robin_Heinze with an E. We've got Harris @nomadicspoon. You can find Jon Major @jonmajorc and I am @jamonholmgren. You can find React Native Radio @ReactNativeRdio. Thanks again to our guests as always. Thanks to our producer and editor, Todd Werth, our transcript and release coordinator, Jed Bartausky, our social media coordinator, Missy Warren, and our designer, Justin Huskey, who is also involved in this process. Thanks to our sponsor, Infinite Red. Check us out, infinite.red/reactnative. And a special thanks, of course, to you, for listening today and checking this out. Make sure to subscribe and hey, send this over to someone, if maybe it's a designer who wants to kind of hear this conversation or developers interested in the design aspect of how these projects come together, really appreciate it. We'll see you all next time.
Robin Heinze:
Bye.