Gavin Nelson - Prototyping, interaction design, and learning SwiftUI (Dive Club Ep. 62)

I made a pretty risky bet back in November of 2022 now I try not to brag but I'm pretty good at web flow I'm fast I've built a lot of websites and back in

the summer I had already built a coming soon page for the new dive website but I also spend too much time on design Twitter and I kept seeing these really compelling photos and videos of people

spinning up websites in framer and the more that I saw the more convinced I was that this was what the future of web design looked looked like so I made a bit of a crazy bet I decided to build

the new dive website in framer even though I had exactly zero experience using the tool well I'm over a year in now and I'm so grateful that I made that decision it's such an intuitive product

the spatial canvas the way they handle break points components honestly you kind of feel like you're in figma only then you have that beautiful publish button up in the top right and man when

you click it it just feels like magic so if you're listening to this and you're comfortable in a different tool right now maybe it makes sense to make a bet of your own you can head to dive. Club

slash framer to take that next step now on to the episode when you have that prototype that may be just entirely spaghetti code that's never actually going to ship in the background but it

creates this very high fidelity thing that's indistinguishable from production that's like the universal language of getting feedback and just like testing your idea for real you you hand it to

someone and you say like change the properties on this linear issue and that is a real life user test in a way like can they do it do they find it easy does it take them way too many Taps to do

welcome to Dive Club my name is rid and this is where designers never stops learning this week's episode is with Gavin Nelson and it is a deep dive into interaction design and prototyping we

talk about his process for Designing the GitHub and linear mobile apps and he shares some really helpful Snippets along his journey of learning Swift UI but before we get into all of that I had

to learn more about how Gavin first got started designing app icons like way back when I think I started in high school I had this moment where I realized that these icons I was seeing

on my computer were handcrafted by digital artists and I just instantly had this curiosity of I need to know how they did that I need to try and explore that area myself I downloaded Photoshop

as a lot of early designers did and started just EXP experimenting I remember my very first icon I like had not learned really about vector graphics

so I looked at these beautiful like, 24 pixel icons and zoomed in real close and saw like each individual pixel and then kind of just thought okay they like placed these pixels on a canvas so I

started smaller like 64 pixels and started individually placing pixels to try and draw a I think my first one was a settings icon and quickly realized that's not how it's done and that was a

very awkward entry into trying to create a a nice icon so I followed that Curiosity and kept learning more and more about vector graphics and Photoshop trying to get a handle for the tool and eventually started connecting more with

folks online who were doing it and learning tips and tricks and that led me into just really exploring this world of Icon design and kind of sparked an interest in design as a whole that like

by the time I got to college I was interested in exploring that my school had a product design and kind of HCI oriented studies so that's what I pursued and one thing led to another and

I continued working on icon design as kind of a way to further my visual craft and just kind of practice that and stay curious about like what new can you do with it and I started picking up this

product design angle as like a really interesting way to stay in the design field but also like think about how you can use it to solve bigger problems make people's lives easier like make my own

life easier I would like try and design little applications or like scripts to do things and that kind of felt like an entry point into design and one thing led to another and now I've been working

in the field for a bunch of years was there a moment where you kind of realized okay this isn't just something fun but actually I can make a career as a freelance icon designer and this is

actually something that people will pay for I think this might be kind of unique but like I've tried to never really think of it as like I need to do this for a career the way I approach it is

always like doing it for curiosity or for fun or like engage engagement with the craft and I've been lucky enough that doing that and sharing the results

has led to enough freelance clients that it kind of naturally formed this network of folks who know me for Icon design so I've been lucky that it kind of grew

organically like that I think like if I had to focus on it as solely my job I would get really burned out on designing icons all day every day for way too quickly so it's been nice to have is

like kind of a little break here and there a way to flex different creative muscles to kind of test the limits of like what you can do and it's it's really a big experiment and you're constantly kind of trying new things and

doing lots of iteration and in a way like a lot of those skills have transferred into product design which is a nice little boost to like my learning and understanding as a designer can you talk a little bit more about which

skills have transferred and and how basically like what elements of the visual craft that you're learning in icon design and just kind of experimenting on the fringes actually show up in the way that you would

practice product design I think the main area is just like constant iteration and constant like asking how can this be a little bit better if I tweak this one thing does it get better does it get

worse if you look at a lot of my design files I'm a Serial duplicator of a frame or an artboard and just like make one little change evaluate it against the previous one duplicate the better one

make another change it kind of turns into this mess and I spend some time at the end cleaning it all up but it's really like a experimentation process what do I change here that makes it better and what do I change over there

that makes it better just constantly trying to find the next best step and then the other tricky part is kind of knowing when to stop but that's something I'm always still trying to figure out let's talk about the product

design part a little bit and specifically I want to talk about mobile design because this is now your third mobile app in a row you did fitbod GitHub now linear and like as you put in

more of these reps and you're exposed to different problem spaces and environments what are you learning about the different techniques or strategies that make someone a good mobile app

designer a lot of it is getting in the right mindset for solving problems on mobile you know there's like it's easy to approach a problem and say like okay well I can do this and put this menu

here and then you select that option and then like three or four taps later and you've got your solution to what the job you're trying to solve for is on a mobile phone but when you put it into practice you realize like people are it

really depends on the context but kind of painting generally people are using their phones in little 1 to 2 minute bursts here and there and any introduction of friction or like a lot

