Why Being Too Polite in Web Design Is a Bad Thing…

Posted on

“You’re too polite.”

These are words that were said to me the other day about my work by my frequent collaborator and brilliant designer, Dan MallWas I offended? Definitely not. I was reaffirmed. I had these thoughts about myself with the way I work as a web designer but couldn’t put it into a simple phrase. It resonated with me.

What does it mean to be “too polite” as a web designer? Here’s an example of our workflow to explain:

  1. Dan provides some art direction by spitting out the first draft homepage comp for a website redesign.
  2. I go into Pattern Lab to use what Dan has in mind for the design to style my already stubbed-out bland vanilla components.
  3. We both look at what I have created in code and iterate over the design with tweaks and changes, whether it is in the browser or a spot comp.
  4. We move onto a detail page template. Another spot comp is made, this time with some buttons and links that are styled differently than the homepage comp.
  5. I build it and style it in Pattern Lab again so it is in working code. We look at it, Dan suggests some things, and I make the changes in the browser.

This is a rough idea of how things went on a recent project.

The problem:

I just kept building stuff out the way Dan wanted me to build it out.

What is the matter with that? 

I never challenged Dan’s design exploration of changing up button and link styles. I just did it.

While Dan is a hell of a designer, it is my job as a developer to look at his designs, ask him why he changed his styles to something different, and collaborate with him to come to a good compromise on a few button and link styles to use in the site or design system. The same goes for him as a designer. After I challenge his designs, he should ask questions about why I think this is a good or a bad idea and challenge my reasoning. Compromise are key here, but both sides can have strong opinions. Don’t let your ego get the best of you, though.

You need compromise because the more styles you add, the less cohesive the site/design system gets, the larger your project size gets, and the more time and effort you need to maintain all of the variations of components as this site/design system develops further.

While we work in a very collaborative fashion (don’t go chasing waterfalls), it is necessary to ask questions and simply talk.

Dan’s role is designer in this project. He’s in charge of making this thing look good by exploring different paths early on that represent the values and brand of the site/design system we are creating.

My role is frontend developer in this project. I am in charge of building this stuff out as well as keeping the components of the site/design system organized and consolidated. 

Dan isn’t in charge of the organization and consolidation of components early in the project. I am. Sure, Dan needs to be aware of keeping variations minimal for an initial launch, but the majority of the responsibility lies on my shoulders. Because of this, I need to challenge his decisions when his art direction takes us off the path away from this consolidation and organization.

I have worked with clients who are also “too polite” as well. Their culture is built around their designers comping and then throwing it over the cubicle wall to the developer to build out. The designer says, “Do this,” and they do it. No challenge. No discussion. The developer is challenged by a designer building something a certain way that can’t be implemented or is difficult/unreasonable to implement in code. But, yet, the developer forces it into place because the design was confirmed by the executives/product owners without taking into consideration the actual product being created. Don’t be a pushover. Be constructive. Don’t be a jerk, though.

The key to fixing this is by having the designers and developers talk about the design while the work is still in progress rather than after the fact. This way the designer understands why you are questioning the 30 button styles he/she has comped up while the developer also understands why the designer styled these components the way he/she did. Better products are made this way.

The “I want this thing this way, now make it so” process needs to stop. Change it to an “I want this thing this way, but let’s talk about if it makes sense, let’s compromise, iterate, and then make it so” process. It may seem like more work initially, but that little bit of extra time will save you the mass amounts of time trying to put out fires later on.