よりデザイン

2017年12月3日イベントの話

「Atomic DesignとSketch Symbol」をお話させて頂きました

THE GUILDさまのクライアント向け勉強会にお声がけ頂き、「Atomic DesignとSketch Symbol」というテーマでお話させて頂きました。

せっかくなので、この記事では当日どのような内容をお話させて頂いたかについて軽く触れてみたいと思います。

当日の構成

構成は「Sketchの話→Atomic Designの話→SketchとAtomic Designの話」という流れを意識しました。そもそもSketchとAtomic Designは別軸の話ですから、それぞれの話が最後にうまくリンクする構成ができたらよいんじゃないかなと。ゲームでよく見るAルートとBルートが合流して最終ルートに向かう、みたいなイメージです。うまくできたかは……

なお、当日はディスカッションの材料とするために、オンラインで質問の投稿や質問への投票ができるsli.doというサービスを利用しました。これまではGoogle Slideのディスカッション機能を使っていたのですが、sli.doだと資料と切り離して使えるのでとても便利です。

SketchのSymbolについて

当日の参加者の中にはSketchについてあまりご存知でない方もいらっしゃる、ということを事前に伺っていたので、最初はSymbolの仕組みや特徴について、実演を交えながら紹介しました。

ここでの個人的な興味は「SketchはSymbolによって何を手に入れたのか?」という点です。
Sketchはバージョン3.7でSymbol機能が大幅にアップデートされ、さらにその後もOverridesやLibrariesなどの機能が追加されました。3.7以前は「アプリやWebのUIが描きやすい」といった程度の認識(※個人の感想です)だったツールがなぜ支持を得たのか。
そこにはSymbolに代表されるデータの構造化、コンポーネント指向、それらによってもたらされる制作フローの効率化などが影響しているのではないかなと思うのです。
そしてこれらの話はAtomic Designにも通ずるところがあるなと。

Atomic Designについて

続いてはAtomic Designについての基本的なトピックをお話させて頂きました。おなじみのAtomsなどの話に加え、原著で言及されている組織内で導入する際の動き方、Interface Inventoryの作り方、スタイルガイドとデザインシステムの運用方法などについてもご紹介しました。

読んだことがある方はご存知かと思いますが、Atomic Designそれ自体について語られている部分って、実は原著においては少ないんですよね。むしろ、組織にどう導入するかとか、作ったあとどう運用するか、みたいな話が大半です。もちろんAtomic Designはいわゆるデザインシステムの1つですから、その構成はむしろ正解と言えます。読んでて楽しい。

ちなみに……実のところ、私も正式?なAtomic Designの運用経験はありません。どちらかと言うと、Sketchのデータ整理をするためにおいしいとこ取りをしているにすぎません。後述しますがAtomic Designをうまく運用できるのはWebサイトであって、Webサービスやアプリには適用が難しいのではないのだろうか?という疑問があるからです。

Atomic Design バッドパターン

今回「Atomic Designのバッドパターンを出してほしい」というオーダーがあったので頑張って考えてみたのですが……それってどちらかと言うと「デザインシステムのバッドパターン」かな?と思ったんですよね。というわけで、ここまでお話したことの逆バージョンをバッドパターンとして紹介しました。実体験がないので想像ですが。

こうして考えてみると、デザインシステムって少人数だと作ったり運用が足かせになったりするし、大人数だと導入や運用にコストがかかるとも言えるんじゃないかなあと思います。もちろん、あったほうが良い結果が得られるとは思うのですが、組織サイズに見合ったデザインシステムを考えてみても良さそうですね。

Atomic Designを応用したSymbolの運用

そして最後はSketchとAtomic Designをからめたお話を。……の前に、今回のスライドを作りながらふと思った疑問、「そもそもAtomic Designって適切なんでしょうか?」についてお話させて頂きました。

特に「Atomsから定義していく」点には以前からひっかかりを感じていました。もちろん実装をしながらアップデートもしていくのでしょうが、何もない状態からテキストの役割やブランドカラーって定義できるのでしょうか?Webサービスやアプリの場合、初期の検証や設計の段階からプロダクトの形が必要なシーンもあったりします。Atomic Designをその段階から取り入れるには、ちょっとむずかしそうだなと。うーん、じゃあ開発に入るちょっと前くらいから定義するのか?とも考えられますが、それだと遅いような気も……?

と考えていく中で「構造を維持した状態でデザインデータが作られていれば、あとはよしなになタイミングでアップデートしていけるとよいのでは?」という思いつきが生まれました。そのあたりをこれまで考えてきた「レベル制によるSymbolの管理」と絡めてお話を。

とは言えこれも別に正解だと強く思っているわけでもなく……いまだ模索中です(Symbolの管理運用まわりの話はディスカッションでもいろいろな声を聞くことができ、私自身もとても勉強になりました)。

最後は、InVision Design System ManagerやInVision Studio、desginbetter.coのDesign Systems Handbookなどを話題に出しながら「でもデザインシステムって、本来は最終成果物と結びつかないとむずかしそうだよね」と締めくくりました。

結局のところ、Sketchも(おそらくは)InVision Studioもコードと結びつかない限りは単なるペイントツールに過ぎません。だからこそできることもあるのだとは思いますが、デザインシステムの定義が今後拡張された時に、プロセスに組み込むにはちょっとむずかしいんじゃないかなという疑問半分、楽しみ半分な気持ちです(加えて言うと「成果物とはなんぞや?」みたいな話もあると思います)。

最後に

ディスカッションに入る前のラスト2枚は、今回の勉強会で特に伝えたかった私の考えです。

自分自身がそうなのですが、それまでPhotoshopやIllustratorを使っていた人間がSketchに触れたことで「そうか、そういう考え方で作れるのか」という発見が得られたんですよね。で、それは何故かというとツール自体が持っている機能だったり方向性に触れることができたからです。つまりは、それを作った人が「こうあるべきだ」と考えた過程、ある種の思想や哲学に触れたからとも言える。もちろんデザインツールに限った話ではなく、コードや開発者用のツールにも同じことが言えると思います。このあたりは、世の中に出てきた新しい価値観のサービスに触れた時の感触と同じですね。
道具はあくまでも目的のための手段ではありますが、そのツールに触ることで初めて気付くことも多いんじゃないかと思います。これからも素敵な思想や哲学を持ったツールが出てきてほしいと思うし、自分も考え続けていこうと思いました。

……という感じのお話を1時間ほどさせて頂いた後は3〜40分ほどのディスカッションタイムでした。sli.doを活用したり、その場で新しい問いを出したりと、私自身も学びを得ることのできた素敵な時間でした。

このエントリーをはてなブックマークに追加

似ている話

2017.12.02

ジーズアカデミー DEVコースで連続講義を担当させて頂きました

2017.11.30

「シンボルの効率的な作成・運用法とエンジニア連携についての取り組み」をお話させて頂きました