Where the design community meets.
This is well written and a very apt insight for where our industry is/should be going.
However, I think the author understates the value of front-end code as a design tool. Designers should be capable of architecting a visual language for an application's UI layer. Doing this efficiently often requires writing top-notch CSS (and even some JS) that can be used in a basic production environment.
The same way a developer should be capable of building an interface that meets certain visual standards without a detailed spec from a designer (eg, readability, hierarchy, simple affordances, etc). This would, for example, help teams ship internal tools quicker.
That said, the thread he's pulling at is spot on, and the swiss-army knife metaphor does a great job of hitting it home.
I have to ask, when do you expect a designer to design an entire ecosystem of design and write top-notch front end development? Developers 9 times out of 10 want the language defined, and by your standards dev'd out so they can just plug and play. This is something that boggles my mind when you think about the amount of time it takes to design cohesive systems let alone dev them out.
When creating an "ecosystem of design", if the designer is skilled enough, it can save time and improve the final product to write basic code which can be passed to a development team for integration.
Take Lonley planet's UI library as an example: http://rizzo.lonelyplanet.com/styleguide/ui-components
A designer might write some basic mark-up and CSS or even JS for the components you see listed in the left column. The development team can then take the mark-up and integrate into their templating system. This process requires a lot of empathy, multi-disciplinary talent, and a defined style guide for coding (using same conventions, same pre-processor, working within existing markup structures, etc)
You went from top-notch CSS and production ready code to, a designer could code up some basic markup. Fairly different things there. Knowing code, and writing enterprise top notch code, are wildly different things. I work directly in a development team, and completely agree with the empathy and the ability to jump in and sling some clean up code. Saying hey designer, we want you to design an ecosystem, from wires to visual, then break them out, have a firm understanding of modular development and write all the markup code for your design that is production ready, so we can grab-n-go that'd be great. Also while you're doing all that, you're not iterating, testing, or anything like that unless you're doing that iterating in-browser (not always bad). There is always a balance to be had. Good talk paul.
Yes, a designer might write top-notch CSS and production ready code. OR a designer might write some basic mark-up. That's the point I'm making. The reason this debate gets so tiresome is that the answer is not academic, but rather depends totally on the team/project at hand.
For smaller projects that have limited functionality, such as a content-driven website, the designer may have to do exactly what you described. For others that same designer may have no place writing code as a deliverable (even if they write code to support their own workflow).
Designers should be capable of architecting a visual language for an application's UI layer
I disagree. That would be like saying a front-end developer should be capable of designing a visual language for an application's UI layer. They may be able to do it, but it might take them longer and not be up to the same quality standards.
Designers should be able to understand in general how the front-end is being architected, and design something that doesn't overcomplicate things for whatever platform it is. But I wouldn't expect a mobile designer to write production code for, say, an Android app's UI elements.
If a team's resources are limited, this might be an acceptable compromise, but more often than not a front-end developer will be able to implement a (well designed, properly spec'd and communicated) design in code more efficiency (in both speed and implementation) than a designer could.
I know the basics of a lot of different programming languages and I could code an app from start to finish (back-end and front-end on web, iOS, or Android) but it would take me an incredibly long time and I'm sure developers would want to re-write all my code. Knowing how those platforms work, however, has improved my designs and my ability to efficiently communicate my designs for those platforms, and it means I can jump into the code to troubleshoot bugs or make small tweaks and adjustments rather than asking a developer to increase padding by a couple pts. In my experience, this has been the most efficient approach.
Coding is not a necessary to "architect a visual language for an application's UI layer". This can be done in Sketch, Photoshop, Illustrator, etc. The visual language is just that, visual. "Designing your very own twitter bootstrap"....that is what I mean when I say "architecting a visual language".
I think your points about workflow are well taken, and the answer certainly varies from team-to-team and platform-to-platform. It depends wholly on the teams' skillset and the requirements of the project at hand.
Finally, when using code as a "design tool", the aim doesn't always have to be production code. Personally, as a designer with my own front-end systems in place, delivering style specs for basic web elements (forms, type, buttons, tables, etc) would be accomplished faster using HTML/CSS than Sketch or Photoshop. I could take a screenshot and send this to the developer, which they could treat like any other mock-up. The benefit is, there is top-notch markup and CSS behind which they can use/not-use.
Your native example is a good one. IF I was designing an Android app, this approach would definitely not work.
Where the design community meets.
Designer News is a large, global community of people working or interested in design and technology.