During the dotcom boom back in the late 90s, I did a bunch of Photoshop-cut jobs. You know, where a designer throws a PSD file over the wall to an HTML monkey to slice and dice. It was miserable.
These mock designs almost always focused on pixel perfectness, which meant trying to bend and twist the web to make it so. Spacer pixels, remember those? We were trying to make the raw materials of the web, particularly HTML, then latter CSS, do things they didn’t want to do. Things they weren’t meant to do.
Then I got the pleasure of working with designers who actually knew HTML and CSS. It was a revelation. Not only would the designs feel like they were of the web, not merely put on the web, but they’d always be better. Less about what it looked like, more about what it worked like.
I attribute this in no small part to the fact that it was real. The feedback loop of working with the actual HTML/CSS, as it was destined to be deployed, gave designers the feedback from the real world to make it better. And the fact that designers had the power to do the work themselves meant that the feedback loop was shorter. It wasn’t make a change, ask someone else to implement the change, ponder its effectiveness, and then repeat. It was change, check, change, repeat.
For a while that felt like it was almost the norm. That web designers confined to the illusions of Photoshop mocks were becoming more rare. And that web designers were getting better at working with their materials.
But as The Great Divide points out, regression is lurking, because the industry is making it too hard to work directly with the web. The towering demands inherent in certain ways of working with JavaScript are rightfully scaring some designers off from implementing their ideas at all. That’s a travesty.
At Basecamp, web designers all do HTML, CSS, and frequently the first-pass implementations of the necessary JavaScript and Rails code as well! It means they get to iterate on their design ideas with full independence. In the real app! Quite often, the JavaScript and Rails code is even plenty good enough to ship, and we do, after a brief consultation with a programmer.
Other times the programming work is more involved, and a dedicated programmer will pair up to ship a feature. But I cannot tell you how much nicer it is to work with designers who know the constraints of the web, and can do the work of the web, than the alternative. When you overlap on the fundamentals, you’re on the same page more frequently than not. (Though we still trade concessions!)
Did we just happen to find impossible unicorn designers? Maybe, I guess? Likely? No. Scott, JZ, Conor, Jonas, Ryan, and Jason all grew into the designers they are today by putting in the work to get there. By not facing the damnation of low expectations or this-is-too-hard-for-them bullshit.
Now some of that is also tied to how we work with the web. Basecamp is famously – or infamously, depending on who you ask – not following the industry path down the complexity rabbit hole of heavy SPAs. We build using server-side rendering, Turbolinks, and Stimulus. All tools that are approachable and realistic for designers to adopt, since the major focus is just on HTML and CSS, with a few sprinkles of JavaScript for interactivity.
And it’s not like it’s some well kept secret! In fact, every single framework we’ve created at Basecamp that allows designers to work this way has been open sourced. The calamity of complexity that the current industry direction on JavaScript is unleashing upon designers is of human choice and design. It’s possible to make different choices and arrive at different designs.
One thing is for sure: I’m not going back! Not going back to the dark ages of designers incapable of making their designs work on their own, incapable of making direct changes, and shipping them too!
Also not interested in retreating into the idea that you need a whole team of narrow specialists to make anything work. That “full-stack” is somehow a point of derision rather than self-sufficiency. That designers are so overburdened with conceptual demands on their creativity that they shouldn’t be bordered or encouraged to learn how to express those in the native materials of the web. Nope. No thanks!
Designing for the modern web in a way that pleases users with great, fast designs needn’t be this maze of impenetrable complexity. We’re making it that! It’s possible not to.
Preach!
Amen! Sam Stephenson (I think you know him) also illustrated this point brilliantly in his [RailsConf 2016 talk](https://www.youtube.com/watch?v=SWEts0rlezA).
In the web’s infancy, it was really easy to render “Hello, World” and really hard to scale up to 100,000 users. Maybe now, the opposite is more likely to be the case.
I love your sentiment here, David, that the trade-off doesn’t necessarily _have_ to exist!
horrible idea
As a new developer, one of the weirdest disconnects is that on the one hand we’re being told we have to learn a pile of technologies to make anything work or get a job, on the other hand we’re being told that “it’s not feasible to know the full stack” and that we should just specialize, and on yet another hand (I know, three hands; I’m committing to the mixed metaphor) we’re being told that the web technologies have advanced so much we shouldn’t need a pile of technologies.
So either a mile thick of tech bloat is necessary to get a job, or a specialization in an ongoing division of fractal technologies is necessary for that, or I should only need my core web technologies plus a server-side stack.
I don’t mind any of those options individually, but I do have a lot of frustration with trying, as an outsider, to guess who I should be listening to.
To clarify, and of course, this is only my impression:
1. Job boards say one should know HTML/CSS/JS (reasonable), but also jQuery, Bootstrap, WordPress, Anglular/React/Vue, Grunt/Gulp/Webpack, Babel, Sass/Less/PostCSS, PHP/Python/Ruby, MySQL/Postgres/Mongo, Rails/Django/Laravel… basically any proper noun attached to any technology that has been mainstream in the past 15 years. I know this is more a peculiarity of job boards than actual expectation… now. For a while I thought I was actually expected to know PHP *and* Ruby, for example.
2. Experienced developers might recommend focusing on specific applications of technologies, like the “Great Divide” article says. So you’re either a back-end developer, or a CSS/UX/UI developer, or a JS developer. I… don’t like this, because HTML and CSS are two technologies that, as DHH says, everybody who works with the web should know. It’s not an unreasonable expectation. It shouldn’t be the realm of only UI developers. Neither should it be unfeasible to learnt the full stack.
3. Some of the people on the Google Chrome team and the Mozilla CSS team recommend that people SHOULD know the core web technologies, like learning modern CSS instead of Bootstrap, raw JS instead of jQUery and the built-in browser APIs before a frontend framework (before, not instead-of). I personally amalgamate (you might say conflate) this with the Rails/DHH idea that applications are not so precious that each requires a whole new galaxy of technologies to make them work; that you can just use a single framework to do all the work, every time. If it needs to be said, I think this is the most sensible of all attitudes and is the main reason I follow the Rails community so closely despite never having had a job in the industry.
I don’t think it’s so unreasonable that one should learn the core web technologies plus a technology like Rails in order to be productive as a developer, rather than to box oneself into a UX-only or backend-only role. In fact, it’s the most sensible-sounding option, because I DO think it’s unreasonable to learn alll the technologies, as job boards seem to desire.
Of course, this attitude is worthless if I want a job in this industry in my home city! But that’s just the way the cookie crumbles.
I’m glad this works for Basecamp but not every designer is just adding on features to an existing product.
We use the same process when we’re designing new products. Basecamp has created about 10 different products over its life time. Same process every time. There’s no difference in the approach to work whether we’re dealing with existing products or new products.
No one’s asking anyone to learn “a stack of technologies.” Web components or React is just javascript and designing an app that way (as FB learned) unburdens far more in the middle project. Rails is great for a 10-min blog or a 2 day prototype, but in the mid-game when things are really heating up, you have to rewrite your monolith, as Basecamp has done over the years. Client-first computing is how game devs do it. Every web dev complaining about having to learn something new is either not very good at this thing called software, or a millionaire with an over-the-hill framework and a book to sell.
“No one’s asking anyone to learn ‘a stack of technologies.'”
It must be so nice to be an established programmer that you no longer have to look at job boards anymore!
Sorry–I have to call BS on that last sentence,LW. There’s too much proliferation of frameworks on Github/etc. more or less tagged “here’s an SPA/server-side/client-side framework we wrote for our VERY SPECIFIC REQUIREMENTS that we think you’ll want to use.” That’s what React is, right? It’s a solution created by Facebook for its very specific needs. Whom among us is writing something on the scale of Facebook? How well does the company posting the job requirements understand the scale of its own application? HR generally doesn’t know these things.
It’s not about not wanting to learn something new–it’s about not falling into the trap of latching on to the latest shiny-shiny because of the real-world costs involved with rewriting and retesting the application. Feature addition grinds to a halt during the rewrite, and customers tend to take a dim view of that; co-developing the new application requires increasing the team size and running into moving-target issues, and management takes a dim view of that. Blindly latching onto the next big thing is a very one-dimensional approach and that’s certainly the sign of someone bad at this thing called software–says the guy who’s been delivering web-based software since 1996, full stack.
As far as job searches go–hey, I won’t be applying for any jobs where Scala is the language of choice. That’s just how careers go. I can operate at a professional level in about 10 languages–but Scala isn’t one of them. I’ve managed to have a successful career without it–so yes, no worries, it’s possible to do well without knowing every darned thing out there. It’s not clear to me that I’d want to apply for any jobs where the employer says I’d need to know all of npm, grunt, gulp, yarn, and whatever-showed-up-on-Github-yesterday because that implies the company doesn’t have a unified build strategy across teams or isn’t very disciplined in how it approaches software development in general. When the requirements list is an exercise in buzzword bingo–PASS.
I worked with many web designers over the last 15 years and don’t remember anyone who was not able to produce static HTML/css for their design, I was thinking it is normal. However frameworks like React introduced back the mess we had with PHP 20 years ago before MVC where developers were mixing templates and code and inline css, this make a lot harder for designers to collaborate these days… We currently use Ember and Rails with clear separation of templates and JavaScript code, our designer feels very comfortobale to work with clean HTML templates without mixed JavaScript, so I guess it is about choosing the proper technology for the team.
Same thinking…
I’ve been just a designer, just a front-end dev, and both (as this article suggests). Being a designer that is writing their own html/css is so much better. You can iterate faster, you can see people use your actual design and modify it based on what you learn, and it opens up more options.
While there are certainly great designers that can’t write html/css, I’d encourage them to learn.
Hi all, has anyone here used webflow.com to make their initial designs?
I’ve found it’s a tool that constrains you to what css and HTML can actually do on the web.
I’m curious does anyone here thinks it’s a substitute for designers writing their own front end code for their designs?
“How I prototype digital products in Webflow …” by Robert Smith https://link.medium.com/4GHcMd8pNT
“if all you have is a hammer, everything looks like a nail”
In this startup world, developers driven industry, everyone have to code. But it’s wrong.
When you say you don’t want to go back and don’t want designer that can’t ship code, it’s a nice way to say you want more developers, and not designers. Less diversity.
Obviously a designer in a web environment have to perfectly know how all of this works, and all of the constraints, but SHIP code ??
I’m a designer and a web designer, I know HTML/CSS (even some PHP) and can do simple site by myself. But it’s just one of the options, and even if you design for the web, I think you don’t have to learn code, you and you can contribute a lot on other designer related skills (conception, writing, photography, animation, strategic planning and so on…)
If you target only designers that can ship code, you only impoverish the diversity of ideas at the expense of the product.
Everything becomes code, because if all you have is a hammer, everything looks like a nail.
[english is not my first language, sorry]
Side Note: Congratulation for your “crazy at work” book, it’s great. If I can suggest you to come in France, 90% of the book is already implemented in our labour code, with even more payed leaves 😉
I fully agree with you, and I’m also wondering how you deal with APIs/datasets? Do your designers just build placeholders for that content and a programmer plugs it in? Or do they know how to work with those technologies?
Much of our designs/workflows are unfortunately dictated by the limitations of our APIs. How does that fit into your designer’s workflow?
I’m excited to hear others share my feelings towards the complexity of SPAs. Here’s the thing: I love challenging myself with code and learning new tools. But every now and then when working with a modern JS toolset I think, “This feels ridiculously involved compared to server side rendering and a bit of jQuery.”
I’ve learned from experience not to talk about jQuery in front of React devs or Vanilla purists though: it’s basically invoking the name Voldemort 😅
I love Vue and React, but I don’t feel like the user gets a whole lot of extra value from me sinking time into client-side rendering.
I was really glad to read this article!
I come from a creative background (photography and design) and I’ve always had a passion for coding, so in the last couple of years, I started learning frontend technologies and working as a frontend dev.
In my practice, I take care of both the design and coding of my websites, and this often takes an enormous amount of time (because of clients expectations and other factors as well).
For this reason, often I find extremely hard to learn everything I need about new technologies and this makes me feel kind of stupid. Like if what I know and what I can do is never enough for the current state of things.
To me, sometimes it seems like if there’s still a huge fight between technologies, frameworks, etc. to the detriment of the actual function and aesthetics of websites, web apps, and online projects in general.
And again, thanks for the article!
I agree most parts of your article with the part that it shouldn’t be hard to learn new things and it shouldn’t be to keep up with the ever-changing web techs. My biggest problem and that Chris’ article mentioned is when companies hiring for help. The problem Chris pointed out was that all of the job postings out there expecting UX-ers to like REALLY good at UX and a list of nonsense JS frameworks are just unreasonable or expect a UX person to pass a programming algorithm test. Ever heard of: “Jack of trades, master of none”? If you want help with UX, don’t scare off your potential UXers (whom probably don’t have a problem picking up whatever it needs to be done) by listing a bunch of unnecessary shit. Just list out the actual expectations of: “We’re hiring UX, nice-to-haves: JS frameworks knowledge etc…” Hell, I will apply for any job in a heartbeat that says stuff like “Don’t know ___ framework? We’ll teach you!” because that excites the shit out of me and I know it WILL be a great place to work.
I, for one, am one of those “designers”/UX person who will pick up “too-hard-to-learn” to get my job done. I didn’t know jacks about Python Django, a year later, I learn enough to get by thanks to my awesome Team Lead who is patient enough to teach me. But to be honest, I don’t enjoy it as much as making UX works. But in order to make things work the way I want, I had to learn them and make it a pleasure to learn it. Python is fun to learn after all. But in fact, I will struggle. I am no programmer, and I am honest about it. But if you want me to revamp the site and make it user-friendly, I am the happiest person alive, but I’ll ask for help when it becomes a bit too much programming wise. So in that aspect, where I work aligns with Basecamp as well.
So really, in fact, us UXers don’t have a problem learning new stuff but the biggest difference is obviously we don’t enjoy doing programming, just like programmers hate dealing with HTML/CSS (everyone thinks it easy until they need to do semantic markups and pass accessibility tests while keep your css readable and without a bunch of !important).
Unfortunately I have the pleasure of working with designers who have no experience with frameworks, no idea about basic HTML, CSS or JS. It’s just a pain explaining them their same mistakes over and over again. If someone calls him/herself a web designer than this person should know at least the basics. The worst is if print designers think they can design for web as well. Stick to what you are good at and if you are thinking about designing for the web please learn the basics first.
Ah, so refreshing…
There is a dying breed of HTML/CSS spartans who used to wrangle the browser stack and subsequently learn how semantic HTML should be written AND how CSS actually works.
Unfortunately, this breed is quite scarce today. The modern “web designer” is using GUI/software tools to showcase clickable prototypes. Whereas I think, “What a waste of time. Just code that shit up and make it real.” Let’s own our craft.
To your point though – the need for designers of the web to learn JS is becoming increasingly evident. I rarely hire designers and/or front-end folks who cannot demonstrate basic JavasScript competency. That’s like hiring an architect who knows nothing about engineering principles.
Call me a purist, but I believe true web designers should command HTML/CSS and have enough JS chops to hold basic DOM/OO conversation.
I love that you still write about these legacy topics!! Keep em coming 🙂