of repetitive action on a phone feels really Amplified when you're trying to use it with your thumb maybe like one-handed while you're walking the dog or something like that and really getting into that mindset of trying to

make very frictionless experiences designed for small chunks of interaction I think makes a big difference and it's easy to sometimes Overlook and think my user has a very complicated job and I've

got this very long set of steps that's going to help them solve that job on their mobile app really trying to distill that down to get more creative can we start with some very intelligent defaults and these are all kind of

principles that I think are not exclusive to mobile design but really trying to put yourself in the mindset of the context in which your users might be experiencing what you design I think

makes a big difference it's been almost five years since I've led a mobile app design project and I think in some ways the cost of that has been I focus Less

on interaction design there are less opportunities to really push the envelope in terms of what interaction design can look like because in many ways mobile you know the sky is the limit so can you talk a little bit more

about how you approach that part of your craft specifically yeah I think that's a really unique space in Mobile design specifically I guess more generally touchbased design you know maybe on an

iPad it would be similar but like you have this entirely different input method from a mouse and keyboard right you don't have things like hover States but you do have things like multi-touch

gestures on iOS for example and that's really powerful and I think it it applies a unique set of constraints but it also like opens up a whole new world of possibilities and that's where a lot

of I find nice interaction design to come in on mobile kind of they it kind of all builds off of very like foundational principles of system feedback like if I touch on something

what happens and I think apple and iOS really Pion neared a feeling of physics based interactions so if I push down on something does it respond to that push

because that is much more of a something you would expect to happen if you touch something with your finger versus like when you're using a mouse you're very used to this digital connection you know there's not a lot of physical connection

to what you're seeing on the screen so taking all those little details into account it's almost like a more well-crafted experience that by doing that just Blends into the background a great example is inertial scrolling on

iOS it's something that for context when you are scrolling along list and you hit the bottom kind of hits the bottom and smoothly over Scrolls a little bit and then like gently comes back to rest

right and it it's as if you like scrolled into a rubber band and that's something that I think your average user doesn't immediately recognize and say oh that's nice when they scroll to the end

of a list on iOS but if you remove that it starts feeling really weird like you're scrolling this list you get a lot of velocity and you're scrolling a lot of momentum and then it just abruptly stops and that's something that you

would find in a lot of digital experiences but doesn't really map to the physical world and I think exploring making interfaces fit in more naturally with the physical world because you're

interacting with them physically with your fingers is a really unique area of mobile design and kind of interaction design on touch devices and it's something that I'm always trying to bring into the experiences I work on and

I think like primarily through prototyping which is another big area that I try and focus on I definitely want to get into prototyping I want to go a little bit deeper on just different

mobile patterns because you've been doing this basically every day for what like four or five years now talk to me a bit about what you've learned about the different mobile patterns to reach for

and maybe like how that has evolved over time it's interesting because there's a lot of unique constraints on mobile devices and you can think about swipe gestures as a good example as like that's a really powerful pattern it lets

people do actions really quickly on their phone but it's also not necessarily discoverable and this is something that I think mobile operating systems still haven't solved for really

well and it's a really tricky problem is like how do I make these very powerful interaction gestures discoverable and visible to the user and our solution right now as an industry has kind of

been let's make sure there's always a visible way to do the same action so it might take you three Taps to delete a notification from your inbox uh which is

the same as just dragging it across the screen with a swipe gesture much faster but if you don't know that exists you can still complete the same action so there's these really unique angles to a

lot of problems but what I found again and again is you kind of have to bake in visible ways to accomplish the same goal and I always try like one of the things I'm always trying to do in my designs is

if you are building what's essentially like a power user gesture right like only a smaller percentage of your user base are going to know about it or like very Avid mobile users to find subtle ways to hint to everyone using this app

that those gestures do exist to like onboard them into these more fast and fluid ways of interacting with their app it's almost like a uh a rightclick menu right you don't have a secondary input

on your phone or keyboard shortcuts you don't have those either and I think a lot of people use those to be far more productive and like that's what you want on your phone you want to be productive

and quick in your interactions and when you can educate users about these gestures their their power kind of exponentially increases in their ability to use the app so swipe gestures are a

common one there's a lot that are kind of interesting like if you imagine a uh a modal window pops up on your phone I want to say mobile app operating systems have kind of conditioned us to this but it's kind of natural to think like I

want this to go away I'm just going to flick it away with my finger like get out of the screen here so building a gesture into that where when you do a flick gesture like that it closes the modal is a very natural extension of

like what you're doing and I I think that's where a lot of the power of interaction design comes in right you're meeting the user with actions like based on their intent and not requiring them to think about okay I want to close this

how do I do it let me hunt for a x icon in the corner to close it I think it's good to still place that there but another great example is the original um I think it's still in the system but iOS

has shake to undo it's a little bit like annoying sometimes it kind of gets in the way but like when you look at the original intention you get so frustrated with your phone and what you're doing that you just shake it like ah this stupid phone and then it says hey do you

want to undo all of this like sorry we got you into that mess I think that's a great example if not perfectly executed on the mobile operating systems right now it's cool to hear you make the

connection between like a keyboard shortcut and the swipe gestur because that does make sense intuitively to me especially for someone that's designing for developers and power users people

who are using these tools every single day like a GitHub like a linear and I can see how that would be a big part of your practice is trying to figure out ways to help people

