Fran Rosa

19 September 2016


Designer's Block: For Designers Who Code

En español: Bloqueo de diseñador: Para diseñadores que escriben código

It seems we have hit a brick wall so I will take design of this project from now on.

Removing someone from a project is never a fun thing to do and it is even harder when talking about design. When managing other designers you never want to take away their independence to make decisions or their pride in their own work, but being a good design manager — or art director — means knowing when to step in and change direction on a project or start over. Removing a designer from a project is always the last resort but sometimes it is necessary.

The problem in this particular project was not that the designer had taken a wrong direction — concept was clear and he had made some good first proposals — or that he lacked the talent or resources necessary to complete the project. The problem was he reached a point from which he seemed to be unable to move forward even after having clear and specific feedback and directions on what needed to be improved and how. The designer just was having some limitations he was unable to overcome.

I know because I have been there.

The project was the design for a new site with a well known structure — we have several similar sites — and started from zero allowing for a great amount of creative freedom. The project also was not technically challenging as it was comparatively smaller than the existing similar sites. It needed to stand out visually and be delightful though, because its main goal was to help build the brand of the company.

The designer is a designer and front end developer used to work on a fast paced environment. And that was part of the problem — when discussing visual hierarchy he talked about HTML reutilization or CSS performance. And that was not the point.

Designers used to work under pressure on a tight schedule know it improves their ability to respond quickly by balancing uniqueness and originality with adopting solutions already used on previous projects, and this can lead to develop a sense of pragmatism that can be hurtful when you have all the time and resources at your disposal because you are used to skip some steps in the process when you have the opportunity even if you do not have to.

This is particularly bad when the same person is responsible for design and front end for a project because current front end possibilities — and the associated design — are endless. From having different versions of a logo for a responsive identity to having subtle animations for some interactions any designer could be designing and developing front end of any project until death. So it is important to build from bottom and know which parts should be further developed.

But if you are trying to work on early stages of design of a new site, and trying to figure out how would front end be developed, and trying to reduce friction on further steps of the project by conditioning your decision making, at the same time, your options are limited to a narrow field of action. The worst part is that you may not even be aware of it.

It happened to me in the past and it happened to the designer. Talking with colleagues — both designers and front end developers, and managers of those — it seems to be a usual problem.

For me working on different team arrangements — working on projects as a designer but not front end developer or the opposite — and on projects with different and specific goals — large functional sites with focus on performance and scalability and advertising micro-sites with a short life — solved the problem. If you notice you may have these kind of limitations because you work on similar projects or in a team that always have the same arrangement, having side projects or making changes in your process can help. And if you manage designers and front end developers try to offer them some challenges out their comfort zone.

Why should you expect different results doing the same thing over and over again?