Comment by agloe_dreams | Hacker News Reader

Comment by agloe_dreams | Hacker News Reader

Parent Full thread

Typographic documentation is for designers generally, but there is a world where this can actually help everyone. Designers should make consistent designs. By doing this Developers can create functional designs systems that have sane default behaviors. Once you can get to that point, the system serves to reduce the load from the dev, not increase.

I have created a tailwind-based design system interpretation like this in the education space at a rather large scale. Our designs and our tailwind-config comes from the same spec.

Doing this removes the engineer from thought by reducing options and possibilities. It also serves as check and balance. Paddings, font-weights, all of it are consistent. Designs that deviate from line-height, padding, weights, colors, etc are incorrect mocks and our configured values will make it obvious to the dev. Code that deviates from the spec is incorrect. This requires a good communication flow between Eng and UX but actually works in practice.

In a functioning system, it is a weight off your shoulders as you end up knowing the defaults just by looking at something.

Might I also remind you, the point of the entire backend of an app is to serve the front end. An app with amazing backend practices but fails at matching designs or specs is just a failure and is noticeable by customers.

Good points which I generally agree with, but I still think it's common to see a remarkable level of time and effort spent on typography compared to even other parts of the frontend. Not always, but surprisingly often.

Many companies have these style guides around typography. Beautiful, thoughtful, very well made things for sure, yet when some backend dev makes a typo so the custom font drops to arial or whatever, it can be days before someone notices and the ones who notice are the font nerds from marketing. Nobody else seems to mind much.

Compare that with what happens if someone misunderstands the 20 year old SQL schema and writes the wrong magic string to a table. Instant crash, everybody notices immediately. Yet database schemas for internal applications tend not to be documented in Porsche-brochure-like sites like this Sweden Sans is.

How did the typography guys get a voice so strong? Note that I don't mind it, I like to see well made things in general, but it's puzzling. It's like there is a secret society of typography nerds that have spread to all major organisations.

>Might I also remind you, the point of the entire backend of an app is to serve the front end. An app with amazing backend practices but fails at matching designs or specs is just a failure and is noticeable by customers.

Just checked my notes and it turns out that frontend is just a temporary fashion-dictated skin over the actually important features of the backend! ;-)

> How did the typography guys get a voice so strong?

In my opinion the "typography guys" don't have an especially stronger "voice" than anyone else. They just do a job once, get paid some (relatively small) amount for it, and then move on to the next project. At the biggest these projects involve a few people working for a year or two. Their entire job is about communication, sales, and sweating small design details, so it's no wonder they do a relatively good job at those.

The amount of work those "20 year old SQL schemas" take, once you include every bit of other comparable detail across a whole organization, is (at least) thousands of times bigger and more complicated. Overall the "code guys" have much more resources spent, spend a lot more time, and everyone ultimately cares a lot more about their output. They are large teams of either long-term employees or long-term contractors, whose work never really ends.

In short: Code is a sprawling mess rather than a cutely packaged self-contained thing. Unsurprisingly it's harder to make sense of at a glance.

Because visual people accomplish work by showing people the work.

Backend people accomplish work by making systems work.

For that reason you’ve seen many fonts and many working websites, but not as many people showing how they created a font or made their website work.

> but I still think it's common to see a remarkable level of time and effort spent on typography compared to even other parts of the frontend

We spend a lot more time reading body text than scrolling through menus or fiddling with radiobuttons.

Graphics design manuals predate computers. They were first used in the real world, with real physical objects like signs, and perhaps the most famous is the London Underground, whose font is pretty much synonymous with British culture at this point.

I don't think it's that puzzling. After designing the typeface, those same designers have time to sit down and write up a fancy brochure for it. Engineers on the other hand, have a long list of existing tickets, so the minute they fix the broken magic string, there's another fix to move on to and no time to write a fancy brochure about the SQL schema.

