Adam Silver

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

What did you love about this module? I loved how all the rules and laws just made sense. What could have been better? What could have been better is letting me just correct the questions I got wrong in the quiz instead of making me redo everything to see if different answers were right. For the radio button explanation, 1 wanted to see the CSS code for how we make it bigger (perhaps I understood incorrectly and there isn't any CSS to show). Based on your experience so far, would you recommend the course to a friend? (10 = definitely, 0 = absolutely not) 10 What's the reason for your answer? Every designer or person for that matter deserves to know what an easy-to-fill form looks like. This course creates empathy for those in different computer interaction situations. Ease of use in any product is fundamental in my opinion.

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.

Why do designers ignore the design system?

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.

For example, if you have a custom dropdown menu, can it be used with a keyboard and does it have the right ARIA attributes on it?

(3) Does it work without JavaScript?

Or does it create a single page application as a React monstrosity?

(4) Is it lean?

Do you use Figma Make and care about UX/accessibility?

If so I have a few questions about the code it produces:

(1) Is it semantic?

For example, does it use <button> for a button and <input> for an input.

(2) Is it accessible?

- How button labels guide users through the interface

It's not just microcopy.

It's the architecture, the flows, and how everything works together.

So if you want to be a better designer, be a better content designer.

- How information is structured so users can find what they need
- How task flows are sequenced so users don't have to think
- How errors are written so users can fix problems instead of feeling stuck
- How navigation is labelled so users know where they're going

If you want to be a better designer, be a better content designer.

Content design is just design with a bias toward the words.

And that's a good thing.

Many designers spend hours tweaking spacing, colours, and layouts.

But once you have a set of accessible components, it's content that matters most.

Content design shapes everything:

Yep, totally agree.

I am also definitely not saying "ignore users so you can make your designs all sparkly for your portfolio"

> Is that worth investigating?

Yes, I would have liked to have asked but ran out of time and it wasn't the main focus of the UR.

> Are extra keystrokes justified?

I didn’t introduce one. And my original post is not clear.

She had expected a link to search on the home page. Like she has now. But that just links to a search box, no filters, no sort, no cases etc.

> Is she actually wrong?

I wouldn’t class it as wrong.

> What's the reason?

I don't know but I guess it's because she has that at the moment.

> Is seconds the right metric?

To me it's a good indicator of her not struggling in the slightest.

She wanted the design changed even though she:

1. Found exactly what she needed
2. Used the interface perfectly
3. Completed the task in seconds

This is why user research is less about listening to what people say.

And more about seeing what they actually do.

2. Clicked "Cases" in the primary navigation.
3. Found the search box instantly.
4. Typed in the reference.
5. Found the case.

But here's what she said while doing it:

"I wasn't expecting there to be a search form here. It should be on the home page."

Focus on what users do, not what they say

UX tip: focus on what users do, not what they say

Just watched a user complete a task perfectly while complaining the whole time.

I'm redesigning a case working system. During usability testing, the researcher asked the participant to find a case by reference number.

1. She logged in.

So yes, try and go native where possible.

But remember:

Native HTML doesn’t guarantee good UX.

2. Some users will click it by mistake clearing all their answers by accident
3. Multiple submit buttons in a form make users have to stop and think

Making users think = bad UX.

And this is just one example.

The list of native components with bad UX is long.

It’s good advice because it’s a one-liner, comes for free, works everywhere and without JS.

I love the spirit of the advice because so many solutions are over-engineered.

But in the case of reset buttons:

1. Users don’t need to clear all the answers they just typed

Native HTML elements don’t guarantee good UX

I used to think native components guarantee good UX.

But I was wrong.

Last week I read a post by a frontend developer advising devs to stop using JavaScript to reset forms.

Instead he said to use the native reset button (type=reset).

So if you’d like to save yourself the time and build a highly accessible autocomplete control, here’s my deep-dive:

adamsilver.io/blog/buildi...

Honestly, this is just a tiny fraction of what it takes to design and build a highly user-friendly and accessible autocomplete.

I spent days working out all the details and testing everything across different assistive technology combinations.