読み込み中...
投稿日
UIデザイナーとの協業時に気を付けるべき7つのこと
もくじ
はじめに
TISデザイングループ所属のUIデザイナーの奥田です。
本稿では、UIデザイナーが実務で経験した「手戻りを防ぐための取り組み」を共有します。
デザイン成果物ができてから間違いに気づくのではなく、事前に進め方やデザイン方針を決めてから進めることで、手戻りを抑制します。
具体的には、デザインの進め方整備、Figma運用ルール整備、レビュールール整備などについて、実際のFigmaデータを用いながら詳しく説明していきます。
規模の大小に関わらず、UIデザイナーと協働して仕事を進める際に参考にしていただければ幸いです。
想定読者
UIデザイナーやUIデザイナーと協業する予定のある方です。
前提知識として、基本的なデザイン知識（Human Interface GuidelinesやMaterial Designレベルのデザイン用語の意味）およびFigmaの基本的な使い方および用語の理解があるとスムーズに読んでいただけます。
案件概要
ある案件では、下図の通り、UIデザイン作業（ワイヤーフレーム作成とデザインカンプ作成）と、UIデザイン整理作業（ガイドラインやコンポーネント作成）を別の会社（以降、A社）のデザイナーとTISデザインチームが分担して進めることになりました。
完成したデザインデータはTIS開発チームが受け取り、スマートフォン向けネイティブアプリを開発していきます。
TISデザインチームがデザインのコンポーネント化・ガイドライン整備を行ったのは、TIS開発チームが開発を進めやすくするためです。
UI Stack（理想状態、エラー状態等）のパターン洗い出しや、デザインルールの整理等を行うことで、デザインのパターンを網羅しデザイン揺れを排除していきました。
アプリケーション自体はReactNativeで実装されるスマートフォン向けのネイティブアプリとなっており、一部WebViewが含まれる構成です。
気を付けること：事前準備編
A社デザイナーと協業を始める前に以下の事前準備を行いました。
①デザインの進め方整備
②Figma運用ルール整備
③レビュールール整備
下記に添付しているFigmaファイルのようにFigma上で整理して、ステークホルダーが参照可能なFigmaファイルに貼っておくと、ルールの確認がしやすいと思います。
【添付】UIデザイナーとの協業時に気を付けるべき7つのこと
※上記添付のFigmaファイルの内容は各章に添付している画像やPDFの元データになります。
①デザインの進め方整備
まずデザインを進めるにあたって、どのような流れで進行するのか細かいレベルで認識を合わせました。
例えば、何から始めて次に何をするのか、レビューはいつ行うのか等についてです。
このように大筋を合意しておくことで大幅な手戻りを抑制することができます。
仕事のやりかたというのは人によって異なることも多いため、「普通こうだと思っていた」が発生しないように対策することが必要です。
②Figma運用ルール整備
前提として、今回はFigmaプロフェッショナルプランを使用しており、ブランチは使用していません。
レビュー実施等はブランチ運用をした方が手違いが少なく管理しやすい部分もありますが、今回はブランチを使用しなかったケースを紹介します。
②-(1) 作業ステータス管理
現在どの画面やコンポーネントがどのようなステータスなのかを管理するために、作業用のタグコンポーネントを作成しました。
最低限、「作業中・レビューお願いします、修正お願いします、レビューOK」の4つのステータスがあれば十分かと思います。
案件によっては「○○さんレビューお願いします」のようにレビューの宛先を追加したパターンを作成することもあります。
今回の案件では「（A社様）レビューお願いします」「（TIS）レビューお願いします」の2つを作成しました。
②-(2) バージョン管理
Figmaにはバージョン履歴を自動保存する機能が備わっています。
自動保存されたデータに「M月D日完成データ」のように名前を付けることもできます。
その機能をそのまま使ってもよかったのですが、今回はFigmaに不慣れなメンバーがいたこともあり、下記のようなルールでページを分けて履歴を保存するようにしました。
メリットとしては、先述の通りFigmaに不慣れなメンバーでも履歴を辿りやすいことです。
デメリットとしては、ページが増えるため画像の多いファイルの場合は特にFigmaファイル自体が重くなってしまうことです。
また、ネストされたインスタンスを切り離す際に、ページ内にマスターコンポーネントがあると切り離しができないため注意が必要です。
そのため、Figmaに慣れたメンバーが過半数の時や不慣れなメンバーがバージョン管理機能に慣れるための時間が取れる場合は、Figmaのバージョン管理機能を使用し、都度のタイミングでバージョンに名前を付けて保存する運用にした方が良いと思います。
②-(3) 画面バリエーション管理
UIデザインには理想状態・空っぽの状態・エラー状態・部分達成状態・ローディング状態といった各状態があります。
これらを適切に作成しておかなければ、エンジニアが開発を進める際に「エラーの時はどんなデザインに？」「初期表示はどうなるんでしょうか？」といった問い合わせが発生し、エンジニアとデザイナー双方にコミュニケーション工数がかかってしまいます。
それを防ぐために、デザイナーは予め必要なバリエーションを作成する必要がありますし、エンジニアは開発観点でレビューの時などにデザイナーに必要なバリエーションを伝えるといった双方の歩み寄りが必要になります。
参考サイト：SCOTT HURFF. “How to fix a bad user interface”. Scott Hurff（個人ブログ）.執筆日不明（2024年2月21日参照）.
https://www.scotthurff.com/posts/why-your-user-interface-is-awkward-youre-ignoring-the-ui-stack/
②-(4) コメント管理ルール整備
今回デザインに関する質問やレビュー指摘コメント等はすべてFigmaで行うようなルールにしていました。
しかしFigmaでは、ファイルを.figファイルとしてローカルに書き出す（名前を付けて保存する）際に、コメントを一緒に書き出すことができません。
そのため、Figmaファイルをローカルに書き出す必要がある場合（ある時点の証跡として残したい場合等）は、コメントの扱いに気を付ける必要があります。
デザインが決まった経緯等の消えると困るコメントをメモとして残しておきます。
注意が必要なことは、この時コメントとメモの呼び分けをステークホルダー内で共通の認識で揃えておくことです。
認識が揃っていない人や呼び分けを曖昧なまま進めている人がいると、結局どちらに文章が残っているのか分からず擦れ違って混乱するだけでなく、誤って必要な情報を消えてしまうこともあります。
-
- コメント＝Figma機能のコメント
- メモ＝下記のようなフレームとしてFigma上に配置するメモ
③レビュールール整備
レビューの流れや依頼先、レビューの観点等を整理してドキュメント化しました。
この時にレビュー依頼時の連絡手段や指摘をどこで管理するのかを含めて決定しておかなければ、レビューの際に誰に依頼すればいいのか分からず困ること、レビューの観点が漏れてしまうことがあります。
気を付けること：作業中編
事前準備が終わり作業が始まってもいくつか気を付けるべきことがあったため、特に有効だったものや重要だったものを紹介します。
⑤性質の異なる画面があればセクションで切り分ける
⑥質問が溜まってきたら個別打ち合わせを設定する
⑦定期的にデザインの棚卸を行う
④ラフを作って会話する
今回A社との会議体としては、週に一度一時間の打ち合わせを行い、そこでデザインへの質問や進捗確認をZoom会議形式にて行いました。
その際に口頭のみでデザインの見た目や動きの話を進めると、後々実は細かいところの認識が違うことや、実際にデザインに起こしてみるとイメージが異ることがあります。
例えば、端末によって画面サイズが変わったときの要素の縦横幅の動きについて質問した際に、相対値で定義するといった回答を得て進めていました。
しかし後々会話をしているとどうやら「相対値」というのが、具体的にデザイン上どのような挙動になるのかA社デザインチームとTISデザインチームとTIS開発チーム間でそれぞれ認識が異なることに気づきました。
すぐにA社に確認を取りましたが、口頭だけのコミュニケーションではお互い要領が得ずイメージがなかなか揃いませんでした。
そこでTISデザインチームはFigmaにてAutolayoutを使用し、それぞれの要素に対してfill・hug・fixedを使い分けて「相対値」で変化する画面のイメージをプロトタイプとして作成しました。
それをA社との定例の場に持ち込み、改めて認識を合わせると、すぐに「作成してもらったプロトタイプのイメージで相違ない」という回答を得ることができました。
このようにデザインの見た目や動きについての会話をする際は、簡単なイメージで良いのでビジュアル的なラフを作成して会話すると、認識違いを防ぎ会話を円滑に進めることができます。
⑤性質の異なる画面があればセクションで切り分ける
性質の異なる画面があればFigmaのセクション機能で切り分けて整理すると明瞭になります。
先述の通り、本案件ではスマートフォン向けネイティブアプリを作成しており、その中にWebView画面とネイティブ画面が含まれます。
それぞれ同じFigmaファイルの同じページにフレームが配置されていたため、一見してどちらの画面なのか分かりづらい状態になっていました。
デザイン上は特にデザインルールの違いはなかったのですが、開発チームが開発する際や新規着任者が見た時に混乱するのではないかという懸念がありました。
もちろん開発チームの画面設計書には記載があるのですが、分からなくなった時に毎回そのドキュメントを参照するのも手間だったため、WebView画面については以下の通りセクション機能で切り分けるようにしました。
⑥質問が溜まってきたら個別打ち合わせを設定する
事前準備で決めていた通り質問はFigmaで行いました。
忙しいタイミング等で返信が滞ることもあるため、その際は質問回答会を別途スケジュールしてZoom会議にてまとめて回答いただく時間を確保しました。
打ち合わせで回答が得られると、その場で回答に対しての不明点だけでなく、話しながら気づいたこともその場で確認ができるため、ステークホルダーの都合さえつけば質問回答会は定期的に行うのも良いと思います。
⑦定期的にデザインの棚卸を行う
検討を進めていく中で更新されて古くなるフレーム（画面）もあります。
例えばある画面についてA案とB案を用意していて、B案が採用された時はA案が古くなります。
このような画面が最新の画面と混ざってFigmaに残っていると混乱してしまうため、都度棚卸する必要があります。
- 削除しても問題ない場合
- 削除する前にバージョン履歴を保存してから削除
- 削除すると差し支えるので、とりあえず画面自体は残しておきたい場合
- 古い画面だと分かるようにしておく（例えば以下画像のように「OLDマスク」をかけておく等）
おまけ：やっておけばよかったこと
今回は時間不足や案件特有の問題があったことで実施できなかったのですが、下記の取り組みができるとよりスムーズだったと思います。
- チームビルディングのための取り組み
- テキストスタイルとカラースタイルの定義は初めに行う
チームビルディングのための取り組み
A社でのUIデザイン自体は既に走り出している所へTISが合流した形だったことや、試行錯誤しながら事前準備を行っていた関係で、案件スタート時にチームビルディングのためのワークショップは実施できませんでした。
もちろん緩やかにチームとして成熟していきましたが、当初はぎこちない場面も見られました。
そのため今振り返ってみると、自分の好きなものを紹介する「偏愛マップ」や得意なこと・価値観を紹介する「ドラッガー風エクササイズ」等のワークショップを少し時間を取って実施するのもよかったかもしれないと思っています。
ドラッガー風エクササイズは別の案件でやってみたことがありますが、チームメンバーの得意なことや何を大事にしているのかが分かり、人となりをよく知れたと思っています。
また、案件の中でも「AさんはXXについて詳しいから相談してみよう」「Bさんにお願いするときはこういう風に言えばお互い気持ちよくお仕事ができるかもしれない」とコミュニケーションに活かすことができました。
テキストスタイルとカラースタイルの定義は初めに行う
アプリのフォントファミリーを何にするか、色はどのようなパターン・使い分けで使用するか、は一番初めに決めておくべきです。
今回の案件では案件特性上の都合があり初めに決めることができなかったため、あとからFigmaプラグインの「Style organizer」等を使用してデザインの揺れを虱潰しにしていく必要がありました。
後から行うと、揺れがあるテキストスタイルとカラースタイルを統一し、ルール化するところから始めなければならないため、工数がかかります。
デザインの揺れを排除する作業は大変だったため、初めに決められるときは、必ず初めにルール化してFigmaのスタイル定義に登録しておくことをお勧めします。
最後に
事前に決めておくべきことが多いですが、初めに頑張っておくと後々自分が助かる場面も多いはずです。
この記事が誰かの参考になれば嬉しく思います。
また、この案件に関わったすべての方々の歩み寄りとご協力に感謝します。
