Getting design and development team on the same page!
What makes or breaks a product team?
Strong design principles are one. A clear, effective roadmap is another. But one of the most important, yet overlooked, aspects of all great product teams, are the relationships between the designers and engineers on your team.
“Truly great products are often a combination of two things: a technical breakthrough and a never-before-seen design it enabled.”
Yet many designers compartmentalise building a product into two distinct parts — design and development. This distinction is one of the most dangerous traps a product team can fall into. When the design is seen as a satellite that orbits engineering, it usually comes crashing back to earth.
The problem is we separate design from implementation. In product design, both these things are inextricably linked. A world with terms such as “design freeze” or “handoff” just won’t cut it.
Design together
Truly great products are often a combination of two things: a technical breakthrough and a never-before-seen design it enabled. So it’s essential designers understand the possibilities and restraints of the technology they’re working with before they can properly delve into the design.
Here’s an example. Let’s say you’re designing a native mobile app. Here are some technical questions you might receive from an engineer that can heavily influence your design decisions:
- Which framework are we going to use for that home screen chart? If we don’t know the suitable one, we should ask the developer for a suggestion and follow the UI of that framework.
- How long does it take the API to fetch the data for that list-view? If it’s too long, you’re going to need to do more than place a spinner.
- The API takes a little too long to load user’s loans. What do we display in the meantime?
Questions such as the above should be asked and addressed as early as possible by discussing with engineers. Involve them in the design process, at the end of the day, it’s the developer that actually builds the website or app.
Even though you’re the designer, the developer knows best when it comes to certain other aspects of the user experience (perceived performance, page loading times, miscellaneous features that will crash the browser).
Turning design into reality
Being a great designer requires you to be empathetic, not only to users or clients but also to your engineers. Let’s not forget that all of us are working for the same goal of building a kickass product!
So here are key pointers to turn your design into pixel perfect reality:
1. (Atomic) Design System:
Design System is a list of all the elements you are using in a project. It helps you maintain consistency in the design. Want to know how we built our design system? Take look at this article:
2. Mockups:
We all have been generating & sharing UI mocks comfortably for many years now. But there are few things which will help us avoid confusion.
Artboard sizes:
Nowadays we have a wide range of devices. Not just web but our mobile platforms also has varying screen sizes! It’s important to decide how will our product look on all those screens? Define the breakpoints and keep in mind the media queries that developers are going to use. Talk with your developer if you don’t know what it is.
Breakpoints and responsive layouts:
Upload an artwork to Zeplin or Google Gallery or InVision with the responsive design (according to the breakpoints that you’ve already set), in other words, share how your design looks in different screen resolutions and devices.
You think it‘s clear that the design will be horizontally centred at higher resolutions, such as 1920 x 1080 pixels, but developers are not mind-readers.
Tools for designers:
We have developed a Sketch plugin which allows you to quickly generate guides for a selected element and helps you achieve web development’s famous grid (column) behaviour in Sketch. The plugin was featured on SketchApp website and newsletter.
File names and versioning:
The name of the screen should simply describe its function. If you’re not yet using a version control solution for your designs, you probably should.
Make sure to use consistent casing when naming your screens, whether it’s ‘camelCasing’ or ‘Sentence casing’ or ‘lower casing’ etc.
We also add 3 number to give the sequence to mockups.
3. Interactions:
Make a flow:
Putting the mockups together is only half the work done. You’d need to stitch the screens together based on the flow using Hotspots (or just make an Interactive Prototype). It helps the product manager understand how the user journey is panning out and helps the developer plan her/his approach to code.
Figure out the fidelity: Not every screen has to be fleshed out with high fidelity prototypes. Few screens could simply be static with explanatory comments, few could get away with platform-specific standard interaction patterns and few might require those custom prototypes. There’s no blanket rule for all the screens, so discuss with your developer & plan accordingly.
Suggested Tools: Overflow, Marvel, InVision, Google Gallery, Principle or craft it directly in code!
4. Specs and assets:
Today with products like Zeplin, Google Gallery, Marvel Handoff or InVision’s Inspect sharing style guides and specifications has never been easy.
Assets and resources:
Exporting assets for the different platform is easy but your developer is gonna love you if you are giving them optimised assets! Use optimisation tools like Kraken, ImageOptim, Optimage or TinyPNG.
Even better if you use SVG.
When you use SVG for your icons or illustrations, you don’t need to worry about devices with different pixel densities. Another advantage is that SVG graphics use up less space, and can be compressed effectively by gzip on the server side.
Think twice before you send an asset larger than 1MB to a developer! Don’t be lazy and send the job off to a developer; you are responsible for the visual quality of the project. Check out this image optimisation guide by Google.
Assets also include custom fonts and copy for your vernacular Apps.
Final Checklist:
- Don’t be too visionary. The ideas must work.
- Work with real data in mind and think about a “scalable design”. If there is a long text, what happens? how does it work in other languages? and if in the future will be adding more items to the menu, what happens?
- Empty states: if you don’t know what they are, find out!
- Explain the reason for your choices about the layout, colors and interactions.
- If you speak the language of developers, you can get respect. If you have a good knowledge of programming languages (HTML, CSS, Java, PHP, JavaScript, C #, Objective-C or Swift) you can be one of them and they listen to you with pleasure.
- Never forget the user.
Conclusion
Although you shouldn’t need another reason to be considerate of your fellow teammates (especially developers, who traditionally, designers find it hard to see eye-to-eye with), using these tips will help you, as a designer, just as much as they help everybody else. Cutting corners to save time only creates speed bumps further down the road, so add a little care and some foresight with your design choices.
Tap the 👏 button if you care about your developer (and/or you found this article useful).
Have any tips of your own? Let us know 🗣
