My problem is that the only people I meet who know CSS fluently and deeply ARE designers.
All our developers don't want to touch complex HTML or CSS with a 10 foot stick, and this seems to be the case with a lot of the resumes I see as well.
I'm the sole product designer AND the only HTML/CSS guy at my company, and that's not for lack of trying to find someone to help. It just seems like everyone wants to work on the app logic and JS, not the actual UI. Those who do want to do that market themselves as designers.
Excellent point. This has been very true in my experience as well. Writing CSS for developers is way more efficient than art directing every pixel. If you have a good relationship, they REALLY appreciate it too.
Myself and I couple of friends prefer exactly the opposite, to focus on UI and not the logic/JS. Also this seems now to be an area of growing, I mean, front-end developers shifting to UI. It shouldn't be that hard to find a good guy.
I think the main problem I see with designers here all claiming they "can code" is that they don't really understand what it means to be a front-end developer.
Sure, I know html/css like the back of my hand and can implement JS plugins with the best of em. I build sites for clients on various CMS products. However, that does not make me a front-end dev.
HTML and CSS are child's play. Front-end devs should be able to write their own JS logic and wire up the backend to a framework like angular, etc. CSS is only 1/20th of what a front end dev should know.
A fully scaled web application with millions, even hundreds of millions of users is not haphazardly hacked together in the same way we build our "hand-coded" portfolio sites. There's many ways to solve a problem, however the most resource efficient way is what matters at that scale.
CSS being only 1/20th of what a front-end dev should know means a lot of front-end devs really don't take the time to get good at it. Which leaves me in the position where the people who are actually great at CSS don't know all the JS logic.
Sure in an ideal world all my front-end devs would know how to translate a design into HTML/CSS, but in the actual world they don't, the "designers" do.
I think what you describe is a general lack of design knowledge and attention to detail from the developer (which the article mentions too), not a lack of CSS knowledge.
CSS is the probably the least complex of all web technologies (other than maybe JSON or markdown?). I highly highly doubt the developer in question doesn't understand CSS. What's more likely is they don't understand the idea of positive/negative space and kerning so they don't understand why exactly they need more padding here, less letter-spacing on this headline, etc. etc.
No, a lot of these developers are very detail oriented, just without design knowledge and without CSS skills. Their detail is about the app logic, not the way it looks.
They get how CSS works, but they don't know how to remove the empty space between inline-block elements, or how flex-box works compared to floats, or the difference in animation performance between various methods, I could go on.
Sure CSS is not complicated, but to build a performant, responsive, and beautiful web app you need more than just the basics.
This becomes increasingly true when you are dealing with SASS or plugins like Bourbon which the developers won't even think to use in the first place.
The tools and world of writing HTML/CSS is more detailed and complex than you might think, even if the actual code is relatively simple. This way of thinking is highly visual and I find designers are much better at it in general.
A designer "who can code" and the kind of developer you've described fill totally different roles....they can, and often should, co-exist on the same team. Anyone with a small amount of self-awareness should recognize the difference and the boundaries of their own skills.
Let's call this designer one with "UI coding skills". His/her skills stop at the template. Perhaps they are well-versed in Wordpress PHP, Jekyll, etc. This is great for their portfolio site, small projects, or anything with limited functionality. This person will never be able to build the kind of stack you're describing. However, they are still very valuable to a product built on the stack you're describing.
The problem is not that designers are learning "UI coding skills". The problem is that people conflate this with a role better described as an "engineer", and then discuss them as if they're zero-sum.
I hope the outcome of this discussion is not to discourage designers from learning "UI coding skills", but rather to educate the decision-makers who are crafting teams about the different skillsets and personalities required for success.
I appreciate you clarifying and I agree with you completely. Those light coding skills are definitely a huge help to any team, even if it's only a general understanding of code. And for the record I have no problem with designers writing strictly HTML/CSS.
My beef is that a lot of people don't understand what you just described, that HTML/CSS is only a portion of the front-end, even people in the comments below. And this trickles down to hiring managers. They think because all these people call themselves "designer/front-end dev" on their linkedin, suddenly they don't need to be hiring dedicated front-end guys for those roles (or really, engineers). I've freelanced at too many small to mid-size companies with jack-of-all-trades types that the article describes doing mediocre work because they are given too many responsibilities. Unless it's a <5 person start-up, Leave the JS logic to an engineer.
This makes a lot of sense! The idea of being at a mid-size company where I'm expected to handle all logic and UI makes my skin crawl. People like me know just enough to be dangerous when it comes to that sorta stuff.
Logic is fucking hard, I'd rather have someone on my team who's whole job is creating a really nice API. I wouldn't want to get much deeper than maybe binding that data to the UI
My thought... Print designer would have to know paper materials/textures/printing press to design well. Industrial designers would have to be on top of all physical materials/machining process, etc. to do so. If s/he designs for the web, s/he then would have to be able to understand/write some code to design well for the web.
Totally agree with you.
I agree that designers designing for web should have a good working-knowledge of the coding that goes into building what they are designing for. They should even be able to do some simple web-building, of sorts. However, I do not believe that they need to know how to actually implement the entire piece, in full.
Just as an industrial designer, even though needing to know a lot about the materials that are being designed for, does not need to know how to actually build, from scratch, the entire piece in development. And just as the print designer, although needing a good base-knowledge of all the materials that go into the printed piece, don't actually have to print it themselves.
I believe that separate roles are important. It is important for the print designer to work with a quality printer to finish the job. It is important for an industrial designer to work with a quality manufacturer to finish the job. It is also important for the web-designer to work with a quality developer to finish the job. I think that, although possible for any of those 3 designers to take their project from ideation to completion all alone, it is behoove the designer(s) to work with a knowledgable partner to get the best end-result.
Just my thoughts :) I mean, more power to the designer who can do it all. I just feel that time can be better spent honing their design skills.
You're totally right and I think I'm the one who didn't get the point of the original article here.
My point is that it's passion that is important and that pushes good to great. Of course designers who only deal with pixels can design the most beautiful websites and sorts but if they are passionate what they are making, they'd dig in to code, which makes their design to real website thing, so that they can communicate with devs better.
So for example, if I happen to know some code, I then will be able to give some deep direction as to how the page scrolling will behave (parallax or not), how focus/active state will behave on certain forms, etc, instead of having devs guess all these things. I'm not really sure if it's possible to understand all these without knowing code...
I also do not believe they have to be able to push their entire piece to live and I agree with how important the separate roles are. We need them. We need to be the master on what we do and we need another master on what they do to collaborate. We just need to understand/know how the other side works to communicate better.
I totally agree! Well said. And, yes, it is definitely MUCH more helpful for a designer to know how code than to not, even if they only use that coding knowledge to aid them in better their designs, interfaces, experiences, and more easily being able to communicate with their developer(s).
Print designer would have to know paper materials/textures/printing press to design well
I don't think this translates to
If s/he designs for the web, s/he then would have to be able to understand/write some code to design well for the web.
You're equating "knowledge" with "ability", and you aren't respecting the very large gap between the two. Expecting a web designer to code is akin to expecting a print designer having the knowledge and foresight to determine paper size and gang-up print pages for the printer so they can just start printing.
When I was working in print production, however, we had jobs where designers would try to do this as a way of "helping out", but this was rarely if ever helpful and almost always required a lot of extra work to fix. The production team determines the best way to print, not the designer. The production team knows what size of substrate they're using, not the designer. A designer is best limited to understanding the complexities associated with the production of a given product as a way of influencing their design, but in no way should they be expected to actually do the work that another discipline has far more experience with.
knowing the affordances of the medium is key, but the industrial designer example is illustrative - while an industrial designer might make a working prototype together with an engineer for certain aspects (electronic prototyping, powertrain, tensile structing, wind-tunnel testing), they wouldn't do it alone.
And once they'd finished their role, a second set of engineers would focus on how to build it with the appropriate material constraints (material, strength, safety, etc). And then a third set of engineers would focus on building the factory line to actually produce it. A fourth set would focus on quality testing, etc.
It is possible to design, create and sell things direct to market - that's the Etsy model, it works for a certain scale. But the larger the scale you work on, the more sense it makes to leverage specialists working together. At a certain point it creates something bigger than the sum of its parts.
It's not that one person can't know everything, it's that above a certain point it's inefficient to have them do everything - and you can't get the benefits of collaboration when you're working alone.
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.
Try collaborating (as a designer) with another designer who doesn't know the slightest thing about developing whatever you're trying to build. You're in for a world of hurt.
I know exactly how it feels like...
A web designer who doesn't know HTML and CSS is like a fashion designer who can't sew.
Or an architect who can't operate a crane.
More like an architect who doesn't know AutoCAD.
Nah, AutoCAD is closer to Photoshop. Typically there's multiple layers of engineering that happen after the CAD, then materials engineers who actually work on the product afterwards with the actual build materials. The analogy doesn't work.
I worked on an electrical engineering startup - majority of engineers on the ground actually use paper printouts of CAD drawings that are then marked up with additional detail. Electrical designers and engineers work closely but people aren't allowed to do both - QA requirements mean legally you have to have different people on the project, otherwise it's too easy for dangerous, broken product to be created.
CAD is highly abstracted ideation, which requires a talented engineer to work with the architect / CAD designer to turn into reality.
The thing I find most infuriating about this argument is that the question 'should designers code' is predicated on the implicit assumption that the highest priority for a designer is to make life for developers easier.
We've tried engineering-led design, it fucking sucked 20 years ago and it fucking sucks now.
A designer's highest priority is to keep users happy, not developers. Sometimes design and development are in conflict, and that's ok - productive tension is what lifts software above run-of-the-mill solutions. Sometimes designers have to give a little to make something feasible, sometimes developers have to work outside of their comfort zone to make something users will like.
I've worked alongside developers for a decade, and I've only had a developer say 'that's not possible' once. Then ten minutes later she'd come up with a working solution, and was overjoyed at having a challenge to solve. If i'd already made an engineering decision for her, the product would have been prematurely limited, and she'd have had a boring job to do.
Your post reminds me of the book "the inmates are running the asylum" that I just had the pleasure of reading this year. As a designer just starting out in Corporate America, I am truly grateful I wasn't designing in those brutal times where design was led by engineers and design was applied after a product was built and treated as a coating of paint.
Yeah I had that book in mind when I was writing the comment!
Knowing how to code makes you design wisely. Period.
This would be a perfect use-case for that old "beating a dead horse" DN post icon.
One weird thing here is people are projecting their "day job" perspective (yes I can walk the front and back end line)... but they aren't speaking to the wildly valuable perspective of, if you can build your ideas, you're in a new ballgame. Designers that can't build, are immediately haltered on what they can push into the world.
Breadth is useful no matter what you choose to focus on.
You know code as a designer? Great, you can actually begin to understand the problems that your developers will face when trying to implement it. You'll design better, more modularly, tuned to the constraints and open to the opportunities of the system you're designing for. Fan freakin tastic. Plus, your developers will respect you more, you'll be able to communicate with them easier.
Breadth. Breadth makes everything better. The problem is not knowing how to code, it's how you choose to use your time. Knowing more will always be better. It's not about whether you can code, it's about whether you focus on code or continue focusing on design.
Yes, breadth in all different areas, everyone doesn’t need to have the same skill set! This article is like someone recommending all bands should have a drummer, a guitarist, a vocalist, and a bassist. What really matters is the music they create, and that’s going to come from all matters of interesting people and skill combinations.
When I hear people call themselves unicorns or devigners this is what I think of.
I think that was very well said. I am in fact one of those designers who can code (and code well might I add) but I am not comfortable with the term "developer" because that means that a there would be a whole new set of expectations that would simply go unmet and it's not fair or just for anyone to have those kind of expectations....but they still do. Being part of a development team definitely presents challenges for the designer who can code. Thank you for this post. I enjoyed it thoroughly.
If you don't know how to code you're only hurting yourself.
Whereas if you know how to code, you immediately have a platform to hurt people all over the world.
If all you're interested in is entry-level generalist positions, sure. I've found over my career i get better roles by focusing on a specialist skillset - and now that I'm the one sitting in the interviews vetting people for my team, I look for people with specialist skillsets. Generalists just aren't very good.
Anecdotally, I'm a designer who can code who is looking for another designer who can code for my startup—and it's a difficult task. There just aren't that many of us out there.
If nothing else, expecting designers to spend their spare time learning to code means they spend less time learning more directly useful design skills, such as UX, design research and user testing. Designers should learn about constraints, but better to focus on usability and experience constraints, not only implementable solutions.
Engineering is the profession that's focused on whether something can be built. Design should be more focused on whether something should be built.
I still don't understand why there's this argument out there that doing one must come at the detriment to the other, especially in terms of learning. One can learn to code AND read articles to learn about best mobile UI practices, it's not like one prevents the other.
There's a bit more to UX than reading best practice guidelines! That's entry level for being a designer. Understanding UX is about understanding people and their behaviours.
Ultimately it's about how much time and focus you have. For most people, maintaining one set of skills at a high level is hard enough. Two sets is the max for most people. And given the number of pretty, well coded software products that are utterly useless, I'd argue we'd do better focusing on creating more designers who can find out what to build rather than how to build it.
Path is a great example. Very pretty, classic startup, lots of unicorn designers, building a product that fundamentally misunderstands how people communicate and maintain friendships. A bit more focus on the human part of design would have really helped.
I agree that we should focus on designing what to build, I struggle with this question everyday working in a corporate setting. At the end of the day, it's all about revenue and that dictates what is to be built and when to pivot. Designers can create a pain-free, intuitive experience for users but when you have product management defining requirements and use cases, your hands are tied in respect to "what to build". That simply isn't seen as our job unless it's your company or you are a UX researcher tasked with uncovering unmet market opportunities through user (segment) research.
Yeah, I understand that it's hard in certain workplaces - but we should resist allowing product managers to degrade the practice of design to just following their dictates!
I guess it's a bit like how you probably wouldn't want brain surgery done by someone who specializes in dental surgery, for example. While the disciplines share a lot and they could probably both do it, it's not perfect.
Title is correct. The reason why there is so much push for getting designers to code is that it seems like a lot designers design things for platforms they don't understand. If you're a designer and you hand me an iOS composition or mock with a traditional web/desktop dropdown; as an iOS developer, I'm going to immediately assume you don't know what you're doing. iOS has native elements which correspond to the equivalent dropdown on web and desktop. The challenge also goes deeper than UI elements. If you're working with 2 designers and one of them understands the mechanics of the framework they are designing for; it's going to be far easier for a developer to work with them and have a conversation.
The problem is that the goto lazy answer is: "Make designers develop so they can feel developers pain" which I don't think is necesary. From a developers perspective, the challenge is more about getting designers to understand the limitations and impact of their design decisions and really good designers know this.
As a concrete example the status bar on iOS can be two colors... black or white. So if a designer is asked to build a side nav menu and they come back with a design that has a dark layout on the main view and a light layout on the side nav or vice versa, part of the status bar will be invisible depending on which color status bar you choose. There are lots of ways around this, but an example like the one below shows that the designer understands that they are picking colors where the white status bar will stand out.
Meanwhile the Mailbox app is an example where the developer would need to use private frameworks (Not recommend by Apple and could potentially get your app rejected) or screenshot capture and overlay to hide and/or move the status bar
A quick google search for “should designers learn to code” yields 25 million results.
I see a solid 64 million when I click that link. Also, "should doctors learn to code" is at a nice 54 million, and a winning 122 million for "should teachers learn to code"
Lol all the discussion of teaching kids to code in school has teachers worried since they would have to learn it before they can give lessons on it if I had to guess
"That's what we need".
Who's "we"? I wonder.
People can say that designers shouldn't code all they want but good luck getting a job without knowing the front-end stack. It's just part of the job now, for better or worse.
Being a UI designer isn't the be all and end all of the design industry FYI.
However designernews.co is definitely skewed towards the tech industry. I'm generalizing here but I think it's safe to say that 90% of the users are either UI, UX, Product, or Web.
To be more clear. I'd say it's nearly impossible to find a job as a UI, UX, Product or Web Designer without knowing (at the very least) HTML/CSS/JS.
Nope. I've actually found presenting as a jack-of-all-trades lost me jobs. Once I specialised I got better job offers.
I think the other design talent has been pushed out really because most of what is posted here could just as happily sit at the top of HN too.
If you look back to when the site started the user base had much more variety.
Still not enough nails in this coffin ay?
You're limiting yourself if you can't code. Your chance of getting together with some friends and banging out a product over the weekend, or of going all in and starting something up full-time, is much lower if you bring just design to the table. In those situations everybody needs to be multi-talented and able to take on a significant chunk of the work.
That's my experience, anyhow.
The biggest benefit of having designers design and developers code is that the designer is an advocate for the user and the developer looks after the qualities of the software (speed, scalability, ...)
I haven't been in situations with developers who were great at CSS/HTML and enjoyed it. Most of the time folks are super stoked when you say you can take care of the nitty gritty of implementation. Especially because 99% of the time the designer is going to have 10 small changes that they need to get it perfect — so much easier for everybody involved in the designer can own that and make the changes themself.
I was in charge of getting a website built for my company recently — I was busy on the product so we farmed out our public-facing site. The implementation of the approved design was going terribly; it was clear that whoever was actually doing the coding didn't have a design eye and wouldn't go the extra mile to make sure the design as approved worked correctly and elegantly across many browsers.
I signed off on a shitty version and fixed it myself in a day. Having that skill meant that the site launched to my satisfaction. If I couldn't code we'd have a piece of poop out there instead of a pretty solid marketing site.
Couldn't disagree more with this logic/premise. Why should one limit themselves? I believe @Allan said it best https://twitter.com/allan/status/535160640462422016
Depends on what stage the company is at. For early stage hiring a designer who can code is incredibly beneficial. Later stage, when quality of code is much more important, you want people focusing on what they are good at.
I think designers should at least have an understanding of software and its limitations, and also be able to work with engineers to bring their mockups/prototypes to life. A flat psd or even a prototype almost never "feels" the same when in its final coded form.
When we say 'designers should learn to code' - what code do we mean?
HTML / CSS - ok sure. That's not really code though, that's styling.
We work on a lot of apps now though. So Objective-C, Swift, Java, DotNet and whatever the different iterations of Windows Phone run on?
But then we also have to design for legacy systems, so add Sharepoint, SAP, 15 year old banking software, Sitecore, custom DotNet systems, internal CRM tools for bank tellers, workflow management systems, government reporting requirements, CQ5, government APIs written 20 years ago. Ticketing systems out of the dark ages.
Then we have to support Wordpress, Ruby on Rails, Drupal, Joomla, Plone, whatever new CMS is flavour of the month.
Oh, and limited-powered set-top box systems running custom code plugging into video-streaming services and third-party EPG over the top with integrated billing and DRM tools. Video streaming tools for broadcasters with integrated licensing management. Subtitling tools.
The developers working on this stuff don't know much beyond their immediate project - half the projects I'm on have developers, BAs, tech BAs and DBAs for each aspect of the system. So why on earth am I expected to know how to code for all of it? It's hard enough learning the guidelines and affordances of the platforms, let alone their code and quirks.
If you're working on a single app or platform, with a simple tech stack, and you have the time to focus on learning some code to make your co-workers life easier, great! But stop making grand pronouncements for the entire spectrum of design.
Agree. It's a scale thing really though.
Great post, totally agree with what you said! Empathy is key. I just spoke about this in a recent interview and I touch on a lot of the points you brought up. http://campfires.io/harrison-telyan-lead-product-designer-at-sindeo/ (scroll down to the part where it asks about design and dev worlds colliding!)