「デザインシステムを学ぶ 31 日」の 1 日目。
1人design system advent calender を見てやる気が湧いたから、「デザインシステムを学ぶ 31 日」という連載をやる。記事は毎日 17:00 毎日 17:00 以降に投稿予定。
個人・チームともにデザインシステムの必要性を感じていた。ガイドラインなどのドキュメントだけでは一貫したデザインを保ちづらいため、デザインとコードをより近づけるための仕組みがほしい。
まわりには同じ意見を持つ人もいて、そのためデザインシステムは一部進みつつある。しかし、自分でデザインシステムの全体像を把握できていないので、システムを完成させるまでの道のりで自分（または自分たち）が今どの地点にいるかわかっていない。今回の連載を通して、残りの作業を明確にし、今後のデザインのシステム化をスムーズに進めたい。
連載のゴール
個人のデザインのシステムはメリットが薄いと思うけど、練習を兼ねてつくる。
- 学びながら個人（ @namikuguri ）のデザインのシステムをつくる
- デザインのシステムについて学んだことをひとつにまとめる
連載前に感じるデザインシステムのメリット・デメリット
今感じているデザインシステムのメリット・デメリットをまとめる。一通り学んだあと、考えが変わった点はないか振り返る。もしかしたら学び終えたあと、デザインシステムは運用が大変だからいらない、となってるかもしれない。
- メリット
- 一貫性のあるデザインをユーザーに提供できる
- 一貫性のあるデザインはデザインをつくりやすい
- デザインをまとめることでエンジニアとのコミュニケーションコストを下げる
- デメリット
- 最初の仕組みづくりに時間がかかる
- 本当に使えるシステムをつくるには触れる範囲が広く、デザイナーだけではおそらくつくれないので人手が必要
- つくったシステムの保守・運用にコストがかかる
