スタートアップのデザインチームにフィットするミニマムデザインシステム
こんにちは。akippaでデザイナーをしている横山です。
今回はakippaのデザインシステム(※ミニマム)の構築を行なった話をしようと思います。
皆さんはデザインシステムを何のために導入すべきと考えているでしょうか？
複数人のチームで効率よく作業するため？
誰が作っても一定のクオリティを担保するため？
サービスの一貫性を担保しユーザーの学習コストを抑えるため？
確かにデザインシステムには様々なメリットがあります。
その旨み全て享受したい(願望)。
実は過去にもデザインデータのリファクタリングを行ないデザインシステムを整備しようと試みたことがあるのですが、環境が目まぐるしく変わるスタートアップでは、定義したコンポーネントやトークンのうち半分ぐらいしか活用されぬまま、結局デザインが全リニューアルになったりと日の目をみないデザインデータ君たちを何度も見送ってきました。
そこでスタートアップの3名のデザインチームには一体どんなデザインシステムが適しているのか、果たしてどうやったら我々は幸せになるのか。
そんな思考の果てに生まれてきた「ぼくのかんがえたさいきょう(=最小)のデザインシステム」をお披露目したいと思います。
現状
そもそもデザインシステムの構築の必要性はあるのでしょうか。
ここでとある1日の私をご覧ください。
「アプリに新しい機能を一つ増やすで！このページのここらへんに導線を追加したら良さそやな〜ほな早速試して検討してみよか。」
「まず、必要なページのキャプチャをパターン別に撮って・・」
「キャプチャ画像をサイズ確認しながらFigmaに貼り付けて・・」
「画像をトレースして、文字とか色とか余白とか諸々の数値を拾って・・」
「あれ、なんか似ているけどここって違うコンポーネントorトークンなん・・？え、わからん、他の類似ページみよか・・。え、さらにわからん。過去のデザインデータ探すか・・・。え、さらにわか(以下略)」
〜数刻後〜
「よぉし、現状の調査と再現終了！ここから新しい導線をどう追加するか考えよ！あれ、そもそも最初何試したいと思ってたんやっけ。もう一回要件見に行こ。」
盛っていません、本当にある怖い話です。
対象ページが多い時は現状調査&再現で体力ゲージが尽きます。
課題
なんでこんなことが起こっているのでしょうか。
結論から言うとデザインデータが正しく管理されていないからです。
はい、深い反省と共にお送りしております。
でも正しく管理するってどういうことでしょうか？
ものすごーく大雑把に言うならばこの2点が担保されている状態と言えるでしょうか。
サービスの公開内容とデザインデータが差分なく完全一致していること
最新のトークンやコンポーネントが管理されデザインデータと紐づいていること
ではこれらを担保するためにはどんなことをする必要があるのでしょうか？
実装時にデザインとの差分が発生すればデザインデータ上にも再現する
リリースタイミングを管理した上でマスターへの切り戻しを徹底する
実装値のみを更新するタスクでもデザインデータを漏れなく更新する
コンポーネントやトークンを保守し、リンク切れを起こさないようにし必要に応じてリファクタリングを行う
これらを行う手間とデザインシステムを保守運用する手間の天秤は、サービスの規模に依存するところだと思います。そこで我がakippaデザインチームの幸せな未来のために要件を整理してみます。
要件
要件というと堅苦しい感じがしますが、要するに私が感じている嫌なこと一覧とも言います。
現状の調査と再現が必要で、作業効率が悪いのを解消したい
網羅性がないため、考慮漏れが発生する可能性を解消したい
過去データを探し出して活用するのに労力かかるので、手軽に使えるようにしたい
トークンやコンポーネントが明文化されておらず属人的なので、迷わないためのルールを決めたいが机上の空論にならない内容が良い
エンジニアとのコミュニケーションがスムーズでなくなるので、実装値との乖離を防ぎたい
作った後に立ち消えては意味がないので、日々の業務効率を著しく損なわない運用ルールが良い
仕様
これを元に、デザイナーチームで相談を行いつつ、仕様を考えます。
[1.2の解決策]全画面のデザインデータを作る
やるしかありません。そう、やるしかありません。
[3の解決策]デザインデータをFIgmaに移行する
過去に制作した諸々データをFigmaに移行してリファクタリングしました。
デザインチームのツールをXDからFigmaに移行することが決まっており、下記の点でも移行メリットがありました。
一つのファイル内で複数ページ管理ができ、同ファイル内にMasterページを作ることで切り戻しのハードルが下がった
オートレイアウトでメンテナンス性が高まった
カラートークンを管理できダークモードの制作コストが激減した
ちなみにXD→Figmaの移行はSVGの読み込みで見た目上は瞬殺のように見えるのですが、フレームの概念がないこと/テキストが分割されてしまうこと/画像が移行できないこと/アピアランスが分割されてしまうこと、などなど細かい問題があったため、今回は結果的にほぼ1から作り直すような形で作業を行いました。
[4の解決策]共通コンポーネントやトークンは最小限にする
環境の変化が激しい現フェーズで、チームに真に必要とされるデザインシステムとなるためには、堅牢さよりも柔軟さが重要です。
そこであえてコンポーネントやトークンは最小限にし大胆な検証にも耐えうるシステムを目指しました。
[構造]
・プラットフォームをまたぐakippa全体の共通ルールはカラートークンのみ
・スタイル/コンポーネントは各ブラットフォーム毎に定義
[定義したもの]
・スタイル
-フォントファミリ
-スペーシング基準値
・コンポーネント
-バー類
-スイッチボタン類
-ダイアログ類
[5の解決策]実装値に寄せる
エンジニアとのコミュニケーションの円滑さを優先し、トレードオフの判断が必要な場合は、見た目通りのデザインデータにすることよりも実装値に寄せることを優先することにしました。
特に今回悩んだのは和文/欧文のテキストスタイルの持たせ方です。実装値では「システムフォント/14pt」となっているものをデザインファイル上で表現しようとなるとフォントファミリもサイズも和文/欧文で別々に当てる必要がありました。
業務効率とのトレードオフをチームで議論し、現フェーズではこの正確性を追求しないという判断をあえて取りました。
[6の解決策]8割の正確性を目指す
ここまで書いてきたように、サービスの公開内容と完全一致のデザインデータを運用することは多大なコストがかかります。
そこで「デザインデータは常に8割のものである」という共通認識をチームでもって運用していこうと決めました。
残りの2割は実機確認を行う必要がありますが、その2割をデザインデータ上で完全再現する工数とのトレードオフです。
設けた運用ルールも一つだけで、「Masterへの切り戻しを行うこと」としました。
おわりに
以上akippaのミニマムデザインシステムについてリアルな実情と共に執筆してみました。
こんなにツラツラといかにも一仕事終えた風に書いたのですが、今回作成したのはドライバー様向けの予約アプリ部分でakippaが提供しているサービスの一部分を作っただけにすぎません。
上記で挙げた課題感というのは、もちろん全ての提供サービスに対して発生しているので、まだまだタスクは山積み状態です。
今回作ったデザインシステムも運用が本格的には始まってはいないので、「本番はこれから・・！」というところでしょうか。
ただ、こうやって常にその時の最適解を追い求めることで、本当の意味で「ぼくのかんがえたさいきょうのデザインシステム」が出来上がるのではないかと思っています。
このようにakippaは全てが整っている環境ではないからこそ、毎日刺激的で面白いです。
akippaに興味を持ってくださった方は、ぜひ他のメンバーの記事も覗いてみてください。
この記事が気に入ったらサポートをしてみませんか？