If your code is good (and reviewed) it can go into production. Just because you're a designer doesn't mean you shouldn't/can't contribute to the codebase.
I agree. To me, it's just a question of how people spend their time. If designers are expected to code their designs, that isn't a good use of their time. But if they're making smaller tweaks here and there, that's fine.
Why is implementing my designs in code not a good use of my time?
I make a lot of design decisions while in code.
My perfect headers in photoshop/sketch are now too long in a browser with real data, how should I handle that?
Empty states, loading states, what if there is only 1 item does my design still look right.. etc.
Code is just a tool, same as photoshop, sketch, a sharpie, a pencil. For me it's a tool that lets me be closer to reality and gives me control to ensure that everything is consistent and the best design possible.
Plus I enjoy coding, it's fun.
Great question. Like you, I've done a ton of designing in the browser. Sometimes it is the best place to make a design decision. In my experience, this most often applies to really minor things. Flows, layout, colors, etc., are best decided and more quickly iterated on in other places (Sketch, PS, paper, etc.).
At Optimizely, we've built out a frontend framework for our product that defines common components like buttons, tabs, modals, etc. This means a lot of those really minor decisions that get made in code have already been made. Our product designers can focus on the big problems, like how those low-level components are assembled, what the user flow is, etc. This saves a lot of time for everyone, and makes the UI more consistent.
And ya, coding is fun :)
Static mockups only go so far. UX is much easier to figure out when you're creating/testing with the native medium. Coding is also nice because it gives you more time with your designs.
Code is the best tool for my design.
I agree. That's what peer reviews are for. Rolling your sleeves up and get your hands dirty in code is one of the best way to learn and understand how things work. Keeps you grounded and understand the limitations.
I've rolled out full fledge feature myself and learn many things through peer review. That gave me an idea where the limitations are and where I can push them. SVGs is one fun and good part to play around with.
I find articles like this to be kind of cute considering I'm the only product designer (until last week) and ONLY person who is HTML/CSS fluent at my company. If I didn't push to Production, our web app would look like...nothing. None of the other front-end developers are interested in learning HTML/CSS deeper (we use Jade and SASS) except for one or two who ask some good questions, and there is a frustrating lack of attention to detail with the quick HTML and CSS they do write and then pass to me.
I would love to be able to focus on just prototyping, but finding a decent UI engineer or front-end dev who cares enough about CSS is REALLY difficult.
To be fair my company is building a relatively polished app with a tiny team/budget, so I guess many of these articles apply more to larger startups/companies.
Yeah, at smaller companies this is really hard. With limited people, you need whoever you can to implement designs.
But that will leave you with really poorly architected frontend code. Lots of one off solutions, repeated code, brittle selectors, etc. For this reason, I recommend you hire a dedicated frontend specialist as soon as possible. A lot of organizations don't appreciate frontend coding as its own discipline separate from software engineering and design, but it is.
What, just because Mattan is a designer doesn't mean he can architect frontend code? Why can't he be good at both?
A person could be good at both, but they're rare. Building and maintaining a frontend system is a full time responsibility for a person or team when you're building a product that will be around for years and you have teams of engineers and designers and PMs working on it.
But if a person is doing that, they aren't doing design work.
And if you're building a personal site or a prototype, then go ahead and design and ship all the code you want.
Kind of a shame to see such a well-considered and approachable argument followed up by a totally unexplained and arbitrary caveat.
Because a person's job title has "designer" in it, they shouldn't be able to push to production? Hiring UI engineers (a decision I agree with) does not, in any way, change the impact that a designer can have in the codebase. They're independent variables.
If you can't write production-worthy code, then don't push to production.
The point isn't that designers can't write production code ever. But if they're expected to code their own designs, then that isn't a good use of your designer's time, nor will you have well architected frontend code. You should have full time UI engineers writing most of the code.
But if designers want to make smaller changes, like tweaking CSS and whatnot, then that's fine. Does that make sense?
Not addressed in the article, but alluded to: A big part of a designer's job is to be a bridge between customers and implementation engineers by providing insights to engineers that customers have expressed. Call it "manufacturing empathy" "customer discovery" "usability research" – or whatever. They are subsets of the same core task.
This task requires that the design team spends significant time out in the field with customers doing research – and only then producing design solutions. That doesn't leave a lot of time in the day for production implementation.
I agree with Jeff that a designer must have a basic understanding of software engineering in order to empathize with the implementation team, and work within their platform constraints.
Small teams are often forced to draft anyone who is able to produce production code, but it doesn't scale long term. As an org becomes larger, it's a better use of time as a designer to be a bridge.
Yep, completely agree
This all really comes down to resource though. It has very little to do with the skills of designers being good enough to write production code. If your team has loads of research experts, is it a good use of designers time to conduct the research when they could be concentrating on digesting that research and turning into something that works?
My design team works on research, visuals and often writes production code and we're lucky enough that we're in an environment we can do all of that, and still meet the deadlines that the business expects.
Agile has the concept of a specialising generalist which when you think about it from a designers point of view means you can conduct research, create designs, or write production code, all based upon what the project demands at that point.
Yeah, I agree with all of this.
These recommendations are tough because every person and every team is different, hence the backlash against my pithy claim. I meant for that to be a guideline, not a hard and fast rule, but I clearly worded it too strongly :)
I think people (myself included) tend to get very defensive when somebody says "you can't do that". It's a good discussion point though, and something my team has been debating too. Good to keep debate in the industry :)
Oh, we're still talking about this?
I always wonder how designers even find time to code. Especially in smaller companies where one or a few people are in charge of research, working with stakeholders, preparing visuals, forming the mvp and so on. If the focus is on those areas, that make up for the whole UX, there's no time left to start to write code. Especially UX is such a wide area (with each one going deep) that even trying to cover all of the UX fields is a challenge.
Such a reductive post man. You're assuming that a designer codes slower/worst than an engineer and that, like any other generalization, is a fallacy. Designers who love to code could be equal or more obsessed with highly scalable, reusable and DRY codebase than an engineer.
So don't tell me in what should I, as designer, "be an expert" or spend my time, because a good designed and coded web experience is my daily "ink trap".
You're right that it's a generalization, and not necessarily true for every person. But someone who's an expert at UX AND coding is extremely rare.
However, both design and coding are crafts, and crafts are never truly mastered. If you're writing code, then you're NOT growing as a designer.
I've jumped back and forth between design and development throughout my career, and I've learned that coding and design are very different skills that use different parts of my brain. I realized that if I want to be truly great at either skill (and I'm not great at either), I should focus on one.
You're right at that point, you can't be master of both at the same time (unless you're a exceptional human being), because "mastering" requires a lot of dedication. But that doesn't mean that you can't be excellent, great or good. And that's something. And great code, that works, is more than enough to go to production. Perfect code requires something that 99% of the times you don't have in enough quantity: time. Same goes to design.
Once you become a master (does that even happen?), I guess it doesn't require the same amount of time practicing, to keep your skills sharp, and you can go and try to mastering something else. But it's best to leave that question for the masters to answer...
What I understand is that struggle on the path to mastery (or excellence, or goodness). Right now i'm like 80/20, coding & design respectively and yes, I feel like i'm not evolving at design as much as in code, which makes total sense given the amount of the time that i'm spending practicing both "crafts". But I can't choose one. I love both. I need both. If I spend too much time coding without design i get bored and vice-versa.
Besides work, the only reason that i'm unbalancing the percentages in favor of code is because, at the time of writing, I have ideas that I cannot execute and that man, pisses me off in a much greater way than the fact that i'm not a pixel perfect design master. For me an executed idea is worth thousands of pixel-perfect possible ones that never leave your drawer.
And this is my longest reply ever... Cheers! Watch out for those binary posts.. I really like to think that life is not about 0's and 1's... but I'm often wrong so...
Well put :)
I didn't intend to be so binary, but I obviously should have put a little more thought into it.
I've done both and it's near impossible to be a master at both. How are you as a designer going to master AngularJS, ReactJS, the latest CSS techniques....in addition to that, mobile design is growing at a fast rate. You have watches, VR, car apps to start learning how to design for as well.
Half the fun of coding is pushing straight to production and testing live on the server. ;)
Good point ;)
Well said :)
These articles "designers shouldn't code" are completely bigotry and i'm sick of them. I believe it's turf-war talk. It's the same as saying "developers should not do design". Considering the roles "Web designer" and "Web developer" are basically the same these days ( look at job listings ) it's understandable the developers are getting a little defensive. However, maybe try getting your hands dirty and try to design something. Designers are a helpful bunch. If you want to learn we will help you to design.
Also I push to production all the time ;)
It's always frustrating to see dogmatic absolute, do/don't rules in article headlines, but...
This does apply to my experience. As the only designer in my company, I'm a design that is as comfortable writing scss as I am sketching, or interviewing users.
But I don't find it a good use of my time to make sure my code is optimised for maintainability, scaleability and in keeping with company coding conventions.
Not that I don't always try to do these things, but an experienced developer who works in code 100% of the time would be much placed to take on this kind of task.
Freeing up more of my time to design.
I identify with you and what you say here. What kind of place do you work at? Just curious.
Yeah when you're the only designer at a company that doesn't have UI engineers then you'll pretty much have to write code. But hopefully you can hire a full time frontend developer soon!
They’re experts in the user experience, not frontend technology.
Implying that they are and aren't.
Carter embraced the constraints of the medium and turned them to his advantage. His deep understanding of the printing process allowed him to make this leap.
I love this. Excellent analogy on the advantage of knowing how to code. Non-coders here scoff at these articles but it truly will make you a much better UI/App/Web/Interaction designer.
In my experience: 90% of the time "know your medium" is not about the web but the specific PROD system I've been working in. Often, engineers don't need to help me with the core code but with how to integrate it into our particular system.
And unlike paper, we can (and have) changed that to make it easier.
Yeah, the prod system is another constraint on design.
Just set up some coding conventions and get the designers to follow the guidelines. Use a framework and build with a clear idea of the scope while using best practices.
It feels so much more empowering to be able to build your own ideas from start to finish. I think learning how to code was one of the best things I ever did.
Yeah, this helps a ton. But building a framework takes a lot of work and requires frontend specialists to build and maintain.
Even then, a designer's time is better spent solving customer problems. If they're going to spend a week implementing a UI that a UI engineer could have done in a day, that isn't a good use of the designer's time. But for smaller implementation tasks, having a framework that enables designers and PMs and engineers to build things themselves quickly is great.
At Optimizely, we've been building out our frontend framework and it's been hugely successful at enabling everyone to build UIs, in less time, and that are more consistent.