Hacker News Reader

Comment by snide | Hacker News Reader

I feel seen!

I'm one of these codey designers. The madness that exists in modern design teams (I used to manage a team of 50!) is insane. There's a lot of time spent on "design systems" in Figma. Very generally Figma is not the website, and the effeciency additions of building tools there is a lost cause.

Modern CSS and your JS frontend of choice is a lot quicker and more powerful for component building and general design work. There's way too much to do with media break points and tokenization there. There's a misguided group of designers that are learning a lot of esoteric Figma features that don't translate into something users will ever touch.

10 and 15 years ago designers needed to learn the code part too. Somewhere along the way we put them in a corner and made learn these prototype tools.

View on HN

I agree with this sentiment. I built and led a "Product Design Team" of about 50, and there were no mockup designers on my team. Either the designers can write some code,, or they can design directly in HTML/CSS. The mockup designers work with the team, and I encourage them to understand the limitations and power of the engineering team. I found that many designers end up short at the "mockups to impress the client" stage and are more artistic than being designers.

Any styles/CSS generated by a visual tool will always be limited to the vicinity of that particular design. But in the real world, the design of an entire website/app/platform should be a cohesive network of patterns and consistencies in the whole ecosystem - this is why understanding and designing in HTML/CSS finally makes more sense.

Yes, the standalone designers will be there, but they will always be disabled and limited unless they, at least, learn how the whole thing fits in, and their designs are just the pieces that fit elsewhere in entirely different ways.

I'm lucky to have been able to play the role of a designer, a developer, and business-sy sales pitching to customers and closing the loop by answering questions from all personas. This also did left me being more of a generalist and not a specialist.

Figma and other tools, however good they become, will always be that prototyping tool for playground before the actual work starts.

> There's way too much to do with media break points

As someone who has been handwriting HTML/CSS for literally 25-years, I'm still shocked dealing with media break points isn't easier.

It easily snowballs into you having 3 different CSS (phone/tablet/desktop).

I wish there was something akin to 'light-dark' (where you can specific a different value conditional on the environment) but would be trigger based on window size.

e.g.

  font-size: window-size(1.2em, 1em, 0.8em)

Which would translate to, if the browser window is small (phone), use 1.2em ... if browser window is large (desktop), use 0.8em

https://developer.mozilla.org/en-US/docs/Web/CSS/color_value...

If you want responsive page elements that change styling as you reflow the page, we have that now - container queries - https://developer.chrome.com/blog/css-ui-ecommerce-cq but it's still somewhat new, and nobody's existing design systems support them yet. People (myself included sometimes) still prefer using JavaScript for this stuff. It'll change over time, though. (Also I've been wishing for this for almost two decades now, so I'm glad to see it arrive!)

Edit: Though even simpler than that is the width media query, which I think you might be looking for: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/widt...

Thanks for sharing.

I've just found that approach very clunky in practice, hence my comment about it snowballs into effectively having 3 different CSS (phone/tablet/desktop) and wrapped in media width queries.

Though maybe I use it incorrectly.

I'm always open to learning something new :)

Well, I'm not sure of other syntaxes to make it simpler, but you could use a CSS variable to make it a little easier: https://developer.mozilla.org/en-US/docs/Web/CSS/var Especially if you re-use the same padding values for multiple parts of the page/site. Then you won't have to update values in 3 different places for each padding/font-size/whatever rule. Instead just set the variable for each @media width and then in your later rules, use the single variable to refer to the correct value for all breakpoints.

Also, some units cascade. So if you set the top-level or parent to a particular size, then child elements inside can inherit (or ignore) the unit. This means at a top level you can set your font-size for each @media width, and then use relative units and it will inherit down. But that only works for very small websites, because it introduces subtle bugs as you incorporate more controls from people not aware of your particular practice.

You can't use variables in the media query itself.

https://stackoverflow.com/questions/40722882/css-native-vari...

You’ll be able to one day!

https://www.w3.org/TR/mediaqueries-5/#at-ruledef-custom-medi...

I'm partial to the TailwindCSS approach where they're right next to each other like:

<div className="text-sm lg:text-lg"> Hello World </div>

I don't know how resizing defaults would work well for most cases instead of specifying what you want.

Tailwind is by far the easiest approach in my experience. You can always use custom CSS additionally if you have to, but it's rarely needed.

The closest I've come to that was using Tailwind.

    text=[1.2em] md:text=[1.0em] lg:text=[0.8em]