accomplish more more quickly but also maintaining like Simplicity as the base experience yeah and there's a really interesting tension there because it's easy to think like everyone using these

more technical tools are going to be keyboard shortcut power users and sometimes that's the case sometimes that's not and I think you want to solve for like everyone being able to use it

but you want to give that extra power to the people who rely on keyboard shk and things like that and the tension comes in on mobile design because like we don't have those easy shortcuts as I've

mentioned and there's not like a very obvious baked in system for like a long press to equal a rightclick menu is kind of the most onetoone example but the the tension comes in where you can try and

solve these things by doing some wild gestures on the screen to like do multiple actions at once and really increase someone's productivity but users aren't necessarily going to know how to do that or like take the time to

learn learn that right that's like if you went from no keyboard shortcuts to introducing keyboard shortcuts overnight and suddenly everyone's like what are these crazy keyst I have to do to increase my productivity right on mobile

you really want to try and balance familiar patterns and think hard about how you can use these familiar patterns in unique ways to make someone more productive or to allow them to get their

job done without thinking about interacting with the interface as much can you talk a little bit about what you are looking for or even when just using mobile apps in your day-to-day like I

kind of obsess over different web experiences and I try to figure out like okay what are they doing what could I draw inspiration from how does that translate to you in just using mobile apps it's it's interesting because I

think one of the things I really strive for and look for in mobile apps personally is just what I was saying earlier like it just gets out of the way you know I don't have to think about

interacting with it I can just take out my phone use app XY or Z to get my job done and then put my phone away when there's some unique pattern or something new that requires you to like learn the

interface that's almost when this friction is introduced and when like I start to get more frustrated with the app so it's a funny balance of my goal is that the apps I'm using get out of my

way but I also as a designer want to acknowledge that and actually realize that which is the opposite intention of the interface to think like hey I use this a 100 times a day and it's very

fluid and very seamless and I have to back up and think like what are they doing that that makes it like that and how can I apply that to my my design is there an app that you've used recently where you've been impressed with some of

the interaction details maybe you could talk a little bit about what stood out to you the app things by cultured code it's a to-do list app essentially I've been using it for years now probably

over 10 years and it's perfectly designed in that way that I can add tasks rapidly I can set due dates I can like rearrange things all really without thinking about what I'm doing and I

think they just really nailed the right amount of gesture based interaction more power when you need it just by tapping through like easy to identify menus never really like gets in your way and

especially for a productivity tool that's what I'm looking for and like linear is also a productivity tool very similar more team-based tasks and product management and like software

development than just a personal to-do list but a similar goal that I try and strive for so I'm always trying to think what makes this fluid and seamless and what makes me love this so much there's also Al just things like more

entertainment apps I recently downloaded Netflix I've used Netflix for years but almost always just through the website and I download the app and the app it feels like one of those things that has

like no right to be as well-crafted as it is but it's incredibly well done and when you use that it's another one of those examples where it's like I don't have to fight this system to turn the

show I want to watch on maybe the algorithm is like not suggesting it to you right away but when you find the card you can tap it you can flick it away when you you scroll down the header kind of shrinks very elegantly and gets out of your way a little bit which I

love there's like a bunch of nice little interactions that I say like it has no right being as well-crafted as it is I think coming from a idea of like it's not a productivity tool like people just

want to watch a TV show but I think that makes a huge difference when you do put that extra energy in because it it lets users focus on the shows rather than like trying to fight against the app

just to get their entertainment I like the Netflix example because it is like it gets out of the way like it checks box but man there are some really delightful interactions like you mentioned the header collapsing when you

pull down I mean I just studied that thing it is so impressive I'm like how do you even think of this you know it just was so beyond my ability to conceptualize and execute against it is

really really a nice detail if you see that all kind of across the system it's baked into like your standard iOS navigation bar where like you'll go from a large title when you scroll it shifts

into the small centered title just to give you more scrolling space and I think it gets really nice when you're using custom components like Netflix does to take a second thought of like okay we're going to shrink this to give

people more scrolling space but they might still want to see their filters so how can we make these slightly smaller but still kind of make the whole interaction invisible but give you that

extra space for when you're scrolling and I think they they did a really good job with that those are little details that I really think like come together to put that extra layer of polish on an app which ideally just makes it like

blend into the background more can we talk about the custom components piece a little bit cuz that's a question I've seen come up a lot from people who are designing maybe for the first or second time with mobile is like why do you

think about when to reach for custom components versus when to rely on the system components yeah it's definitely a a tricky balance I've been in both

situations where at GitHub we built significantly more with kind of stock iOS and material design components and you get a lot of advantages from that but there's also instances where they

don't quite get the job done and you need something a little bit more custom linear on the other hand kind of puts linear's design system first to give it a big sense of brand cohesiveness and

then relies on default components for both IOS and Android I think there's like technical reasons behind all of this you know like Apple and Google have done excellent jobs with accessibility

and they continue to improve that all the time and a lot of that is baked into the the stock components so you know if you use the stock tab bar it's going to meet a set level of accessibility

requirements so it definitely takes more work when you're doing it custom to meet those same requirements and you don't you kind of foro some advantages of like

when uh WWDC rolls around and they release new introductions into Swift and kind of the stock set of iOS components you don't get those immediately you might have to do a little bit more work

to integrate those apis but there's just trade-offs on both sides in terms of using like mixing custom components and stock components I think that comes in largely when you're trying to solve a

