In this series, we’ll discuss how to navigate the elusive rabbit hole that designers often find themselves in when dealing with developers on creative projects.
Writing this series been a long time coming for me. As someone who has played on both sides of the fence–designer and developer–I have felt the frustration that many professional developers and designers feel on a daily basis. Now that I’ve decided to focus on becoming a better developer, and the fact that I have taught many courses on both user experience and web development, I feel it’s my duty to tackle some of the barriers that face both developers and designers in the workspace.
During the coming articles I will take both developers and designers down a path where I’m hoping, afterwards, they will be able to work together a lot more efficiently.
There's a powerful, tangible love-hate relationship between UI/UX designers and developers.— π (@pi_alize) October 21, 2016
The relationship between a developer and designer is so closely bound that if one party doesn’t pay attention to the other, the final product won’t have the expected outcome.
In the first part of this series, I plan to outline the problems that designers and developers face as well as how to get past these barriers. Whether it’s designing with code, or understanding what code is needed to take UX from design to an actual environment.
In the final part of this series we’ll take a look at the backend. I’m not going to teach you how to program, however, I will introduce you to the mindsets and methodologies that developers take to reproduce not only your design, but also the logic that is involved. I’ll close off here with a final thought and some useful resources to help you and your team work more closely together.
Note to Developers
This series is geared towards individuals who come from a strong design background. Any of the concepts that I explain here, however rudimentary, won’t go into detail and will suffice for a high-level understanding of computer programming.
Designing With Code, or Coding With Design
A debate that I’ve often come across on many a website concerns the design process. Should teams start with a “finished” design and then code it up bit by bit, or is it better to design simultaneously while you are developing functionality. There are pro’s and con’s with both, so let’s unpack it a little bit more.
Functionality is Inherently Part of Design
Most wouldn’t think so, but when building a blog feed or Twitter widget, design has a major role to play in how that piece of code works. Let’s take a common scenario: Whether to make a Twitter widget pull in new tweets on page refresh, or asynchronously via AJAX, without refreshing the page. AJAX is the cleaner more sophisticated way of solving the problem which ultimately would benefit from a clean UI and smooth fading effect. But a designer might be completely oblivious to this. They may have absolutely no idea that the said piece of functionality existed or could even be programmed. This is why, when designing a sophisticated website or UX, it’s fundamentally important to discuss functionality with the developer.
More Than Just Aesthetic
The web is accessed in many different ways, formats, orientations, environments and even with different senses (think screen reading or audio-assistance). As a designer, you need to be sure that a quality user experience is present and consistent across all of these variables, and that users can even tailor what’s necessary at their whim. Many designers don’t take these parameters into account so it’s difficult to actually develop a consistent experience.
Again, this is just another reason why designers and developers need to work together as one. I’d even go as far as to say that a developer should be an extension of a designer, or vice versa. This is a combined effort to produce the most viable user experience possible.
“When designers and developers work together, they can make magic happen.” – John Botica
Design Should be Translatable
When I say “design should be translatable” I don’t mean into different languages (though there are cases such as translating web experiences into right-to-left scripts that would dramatically impact your LTR design), I’m referring more to the fact that design should be clear and well-structured enough to make an easy transition from static to dynamic. This comes with experience and an understanding of how browsers render elements and form.
“We need to be able to translate our process to each other in a way that fosters creativity and structure.” – Airrick Dunfield
The world needs designers that push the limits of layout and aesthetic, and it needs developers that are brave enough to push the constraints of web engines, but both parties need to begin to work more closely together.
In the next part of this series we’ll discuss solutions to the barriers we’ve spoken about above. In the meantime, let me leave you with some relevant reading material. See you in the next article!