The irony, of course, is that codebases would be a lot better if developers did sit down at the end of a project and wrote high quality documentation for it. Even better if they did it while developing the codebase.

Also, this comment is especially ironic on HN where the top 10 comments on every Show HN submission will be nitpicking about the design of the website or the wording used, etc.

I find it easier to write the documentation first, mark it as "not implemented yet" and then do the code. Added benefit if people accidentally stumbles on the documentation and have suggestions before the code is written :-)

> Yet database schemas for internal applications tend not to be documented in Porsche-brochure-like sites like this Sweden Sans is. How did the typography guys get a voice so strong?

The frontend design team naturally puts more effort into the clarity and visual design of their design documents than the backend engineers do. This shouldn't be surprising.

Arial is the Rob Schneider of typefaces.

Do you have more of these?

Deuce Bigelow and The Hot Chick are in the top 20 comedies ever, and I'm tired of pretending otherwise.

News flash: technical worker thinks more resources should be diverted from non-technical matters to technical matters. Film at 11. ;-)

The people who design interfaces and the people who do branding and identity work are rarely the same people. I've done both (and was developer all over the stack for a decade,) but never at the same time. Branding and identity work is usually done by specialized agencies, and they're usually the ones who make decisions about the type stack.

What you and most other developers don't realize is that these things do actually matter— just not in ways that non-designers consciously pick up on. When looking at an individual website, most folks might not see much difference between a poorly kerned system font and a really expensive 'pro' font painstakingly hand kerned over months or years. However, when people are encountering a brand on a whole, having a uniform, polished look across media dramatically affects how it comes across, and that is hugely consequential. Think about how differently car dealership websites land than car manufacturer websites? And they're selling literally the same fucking product! A knowledgeable designer could write an essay on the difference in the two designs while a layperson would likely shrug and say "it looks... smoother I guess?"

It's really no different than performance for developers. Most people don't consciously notice the difference between a website that's really really streamlined and optimized and one that's just kind of okay... But the meh site will not inspire positive feelings about the experience. If your competitors do better, you likely won't be the one getting their business even if the customer didn't consciously reject your business because of it.

> What you and most other developers don't realize is that[...]

Generalizations like this are just so bad. My biggest beef with design/"product" folk in the tech world is this thing that many of them do, where they justify their existence as a group of people and a business function by bad-mouthing developers.

> Generalizations like this are just so bad

> this thing that many of them do

Lol. You can't just qualify a generalization with "many" to make it a non-generalization.

Before getting into design, I was a full-time back end developer for 11 years and worked in dev organizations in ops/support rules for a decade before that. The job market over the past decade had coddled developers so much, and made them so fragile and arrogant. Even intimating that my professional opinion on design is more informed than a developer's opinion on design often yields a intellectual temper tantrum.

So I could be wrong about their point because they used SQL schema as their comparison but the commenter does question typography specifically so I think this is more "why is topography so focused on?" not "why is design so focused on?". At least that's the more interesting question to me.

For example this page. First thing you see is a hero image showing their font in use. It's a pretty important element that takes up the whole screen. It's blurry and pixelated. Not the worst I've seen but definitely gives me more car dealership not car manufacturer vibes. It's a 1.3MB png that looks just as good converted to an 80KB jpeg and imo even better as a 20KB avif. If it was instead a 1.3MB jpeg or avif starting from a high quality source that thing would look crisp and super car manufacturery.

There is also a section in the page where the text goes blurry because they've included a table as an image. Or I should rather say it's both blurry and an image because they could have just included a higher res image of the table. They have plenty of other images where it looks fine. Again something that gives me car dealership vibes. Actually I would say blurry text image table is specifically a dodgy second hand car dealership level of vibe.

Now you could say that the typography page isn't user or customer facing so its not that important but I see plenty of shitty blurry images on otherwise polished looking pages all over the internet, and also if they covered images in their design system like they do typography then it wouldn't matter. They'd just be in the habit of only using high quality images and have some process in place to deliver them in appropriate formats.

