In my experience, most in-house web teams basically employ two types of people: designers and developers. Sure, some people call them different things, and there are definitely exceptions, but generally speaking, we’re split into these two camps.
For the most part, our technical responsibilities are split up as such: “designers” do the client-side things (HTML, CSS, Javascript, Flash, etc.), and “developers” do the server-side things (PHP, Python, Ruby, Java, .NET, etc.). Somewhere along the line, we decided the gap between front-end and back-end would be a good place to divide up our responsibilities. But is it?
Besides an understanding of basic interaction design principles (color, layout, topography, composition, human-computer interaction, user interface, etc.) and a killer portfolio, some of the bullet-points you’d like to find in a web designer’s skill set include an understanding of HTML and CSS and competence with several key pieces of software. This pretty much constitutes a “complete” skill set.
But more and more, web designers are expected to be proficient with Javascript and/or Actionscript programmers — the soaring popularity of AJAX and rich Internet experiences have demanded it. Often times, in-house web teams for corporations need this kind of expertise on staff, but not necessarily in a full-time capacity. So, because of our artificial front-end/back-end line in the sand, client-side programming falls in the lap of designers.
But Javascript and Actionscript are programming languages. Like real, full-on, object-oriented, programming languages. Programming involves an entirely different skill set than design. By asking web designers to be proficient with client-side programing, are we unfairly expecting them to be experts in two totally separate fields (design and programming)? I’d argue that we are.
Competence in Javascript and Actionscript is much, much more compatible with the existing skill set of a web developer than it is with that of a web designer. Programming is programming — even if he or she’s never written Javascript before, all a developer really has to learn is a new syntax. The basic concepts are all the same.
If your team isn’t going to hire dedicated Javascript/Actionscript programmers, I would suggest you consider dropping the front-end/back-end dividing line and have your developers take on this responsibility.
What do you think?
Note: Yes, I recognize there are a handful of web designers out there who are truly great at both design and programming, but they’re few and far between, and most in-house teams aren’t lucky enough to have them on staff.
Coming from a designer’s perspective, I have to agree with you on this. It was big enough learning curve to jump from print design to Web. Asking me to also learn a whole new skill set would start pushing me into the jack-of-all-trades master-of-none area.
I like the way we’ve divided work in my office. We’ve split it between markup and programming. Since JavaScript uses both, the programmer and I have to work together.
Although, designers still have to know how code works in order to design for it and not all markup languages are as easy as HTML and CSS — as I learned with XSLT. Designers still have to be able to adapt to new things.
I guess the biggest question I get from this topic is why do we expect so much from designers? Why do they typically get paid less than programmers, but are expected to program?
I agree that web designers can have a hard time writing Javascript. That’s nothing new for me however — I consider myself a web developer and I am partially responsible for HTML and CSS. When it comes to real programming though, the designer guys can’t help me anymore — I’ve got to do the Javascript stuff and the Python (nowadays)/PHP programming. I absolutely suck when it comes to designing things though…
It often makes sense to put the responsibility for the Javascript code on the developer, not the designer, especially with the not-so-new-anymore XHR stuff which is getting more and more commonplace.
My employer is currently struggling with a very similar problem, we’re in the process of growing from a 15-20 developer company to a 30-50 developer company. Up to this point, everybody has done a little of everything to pretty much mixed results. The proverbial Jack of all trades, master of none if you will. This mentality comes down from management because it used to work perfectly fine (prior to “Web 2.0”). Recently, it hasn’t been working very well at all.
In my experience, we actually have three divisions in our projects, client side (designer), middle tier (developer), and database (DBA). We’ve found that any particular employee is usually good at two of the three, and those two are almost always next to each other. So, either you’re a client-side person that loves HTML, CSS, and JavaScript who can also write back-end Java code if necessary, or you’re a Java Developer who can tune a database and write complex SQL queries. Expecting a DBA to write JavaScript is a dangerous thing, as is expecting a designer to write efficient SQL.
I’m no psych major but I’m pretty sure it’s a left-brain, right-brain thing. Now, I will give you the fact that we also have an art director who does the actual “art” in our design comps, so our designers are not the same as yours, but html, css, and javascript are nothing more than varying degrees of “programming” languages. These languages have syntax and rules, so maybe we do have it right in the fact that we have developers doing “design” work, but as proven on a fairly regular basis, not all developers have the ability to translate their skills to something an end user will actually see.
Of course, in the experience of our company it’s much harder find a designer-developer than a developer-dba, so maybe they’re just a rarer breed.
I agree that they are two totally different disciplines. I’m not sure I totally agree with sending the JS and AS over to the developer. I have experienced some developers do know javascript like the back of their hand…but its the old stuff. I recently did some JS work for a project and handed it over to the developer to integrate some old asp code(yuck) with it…and he ended up changing all the JS to what he understood…the old way. Sure this is most likely a fluke, but I may be wrong.
I guess another question should be: Would you rather be the one doing the Javascript on your nice semantic code, or handing it off to a developer who may rework your code to make it work in his/her own way?
I am by no means the perfect designer, nor am I the perfect developer, but I actively learn and do both of what you describe (front end design and javascript/actionscript). I would say I am competent in XHTML, CSS, Javascript and Actionscript. I honestly dislike flash for most things, but at my full time job, I have been the one diving into the actionscript because we currently don’t have a person hired strictly to do this. And you know what… I enjoy both disciplines. I enjoy taking a comp/wireframe, which was originally meant to be 100% flash; and turn it into 80% XHTML/CSS 20% flash. My web standards soul loves that.
I understand being a hybrid probably takes away from being strong on one end or the other, but I think its needed in-house and especially if you are a freelancer. Its also nice to be able to communicate in the designers language and also the developers language. I find things go much smoother when this is achieved. Its also nice to step away from the design end once in awhile and get deep into some javascript coding; and vice versa. I find this stimulates the mind well and stops you from getting bored with possibly doing the same thing over and over again.
(wow, that was long, did anything make sense?)
I agree. I have long hated doing development work. I can do it but I struggle. I will not back down from a challenge but in my view I shouldn’t have to have the challenge to begin with. JS frameworks make it easier, but there is still a lot of stuff that goes over my head.
@Brian - I feel your pain! Before I came along all of our javascript was the old way and everyone (both developers and designers) hated it because of that. However, once I started showing the developers the new way (in our case prototype-based OOP), they started liking it more and doing a better of dealing with it and the semantic html it was built on.
Where I work, we have a three tier system. We have designers that sit and play in Photoshop, Illustrator, and Flash all day. Then we have Client-side developers, who are responsible for the HTML, CSS, Javascript, and if need be, Actionscript. After that we have the server-side individuals that are responsible for the Java code that we’re producing.
This seems to work fairly well for us. Granted, our designers are also comptent in HTML and CSS, though not to the same degree as the client-side developers, so they can design with HTML in mind.
I guess, like Eric, we sort of hit the respective areas next to our specialty as well. Being a client-side developer, I also hit on design and on the back end code, though Java is certainly not a language I know. I’m a Django and Rails person.
We do that at work, and it works OK. The only problem, from my perspective as a developer, is that the people responsible for how an interface looks are no longer the same people who are responsible for how the interface acts. In the larger sense, it sometimes makes it harder for any one person to see the big picture. In a smaller, more practical sense, it gets kind of frustrating for us when designers delete or rename stuff that our javascript needs and frustrating for the designers when we want them to name and organize elements in a certain way. My employer has about 15 people doing web stuff, so it’s sometimes difficult to find out who did what and why, then work out whether they should change it back or whether we should update a bunch of scripts. The clean server-client separation made this stuff a bit easier, but it’s just less and less practical these days.
If you can afford to do this, it definitely makes sense to. but I think many teams are still in the boat where they don’t have the resources to do so.
Well, you definitely want the designers to design the interaction — who implements it is a totally separate matter.
When I look at job ads, I’ve noticed that about 80% (approximately) of the designer job ads always ask for some javascript/ajax skills to some capacity, whether it be mandatory or optional. I wonder how that affects the quality of their applicants?
I am a designer who knows HTML/CSS very well. When I was job hunting, I would look at these ads that are chock full of programming languages I need to know (as a designer I might add) and sometimes not apply because I didn’t feel I had the applicable skills.
I would generalize and say that most designers who know javascript in addition to HTML/CSS are probably not extremely great designers, it comes down to the jack of all trades versus the specialist.
My point is, if you truly need a designer, why would you include javascript as mandatory part of their skillset? You can find them, but chances are they’ll be less of a designer if they need to know programming languages too.
I agree, but I’d add that it’s important for the designer to have sign-off on what the developer does.
JavaScript affects the interface and usability of a site greatly, and it’s ultimately part of the design.
Maybe I’m just too obsessive, but I find myself wanting to do both front-end development and design. I love coming up with page layouts in Fireworks, but at the same time really enjoy writing JavaScript. Arguably, perhaps the fact that I don’t really use Photoshop negates me from being a “real” designer. :)
I’ve always thought writing really good JavaScript was super-hard: you’ve got the inherent complexity of a programming language, the cross-browser nightmares of CSS, and the accessibility angle of HTML.
Browser improvements and the frameworks/libraries are helping a lot with number 2 now. We’re still in the early stages of all this web stuff. As you’ve pointed out, the human issues, as ever, are the trickiest.
Like Steven Ametjan we use more divisions of priority:
1) Information Architects (Wireframes and all Interaction) 2) Designer 3) UI Engineer 4) Middletier Engineer
This lets me (ui engineer) focus on what I know best, xhtml, javascript, css, and standards. It also ensures that the other people in the chain are masters of their respective domains.
I haven’t a clue what the answer is in smaller development environments, and it’s something I struggled with (trying to do decent design work) before I found my current employer.
As well as increased demand for skilled Javascript peeps AJAX type web stuff is also leading to a higher demand in those skilled at user interface/experience/interaction type stuff and this is also often lumped in with the “designer” role.
I think Steven Ametjan’s workplace with it’s three tier system is going to be a strong future trend. There will still be designers, focusing on, you know, design, but also the UI/UX stuff. There will still be developers who know Java, PHP DB’s and similar and can do it in their sleep. Then there is going to be a new breed of web peep filling this gap in the middle. They know HTML, CSS, Javascript and by know I mean they REALLY know their stuff. They will know enough about design to take photoshop comps and wireframes and make them functional and know enough about development to deal with templating systems and similar ilk.
I get the impression that designers often come to the web from print design or some other design trade backgrounds and that developers often come from traditional computer science software engineer type backgrounds. This new role are people coming straight into the web, people that have grown up with the web and want to go straight into it.
I dunno if you agree or not but I think my hypothesis will play out. The question is what do we call these people? Client-side developer isn’t as cool as just “designer” or just “developer”.
@Chris.
I would include javascript as a mandatory skillset for the simple fact that, as a designer, you need to know what language will be doing what in your design. I’m not saying become a javascript guru, but know, at the least, how it works with your XHTML and CSS; especially since javascript can manipulate both of these. The DOM is a powerful thing, and knowing what it can do as a designer will help you design wonderful interfaces that users can use, and like… not just interfaces that users can like..but not use.
As mentioned in my first post, I have now gotten a few projects that at first were going to be 100% flash. Well, since I have been playing with the javascript DOM and learning (thanks to Jeremy Keith and Cameron Adams Books) more about how it works, we were able to not use flash in some cases; which…i’d say is a good thing as a web standards geek. I wouldnt have even thought of using javascript over flash If I did not know what it could do; knowing Javascript made me think differently during the design phase of the project.
This brings up the whole topic of taking a print designers web comp(the ones who have no clue what XHTML and CSS are) and turning that into a site. Usually a disaster; since that person doesnt know the web well. On the otherhand, I have worked with some comps like this that made our team get really creative on how to do things.. and they worked well and we learned new things along the way. If I would have just known XHTML and CSS…we wouldnt have tried to make some of these quirky designs work.
Back on topic, my point is, it usually helps the front end designer to know XHTML, CSS, basic design principles and basic javascript principles; all of these affect the interface, not just the first three.
Personally I don’t think it is the designers responsibility to code at all, I think the definition of a developer also includes html and css. Most designers I know don’t have a clue about css except what Dreamweaver inserts and they have no real inclination to start learning. I say stick to what you are good at. HTML & CSS programming done correctly can be just as tricky as basic server side programming.
This is getting a little bit tangential to the original post, but that’s okay. My feeling is that it’s not ultimately important who implements the design, but it is important that the person doing the design has a firm understand of the web, how it works, what’s possible, what’s tricky, etc.
This is no different from print, or any other form of design. If I’m a print designer, it may not be my responsibility to actually make the prints. But, in order for my design to be any good (and usable), I do need to have an understanding of that printing process. I need to know what such-and-such type of ink is going to look and feel like on such-and-such type of paper, how much more money it costs to add more colors, etc, etc. (I’m not a print designer, so this may not actually be what I need to know, but you get the point).
Take another type of design: architecture. Same thing applies. The architect usually isn’t also the one building the house, but the architect still needs to have an understanding of the materials, the tools needed, the processes, etc. that the builder will ultimately use in order for her to be a good architect.
Web designers, whether they’re actually coding the HTML/CSS/JS or not, need to have a good understanding of how these things work together. To me, that’s a given. I don’t think anyone would argue it.
But, “having a basic understanding” and being able to program in Javascript are worlds apart. I don’t think the later is necessary — or even fair — to expect of a web designer. If you find one that can do it, awesome. But it’s unrealistic to expect it.
Oh, if only it could be that simple in the Real World.
To summarize, I think I’m proposing that the Web is best built by people who have multidisciplinary chops, and that without outstanding project management, teams of specialists will always come in second best as a consequence of communication breakdowns.
If you must force people to specialize, then make sure your designers have markup on the insides of their eyeballs, stylesheet whizzes have a grasp on client-side scripting, and that programmers don’t get lost with the DOM.
In warfare, the practice of covering all downrange points with a minimum of two weapons is called mutually supporting fire and it seems only rational that with all the targets Webdevs are forced to hit, they should be organized on a similar principle if at all possible.
Sure, a lot of enterprise-scale shops utilize the approach of dividing labor to a faretheewell, and they’re hiring a lot of dead weight because of it. Do you always need a designer who’s lost when a body’s needed who can hack a maze of twisty stylesheets? Or a markup technologist who never really got the hang of that scripting thing? …Probably not, unless you’ve got management superstars who know how to keep everyone producing while simultaneously refraining from driving them crazy.
When everything’s said and done, don’t worry about how to divide folks’ labor. Instead, worry about having people at hand who have outstanding communication skills, excellent work habits, plenty of smarts, and an unassailable grasp on the fundamentals of the Web medium. Once you have those, they can do anything. Some may be more talented at software engineering and others at UX, but gunning for core talents rather than mere skills will do a lot to bring in the best product in the least amount of time.
I have had the pleasure of working in some rather diverse environments, both small teams where it’s, “hey do you know how to do this? cool do it.”, and now at AOL where there are very clear lines of division in these responsibilities. I have been there for a year now and I am now working to tear down some of those lines.
Given the complexities of the architecture our sites are built on and with multiple content feeds and databases our developers are, IMHO, burdened by too much of the responsibility of the front end code and interaction. By that I mean that when having to prioritize because of external pressures of deadlines or the like what gets sacrificed is the attention to detail in HTML, CSS, and JavaScript.
It becomes an issue where a site is hacked and pieced together and it’s unfortunate, I and my team try to take pride in the designs we do but it is hard when it leaves your hands so early in the process as mocks and though the functioning product is delivered the issues become apparent cross platforms and browsers.
I don’t intend to lay blame or disparage my co-workers it’s a complicated business and rather than cry about the sacrifices I am trying to help elevate the issue by taking on the task of front end code and CSS into my design team, where I feel it should have been to begin with, on our current project as a test case to prove it makes for a better system for production and leads to a better end result.
Javascript is another issue that we may address after we make these inroads, but my point in all this is that after having the benefit of working in these types of environments I would much prefer there be as little separation as your skill sets will allow.
I grew up designing, I taught myself to code, in this business of the internet I feel more comfortable when I am at least involved in all aspects rather than passing off a vision of an experience to come what may.
Its interesting that your experience is that web teams have been separated into designers & developers and the designers are responsible for front-end development. That seems like a lack of either a) knowledge or b) funding on the firm’s part. A successful team IMHO would be 3 distinct roles:
Designer: Skills include typography, color theory, layout and graphic design. Hands photoshop or similar graphic comps off to the:
Front-end Developer: Skills include HTML, CSS, JavaScript, etc… Hands templates off to the:
Back-end Developer: Skills are deeper languages. Responsible for designing, writing and tying in the CMS to the templates.
Of course there is room there for other people, IA, etc… but generally those three roles can make a pretty great project. I don’t know why you’d ever want a designer doing front-end work. It seems like they’d be much slower and less efficient at it than a front-end developer whose sole role is front-end development. Just in the same way you wouldn’t want your back-end developer doing the design.
If you can afford to do this, it definitely makes sense to. but I think many teams are still in the boat where they don’t have the resources to do so.
At a firm, that seems really strange in today’s world. Its not like there’s not enough work to go around … the world is teething for great design right now. Adding 3 tiers can let people focus on what they’re good at, increasing productivity and pushing out that much more work, making that much more revenue. Seems like a no brainer.
At a corp, it gets a little more complicated. If there’s enough work to go around, then of course it still makes sense because it creates more efficiency. If there’s simply just not enough work to go around and the web team “can” be handled by only 2 people … then I think the corp is making an active decision that they need to be responsible for by finding people with specialized skill sets that can handle multiple tasks. E.g., if you are such a corp and looking for your web team, then when you make the listing, require someone who is skilled & enjoys doing both front-end & design or both front-end and back-end, and then the other person picks up the third.
The server/client-side boundary is certainly artificial… presentation logic is programming. And that programming often needs to interact with server-side programming. It probably makes more sense in the head of a developer.
I agree with Jon in that graphics design and web design are two different hats as well. One involve illustration, and one involving interaction design and html/css browser support.
Maybe this the artificial divide is related to not having good source control processes (and people processes). Having a server/cllient split is perhaps easier in terms of “i won’t step on your files”.
It depends a lot on the application/website and the people involved though. Things are changing, and web applications are getting more complex. The mouse overs that DreamWeaver or Fireworks can make aren’t sufficient anymore.
I disagree that languages are just a different syntax. It’s something I’ve been thinking about lately. There is a surface level to languages… a language like Ruby appeals on that level, due to a well thought out syntax and enforced coding standards.
But there is a deeper level, which I wonder if many programmers think about? In the age of polyglot programming, coders could be running into trouble by not realizing how things like mutability or conditionals work differently in each language… and certainly not using all languages in the best way.
So we have graphics design, web design and user interaction design tied to usability and accessibility, backend programming, database administration, front-end programming, server administration… without even talking architect, management, search engine optimization, market research. There are a lot of hats, and a lot of stretched people doing several.
…And to answer Josh #1’s question:
I can think of a number of reasons why this is so:
Designers’ tool constraints are an effective leveller of their productivity. Once you’ve learned to play Photoshop (et. al.) like an organ, you’re maxed out. As a consequence a designer is compensated on the basis of the value their employers place on their skills. Copywriters have it far worse, because… didn’t you get the memo? Anybody can write, man. [/snark]
Per the point to this thread and many of its comments, design talent and programming talent of equal strength are difficult to find in a single individual. So designers might be made into programmers, but…
The productivity of programmers varies by an order of magnitude or more, and their productivity is easier to measure, regardless of the metrics used. I only expect a quarter of the software engineering results from a designer that I do from a superstar engineer, because the superstar engineer is doing 80% of the work in getting the application built. Chances are that I value the designer’s ability to communicate effectively with the engineer far more than any actual skill she’s got as a coder - putting her in a position to do exactly that is probably why I encouraged her to start programming in the first place. Unfortunately, talent for communication is even harder to measure than talent for design, which means that those folks wind up being compensated according to supply and demand.
Yes, it’s unfair.
I think it’s very unrealistic, or asking for trouble, to expect designers to actually implement their designs. I do agree with Jeff, though, in that all of the really talented designers I’ve worked with all have a good understanding of how the web works. I find it to be pretty easy to look at a design and see whether they have this understanding or not. The same is true between all layers of web development - the best at each of their fields has a decent understanding of the layer below theirs.
As far as who, in the end, will be building the front-end of the site, if you’re not going to hire a front-end developer, someone who has spent a lot of time and has a lot of experience using the technologies behind the client-side of your site (html, css, javascript, etc), then it just comes down to whoever on your team is better at it.
Asking whether the designer or the back-end developer should build the front end is simply asking which two under-qualified people should do the job - who cares?
Josh, I was careful to say “in-house design teams” in the post. I’m not talking about design agencies here, for the most part. They’re usually not the ones dealing with these problems. I’m talking about the in-house teams at Universities, newspapers, health care facilities, law firms, etc, etc, etc.
Okay, but I think you’d still agree that it’s easier for a Ruby, Python, or Java programmer to pick up Javascript than it is a designer who didn’t study programming at all in school. Right?
Who cares? Probably the people in these situations. I mean, it’s real nice and idealistic to say, “you have no one qualified, so who cares?,” but the reality is that these in-house teams still have to do the projects, even if you think their staff sucks at front-end development. They’re going to build it one way or the other, so I think it’s relevant to talk about which way is better.
Remember, perfection is the enemy of “good enough.”
Developer Developer Developer Developer
The reason: Security.
With Javascript, you can open up huge security holes, and particularly so when mixing with back-end as AJAX does. You need someone who has security training to program it. I have not met too many designers who were trained in security, particularly back-end security.
I’m a developer, who’s made the effort over the last year or 2 learning more about the design side - particularly about css, xhtml, and table-less layouts. The web 2.0 era has certainly changed things. For one, Javascript development has become significantly easier. Using frameworks like jQuery and Prototype, are now doing much of the heavy lifting. So one could make the case that it’s not that big of a deal to have the designer code some javascript. However, I’m not that guy. I think javascript should be shared by both sides. As for flash, I don’t like it so you’re on your own :)
Just so you know, developers are also facing rising expectations. It’s not enough to know php, do some simple database queries, and spit out some html. Nowadays developers need to know about frameworks, design patterns, advanced sql concepts like stored procedures and triggers, Regular expressions, OOP, shell scripting, content management systems, and depending upon the position maybe some apache configuration and linux administration.
I think if each side can learn more about the other, the overall product will be better for it. So all the developers should learn about the importance of developing valid, semantic html, and help their designer friends with their javascript. The designers need to make use of version control for their files, and continue to help out with javascript coding.
Very timely article. It’s a problem we have been experiencing for a while now.
Here we implement the earlier mentioned three tier system. We have UX designers who design concepts and design the majority of the visual and interaction design. Then we have front-end developers who are expected to have both design and development (HTML, CSS and Javascript) knowledge. Finally, we have software developers who do .NET as well as Javascript.
To answer the question who owns the Javascript, I think we would answer: we all do. The front-end developer who writes Javascript is expected to stick to user interaction related Javascript. The Javascript needs to reflect the functional requirements of the interface.
Whereas the software developer who writes Javascript tends to focus on the dynamic aspect that involves communication with server-side components — AJAX, Google Maps overlays, etc.
Part of this ‘clear’ (it’s not that clear actually) seperation is due to our workflow. The functional Javascript is usually written during the conceptual phase (agile, buzzword++), whereas the latter type of Javascript is usually done when the application is actually developed.
It’s definitely a difficult problem and I would not ever expect a designer to be capable of doing HTML, CSS and Javascript perfectly. Understanding them is a must, but execution is a different ballgame.
Interesting article & comments, both very much appreciated.
I work at a smaller shop - we have 4 developers, 1 dba, and 1 designer. But the designer doesn’t do any code; instead, a developer will code a skin, working with the designer, for either all or a large subset of our applications. However, each developer deals with everything from persistence to application-specific CSS for every application, and I kind of always figured that’s how everyone did it. The perspective is certainly interesting, although probably more fitting for larger shops.
Certainly at my place of work the JavaScript is kept in the hands of the developers, except when using jQuery - where I can step in and get things done.
You’re right, it’s a programming language, and while I’m able to read and understand most programming stuff sufficiently to know what it does, that doesn’t mean I can write it very well for any large application. Bits and bobs I can do though, and using frameworks allows me to do more, and also keeps support issues down. But it’s the developers that do the heavy lifting.
Nice post, Jeff. I agree with you. The demand for Javascript/AJAX has exploded over the last few years thanks to all the great stuff out there.
Many clients I work with end up being more concerned about animated UI’s than their content.
I think that if you’re going to have lots of repeated Javascript and AJAX features on your site(s), you should have a team member dedicated to it, and it probably shouldn’t be one of the designers.
I still enjoy (the unrealistic) ideal situation where there’s a team member for everything: designer, developer, information architect, DBA, etc. Now add in UI Developer or Javascript Ninja for yuks.
Most designers I’ve worked with do not code, or at least have apprehension. Most developers I’ve worked with do not design. Neither have ever magically turned out to be a whiz DBA.
I think it’s crucial to focus and specialize. I believe XHTML, CSS, and other possible mark-up is in a web designer’s toolkit and they should be more than familiar; but, like a good drink, they’ll be very weak if you’re spreading them too thin.
Hmm…I agree Jeff. Javascript is a programming language. Naturally, the programmer/developer should handle it.
It seems to me, though, that not a whole lot of people are really writing much Javascript these days, they’re just using the various frameworks/libraries that can everything they would need to do with JS.
Just my $.02.
Ultimately, I think it really depends on the level of scripting required. Let’s face it there is a huge difference between basic javascript functionality, and advanced practices. In an in-house gig (limited to the scope that Croft mentions in a previous comment — that is taking the giants of a Google or Yahoo out of play), I think it is fair to ask the designer to take responsibility for minor javascript implementation, especial given some flexibility on release dates, which often comes with one of the aforementioned positions (this differs greatly from agency or studio jobs, where turnaround must be quick and clean). When you are talking about larger implementations, it is important to understand something about the architecture of programs (Check out “The Pragmatic Programmer” by Hunt and Thomas to get a better understanding of what I mean). These ideas about scalability and the like are advanced even for the best of programmers. Maybe that’s the real deal with javascript: it is a programming language that has wide range of implementations from extremely basic to extremely advanced. Once again (as we are finding when we talk about web development roles), it comes down to a matter of semantics. I am thinking it’d be nice (especially in job listings) to make a distinction between: javascript(des) and javascript(dev).
Jeff - You’re absolutely right, obviously it’s an issue that teams have to deal with. I apologize for the tone of my comment; I’m going to chalk that up to stress and tiredness.
The point I was trying to make is that in a situation like this, the answer would be found in a case-by-case basis in each team.
If the designer has absolutely no programming skills, he/she is probably going to have trouble with in-depth javascript. However, if the designer has some javascript/programming experience and a solid understanding of HTML/CSS, it might make sense to point them towards jQuery or something like that.
It basically comes down to this: instead of making a general rule, decide who, on the team, has a better understanding of how to use the relevant technologies, and put them in charge of it.
I think that asking a webdesigner that is already covering layout, graphic, interaction, navigation to do significant programming is unreasonable.
Yet a good webdesigner should be able to adapt existing in-house-developed coding patterns on a particular page.
Developers should provide a fairly simple interface for designers to use. Personally I think that html attributes and a couple of JSON definition blocks in the markup should be able to do what’s needed. Perhaps you sometimes need to plug in a simple function implementation in the definition block. That should be do-able as well, provided examples exist.
In concrete terms I think a competent web designer should be able to use something like jQuery. A developer should then be writing the plugins.
Hey, no worries. We’ve all been there. :)
I do think that’s generally sound advice for most teams, but big organizations still want job titles, job descriptions, org charts, and the like. In a small team at a company who is okay with very loose organizational structure, it’s probably fine to just wing it and say, “whoever can do this shall do it.” But, that lack of structure and expectations won’t fly at a lot of places (in particular, I don’t think it would have gone over well at the Universities I used to work at).
:)
I’m surprised to find it’s not the norm for developers to handle the javascript. As you say, it’s just as much a programming language (with all the challenges that entails) as PHP or Ruby, etc. I’m the developer for my company, and I certainly handle all the scripting, whether it’s back-end or front-end (shout out for mootools). We freelance a lot of design work, and I’m friends with many of them. Probably only one or two would have any idea what to do with javascript. To me, it is the developer’s responsibility…
At Viget, all programming-oriented stuff falls on the developers. Occasionally, for a project with lightweight scripting needs, one of the more jQuery-savvy designers will tackle it, but I’d guess that 90% of our Javascript comes from the developer team.
Often, this works just fine. But sometimes interaction-level development has interface repercussions that developers aren’t always super-sensitive about, and the overall polish of the design might have a chance to suffer if not handled carefully throughout.
One strategy we’re trying to take is hiring a front-end developer, who will indeed own that layer. She would have some design chops (especially in the area of interface design), and be a member of the design team, but would be responsible not only for markup, but also for the interaction/scripting layer. She would work with developers to coordinate on AJAX-oriented calls, and would work with the visual designers to ensure that the interaction maintains the intended visual and experiential integrity.
Will this make our lives a dream? Maybe… we’ll see.
On another note, This is another example of where referring to HTML/CSS as “code” can cause extended confusion. If designers with HTML/CSS skills are thinking that they can code, when they actually are marking up content, then it seems like a smaller stretch to code in Javascript, which really is code.
I am of the opinion that planning out and implementing really well thought out CSS and markup falls under the class of “programming” and can be a daunting task for a designer who purely lives within the art for a project.
Whether “design” = “development” is a question of semantics and IMO you can’t divide those lines in any concrete way other than separating the art (photoshop) from what makes the art real (css/html/js/php/etc.).
I consider myself what is being tossed around here as a front-end developer and am part of an agency where the lines between the art and the development are clearly marked. The designers would never implement their own javascript (let alone code up the CSS/HTML)
Front end engineer is the missing piece? Three sided die:
Just my take.
Again, I recognize that having a third tier — the “front-end engineer” — solves this problem, and that’s terrific if you can afford to do it. But, in my experience (and I have some, having worked on several in-house teams before joining Blue Flavor), many teams don’t have the needs or resources to hire a front-end engineer full time, and thus split responsibilities between designers and developers.
In my experience, I’ve always found that developers can more easily learn/understand/etc javascript better than designers typically can. So, given that benchmark, it seems to make sense (to me at least) that javascript would be the responsibility of the development team.
This isn’t always the case, but on average, I imagine it’s true.
Commenting on Jeff’s tangent from earlier, I ABSOLUTELY agree that Web designers should know their medium (HTML/CSS) the same way architects or print designers know theirs. If you don’t know and understand the presentation layer… how can you effectively design for it?
Great article Jeff, and has already generated some good comments.
As a designer without any true programming experience (I do not put XHTML/CSS under the “code” umbrella, just as people who work with QuarkXPress or InDesign don’t consider knowing how to use text boxes, image boxes and stylesheets to be programming.
But designers who create user interfaces need to have a complete understanding of how it will get put together, how users will interact with what they design, etc. The technical knowledge needs to be there, even if they can’t implement it themselves.
Your print analogy is perfect in this regard - you could even argue that musical arrangers fall into a similar category: I know some excellent arrangers of vocal jazz who can’t sing to save their lives. But they understand how voices work, and how the harmonics in different ranges interact with each other to create specific sounds and set moods. I’m sure the same goes for arrangers and composers of orchestral music (I would venture to say they understand how every instrument contributes to the whole, even if they can’t play most of them).
It’s all about understanding your role, and communicating properly with those who complete the whole.
Well I guess I would just be saying the same thing, I have never worked at a place where the designer actually did HTML, CSS or Javascript. I was always the front end guy that did all that stuff and worked closely with designers to put out great solutions.
At least where I am from in Michigan, there really aren’t a lot of experienced web designers that actually code, but there are a lot of great web designers even if they can’t. Right now I am working with a web designer who has been in the field for 11 years and doesn’t know any code but had never done much print.
Although I do have a lot of contacts with people from local groups who have small business where usually the person that started it was the designer,coder and all other things. I myself can design and do so on the side but at work I sit mainly with the engineers and have now went more of the programming route.
I do think if you live in the city I do and are a designer you don’t have know how to code one bit of anything, you just need to be able to adhere to basic web design principles and work closely with the development team.
I constantly see job listings for some type of swiss army knife designer, who in addition to being a design rock star and front end prodigy is expected to also understand a variety of back end languages.
First of all, where would such a person come even from? In school you’re led down one of two paths, designer or developer, and the two rarely meet. We’re not equipped for all these skill sets.
Second who really wants a jack of all trades, master of none? Shouldn’t we hire people who do a few things really well instead of many things passably? Oh I remember, companies who are too cheap to pay for the right people for the right jobs, and would prefer to churn out crap instead.
In my own enterprise experiences, even though I don’t market myself as being knowledgeable in Javascript I end up doing it anyway rather than leaving it in the hands of sloppy developers who don’t understand unobtrusive coding practices and dump onClick events into every link.
Beth #45 writes:
I can see a number of reasons why a jack of all trades might be useful:
I suspect that anyone here would gratefully take “adequate” at a mere fraction of the price of good, as long as it’s brought in on time. Well, that’s what’s being attempted here.
Jacks of all trades are great — it’s the master of none part that hurts. I definitely know a few people that I’d call a Jack of All Trades, Master of Most (Shaun Inman and Nathan Borror come to mind), but these folks are really, really rare and it would definitely be unfair to expect everyone to be like them. If you’re lucky enough to have one of ‘em on your team, that’s awesome. But again, you can expect it.
I think it is better to have people that have a diverse knowledge of the web. It all depends on what you call a “Master”. I would rather have a software engineer who was a good programmer and studied usability and a bit of design. And of course knew enough HTML and CSS to not screw up the code when handed to them by the front end person.
How often are any of us “Masters” as we call it. Most of us aren’t the leaders in the industry although I’m sure there are these “Masters” commenting on this blog but most people are just good at what they do. They may not have a following or write books but they sure can get the job done, in a timely manner and above par standards.
I myself don’t consider myself a leader in the industry and of course you don’t either because I’m sure most of you if not all have never seen my name before. I feel thought that I can code the HTML, CSS and Javascript as good as some of these “Masters” we talk about and follow through the blogosphere. I always have studied a bit in User Experience, Interaction Design and Graphic Design. Now I’m not the greatest at those because most of my work is not creating those deliverables.
I am starting to get into programming more and more and I have taken a Java class to get better with our current platform. I don’t think I will ever be one of those programmers that will be learning a language every year or even a system architect. But I’m definitely sure that I will be able to get the job done when it comes to my current project and I will strive to do it with the up most standards and optimization. All while having great input with other parts of the team on issues of usability or design.
Sorry to go on with all that but I just wanted to show an example of this “Master of none” thing. If you have studied one thing for 5 years or so, I’m pretty sure your going to “Master” it as much as you can and if you want to add something else to your arsenal and you decide to study something else and “Master” it your not going to loose your Masterness :) of the first thing.
Giving this some more thought, and especially looking at it from the point of an in-house team where there isn’t the budget for a three-tier system, I have to agree with you Jeff, that Javascript should probably lie in the hands of the programmers, and not in the designers.
However, I do think that the designers should have at least enough knowledge of what Javascript can, and can’t do, to dictate to the programmers what functionality they want the site to feature, assuming that its even plausible.
If you’re dealing with programmers that have an OOP background, it should be much easier for them to understand the basics of Javascript than it is for a non-programmer to pick it up.
The same would also go for ActionScript, since they’re essentially the same language.
The flip-side of course is if the in-house design team is lucky enough to have a designer that also can code the pants off of some javascript. Then, it’s fair game, though if I were the manager, I would probably put it in the hands of the designer, so that he could handle the client-side, and only hand off what needed to go to the server-side in the instance of XHR calls.
When I was working at a small magazine publisher, we only had a two tier system, and I was the only one that was capable of coding Javascript from scratch. This quickly became my “area” while the other designers would work on their HTML and CSS for their respective sites, I would then come in to handle the client-side scripting, and then hand the site to the server-side to program the database calls.
Same thing happened to our one designer that also had an aptitude towards Flash. He got all the Flash work for all the sites.
One thing that I haven’t seen mention of is JavaScript usage as part of the design process, not just the final product.
In my organization we try to get “clickable prototypes” in the hands of our customers as quickly as possible. It’s one thing to say in some notes somewhere “click here and it slides down to show box A”, or to have two different versions of the page to show open and closed states. But to have the box actually slide out (date picker show up, modal dialog appear, autocomplete to drop ,etc etc) is so much more tangible to the customer to show them what is going on.
That doesn’t mean that my autocomplete needs to hook up to a live backend, but being able to get it to load something from a static file so the customer can actually interact with it can be the difference between confusion over the feature and a customer who “gets it”.
I guess I am offering a hybrid that some have hinted towards. There is JavaScript that is used to create the interaction itself that I feel is the designers responsibility. Does 300ms or 400ms to show that box “feel” right? Should that fade in or slide in? You can’t know without actually playing with it.
Then there is JavaScript to do some serious heavy lifting such as real Ajax requests, actually adding up all those columns of data instead of faking it, etc.
For those who believe 100% of the JavaScript should be pushed to the developers, how do you get these interactions “just right”? Are these decisions left to the developers, do you come back in after they are finished and tell them tweaks?
After reading the article… I feel that this is owned by the front-end developer, A person who seems to have be a liaison between Designers and Back-End. Given my position @ http://thisnext.com and my previous position, as “FE” I have been required to complete projects were I was designing and coding the markup and client logic from beginning to end. Even interviewing for Front-End positions, I have been question about my design skills and have in some cases been required to show my design portfolio as well. It may just be a trend in thinking that because so many designers are learning so much client-side scripting, that it is to be expected they would know it. I see this going both ways from Designers to Front-End Developers alike, Front-end will be asked if they can design and Designer will be asked if they can code.
After reading the article… I feel that this is owned by the front-end developer, A person who seems to have be a liaison between Designers and Back-End. Given my position @ http://thisnext.com and my previous position, as “FE” I have been required to complete projects were I was designing and coding the markup and client logic from beginning to end. Even interviewing for Front-End positions, I have been question about my design skills and have in some cases been required to show my design portfolio as well. It may just be a trend in thinking that because so many designers are learning so much client-side scripting, that it is to be expected they would know it. I see this going both ways from Designers to Front-End Developers alike, Front-end will be asked if they can design and Designer will be asked if they can code.
Traditionally our developers are responsible for maintaining a JS framework that our designers can use to accomplish graphic design and UI tasks.
More importantly though, is to make sure the line of communication is open between developers and designers and make sure they work together.
I am just about to start applying to jobs in the industry (after finishing my degree) and find this post quite interesting. I would foremost consider myself a developer/programmer, however, I feel I am also a competent designer.
I think it all boils down to whether the designer knows JavaScript, it seems it is often the case that designers will learn a client-side language over a server-side one. Espicially with the increase in easy-to-use frameworks like jQuery, which seem to be breaking down some of the barriers that previously existed between designers and programmers.
I think that asking a webdesigner that is already covering layout, graphic, interaction, navigation to do significant programming is unreasonable.
Yet a good webdesigner should be able to adapt existing in-house-developed coding patterns on a particular page.
In my company we have designs who do nothing but produce graphic designs for clients, brochures, leaflets, cards..etc then developers do all technical related godness.. :)
I agree with Jeff’s comment that the jack of all trades label is not so bad. This is exactly the strength that I’ve relied on for many years to stay employed (though I hesitate to self-apply the master of most part ;) But there is definitely a stigma attached to having a varied skill set. It’s your personal responsibility to step into the job and prove that you can contribute to the team in more than one capacity. It takes some time, but both designers and back-end developers will begin to seek out your help. From this angle I believe that it is a wise career move to add front end development skills to your design skill set.
At my work we have designers (photoshop, illustrator and such) Flash developers (AS and animation) Front-End Developers (CSS, HTML, XML and such) and Developers (.net, java etc.)
The problem we have, besides myself, none of the other designers even know the tiniest bit of CSS or HTML. Too me that’s a major issue. How can you design something that you have no idea how it can be implemented.
I see no need for designers to know anything about back-end database stuff. They should understand a little bit of it but that’s all. Designers definitely should be able to write some CSS and HTML, even if they aren’t a master of it they should understand the basics and how designs (photoshop files) get translated into mark up.
Then again we have 40+ people so we do have the luxury of having very specific roles.
Here, we have exactly the same problem, except we split it squarely in the middle at the HTML layer. With designers being responsible for Design/CSS/HTML and engineers being responsible for HTML/JS/Development. The distinction drives me batty when the time comes to implement any sort of dynamic design and you get a ping-pong game going between the two groups.
I want someone who loves web-based frontend development…from CSS through HTML, to JS. If I have a team of one, it would be a frontend developer…hiring out for original design work and backend development. If I have a team of two, then two frontend developers…hiring out for original design work and backend development. If I have a team of three, then a frontend developer, a designer, and a backend developer…and so on down the line.
The meat, the output, of our work is the CSS/HTML/JS that builds the page. To let that skillset fall on the edges of two other skillsets seems dangerous to me.
While I’m a front-end developer, I love it when designers give me clean, semantic HTML/CSS + some UI-enhancing JS, rather than Photoshop comps (or worse, Freehand files).
As a developer, I’m more than happy to then go on and flesh out the JS and tweak the markup when templatifying the design.
But there is nothing worse that a Photoshop comp that has been whipped up without any consideration for the technical implementation of the design, especially if the expectation is that the end-result will match the supplied comps pixel-for-pixel.
The designer requires a clear understanding of what is involved in the developer’s work, and vice-versa.
At uni I did a fair bit of JS but came away from it and concentrated on learning HTML and CSS which I reckon I’m pretty good at now.
I’ve fiddled with some .NET stuff and Visual Studio but for JS I just try and use whatever is in the public domain, mainly because, chances are, it has been tested quite well.
I’ve done some Flash stuff as well, but just the basics for making ads. This is mainly because I know Flash and web standards do not go together particulary well.
So yes, it is harsh to ask the designer to do the JS!
I’d say the proof is in the pudding, look around the Web, we can all see that the majority of websites are poorly designed, I think because most web projects don’t have true designers involved, they have somebody who learned HTML/CSS and then learned a bit about design, ‘just enough to be dangerous’ as the saying goes.
A designer has a very different skill set (and hopefully some formal education in their field), compared to those who are great at HTML/CSS and those who are great programmers.
Especially applicable to small to medium size teams …
Any web designer that has no programming skills, is a poor web designer. When I design a website, clients ask to do all sort of things that need to be interactive, add flavour to the content they like to see on their web pages. And flash, javascript are just these typical things that can do this sort of stuff. Also I think, you can do more a superior design since you know how to debug your code as well …
I didn’t read all the comments, but a lot of them seem to be designers saying they don’t want to give up their control of the JS/AS. JavaScript and ActionScript are full-fledged programming languages and the people in the best position to quickly write effective and performant code in them are programmers.
It is a legitimate fear that the visual and interactive designs will diverge, but programmers, in my experience, are much more used to making something to be exactly what someone else told them to make it than designers. There is a lot of creativity involved in both jobs, but the programmer’s creativity is hidden in the implementation details of her black boxes.