Tips for Designers & Developers Working Together to Implement Great UI’s

Jess Eddy
8 min readMay 29, 2017

--

This post is based on this question I received recently:

I’m a designer and just started a new job. It’s the first time I’m working directly with developers and I’ve hit some obstacles. The development team (a small group) and the design team (two of us) are having trouble communicating with each other so that the coded version of the UI matches what we’ve designed. None of us seem to be experienced with this process, any tips?

The most challenging aspect of my career has been getting designs implemented as intended — in code.

It’s usually no one’s fault.

It’s not as simple as looking at a design and coding it; discrepancies always arise — and it’s not because of a lack of skills, it’s the nature of the work. Emotionally and professionally, it’s hard seeing great design work disintegrate at the implementation stage. Fortunately, there are ways in which we can work together to do great work!

As a freelancer, the client may not understand or appreciate (or want to pay) for you to be involved in this phase. If you work at a company, this part of the process may be undervalued or misunderstood.

It’s been my experience that designers, developers and product managers, etc.— all want the same thing; we all want to do and ship great work. When we’re not achieving that goal, it’s often a case of not knowing how to work together…not sharing common processes that support the goal.

The other aspect that makes this topic difficult is an understanding of what good implementation is and looks like. As designers, we look at UI’s through a very fine grain lens. We can see all the small — or large details that need to be addressed.

As the saying goes, the devil is in the details.

Padding, margin, color and spacing issues may seem trivial but add them all up and you have a mess of a UI. It’s entirely possible to put the designed UI next the coded UI and the designer may see all the flaws while others think it looks totally fine! This is not a pat on the back to designers nor is it meant to convey that developers are bad at their job — it’s just a statement to address the perception gap that exists.

If UI issues are not addressed, over time this creates UI legacy that becomes harder to fix the longer its ignored. It can also create an emotional impact and make people feel like the work they do doesn’t matter because it’s not being executed very well. Worst case scenario, employees leave to do better work somewhere else and or your customers are frustrated with the product you’ve spent so much time building.

Now that we’ve all had a therapy session together, let’s move on to solutions!

Define Your Design & Development Process

How you work together.

Design and development are two sides of the same coin, which is why they need to work together. Specific design and development processes may vary, but should include similar attributes.

  1. Inclusion of developers/UI implementers in initial (pre-design) brainstorming or design ideation
  2. Inclusion of developers/UI implementers in design reviews
  3. Frequent communication between designers and developers throughout the design and development process — including pairing

These things keep the team aligned. When teams make decisions together, they make better decisions that are balanced with perspectives from all sides — designers and developers. Everyone is sharing the same information, which creates a common understanding. Decreasing potential confusion, increasing team flow and efficiency.

Share a Components Library

Use the same building blocks.

There’s no silver bullet solution for making the design and development process an easy one but there are certain things that alone, solve a lot of problems. Sharing a components library is one of them.

UI’s are made up of a lot of reusable components like forms, text styles and containers. These components make up the overall templates of our application. Designers and developers should be working with the same components. At Data Republic we use Angular 2 and a theme that we purchased (our “components library”), which I apply light customizations to. I do this because out of the box components sometimes need finessing to fit in with the product and sometimes they’re just poorly designed. Once a component is customized, that’s the new version of the component — everywhere its used. We routinely talk about which components are best to use for a specific design task during the design process; this type of communication creates less waste in the overall process.

Some people use the phrases “components library” and “front-end framework” (think Twitter Bootstrap) interchangeably. Lately, I’ve been a big fan of working with the best, small components library that integrates well with the rest of the technology stack used for the project. Small because large frameworks create a lot of potential legacy up front and give you a lot of code that you don’t end up using.

Here’s a few lightweight frameworks:

Organise Your Workspace Around Teams

Work “together.”

This simple concept is meant to enhance communication and collaboration, two must haves for doing great work! If you work in a small startup, say one to two designers and three to four developers, chances are you’re all working on the same feature(s) or product. If you’re working in a larger company and your teams are much bigger, you might be working on different projects, features or products. Either way, consider organising your teams, not by department but by what you’re working on. In Agile, these are called “feature teams.”

A feature team is “is a long-lived, cross-functional, cross-component team that completes many end-to-end customer featuresone by one.”

The days of: designers sit here and developers sit here — is over and probably never should have existed to begin with!

Working in close proximity to one another creates a natural transparency that is highly beneficial and helps to create positive outcomes.

Pivotal Labs calls them “Project Pods.

Include a Step for UI Review

Pairing for Perfection

This is part of defining your design and development process. Whatever your process is, make sure you have a step for a UI Review. Typically this step is right before QA and right after or in tandem with code review. This allows the designer to do a thorough review of the coded UI before it’s tested and shipped; it’s a chance to get the UI right. This is really where the magic happens!

When I say UI Review, what I really mean in practice is — a designer pairs with a developer to make updates on the screen so the coded UI looks as intended. This is one of the highest value activities a team can do together and it doesn’t take a ton of time.

It may take me 1–2 days to design a small feature. It may take the developer or development team a week or more to build. Pairing to get the UI in tip top shape may take two to three hours but the value is too great to quantify!

Read more about Pairing in this post.

Use Zeplin to Share Files

Make the CSS transparent.

Remember the days of design documentation? The designer spends hours putting together a “UI spec,” documenting — among other things the sizing and spacing of everything. This always seemed like such an enormous waste of time considering you could just work together to achieve the same outcome. Thankfully these days we have a lot of tools at our disposal to help in the process. Zeplin is a collaboration tool for designers and developers. You can export your design files into Zeplin and developers can not only view the files but more importantly see the CSS attributes for components in the file! It’s brilliant. This should be an accessory to doing better work together, not the only solution.

Design a Sprint/Step Ahead

Create definition through design.

Even if you don’t work in Sprints, you likely work in some sort of sequence and or cadence to get work done. The design process is great because it not only sparks useful conversations but it can be used to create technical definition — i.e. the requirements! Designing a step ahead of development is another great way of reducing waste. Make sure someone is taking notes throughout the process so you’re not losing all those great ideas. ☺️

Do you have any tips or ideas for designers and developers working together to implement UI’s? Please share them in a comment! Have a question? Email me! jess@jesseddy.com

--

--

Jess Eddy

Jess, Sydney-based digital designer/mentor, uses her design & tech background to foster creativity, and drive innovation. Renowned for practical guidance.