Thinking like a developer

Hi there. My name is Nick Basil, and this is a quick lightning talk on how to think like a developer as a designer.

And hopefully we're gonna save you a bit of money here so you don't have to go out and drop 12 k and months of your time on a code in bootcamp, uh, to start thinking like one.

So first and foremost, I wanna start with like a big picture concept that's gonna frame a lot of the considerations that we look at later.

First and foremost, there's this concept of front end and back end that developers are constantly kind of cycling through as they think about, uh, anything that they're gonna be touching, right?

Any of the work that they're gonna be doing. So that's, uh, and this is kind of a cute little, uh, meme about exactly how we think about front end.

It's that, that tangible physical representation, it always looks nice. The CSS has done well. It looks just like the mockups, right?

Uh, and then the old joke is that the back end is just spaghetti, right? It's just, uh, kind of like, uh, how UI and ux like drip on each other, front end and back end do very similar things in the developer world.

Uh, and so there's this old joke that the back end is all messy, but in reality, they're both hugely important and you can't have one without the other.

They're, they're necessary to build modern, uh, experiences on the web. So let's take a look a little closer. Look at both of these, right?

So front end, this is probably the thing we're most familiar with as designers, right? Uh, and probably the easiest thing for us to start wrapping our head around, right?

And really front end, it's all about representing the UI and code, right? So that tangible, that experience that we interact with, that users interact with, that is what, uh, front end is all about.

It's also important to be able to react to user input, right? That's another consideration of the front end, is somebody clicking this, uh, somebody interacting with it, and then also based on that interaction, kind of going to the back end and saying, Hey, the user submitted this form here, here is

that data stored for us? Um, or we want to see this, uh, collection of listings, right? Uh, if we're Airbnb, like, give us, give us those listings so that way we can show 'em to the user, right?

So asking the backend for data, asking 'em to change data, hugely, hugely, uh, important. But the front end is initiating a lot of those conversations, right?

And lastly, ensuring that anybody can use the ui, right? And this is accessibility, right? Really, really important. But also it's mobile, right?

Are people on mobile devices able to use the ui? Are people on browsers, cross browser compatibility, able to use the UI as well?

Are people with screen reader technologies or other assistive tech able to access the code, right? So front end is really concerned with all those things, um, primarily, right?

Of course, overlap. But, uh, and backend can come in here and be concerned about those things as well, right? It's not, it's kind of like ui, right?

That's really a UX consideration, UI consideration. Well, really they bleed back and forth. Same deal here. But developers start thinking in these sort of buckets when they are approaching problems.

So on the back end, right? We kind of alluded to this a little bit, but it's all about saving, retrieving, and deleting data, right?

It's that data management, right? That's why we're talking about databases, data architecture, schema, right? That's what we started thinking about on the back end here.

A lot of times this is initiated by the front end, right? We think about forms, is the classic example. You're submitting a contact form, you're sending the data from the front end to the back end, and that's what we're thinking about.

But this can also be initiated just by business logic, right? Maybe we wanna say, Hey, Fridays, that's a big sales day for us.

We wanna send a reminder email to all of our users, right? Guess who's in charge of that? That's back end logic, right?

Uh, and that's not initiated by users, right? They're not coming and saying, every Friday, I want an email. Maybe they are, that could happen.

But in a lot of cases, that's kind of a, uh, what we call a chron job or something that just happens, uh, based on time or, or chronologically, right?

Um, and that's, that's logic that has to be happening on the back end. And also, and this is something we forget a lot as designers.

Cause we don't have to deal with it that often, or we, uh, we should, but we sometimes easy to forget about it if you're not living, breathing it, but as access, right?

Authorization, authentication, right? Um, a lot of times you'll have a logged in experience and a logged out experience, right? Backend is really in charge of making sure that the right data is shown to the right users at the right time, right?

And that is a hugely important consideration for our backend devs here. And so that is, um, another world that the backend of is kind of primarily focused on front end.

It matters as well, right? Frontend dev definitely doesn't wanna show, um, all users the button for deleting the workspace, right?

That should only be for a admin users. There's a conversation there. There's the back and forth. But backend is really in charge of protecting the data and making sure that it's not, uh, editable or updateable or deletable at the wrong times by the wrong people.

