At some point, all designers have found themselves in the following scenario:
You’ve finished designing a project and just got stakeholder approval, so you hand off the design to your developer and pat yourself on the back.
But then you get a preview. And… it looks nothing like the design you had in mind.
What in the world happened?
Well, most developers aren’t designers. Some might have a good eye for design, but the majority will need clear communication and direction from the designer in order to deliver something pixel-perfect.“It always pays to be kind to your developer.”
On the flipside, because most designers aren’t developers, sometimes a design winds up being impossible for a developer to build because of technology restrictions. There’s no way for a designer to know that unless they involve their developer from the start.
I’ve spent a ton of time working with developers and figuring out how to optimize a great working relationship. It’s really up to both to make it happen.
Get familiar with server-side restrictions
Designers don’t necessarily need to know everything about development, but they should know enough to feel comfortable in the space. A great example: get familiar with the basics of how the server side of things work so you can create spatial elements that blend well with the information you have to work with. Your design will also be optimized to address all specific server-side restrictions.“A quick feedback session with your dev could result in an even better design.”
A quick conversation with your developer right at the start of a project can help clarify the entire process. Another thing that helps make everything crystal clear: create a wireframe, share it with your dev, then meet to discuss it. A quick feedback session could result in an even better design—or it could keep you from wasting time on something that isn’t possible to build.
Get to know client-side limitations and abilities
The server side and the client side of programming are completely different worlds. This disparity can certainly influence the visualization of a design. For instance, if you need to make a specific element work on Explorer 9. This can create a conflict based on what software you each use and your individual workflow.
That’s why it’s useful that if the developer uses Iconic, you as a designer need to make sure that the elements of your design can also work on Iconic. You really don’t want to have to use images for every element in this case.
A good design not only looks good and is easy to use, it’s also fast-loading and efficient. To make a web design load fast, you need to create a design that uses as much style in the code as possible. For example, I’ll always use CSS buttons for websites. They load fast and they look good on every platform.“Good designs don’t just look good—they load fast.”
Speaking of platforms, this is another issue that needs to be addressed. Your design should fit all resolutions and platforms. Consequently, it can pay off if you understand and learn each platform’s unique restrictions, resolutions, and code support.
However, platforms can vary from screen to screen. Each unique platform is built to handle your design in a different way. Therefore, each unique platform will handle your design’s functionality differently.
A case in point: if you make your information appear when the mouse hovers over an element and the platform has a touchscreen, well, there is no mouse over—you’ll need to alter the design to fit touchscreen devices.
More mobile limitations to keep in mind:
- Needing a keyboard to pop up for a form
- Adjusting click size depending on the user’s finger size
- Addressing connection problems. Your design should look good even if it loads in sections
- Keeping mobile designs and interaction simple and not too complex. This is mainly because a device’s graphic card is sometimes limited on mobile compared to desktop
- Providing the option for right-clicks. Make sure users have a way to open the right-click menu (if you have one) when needed
- Releasing information faster. Mobile users are usually doing something else while using their device.
These distractions need to be addressed by presenting the information and actions in a clear, simple, and fast manner.
Create a demo mockup and behavior documentation
After you’ve finished the design, you’ll want to create a working demo. I use InVision for this portion of the process. I think it’s a great tool to showcase my designs because it helps me show the developer exactly what I want to focus on in each section of a design. This includes how each feature will behave, where each link routes to, and much more. It takes only a few minutes to create a working demo, but it can save a lot of time not having to go back and forth with the developer.
Plus, InVision lets you write comments right on the designs so you can add explanations.
Organize files and folders
Before you send a large load of files to your developer, be sure to establish some order. You definitely don’t want to send your developer a mess of files that they’ll have to sort through and organize. Nobody has time for this.
Since you’re most familiar with your files, be nice to your developer and send them a collection of nicely arranged files.
For example, if there are a lot of files, I’ll ensure that they’re all labeled with the correct name of the page, platform, and size:
I’ll keep only the latest version of a file in its main folder, and I always arrange folders by platforms. I do this despite the fact that it’s difficult to create one main folder with all the mobile and desktop files in one place. This way you won’t make your developer have to work any harder to find the right files.
Trust me, nobody wants to work on the wrong version of a design.
These 4 simple tips can make life much easier for you and the developer you work with. You’ll be able to develop an optimized workflow while you maintain a positive working environment.
Remember, the better the relationship is between a designer and a developer, the more likely it is that you’ll create amazing products.
You might be surprised by how much useful design input a developer may be willing to share given the right circumstances.
That’s why it always pays to be kind to your developer.