skip to Main Content
Three Easy Ways UX Designers Can Empower The Development Process

Three Easy Ways UX Designers Can Empower the Development Process

The collaborative processes between UI/UX designers and developers often determine much of the way software development projects turn out. Designers must remember that software developers are often depending on designers for clear direction on both how an application needs to function. The quality of design work has a direct impact on the velocity and quality of development tasks – and therefor the happiness of a client or stakeholder(s).

Below are three ways designers can help empower developers:

  1. Collaborate early and often during discovery

Developers should be involved heavily during the discovery process. This seems obvious, but some designers like to work with the philosophy that designers design and developers stick to code. The Headstorm process allows for ample communication without losing efficiency that comes through too many meetings with too many people.

Some of the items I like to flesh out early in the project with a technical lead or other developers may include:

  • Choosing a library of elements vs custom element design
  • Understanding the complexity of different user roles and goals of the users
  • Estimating development time for interactive elements

Often, during a design sprint, I’ll run what I have by the development team just to hear thoughts. I find that developers often give a very different perspective that can help cut out fat from designs. It also helps to understand how certain things work under the hood and builds empathy between design and development when both sides are not afraid to listen and give feedback.

  1. Document extensively

Documentation is one of the things that no developer or designer wants to do. Design documentation is tedious and can often seem like a less valuable asset when compared to nice looking mock-ups or diagrams BUT documentation is one of the most valuable things for developers to connect the dots between high fidelity screens and functionality.

Design Documentation Image Example

Great documentation saves everyone headaches (including designers).

If you think about it, our real role as a designer is actually to provide documentation – albeit it is represented in a visual fashion. However, using words to supplement visuals can help developers immensely when it comes to understanding how exactly interactive elements function.

An easy questionnaire to determine necessary documentation:

Are there many outcomes from element(s) on the screen?

If yes – a user flow chart might be great to provide context on the users’ decision making process

Are there many input fields?

If yes – document the type of field, validation parameters, visual elements, and any other field associated information

Are there multiple users and user roles?

If yes – create separate user flows and clearly notate which screens and elements are available to specific user roles.

There are many questions you can ask yourself as a designer – but a general rule is that more documentation is better than less. This doesn’t mean to spam charts and comments everywhere. Keep things clean but also detailed enough so you can also answer questions if needed (see point 3).

  1. Be prepared for questions

One of the most frustrating things for developers is to wait for a design team to answer questions around functionality while being in the middle of a tight sprint.

It’s understandable for designers – we often are working sprints ahead in order to hand off designs ahead of the developers. After delivery of screens, a designer or design team may be far into the next set of screens or even on another project.

However, it is an amateur mistake to assume that designers will not have to provide support after hand-off of assets. There will be times when feasibility is questioned. There will be times when a quick 15-minute meeting needs to be set up to validate a user flow. There will be times when a slack message is sent asking about how a button functions. Make time for questions from your team!

My suggestion is to allocate a small amount of time post design hand-off dedicated towards design support. This is dependent on the project, but I expect anywhere from 5-10% of my time to be spent helping with design support tasks after I have “delivered” a set of design assets.


Software development can be a grueling experience if design and development teams work poorly together. UX designers often designate themselves as masters of empathy – but that title doesn’t come without responsibility to our own teams and developers. Helping facilitate the development process is our responsibility as designers…and every little bit helps when it comes to collaboration.

Back To Top