So while backend vs frontend or functionality vs polish are imo boring and played out webdev topics, I am super curious as to why they care enough about inspiring positive feelings through web design to make an entire custom font, have a page of guidelines on how to use said font, but dont have the same level of care for images. And why I see this contrast enough to consider it reasonably common in the industry.

>News flash: technical worker thinks more resources should be diverted from non-technical matters to technical matters.

Good one, but that's not my point just to be clear! I think this kind of documentation tends to happen in organisations that already spend so much on enterprise licences that a team of designers doing "graphical profile" work for a year is almost a rounding error, and I don't mind that it happens at all. It's just weird that it happens to such an extent around typefaces, of all things.

Large corps pay dearly for Dell servers, kubernetes solutions from IBM, even the HR-systems are shoved to the cloud. Fortunes can be saved doing those things in-house, but the thing that happens in-house is - replacing Arial with something that looks almost like Arial.

Isn't that a litte weird? (Even if it is also wonderful) :)

Designers really like to nerd out about typefaces because it's such a minute detail that average people don't notice.

And because they like to nerd out so much about it, they put more effort into it.

Companies value their branding because it's the public face of a company. It's very visible, and if not everywhere, then certainly in a lot of places. And there are a lot of people across any large organization who might wind up having to put together printed materials that include branding elements: it can range from an assistant ordering business cards for a new hire, to a random staffer wanting to put an ad in a local high school musical's program booklet, to the team working on the organization's website.

Brand guidelines tend to seem expansive because they have to break things down in a way that's very easy for all sorts of people to adopt with minimal hassle. From what I've seen, the moment that process gets anywhere within a thousand miles of difficult, people will say "forget it" and do what they want.

Despite all that, branding doesn't really require much in the way of ongoing resource commitments from an organization. They get put together when the brand is updated, and more often than not, the entire process is often outsourced to agencies. Either way, once it's done, it's done for a while.

It's also often publicly available. You can find brand guides for all sorts of companies and organizations available online. Technical documentation is almost always internal, unless we're talking about stuff that's been open-sourced, API documentation, etc. It's also ongoing and is in constant need of updating as code gets updated. As a result, there's no need to pretty it up beyond whatever makes it accessible to your developers. The priority is on keeping it updated as best you can, within the limits of available resources. That doesn't always happen, of course.

Different audiences merit different approaches, and because one is more visible, it may give the false impression that it's of higher importance to an organization.

I agree with much of your comment, but take umbrage with:

> the point of the entire backend of an app is to serve the front end

It’s a phoney argument. Once can just as easily say “the whole point of a front end is to provide simple access to the backend, rather than doing it via APIs”.

The whole system is important.

Some backends have appalling frontends and are still popular. The opposite is also true.

I was kinda hoping that the OP would counter with that line and then I would agree and make exactly your point haha. My point was simply that the system is interdependent as opposed to the OP's take that the FE consistency doesn't matter.

>the OP's take that the FE consistency doesn't matter.

No no, FE consistency matters for sure! I really appreciate a good brand identity document, it's really nice to have.

But using Arial everywhere would also be consistent, right?

I think what he’s trying to say is that to the user of the system, the front end is the system. To a non-engineer its just an app and nobody knows or cares what end goes where.

Do you have any good recommendations for designing the design system? I’m currently in a position where our designs don’t always “fit” the spec that in theory exists. I’d like to get us on tailwind but widths and paddings and margins at times have weird divisions (I tried getting a rem to fit the px from the design and 1.24444…was close enough. It’s 1.25 and I won’t be bothered to fix it)

> Our designs and our tailwind-config comes from the same spec.

Is this the design system you created, or is this something others can use (or both)? As someone who's avoided frontend work primarily because I find CSS tedious, having a system over top of it that speaks design language sounds interesting.

Admittedly, looking at Tailwind now, looks like it's worth just trying that to start with.

Reply on news.ycombinator.com