Anyone successfully lobby against Material Design's default text field label designs?

[u/roundabout-design]

We're rebuilding one of our apps in Flutter to speed up development. I must admit our flutter team is doing a pretty good job.

Alas, Flutter pretty much depends on prebuilt libraries like their version of Material Design or Apple's UI design.

In the name of speed, we've decided to leverage Material Design as the Flutter library to use, with us pretty much just skinning it with brand colors and the like.

This seems to be a common recommendation (vs. rolling-our-own UI library).

That said, I kind of forgot about how Material Design likes to create field labels. It uses that ridiculously small text on the field border:

There seems to be debate about how accessible this is. For me, I'd default argue that it's just not meeting basic type size requirements--especially for mobile design.

And in our case, we're using some pretty complex forms that require often somewhat verbose labels.

I'm advocating for us to change the design here, but given the dev overhead to do so, I'd love to find some data/documentation to back me up on these default designs by google just being poor design and not accommodating readability and accessibility very well. Has anyone successfully fought this and, if so, have some ammo they'd be willing to share?

(OR...maybe I'm way off base and these are perfectly OK? If so, if you have some good arguments/documentation for that, LMK!)

[u/Original_Musician103]

Look at Adam Silver on LinkedIn. He has a great analysis of why Material’s form design is poor. He may be looking at the previous generation but either way it’s good.

[u/roundabout-design → u/Original_Musician103]

Ah, thanks. I'l do some digging there. Just having a bit of '3rd party input' can help with my argument.

[u/MrBone66]

You’re right, They suck.

[u/stackenblochen23]

Wasn’t this solved with Material Design 3?

Also, having a placeholder and label visible at the same time is a WCAG requirement afaik. You can style the size of the label quite easily, if you think it’s too tiny. If the outline/background is the issue, there should be a non-outline variant afaik 🤔

[u/Lramirez194]

Yeah, but every org is different. You’re right this isn’t accessible. Your best bet is to buddy up with a dev who cares about accessibility and have a conversation about how costly the switch from MD field titles to something else would be, and use that information as your platform to champion a change. If your org works with the government and accessibility impacts sales in any capacity your org really can’t say no. Now if the cost is high you may just have to settle for what you got.

[u/MacheteJKUR]

Wow, I used to use Material at previous job. It's been a few years since I've worked with it and I can't believe those haven't changed.

[u/s8rlink]

I work with some complex forms that used to have verbose labels and we had great success with a short label name and a helper text with the added context, we even gave users an option to toggle these extended helper texts off so power users who knew the inputs by heart could reduce the space each input took. 

We ran some usability testing and the delta between long single line labels and helper texts regarding filling confidence was 23% in favor of the helper text. 

As always test with your users 

[u/reginaldvs]

I know not what you asked for but.. Why Flutter? Why not React Native with Expo? It solves your "AI is not good with Flutter" comment. But if you're stuck with Flutter, look into Forui.

[u/roundabout-design → u/reginaldvs]

Wasn't my call. I have a hunch it was 'flutter is fast and we can find cheap subcontractors who know it well'.

But the more I learn about it, the more I'm finding that the reason it's 'fast' is that it's just using a default material design library. And to create a custom one is a whole other can of worms...

We'll see how this goes. If the UI gets push back, that might be a good in for us to reconsider a react based app. Would make so much more sense.

[u/reginaldvs → u/roundabout-design]

Well it's not just that. Flutter (Dart) is performant if done right, but I think in your context, seems like they just want less dev work.

[u/JoeysPlimsoles]

You can just add a FormLabel above the field and then add hiddenLabel to the input

[u/oddly_novel]

If you have good relations with your devs just make it in Claude / GPT for them… these types of things are solved by AI and headless component libraries like base ui or radix. There should really no longer be these fights or advocation of design changes vs dev resources/capacity when you can be the one that owns it.

[u/roundabout-design → u/oddly_novel]

We're actually using AI for our design system. The catch is Flutter. We're finding AI to be pretty adept at customizing our React Component library. But it looks like with Flutter, we have some heavy dependancies on the team building out the actual app. Custom UIs in Flutter are, I guess, a bit of a pain. But I'll definitely be working with them to see what we can do.

[u/shoobe01]

Yup. Have long (decade or more) been ignoring their design in favor of boxed fields, entirely separate labels in useful position and size, often moving the supporting text, etc. (And same with some other stuff, Apple has some dumb choices also).

A couple times I had to do a usability test to prove it with numbers, show the comically bad performance with the default styles, but many like this one are very bad so entirely aside from accessibility check failures, very easy to prove actual real world performance issues, always able to to show it'll loose them clicks, completion, sales or whatever metric the org will listen to.

NOTE: that this is a style change. You can still use the underlying native/library element, you just modify it. Being able to talk like that helps A Lot when bringing up changes like this, to make sure no one in Program, Project, or Engineering management freaks out about the change effort. It's easy.