Article summary
Being a designer on a software project can be difficult. There’s a lot of nebulous space to work through. Who are we building this product for? What is our value proposition? How will we elicit delight? What minimal product should we start with?
On top of all that, there’s also the question of, How do I keep the development team fed with designs and happy?
If you’ve ever found yourself wondering what you can do to be a designer that developers love to work with, this post is for you.
1. Be Organized
I get it. As a designer, sometimes your files can get a little messy. You’re iterating constantly. You’re moving quickly. And who wants to “finalize” a file when you just know your customer is going to want another round of revisions?
It’s totally okay to operate in this mode while still in a state of converging, gathering feedback, and iterating on what you’re designing. However, once your development team is gearing up to begin building your designs, it’s time to get tidy.
Here are my favorite ways to keep things neat and straightforward for the dev team.
Utilize a tool like Zeplin for design-to-dev handoff.
Zeplin is great for many reasons — so many that I wrote about it already. The gist, though, is that Zeplin creates one go-to source of truth for the development team to work from. That means they won’t have to sift through your Sketch files to hunt down that hex code or export that icon. And it means you, lovely designer, don’t need to worry about them accidentally breaking your file by opening it without having the correct fonts installed.
Create a detailed style guide.
You can create your style guide in a myriad of ways, but if you’re already using Zeplin, I recommend housing your style guide there as well. In your style guide, be sure you include:
- All text stylings (h1, h2, h3, p, input placeholder, input, etc.).
- Colors with names (so the entire team will be on the same page when you ask to change the h2 from “midnight green” to “forest green”).
- Buttons in all states (resting, hover, pressed, disabled, etc.).
- Components in all states. This means not just the “happy path,” but also what each component looks like if there’s an error, if it is empty, etc.
- Icons and imagery. Before exporting these, be sure to talk to your dev team about the ideal format.
House your files in one place, like Google Drive or Dropbox.
I know what you’re thinking. I just told you that using Zeplin would mean the development team won’t need to access your files. That will be true most of the time. However, there may occasionally be a situation where someone needs to access your source file. Maybe an image needs to be exported differently. Maybe you’re out sick and forgot to push a screen to Zeplin. The point is, things happen. Be ready for those things by making sure your files are accessible by your team.
They should live in a shared drive, organized in a logical manner, with document names that make sense. No login_v9_final_FINAL.sketch, thank you very much!
2. Pair Often
At Atomic, we are strong proponents of pair programming, that is, two developers working together to solve a problem at hand. Pair programming is not new, and it is likely something you’ve heard of or that your team currently does. One of the many reasons we love pair programming is that it can help reduce risk. Two heads are better than one after all, right?
This is true of a designer/developer pair as well. Below are a few situations where I recommend pairing with a developer.
Pair while designing a new solution or workflow.
Pairing with one (or multiple) of your developers will help you better understand what technical constraints exist. Perhaps the solution you had in mind is not even technically feasible. Perhaps it is feasible but only if tackled in a specific way. Knowing these constraints before you spend time designing the solution in a completely greenfield manner is ideal. This will reduce the risk of sinking time and energy into dead-end routes, and it will help you reach a solution quicker.
Pair when the dev team is implementing a tricky workflow or animation.
You might be thinking, “I’ve done my tidy-up homework — the developers have access to my super-slick style guide and screen designs. Why do I need to pair here?”
Some things are simply hard to define statically. For example, perhaps there’s a loading animation you had in mind. It’d be quicker and easier to sit down with a developer and pair on the timing of each piece of the animation than to try to define it in a user story for them. This can also be true of larger complex workflows.
Pair by being “on call.”
One of the best ways to support the development team is to operate as if you’re always on call for them. Sure, you have other priorities. You might have a round of user testing to prepare for, or perhaps there’s an upcoming feature design you’re preparing to share with your stakeholders. Of course, all those things are important too!
However, making sure the development team can get quick responses from you when they have questions is the best way to ensure the design principles you’ve laid out will be upheld.
When I say “on call,” I mean this within reason, of course. You certainly don’t need to answer questions outside of your normal working hours. You can and should still be present in other meetings and workshops. If a question from the development team comes up, move responding to them to the top of your to-do list for when you’re at your computer and ready to go heads-down on designing.
3. Be Flexible
As a designer, you have the pleasure (and sometimes daunting task) of creating design patterns and standards that elicit delight. Finding the right balance of “oohhh, shiny!” and “let users get the job done” can be tough.
Sometimes, you find what you believe is a perfect balance, but you’re still asked to compromise. This can be frustrating, so try to remember: software is expensive to build, and sometimes cutting down on a smidge of delight is necessary to get an initial product out the door in a timely fashion.
Be willing to be flexible (within reason) to help your team ship your software on time. This might mean keeping infrequently used interactions straightforward and utilitarian, while saving your moments of delight for aspects of the product that will be accessed often and truly set it apart from others. For example, you might choose to keep a settings menu straightforward and to the point, while spending extra time creating a unique dashboard experience.
We’re in this Together
Remember, at the end of the day, your team is likely striving for the same thing — to create a great piece of software, within the constraints of your timeline and budget. Staying organized, pairing, and being flexible will help you get there!