10 tips to help bridge the gap between design & engineering.

In my experience, design often tends to finish second before engineering in most large scale software companies, unless there’s a strong focus on design and user experience, or you’re lucky enough to work with a design lead product. Here’s 10 tips (not in any particular order) for when working with engineers across product and agency to help you build solid relationships, and in doing so, build the confidence and ability to make sure your designs and interactions are built the way you imagine.

Some of these tips apply to working in an agile product environment, however, can easily be translated if you’re working in an agency or even freelancing.

A tight relationship between designers and engineers is crucial to workflow, put your egos aside and work together to produce the best product.
  1. Spec your designs, the more detail the better, never leave your engineer guessing.

It’s important to remember things like variable states, discreet interactions, validation styles and all the different measurement and placement variables in-between. The more detail you cover, the better your engineer will be able to bring your design to life. Using an app with a built in measurement tool like Sketch’s ‘Measure’ plugin can make speccing measurements such as distances, heights, widths, padding & margins a simple and streamline task. Create your spec with as much reference detail as possible to ensure your design is built to perfection, down to the very pixel.

It’s also important to remember that not all engineers rely on the same specs to produce a build. Mobile platform specific engineers (e.g. iOS & Android) interpret measurements differently than a front-end engineer would. In fact, some Android developers cringe at the word “Pixel” this is partly because they use ‘dp’ (density-independent pixels) instead of ‘px’. It’s important to consider how an engineer as an individual likes to work, and to establish what level of detail they need to produce the right quality of build.

How I’d typically spec a small feature of a product. I’d sit down and go through this with my dev. This is a only a snippet of a much larger spec.

2. Provide interaction specs via animation.

Say goodbye to the days of booking a time slot in an engineer’s calendar to talk through a design interaction. They’re bored, and you probably are too.

This should be an exciting time to showcase your design by bringing it to life with interactive prototyping tools like Principle, Framer, Origami, After Effects, inVision, etc. This will give your engineer a chance to visually recognise what interactions are taking place, and how you’d expect it to behave in the wild.

Animating interactions can help validate design decisions and provide your engineer with a clear spec. Made with Principle. Case study.
An animation showing the interaction that occurs when a user navigates down and interacts with the Contact Agent FAB. Made with Principle for Domain.com.au. Case study.
An animation showing the different states of Android on-boarding cards. You can try to explain everything that’s happening here, or simply show them, which would you prefer? Made with Principle.

3. A platform specific developer is likely to know more about a platform or framework than you — and that’s okay!

Accept that and learn from them. Platform specific developers (e.g. Android/iOS devs) spend all day, every day engineering mobile apps using the latest technology. Chances are, they will know certain aspects of Material Design, iOS guidelines and device capabilities better than you do — and that’s good, especially if you’re not always designing for these platforms. Listen and learn from advice they share, it will help you grow as a designer and build a better connection with the engineer.

Google’s Material Design and Apple’s iOS9. Both provide guidelines on how to best design and spec for the respective platforms (Android/iOS). Remember, these are guidelines only.

4. Be mindful of the engineer’s skill level, and try to give working examples of your vision for interactions and functionality.

Not all engineers are Senior JS Gurus, or Lead Front Ends, we all started somewhere, remember? If an engineer is having difficulty with a design feature or interaction, find an example of what you you’re looking for in the wild. There are a heap of HTML/CSS/JS collectives out there such as:

We all started somewhere, remember?

5. Be lenient with your design, for the greater good.

It’s not about being right or wrong, it’s what’s best for the product. We’ve all been there — you’ve interviewed users, researched patterns, tested prototypes and designed a component for a product and it doesn’t get the feedback you expected. This can be a blessing in disguise, which generally means two things;

a) Your team is invested and talking about the product, they’re thinking of pain points, journeys and overall product experiences, just like you are.

b) As designers, we learn from user feedback. Users can be anybody from the little old lady in the supermarket, to your front-end dev working on your component. Our job as designers is to listen, define, and solve.

If you’re convinced that what you’ve designed is the best solution at this stage, then rely on your data to come to an agreement. You know what’s tested well, and what users want, share this with your team.

Still can’t come to an agreement? Let the data decide — A/B test it!

We need to acknowledge feedback from as many different stakeholders as we can, we all share a common goal and want to provide the best experience for our users. In saying that, feedback should be given that draws from your area of expertise, trust that your creative team know what they’re doing, and have generally tried and tested many different concepts before arriving at a specific solution.

6. Design review, design review, design review! After every sprint.

Design reviews are your ticket to a pixel perfect design and should be done at the end of each sprint, or after a milestone‘s been met.

Grab a coffee with your engineer and go through the build, talking about how you can move forward with perfecting the design.

Design reviews are your ticket to a pixel perfect build.

7. Get down and dirty with JIRA, or other issue tracking software.

As a designer, keeping a ‘single source of truth’ for our design files, image assets, specs, and interactive prototypes is super important to ensure engineers are working with correct files, assets and have the most up to date specs regarding our projects.

Everyone, at all levels of investment should be included in the ticket. Ideally, you‘d see PM’s, front-end engineers, back-end engineers, and designers all involved, and actively updating a ticket to keep the project relevant and up to date. Use apps like Google Drive, DropBox, or InVision Sync to sync your latest Sketch/PS files, and assets.

8. Teach your engineer the basics of how to use design software for rapid asset management.

If your engineer uses Sketch, or Photoshop, sweet! Don’t leave them on a 30 day trial (unfortunately this happens often), grab them a licence and encourage them to explore the software. Depending on the experience of the engineer, masterclasses or studio sessions could help in teaching them the basics when it comes to exporting assets (super easy process in Sketch that little engineers have trouble doing).

If you want to speed up the speccing process further, teach them how to get values of the most common elements such as hex/rgba colours, border radius values, padding/margin, font families, sizes and colours, etc. You’ll notice how much more pixel perfect your designs are and how much time you save when your engineer can spec the design themselves.

9. Learn to code! It will make you a better designer. Period.

Every designer should know the capabilities of the device they are designing for.

For mobile designers, you should know some Swift/Java. Knowing how your design will interact with users is key to producing a successful app. Having a background in front-end development helps me to make sure what I’m designing is;

a) Functionally acceptable

b) Accessible

c) Doable within scope

There are a bunch of great online resources that will help you learn enough for a decent foundation in HTML/CSS and JavaScript, products like:

Every designer should know the capabilities of what they’re designing for.

10. Communication!

Nothing is more important than good ol’ communication between you and your engineers (and wider team). If you‘re able to openly chat with your engineers, the work you both produce will be infinitely better, and so much more enjoyable. Get your team on Slack or HipChat, create a room for your scrum team, project, or product and get chattin’ !

Remember, you both share a common goal, don’t come to each other with problems, rather solutions.

I hope you can use these tips to improve your workflow and build stronger relationships with your engineers and team. If you have any other tips or advice to share, I invite you to share your knowledge in the comments.

About Peter Finlan

Peter’s a Product Designer by day and front-end engineer by night. He loves solving complex problems by crafting user centric, emotive and engaging product experiences through research, testing and data analysis. Turned on by motion and interaction design, he enjoys simplifying complex user journeys by using delightful invisible animation.