problem when I'm trying to solve a mobile design problem I'll start by reaching for the stock components and if something's not quite getting the job done well enough that's when I would turn to custom stuff mostly for reasons

like we touched on before like you don't want to necessarily ask the user to constantly relearn how to use their phone right they're very used to the

more default like a bottom sheet is very ubiquitous across a lot of apps they'll generally know how to interact with a bottom sheet and that's something you can kind of safely introduce but if you start getting crazier with different

types of custom work it can be very effective like they can pick these things up and maybe it makes them more productive but it also can be a bit more of a learning curve and potentially turn

some users away or confuse them let's talk about linear a little bit because you actually inherited the mobile app design from Alex Cornell who we just had

on a few episodes ago you're like a few months in so can you talk a little bit about how that experience has been so far yeah it's been fantastic I've loved my time joining linear so far it's been

about 3 months like he mentioned I think Alex had been there for about a year working on the mobile apps and he really took it from basically nothing done for mobile I don't think any code had been written maybe a little bit and started

designing kind of the foundation and it from what I've seen of his work at linear he did a lot of exploration into what if we like kind of rethought or like started from nothing and thought

like how what is the effective uses of linear on a mobile phone and he arrived at a foundation that was super solid that I inherited like you mentioned and I got to kind of take that and shortly

after I joined we shipped the IOS app to the first set of beta customers so it's been really interesting hearing all of their feedback come in and trying to still that down and figure out like what

are the problems that underpin all of this feedback and how can we address that so I've been able to take that Foundation Alex left and start building on top of that and trying to change it in some ways based on feedback and based

on just daily use of the app ourselves and then expand it in other ways but it was it was nice it takes a lot of time to be confident in the foundational direction of your app and he spent a lot

of that time working on that so I kind of got to come in at a slightly different stage and work on some different problems but I mean that's part of the job I love kind of getting a mix of different problems and getting to

work on different aspects of it let's talk about the problem solving process a little bit then because a question that I really like to ask people is what are you doing to kind of like collapse

complexity and get momentum on some of these more ambiguous meaty problems when you're handed a very ambiguous problem or you discover a very ambiguous problem

I think it's really important to kind of what I do personally is just kind of like brain dump into usually like text or sketches or something like a lay of the land like what is the problem is that really the core problem we're

trying to to solve who is going to be using this or who is affected by this problem and when are they affected by it and try and kind of paint this whole context picture and then my goal is

usually just to try and think about as many different crazy Solutions as I can for the problem and what I find is like usually you can sketch out a 100 Solutions of varying degrees of like

grounded in reality to the problem and maybe like 98 of them are just totally out there and you take those those two that remain you continue iterating on them and you hit a little bit of a brick

wall maybe at one point and you kind of go back to those original Solutions and maybe you can take a piece of number 62 and a piece of number idea number 20 and kind of combine them and apply them to

the one that has been working so far and continue iterating so it's a lot about I mean for one making sure you're solving the right problem and then two just kind of like iterating through a lot of

different potential Solutions and similar to like how I approach icon design like making one one tweak here and thinking does this solve the problem better one tweak here and thinking does

that solve it better and the further you get down the line the higher Fidelity usually I go and try and move into figma and think like does the layout work and do the visuals work and prototyping

think do the interactions work can I validate the decisions I've been making so far by trying it in a prototype and ideally you just like slowly start chipping away at the ambiguity okay

let's talk about the prototyping piece then can you go a little bit deeper into like like at what point will you start stringing things together into a prototype while you're still just kind of exploring this Myriad of ideas

there's two main phases where I'll do it one is very early in the process like maybe I've got an idea for a interaction that isn't super common or that like I

need to test out like does this actually solve the problem or is this actually like easy to use and discoverable and at that point I might turn to prototyping to put together a very low Fidelity

prototype that has kind of a higher Fidelity implementation of the interaction just to test it out and see like okay that doesn't work or it needs to change in this way then I go back to the very early low Fidelity work and

kind of go from there the other phase is much later in the process usually I like making prototypes to try and like validate the decisions I've been making or really to like help make the

decisions in the first place so maybe I have a lot of the visuals looking pretty good I've got like a solid idea for how to solve the problem I'm working on and I'll start coding a prototype that the

goal is kind of being two goals really one is make it as roughly as fast as I can as fast as reasonable and two is make it as kind of indistinguishable from what I might see in production if

it was built over an engineering cycle and the goal with that being is you can just hand that to someone and say what do you think of this does it work and that's almost maybe there's a little context setting of like what the goal is

of this like what you're trying to get done but you hand it to someone and you say like change the properties on this linear issue and that is a real life user test in a way like can they do it do they find it easy does it take them

way too many Taps to do when you have that prototype that may be just entirely spaghetti code that's never actually going to ship in the background but it creates this very high fidelity thing

that's indistinguishable from production that's like the universal language of getting feedback and just like testing your idea for real so that's why the the speed part comes into it you know I want

to get to that stage quickly because when there are changes that need to be made it's easy to rip out little pieces and adjust little pieces and have a version two instantly and you don't

have to spend weeks months however long actually building it to then really test it with your users hey guys real quick if you know me then you know I love products so I want to take just 30

seconds to tell you about three of my favorites now anytime that I'm designing and building a website you better believe that I'm going to use framer I made the switch recently and I'm never

going back now once it's time to animate my designs and showcase my work that's when I'm going to use Jitter it's like figma only for motion design and every step of the way I'm going to be using

