The great thing about Twitter is that there is a lot of designers (and it's also the reasons that Twitter isn't that great sometimes, right?). However, a few days ago, this tweet appeared in my feed:
🧶Design System Twitter: how are you creating, maintaining your icons? If it’s one person, are they in-house or outsourced? If it’s a shared task across all teams, how does this work? Is it something else!? Tell me everything! RT pls 🙌🏻🙋🏼♀️— Alex ✨ (@skougs) June 14, 2019
There is a lot of nice tips and ideas in the replies, but I picked one that inspired me the most, it would be this one from Mark:
The design system switches out icons based on size too, so larger icons can include a greater level of fidelity. The only thing we ask is that icons are user tested (for comprehension) and don’t commit any A11Y sins— Mark Boyes-Smith (@markboyessmith) June 15, 2019
I wouldn't say it better, so I'll reference Refactoring UI here – Don't blow up icons that are supposed to be small and mostly this image:
A technique mentioned in Mark's tweet is basically a solution how to handle issues like this easily – designers will only choose how large icon they want to use, and design system will pick the right one from prepared icon sets. It would mean to have all icons in both variations, but that's just a small technicality (and definitely solvable).
Side projects are a vast topic for me – I just like to work on something else than on my main job. And usually, I overthink my side projects, I make them huge, and in the end, I don't launch them at all. So I decided to write down a few principles that I will use this to evaluate if I will start my next side project or not.
These principles say that my next project probably won't be focused on content creation or curation. However, I have DesignSystemsJobs currently, and it needs regular maintenance (adding new jobs, removing inactive ones).
I need to decide what to do with it - one option is to close it. But I may like it too much - and I have a strong desire to learn some machine learning. After five months, I already see some patterns in how I pick jobs that are focused on design systems. I might turn this into some script that does this manual work for me. I need to think about it a bit more and plan to decide in the next days.
I should probably mention an article Intentionally Tiny Side Projects that inspired me to do this.
Just a quick mention of one tweet, mostly for my future references when someone mentions that "it's okay to have documentation as markdown files."
What size is the subset of designers + developers who understand systematic, scale-based design but don't enjoy working in a text editor?— Colm Tuite (@colmtuite) June 6, 2019
I like this Barcamp a lot – with more than 500 people, two days full of talks and workshops and a very friendly atmosphere. (And a lot of ice cream)
I didn't know much about what will happen on my first day. I attended the IxDA workshop, where leaders of local IxDA chapters shared their experiences. That was interesting, mostly because it was great to see chapters that are in different phases – some of them were just starting, with the first meetups and early challenges. Some of them were running for years and were happy to share their best practices. In the afternoon, we had a workshop on defining maturity levels for IxDA chapters. This is something I would be maybe part of in the future again, as it promises to help any chapter with local success.
Talks, the second best thing on UX Camp Europe (after networking). My focus was mostly on design systems and design operations (a.k.a. DesignOps). There was a discussion about what everything belongs into DesignOps and this presentation is the output. Pretty comprehensive, isn't it? Yep, I am still figuring my own opinion on DesignOps; I'll share more on this topic later this year. Maybe.
The last, but not least – I talked how we explained at Kiwi.com that we need 5 people focusing only on our design system (and brought the value with it). Check my presentation slides, or if have any DM me on Twitter.