doesn't tailwind do this?

Tailwind doesn't to anything special here. Its just css media queries.

I am not sure if you are joking but there is whole set of techniques called fluid typography that does this (using css math functions mainly clamp) https://fluidtypography.com/ It's not a silver bullet and many people simply don't prefer it to having a few breakpoints (that includes me too).

  font-size: clamp(3.125rem, 3.464vw + 2.229rem, 5rem);

From their website, this is not easy code to maintain.

It’s not obvious how to increase/decrease the font size at a later date.

I prefer this tool: https://utopia.fyi/type/calculator

It generates step size variables and a comment linking back to the web calculator filled with your values.

Virtualization tool may help.

https://modern-fluid-typography.vercel.app/

> As someone who has been handwriting HTML/CSS for literally 25-years, I'm still shocked dealing with media break points isn't easier.

I suspect its that every new project, you deviate, whether someone implements it differently, or someone else entirely implements it, and now you have to hack your way around the chosen path.

The one insane sounding approach I've seen is to just have a UI for one screen, and another ui for another. You hide one on mobile, the other on desktop.

There's so much nuance too, if you dont specify some meta tag your media breakpoints wont even work, which you'll forget when you start a new project after spending 6 years on an already built project.

I use react native and react native web a lot and use dripsy for building design systems — it allows you to do exactly this. Define your breakpoints, and then pass an array of styles to a single style property. It’s really great

https://www.dripsy.xyz/

I'm way behind in the loop these days, but isn't it just a tiny screen (phones) and then large (Tablets and Desktops) these days? Tablets (medium) sizes are now well-sized, so you should ideally be just building for that segment of 1024-1200px width!

That should reduce the media query worry to one single breakpoint, no?

tailwind is pretty close IMO.

text-sm md:text-base lg:text-lg

Mobile: font-size: 0.875rem; /* 14px / line-height: 1.25rem; / 20px /

Tablet: font-size: 1rem; / 16px / line-height: 1.5rem; / 24px /

Desktop: font-size: 1.125rem; / 18px / line-height: 1.75rem; / 28px */

Tailwind is pretty nice for this

  <div class="sm:text-lg lg:text-sm" />

> Modern CSS and your JS frontend of choice is a lot quicker and more powerful for component building and general design work.

I'm a former designer turned programmer, and I couldn't agree more. I was recently tasked with doing some mockup images (no official designer on the team), and at the end, I realized that I could do it so much faster with code.

Ironically, while I was putting the images together (I used Affinity Photo), I remember thinking to myself "Does this thing have some sort of scripting language?".

I still think a sketchpad and a pen is the best way to generate ideas. But, when it comes to mockups, good old HTML and CSS really can't be beat.

That's how I've always worked. I create everything in HTML and CSS and enhance the design iteratively, then I hook up the data fetched from the backend. It's way faster for me this way.

> I still think a sketchpad and a pen is the best way to generate ideas.

Couldn’t agree more. When I’m not working on a design that’s been passed to me by a designer I usually “design” on paper [0] and I still think it’s the fastest way to work through my ideas. I then jump from there straight to the browser.

But this is obviously an unsustainable workflow if you work in a team.

[0] https://manuelmoreale.com/how-to-make-a-blog

True and valuable design is timeless and smooth. It requires a lot of work and collaboration, which cannot be done using Figma.

To this day, the hidden elephant in the room for professional SaaS apps is breakpoints and the experience between them, including when and why to transition.

Figma supports the hyperactive single designer, not the ambitious industry designer who works on something that has stood the test of time for many years.

Apple has changed its UI twice since 2007, while Figma designers do it almost every day. I think there is a connection.

Great product leads understand that great design doesn't mean firing up Figma every day, but paradoxically doing the opposite. Consistency over time is a human condition.

I think the issue is that people started adding “pixel perfect” fidelity to mocks.

also anecdotal but having worked with UX people at a tech unicorn I think most of them are not that useful, and also don’t know that much. It got to a point where we (we built most of the foundational pieces of the business) just elected not to rely on our UX teams’ input too much.

I feel like it’s an essential job that most do really badly and in turn makes me think of the whole profession as a meme.

The best UX designer I worked with was a hybrid of a PM and SWE. He was amazing to work with. The dozen or so others I’ve worked with knew more about “dressing and looking like a designer” than actually designing.

I wouldn’t call Figma a prototype tool. It’s pretty bad at prototyping sophisticated interactions.

