Design & Development — Part 1: How Digital Designers Can Help Developers
Working as a software designer means a lot of interaction with developers. We often joke about the “rivalry” between the two departments, but if left unchecked, this can actually become a blocker between projects and lead to disruption. The biggest pain point between designers and developers is understanding the limitations of each job. Communication and empathy are key, so for the first part of this series, I want to go through some things a designer can do to make the lives of developers easier.
Before the Design Process
Learn a little bit of code
Let’s start this list off with a controversial opinion: do designers need to code? I have a computer science degree, but I don’t have to write code in order to do my job. However, it’s still important to have some understanding of what’s being coded. As for the language, it depends on your company, but HTML, CSS, and Javascript are good for websites and Swift or Kotlin for mobile design.
Now, you don’t need to master the language, but you should be able to tell what it’s doing at a glance. This will help you picture how long a design might take to build. It will help you empathize with your teammates. And it will make you an asset later on if you’re in development cycles and you’re able to just go into a codebase to make a quick color change rather than pestering someone constantly. You’ll be able to understand what a developer can or cannot reasonably do, which leads into the next tip.
Understand the limits of what can be built (and accessible)
The hardest line to balance on as a designer is between being a creative spirit, but also grounded to reality — in this case, the limitations of what a developer can actually do. Having custom buttons, styles, and animations will simply create a headache for a developer, especially if they’re running on a tight deadline. What might seem easy for a designer to create can take days for a developer to implement.
Take some time to empathize. Code out an animation yourself and see how long it takes. Talk to an engineer about your ideas before implementing them to get feedback.
Accessibility is something to always be aware of as well. How does your design work for someone using a keyboard or a screen reader? Add in those considerations when you’re building the user experience.
Know the difference between iOS, Android, and web standards
This one is a little niche, but has gotten me in trouble a few times when designing a mobile app. I wouldn’t say I’m an Apple “ride or die” fan, but I own an iPhone, so naturally, I am familiar with iOS components. I was once on a project to port an iOS app to Android. It took a while to break away from the Apple mindset and learn Android functionality. It’s been even harder to create designs that are neutral and suited for either environment!
On the flip side, being familiar with design standards makes it easier to know what’s in your toolkit and can drive design decisions. Should the navigation go on the top or bottom? That depends on what system you’re using. Should you use an Apple action sheet or a Material Design bottom sheet?
Here are three good places to start for mobile design guides:
Apple Human Interface Guidelines
Web design might be a little tricky since there aren’t clear cut guidelines, but you can familiarize yourself with HTML components and read up on usability!
During the Design Process
Keep engineers in the loop early on
Between planning stages, UX wireframes, and high fidelity drafts, try to meet with at least one engineer during your process. They can help guide decisions through their experiences. Maybe something just isn’t possible the way you’ve described, but there’s an easier solution that they’ve coded before. Their perspective can not only help unblock you during creative stumps, but stop a design before it runs off the rails.
It also establishes trust between the design and development teams. If they have some skin in the game, then they’re more likely to follow through on the designs or willing to compromise a bit more. Plus, you’ll be the one they come to when they need help.
Try to account for all use cases
If you don’t have a design for a use case, your engineer is going to have to take a best guess at what it’ll look like. Not saying they all miss the mark, but if the design is something you want to have domain over, then you will want to get rid of any unknowns for the development team.
Now, I put “try” in here for a reason. You’re probably going to miss some use cases, and that’s okay because you’ll get better with more experience. In the meantime, try to make some sort of diagram or flow chart that shows all the possible cases a user can end up in, including error states or network failures. Even the outlying use cases where you think “No one could possibly fail this” — someone will.
Tools for mind mapping, user flow diagrams, and even a simple text editor can help you plan ahead. And, talk to your engineers beforehand to see if you missed anything.
It’s also helpful to add in states for buttons such as unselected, selected, or not selectable. Include primary and secondary buttons. Add in a keyboard on the screen to show developers how elements should look pushed up. What does the loading screen look like? What about empty text fields or ones with the max amount of text?
Consider different screen sizes
I get it, designing for an iPhone X is fun. After all, it’s the biggest screen. No one wants to remember the SE or an iPhone 8. But, you can’t just ignore the fact that yes, some users still prefer a smaller screen, especially with Apple’s latest upgrade to the SE.
You don’t need to create all screen sizes for each individual artboard, but keep in mind when you’re adding certain elements how cramped they may end up on a smaller size. Maybe create a few basic screens such as the login or home pages so the engineers have some reference on spacing and margins. And now would be a good time to mention spacing…
Keep spacing consistent
Don’t place things without rhyme or reason. Using a grid can help create layouts that are pleasing to the eye, but be consistent with them once you start. For an engineer, going in and doing minute customizations for every little factor is incredibly tedious and annoying. Some might not appreciate having a random “20 px” top-margin paired with “13 px” bottom-margin.
Try to work with the same factor. I tend to go towards factors of 4, so keeping things spaced out at 8px, 16px, 32px, and so on. You can do factors of 5, or 10! Just make sure that there’s some sort of pattern to it.
Create an easy-to-follow style guide
When you eventually move onto the high fidelity stage of designing, make sure to create an accompanying style guide. You should be consistent with the colors and fonts you choose. Then, put them all in an easily accessible document or page. Also, feel free to name things so that developers can refer to them later; otherwise, you might end up with “dark_blue,” “darker_blue,” and “blue” as the names.
Put the font name, font size, and font colors outside the text styles you created for reference. Add hex codes next to colors and gradients. Also, keep a nice spot for your symbols. Make things exportable as well so that developers can reference this page and grab the assets they need.
Name layers or files with titles that make sense
It’s tempting to just leave the file with several “Rectangle 1,” “Rectangle 2,” and so forth everywhere. You probably have a billion “Copies of…” everywhere. However, you’re not doing anyone any favors by leaving this mess later on. Take the time to go back and name layers and shapes with their actual function. Group things that make sense such as text fields with their sample text. Entire modals with buttons. Don’t forget to name the actual artboards you’re using. Try to use some numerical system to order them, especially if you have to export anything. Also, note some things that need to be made into assets and make sure to include those into your style guide from earlier!
Try to do this step as much as you can throughout the process; however, I know it can be interruptive to your design flow if you’re focused in the moment. So make sure you’re cleaning up after you’ve wrapped up a design session. Or be like me and save it all until the end. Whatever works. Just make sure that you’re not handing off a complete mess to the engineers!
This is going to help them stay organized, especially if they need to export any screens and you’ve got them in order. It will also give a good point of reference to what something does in case there’s not enough context surrounding the design. This will help you in the future should you choose to come back to fix the design and you can’t remember where you left off. Plus, it makes locating certain elements easier in the long run.
Leave notes on animations if there’s no prototype
As much as I love a good prototype, sometimes there just isn’t enough time for one. So doing the best you can, leave some notes for the engineers to see what needs to be animated and how. Do you want fades or slides? There are quite a few standards out there, but if you have something custom in mind, it’s best to make sure your engineers are on the same page.
However, I wouldn’t recommend custom animations in the first place if you’re pushing a deadline, thus you don’t have the time for a prototype. But hey, you make your own judgment call.
As our senior engineer puts it, “There’s nothing a developer hates more than the word ‘morph.’”
Refine and polish designs before handoff
This one sounds like a given, but really scrutinize your designs with painstaking attention to detail. You’ve been looking at them for a while, so some things might be missed.
Symbols/reusable components are helpful in making global changes, but sometimes they goof up and you end up missing a few buttons here and there. So take your time when reviewing your designs. Are there any typos? Are the layouts all following the same grid system? Is the same color being used everywhere? Are fonts where they need to be? Bringing in a fresh set of eyes can help with spying any jarring mismatches you didn’t catch.
When you think your designs are finally ready for handoff, try to schedule a meeting to go over it with at least one engineer, if possible. This allows them to ask questions and really understand your intentions behind your designs. It also opens up a dialogue for any further changes, although, you would ideally already be communicating with them throughout the whole process.
After the Design Process
Learn the engineering process for QA design audits
Learn what process your development team has placed for reporting bugs and assigning tasks. Is it Trello, Jira, Github, or GitLab? If your team is implementing agile methodology, chances are there is some sort of ticket creation involved.
Keep up with the latest production, QA, or dev builds they release and start doing your own design audits. Then, instead of sending a long list of things to an engineer that will just get lost in the mix, start adding tickets yourself.
Better yet, ask if you can take over on some smaller tasks like color or font changes if you know how! Do what you can to help the engineering team.
That is, of course, if they’re okay with it. Respect their boundaries. After all, you’re in their stomping grounds now.
Be available to answer any questions
Now that your designs have been handed off, you can continue working on some other project, or maybe start implementing version 2! But keep yourself available to answer any questions that pop up from an engineer. And don’t feel bad about this — it’s good that they’re asking questions rather than making assumptions! If you’ve established trust with them from before, then they’ll continue to trust you to guide them in the right direction.
And should they point out something that you missed or didn’t account for, thank them! Then, promptly fix these in the designs and notify the team of those changes. Your job is to keep the file as a source of truth for them.
Let’s refresh! Here are the things a designer can start doing to make the life of a developer easier:
- Learn a little bit of code
- Understand the limits of what can be built
- Know the difference between iOS, Android, and web standards
- Keep engineers in the loop early on
- Try to account for all use cases
- Consider different screen sizes
- Keep spacing consistent
- Create an easy to follow style guide
- Name layers or files with titles that make sense
- Leave notes on animations if there’s no prototype
- Refine and polish designs before handoff
- Learn the engineering process for QA design audits
- Be available to answer any questions
The biggest takeaway is that you want to get rid of as much guesswork for the developer as possible. Don’t have them do your job too! Learn a few skills for yourself. It really doesn’t hurt to know some code.
There will be a part 2 coming out soon that reverses the roles and talks about what a developer can do to make a designer’s life easier. Until then, let me know if you found any of these tips helpful or what you do differently at your company!
Here are some cute kittens to end this blog. Thank you for reading!
