Design for your developers, not just your users
As a developer, I have worked on many feature definitions, tickets, and mockups. Working on both freelance projects and at companies, I have come across unclear requirements more times than I can count. Though it's impossible to be perfect, there are ways to improve developer productivity and establish a better foundation for how your apps are built.
It starts by designing for your developers.
Though users are typically the primary stakeholders, recognize that developers are the bridge between concept and execution. Developers are limited by similar factors; time and budget being two of the most common. However, some limitations are entirely within a designer's control.
For example, designs that are overly complex or ambitious can be a nightmare for developers. Even if the design looks eye-catching (think most Dribbble shots), it might simply be too difficult to implement or even use. Similarly, developers can perform higher quality work at a much faster rate if there doesn't need to be a constant feedback-support loop. A developer shouldn't have to constantly ask what should be displayed in some input case (think failure/success handling), or why two elements are inconsistent in design despite supposedly being the same.
Here are some basic but common examples of design states that are often forgotten:
- Null/empty values
- New values (reassigning from null)
- In progress, loading, or pending states
- Error, success, etc. Should these be messages? Other visual cues?
- Consistency in implementation, such as text size and color, padding, grid spacing
While developers should be responsible for making reasonable assumptions and maintaining autonomy, their job is to produce a fluid, functional application from what's provided. If given something difficult to work with, there's no guarantee that the actual app will be any better.
Confusion breeds chaos and makes it tough for many devs – especially those who have little interest or background in design – to accomplish their work in the expected amount of time. For an application to be well-executed, all three points need to interact and consider each other's needs: designers, developers, and users.
As a designer, you’re probably dealing with different sets of requirements, communication across different departments, and responsible for designing flows. You may be constrained by deadlines or financial limitations, and so it’s tough. But keep developers in mind, and they’ll return the favor through a beautifully executed user experience.
In exploring this idea, I found that Invision's Inside Design published an article that covered a similar idea. It's more in-depth and put together than this article, and I highly suggest you read it if this idea interests you.