Quick wins—Battling designer bias with design components
Last month we were getting ready for a new feature to be launched for our enterprise customers. It’s a significant change, and just before getting a final walkthrough from one of the engineers, we were eagerly prepping the red carpet. Halfway through the demo though, we saw something that spooked us. It was just a scrollbar — a windows scrollbar, which has no variant for dark backgrounds — and on our dark UI, it was sticking out like a some horrible Franken-thumb.
Why was this so unexpected to see? As designers we had a bias to think everyone is using the thing we use, which in our team (until the arrival of Annie!), was exclusively Macs. Mac scrollbars show and hide as needed, and are much more of a background element visually. Because they are normally so invisible to us, most of the time we were just adding vague scrollbar shapes to imply the container was scrollable. Not being the real styling they also weren’t the correct width, and it was forcing another small wedge between intent and execution.
There is of course a long list of designer biases (assuming everyone has their browser window at the full width and height of their device, short and concise length names and titles, perfectly placed images and profile pictures) but the scrollbar bias at least has one seemingly obvious solution — just build your own custom scrollbar, and it’ll look exactly how you want on every device and operating system. Of course! What’s not obvious about this solution though is it’s a very small superficial win, at the huge expense of something much more important. Accessibility and familiarity for the user.
There are lots of resources on how to create custom scrollbars (the above by CSS Tricks maybe the best up to date example), but they all assume people changing the default scrollbar for personal blogs or websites. Changing that default behaviour in products though, which contain unique UI and containers of all shapes and sizes, and you’re removing an anchor of familiarity. As for accessibility, each change you make is undoing years of work on native OS scrollbars, which are designed to work with different keyboard inputs, spacebars, trackpads, mouse wheels and more. Firmly in the camp of not creating custom scrollbars, we needed a way to include the real scrollbars for both operating systems in our design work.
After some digging, and through the help of a great person in a great slack group, I had the official design UI kits created by Apple and Windows. They are a fantastic resource, but for our use case we needed the components created slightly differently. After a bit of playing around, we’ve now got them as components in our design system, with added states for different scroll positions. Now whenever we design scrollable areas, we’re balancing our designer bias, and are aware of exactly how it’ll look in reality, for all our users. Bonus ball! The states are also named to help us communicate the core states of a design using scrollable areas, in a much clearer way — beginning, middle and end.
Although we create everything in Figma, we wanted this to be a little resource everyone can get quick value from. You can download them all here for Figma, Sketch and XD too. We keep things like this in the foundations part of our design system, but rename them to fit wherever makes sense in yours. It’s a small thing, but hopefully with this there’ll be no more getting spooked by scrollbars in the wild, and one less designer bias in the process.