They are canvas based clickable mock-ups with fancy transitions and a few more things.

But it can’t generate / export to HTML which comes in handy when you need to use it offline.

Figma puts codegen on plugins and partners. These either generate generic html or, more commonly, platform specific code.

I’ve not checked recently, but can you export an entire project retaining all interactions and run it offline like you would with a HTML based prototype?

My math is closer to 18 years.

At the time I was selling UX services, and the 'prototyping tools' of that generation were what drove me learn PHP, Ruby, and Javascript - for all the reasons you state. I was baffled by all the time and energy people spent becoming an expert in the prototyping tool rather than an expert in building for real. I declared these prototyping tools an expensive distraction and never looked back.

Agreed that in most cases all this extra work and attention to detail is essentially wasted effort that never sees the light of day.

But it’s possible to extract value from it if you have a culture where designers build prototypes, and you can use those prototypes for user testing, feedback, demos and pitches, while the code is being built. But it’s rare that companies have this culture.

Really good (and underdiscussed) point that Figma designs are not just for consumption by developers.

I know this is a cliche phrase, but when you're trying to align stakeholders (PM, manager, VP, dev lead) on a product, it is genuinely very useful to have really nice, hi-fi mockups to make sure everyone is talking about exactly the same stuff.

It's also definitely a scale thing. If you have 500 developers, it's probably worth putting in some extra sweat just to make sure they're all using the exact same button, etc

If you have 10 devs... yeah, hard to justify a super-perfectly-polished design system for every single bit of your frontend, IMO.

Hard disagree here. Are you writing production code, or are you building mockups/prototypes?

I don't want non software engineers touching production code. It's too hard, and the depth of skillset for a product/UX designer is already huge.

If you find css and js faster for prototyping and mockups, then sure. I'm doubtful and still yet to see that work in the wild.

It would actually probably be pretty helpful if the designers knew their way around the production code, since they'd have a lot more context about what is going to be easy/hard to do. They won't be in some design vacuum.

Silo-ing off code because someone isn't a "software engineer" also feels kind of funny to me.

it would be useful if anyone in the company - CEO, salesman, designers, "X department" knew their way around the production code so your statement feels funny to me. look at sports - it would be awesome if everyone on the team is a great linebacker but ...

I know you're joking but I've worked in very engineering-heavy startups where this was the case and almost everyone had to write some code, production or not.

I think teammates would have enough context of each others’ positions that they could play the part if necessary, even if theyre not as good. They might even appreciate the skills gaps. So I think sports holds.

Hard counterdisagree here. To just have a blanket rule preventing "non-software engineers" from making production changes is completely arbitrary and suggests you may be lacking a rigorous process for determining which changes are actually important and ensuring they get proper review (no matter who made them). If you had a good process there's no reason anyone at all shouldn't be able to propose changes to production code.

What makes someone a software engineer in your scenario? I myself have worked as a software engineer for about 30 years at this point and have a degree and postgrad in Jazz, contemporary and popular music[1]. My work in software has encompassed writing software where making a mistake would have very significant real-world impacts[2].

I have worked with designers who are much more capable at making certain changes to production code than some titular software engineers.

Lots of changes to production code are not hard at all. I would go so far as to say the vast majority in fact.

[1] I can't play any more due to RSI which means I am now professionally qualified to explain to you why Steely Dan is the best pop band ever and harmonize things in 5 parts in the style of Duke Ellington and not much else.

[2] eg pricing, risk and decision-making with very large amounts of money on the line and even doing data analysis in regulatory and criminal investigations.

One day I will be part of my dream team where the UI designers and the FE developers are the same people. The amount of time my current team wastes on iterating on UI design, only to then do a second round of iteration on the actual developed product is insane. And then there are always massive inconsistencies in the designs, padding, margins, corner radii and so on are rarely consistent, and the developers ALWAYS point out these consistencies.

Just Do I Right the first time, and to that final round of UI refinement directly in the UI, as part of your development SDLC. It'll save so much time money.

Been a front-end designer since I started learning/my career (2007 lol) and sorta hate having to use Figma yet it's a lot like using Photoshop so it's not too bad. Yet I almost always just design/code in the browser using the "Inspect Element," tool (take my last design project, deconstruct it as needed and then copy and paste the code into an IDE; click refresh fairly often).

I think the basecamp does the same thing. have designers who work on html / css and it shows in the beauty of their products.

Reply on news.ycombinator.com