Consistency is often seen as a slam-dunk argument in favour of an initiative. But if you don’t know what you want to a design to be consistent with — and why — then consistency risks confusing your users. Read full article
Comment
A delightfully geeky breakdown of how a London bus stop is designed and built. It got me thinking of design systems.
What makes a good principle? How do you avoid principles that are mere motherhood and apple pie? According to Jeremy Keith, it’s all about establishing priorities.
He goes on to outline the danger of prioritising the experience of developers or designers above the user experience. He makes an interesting observation about a perceived difference in the way developers, er, develop and the way designers do.
Developer efficiency is prized above all else. Like I said, that would be absolutely fine if we’re talking about technologies that only developers are exposed to, but as soon as we’re talking about shipping those technologies over the network to end users, it’s negligent to continue to prioritise the developer experience…
I’ve been talking about developers here, but this is something that applies just as much to designers. But I feel like designers go through that priority shift fairly early in their career. At the outset, they’re eager to make their mark and prove themselves. As they grow and realise that it’s not about them, they understand that the most appropriate solution for the user is what matters, even if that’s a “boring” tried-and-tested pattern that isn’t going to wow any fellow designers.
What’s worse than design by committee? Design system by committee.
The Gov.UK Design System team have discovered that using the HTML element <input type="number"> creates some surprising problems in certain environments.
Some of the limitations in assistive technologies such as Dragon Naturally Speaking are disappointing but unsurprising.
But Chrome deciding to convert large numbers to exponential notation is rather more eyebrow-raising. Then there is Safari adding commas to long numbers that are in fact credit card numbers. You have to wonder about some of the decision-making among browser vendors.
Why a design system should not be thought of as a Thing like a style guide, but in fact is all about building a community.
I have to tell you: a lot of the time that I’m working in design systems, I’m not even touching a design tool. Or coding. Rather, it’s a lot of people-focused work: Reviewing. Advising. Organizing. Coordinating. Triaging. Educating. Supporting. That’s a lot of invisible systems work right there.
Know the magic behind Lego and how it will help you design better software
Lessons from Lego on how to create a successful modular design system.
Ethan Marcotte on the “delicate act” of working with a design system. It’s the same challenge facing anyone working with a hub and spoke structure.
How do you balance a drive to standardise designs (or business processes, or policies, or whatever), against the often legitimate requirement to meet unique local needs?
It’s easy for an organization to look at that one-off pattern as a problem of compliance, of not following the established rules. And in many cases, that might be true! But it’s also worth recognizing when a variation’s teaching you a lesson: namely, that your design system isn’t meeting the needs of the people who’re using it.
On the increasingly complex nature of design and development.
The way we build for the web right now feels problematic in so many ways. Instead of welcoming everyone from our teams with their various skills, we create layers of complexity that shut many out.
I sense this is deliberate, albeit in a subtly unconscious way. There is a culture among some in technology that seeks to belittle and exclude those who find complicated things intimidating. So development has grown in complexity over time, probably needlessly so.