3.2 Design System - 其他注意事项

一个人厉害永远比不上一群人厉害
某次跟同事闲聊时谈到这件事 我们一致认同在一个团队里 大家都是互相学习的
所以如果你发现别人某方面不擅长 可以主动提供那方面的资源
当彼此因为这样互相督促而成长 合作也会越来越顺利跟轻松

因为尚未实际产出一套正式的设计系统，这边只能就前人文章搜集归纳出制作时应该注意的事情

当我们大致对於一套设计系统应该有哪些项目、也决定要开始做的话
当然最重要的就是团队（人）
一个制作设计系统的团队要有哪些组成呢？
原子设计 这本书
大致将团队分成 makers,users，两组皆有设计与技术人员，makers 多了管理人员

当定好团队组成後，最重要的就是团队共识了！
可以用 Workshop 的方式去进行并在工作坊内至少了解下面几件事：

1. 团队每个成员擅长的地方、可贡献的时间
2. 不同职位的人在作为 users 或 makers 角色时，对於设计系统有什麽样的期待、平常工作是如何使用的(ex: QA 跟 RDs 怎麽看设计系统的文件，他们会需要哪些资讯)
3. 怎麽分工？谁负责制作元件、谁负责更新文件、谁负责做决策该项目是否完成且可更新至产品与文件、谁负责开发或测试
4. 审核的流程会是如何？要怎麽判断哪些项目该更新至设计系统、哪些该淘汰掉(ex:不符合时下的互动方式、用户反馈负面居多)
5. 当设计系统更新时，该如何让用户知道并了解如何使用？

把这件事当作一个专案来管理，不论是用 Jira, Trello, Asana 或 Notion 都好，让大家都能了解目前整个专案的走向，每周一次会议了解彼此的进度会比较好

小故事

在一个团队内，大家都有各自擅长的地方，可以好好利用这点帮助彼此成长、没有谁特别厉害
之前曾在一个活动听见旁边一群厉害的 UX 谈论当时很流行的 Daily UI 挑战
内容大概是觉得一窝蜂做这件事在训练 UX 逻辑思考上帮助不大
其实之前我也曾想试试，但比起单一画面，我更想做一连串的流程、一个完整的产品
所以当时还把所有主题搜集起来，画树状图看看有哪些画面可以串成一个 App
做单一画面或许对流程的逻辑思考帮助不大，但至少可以训练设计师的美感跟了解每一个不同的画面应该要有哪些资讯跟功能，况且要全部做出来的毅力跟坚持也不是一般人能有的(就像这个 30 天写文挑战一样，痛苦跟喜悦参半啊！)，所以不要小看自己做的每件小事，每件事都有它的意义，变强後也要记得不拿自己擅长的地方去轻视别人不擅长的地方，大家都是为了更强而努力过来的

我很常默默希望 RD 也能多了解 UX，可以避免掉很多「花了很多时间开发却做出用户不会用的东西」的情况
当然反过来思考，RD 们也会希望 设计师或 PM 多了解技术，避免天马行空梦很大、时间很少、开发难度却很高的情况发生，所以我会时常提醒自己不用拿框框限制自己、多多了解技术面的。

p.s.原子设计真的要看看，是本很棒的书，不管你是设计人或技术人，都会很有帮助的

Day 28 End