raycast constantly it's the Cornerstone of how I use my computer and the way that I stay in flow while I work now I hand selected framer raycast and Jitter

to partner with me so that I could do these interviews full-time so if you want to show them some love it would mean a lot okay now on to the rest of the episode I think a lot of times maybe

more so in web but a lot of times like the interaction piece of it is kind of the thing that you figure out at the end once there's like full alignment on the

core flow and layout and maybe even UI design so it's interesting to hear you talk about prototyping in the early stages of your process can you maybe talk about that tension a little bit

like when is it that the interaction itself has to be the thing that you fig out maybe even before you nail down the specific visuals it might be that it's like a little bit more kind of integral

to mobile design in general but I think it really comes into play when the interaction is kind of the core solution to the problem so for example I've been working on a a problem recently at

linear that involves kind of like a scroll View and on top of the scroll view is a bottom sheet and part of my idea for this solution is like you can tap in different parts of the scroll View and the bottom sheet will expand or

collapse depending upon what you tap on and you can scroll within the bottom sheet and tap on different things there and it might move the scroll view my Sketchbook looks like the Charlie Day meme where you've just got a bunch of

strings strung up and like it's completely unintelligible and you try and put that in figma and you've got like 40 frames to spend 20 minutes explaining to someone to like try and

give them the idea so I turned very early on in the process to code and just built a very rough prototype where when you did all those Taps like my intentions for the bottom sheet would

happen and you could just test it out and it was so much faster to say okay this makes sense or this one didn't make sense and I need to adjust it then trying to like look at a bunch of figma

mockups and think like okay I think this is making sense I think if you tap on this what I would expect to happen will happen based on this spec where when you're holding the Prototype you tap on

it and you're like I might have spent like a week deciding okay this will happen and this will happen and this will happen and then use it and you instantly know that was the right choice that one wasn't and that was the right

choice and then you can move on from there so when the solution is really ingrained in the interaction I think that's when I turned to prototyping really early to try and validate that along the way when the interactions are

kind of the level of polish at the end to try and make everything feel more fluid that's when you can kind of start tweaking the spring values of your animation at the very final stages or

even as it's being built to production you've now mentioned sketching figma you've been said the word code a couple times can you talk to us a little bit about like when you reach for these

different tools I think it really depends on the project I'm working on but generally I'll move between the three very quickly and very interchangeably there's not like a set first I do this then I do this and then

I do this they all have their different values and the key is that you're just using each one for what it's valuable for so sketching might be like a lot of

quick quick ideas maybe it's trying to figure out like what I need to code to make something work in a prototype just rapidly going through things my Sketchbook is like I mentioned kind of unintelligible to anyone but myself you

know it's my personal notes it helps me record the ideas experiment with them when I move into figma it's more of an artifact that focuses on the visuals and maybe like a simple click-through

prototype just to think about how things are working out potentially to share it with others on a zoom call type of thing and when I move into prototype it's more to like really validate

decisions solidify ideas share it with others in a way that creates an instant connection more so than giving a figma presentation and trying to tell a big story around what I'm working on so

moving between them is pretty fluid I might be prototyping something decide it needs to change the fastest way to figure out what that change is is just by sketching a few Solutions it is a theme that I'm noticing in these

conversations is that the people who do have some code skills under their belt rely on sketching a little bit more whereas the people who don't spend more

time in figma I try and not overthink like too much about what tool I'm using when and just focus on what is my end goal and what's the fastest way to get there I've seen some wild figma

prototypes that I would probably have to spend way too long messing around with all the the noodles and figma to get it to work but there are some folks who that comes very naturally to them and they can just blast through a bunch of

prototypes and that's totally valid you know no hate on like any different type of tool you want to use to get to the end goal I think it's just important to think about what your end goal is what

kind of artifact that looks like and what an effective way to get there is when is code the fastest way to prototype for you I'm turning to it more and more like almost exclusively now for

prototyping different things I think where it really shines is kind of when you're trying to achieve that level of fidelity that is indistinguishable from production right that's very hard to do

at least for me in figma there's might be a lot of like smart anime little glitches you know like it's a crazy powerful feature don't get me wrong but it's not going to be quite the same as

what you're doing in code or a tool like origami and I think that's really powerful you know like the higher Fidelity a prototype is in some ways the

exponentially more useful it becomes even in the early stages when you're trying to prototype an interaction and just quickly validate a decision if you

can get it using plain old JavaScript and H ml just like maybe you are using Times New Roman for your text because you don't have any CSS it can be super

fast I think folks underestimate how fast it can be to go from zero to a little working code prototype and part of the thing is to focus on the purpose of each prototype right like you don't

have to start from an idea and start coding something as if it's a fully fleshed out idea right you can make a little playground for yourself and code a single interaction or a single little

flow and and see how it works and go from there and you can duplicate the JavaScript file and make a totally new one and try again type of thing one of the things I've actually done at linear is I ship a little just internally a

little test flight app that has all of my prototypes in it so it's a really easy way or it's like probably the easiest way I found to share xcode prototypes with a a team and the very first page of the app is just an index

and it's just a list of all the different prototypes I built so sometimes you'll have like version one version two you can kind of go in and see the evolution try different versions that's what I turn to code for really

and when I turn to it okay so let's say that you are coding a prototype for some project that you're working on how often are pieces of that prototype actually

