'According to James Traub (writing for The New Republic), Gardner's theory of Multiple Intelligences has not been accepted by most cognitive scientists nor by most academics in the education field. Indeed, George Miller, one of the psychologists credited with discovering the mechanisms by which short-term memory works, wrote that Gardner's theory boiled down to “hunch and opinion.”'
I am editing a forthcoming book in the field, written by a teacher who earnestly believes in MI. Evaluating this teacher's data, his approach is clearly working for his students, but I think because of better engagement, more individual attention, and more interdisciplinary projects. Ultimately, I think we're cutting most of the MI stuff from the book as unsupported, although he will cite Gardner as inspiration.
The data I've looked at is more consistent with variation in subject performance primarily correlating with interest and personality, rather than MI.
> is more consistent with variation in subject performance primarily correlating with interest and personality
My hunch and opinion is that this is correct, too. ;) Also, it all kind of reminds me of the Pygmalion effect[1]. Other people tell us what we're good and bad at and then we run with it...
Yay - designer/developer "teams". Sounds fair enough, but it's gotta work both ways.
You as a designer need to be flexible. If I as a developer say "that can't be done within the given time/budget/constraints", you'll need to rework or rethink some of your precious design.
I as a developer need to sometimes do some more research to make sure something can, in fact, be done, instead of relying on 10 year old preconceptions about what's possible and what's not. I may need to tell a client/pm that we're going to do XYZ visually and IE5 be damned because I've looked at the stats and 0.21% of the visitors in the past 18 months used IE5.
I've rarely seen true teamwork collaboration between designer/developers in the web world, and it's worse in the 'virtual team / freelance' world, because pretty much every project is a new set of people working together for the first time.
What's more common is a designer puts together some graphic design which is fairly impossible to recreate in browsers, then complains tirelessly that it doesn't look exactly 100% the same on every single browser, including their WAP phone, iPhone and IE6 on XPsp1, and proceeds to tell you about their cousin who made all this work perfectly 6 months ago because he wrote some javascript to make everything awesome. Then the designer coming back 4 hours before a demo/launch and telling you that the color in the footer on each page needs to be different, but they're going away on vacation in 10 minutes and "it's pretty simple, just look at the 19 mockups I emailed to you in February" (conveniently named 'XPJ59 client X here's slide #1.JPEG', etc).
Also more common is a developer who takes no notice of the designer mockups that were approved by 8 people over 2 months, and just does their own thing with CSS3, custom modified jQuery, and only tests on their custom Konqueror or Chrome beta release, then pushes to Heroku where only they have an account and rights to push.
Yes, designers and developers need to learn to work well together to appreciate the issues each faces. Web designers do, in my view, need to have a better understanding of web technologies, understanding the limitations and possibilities of the tech. I don't see how you can do that without actually, you know, learning how to code some. Developers should have a better idea of how to use graphic tools, and sit in on some meetings where designers are subjected to idiotic whims and endless debates on shades of blue to have a better understanding of why the designer is bitching about what should really be a 2 minute change for the dev (cause the designer will get it in the neck from 8 people if they don't).
You're right. Every discussion about "designers should code" always shows problem in teamwork and communication, not in coding skills. :)
And even if as I was saying learning to code is a way to create these skills, like designing things is for developers, another way is just listening to the developers/designers in your team. It works very well and it's way more efficient for a lot of different people. :)
Agreed, although "just listening" doesn't go as far as "just listening while also having walked a bit in their shoes, or at least tried those shoes on for size."
Design is not about the tools you use, and development is not about the code you write.
Developers can learn design fundamentals (and I mean really basic "what's the idea behind this color/element/typographic decision?") without touching Photoshop, Illustrator, etc.
Similarly, designers can learn about what is and isn't possible, without learning to code, through research about the existing technologies and their use cases.
"designers can learn about what is and isn't possible, without learning to code"
Depends on what we mean by 'code'. I don't expect designers to understand javascript, php, java, .net or whatever.
I do expect someone who bills themselves as a web designer to understand the basic fundamentals of CSS, what works on various browsers, gradeful degradation strategies, etc. I don't really think you can do web design successfully without understanding them, and I've never met anyone who really understands them who didn't also actually code html/css from scratch, at least at some point in their career.
It's probably possible to just read about it without opening an editor, but probably far less effective.
And re: developers - getting some understanding about colors, shapes, fonts, sizing, etc, to understand why some decisions are reached will definitely give a new appreciation for good design, and can help in other projects in the future where perhaps a good designer isn't available. I've stolen quite a few tricks from some designers I've worked with, and as time goes by I get better and using those tricks together in concert to make stuff that doesn't suck too bad.
Why would they implement a feature that's in every browser anyway? They should just design the site so that changing the font size through the browser works.
Buttons to change font sizes are anywhere in a browser's default chrome, therefore 99% of people don't know you can do it.
In general, I think it's dumb, but have been on the receiving end of "add font size buttons". No amount of "but you can just hit ctrl-+" does any good.
I believe his point was that a web design should be resilient to the fact that users can do this with their browsers. Among other things web specific I assume. That seemed pretty obvious to me anyways.
Similarly, designers can learn about what is and isn't possible, without learning to code, through research about the existing technologies and their use cases.
True to some extent, but the more you know about what is and isn't possible, the closer you are to basically knowing how to program. I suppose how abstract your knowledge can be depends on what you're trying to do.
For example, I think game designers need to know a significant amount about how game engines work: maybe not the algorithms of, say, gouraud shading, but they do need to know what's possible and not possible in NPC AI, and the more complex the behavior they're designing is, the more they need to know about how NPC AI actually works, to have even a reasonable guess at how their ideas would translate into reality.
A few people have argued this under the labels "computational thinking" and "procedural literacy", a category of skills that doesn't necessarily involve knowing the syntax of C++, but does entail being able to think in terms of algorithms and technologies. There's also an older idea of "design thinking" that sees it as almost always including some technical aspect; that's common in architecture, where the ideal architect is a designer but still quite familiar with at least parts of material science.
The problem is that in a startup environment, needing to constantly explain how web application design works can waste significant time and energy, decreasing morale and impacting momentum. It's a drag, and an unnecessary one.
Web applications don't need to have heavily designed UI elements. The kind of designer that's useful for a web application is one who has a deep understanding of the unique constraints and conventions of web application design, not someone who is a whiz is Illustrator or screen printing.
"The team of the digital era is a designer / developer team"
At my last job, I kept trying to get them to hire a designer. When I left, there were like 15+ developers and no designers. A couple of them thought they had designer skills, but they didn't really. They ended up outsourcing their design, and of course, a lot of back-and-forth was needed.
I absolutely think that designers and developers need to work closely together.
I also think it's -possible- to have someone who is great at both. But you're going to pay them a lot more. Probably more than having 2 specialists. They are going to be amazing at what they do. You certainly won't get twice the work from them that you get from 2 specialists.
LoseThos is for programming as entertainnment. It was common for one person to make games on the C64. Obviously, that person was a programmer, not an atrist. The poor resolution and colors made an even playing field -- it all looked primative.
Don't worry -- all those extra pixels you're missing in LoseThos would just have made making art more tedious.
I disagree. Just to be clear, we're talking web design here in HTML/CSS, not actual programming in JavaScript or Ruby. HTML/CSS creates designs, just like pencils create sketches and paint brushes create painting. Sure, it's hard, but watercolor and oil painting is also hard and has to be learned. Web design is no different.
IMO, in a team, creating the HTML and CSS is a responsibility of the designer. The developers are too busy doing real coding. At least, that's how it works in the design agencies I know personally. It's always a designer that creates the markup, whether a lowly design intern or a production artist. Maybe enterprise and tech startups are different, but that's how it works in the design agencies.
I agree with you, what's next after this? designers that can't use photoshop because it is not part of their intelligence type? HTML/CSS is the designers medium and they have to learn how to use it just as a painter needs to learn how to use paintbrushes or a film director needs to learn how to use a camera.
Don't worry, there's nothing "after this". "Designers should code" exists only in the web design field. It's fair to suggest that "Designers that can code are better", but it's not a must in any way. That's the point. :)
Probably you never met amazing designers that can't even put a "." at the end of their sentences.
People are different, with different mind, and intelligences. Forcing such a designer to "code" is just going to destroy his skillset, that otherwise would be of great use in a good and collaborative team. :)
If someone has to be forced to learn/use the underlying medium then there's nothing to destroy, they don't have the skillset to to do the job to begin with and they should probably just stick to doing print layout.
Having worked with designers ranging in skills from pure photoshop all the way to writes app code in addition to markup, CSS and javascript, in my experience a designer that doesn't have a solid understanding of raw markup, CSS and javascript is a liability.
I worked with lots of excellent designers that aren't able to write a single line of code. And still paired in a good team with a developer, they did marvels. :)
So what you're saying is it's cool for someone to only learn half their job if you've got other warm bodies available to cover for them. Eh.
Taken to an extreme this is similar to you saying I'd make an excellent plumber if I could drive the truck and had a couple of helpers that actually knew how to do plumbing.
You can't tell me with a straight face that a designer that doesn't have a solid grasp of the underlying principles of how front end code works isn't going to (at least occasionally) end up cranking out the worst sort of pie-in-the-sky speculative horseshit that's a rugged nightmare to mimic on the web, and every time they do they end up taking a big ass bite out of the project budget when the rest of the team is scrambling around trying to sort out the cross browser issues with the hot mess of a design comp they've just been handed.
That's a nice metaphor, but no, we aren't saying that you are doing a job, and actually you don't know how do to it and you have someone else doing that for you. The plumber metaphor is flawed.
I can tell you, because it happen every day. It happens to me every day. And if you don't believe me, just read around the comments from people, here and on the article page, that do exactly that.
By the way, there are also comments of people saying that designer must think a bit over what's technically possible, to innovate. Figures. ;)
The problem however isn't in agreeing or not, but in not being so sure that your point of view is the right one.
I think something is being overlooked here. As a designer, when "learn to code" is suggested, it's not aimed at programming languages (C, Ruby, Python, etc.), but rather simple/easy to understand things like HTML/CSS. Any self respecting designer should be able to take a .psd and get it working in a browser. And although it's not necessary for a designer to understand development languages, there's nothing wrong with it (regardless of scientific theories).
I will call your bullshit and raise you a fallacy. ;) But seriously, I think that pigeon-holing yourself into one skill set is the WORST thing you can do. If nothing else, you should at least attempt to learn code so that you might be able to produce reasonable, efficient designs that the coders can easily implement.
But it goes much farther than that.
Someone (on the internet) once said "programming is the new literacy."
I am both an artist and a programer. I am not very good at either, but I find having a knowledge of both is extremely empowering. I DO NOT believe that you are born an artist or programmer. Sure, you might be born with a slightly better brain than the next person, but anyone with an IQ above 70 can learn to program and/or draw. Learning both is not time wasted, but time invested. Being a good programmer can actually save you time as a designer.
I know, it's wonderful when you can do both, but I think it shouldn't be forced on everyone. Not everyone is a specialist, and not everyone is a generalist. Forcing one, or the other, is harmful. :)
Wow, what a way to say I'm not good at either but it doesn't really matter in the end. Really? So you say you're not good at either but having knowledge empowers you? In what way? It gives you the ability to point out people better at those skills than you? I think you should focus on one until you feel you are good at it and then move on to the other.
Yes, anyone with an IQ above 70 can learn just about anything. Doesn't mean they will be good enough at it for a career. You make sound as if those abilities are not challenging or difficult in any way and anybody can do it. If that's what you are saying then I have to seriously disagree.
Good point about being a good programmer can save you time as a designer, but it can work the other way as well.
I only said am not very good at either - but competent enough at both to do them professionally, I think (and I have). Only trying to be humble ;) Anyways - Like the comment below, I don't believe anyone should be "forced" to do something, but at the same time no one should be closed-minded about learning new things.
The one thing I have learned from working in both areas is that in the beginning you improve very rapidly, but at some point only hard work drives you closer to perfection. I would advise anyone with an open mind to at least try learning something they are not good at. Not a requirement by any means, but I do not think anyone would regret trying.
I got about a quarter way through the article and gave up reading. The reasoning cited is pretty poor. I was someone that used to think i could never code because my brain wasnt wired that way, but yet here i am, coding. Its given better insight into what issues and constraints programmers face.
This whole pigeon-holing exercise is just a complete farce. Far better to know a little about everything than everything about a little.
Its really not as a big a deal as people are making out.
The author is just pigeon-holing the abilities of people. I was/am pretty good at math AND art. Not everyone is a specialist that fits neatly into perfectly shaped holes.
Designers who design for the web should know HTML, CSS, and Javascript pretty well. The best ones know them throughout. Design isn't art -- it's a technical profession and one that requires the designer to know their medium. If you do not then I would say you're taking the piss right out of it.
Being the person who has to "code" a designers' work is a career built on frustration. The web wasn't built in photoshop. It was built by nerds and engineers. It has come a long way to allow people to make their HTML documents more expressive (to the point that they've become full application UI's...). But that doesn't escape the fact that this is a technical medium with specific technologies that drive those expressions.
You have to know this stuff if you want to be good, IMO.
Pigeon-holing? Quite the opposite. I'm making the difference between "should" and "could". That's exactly because not everyone is a specialist, neither I am, but at the same time not everyone is a generalist! :)
Exactly like I'm saying in the middle of the article, "you have to know this stuff", but you don't have to know also how this stuff is done, you can, of course. But it's not a must. :)
It's always sad for me to hear people with bad experiences with designers or developers, but really, I don't think that "code" is the answer. I believe that "teamwork" is the answer. Knowing. Discussing. Collaborating. I've never seen a team doing that failing, regardless of the mix of skills :)
It's the "Theory of Multiple Intelligences" bit that gave me the impression of pigeon-holing. And the paragraph preceding it where you go on about the typical high-school stereotypes. And the rest of the article is built on the premise of a dichotomy where creativity is separate from technical ability... the whole "left brain/right brain" idea.
It's bunk!
I think the split is actually in designer/front-end developer.
If you want to make analogies to other industries, I think your concept of designer is more analogous to a "concept artist". The person who has the good ideas that are not restrained by the burden of having to think about how to build them.
However when I hear, "web designer" -- I'm thinking of someone who can create or take a concept and actually build it. Someone who uses the tools available (HTML, CSS, Javascript, et al) to create something. This person does have to know how to build their ideas from the tools available.
And I think for most projects the designer is also the concept artist. Very few (if any) web projects actually need those roles filled by two separate specialists.
So I don't think it's bullshit. Designers should know how to code. And they should be good at it too.
Again, I agree. The whole article isn't built on that dichotomy. It's just a sequence from a simple perspective to a more complex perspective, and actually ends saying that it's better if you are willing to expand your view, exactly like you are saying. :)
~
On the second part of your comment, well, you are talking about "web designer" specifically, and with a very specific definition of it as well. If that's your definition, then yes, he have to do that. But er, it looks more like a Frontend Developer to me, and I never heard of a "Concept Artist". ;)
However, it's a matter of terminology here, and there's surely some confusion about it. :)
Amen. As far as I'm concerned, a "web designer" who refuses to learn CSS is like a "painter" who won't learn about working with paint, or a "musician" who can't carry a tune or play an instrument.
The problem here is 'designers' is an ambiguous term and 'code' is a loose term. If the sentence is "Web designers should know at least HTML/CSS." as it should be, then the debate would proceed properly instead of everybody missing each other's point. Framing this whole argument into "designers should code" is not doing any side any favor.
Thank you. I agree that whenever someone writes such a post saying that web designers should or should not "code" then they should define what coding means in that context.
Creating HTML markup and CSS is debatable of whether to call it coding or not. But every web designer I've ever interviewed I expected them to write their own HTML markup and at least be of average skill with CSS. Ability with Javascript was a bonus but not required.
I have a design degree and I learned HTML in class as part of my minor. This was before CSS was common so it was all font tags and tables. They used FrontPage for this but I refused and stuck with Notepad in back of the class.
I, as a web designer, create my design, write the HTML markup, write the CSS and code the javascript. In some cases I tweak the back-end code to suit my needs if it's light. Heavy-lifting on the back-end is done by a programmer.
Truthfully, I'm probably more of a front-end developer these days though.
I am not a print designer therefore I would have a bit of a learning curve to re-acquaint myself with the medium which I learn in school. But it would be expected of me to learn it. Therefore, I don't feel it is wrong to expect a web designer to learn their medium as well.
But hey, everybody should pick what works for them. Some companies don't want designers involved in markup, that's fine. Some companies do, that's just as good.
As a programmer I could care less if a designer can code. What I'd love though is if design courses spent a very small amount of time teaching basic source control, organization, and naming conventions. I know some designers would consider this boring, but I swear it would really simplify the process and we coders would be much more accepting of last minute changes (after all, we make last minute changes sometimes too).
I think the misconception presented here is that designers shouldn't necessarily be handing massive, unsliced photoshop files to pure coders. There's a a few skills in the middle of that process; slicing, optimizing, organizing, and css. Often enough neither designer nor coder is proficient in this area. Handing off your mockups to third party slicers isn't always the best idea either (you can end up with some pretty strange CSS, and dealing with UI changes down the road can be painful). You might be better off with someone dedicated to this role.
It is really arguing the extremes, when reality, the best place to be is somewhere in between.
Designers and developers should of course have good understanding and empathy for what the other person does. But at the same time, they shouldn't have such a complete understanding that it negatively impacts their primary role.
For example, if you're a designer, you don't want to fall into the trap of only incorporating things into your design that you already know how to code. You might leave a lot of innovative stuff out that would make the product better. If you're a developer, you don't always want to be bound by the existing design constraints either. It's a back and forth discussion between the two halves.
A great deal of people do refer to HTML markup as coding. It's debatable if it should be called that but in many cases when someone says "coding" the context is HTML and CSS.
Exactly! HTML is way different from a programming language. HTML is a language that describes structure, not logic. The web is all about structuring information in a way people can make sense out of it. Any web designer that is not able to use a language to provide structure, is not at the to of their profession.
Depends on how you look at it. Writing HTML is more like using Word in a formatting mode where you can see the code that's normally behind the scenes. The method you are referring to is similar to using a WYSIWYG editor. Plus it depends on how you define what "code" means.
Coming at this as a designer who learned to code in both senses of the word, I have to disagree with the sentiment that HTML/CSS is easy.
Sure, the principle is rather straightforward, but writing CSS is tedious and error-prone and the HTML/CSS is combination is modeled on single column text based layouts… it’s shocking to find out there’s no built in support for columns and no way to vertically align an element, for example.
I spent a month doing CSS until I had learned to implement the kind of grid I could knock together in 5 minutes in InDesign… very unsatisfying… Whereas later I spent a month learning Python and felt like I made much more progress, deepening my understanding of the digital medium, improving my “procedural literacy” and shaping my views about possible interactions.
So programming logic is actually more easy and fun for me—though that doesn’t take away from the fact that you need CSS knowledge to make a design work…
The actual problem is that many designers just don't understand how things work in general. They just "do some pictures"... Then ofc they get this "learn to code" line.
But I can say the same about programmers when it comes to design.
This is something that needs effort from both sides if you care about final result
Some of the best designers I've had the pleasure of working with didn't know how to write HTML or CSS. The did, however, deeply understand the constraints of web design. Knowing HTML and CSS gives you a de facto understanding of the constraints, but you don't actually have to write it in order to become a competent web designer.
I also think most people are thinking from the perspective of the scrappy start-up, where you must be multi-talented in order to cover various roles. In large organizations there's designers that only produce wireframes, then another designer comes along and produces the final visual output, and finally another guy comes and codes it. Not that it's the right way to do it, it's just that the expectations are being set too high.
Instead of putting down web designers who can't code, appreciate web designers who do it. This comes from a web designer who can code.
I think this post is at least partially misunderstanding the assertion that designers should be able to code. The point is not that they should be a coder, just that they should, like you said, "deeply understand the constraints of [their field]."
Someone who comes up with a good design that can't or won't be implemented may as well have not designed it in the first place- but if they understand the constraints on their design they can come up with something optimal that can actually exist.
Methinks we are ignoring the elephant in the room. Sure, good teamwork will solve a lot of problems, regardless whether the designer can code or not. A team with all the skills combined can deal with both.
But there are people that have a vested interest in playing designers and developers against each other.
I've seen this happen time and time again, both via internal management and external clients: feeding designers and developers separately different bits of information (but never the whole picture), letting them make commitments based on that information and only then bringing the two together. The end result is that in order to make good on their separate commitments, designers and developers are left with very little room to compromise, which undermines the cooperation. The goal of this little divide-and-conquer game is to pressure them to come up with a result they otherwise would not have committed to given the time and budget constraints.
There's a reason why designers and developers are often very deliberately hired or managed separately for the same project. There are plenty of people who believe having designers and developers work together too closely is not in their interests.
People working on teams where each occupies some vertical niche -- designer, developer, etc. -- should have a solid understanding of the territory their own niche abuts.
I don't think visual web designers should necessarily be able to fully and efficiently implement their designs, but they should have a general understanding of how their designs will be implemented. IMO part of a web designer's educational experience should include interactive design (not just art and print design), HTML and even a programming class.
Likewise, front end engineers should have some exposure to art, design, maybe even have taken some drawing classes, and definitely be able to operate Photoshop and Illustrator (or whatever the predominant tool is).
You don't hire an architect who doesn't already know something about contracting, materials, and geology, even if they're not going to be driving the bulldozer. Same goes for web design.
Design and art have always required technical knowledge of tools and the medium, and knowing HTML and CSS is no different.
Web application design (which is distinct from brochure web design or print design) has unique conventions and constraints, and web application designers absolutely must have a deep understanding of both. There are header nav bars. The branding with the link to the root path is in the upper left, user info/settings are in the upper right. HTML and CSS are structured as boxes within boxes. Main content areas contain the primary content, sidebars contain secondary content. Components are modular. Browsers have significant variation in how they render things, and viewport sizes vary dramatically. We have views and forms, GETs and POSTs. Resources are nested, with one URL per resource. Browsers have different levels of CSS support, leading to a focus on progressive enhancement and graceful degradation.
Every single time I've ever worked on a web application with a designer who didn't know HTML/CSS or a web designer who only does brochure sites, they stumble on these issues, and we end up with inflexible designs that have usability issues and are a pain or impossible to implement. Designers who don't know HTML/CSS create drag in a startup environment. It forces others to spend time and energy explaining how the web works and what the conventions are.
He buries the lead at the end. It's good for designers to know how to code but they shouldn't spend so much time coding that they can't grow their design skills.
Yes some people are more creative, but who said being a good programmer had nothing to do with creativity? Along the same lines design is not art. I've seen many talented artists who were average designers because they couldn't, or wouldn't, blend in some structure to their work.
I started out as a book designer, then web hit and I became web designer. Although I admit the early days of table based layout made me want to run back to QuarkExpress. Flash arrived on the scene and sites like the Remedy Project inspired me to learn to code. Long story short, I now know OOP inside out and, thanks to hacker news, have dived into in functional programming.
I spend very little time designing anymore. I'm still miles ahead of my fellow developers, and I tend to be more creative in my problem solving. That said I still run to them (or stackoverflow) when a hardcore programming problem pops up.
Becoming an expert at anything takes time, if you're a Jack of all Trades one of those trades will suffer. I've chosen programming because I like building things, plus the pay's not bad. I'm still 'designing' it just happens to be with code.
Look at someone like Garry Tan of Posterous, he can design and code, and for that he is significantly more desirable than a large portion of designers. I would not call it bullshit.
The point is that we should stop to say that designers who can't code aren't valuable.
Of course, and it's exactly the last part of the article, if you can code it's better. ;)
The dichotomy of 'design vs code' feels artificial to me.
The activities of designing and of coding overlap extensively. Both require a clarity of communication, a deep consideration of the purpose of the thing to be designed/built, and a sense of taste.
If in the habit of extracting general principles from concrete examples, coders can become better coders by learning aspects of design and vice versa.
Many of the concepts in a 'coder' book like 'How to design programs,' for example, are readily applicable to UX design, e.g: refactoring, wishful thinking, generalisation of purpose, and the control of complexity by use of 'black boxes.'
Likewise, a 'designer' book like 'The design of everyday things' is full of stuff that applies usefully to the activity of coding, e.g: the importance of meaningful feedback, and of ensuring a clear mapping between expected actions and their outcomes.
These correlations aren't everywhere to be found, though. But I've always found interdisciplinary people to have the freshest approaches.
This argument is made by those that are completely satisfied with their design. A little engineering knowledge on their part could never make the design even better. no, never!
This might work for web design. In my experience, it doesn't work well for UI design.
The first law of UI design is that you will fuck up most of the time. Most of your ideas are going to be bad bad bad. If you think that every mock comes out of your workstation smelling like roses, then you're either deluding yourself or you're just knocking out something incredibly derivative. To be a good UI designer you have to say no all the time, and to all of your ideas.
So here's the problem. Static image mocks only paint about 60% of the picture when you're talking about modern (especially touch-based) interfaces. Static mocks don't give you enough information to accurately cull your ideas. Sometimes you need to build the damn thing, so you can touch it and move it and realize well damn, that wasn't such a great idea after all (or oh, this part really needs to be changed or the final, magical yeah, that's not too bad).
All of the best and most innovative UI designers that I've met have been able to build interactive mocks of their designs. Now - don't ask how they did it. It's spaghetti code that will curl your hair, frequently written using some arcane technology that might not even be supported anymore. But it works just well enough that they can use it to iterate on their ideas.
Now, you can split this job into two people. One a "designer" and one an "interactive mock engineer". In theory, it could work, but in practice I've found that it becomes hard for the designer to detect the flaws in the design. I'm not sure why. But the final product doesn't change as much. It doesn't evolve as much. It's rarely as good as it should be.
The following quote didn't really fit with my post, but I like it too much not to share it. Take heart! Your limitations are not as strong as might believe.
A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.
It's a wonderful quote, because it also says that before coding you might want to learn cognitive psychology, social psychology, gestalt theory, marketing, copywriting, information architecture, usability, economy, statistics, science of materials, architecture and so on and on. :)
There's not just "design" and "code" out there, the design field is way more deep than that, so that quote might translate well to a designer that can't code, but studied in depth social psychology, urban architecture and team cooperation techniques. :)
103 comments
[ 4.1 ms ] story [ 528 ms ] threadhttp://latestlearningcurve.blogspot.com/2010/01/learning-sty...
The data I've looked at is more consistent with variation in subject performance primarily correlating with interest and personality, rather than MI.
My hunch and opinion is that this is correct, too. ;) Also, it all kind of reminds me of the Pygmalion effect[1]. Other people tell us what we're good and bad at and then we run with it...
[1] http://en.wikipedia.org/wiki/Pygmalion_effect
You as a designer need to be flexible. If I as a developer say "that can't be done within the given time/budget/constraints", you'll need to rework or rethink some of your precious design.
I as a developer need to sometimes do some more research to make sure something can, in fact, be done, instead of relying on 10 year old preconceptions about what's possible and what's not. I may need to tell a client/pm that we're going to do XYZ visually and IE5 be damned because I've looked at the stats and 0.21% of the visitors in the past 18 months used IE5.
I've rarely seen true teamwork collaboration between designer/developers in the web world, and it's worse in the 'virtual team / freelance' world, because pretty much every project is a new set of people working together for the first time.
What's more common is a designer puts together some graphic design which is fairly impossible to recreate in browsers, then complains tirelessly that it doesn't look exactly 100% the same on every single browser, including their WAP phone, iPhone and IE6 on XPsp1, and proceeds to tell you about their cousin who made all this work perfectly 6 months ago because he wrote some javascript to make everything awesome. Then the designer coming back 4 hours before a demo/launch and telling you that the color in the footer on each page needs to be different, but they're going away on vacation in 10 minutes and "it's pretty simple, just look at the 19 mockups I emailed to you in February" (conveniently named 'XPJ59 client X here's slide #1.JPEG', etc).
Also more common is a developer who takes no notice of the designer mockups that were approved by 8 people over 2 months, and just does their own thing with CSS3, custom modified jQuery, and only tests on their custom Konqueror or Chrome beta release, then pushes to Heroku where only they have an account and rights to push.
Yes, designers and developers need to learn to work well together to appreciate the issues each faces. Web designers do, in my view, need to have a better understanding of web technologies, understanding the limitations and possibilities of the tech. I don't see how you can do that without actually, you know, learning how to code some. Developers should have a better idea of how to use graphic tools, and sit in on some meetings where designers are subjected to idiotic whims and endless debates on shades of blue to have a better understanding of why the designer is bitching about what should really be a 2 minute change for the dev (cause the designer will get it in the neck from 8 people if they don't).
And even if as I was saying learning to code is a way to create these skills, like designing things is for developers, another way is just listening to the developers/designers in your team. It works very well and it's way more efficient for a lot of different people. :)
Teamwork, and trust.
I saw a presentation by a designer/developer team a couple years back - one blog entry on that is here: http://www.viget.com/inspire/stop-driving-your-developers-cr...
Another here: http://www.viget.com/extend/stop-pissing-off-your-designers/
And slides here http://www.slideshare.net/mindywagner/10-things-designers-do...
Developers can learn design fundamentals (and I mean really basic "what's the idea behind this color/element/typographic decision?") without touching Photoshop, Illustrator, etc.
Similarly, designers can learn about what is and isn't possible, without learning to code, through research about the existing technologies and their use cases.
Depends on what we mean by 'code'. I don't expect designers to understand javascript, php, java, .net or whatever.
I do expect someone who bills themselves as a web designer to understand the basic fundamentals of CSS, what works on various browsers, gradeful degradation strategies, etc. I don't really think you can do web design successfully without understanding them, and I've never met anyone who really understands them who didn't also actually code html/css from scratch, at least at some point in their career.
It's probably possible to just read about it without opening an editor, but probably far less effective.
And re: developers - getting some understanding about colors, shapes, fonts, sizing, etc, to understand why some decisions are reached will definitely give a new appreciation for good design, and can help in other projects in the future where perhaps a good designer isn't available. I've stolen quite a few tricks from some designers I've worked with, and as time goes by I get better and using those tricks together in concert to make stuff that doesn't suck too bad.
Death to adding those stupid "font size icons" to change to one of 2-3 predetermined sizes too!
How many sites can you really change the font size? Unless of course you mean through the browser.
Buttons to change font sizes are anywhere in a browser's default chrome, therefore 99% of people don't know you can do it.
In general, I think it's dumb, but have been on the receiving end of "add font size buttons". No amount of "but you can just hit ctrl-+" does any good.
What's the percentage of users who manually change their font size? Is it the majority? Because if it's not, then I'd hardly call it "useless."
True to some extent, but the more you know about what is and isn't possible, the closer you are to basically knowing how to program. I suppose how abstract your knowledge can be depends on what you're trying to do.
For example, I think game designers need to know a significant amount about how game engines work: maybe not the algorithms of, say, gouraud shading, but they do need to know what's possible and not possible in NPC AI, and the more complex the behavior they're designing is, the more they need to know about how NPC AI actually works, to have even a reasonable guess at how their ideas would translate into reality.
A few people have argued this under the labels "computational thinking" and "procedural literacy", a category of skills that doesn't necessarily involve knowing the syntax of C++, but does entail being able to think in terms of algorithms and technologies. There's also an older idea of "design thinking" that sees it as almost always including some technical aspect; that's common in architecture, where the ideal architect is a designer but still quite familiar with at least parts of material science.
Web applications don't need to have heavily designed UI elements. The kind of designer that's useful for a web application is one who has a deep understanding of the unique constraints and conventions of web application design, not someone who is a whiz is Illustrator or screen printing.
At my last job, I kept trying to get them to hire a designer. When I left, there were like 15+ developers and no designers. A couple of them thought they had designer skills, but they didn't really. They ended up outsourcing their design, and of course, a lot of back-and-forth was needed.
I absolutely think that designers and developers need to work closely together.
I also think it's -possible- to have someone who is great at both. But you're going to pay them a lot more. Probably more than having 2 specialists. They are going to be amazing at what they do. You certainly won't get twice the work from them that you get from 2 specialists.
Don't worry -- all those extra pixels you're missing in LoseThos would just have made making art more tedious.
IMO, in a team, creating the HTML and CSS is a responsibility of the designer. The developers are too busy doing real coding. At least, that's how it works in the design agencies I know personally. It's always a designer that creates the markup, whether a lowly design intern or a production artist. Maybe enterprise and tech startups are different, but that's how it works in the design agencies.
People are different, with different mind, and intelligences. Forcing such a designer to "code" is just going to destroy his skillset, that otherwise would be of great use in a good and collaborative team. :)
Having worked with designers ranging in skills from pure photoshop all the way to writes app code in addition to markup, CSS and javascript, in my experience a designer that doesn't have a solid understanding of raw markup, CSS and javascript is a liability.
Taken to an extreme this is similar to you saying I'd make an excellent plumber if I could drive the truck and had a couple of helpers that actually knew how to do plumbing.
You can't tell me with a straight face that a designer that doesn't have a solid grasp of the underlying principles of how front end code works isn't going to (at least occasionally) end up cranking out the worst sort of pie-in-the-sky speculative horseshit that's a rugged nightmare to mimic on the web, and every time they do they end up taking a big ass bite out of the project budget when the rest of the team is scrambling around trying to sort out the cross browser issues with the hot mess of a design comp they've just been handed.
I'll pass, thanks.
I can tell you, because it happen every day. It happens to me every day. And if you don't believe me, just read around the comments from people, here and on the article page, that do exactly that.
By the way, there are also comments of people saying that designer must think a bit over what's technically possible, to innovate. Figures. ;)
The problem however isn't in agreeing or not, but in not being so sure that your point of view is the right one.
And I'm talking with a straight face, yes. :)
But it goes much farther than that.
Someone (on the internet) once said "programming is the new literacy."
I am both an artist and a programer. I am not very good at either, but I find having a knowledge of both is extremely empowering. I DO NOT believe that you are born an artist or programmer. Sure, you might be born with a slightly better brain than the next person, but anyone with an IQ above 70 can learn to program and/or draw. Learning both is not time wasted, but time invested. Being a good programmer can actually save you time as a designer.
Yes, anyone with an IQ above 70 can learn just about anything. Doesn't mean they will be good enough at it for a career. You make sound as if those abilities are not challenging or difficult in any way and anybody can do it. If that's what you are saying then I have to seriously disagree.
Good point about being a good programmer can save you time as a designer, but it can work the other way as well.
The one thing I have learned from working in both areas is that in the beginning you improve very rapidly, but at some point only hard work drives you closer to perfection. I would advise anyone with an open mind to at least try learning something they are not good at. Not a requirement by any means, but I do not think anyone would regret trying.
This whole pigeon-holing exercise is just a complete farce. Far better to know a little about everything than everything about a little.
Its really not as a big a deal as people are making out.
Designers who design for the web should know HTML, CSS, and Javascript pretty well. The best ones know them throughout. Design isn't art -- it's a technical profession and one that requires the designer to know their medium. If you do not then I would say you're taking the piss right out of it.
Being the person who has to "code" a designers' work is a career built on frustration. The web wasn't built in photoshop. It was built by nerds and engineers. It has come a long way to allow people to make their HTML documents more expressive (to the point that they've become full application UI's...). But that doesn't escape the fact that this is a technical medium with specific technologies that drive those expressions.
You have to know this stuff if you want to be good, IMO.
Exactly like I'm saying in the middle of the article, "you have to know this stuff", but you don't have to know also how this stuff is done, you can, of course. But it's not a must. :)
It's always sad for me to hear people with bad experiences with designers or developers, but really, I don't think that "code" is the answer. I believe that "teamwork" is the answer. Knowing. Discussing. Collaborating. I've never seen a team doing that failing, regardless of the mix of skills :)
It's bunk!
I think the split is actually in designer/front-end developer.
If you want to make analogies to other industries, I think your concept of designer is more analogous to a "concept artist". The person who has the good ideas that are not restrained by the burden of having to think about how to build them.
However when I hear, "web designer" -- I'm thinking of someone who can create or take a concept and actually build it. Someone who uses the tools available (HTML, CSS, Javascript, et al) to create something. This person does have to know how to build their ideas from the tools available.
And I think for most projects the designer is also the concept artist. Very few (if any) web projects actually need those roles filled by two separate specialists.
So I don't think it's bullshit. Designers should know how to code. And they should be good at it too.
~
On the second part of your comment, well, you are talking about "web designer" specifically, and with a very specific definition of it as well. If that's your definition, then yes, he have to do that. But er, it looks more like a Frontend Developer to me, and I never heard of a "Concept Artist". ;) However, it's a matter of terminology here, and there's surely some confusion about it. :)
Creating HTML markup and CSS is debatable of whether to call it coding or not. But every web designer I've ever interviewed I expected them to write their own HTML markup and at least be of average skill with CSS. Ability with Javascript was a bonus but not required.
I have a design degree and I learned HTML in class as part of my minor. This was before CSS was common so it was all font tags and tables. They used FrontPage for this but I refused and stuck with Notepad in back of the class.
I, as a web designer, create my design, write the HTML markup, write the CSS and code the javascript. In some cases I tweak the back-end code to suit my needs if it's light. Heavy-lifting on the back-end is done by a programmer.
Truthfully, I'm probably more of a front-end developer these days though.
I am not a print designer therefore I would have a bit of a learning curve to re-acquaint myself with the medium which I learn in school. But it would be expected of me to learn it. Therefore, I don't feel it is wrong to expect a web designer to learn their medium as well.
But hey, everybody should pick what works for them. Some companies don't want designers involved in markup, that's fine. Some companies do, that's just as good.
I think the misconception presented here is that designers shouldn't necessarily be handing massive, unsliced photoshop files to pure coders. There's a a few skills in the middle of that process; slicing, optimizing, organizing, and css. Often enough neither designer nor coder is proficient in this area. Handing off your mockups to third party slicers isn't always the best idea either (you can end up with some pretty strange CSS, and dealing with UI changes down the road can be painful). You might be better off with someone dedicated to this role.
Designers and developers should of course have good understanding and empathy for what the other person does. But at the same time, they shouldn't have such a complete understanding that it negatively impacts their primary role.
For example, if you're a designer, you don't want to fall into the trap of only incorporating things into your design that you already know how to code. You might leave a lot of innovative stuff out that would make the product better. If you're a developer, you don't always want to be bound by the existing design constraints either. It's a back and forth discussion between the two halves.
Sure, the principle is rather straightforward, but writing CSS is tedious and error-prone and the HTML/CSS is combination is modeled on single column text based layouts… it’s shocking to find out there’s no built in support for columns and no way to vertically align an element, for example.
I spent a month doing CSS until I had learned to implement the kind of grid I could knock together in 5 minutes in InDesign… very unsatisfying… Whereas later I spent a month learning Python and felt like I made much more progress, deepening my understanding of the digital medium, improving my “procedural literacy” and shaping my views about possible interactions.
So programming logic is actually more easy and fun for me—though that doesn’t take away from the fact that you need CSS knowledge to make a design work…
Although I would say that HTML and basic CSS is easy. Getting creative with complex layouts using CSS can get challenging.
But I can say the same about programmers when it comes to design.
This is something that needs effort from both sides if you care about final result
I also think most people are thinking from the perspective of the scrappy start-up, where you must be multi-talented in order to cover various roles. In large organizations there's designers that only produce wireframes, then another designer comes along and produces the final visual output, and finally another guy comes and codes it. Not that it's the right way to do it, it's just that the expectations are being set too high.
Instead of putting down web designers who can't code, appreciate web designers who do it. This comes from a web designer who can code.
Someone who comes up with a good design that can't or won't be implemented may as well have not designed it in the first place- but if they understand the constraints on their design they can come up with something optimal that can actually exist.
But there are people that have a vested interest in playing designers and developers against each other.
I've seen this happen time and time again, both via internal management and external clients: feeding designers and developers separately different bits of information (but never the whole picture), letting them make commitments based on that information and only then bringing the two together. The end result is that in order to make good on their separate commitments, designers and developers are left with very little room to compromise, which undermines the cooperation. The goal of this little divide-and-conquer game is to pressure them to come up with a result they otherwise would not have committed to given the time and budget constraints.
There's a reason why designers and developers are often very deliberately hired or managed separately for the same project. There are plenty of people who believe having designers and developers work together too closely is not in their interests.
I don't think visual web designers should necessarily be able to fully and efficiently implement their designs, but they should have a general understanding of how their designs will be implemented. IMO part of a web designer's educational experience should include interactive design (not just art and print design), HTML and even a programming class.
Likewise, front end engineers should have some exposure to art, design, maybe even have taken some drawing classes, and definitely be able to operate Photoshop and Illustrator (or whatever the predominant tool is).
You don't hire an architect who doesn't already know something about contracting, materials, and geology, even if they're not going to be driving the bulldozer. Same goes for web design.
Web application design (which is distinct from brochure web design or print design) has unique conventions and constraints, and web application designers absolutely must have a deep understanding of both. There are header nav bars. The branding with the link to the root path is in the upper left, user info/settings are in the upper right. HTML and CSS are structured as boxes within boxes. Main content areas contain the primary content, sidebars contain secondary content. Components are modular. Browsers have significant variation in how they render things, and viewport sizes vary dramatically. We have views and forms, GETs and POSTs. Resources are nested, with one URL per resource. Browsers have different levels of CSS support, leading to a focus on progressive enhancement and graceful degradation.
Every single time I've ever worked on a web application with a designer who didn't know HTML/CSS or a web designer who only does brochure sites, they stumble on these issues, and we end up with inflexible designs that have usability issues and are a pain or impossible to implement. Designers who don't know HTML/CSS create drag in a startup environment. It forces others to spend time and energy explaining how the web works and what the conventions are.
Yes some people are more creative, but who said being a good programmer had nothing to do with creativity? Along the same lines design is not art. I've seen many talented artists who were average designers because they couldn't, or wouldn't, blend in some structure to their work.
I started out as a book designer, then web hit and I became web designer. Although I admit the early days of table based layout made me want to run back to QuarkExpress. Flash arrived on the scene and sites like the Remedy Project inspired me to learn to code. Long story short, I now know OOP inside out and, thanks to hacker news, have dived into in functional programming.
I spend very little time designing anymore. I'm still miles ahead of my fellow developers, and I tend to be more creative in my problem solving. That said I still run to them (or stackoverflow) when a hardcore programming problem pops up.
Becoming an expert at anything takes time, if you're a Jack of all Trades one of those trades will suffer. I've chosen programming because I like building things, plus the pay's not bad. I'm still 'designing' it just happens to be with code.
The activities of designing and of coding overlap extensively. Both require a clarity of communication, a deep consideration of the purpose of the thing to be designed/built, and a sense of taste.
If in the habit of extracting general principles from concrete examples, coders can become better coders by learning aspects of design and vice versa.
Many of the concepts in a 'coder' book like 'How to design programs,' for example, are readily applicable to UX design, e.g: refactoring, wishful thinking, generalisation of purpose, and the control of complexity by use of 'black boxes.'
Likewise, a 'designer' book like 'The design of everyday things' is full of stuff that applies usefully to the activity of coding, e.g: the importance of meaningful feedback, and of ensuring a clear mapping between expected actions and their outcomes.
These correlations aren't everywhere to be found, though. But I've always found interdisciplinary people to have the freshest approaches.
This argument is made by those that are completely satisfied with their design. A little engineering knowledge on their part could never make the design even better. no, never!
The first law of UI design is that you will fuck up most of the time. Most of your ideas are going to be bad bad bad. If you think that every mock comes out of your workstation smelling like roses, then you're either deluding yourself or you're just knocking out something incredibly derivative. To be a good UI designer you have to say no all the time, and to all of your ideas.
So here's the problem. Static image mocks only paint about 60% of the picture when you're talking about modern (especially touch-based) interfaces. Static mocks don't give you enough information to accurately cull your ideas. Sometimes you need to build the damn thing, so you can touch it and move it and realize well damn, that wasn't such a great idea after all (or oh, this part really needs to be changed or the final, magical yeah, that's not too bad).
All of the best and most innovative UI designers that I've met have been able to build interactive mocks of their designs. Now - don't ask how they did it. It's spaghetti code that will curl your hair, frequently written using some arcane technology that might not even be supported anymore. But it works just well enough that they can use it to iterate on their ideas.
Now, you can split this job into two people. One a "designer" and one an "interactive mock engineer". In theory, it could work, but in practice I've found that it becomes hard for the designer to detect the flaws in the design. I'm not sure why. But the final product doesn't change as much. It doesn't evolve as much. It's rarely as good as it should be.
A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.
-Robert A. Heinlein
There's not just "design" and "code" out there, the design field is way more deep than that, so that quote might translate well to a designer that can't code, but studied in depth social psychology, urban architecture and team cooperation techniques. :)