That's a lot of words. I'll counter with my own shorter list for those without the stamina.
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.
> 5. Learn that design is meant to move, and pick up animation!
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.
Same here, and I'd add that JavaScript (not TypeScript, not React, not X) has also been a constant for me.
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.
My whole career has been in enterprise software, and I've found that the actual end users like the same sorts of things you find in well-designed consumer apps, because that's what they're used to. I think when you say "UI animations seen on mobile apps are better, e.g. subtle animations used in Apple's music app improve usability." that really nails it - nobody wants overly artsy animations (in consumer or B2B software, in my experience), but subtle use of animation can make the product feel more responsive in a way that improves the user's perception of it.
Oh man how do I find someone like this. As a backend/infra dev I respect, fear and loath (in the reverse order) css. If you can find your complement(s) there is nothing like it!
I've tried to move toward this kind of arrangement in the past, but have never quite broken through. While I'm fluent in HTML/CSS, the major obstacle to actually committing code as a UX/UI designer has been the codebase itself.
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.
Not sure about today (since I don't work there anymore), but my org at Microsoft back about 5 years ago had a role that was pretty much like what this comment chain is talking about.
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.
My company is big on hiring designers who can code. We are in the humane tech / hw / AI space. My email is in my profile, feel free to reach out if interested!
There isn't any correct way to structure CSS. Even if you are the best you will still have people telling you are wrong or they don't want their styling structured how you suggest.
Or even simpler—change your career to programmer, and bring your thoughtful aesthetic sensibilities to the fore where needed and _permitted_ by your developer colleagues.
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.
Just about any application in a team is going to require you to run the application locally so you can work on it. That immediately means you need to understand how to navigate your terminal, run commands and install software through package managers. Almost always, doing so is made more difficult if you don't understand what your .bash_profile does.
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.
HTML, CSS and Javascript do not require ANY use of terminal, commands or package managers, or even knowing those things exist.
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.
An example: The designer who wants to code may decide they want to make an interactive animation. This means they are about to embark on a journey of HTML DOM, CSS, and javascript. It DOES NOT mean they are embarking on a journey of typing a bunch of distracting non-code into a lifeless terminal. Forget about that. Focus on code - HTML, CSS, JS.
> "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?
I think they are referring to "needing a developer" to push to staging, not that there wasn't a staging environment. That means the designer who codes is still blocked by available developer time, and if the developer is out that they, they what? just don't work for the day?
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?
> "...expecting them to write all of the code they need from scratch?"
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.
You didn't like my Wordpress plugin comparison!? I'll write it better. Package clutter, maintenance, integrity, updates, all those things are spinning plates. Similar to Wordpress' needy and naggy plugin ecosystem found there.
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.
I disagree but probably the level of "learn the terminal" is the source of disagreement. Coming from nothing, cd and ls do actually take a second to wrap your head around. I don't think a designer/developer necessarily needs to be able to pipe commands to each other but running yarn and hitting ^C is something every web dev should be able to do, even if it isn't second nature.
It's second nature for us but I've been at it since the DOS days,
As a "designer + developer" it's surprisingly hard to land roles where you'd be the most impactful. Hiring managers struggle to comprehend to diversity of what I can do (https://zchry.org/), and I really don't want to simplify it more than I already have.
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.
I don't mean to be negative and I'm just giving feedback incase it helps or re-enforces what you've heard/thought before -- but the moving clouds on that page give me a headache and make the page practically unreadable for me.
In the theme of other comments, I struggle to identify what I am.
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.
Anyone resources for the opposite, how to become a "coder who designs"?
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.
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.
Leave Tailwind well alone unless you enjoy individually styling every anchort tag inline over and over again. Tailwind is an abomination that has spread like cancer throughout the front-end dev space.
One helpful resource is https://www.refactoringui.com/ and related materials/blogs - but evaluate it against your inspirations to understand when the “rules” should be broken, or aren’t even rules that apply to the aesthetic you’re going for! Particularly if that aesthetic is advised by, say, luxury fashion. But it helps to understand the space of what is possible!
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.
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.
For me, a lot of it was just developing a "gut feel" for UI/UX, which enables me to play with different designs and achieve something decent through iterative tweaking (just keep poking it until it feels right).
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[0] (newer versions are ok but not as high quality, with fewer details and compromises in clarity in favor of aesthetics).
I think Figma's tutorials are a great way to start. There's something valuable about learning design as you learn how to use a design tool at the same time.
Lol, coding was the most difficult thing for me to learn. I didn’t learn design but did take a 1 month class (40 hours per week with a teacher + 20 hours of self-study). It was by far an easier month than my first programming course.
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.
I faked it until people believed I knew what I was doing. I had just finished school (and grad school), so I wasn't going back for another degree in engineering or design. I felt lucky to not be working at a deli or a call center, which had been my previous jobs. I spent a lot of nights and weekends trying to get things right, while making it look like it was easy. Eventually it did get easier, like with all skills.
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.
My hot take has always been that the emergence of the Front-End Developer role came about backwards and that the correct expectation was that designers learn to code.
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).
Javascript--especially before being engineered into its current oblivion--was fuzzier territory, but I'd advocate that it should be a shared responsibility between the designer and [back-end?] developer, meeting somewhere around accessing the API.
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. :)
I agree. For a while now, I've been working on a programming language specifically for designers. The idea is to incorporate the same verbiage and mental models that designers use in their daily lives. I think html and css are nice, but they can't be transferred over to other platforms. Designers need a platform-agnostic language.
>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.
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.
> My absolute favorite thing about writing code — and the reason I stuck with it through the initial learning curve— is that there is pretty much always a right answer when it comes to code. Your code either works or it doesn’t. This is not the case with almost anything else in life. When you write an essay, paint a picture, or design a website, you never really know if you did it “right.”
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.
If you’re a designer (or business person, or just a human) and you’re thinking about learning code…pay a LOT of attention to this sentence from the article:
> “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.
I was talking to a friend about career options the other day and said they could always learn to code. Their face screwed up. They didn’t want to do something boring like that, they said.
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.
I'm someone who is naturally strong at design, but studied CS/software engineering because I ultimately wanted to be able to build my own things. For years I tried to find careers hiring those unicorns -- people who could design and code -- but they were few and far between. My last gig that required both was at a hedge fund here in NYC, where they don't explicitly hire designers. These days I work exclusively as a software engineer, and I definitely miss those times when I worked as a designer. Among other things, the hours are easier and the amount of praise you get way higher :-)
For what it's worth, I love this story! I took the opposite approach but with the exact same logic: Code came naturally but I wanted formal training in design so that I could really embrace both sides and shape excellent products (and in particular, implement all the ideas I had from start to finish).
What made you choose the software track this time around?
I have seen good works from the author, Meagan Fisher. She is a fantastic designer.
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.
Yes, it is way better to mockup prototypes directly in HTML/CSS/JavaScript, but the output is the "design work." Be an excellent designer; you just happen to know how to code that.
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.
I think there's a simpler, but slower path that is much more successful. It seems that all the best web devs I've known took this path.
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.
I’m a designer who codes, and for those who have had trouble expressing the value and finding a role that enables both, here is how I’ve positioned it:
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.
In the past I've just called myself a full-stack designer (+/- extra words like UI/UX or developer) or some variant thereof. The hiring process isn't really aligned to finding such folks though for sure. Neither are internal progression systems at some companies.
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. :)
Designers who only design with no regard for what is possible, simple, etc have been the bane of my existence at previous employers.
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.
Then I could say I am a designer who codes. I learned by myself HTML and CSS, and eventually JavaScript, PHP and some Python (when Python 2 was still a thing!) even before beginning to study graphic design.
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 sometimes wish I could go back. I was never a designer in a pure sense, but I enjoyed a few roles of web development that had me doing both design, UX, business development ideation and the actual coding. Back when the lines between roles were blurrier, and especially when I was running a few SaaS side projects. Now I specialize in web applications and in specializing I gave up those hats.
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.
I’m currently someone who’s learning to program to get out of the trades, I have a good eye for design and I’m decent at technical engineering (I think anyway) and I’m trying to approach it as a designer first who can code second, I figured this out when learning JavaScript/Python that I won’t ever be able to breathe code like some people but then I witness the design these end-game engineers come up with and I’m absolutely floored at how bad it looks.
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.
My journey has been to start with data visualization using d3.js etc and gradually moved into much more complex tech stacks for vis & data processing.
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.
I’m a designer who codes! It’s very different today than it was ten years ago. Or even ten months ago.
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
If you want to go the extra mile, learn enough JSX to build a static version of the page. The developers will love you if you hand them components and CSS that look correct. It's less work than you might think to jump from HTML to JSX.
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
p: {
text-color: blue;
}
Is bul*+* easy. You did not nothing other than just give an intent to the system and be amazed at the results
I didn't see a Medium banner. But just curious, how did this Medium banner you mentioned hurt your experience? Did you have to scroll past it, or press a close button on a modal? We need to stop pretending that internet platforms/services should be totally free to use without minor annoyances.
I’m not the person you asked, but I did click through to check. At the top there’s a banner:
> To make Medium work, we log user data. By using Medium, you agree to our Privacy Policy, including cookie policy.
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.
I have a personal opinion about modern "design" that isn't shared by most designers or coders. You're welcome to disagree and vote me down but I just want to say this is just my opinion and I prefer to hear your disagreement in the form of a civil reply rather then an anonymous down-vote.
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.
Actually I don't think most programmers are capable of designing something like spacex.com
- 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.
the point is that you have to want to in the first place. This is kind of like looking at “the flame” or some other modern art and saying “yeah that’s easy, I could have done that.” It’s missing the point entirely.
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.
I've always thought this was the elephant in the room about design. Like yeah, you make the important text big, you put it at the top, you make a rectangle and you fiddle with the position of the rectangle, ooh those are nice looking colors, ok now maybe some borders and a drop down taskbar, etc.. Really it's not difficult at all.
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.)
Good design has always been easy and pertains to everything we touch/interact with..roads...websites..apps..showers..bathtubs..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.
Oh that's just part of it. The other part of design is the look and feel, or how attractive something is. It's a big part of it.
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.
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.