So those are sort of big picture, right? Again, it's like Y u X, there's back and forth here, but when developers are thinking about their jobs, right?

There's typically a front end developer and a backend developer, and they're thinking about the considerations and concerns of what they need to build based on our designs.

They typically start thinking in these two buckets first, and it frames a lot of the other things that they consider, uh, as they move into different designs here.

So, let's see an example of this in action cam. So this is Airbnb here, right? A little gift.

Um, and this is their ui, right? And so it is, um, just their search interaction here. And you're hopping in there.

You're clicking on the front, the search bar, you're putting in your inputs, All this right here, this is all front end actually, probably.

Um, it's all happening in their components. They're, they're react, I'm assuming components. Uh, maybe they're using view, who knows. And then as soon as they hit that search bar, right, they're actually submitting a very sneakily designed form.

And it's saying, Hey, given this input, given these parameters from the front end, give me the listings that we have in our database that match this criteria, right?

And so, as you can see, as a developer, as I'm looking at this interface, as I was given these mockups, I'd be saying to myself, Okay, these are the front end considerations.

This is all this interaction, and these are the components, right?

And now as I think about my backend, what, what is the data? Well, I know I'm gonna have all my listings, and then I have search criteria, right?

Okay, So I can filter my listings based on that. Now I'm thinking about manipulating my data and returning a sort list that is a data consideration that's backend, right?

So you can see developers, when they're thinking about the experience, they're often flipping or, um, going back and forth between that front end consideration and that backend.

So this conversation really frames pretty much their entire perspective on everything. This is a front end consideration. This is a packet.

But now we're gonna look at three a little bit more detailed considerations that developers are frequently thinking about, uh, as they approach a design.

So for the most part, they're focused on components, they're focused on interactions, and they're focused on data and components.

Very much a a UI of front end concern interactions. Start bleeding that line between you, uh, front end UI and backend.

They can be both. It can be one or the other. Uh, but interactions hugely, hugely important. And lastly, data, again, that's another one that sort of bleeds the line, but also hugely important for, um, both front end and primarily back end engineers as well.

So let's dive into it here. So we have this little meme here. Uh, I know we work in components a lot as designers, right?

It's, it's kind of, we've got this trend. Now, it's all components. And the crazy thing is for developers, it's all components as well, especially on the front end, right?

Everything that we're doing now, we we're trying to componentize, right? Because it's easier to maintain, it's less work for us to build.

Um, it's got all sorts of wonderful benefits, right?

And reality, we're actually thinking pretty closely to our developer counterparts, but we might not always have the right language or communication to explain to them what we're thinking about.

So that's looking an example here and sees in action, right? So we've got some featured listings or just booked in the United States, right?

These ones are hot commodities, They got snap right up. Uh, and as you're thinking about this as a designer, you're probably thinking like, Okay, I've got this in Figma.

This is my Figma component. We've got our image right here. We've got our title, we've got our rating. Okay, that could be maybe an auto layout thing.

And we'll have the whole thing auto layout, right? Um, price that's a little bit different. So we'll have a different treatment for that, okay?

But you can see very easily, right? You've got your, your groups, your layers, and it's all coming together.

Funny enough, you show this to the developer, they're doing the exact same thing. They're like, Okay, I've got four components here.

Uh, I'm gonna have my image, great, I'm gonna have my description. Awesome. They're just thinking about it in html, likely, um, maybe, maybe some other template language.

But that's, that's primarily what they're gonna be thinking of this in. Uh, and then they're gonna start thinking about the interactions and the data after that.

But both of us, we're always thinking about components, right? And so if we look at this, right? What does this look like in Figma?

That's our layer list, right? We've got our image, boom right there. We're starting to think about the content below. We've got our heading, okay, that's gonna have that data inside of it.

Description, price. That's how that's gonna look. And now look over at the code on, on the right hand side.

Don't worry about the syntax. Syntax is not important. What I want you to look at is the organization of that code, right?

It's just like ours. It's just nested the exact same way. They've got the image in there. They've got another sort of container or folder for the content, another one for the header, those other two pieces, right?

Uh, can, can live on their own there, right? They're thinking in exactly the same way as we are with these components.

Uh, we just don't even realize it, right? So a lot of times for us, it's communicating, Hey, we've thought about this.

