This title is a bit clickbaity. To save you a click: the author's mistake was, as a designer, to stop writing interactive prototypes and to go back to making static screenshots instead.
I would take that a step higher in abstraction and say
"His mistake was to stop going above and beyond because someone told him it wasn't required"
The lesson we can all take from this is to give you absolute best - if your immediate manager(s) are not ready for it, don't stop just because they can't handle it.
"His mistake was to fail to defend a better, interactive workflow enabled by new technology that could have helped the company tremendously, and instead fell in line."
The lesson for me is, we have to think critically, recognize real opportunities for the company, and argue for them. To fail to do so is not doing your job.
Two or three of the best designers that I would never hesitate to recommend all know how to code. They know exactly what's possible in which browser, and they organise their assets, mockups, designs, documentation so beautifully that as a developer I actually look forward to bringing their designs to life.
More often than not I'll shy away from doing front-end precisely because a lack of understanding from a designers part on what's possible or what needs to be hacked together using ludicrous amounts of JS/CSS workarounds; especially since these very designs or ideas is what the client or PM okays / is expecting.
Just my $0.02 - as a dev I'd love you quite a lot of you knew what I do and help me by taking the limitations into account :)
Likewise, devs need to - politely, but firmly - know how to push back on some 'designs'. I push back on bad designs - things that obviously won't be usable on multiple devices, have demonstrably poor UI, etc - when I know that the 'design' was done in a vacuum, without any testing or acknowledgement of web realities.
I've worked some truly awesome design folks over the years, but also had some folks have their 'designer' send me a PSD from themeforest that they went in and added crap to that made it essentially unusable, then charged the client $800 for a $30 theme.
So, should programmers learn how to design? Oddly enough in the 80's programmers were the designers for the most part. The idea of a standalone designer was more of a web idea from the mid-90's. Before then we all considered design as a part of programming. The one app I built from 1988-1993 that is still sold (many owners later) has many features remaining identical to what I designed despite being the lead programmer. Today people laugh at the idea.
I think the more everyone on the team understands all the specialties the better the app is likely to be.
I think I have learned some web design just from using the internet for the last 15 years. I'm not a phenomenal designer, but I've got some intuition and can make some simple choices.
And I get really nervous when my company's designer wants to adding a scroll bar to a modal dialog. :-(
May as well. Blogs/media continually throw every small skill that they can into the bucket-of-things-you-need-to-know-as-a-developer. Eventually it'll catch on and it'll be on job postings.
Since CSS2/3 I never touched design programs again to design websites and web apps. It's so easy to trow a basic interface together and then use CSS to give it nice looks. So this became my way of work:
* Build a simple HTML template as interaction design
* Add some basic design (style, color, fonts)
* With the customer fine tune the design
* Add code to the templates to make it all work (or hand it over to development)
Ofcourse you still need design experience. You are just using other tools.
I agree it is easy to throw a basic interface together in HTML/CSS/JS, oftentimes the code is reusable and this approach can be pretty effective. However, I'll present a reason you should NOT do that - if you are working with non-technical users /designers in a joint-application-design (JAD) or collaborative type session.
When you are sitting next to someone, and you are designing UI, and you have to open anything that looks like code, it can throw off non-technical people severely. Oh, sure I can make this box bigger, let me just change this property on some CSS, adjust this div and then refresh the screen?
I have done both styles, using tools like Balsamiq and Axure RP, paper prototypes, whiteboard prototypes, fat-client prototypes using desktop UI frameworks, and prototypes in HTML/CSS/JS. I think the advice here is, make sure you know the audience you're working with, and that having to interleave code with the design process doesn't throw off the workflow (even if only basic coding).
I used to sit down with a client and change elements of the design right from the developer tools. In theory, it's a nice approach.
In practice, it meant that clients started to have unrealistic expectations of 1) how many changes they could ask me to make over time, and 2) how much time it would take to make a change.
So nowadays I only do this with designers that I work with, at set times, or with clients that I know I can trust.
I completely agree with this one. Designers and UI/UX developers are not mutually exclusive. It works better when it's the same team/person.
It works really well when designers know what they are catering to. In case of browsers, it saves a lot of time when they know browser differences, or when they know JavaScript / CSS capabilities.
What a less than visionary manager. I would love UI folks to make a prototype of how they envision the UI to work. It helps a lot and allow for some quick feedback from both the biz and the programmer who has to do the programming. Its in the same ballpark as writing the user manual first then starting to program the project (Pages by Pages, I do believe).
I knew a couple of consultants who did enterprise process work and also knew Shockwave. They would program a demo of each process. A little figure moving paper from place to place gets the point across better than any PowerPoint presentation ever will.
If 'designs' are intended to be reused across multiple areas - print, tv, web, whatever... - I cut designers a bit of slack in terms of deliverables. When the designers are primarily/exclusively working in the 'web' or 'mobile' portion of their industry, and yet, after several years, do not know how to even start to test ideas out in a browser, it's a sign that that they don't care about their work or career as much as I though they did (or as much as they probably think they do).
Even 15 years ago, the best design folks I worked with could do basic HTML stuff, to at least test out their core ideas. We'd review them, and I'd point out some problems we'd have cross-browser, or limitations of JS interaction at that time, and we'd iterate some ideas. They understood enough of the web portion (and these folks came from print) that when I explained (or could demonstrate) the problems in code, which they'd already written some of, they knew why the problems were there. They could know something was actually not possible to recreate in pixel-perfect fashion across IE3,4,5, NS2,3,4, WebTV and Opera, because they had experienced a site was more than displaying a single JPG file on a website with a massive HTML map area (did a couple of those WAY early on - insane).
Don't send me a photoshop file with 280 layers, one for each rounded corner on the 17 round corner boxes with too-small text which only looks good on your 30 inch triple monitors please. It's not going to translate and give the same 'feel' on multiple screens. (how come it's OK for you to not have to know html/css, but I have to have a photoshop license to work with you? and your agency complains about how expensive I am to boot?).
I don't expect you to be an expert in coding/layout, but I do expect you to know the basics. Similarly, I'm fine with knowing how to open PS files, resize images, export to different formats when you don't deliver what I ask for, etc. I can't do all of your job, you can't do all of mine, but let's have some familiarity with each others' worlds, OK?
About 20-30% of the design folks I've dealt with have truly 'got it', when it comes to designing for the medium, and understanding the tools. Most of them also did it in print, and would have an understanding of copywriting basics, font impacts, etc, as well as paper issues (printing on different paper types could impact colors, glossy vs matte, whatever). They understood the print medium, because they understood the basics of paper, then got in to web and understood the basics of web (HTML/CSS/etc). For better or worse, the other 70+% of folks just don't get it, or seem to care.
The older I get, the easier it is to choose to not work with those folks, but for the first several years of web work, I couldn't put my finger on why it was so much more productive working with person A vs person B.