making it into production and if they're not why reach for code versus something like an origami maybe I think it depends on the type of prototype it is so that's

a little bit vague but for a better example is the linear onboarding screen for the bobile app you download the app you open it up and you immediately see this little like welcome to the app

signin basically page and we built a little layer of delight into that where the app icon is kind of there and it's floating appears to be floating like off the screen of the phone with a little Parallax effect so you tilt your phone

one way and it kind of reacts to that that was a prototype I created like actually before I joined linear I was experimenting with those effects in in Swift UI when I joined we wanted to polish the screen up a bit and I thought

this was a really unique idea so applied it to the linear brand essentially and experimented with it some more in that scenario I think the engineers I worked with copied and pasted a decent few

chunks out of my Swift UI prototype into the real app because the whole purpose was to like tweak these values to Perfection so that the effect worked in a lot of other cases the code I write is

a total mess like the engineers might glance at it when they are thinking through what they're building and like what edge cases I covered and how I handled them but almost never is it

specifically written to like be able to be put right into production and I think that's a pretty separate skill set and I think like not worrying about that lets

me move much faster in coding I am not a fantastic engineer by any means and I probably would struggle greatly to write production code for a lot of these

systems if I'm even capable of doing it right now but I can put a million State variables in a file and say when you change this this one flips and when you change that that one changes

and hook up a prototype like that much faster than if I actually had to make it legible code for someone that doesn't have as much of a coding background what are some of the ways that this kind of

sticks and stones prototype that you're creating is significantly simpler than something that would make it to production little bit tricky to answer because I am not great at knowing like

what is required for production code but what I would say is you can kind of just make a mess because the code you're writing is basically a means to in end for the artifact that is the Prototype

that you're going to be using so it really doesn't matter what it looks like behind the scenes if it works the way you intended it to because that's what you're using to communicate with folks now that's not always the case like I touched on the linear onboarding thing

but if you don't have a programming background and you start learning little bits and pieces your the data you use in it can just be pulled from an array it can be hardcoded if you really want if

you only need to change one number when you update a something in the prot type you can make only that a variable where everything else is probably in a production environment is likely to be

pulling from an API and kind of built more modularly and reusable components and things like that so that's all stuff you don't have to worry about if you're just building it for the end goal being

a single prototype I think for web a lot of times where designers really really sweat the details to make something feel amazing is in the hover State and

obviously that does not exist in Mobile so what are some of the areas where you might find yourself really sweating the details in the name of delight I constantly find myself wishing like

there's some developed way to hover your finger over something and like your iPhone to detect it maybe it'll come someday but I think one of the areas is kind of interactions and gestures and

things that are based in real physics or close to real physics so for example if you you swipe a modal that modal popup you swipe it away uh that it kind of

gradually responds to like the velocity of your swipe some simulated gravity and if you swipe it up into the right it doesn't just disappear from the view it gradually moves up into the right slows

down and then maybe returns back to the center of the view where it disappears I think doing things like that is one of those moments where you use it and you're you don't even

realize that animation existed because that's what you expect it to happen right if you swipe a piece of paper on your desk it's going to move the direction of your swipe so I think that's one of the areas that like really

adds that level of kind of invisible polish anything else that we should be talking about our questions I should be asking in terms of like how you have

grown as a mobile designer or someone who is like investing in this skill set of interaction design I think one of the big skills that is really valuable and

has really influenced my career a lot is kind of the skill of more broadly called storytelling and this is something that I really picked up and learned a lot uh while I was working at GitHub I worked

with uh Brian Lovin who I think was a a guest on your podcast before um and he was really fantastic at this and I I learned a lot working alongside him on the GitHub mobile app in that your job

as a designer may be to like solve these problems and build these user experiences that like let someone get a job done but the second part of your job is convincing the the team of people

you're working with that this is the right thing to build in this way at this time I think you can do a lot of great work and none of it may ship if you don't have that second part of the skill

set so that's where learning to really clearly Define the problem you're working on how your solution addresses it what the users are that like who they are that might be using it and when

they're doing that what I talked about earlier with mobile design might be more focused on like very quick interactions used in one to two minutes and then the bones put away and that's kind of like a

very valuable skill for working with teams of all sizes and kind of what led me into this road of interaction design and developing more higher Fidelity prototypes because I realized how

valuable having that prototype along with that story about the context of your work is you know you can set up the context and explain the problem you're solving and then show the Prototype and

say like here's the proposed solution this is what you would have if you're on board to build this in a month or so so is there anything that you're doing to make sure that you get the level of

feedback that you need because I do think when you're communicating in static mocks as you kind of alluded to earlier a little bit like there is more of a burden on storytelling like you

really have to use words to convey what is happening and the intent whereas like it's if it's a functional prototype you can kind of just hand it over but like how do you think about the right

questions to ask or even when you're sending out this test flight like can you go a little bit deeper into what you're doing to make sure that you are sourcing the right inputs from the rest

of the team to know where to take this thing something I still struggle with a lot of the time is sharing some work I've done maybe you like explicitly say in the beginning I'm looking for

feedback on points one two and three you present the work and you get feedback on one two and three but like maybe the conversations derailed by feedback on point4 I haven't found a perfect solution you know like you try and

educate your audience as to what feedback you're looking for as well as you can but inevitably more feedback will come in and I think you have to look at that as a good thing you know any feedback is feedback that I would like to be hearing because that's