This should be a component, uh, in your, in your, uh, development system, in your, in your code styles or your design, uh, your, your code snippets library, right?

Uh, in your, in your pattern library. And then they can go and they can, they can build from there, right?

And so making sure that we're communicative of those things, that we've, Hey, we've thought about this. It should be a component.

We want you guys to treat it like a component. The developers are already thinking about that and, and thinking that way.

So we just need to connect the dots for everybody and help them see, uh, what they're already seeing and what we're already thinking.

But developers, they're thinking this way. They want to think this way. They're super happy when we do as well. Alrighty.

So now we've got, uh, our next section interactions, right? And I'm so guilty of this as much as the next designer, right?

The deadline's coming, the saying, Hey, we really need those designs for the dev team, right? Uh, and you say, All right, here are the static mockups, uh, and, and just get developing and we'll go onto the next project, right?

And in reality, we're doing ourselves, uh, and our developers a a huge, huge disservice. And ultimately, our users, right? Cuz they have to consume this.

Um, if we don't think through the interactions, right? Uh, and we don't push on to that interactive prototype or whatever tool we're using, we don't have to do interactive prototypes, but that's a popular one.

Uh, but we, we need to at least at some level be communicating interactions because our desi, our developers, that is the next thing they think about after a component, right?

They say, Okay, I've identified my components. What are the variants? What the state to that component? And then how do we flow between those variants?

What does that look like? Because they're gonna ultimately be responsible for implementing that and, and creating that reality, right? So for them, that's, that's immediately what they're thinking of next.

So let's go back to this example here cuz it's such an interaction heavy example here, and it's, it's a really great one, right?

So all this is happening on the front end. You've got your sort of search bar component, right? And it's got the closed date.

Now it has an expanded state, right? You're clicking, uh, all those buttons there, each of those inputs on that, uh, search bar, have a state.

And then you've got, um, that component level interaction plus the journey level interaction, right? Notice there, it's subtle, but like when we, we call it out, it's a little bit more obvious.

When you click on that search bar for the first time, it prompts you straight to that where, And then as soon as you select something where it goes to check in, right?

So the developers and, and the designers on this project, they thought about not only the component level interaction, they also thought about the journey level interaction, right?

What does the state, when the, where, uh, input is selected? And then what should happen once we've made our wear selection, right?

This does not happen when a designer just hands off its static mock up to a developer, right? That's not, that's not not how these interactions get made.

What happens is our, on the design side, we need to think through the interaction, just like our developers thinking through the interaction, right?

So we just say to ourselves, Okay, what happens next when we click this button, this input, this, um, whatever we want to have, be actionable in the design.

We need to ask ourselves what happens next? And then after that, what should happen next in the user journey? And then we need to articulate that to our developers in order for these, uh, interactions to happen.

Of course, a ton of tools for this.

We can use Figma, um, we can use framer, we can write this out in text. We've definitely have seen design requirements that way.

Um, and, and my favorite really is, uh, once the developer is ready to actually implement this, sit down with them, kind of say, Okay, we're gonna do this together.

And this is a great way to learn how they're thinking about interaction design. Uh, and a great way for us to sort of finesse and say, Okay, let's, let's tweak the easing here.

Uh, and actually it look better in the mock up, but it's really not coming out on mobile. So let's think about it this way.

Um, you could have all those real time conversations and really finesse this remotely or in person, uh, and make this a really, really phenomenal design.

And I bet I would bet a lot of money that the Airbnb team, they paired on this.

They definitely had tons of design review. They probably sat down with their engineers and they worked through this interaction together because it's very robust and well thought out, and they communicated it really nicely, right?

And so our developers, right, they're thinking about the component, those static things. And then they say, Okay, what can those static things do?

How are they all connected to each other? That's the next thing that they're thinking about. And so we can be superheroes if we think through that as well.

And then give them not just the states, but the transitions and the journey through that experience as well. This is a really famous example I did want to touch on, right?

This is how complicated and complex this is. Get, this is Slack. Um, and this is their logic for sending a notification, really like the fundamental experience, the interaction experience in their app, getting that notification, getting that prompt to go back to a channel or to a message and check it

out.

Uh, this is, this is the logic from this is from their engineering team, but I'm sure design had input on this of how their, uh, their message, their notification badge should show up.

