1. Become very strong at raw CSS.
2. Learn how to use your terminal.
3. Start making "polish" PRs in whatever site / app you work on.
4. Pick up skills from engineers organically around you as you clean up the front of the frontend.
5. Learn that design is meant to move, and pick up animation!
If you really learn CSS, like becoming the best person at your company in it, you will become immensely valuable to your team. Every great coding designer I've known got there because they were frustrated their engineering team would miss details from their designs. They learned how to clean up behind them, and then next thing they knew they were delivering coded prototypes, and not designs to their feature teams. They knew static designs would fall apart, and had the stamina to work on the three issues that come up most in web design: text truncation, focus issues and media query issues.
Source. Coding designer that's been at it for 25 years. I've worked at every level of design: from grunt, to open source system-designer, to Head of Design at a public company for a 45 person design team. Gave it all up to get back in the code and hack!
Coding designers are the best! Pair them with a strong visual designer and a patient engineer and you will have an awesome product.
Side note. I've worked in dozens of front-ends over a long career. CSS is the only constant.
If you do, please don't force users to endure slow animations or slow "micro interactions", make it do what it does fast, especially if you're building applications people use professionally.
> Side note. I've worked in dozens of front-ends over a long career. CSS is the only constant.
Interested to find out more what you mean with this:
> 5. Learn that design is meant to move, and pick up animation!
I mainly work with 'Enterprise' or B2B users. My experience those users don't care about animations. They just want the fastest way from A -> B and don't get in their way.
What's your experience and with what type of users?
I get frustrated with animated interfaces on the web. It usually means my laptop fan spins up because the designer wanted to show off how cool all those CSS animation thingies are.
UI animations seen on mobile apps are better, e.g. subtle animations used in Apple's music app improve usability.
I usually try to stick to using it for making signifiers clearer, to show state changes or for feedback.
This is a good book: https://rosenfeldmedia.com/books/designing-interface-animati...
What laptop do you use?
I can pop open a web inspector and make a bunch of changes, but that's the easy part. Unlike when I'm working on my own, far simpler side projects, I can't just switch over to VS Code and paste the changes in to the requisite selectors: Assuming I have a local environment set up (no easy feat itself!), now I have to track down React components, find their stylesheets, perhaps follow some leads out to other stylesheets coming from different libraries...
It's all something I'd love to get to a point of familiarity with in my next job (which I am currently looking for!), but the upfront time investment (in part by the developer to explain the repo to me) has kept it just out of reach so far.
You could use AI tools to emulate a co-worker putting you up to speed probably nowadays.
IIRC they called it "design engineer". Not sure where in the org structure they fell under (i.e., whether they reported to design managers or engineering managers, i think it might've been under engineering managers), but I worked with a few of them directly, and it was amazing.
I was working on the front-end of a web app, so I did quite a bit of design implementation handed to me by designers. But for some very tricky styling or just in general, occasionally, design engineers would come out to help.
In what world does the order of learning go CSS > Terminal for the "designer who codes"? In no way should that be on the list for the author's target audience.
This isn't about learning the full unix suite, it's about knowing enough to get the product you're working on running locally. Speaking from experience, I've known so many designers who were simply ineffective in their feature teams because they had no ability to even see the feature be developed locally. They all required a developer to push up a staging environement, generally later in the product build.
Designers who can actually run the software early and give feedback during this time have a leg up on those that can't.
The designer who wants to code can learn and develop locally all day long without touching terminals or package managers, or any of that boring lifeless crap that will drive them away.
If the designer who wants to code wishes to version control, they could use Github Desktop or other similar non-terminal applications. You can push and pull all day long without touching a terminal. Github Desktop is a nice, lightweight application that works well and is easy and reliabe. I use if often.
> "They all required a developer to push up a staging environement"
Oh no! How dare they!
If the developer hasn't made a staging environment, I'd be asking why not. It's not hard, and is appreciated for sending preview links to internal non-technical colleagues or clients who wish to see progress or specific features. Staging environments are a very good idea, are you suggesting they are not?
This not-entirely-hypothetical individual just started learning to code. Getting caught up with package managers isn't great, but are you expecting them to write all of the code they need from scratch? Don't professional developers use other people's work (aka libraries) to make their job easier? Why wouldn't a beginning developer also want access to those same libraries?
What's easier, writing a whole interactive animation library from scratch, or using someone else's library that implements a bunch of stuff for you? If you want to use this library, why not use some sort of software to manage it? Or is the designer-developer not allowed to use Google to find cool libraries to reduce the amount of typing distracting code into a lifeless VScode window they have to do?
Yes! Coding is not about downloading a library and hoping it prevents you needing to code.
> "writing a whole interactive animation library"
You mean all 20 lines of code needed for an animated widget? Sure... let's download a 500 line animation library and use 5% of its functionality.
Package ideology reminds me of Wordpress plugins. "Just use a plugin" works great until you're drowning in plugins and your server CPU is spiking beyond reason because the plugins don't all play nice together.
As I said, the designer who codes may be welcomed by their engineer colleagues, who provide flexible means for them to contribute and push changes. Perhaps to a certain branch or otherwise streamline the process via Github Desktop or some less intense process, or even just sFTP to a place that can be previewed for later integration once everyone is happy the code is sound.
Oh good, I was worried you actually understood what it's like to be new and not very good at programming, as we all were, when we first started out.
That you're dragging in an unrelated rant about WordPress plugins tells me all I need to understand about where you're coming from.
New coders/designers should spin less plates at once. Raw CSS animation, then JS loops, timers and manipulations. Add a one line easing function you find somewhere such as this excellent page: spicyyoghurt.com/tools/easing-functions, and this helps fulfil the "who codes" goal more than "who installs."
You're right there are libraries that will be used and useful. But don't be surprised if designer-types are not too fond of some backend-centric workflows and tools popular among programmers, Which is okay. Diversity of tools and approaches is a good thing. Aiming for minimal code sent to client is a good thing. Hope that leaves on a better note.
It's second nature for us but I've been at it since the DOS days,
No idea what "running yarn" means, and I don't intend finding out. I'm too busying with actual web development! :-)
I found it very easy to get started but very very challenging to get good.
These days you can start by learning the heck out of flexbox.
Take a design and implement all of the layout using nested divs and flexbox.
Agencies love me, but they're usually not technical enough to know any different. Early stage startups seem reluctant, and large corporations don't even give me the time of day. Very confusing position.
Am I a designer who codes, or a coder who designs?
Am I a product designer? I did an "Industrial Design" degree, so formally yes, but most people here think of product design in the digital not physical sense.
Am I an engineer? Well I don't have a "formal" engineering degree but I have worked professionally as a "Design Engineer" (in the physical product sense), and a "Software Engineer", so I would say yes.
Am I an "inventor" who can build stuff, probably.
I dislike labelling people, it puts you in a silo that can be difficult to span out of. I just wish job ads were not so prescriptive, putting up walls of what a role is.
Just do you, do what you love, what interests you, and find people you enjoy working with.
Edit: I don't mean generic "learn design" resources for people who don't know design but specifically resources meant for programmers to pick up design. Like the book "Math for Programmers" but for design. Although thanks for all the links, surely there is something good there too.
Visual design or interaction design?
Personally I'm already at a comfortable level when it comes to both coding and designing, so I'm not looking for anything in particular. But to gather a list of resources that I can share with mentees who mentioned they're interested in getting better at the design-side of things.
Those are all great, and other links are as well, so thank you everyone.
Someone else mentioned paying attention to the design elements all around - this exercise of copying designs by hand is an excellent way to start to notice those little details.
Start by opening up your design eye and paying attention to the how and why of everything you see. The design of everyday things is a good book to start opening your design eye.
The material design spec is a good resource for learning some basic design rubric.
Learn the tools that are used to design. Adobe XD is my personal choice. Build tooling inside of XD to work faster, like your own custom sticker sheet. Maybe even get practice at it by designing a design spec by hand. Material design, tailwinds, and bootstrap are all options to start from.
I absolutely LOVE Tailwind and wish I'd discovered it earlier.
2. Go to https://dribbble.com/ and look for inspiration
3. Read https://css-tricks.com/ and try to reproduce some of these things
4. Get into computer graphics in general. Mess around with https://www.shadertoy.com/results?query=&sort=popular&filter...
5. Go on a wikipedia dive from https://en.wikipedia.org/wiki/Human_factors_and_ergonomics and https://en.wikipedia.org/wiki/The_Design_of_Everyday_Things
6. Go to ai.com and ask things like "how to learn figma as a coder" and drill down to specifics
This depends on who you are designing it for.
The B2B user base I worked with for example hated material design back then.
Information density is important.
So give users a choice to change this.
It is crucial to realize that designing an app that is meant to be used by professionals is different from designing an app meant to be used by everyone.
Apps that are meant to be used by everyone need to try and lowest-common-denominator the design. It means reduced information density, less distractions, and always guiding them by the hand to do what they want to do.
Apps for professionals are meant to be used frequently, build familiarity, and provide powerful tools for those people. In those cases some friction in the design can be tolerated if the result is a powerful tool, and information density can be high because it speeds up their workflow.
> This depends on who you are designing it for.
As someone who uses fullscreen magnification, all the excessive negative space that is trendy in a lot of contemporary UX design (e.g., in Microsoft Teams) is difficult to deal with. The more space there is between everything, the harder it is to tell 'where I am' when I'm zoomed in. Higher information density is easier to navigate spatially when your visual window of context is smaller, whether that's because you're using full screen magnification or because you're physically moving closer to your monitor and concentrating.
Similarly, the more screen space is wasted on negative space in windows whose main function is to present something to me (PDF viewer, shared screen or PowerPoint window during a video call), the more I have to rely on external magnification software instead of in-app zooming or scaling, which makes everything blurry (pixelated) and ugly.
I'm yet to meet a non-designer who actually likes material design.
In my experience, this mostly entails internalizing sets of rules surrounding usage of whitespace, alignment, control grouping, functionality disclosure, and legibility among other things. For me this was older versions of the OS X Human Interface Guidelines (newer versions are ok but not as high quality, with fewer details and compromises in clarity in favor of aesthetics).
To be a coder who designs you have to learn about design which is no small feat.
But to learn to code .... well all that is ... is just learning syntax and telling the machine to carry out instructions. At minimum.
Coding can't be that hard if people like me can do it.
Everyone is good at learning different things
How would you know? We have these scenarios:
1. a coder first who learned how to design second
2. a designer first who learned how to code second
These paths are mutually exclusive, you can't experience both. How then can you judge one as being easier than the other?
How quickly do you become the thing when doing it?
Non Designer's Design Book - for higher level guidelines on design
Refactoring UI - for tactical suggestions on UIs
Some other books: Bootstrapping Design and Design for Hackers
1. Get an English Lit degree
2. Decide you want to own a home someday
3. Learn to code
4. Get a job for a small company
5. "Somebody has to do design around here, and you seem the creative type"
6. Learn to design
It's cool being a "designer who codes" when you work for a small company that needs people who can do multiple things. Always lots to do, and you get a lot of control over how your design is implemented, since you're doing a lot of it.
When I started working for larger companies, they did not know what to do with me. I kind of had to pick a well-understood path so they could fit me into the org chart. I decided to go with design, as I got sick of learning a new way to manage state every two weeks.
The only superpower it gives me is being able to translate what engineers say. Even if I know how web apps are built, I don't know how ours is built at a level where I can start wading in to arguments about it. I wouldn't do that anyway, because it's presumptuous.
(As you know, the opposite is not true: any engineer, manager, executive, or other employee feels empowered to teach a designer how to do their job better, I've noticed.)
I like to code, but I'm happy I don't have to do it for a living anymore.
Can you elaborate on step 6?
I tell people that design is a form of engineering. Like engineering, it's about finding the optimal solution given a set of requirements and constraints. Nobody believes me, but I don't really see that there is a meaningful difference beyond the tool set. The hardest thing about design is that you cannot automatically validate it, or write unit tests, or do static analysis. You have to try it out, and be willing to look stupid, then iterate on it as soon and as often as you can.
The main qualifications for being a designer are that you can imagine the process from the perspective of someone who isn't you, and that you give a shit about it being right for them. I've worked with a lot of front end developers who are good programmers, but don't give a shit about getting it right. When I did both design and development, I think that was my main advantage, and why I eventually got pretty good at it.
HTML & CSS seem a world apart from traditional programming (and computer science, etc.) and were initially much more about things that were the designer's realm--another tool for layout, format, hierarchy, etc. I remember so many frustrated PHP et al. devs who really didn't love writing HTML being thrilled when I would ask to contribute to the UI layer of a given CRUD app. I was happier doing it that way too (still am).
The ability to both design and implement the interaction layer of a website or application is a superpower and, on average, results in a higher-quality product. The current division of labor makes for weird silos and loading spinners everywhere that one layer of responsibility ends and the next begins.
Note that this is the path I took and prefer (dev who designs; designer who devs), which I suppose makes me both less-common and very biased towards it. :)
This was the problem. HTML was for a very specific idea about design and page layout but designers wanted more options then the primitives provided by HTML.
So to fix they created CSS. Then started endlessly tacking things onto CSS until it's the mess that it is today.
A well designed API happens in layers. You have pixel primitives at the bottom layer and then progressing higher and higher to textual and graphic design primitives at a top most layer. What we have in the front end world today is HTML at the bottom layer and pixels inside the canvas layer. The whole thing is duck taped together in ways that don't make sense.
I grew up in a wilderness of mirrors, constantly lied to about so many things it took years to adjust after leaving home at 17. This aspect of programming brought stability and prosperity into my life. It remains that way 40+ years later.
> “I code because I love to code.”
In my experience, that’s all that matters. If you can try a coding tutorial and find the _process_ fun, if a little irritating, you can learn to code.
Too many people suffer for a long time trying to code because “it’s cool” even though they hate it. There’s nothing better about code than any other skill, and a lot of people really struggle with it. You can probably get a pretty good sense of if coding is a good fit for you in ~4 hours on a couple udemy tutorials.
In that moment I realized that some people perceive coding to be a boring activity. They were surprised when I said I often do it in my spare time for fun.
What made you choose the software track this time around?
If you are good at coding your design work, you should say you are "a designer" rather than a "designer that code." You are an excellent designer, where your final work is the design -- the coding part is the means to your design end. People, clients, customers, and bosses will eventually realize that -- which is the icing on the cake.
Once upon a time, when I talked to potential clients or even new companies, I tended to outline what I could do all the way; some of the ideas were disruptive, putting the other person in a defensive mode.
A CEO (my boss who invested in my Startup) gave me some advice, one of the many best advice I got in life.
Instead of saying you can do all, pick the one with the highest impact and get in. Once you are in (either a new company, new client, or new group), start executing beyond what you said you do. Now that you are in, it is much easier for others to appreciate your extra abilities than when you were outside.
In my experiences of working with quite a few brilliant design-coders, who are way better than me, it is easier for coders to become designers -- understand the concepts, recognize the patterns, etc. without being anywhere near artistic.
First get a CS degree and then do whatever dev work you're most passionate about to start your career. It may or may not be web dev. It's probably not, but for sure at this phase you've learned or are pretty far into learning linux and a handful of general languages like c++, java, python, etc.
After a while you end up trying out web dev because you have projects on your plate that demand it, but it's not just frontend. You will learn to at least spaghetti your way through html/css/js, lots of web server configuration, implementation details about web browsers, and pick up nodejs or even ruby.
Then you dive into frontend where hopefully there's a designer or design team sending you figma files at least. It's at this point where you have probably already learned or are very familiar with frontend libraries like vue or react anyway but now you get to master those and maybe not just use them for complicated web apps.
The final step is learning design, which is comparatively less strict and kind of fun.
It's at this point where you can take a project all by yourself without much fuss or any surprises which is exactly what your boss and coworkers wanted all along. I'd more gladly work with a dev who knows design, than a designer who codes. The code is simply not as forgiving. Implementation details must always be first. This isn't really up to opinion. Web is hard to do correctly and the bar for the quality of work is only getting higher.
As the primary designer for a product, who can also implement the design - the amount of communication needed between design and engineering literally evaporates.
I tell my devs they can build an ugly v1 of any feature simply for the sake of speed, and I’ll go in after to clean it up and make it look consistent. they don’t need to waste time with CSS.
Design changes so often after implementation, that I don’t even keep a living design file, most changes happen directly in code. If I do need to design something as part of a pitch or meeting material I take a screen shot of the product and just modify that.
Having worked as only a designer, and then only as an engineer, I can’t express how much faster my team is when design is part of engineering.
Speed is most critical to startups, I’ve always found interviewing with startups and presenting this skill set is highly sought after when expressed properly.
My first internship was as a designer, then I freelanced for them as a dev, then when I graduated and it came time to join full-time, I was asked to pick one track or the other. :)
I feel there is a VERY small set of shops where someone who just dumps a figma in your lap is useful.
The places I’ve seen that employ figma-is-my-only-output designers have just not been the right places for that skill set… but they always wish they were.
I guess it's great in the sense of being able to "speak" designer language and developer language. I have learned from people who codes like breathing and I do hope they have learned one thing or two from me about design.
But right now I am being miserable in trying to get a job focused on coding. As I don't have any real world experience with React (nor Vue, Angular nor Svelte), I haven't landed any gig. And I suspect that the fact I don't have a CS major also doesn't make things better - at least here I feel like employers who see a CV of a graphic designer who says they can code, will say something on the lines of "bullshit! Only CS people can code!"
I am getting a few more hats back while building a little game though. There is so much going on in a game, bigger games are probably the most complex pieces of software I have encountered and it's amazing any AAA titles get released at all.
This really helped me cement my theory and approach in my learning. I’d argue that adding marketing to your toolkit would flesh you out into a pretty decent employee at most companies.
Data visualization is very much user facing and lots of opportunity to let your more designerly intuitions in visual storytelling, communication motivate you along the way.
Then gradually you start to learn more about UI programming, but also data preparation with larger and more complex datasets.
We’re a “deep-tech” early-stage startup looking for someone to join our team and lead our frontend efforts.
You can read more about the role at:
1) get a good grasp of programming basics by taking a codecademy python course
2) use copilot / chatGPT / codeium
3) build stuff better and faster than I was able to do last year
As someone who went from Photoshop -> FrontEnd WebDev -> FullstackWeb -> MobileDev… I feel inclined to say markup isn’t programming.
The engines that injest CSS and display them on screens (aka developing browsers) is programming. Otherwise it’s just intent based markup.
For example, using CSS to say <p> tag content should be green is pretty trivial. Actually programming that to display the text, in the font of choice, in the language, wrapped to the screen width, compiled to work on the device’s hardware - is programming!
Giving me a css statement
Is bul*+* easy. You did not nothing other than just give an intent to the system and be amazed at the results
Also, CSS with animations is now Turing-complete. So yeah, writing HTML/CSS is programming.
Seems they’re collecting user data without prior consent. I don’t think that’s even legal under the GDPR. Then I tried to start to read the story and couldn’t get one paragraph in:
> Read the rest of this story with a free account.
Both are more intrusive than your description (having to scroll past or close a button). One is potentially illegal. To each their own, and even so those may not bother you, but I understand how someone wouldn’t classify being forced to create an account or having data logged without recourse as minor annoyances. Certainly there are entitled complainers everywhere on the internet, but when we don’t know what someone is complaining about we shouldn’t assume that’s what someone is doing.
If I recall (may be mistaken), Medium is one of the domains that is (was?) automatically downranked on HN. Wouldn’t be surprised given the above.
First my opinion of modern design is that it is trivially easy. Modern design nowadays is simply about deciding how to layout text, colored polygons and pictures on a page. The next layer of complexity is temporal and around how the page transforms via interaction with it but this is also easy. This is largely because of the trends towards simplicity and minimalism which are very different from the complicated and ornate design styles of the past.
I mean take a look at HN or even the google main page. Both are excellent designs. Clear, clean and informative and straightforward. But, also, those designs are extremely trivial. There's not much detail and there's not much work involved in creating these sites. It's simply a matter of moving certain premade primitives into the correct position.
I mean take a look at the spacex website: https://www.spacex.com/. Looks good right? But it's also just not much work. It's basically a slide show of background images with a link to the relevant page.
It can get more complex then this when you design something like jira or gmail but ultimately even those UIs though more complex doesn't even near the complexity of programming.
That's why I'm not surprised about people like the OP who are better at "design" then coding. Yeah it makes sense because design is waay easier then coding. On the other side of the equation I've seen powerful engineers say they can't "design" and I'm literally in disbelief. Are you saying you can't imagine something like the simplistic spaceX slideshow? I don't believe it. I think a lot of engineers are just under confident about their design skills and a lot of designers are over-confident about their own skills.
At the same time I feel for the OP because front end technology has literally become over complicated over the past 2 decades. It's a mishmash of over-complexity welded together into legacy tech to make it hard for designers to be able to implement their designs. It doesn't have to be this way but that's an entirely different story.
- every image on the site fits the minimalist theme (and there are hundreds). The photos are always dark in the appropriate areas so the text is readable, and they're dynamically cropped/resized with good positioning for all breakpoints.
- the front page appears to be simple, but if you click through the site there are actually a ton of dynamic illustrations and charts like this: https://www.spacex.com/human-spaceflight/
The key thing is that the aesthetic is executed consistently and with restraint. This video is a bit old now but it's as true now as it's ever been: https://www.youtube.com/watch?v=EUXnJraKM3k
Minimalism is the most difficult aesthetic to pull off, because it's easy for the end result to look unfinished, cheap or lazy.
I think the problem is not that coders can't be designers, but that coders generally don't really care about design, and I say that as a coder. If you gave the spacex project to the average coder, you'll probably end up with something like sap.com or fortinet.com
Web design has converged a lot in the last 20 years because people don't want to learn a new UI for every website they visit. This makes good web design harder, because now if you want to create something memorable and distinctive, you'll need to do it in spite of the navigation and functional parts looking identical to every other site.
Every point you mentioned is trivial to meet imo.
People are looking at something and not realizing how trivial it is. It's a sham. It's like the mother who secretly had her kid paint random shit then she started secretly selling the blobs of paint as modern art and showing that the entire industry was just empty snobbery. True story.
Personally, I've looked at the divide and stepped over it and did it. My "designs" are on par with someone with "design" training.
In fact my skills are often superior as i can produce graphics beyond what they use in flat design.
It's just a bunch of almost instinct based decisions that requires no specific skills, application of difficult principles beyond some very obvious, almost tautological truths (things people use more often should be more visible/accessible, the eye should not be strained/forced to move too much, etc.)
Basically you design stuff the way it's expected ..you don't design road and road patterns that much differently or you will cause confusion and accidents. Same goes for web or app design..use and stick to design patterns everyone is familiar with.
Design overall is easy I think if stick with all that in mind as well work hard to keep it so simple (k.I.s.s. Keep it simple stupid).
If it's a new product and or experience you are designing you still use design patterns people are familiar with.
Nowadays people find minimalist designs more attractive so it's not just UX, but even the aesthetics have been cut down to pure simplistic geometry. So to make things look good "aesthetically in terms of modern design" now requires very little talent.