In Bring me problems, not solutions, Jeff Croft contrasts the roles of “web designer” and “web monkey” by making an analogy with construction work (emphasis mine):

I liken the difference between what clients often think they’re paying for and what we really do to the difference between architects and construction workers. Architects plan and design new buildings, and construction workers implement those plans. Likewise, there are two tasks in creation of a new website: the planning and design, and the implementation. In some cases, they are both done by the same person — but it seems that many clients are expecting their web designer to be far more concerned with the implementation than with the design. That is to say, they sometimes see us as web monkeys who simply carry out whatever they ask of us.

This guy didn’t want a designer. He wanted an Illustrator guru to carry out what he’d already decided upon. He didn’t want me to architect a site for him — he just wanted me to be his construction worker. That’s not to say construction work isn’t important, of course — but it’s only a small part of what I, as a web designer, do. This was an extreme case, but it illustrates (no pun intended) my point — hiring a web designer and having them act as a web monkey is not only a waste of money, but also shortchanges your site from the benefits an experienced web designer’s perspective can add.

I think this is a great point. Many times I’ve observed conversations between business-types and designers along these lines:

1. Business-type: So we decided to put a picture of a monkey throwing his poo to the left of our logo on the site. How many pixels should we leave between the poo and the logo?
2. Designer: Huh??? What, pray tell, does this monkey or his poo have to do with our website?
3. Business-type: Err, some users told us the home page isn’t friendly enough, and we thought, well, that a poo-throwing monkey would help project a friendly site personality.
4. Designer: Oh! Why didn’t you just say that? I’ve got lots of ideas on how to improve our site’s personality.
5. Designer: …work work work…
6. Business-type: Wow, that looks great! Way better than the poo thing.
7. Designer: Yay!

While I think Jeff’s analogy is pretty good, it seems to me like it’s missing the role of front-end architect — the construction equivalent might be a civil engineer. Civil engineers are the interface between architects and construction workers — another aspect might be that civil engineers are the interface between the architects and reality. Just so, front-end architects interface between designers and the realities of the web, as well as between designers and the “web monkeys.”

For instance, at some point in my career I received a set of mockups for a new section of a site from design. The mocks were quite comprehensive, covering many behavioral corner-cases, yet something struck me as a glaring omission: nowhere in the mocks or attached documentation was there anything about what the URLs should be. To me, as a front-end architect, the design and maintenance of a well-structured, thoughtful URL space is a critical part of web engineering. To design a piece of a site without thinking about what the URLs would look like—without thinking about what the resources are, and their relationships—is analogous to designing a bridge without thinking about what materials the bridge would be made of.

I suspect at this point that any web designers reading this are thinking no, to do visual design without paying attention to such things isn’t web design at all — you might call it visual design, or graphic design, but that’s not web design. Sure, different organizations draw the lines between these roles in different places, but I think the point basically stands.