And so this is the level of detail you can get to maybe aspire to. Definitely not everything is as complicated.

Um, but this is how it can be visualized and how you can communicate this level of depth in your interaction experience to your, to your developers.

And this is what they have to think through in order to make it happen. This is the logic that they put in place to make it a reality.

And so this is how the level of detail that they're thinking about this at all. Alrighty, last but not least, let's talk about data.

Right? So components, very much a UI concern, uh, interaction design can, can be both, right?

They hit that search button in that, in the, uh, in the Airbnb experience, and then they go, that's a, a backend request.

They get the results back. There's some backend considerations there. So back and front end, always framing the conversation data. Huge, huge part of backend.

Also really important for front end as well. So let's dive in here. So I think we, again, similar to components, we actually think more in terms of data than we realize, and we don't give ourselves enough credit for it, right?

So if we come back to our, our Figma component for this information, if we've been labeling our Figma files, uh, our Figma layers correctly, we've probably identified a lot of the data requirements for this component anyway, right?

And we look through here, right? There's the image, there's the title, Okay? Rating, description, price. Great. Okay. So we've actually, like in the process of designing this, we've probably thought through all the data points that need to exist within this component and therefore within the overall

design, right?

And if you think about it, our designs, if you took away all the texts and you took away all the images, what do we have?

We, we've got boxes on a page, right? We've got borders and shadows, we've got nothing, uh, nothing useful to a human at least.

And so the content, the information that we are sharing through our design, that for a developer's data, and what a developer is thinking is, how are we gonna store all this?

Where are we gonna put it so we can access this later, uh, when the user needs it at that right time, at that right moment for the right person, right?

And so that is, uh, what the developer thinks of next. They've thought through the component. They say, Okay, this is a component, this is the interaction.

What is all this data? How am I gonna store it?

And how am I gonna show it at the right time? Right? So that's the, like the last sort of thing that they're, they're thinking through on their criteria.

Um, so for us, right, as an, uh, as designers, we can start thinking through this for them and start identifying the pieces of data so we can be more communicative about exactly the data requirements here.

And, and this is tricky, right? This is moving from, um, sort of very tangible things to a lot more abstract things.

And what I like to do to bridge this is to think in terms of spreadsheets, you know, Google Sheet, Excel, whatever works for you.

Um, thinking in terms of putting the information that we've designed into a spreadsheet can be a really helpful exercise for identifying the data, uh, that our engineers are gonna end up needing.

So if you did this for your developers, they're gonna love you forever.

But really thinking through, okay, for this component, I've got my title, I've got my rating, I've got my description, nightly price, Okay?

And that's an interesting distinction, right? It's nightly price. Uh, and then I have the image, right? And so a developer sees this and they're thinking, great, this is like our database table, all those, everything in bold there, that is a column that row there, that's an individual entry into the

database, right? And they're starting to think about this in terms of, um, the data model, the architecture, the schema for the project, right?

And that's for their backend considerations there. So Excel is a really powerful tool, and it is a great way for us to sort of visualize what the database engineers, the backend engineers are thinking about for the data requirements, right?

And it's a little, little more complicated than this, but it's, it's a really good bridge for us to start thinking about it for sure.

The other thing that I wanna call out here is there's different types of data, right? Their title, for instance, that's, that's text, that's a string for developers, right?

Versus the rating that's afloat or, or a, um, a number with decimals, right? So for them, they not only have to think about what the information is, they need to think about what type of information it is so they can store it correctly, uh, in a way that, um, the computer can process, uh, correctly.

So description, that's another string that's more text nightly priced. That's an integer. It's a whole number. Like what happens if we have sense, right?

That's a very, like, what if in our design, half the components had sense and half of them didn't. Well, now we have design inconsistency, right?

So there's internal consistency. We could pick one direction or the other, uh, or maybe we really do need to support both, and we should make our developers aware of that, right?

So they're gonna have those sort of questions at they start interpreting your design here. Uh, and the really cool thing is this data, right?

Once we've sort of done it, modeled can be used repeatedly throughout the application experience, right? So if we go to the individual page for that listing that we were looking at there, what we can see, we've got the description right here.

We've got the rating, we've got the price per night, we've got the rating again, right? And we're reusing this information repeatedly throughout the experience.

