AbemaTVの開発組織では、UIデザインツールはSketchとAbstractを使用しています。
今回は2018年11月現在での運用方法について紹介したいと思います。
Sketchは言わずと知れたUIデザインに特化したツールです。
様々なデザインツールがありますが、複数人での共同作業やバージョン管理をする際には、SketchとあわせてAbstractを導入する組織も多いのではないでしょうか。
私たちは、2017年12月にAbstractを導入する以前はGitHubやGoogleDriveでSketchデータを管理していました。
しかし、それらのツールは「デザイン作業」に特化しておらず、どうしても痒いところに手が届かない状態でした。
AbemaTVには現在6人のUIデザイナーがおり、マルチデバイスへの対応のため多くのSketchファイルを運用しています。
・モバイルアプリのiOS・Android ・テレビデバイスアプリのAppleTV・AndroidTV ・デスクトップとモバイルのWeb ・管理画面であるAdmin ・現在開発中のNewデバイスプロジェクト ・その他
基本の運用フロー
基本的にはデザイナーが作業する際は必ず
ブランチ作成 → コミット → レビュー → マージ
というフローをとっています。
6人のデザイナーの作業履歴を全て追えるようになったことだけでも画期的です。
Slackと連携しており、通知が流れてくるのでいつ誰が何をコミットしたかわかるようになっています。
（今までのデザイナーの作業はブラックボックスだったところもあるので、丸裸になりすぎて怖いくらいですね。）
AbemaTVでは開発体制がなかなかに巨大なため、リリース後3年目の現在も常に多くのアップデートが行われています。
そのため、1つの「iOS」のSketchを同時に3人のデザイナーがいじくり回すこともあります。
動画部分のUIをいじる人、検索機能のUIをいじる人、設定画面のUIをいじる人…などといったように目まぐるしくUIに変更が加えられていきます。
Abstractでもツライことはある
正直に言いますと、Abstractで完璧に管理しきれている訳ではありません。
Abstractはアートボード単位での差分管理なので、以下のような問題がおきます。
Aさんがある画面の変更を加えてマージする前に、
Bさんがその画面に触れないがその画面に含まれるSymbolを編集したときにコンフリクトする。
「今から〇〇の画面いじるから、そのSymbolいじるのちょっと待って!!」
「ｱｱｱｱｧｧ!!そのコミットっ!! こっちがマージするまで待って!!」
「あーコンフリクトしたわ。Restoreしてもこの作業はやり直しだわ。ダメだわ。あー。」
数ヶ月Abstractを使った私たちはだいぶ学びましたが、それでも↑のようなコミュニケーションはいまだに行われています。
少しアナログな方法ですが、コミュニケーションを円滑にするために
「マージする予定のない場合、ブランチ名にArchive用とつける」
といったことをしています。
例えば新機能のデザインのパターン出しをする際は、「綺麗なコミット」に気を配っても非効率なのでアーカイブする前提で作業します。そしてデザインが確定したら「清書する」イメージで新しいブランチを作るようにしています。
その清書ブランチでは、なるべく「綺麗でわかりやすいコミット」をチーム全体で心がけています。
AbemaTVのSketchファイルは「常に全画面の全モジュール、全文言が正しい」状態を目指しています。
もちろんSketchファイルは仕様書ではありません。しかし、デザインの運用が頻繁に行われる組織ではここをないがしろにしてはいけない、というポリシーのもと、なるべく綺麗な状態を維持できるように管理をしています。
そのため、Abstractのレビュー機能を使って、Sketchの使い方が正しいかどうかメンバー同士でチェックするようにしています。
ここで気をつけるポイントがあるのですが、
「デザイン自体の良し悪しの議論」は、Slackなどのオープンな場で行い、
Abstractで行われる議論はあくまでも「Sketchデータの良し悪しのレビュー」に絞っています。
また、元々はデザイナーのみが使っていましたが、最近になってディレクターやエンジニアにもAbstractを導入してもらい、Sketchデータに関するやりとりはここで完結するようにしました。
Sketchのライブラリ機能
Sketchのライブラリ機能を複数人・複数プロジェクトで使う場合、Abstractが大活躍します。
AbemaTVでは、UIに用いる「アイコン」と「カラー」に関しては
1つの「ライブラリ」ファイルが全てのプロジェクトから参照されるように設定しています。
特に変わったことはしておらず真っ当な使い方ではあるのですが、真っ当に使うようになるまでの準備が意外と腰が重かったりしますよね。
（元々ライブラリ機能が出る前からSketchファイルを作っていたので、ライブラリに差し替えるだけでもめんどくさかったり…。）
そこは効率化することに対して意欲的なメンバー（以前この記事を執筆したデザイナー）が仕切ってくれました。
運用の効率化も、やはりリーダーシップを持って進めないと実現できないものです。
ライブラリ内のアイコンを差し替えるコミットをしてマージすれば、そのライブラリがリンクされた別のSketchファイルにも反映されます。
このようにライブラリファイルではSymbol化されたアイコンが並んでいます。（画像は一部）
また、カラーもライブラリ内のレイヤースタイルで管理しており、各アイコンにはデフォルトとしてWhite(#FFFFFF)を設定しています。
ここのポイントは、アイコンのシェイプ自体にはレイヤースタイルは設定しておらず、カラー用のレイヤーを用意してシェイプでmaskしていることです。
アイコンのシェイプに設定してしまうと、シェイプを差し替えたときにレイヤースタイルのOverrides設定がリセットされてしまうのです。
カラーのレイヤースタイルはこのように管理しています。（画像は一部）
これを設定しておけば、
↓このようにライブラリでリンクされたSymbolの色をOverrides機能で自在に変更することができ、
なおかつその色もライブラリで編集すれば一括で反映させることができます。
気をつけないといけないポイントは、Sketchのバージョンのアップデートです。
複数人で作業する場合はSketchのアプデタイミングは気をつけないと事故ります。
マイナーアップデートはそこまで問題無いことが多いですが、メジャーアップデート後にライブラリを編集すると、古いバージョンのSketchで開いたときにライブラリのリンクが外れてしまうことがあります。
便利なSketchのPlugin
ライブラリ機能を使ってシンボルに対する作業を行う際に便利なPluginを紹介します。
すべてsonburn(https://github.com/sonburn)さんという方の制作されたプラグインですが、どれもかなり重宝しています。
symbol-organizer
Symbolの並べ替えをしてくれるプラグインです。Symbolの命名規則をしっかりしてればしてるほど、ちゃんと綺麗に整列させたいですよね。
使われていないSymbolを検出してくれてそれらを削除する機能もあります。
symbol-swapper
選択したSymbolを、特定のライブラリのSymbolに置換できます。
使用シーンとしては、
新機能のデザインをUIのSketchで作ったけど、そこに用いたアイコンがライブラリ化されていなかった。
その後ライブラリでその新アイコンを追加。
Sketchファイルの既存のSymbolをライブラリに置き換えたいけど一個一個アートボードから探して再設定するのが面倒。。
といったときに活躍します。
置換するライブラリのSymbolと同じ名前にしておけば、Symbol-swapperを使って一発です。Overridesも維持してくれるので、何度でも置換可能です。
symbol-instance-renamer
Symbolを配置した際のレイヤー名を、Symbol名そのものにRenameできます。
配置した後にSymbol名を変更すると、配置してしまったレイヤー名は変更前の名前になってしまってますよね。
それを最新のSymbol名の状態にしたいときにこちらのプラグインを使います。
一括でもできますし、特定のPages、特定のアートボード、特定のレイヤー、など対象を自由に選択できるのが助かります。
これのおかげで、複数人が複数Sketchで使用しているライブラリ内のSymbol名を変更してもみんながそこまで困らない状態が作れました。
symbol-instance-locator
選択したSymbolが使用されている箇所を検索できます。
Symbolの影響範囲を知りたいときや、Symbol編集時にミスが無いかの確認に使えます。
Overridesで色々と細かく設定しているコンポーネントのSymbolに変更があった時に、抜け漏れが無いかを確認してからマージするようにしてるので、作業時にもレビュー時にも重宝するプラグインです。
最後に
デザインツールは様々な選択肢があるのでどんどん新しい物を取り入れていきたいところですが、
組織が大きければ大きいほど、
デザインファイルの歴史が古ければ古いほど、
なかなか腰が重かったりします。
組織のスケールによってツールの使い方も変わってくるはずなので、これからもその場での最適解を諦めずに見つけていくことが大事かもしれません。