something that can make the the work I'm doing better I think there's this other angle too where presenting something in a prototype even if it's just a click-through prototype and figma something very lower Fidelity and put

together can go a long way in terms of guiding that feedback right like if you show a bunch of static frames in figma it's very easy for someone to start start critiquing the visuals of something in the lower left corner when

what you're focused on is somewhere else but if you show this in a in a prototype and you start interacting with it that really draws the attention and focuses in on that and I found at least that

that will kind of hone the feedback more towards useful to like what you're trying to get feedback on and at least secondarily leave room for feedback on everything else can we talk a little bit

about your journey learning Swift UI and and maybe you could even give us a little bit of context first like what foundational knowledge did you have in code before really diving into this like

at what point in your career did you start to Tinker and explore in that world and then yeah maybe you could tell us about how you have went about

learning these new skills and specifically you know I'm seeing all these really interesting prototypes that you're sharing in Swift UI on Twitter and I'd love to just hear about your journey getting to the point where you're able to create something like

that there's a few different things that led me there I'd say like when I was in college part of my studies on human computer interaction involved some kind of like Baseline level knowledge of

computer science classes so I actually started learning Java and C++ stuff that I don't really have a use for today but taught me about arrays and variables and like conditional statements and kind of

that very foundational layer of coding so I had that knowledge and I had actually spent a good bit of time uh working in origami which is super

powerful tool you can do some incredible things in there it's basically like a visual code tool in a lot of ways and I turned to that because I wanted this

like very high ceiling of what's possible to create in a prototyping tool so that I never felt like if I was trying to communicate an interaction and I had to preface it with like this figma transition is a little janky it'll be

better in production that felt kind of like a failure of like designing that interaction well to me you know I wanted to like be in an environment where I could just do that that and origami let me do that but this is more a personal

thing I think with that foundational knowledge of basic programming principles I would always hit these little corners of origami where the way origami wanted me to do it and the way

that made sense in my brain like didn't quite align so I was kind of like fighting the tool a little bit and it got me far enough but I you know Swift UI came along and I had learned some

react just to build my own website before that and they're they're pretty similar in a lot of ways and it got to the point where I was spending enough time like frustrated trying to hook up the right nodes in origami to get my

result and I kept thinking like I know how to use an array in code better than a loop in origami so I turned to Swift UI and just started experimenting you know like a lot of my learning whether

it's icon design or 3D work or coding just comes from pursuing personal projects and like really hitting the wall of my knowledge and then learning just enough to unblock myself until I hit the next wall can be kind of a

frustrating process but if you if you persist you can learn a lot by doing that and part of it was also like being inspired by seeing all of this cool work that other designers were posting online

that was done in Swift UI and realizing the ceiling for what you can do in code even origami is just entirely endless you know if you can imagine it you can they give you a lot of tools to make it

very easy to like get most of the way there so I started just with some very small personal projects I like to just like start messing around I think Swift UI makes it easy to kind of take take a

static mockup in figma and recreate it just the visuals at least you know like that's a great way to start learning uh both things like flexbox if you're using

web Technologies or Swift UI like hstack and vstack and zstack very closely mirrors figma's Auto layout so if you're familiar with that it's really easy to like jump in there and start getting

some visuals on a screen and it's really rewarding even if it's something totally static that you can plug your phone in and hit build and run an xcode and have what you created visible in an app on

your phone I find that very rewarding so that kind of just leads to a cycle where like I would kind of come up with progressively harder to code ideas for just like fun little prototypes I could

experiment with in some free time and work on coding them and again when I'd hit a wall I'd go on stack Overflow and very more recently chat GPT is like my best friend for learning more coding

great time to start coding and unblock myself and then continue on to the next thing and go from there and then when I felt comfortable enough and fast enough I start applying it to my day-to-day work and that's like the more you're

doing it the more you're learning and the more confident you're getting with it and it kind of all snowballs from there let's say someone's listening to you their current ceiling of fidelity is a figma prototype they're inspired by

what you're saying how should they think about the which route to go down should they download origami or should they download xcode it's a good question I

don't think you can make a wrong choice chice I think when you open up each tool and you can use them interchangeably I mean they're very similar in a lot of ways I personally just like writing code

it feels a little bit more the code I write is theoretically going to be around forever you know Swift UI might change the Frameworks might change it might not run super well in the future

but origami files are very like confined to you can run this in origami and that's about it you again you can't really go wrong I just looking at the landscape I thought that I felt more

confident in my ability to learn more and more and apply that to broader things through code you know like maybe one day I want to build my own IOS app

and having this base of prototyping through xcode and Swift is getting me farther towards that goal than doing it all in origami that's one of the the factors that comes in but really like

just start small and start chipping away at it and ask questions when you get stuck and you'll learn a lot very fast and it'll be very rewarding in either tool you choose speaking of asking

questions what have you learned about interacting with chat GPT that's helping you get unblocked with swift UI that's a good question I don't like the idea of

turning to chat GPT and saying I need an app that does this and then it gives me code that I don't understand and pasting it into xcode and telling it what the errors are and letting it debug it

itself because I don't really learn a lot from that so what I try and do is like do as much as I can myself if only for like if I'm writing a bunch of just

visual like layout code not very tough to understand kind of like the base level stuff if I ask chat GPT to give me that boiler plate it might be like written with slightly different styling that I don't like to use and like I'm

