Adam Silver
@adamsilverhq.bsky.social
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
UI/UX tip: avoid interruption pages Last week, someone asked me about their interruption page. I understand why designers might be drawn to a pattern like this. I’ve been close to using one in the past. But interruption pages have multiple issues and they’re unnecessary.
Measuring whether a service is working is harder than measuring whether it's running. A thread on what performance measurement looks like when it's actually useful. 🧵
A little UX tip to improve sign-in pages with multiple options. The problem is that some users may not remember which one they used. But the fix is simple: Highlight the one you last used with a little text label. Boring UX = Good UX
Last night I ran a live training on file upload UX. It was really fun. Everyone seemed engaged. And all the questions were great. Nobody asked about animation. We focused on important details like:
“I used to think design was about making webpages look nice and wowing users with fancy animations.” This is from a full stack developer who took my course on form design.
New post: does the accept attribute on file inputs work better on Windows and Android (compared to Mac)? Last week I wrote about the problem with using the accept attribute for uploading files. In short: It disables invalid files... Disabled files = bad UX
Do web components make your design system framework agnostic? Yesterday I asked this question on LinkedIn, BlueSky and X. In short the answer is: No, but sort of. Let me explain: Web components are just HTML, CSS and JS, so they can be framework agnostic.
Can your design system components be framework agnostic? I sometimes see frontend engineers suggesting that design systems can be framework agnostic if you use web components. But I don’t get how that can be the case. Firstly, your components need to render real data.
UX tip: don’t misinterpret a WCAG recommendation as good UX Last week I posted about why the ACCEPT attribute on file inputs is bad UX. In case you don’t know, the accept attribute lets you specify which file types an input will accept (and then disable the rest).
Spent the last day writing and refining a problem statement with my content designer. All in prep for a 20 minute show and tell. Because if you can't articulate the problem it's a lot harder to justify the solution. Ideally we would have done this a bit earlier...
Here’s an example of native browser behaviour with bad UX. Last week I shared a problem with a multi-file upload pattern. The problem was about how to make sure users could deal with multiple errors across multiple files.
Here’s a tricky UX and accessibility problem I’m not sure about (perhaps you have ideas). It’s to do with a multi-file upload pattern. Note that this is the degraded version of the UI that works without JavaScript. The enhanced JS version works differently.
"How do you take design from good to great?" By doing the hard work to make it simple. Anthony Hobday gave the perfect example on the Complimentary podcast when he was describing his experience of applying for a driving license.
“Design is just stopping other designers from doing stupid sh*t.” My designer friend sent me this yesterday. She was trying to convince her team to use the standard design system components. Because they’d all strayed from the standard:
Just scheduled a newsletter “The perfect file upload pattern”. It goes out in under an hour. If you fancy it, you can sign up to my newsletter here: adamsilver.io/
I can help you design products that are ridiculously simple and accessible to use
Adam Silver – interaction designer – London, UK
adamsilver.io
In 2013 I came across a UX tip for designing mega menus. Most mega menus work on hover. So you hover and out pops a menu. But you have to move your mouse perfectly horizontally to enter the menu. Because if you don’t it disappears. That’s inefficient and unnatural.
The six signals of quality in software - according to UI/UX designer Anthony Hobday: Signal 1: Reliability → Does the software technically perform as expected, all of the time? This means no bugs, no downtime, no errors, and so on. Signal 2: Speed
Most designers use the UX term “affordance” wrong. For example, they might say: “The CTA needs better affordance” But affordance just means what something can do. A submit button affords submission. That’s it. It only describes the capability.
Design tip: don’t forget about the <title> tag The content inside that tag appears in the browser window or tab. This is important because: 1. It distinguishes your website from other open websites 2. It's the first thing announced in screen readers
Why Designing in Code Makes You a Better Designer, by @adamsilverhq.bsky.social: https://adamsilver.io/blog/why-designing-in-code-makes-you-a-better-designer/ #design #career
Why designing in code makes you a better designer
Adam Silver – interaction designer – London, UK
adamsilver.io
"Can you make single page applications accessible?" I’ll answer in a sec. But first: It’s the wrong question. Accessible doesn’t always mean good UX. SPAs change standard interactions like clicking a link and submitting a form.
Frontend devs: would you take a job with the following tech stack? The stack: • Node.js • Express (or similar) • Nunjucks templating • Progressive enhancement I keep seeing devs dismiss server-side rendered stacks in favour of React SPAs, so I wanted to get your take.
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...
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.
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
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 [...]”
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.
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?
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:
