Three Strings and a Grey Button

Most of a sign-in integration is invisible: a redirect, a callback, a token exchanged and checked. The one piece a person actually sees is the button, and it turns out to be the piece with the strictest specification. Google says what the button may say, what colour it may be, and what may sit around the logo, and it says so precisely enough that "close" is a different answer from "correct".

Three strings, and no fourth

The text on a Google sign-in button comes from a short list. Sign in with Google. Sign up with Google. Continue with Google. That is the set. Not "Log in with Google", not "Use your Google account", not "Google" on its own next to the logo.

This product uses the first two: the sign-in screen says Sign in with Google and the registration screen says Sign up with Google. Under each sits a smaller line saying which accounts it accepts — Google or Google Workspace account — because a person deciding which button to press is usually asking whether their work account counts.

Why the words are written out by hand

Here is where the specification meets ordinary engineering habit. Every provider on the sign-in screen has the same shape — Sign in with Google, Sign in with Microsoft, and so on — and the obvious move is to store the verb once and the provider name once and join them. One template, every button, no repetition.

That is exactly the move this code refuses. Each provider carries its sign-in label and its sign-up label spelled out in full. A composed string is correct on the day it is written and one refactor away from leaving the permitted set: somebody changes the shared verb to Continue, or to Log in, for good reasons on some other button, and Google's button follows it out of compliance without anybody touching Google.

Duplication is usually the thing to remove. Here it is the thing that keeps the button inside the rules.

There is a companion field with the opposite purpose: a bare name, Google, with no verb at all. Messages that mention the provider — your Google account email must be verified — use the name, never the label with words cut off it. That field exists because cutting words off the label is what broke the wording the last time the buttons changed from Continue with to Sign in with: a message built by trimming the old prefix kept trimming it from a string that no longer started with it.

Three backgrounds, and the grey one

The colour rules are just as narrow. The standard multicolour G may sit on one of three backgrounds: white, a specific near-black, or a specific neutral grey. Text is a specific dark grey. And there is no border.

What is not on that list is the thing a designer reaches for first: a button in your own brand colour with the Google logo on it. A coloured background under the standard logo is explicitly outside the guidelines. It looks more integrated and it is the one variation the specification names as wrong.

This product uses the neutral grey. The border detail is worth a sentence because it shows the guidelines and the layout pulling against each other: every other provider button on the screen has a border, which adds a pixel to its height. Removing Google's border outright would make it a pixel shorter than its neighbours. So the border is kept and painted the same grey as the background — invisible, as the rule requires, and the row of buttons still lines up.

Our palette stops at their logo

This site holds itself to a strict palette: the navy and orange of its own logo, slate neutrals, and status colours used only for a state. A build check fails on any colour outside that set in a public page.

Google's blue, red, yellow and green are outside it, and the check lets them through on purpose. A third-party mark keeps its own colours, and the sign-in buttons are listed as a place where marks are drawn whole. Recolouring another company's logo to match your brand is the same mistake as a coloured background under it, just made by a stricter designer.

The colours themselves live with the provider, not in a stylesheet: each provider entry carries its background, text and border, and the button is painted from them. Adding a provider means adding one entry with its own colours, and the button, the redirect and the callback follow from it.

Why any of this is checked

A product that asks Google for access beyond basic sign-in goes through Google's app verification, and the sign-in screen is part of what is looked at. A button that drifted out of the permitted strings or onto a coloured background is the kind of finding that delays it for a reason unrelated to anything the product does with data.

Which is the real argument for writing the strings out. The rules are small, they are easy to break by accident, and the place they get broken is not where anybody is looking.

What is in place

Three positions held on purpose

• Repetition over composition for button text. Every provider label is written out even though they share a shape, because a shared template is exactly what carries a compliant string out of compliance during a change made for some other button.
• Their mark, their colours. The product's palette is strict and it stops at a third-party logo; a Google button recoloured to match our navy would be both off-brand for Google and outside its guidelines.
• The neutral variant, not the dark one. The grey button reads as a deliberate choice beside the other providers on a light screen, without competing with the product's own primary action.

Frequently asked questions