Design and Development Collaboration: Best Practices, Tools and Guides

The visual design and front- and back-end development teams at Revelry collaborate on nearly every product build it tackles. We sync with our internal team to go over project documentation and details, communicate with our innovation partners, and have discussions about process and implementation.

The Revelry design process itself is a roller coaster of wireframes, mockups, UX discussions, and most importantly, teamwork. And then, the almost-never-ending collaboration and handshake work between design and development begins.

But First, the Design Journey

As a designer, these are things I keep in mind when setting up a new project.

1) Scaling Down Design Fidelity

One of the most important things to keep in mind is to use your time wisely, and choose the best route to take in order to get the project done in a timely manner. Does the user flow actually require a mood board or sketches? Can you skip that step if everything is straightforward (only a few screens already mapped out) so you can move straight into mockup-land? Would it be more beneficial to create quick wireframes versus detailed mockups?

These are all important questions you need to ask yourself and discuss with your teammates before jumping into a project. When you need to move quickly, quick wireframes might be the best way to go. If you need more detailed screens with some new branding, mockups will be your best bet.

2) Keeping Communication Open

It’s very important to keep constant communication between all team members: clients, developers, QA, product managers, etc. This way, everyone stays on the same page without throwing a curve ball during a presentation. There may be some key details missing that the client forgot to mention, or there may be a component that you want to use that might require some extra thought and input from the developer.

Everyone is designing this product, even if not everyone is actually doing the sketching. Design never ends: it requires constant alignment from all stakeholders.

Small questions and staying open to all feedback is certainly key, and this can potentially save you hours of time in the end.

3) Fearlessly Asking Questions

CJ at Revelry wrote a great blog post about why your bad questions are actually good. The first type of question she writes about, the nitpicky question, also pertains to all things design-related. You can save so much time in your design journey by clarifying something with the team or the client. Even if it is a nitpicky question, it’s always good to ask. Your team will thank you in the long run, and you’re preventing any ambiguity amongst the team and the project.

Useful Collaboration Tools for Design and Development

There are tons of useful tools out on the world wide web that are available for designers, and many of them will make your life easier during this hand off (or handshake, as some more eloquent folks might say) between design and development. Here is a list of the most beneficial tools that I use:

1. Sketch, InVision, and Craft for InVision are essential tools for wires and mockups
2. Let the developers know which Icon Set will be used (Material Icons and IcoMoon are two of my current favorites)
3. Export all needed images for the team. I usually keep these in a shared folder in Google Drive – along with keeping them in the file structure – so the whole team has access to grab what they need.
4. Generate all Favicon sizes (https://realfavicongenerator.net/ is a great tool to use)
5. Generate all App Icons (the Make App Icon generator desktop app is worth the $10)
6. Fully discuss plugin-required components with every developer on the team. It’s very important to elaborate beforehand, so you’re both on the same page and know how that plugin will be implemented.

Stylesheet Guides: A Developer’s Bible

Stylesheet guides are fun to create and extremely beneficial to all members of the team, especially the developers. This can be done in Sketch as a mockup, but at Revelry, we implement all of the styles and set up the stylesheets for the styleguide. You can keep it simple, with only listing out basic styles, or get a little more complex by stubbing out the components. Whatever you’re able to create for the developer will save tons of time. Not just for you, but for everyone.

Here’s an example of how stylesheets can be useful: the developer may not know what classNames to use for a secondary expanded button, so after their work is done, you’ll have to go back through and do a design sweep to clean everything up. With a styleguide at their fingertips, the developer will easily be able to view each type of button, and have a visual representation of how each button should be used.

Check out this example stylesheet guide that I mocked up for you:

I like to stub out as many small components as you may need for the project. If you know an Empty State will be used, go ahead and stub it out and style it within the stylesheet. That way, when the developer is ready to pick up that Empty State ticket, he or she will have the stubbed out version available with all of the styles in place.

If you don’t know where to start, it’s always handy to create a punch list ticket for your stylesheet guide. Here’s an example of a standard styleguide punch list that I’ve used on projects:

Styleguide Punchlist

I also made this checklist just for you. Bookmark it!

Be Open to Collaboration and Pairing

One of the most important aspects of handing your completed design work off to other members of the team is to be open to collaboration and pairing. When you hand your designs off, you’ll need to explain everything in detail to the team. This way, they will be off to a good start, but there will always be instances where it’s best to pair if something isn’t clear.

Instead of getting frustrated, keep in mind that this will help the team to improve in the future. Every pairing session you have will strengthen their knowledge.

Be the Design QA (Don’t Be Afraid to Give Feedback)

Feedback and constructive criticism are so important in the process of working together on a project. YOU are the Design QA. YOU are the lead of the design direction on that project, and it’s your responsibility to keep a close eye on things throughout the entire duration of the sprint.

Developers look to their designers to get feedback, so give them all of your thoughts! Holding back or biting your tongue will only hurt the team. If you’re worried about hurting someone’s feelings, take some time to phrase your feedback correctly, and throw in some positive notes to highlight their efforts. It will help everyone and the project as a whole, and at the end of the project, you’ll have something to be proud of. Being the design QA is a massive task, but it’s also one of the most rewarding feelings I’ve experienced in the office.

---

Communication Culture Design Engineering Front-End Development Transparency UX Design