And as developers, we're always thinking like, okay, like this is the model, this is the Excel spreadsheet. How many times can we just store this once and not have to store it again or duplicate it or move it to this other relationship or entity co.

Where can we keep it track of it once, um, so we can keep our data needs as consolidated as possible, right?

So that's the the other big consideration that reusability of data, right? So as we design our, our flows, right? We've got one page with the tile, the card, another page for that, for that, uh, representation of it.

If we could start thinking about, okay, this is the title here, and it really should match the title over here, your developers are gonna love you because now all of a sudden they don't have to have different data requirements for these two pieces of design.

It can use the same requirement, right? A lot of times we might have like a truncated little title over here on the title and a full title over here on like the, in, on the, the show page or the, or that layer down.

And for a developer that's hard. It's like, hmm, do I, how am I truncating it? What's the logic?

What are we doing over here? And for them, that becomes a challenge. So, uh, as we think through our data needs, we, we really start articulating better designs for people as well.

Alrighty? And last but not least, there's one other piece of data that we're, we're seeing here. Uh, and then I want to go, go over here.

And that is relationships, right? So right now we've only been talking about single listings, but we can also see there are reviews here, right?

78 reviews, right? And if we look at that page, we can see that this review here has content. It has a user, it's associated with the stay.

There's properties, uh, that individual ratings that are associated here. And they all aggregate up to this. There's a lot of math and data and information that's going on here, right?

And for us, this is just another screen in our, in our mockups, but for the engineer, he has to look at this and say, Oh, there's, there's things going on here.

There's information, there's data, Uh, and we need to think through the relationships between all these data, right? So in this case, right, we're looking at these reviews, we're saying, Okay, this will have content and it will have a user, and implicitly it's gonna have to belong to a listing, right

? You can't have a review about two different properties. It's about, uh, one listing, one visit even. Um, so now all of a sudden you're defining a relationship.

So the listing can have many reviews, Reviews belong to one listening. And in engineering, that's a one to many relationship.

But as designers, what we can start thinking about is, Oh, okay, this information is actually like, should have one parent, right?

It should belong to one thing. Same way we think about our, maybe our card components, right? Those should really only belong on the homepage, right?

Or they should only belong on the search page, right?

We think of relationships all the time. Uh, we just don't call 'em that as explicitly as engineers do, right? Um, and so when we're thinking about designing another page, adding something like reviews or comments, right?

That's another great example. Comments would belong to this listing, or comments belong to a blog, post reviews belong to this eCommerce item and this purchase, right?

If we think about Amazon's use case. So we really need to start thinking about the data relationships in addition to the individual data model or entities or Excel tables that we were thinking about earlier.

So that is, uh, data kind of flows and requirements and all the things that the developers are starting to wrap their heads around already.

So wrapping it all, bring it all together here. Here are some tips to think like a developer as you approach your next design project.

So first and foremost, remember the framing. Does this design impact the front end, the back end, or both, right? Typically it's gonna be both, but sometimes you'll have just those front end, back end requirements components.

First and foremost, is this design as internally consistent as possible? Do we have decimals over here for our sentence? Do we not use, we use whole dollars over here, right?

Um, do we have all of our variants? Are they as consolidated as possible? Do we have two really similar variants that maybe we can combine into one, right?

How do we make this as as internally consistent as possible? And then also, have I used as many components as possible?

Is everything a component that could be a component? So that way it might developers know, uh, to use those and that they're thinking about this anyway, This could give them a, a boost forward in their thought process for the interactions, right?

What are the component level interactions for a button? What happens when I click that button? If I hover over the button, what do the states, what does that transition between the state look like?

And then what happens once I've clicked it? Where do I go? Does the form submit? Do I, uh, see a toast?

Notification on success? Do what about an error, right? Like what are those journey level interactions? Um, and how should those be represented as well?

And lastly, data. What are the individual pieces of the data and the design? And then what are the relationships? How do they all interconnect with one another?

And lastly, who should have access to this data and when should they have access? Should all the users see the delete the workspace, delete the account button?

Or should only the admin users see that? Maybe only the owner of the account should see that, right? Thinking through all those different roles and permissions, hugely, hugely helpful for your developers and how they're thinking about this as well.

So hopefully we've saved you $12,000. This was a little bit more of a primer on how to think like a develop.