これは Livesense Advent Calendar 2023 DAY 19 の記事です。
アルバイト事業部「マッハバイト」のデザイナー @n_m_y_yです。
年末になりました。あと2日で草野マサムネさんのお誕生日ですね〜
さて今回は開発チームでデザイナーとして働く中で得た、レビューや実装のしやすさに繋がるデザインデータの作り方とデザインの伝え方に関する工夫についてまとめていきます。
今回はこんな問題を抱えている方に向けています。
- デザインが実装された後に、デザイン時には考慮していなかった表示があることがわかり手戻り工数が大きく膨らんでしまう
- デザインレビューで、自分が良いと思ったデザインが選ばれずディレクター・PdMの好みでデザインが決まってしまうと感じる
- 議論したいところ・みて欲しいポイントから論点がズレてしまう
- せっかく細かくデザインを組んだ箇所があるのに実装されていないときがある
- デザインが実装されると「なんかイメージと違う」となってしまう
おそらくデザイナーというと、 カッコイイデザインを作ってるなんかクリエイティブな仕事、というイメージになるかもしれませんが実際の内容は
- 手を動かすデザイン業務5割
- コミュニケーション業務5割
くらいの比率で、実はコミュニケーションの比重がかなり大きめの職種です。
デザイン業務について詳しい内容はすでにKamikazeさんが記事にされているので、ぜひご一読ください〜
ちなみに弊社は各事業部に少数のデザイナーが配置されるいわゆる「事業部付きデザイナー」スタイルです。この場合デザインデータはデザイナー同士が作成・レビューに使用するだけでなく、デザイナー以外の多職種のメンバーと一緒にデザインレビューをします。共創を意識したデザインデータ作りを行う必要があるので、弊事業部ではコラボレーションデザインツールのFigmaを導入しています。
それでは、いってみましょう〜！
- 実装分岐を考慮しデザインを組む
- 思考・意図は言語化する
- 意図・周辺の情報を残しておく
- 変更点（みて欲しい箇所）は明確に
- 提案時はなるべくプロトタイプを組む
- 終わりに：「デザインはデザイナーだけに任せるには重要すぎる」
実装分岐を考慮しデザインを組む
１画面の中でも、状況によって表示パターンが複数種類存在する場合がありますよね。デザインを作成するときは、実装分岐を考慮し必要に応じて同じ画面でも複数のデザインパターンを作成しています。
例えばマッハバイトの場合、同じ画面でも以下のような表示パターンが存在します。 こちらは、現在リリースされているアプリのデザインをデータとして管理しているマスターデザインファイルからのスクリーンショットです。
こちらはエンジニアさんから「実装分岐を網羅できているわけではなく抜けていることもあるので効率が良い」や「着手前の見積もり精度が上がる効果もありそう」との声をいただいており、スムーズな開発工程では欠かせない作業です。 実装面を考慮したデザインについて、もっと具体的に知りたい方はこちらの記事がおすすめです。
https://note.com/pittan/n/n5789d09c5575 note.com
思考・意図は言語化する
デザイナーは画面を作るだけではなく、様々な周辺情報を組み合わせてデザインを組み上げていますよね。ただし結果（=アウトプット）だけを共有するのはもったいないと考えます。なぜならアウトプットに対する情報が不足しているため、理解が深まらず見た目の好みに基づいて評価されてしまうからです。
過程の思考プロセスとデザインの意図を共有することでレビュアーは見た目の好みだけではなく論理的にデザインを観ることに繋がり、レビュアーとデザイナー間で建設的な議論ができます。
デザインレビューを誰かに頼むときは必ず意図を言語化して、説明とセットで渡すことが大事です。ミーティングの場ですでに口頭で説明した内容でも、余裕があればメモを残しておくと良いかと思います。
このような情報を残すことで、たとえ担当者が変わってしまっても後続のメンバーで経緯や思想をトレースできます。適切な判断を下す助けになったり、サービスの長期的な一貫性につながったりして、品質保持がさらに強化されるメリットが挙げられます（開発者だけでなく、めぐりめぐってユーザーにまで良い影響があると信じています）。
言語化するコツについてここでは詳しくまとめませんが、
- なぜその色・形・余白にしたか（ユーザの視点、アクセシビリティの考慮などはしたか）
- どのデザインを参考にしたか
- OSのガイドラインは参照したか、どの項目か
など、自分がどうしてそのデザインを作ったかを書き出してみるだけでも簡単な説明ができあがりますね。
意図・周辺の情報を残しておく
関連情報（要件定義書、タスクチケット、議論、参考Webページ、インタラクション・モーションなどの指定）がある場合はFigma上に残すようにしています。 関連事項や要件が曖昧なままであると間違った方向に進んでしまったり、要件にそぐわないデザインを作成したりするリスクがあります。 なぜこのアウトプットになったのか、という説明の補助でもあり、実装時への情報の橋渡しにもなります。
残し方としては2種類の方法を使っており、 全体に関わるもの（要件定義書や、タスクチケットなど）はFigmaのDevモードを使ったり、参照元リンク用のパーツで貼ったりしています。
もう一つ方法があり、画面の特定の一部に関連するもの（参考にしたWebページ、インタラクション・モーション指定）などは、画面近くに書き込むようにしていきます。 次で内容を詳しく説明します。
変更点（みて欲しい箇所）は明確に
デザインを担当している人は自分で変更した内容を把握していますが、他人が見ると変更点が一目では分かりづらくなることがあります。サイゼリヤの間違い探しのような状態を避けるため、注目すべきポイントを明示的に示す工夫を行うと間違い探し時間を大幅に削減できますし、議論したいところ・みて欲しいポイントから論点がズレてしまうことも避けられます。
私は下の図のように、ピンクの強調パーツとふせん風のメモパーツを一緒に使うことで、変更に注目できるようにしています。
こちらには、デザインの変更点のメモとともに参考にしたWebページ、インタラクション・モーション指定なども記入しています。
小さい工夫ですが効果的で「ふせんのお陰でold/newで微妙に変わってる点を見逃す可能性が低くなった」との声をもらうことができており、チームの業務効率も上がっているようです。
もう一つ重要なポイントは言語化したデザインの意図を「ここみてね」情報と一緒に記しておくことです。言語化するメリットは前述したとおりです。変更箇所の近くに貼っておくことで、何箇所も参照する手間を減らすことができます。
もしファイルの運用でFigmaのブランチ機能を使っていたらGitHubのようにビフォーアフターを素早く確認できるのですが現在はブランチ機能の使用は限定的なため、このような工夫を行なっています。
ちなみに「変更点を強調する」という見せ方は私が以前一緒に働いていたmuさんから教わりました。素晴らしいデザイナーさんで、他にもたくさんのことを学べました。
提案時はなるべくプロトタイプを組む
デザインが実装された結果「これはイメージと違う」という経験をしたことがある方も多いのではないでしょうか。さらに「見た目はいいかもしれないけど、実際に動いてみないとわからない」という意見もよく耳にしますが、なんとプロトタイプを組むことでさけることができます！
Figmaはデザインだけではなくプロトタイプもシームレスに組めるので大変便利ですね。静的なデザインと動的なプロトタイプを一緒に共有することにより、チームメンバーとのコミュニケーション齟齬を最小限に抑えられるのでおすすめです。
考えてみれば、紙ベースのデザイナーが度々実物大の印刷や色調整を行うように、UIデザイナーも「実際の使用環境に近い状況」で自身のデザインを確認することは必要な工程だなと思いました。さらに、「自分以外の人」が試すことによって精度が上がっていきますね。
こちらはプロダクトマネージャー（PdM）が、わかりやすいと声をかけてくれました。
さらにポイントですが、Slackで共有する際にはプロトタイプとデザインのURLだけでなく、それぞれのスクリーンショット画像と動画も一緒に渡すようにしています。スクリーンショット画像がついている方が興味を惹きレビューに参加してもらいやすくなり、他職種の方がアプリを立ち上げる手間を省くために行なっています。Figmaを常に開いているのはデザイナーだけなので、デザイナーの皆様はご注意くださいね。
遷移はなるべく明確に
プロトタイプや実機確認には時間がかかるので、遷移をFigmaに書き込み管理しておくと扱いやすくなります。遷移図が別にある場合は不要かもしれませんが、アプリの規模が大きくなるほど遷移は複雑になります。遷移は直接UXに関わるため、可視化しておくことでユーザビリティに関する問題や課題を特定することができます。
方法①FigjamのConnector lineを持ってくると楽ちん
実はFigjamからコピペできます。
方法②プラグイン使っても楽ちん
プラグインは AutoFlow を使用しています。
www.figma.com
どちらの方法でも、遷移を判りやすく簡単に書き込むことができるので空いた時間でサクッと作業ができます。
不要になったパーツ・画面は明確に
デザインのプロセスは試行錯誤がたくさん含まれていますよね。多くの場合複数の案を作ったうえで結局没になるものもあります。しかし、消去せずに「不要ゾーン」に保管しておく方が良いと私は考えています。なぜなら完全に消去してしまうとそのデザインが生まれた経緯や、なぜその案が没になったのかの理由がわからなくなるからです。十分に検討済みですよ、その上で選ばれた案です、と示すことができます。
ただし、ステータスの共有は重要で「これは議論済み」「これは実装不要」といった情報を明確に共有しなければ、他のメンバーが混乱してしまう可能性があります。というのも私がゾーン分けを忘れてしまい、混乱を招いてしまった経験があります。このようなミスを繰り返さないよう、自戒の意味も込めて書いておきます。
終わりに：「デザインはデザイナーだけに任せるには重要すぎる」
もしかしたら一般的には、デザイナーがすべてのデザインを思うがままに決め、思い通りに実装してもらえるように見えているのかもしれません。デザイナーの方ならわかると思うのですが、実際は逆の方が多い気がします。
意図や目的の共有がないままアウトプットだけを求められる社内受託状態になってしまったり、プロジェクトオーナーの思い描くものを忠実に再現する作業をしたこともありました。
たしかにデザイナーはデザインに責任を持つ必要はありますが、責任を持ちたくても持てない状況もありますよね。
それでも背景を探ったり目的を共有してもらいデザインの意図を根気強く伝え説明しながらデザインを共有することで、対話が生まれ少しずつ担当できる範囲が増えていき上流工程から担当できるようになったプロジェクトもあります。
逆に、説明をつけずにデザインを選んでもらうことをしてしまい、手戻りが発生してしまったこともあります。見た目の力で振り回してしまいました。
そういう経験から私はデザイナーにとってコミュニケーションは大事な業務だなと実感しています。
実は今回の内容は私が作り上げたルールではなく、前任のデザイナーや同僚たちから蓄積された先人の経験やアイディア、Figmaに残されていた情報をまとめ整理して文章に落とし込んだものです。言語化しておいてくれてありがとう、と同時に「言葉にして伝える・残す」ことの大事さを改めて感じました。デザインも見た目だけではなく言葉にして伝え、見た目と説明両方のフィードバックをもらうことで新しい発見があることが多いです。
今回も、この記事を書くにあたり改めてデザインレビューについて開発チームに意見を聞いてみました。すると「議論しやすいように変更箇所にナンバリングしておくとよさそう」という新しい意見をもらえました。まだまだ様々な工夫ができそうです。
これからもデザインをデザイナーだけに閉じないように日々よりよいプロダクトを届け社会の課題を解決していきたいです〜。
長くなりましたがお付き合いありがとうございました！
現在アルバイト事業部ではUIデザイナーを募集しております。
あたりまえを一緒に発明していきたいデザイナーさんはこちらからぜひご応募ください。