just going to go back and correct it so I try and do a lot of it myself and when I get stuck on something I try and really isolate the problem and say like teach me about how to solve this don't just solve it for me I think that's

where you learn the most so I would encourage folks to if you know nothing about react and you're trying to build your first website ask chat GPD for the basics of react or like read the react

docs and kind of start there start coding it yourself when you get stuck and you want to do something that you don't know how to do ask it how you do that rather than like taking all of your code and pasting it and saying build

that for me I think you'll learn a lot more and it'll be much more valuable for you like as you keep going rather than always needing this tool to give you the answer and you're relying on it entirely

I mean so you're actually like typing in language like that like teach me how to think about X or teach me how to do X yeah a lot of the time they'll say like I want to I want this to happen how would I do that and then it'll say like

here's how you would do it and I don't give it all of my code so it kind of generalizes a lot of it which I find very helpful and then I'll say like okay like I won't literally type okay but

there'll be a piece of syntax it uses that I don't quite understand uh and I'll say can you explain why this symbol is in the code here and like what that means you know Swift UI has this thing

called trailing closure syntax which I still don't really understand it and you can write Swift UI without using it and for whatever reason a lot of people love using it it's just it makes your code

shorter to read I guess but I find it hampers my understanding so I'm like it uses a piece of trailing closure syntax I'm like okay wait explain like word by word in these three lines what each word

is doing and why you used it and then I'll kind of slowly get a better understanding is there a aha moment or just like some kind of thing that you've accomplished in Swift UI that had you

really excited recently that you could share there's this prototype I built it was a bunch of months ago now I think it was like back in January is but it's it's posted on my website and Twitter

where I tried to make a watch OS app grid interaction kind of on your iPhone so kind of that hexagonal like honeycomb shape of app icons rather than our 4x4

Grid or whatever it is on iOS and it's one of those moments this this is why I love code versus something like a figma prototype or a other prototyping tools are kind of like key frame animation

type stuff because I wanted to be able to pinch on the grid and see between like one and 100 app icons as you kind of zoomed out right what I did with the

help of some chat GPT was build an initial app icon and then say okay like you get your for Loop and you say for zero to 100 app icons I want you to place them each and every time you place

one offset it by this amount and this amount if it's in this position and two different amounts if it's in this position and suddenly you like hit the right incantation of your for Loop and your entire grid just appears and it

just works and those are those moments where I'm like I got it I did it this is my goal it might be silly and have no purpose at the end of the day but part of the fun was learning more Swift UI

was experimenting with this idea maybe a very small piece of that makes it into some of my mobile design work in the future maybe it doesn't but like that's kind of those fun little aha moments I

love in coding as a designer that bring me a lot of joy and motivate me to keep going can you help someone again who's listening who like doesn't have this technical background but they're inspired what are some of the pieces of

foundational knowledge that you think are most important that they should actively seek an understanding of in order to be able to build these more interesting experiments on top of it maybe it's helpful because like I still

probably don't know a lot of coding just enough to make some prototypes but I'd say like a a good foundational base and if you disagree with this don't don't

email me but is kind of like knowing your basic data storage like arrays will be super helpful if statements saying like if x do y if y do z type of thing

and then for Loops are kind of like or Loops in general just continuously run this code until I say so I think that's I don't have this definition off hand but that might be like the collection of things you need for something something

to be tur in complete which means like you can theoretically accomplish anything with the coding language so just having a really basic understanding of that and variables is probably the the other one there will give you this

Foundation where like you can write a bunch of really just awful code that some experienced engineer would never ship to production but will get you off to the races and like get you learning

and continuing to work so I'd say start there with some foundations they're in like every programming language so it doesn't really matter what you choose and it's easy to apply them across languages too I like your perspective

maybe an engineer would poke holes on the things that maybe you're missing or something like that but like you're making it feel very attainable and I've like seen the things that you've been able to build and it's like okay well

that doesn't sound that bad you know that's one of these these cool things with like teaching somebody something is often I find the best teachers are people who struggled with it initially

themselves because they can put themselves in the shoes of someone who is struggling to learn thing XY Z and relate to that and think like here's how I unblocked myself here where when you have someone trying to teach you

something where the subject just came very naturally to them it might be more of a like why do you not understand this like I don't know other ways to explain this that'll help your understanding so hopefully my struggling through learning

code can help others struggle a little bit less on their journey I me you're totally right it's like in some ways if you are interested in learning Swift UI the the last person you want to learn from is the expert in Swift UI like the

the more interesting person to learn from is like who's like maybe one or two rungs on this ladder ahead of me because they deeply empathize with the struggles that I'm going through and they remember

how certain things trip me up or or how challenging like wrapping around like this mental model was you can learn some bad habits along the way but like you can always iron those out and kind of

progress up to learning from the the expert themselves eventually well Gavin thank you so much for coming on and sharing about your journey I know I personally am inspired by all the things

that you're sharing and creating and you know it's quite obvious that you're someone that enjoys learning and kind of pushing on that ceiling of what you're capable of creating so thank you for

coming on today but also just continuing to put yourself out there and inspiring us great yeah thank you for having me I I really appreciate the opportunity I've love listening to other episodes of your

podcast so I hope this this one helps someone out there or inspires them or makes them curious about something hey it's red don't forget if you want to go

even deeper each week I send an email out to over 10,000 designers with bonus resources and key takeaways from these

conversations so head to dive. club/ to

sign up okay I'll see you next week