Adam Silver
adamsilverhq.bsky.social
Adam Silver
@adamsilverhq.bsky.social
380 followers 29 following 430 posts
Designer with engineering background. I talk about designing products that are intuitive, accessible and delightful to use. Design newsletter: https://adamsilver.io/newsletter Good Design Crash Course (free): https://adamsilver.io/gdcc
Posts Media Videos Starter Packs
Pinned
Yo I’m new here so let me introduce myself...

I’m Adam Silver and I’m a designer (and former frontend engineer).

I talk about how to design products that are effortless to use (for everyone).

If you fancy it, here’s my backstory:

adamsilver.io/bio/
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.
→ “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
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:
What you see should match what you hear!

But worse than that:

All of this is completely avoidable if you just lose the acronym.

Accessibility shouldn’t be an after thought.

It should be part of your entire entire thought process.
(1) It only improves UX for non-sighted screen reader users. Everyone else has to stop and work out what “IMPL” means.

(2) Sighted screen reader users hear “Implementation (deploying to production)” but see “IMPL”. That can be confusing and slows users down.
So you add visually-hidden text:

<span class="visually-hidden">Implementation (deploying to production)</span>

Now screen readers will hear ‘Implementation (deploying to production)“.

Much better, right?

Well, no.

Here’s why:
Accessibility tip: visually hidden content isn’t always accessible, even in screen readers.

For example, let’s say you have a table with a column that shows acronyms.

You say to yourself “that’s not accessible, because screen reader users will hear “I. M. P. L.”
But the key takeaway is that prototyping changes how you think about design. Because it forces you to embrace the right constraints.
6. Nudges designers to use the standard components in the Design System and learn how they can and cannot flex.

7. Easier to keep up to date, and reuse patterns/components. Code is usually more powerful that way.

But there is one downside:

You need to learn it.
...keyboard, mobile, etc.

4. It’s easier to show how something really works to designers, content designers, PMs, and developers. No need to imagine and make incorrect assumptions.

5. Nudges designers to think of the important stuff (a11y, responsiveness, real data, long data, short data, no data)
2. Testing with something that behaves like the real thing gives drastically better user feedback.

3. Further to (2) this is because users don't interact with pictures of software. And they don't use your UI in the same way. Some use small screens, big screens, screen readers...
Just in a workshop discussing the pros and cons of using the GOV Prototype Kit over something like Figma.

Here’s the advantages:

1. Once you know the basics, you can build and iterate much quicker than in Figma - especially for complex journeys.
→ ‘use a tooltip’

If a hint is useful, why hide it behind a hard-to-use, inaccessible interaction?

→ ‘for a cleaner design’

Design is about clarity, not cleanliness.

I think we designers are going to survive just fine without AI.

What do you reckon?
I asked ChatGPT “How do you add hint text to radio buttons?"

It suggested:

“If you want the hint to appear when the user hovers on the radio button, use a tooltip for a cleaner design”

Let’s break this down:

→ ‘If you want’

Design is not about what you want. It’s about what users need.
p.s. illustration taken from Remix
Enterprise products are often prone to spinnageddon.

This is where each component “loads itself” async with a spinner.

This is a slow, inaccessible experience that's totally unnecessary.

Instead, render on the server.

You’ll get the standard, accessible, browser loading indicator for free.
1. It’s accessible (so it works for everyone)
2. It’s obvious (so you don’t have to think)
3. It puts users in control (so we don't restrict users)
4. It’s lightweight (so you don’t spend time looking at loading spinners)

If you’re keen, you can get it for free at the link below:
Over 1,500 UI/UX designers have watched the Good Design Crash Course.

In the course, I explain what design actually is (hint: it’s not just about aesthetics).

And I reveal the 4 principles I use every day as a designer to make sure that what I design is actually good.

That is:
Yesterday, I ran a live design feedback session for my Form Design Mastery members.

First thing I did – on camera remember – was take a sip of water.

But I missed my mouth and it spilt all down my grey t-shirt.

I might do that again in future.

It’s a great ice-breaker.
UI/UX designers and frontend devs — what’s your go-to input mask library?
But it does show you that users don’t care half as much about pixels as most designers do.

This is why you should spend less time pushing pixels, and more time solving deeper problems that actually cause problems for users.