Adam Silver

How to write a single form label that works everywhere | Adam Silver posted on the topic | LinkedIn UI/UX tip: write form labels that make sense in all contexts. For example, let’s imagine you need to ask the user to provide a reason for rejecting an application. You could use different labels in different contexts, for example: → “Tell us why you are rejecting the application” when entering a reason for the first time → “Reason for rejecting the application” when checking your answers → “Update why you are rejecting the application” when updating the reason But this is inconsistent, more work and most importantly completely unnecessary. Instead write a single label that works everywhere, for example: “Reason for rejecting the application” Takeaway: A good form label is both clear and consistent regardless of the context.

Here's that link to the post about labelling form fields:

www.linkedin.com/feed/update...

I think the content works a lot better with the radios.

But I get it - with checkboxes it takes up less space and may feel less overwhelming at first glance.

What do you think?

I try to avoid legends like "Receive notifications for:" because ideally the label should stand alone (will link to another post about why in the comments).

So I’ve gone for “Which notifications do you want to receive?” but it’s wordy and doesn’t add much.

But I want to point out a few details and things I’m considering as I design:

“Email notification settings” makes a good h1 heading but it’s not ideal to describe the group of checkboxes.

Yesterday, I asked you about checkboxes vs radios for a settings page.

It got a lot of comments but I want to highlight this one:

> The content is key for the checkboxes. The checkboxes need a separate legend - something like ‘Receive when:’

I agree...

the radios are defaulted.

the default is all off. So there's no empty state.

Yeah, that's a good point and you've reminded me about the problem with checkboxes needing a clearer legend (heading).

But I don't like it when the legend (heading) has to be read in combination with the labels below though.

Perhaps it's possible to have another that's clearer.

Yeah I can see that argument, there's just less to look at.

But I worry that that's choosing brevity over clarity, even if minor.

Not sure though.

p.s. I totally understand if your answer is "The radio buttons worked well, no need to test the checkboxes unless you have literally no other work to do which is probably not the case"

But we didn’t test the checkbox variant.

So thought I’d ask you what you think.

This is because the labels explicitly state what the user is doing. We thought that users have to work a little bit harder to understand that the checkboxes because the labels are just the notification type.

We did a round of usability testing and the radio buttons tested great.

UX question: here are two designs to manage notifications.

Variant 1: radio buttons
Variant 2: checkboxes

In a service I worked on we explored both but went with the radio buttons.

Here’s the full post:

“Why designing in code makes you a better designer”

adamsilver.io/blog/why-de...

The fix isn't to learn design theory. It's to learn the material:

HTML, CSS, JavaScript, accessibility and even HTTP.

Yesterday, I sent a newsletter about this to 10,194 designers, content designers and frontend developers.

If you missed it, I’ll pop a link below in the comments.

> It's very impressive that you can teach a bear to ride a bicycle. But that's not what bears are supposed to do. And that bear will never actually be good at it.

I spent years building bicycle bear websites as a frontend dev. The results were always complex and fragile.

- They break the back button causing users to get stuck
- They replace native controls with custom ones that are harder to use and inaccessible

Frank Chimero says that when you do this you create “bicycle bear websites”:

Frank Chimero famously said that like wood, the web has a grain.

You can go with the grain.

Or you can go against it.

Many designers go against the grain, often without realising it.

- They use scroll jacking and break a basic interaction with something confusing

Form Design Mastery - With Adam Silver Eliminate friction and increase conversion even for complex, supersized form flows

If you’re a UI/UX designer and want to learn research-proven form patterns that actually work (even if you’re working on highly complex, supersized forms):

formdesignmastery.com

I ask my Form Design Mastery students for feedback after every module.

It helps iterate and improve the course.

Here’s some feedback I received yesterday from module 1, Nailing the basics:

“I loved how all the rules and laws just made sense [...]”

This is the hardest one to fix because you have to throw away what you have.

And usually by the time the organisation realises, a huge amount of time and money has been spent.

And the stakeholders are understandably worried that the same thing will happen again with a new tech stack.

This is not just about UX, it's about cost of delivery.

When devs and designers spend all their time trying to crowbar a fundamentally broken system into shape - wrestling with it just to get the basics right - the cost to the business is huge. And it stops you from working on deeper problems.

But usually the styles are still off and you can tell it's a cheap imitation.

And usually behaviour and accessibility go out the window.

99% of the time the best thing to do is to rip up what you have and start again with a good tech stack/architecture.

→ Reason 3: The production tech stack/architecture doesn't allow the design system components to be used as intended.

For example, the tech stack is so locked down that devs are left with just trying to make it *look* approximately like the design system *styles*.

Thirdly, even if it is, it would be good to know why and in what context and feed that back to the design system team.

It also costs more to design, test and build.

And lastly:

This is bad for a few reasons:

Firstly, the designer is putting their needs first. Ironic because the job of the designer is to put their users first.

Secondly, it risks UX. Because it's unlikely their own pattern is better than the design system's.

The thing is, it's not just the designer, it's everyone at the organisation building something. If nobody in the team knows the design system exists, that's a problem.

But this isn't the most common reason...

→ Reason 2: The designer is bored and wants to do their own thing.

That's a worry because either the designer didn't bother trying to find out if one exists. Or if they did then they couldn't find it.

Many designers don't use their design system (even if it has a good solution to their problem).

Here are the reasons I've experienced:

→ Reason 1: The designer doesn't know the design system exists.

By that I mean, are there a million extra DIVs and SPANs with loads of meaningless class names?

Respond below in the comments.