We refreshed Figma's UI: An inside look at our process by Rasmus Andersson
今日はこの半年間、私たちが取り組んできた新しいFigmaのUIを公開することになりました。タイポグラフィー、レイアウト、色、アイコンにいたる細部にわたる微妙な変化に気づくでしょう。
今回のリフレッシュの私たちのゴールはなるべく控えめで目立たなくすることでした。構造上ではなく、主に表面上の変更に集中して、量的、質的な調査を実施しました。また、それぞれのかかわるチームが最終製品の共通理解ができるように、詳細に関する社内で長い時間をかけて深く議論しました。
すべての人に新しいデザインを好きになってもらうことは不可能です。デザイナーは当然このことについて理解しています。この記事ではなぜ今回このようなデザイン変更を行ったのか、ハイレベルな知見、それにかかわるプロセス、そして学びを共有します。（具体的な変更についてはカバーしていません。それは自分自身でFigmaを使ったときにわかります！）
遅かれ早かれ、多くのプロダクトは見た目をリフレッシュ的なことをする必要があります。わたしたちは、同じ道のりをたどる人たちのために、自分たちが使ったツールやテンプレートも共有します。
デザイン変更をするとき
では、いつデザイン変更をすべきでしょうか？雷が打つような瞬間もありませんし、空が割れて神様がデザイン変更のお告げをしてくれることもありません。むしろ、鍋で煮るロブスターのようなものです。圧力が徐々にかかってきます。
Figmaでは昨日できたことが、今日はうまくいかないような感覚がUIについて膨らんできました。私たちは必要があればコンポーネントを急ごしらえして、既存の要素がフィットしなかったら特注のソリューションを作りました。その結果、ツールの全般にわたって無数の表組、ボタン、入力、様々な色合いが使われるようになりました。
ユーザーは一貫性のなさや微妙な美しさのニュアンスに気が付きましたし、私たちも気づいていました。一つの問題について気軽に話をしていて、最終的に非公式なチャットに雪だるまのように膨れ上がりました。
Figmaのオリジナルシステムの制約の壁に突き当たり続けるのは驚くことではありませんでした。最後に全体的なインターフェースのレビューを行ったときには、まだマルチレイヤーやコンポーネントなどなかったのですから。別の言い方をすれば、UIの基礎を作ったとき、FigmaはまだFigmaですらありませんでした。
ステップ１：有限ブレインストーミング
最終的にUIについての積みあがったものについて何かすることにしました。まずはデザインチーム全体で二時間のブレインストーミングセッションを設定し、UIに関するねじれや欠点、そして、気に入っている点のカタログ作りをしました。
自分たちのパソコンでFigmaに触れ、プロダクトの隅々まで入り込みました。きづいたことのメモとスクリーンショットを取り、Figmaファイルに入れ込みました（それ以外の場所があるとでも？）。
一時間ほどたち、メンバーは自分たちが見つけたことについて話して、内容をノートに書き込んでいきました。話の中で「うわ、それ最悪じゃん」のような顕著な反応があった場合、その反応についてもメモを取りました。何が大きなインパクトがあるのかそのシグナルの初期調査となります。
そして、情報の洪水から数日間時間を空けました。同じようなプロセスをやってみたい？Figmaでシンプルなブレインストーミングのテンプレートを作ったので試してみてください。
figma.com/file/J3XZEzlgTHP3Xj2ELcNywG
ステップ2：世界を整理整頓
ブレインストーミングの後に時間を置くことは大切です。そうすることによって、メンバーは頭の中で情報を処理することができます。思考の種は会話から生まれ、意見はひと晩で表面化してきます。
私たちはそれらすべてを次のミーティングで話しました。いくつかの課題は当初考えていたよりも重要ではないと気付きました。いくつかの課題はより大きく見積もってなぜこの課題は解決しなければいけないのか議論しました。
すべてのケースを話し終えた後、リストを均等に分配してポストイットに転記していきました。その過程で一時的に整理整頓もしました。
たとえば、リストにいくつか「通知」に関するメモがあったとします。ポストイットに転記するときは「通知」に関する複数の細目を作るのではなく、「ツール上で通知を扱うシステムが必要」とまとめます。いくつかのポストイットは複数のアイテムを代表することもあるため、私たちの最初のリストはこのようにして短くしていきました。
ポストイットを壁に貼るときは「似た者同士」で集めていきました。たとえば、「色」についてのポストイットは自然と集まっていきますし、「読みやすさ」や「空白スペースの使い方」などについても同様です。もちろん、完璧なプロセスではありません。それぞれのノートにはダブりもあります。しかし、そのダブりも課題の大きさのサインとしてとらえることもできます。
最終的に以下のカテゴリー分けをしました。
- アイコン、タイポグラフィー、読みやすさ、色、ダイアログ、文体、、ツールバー、エディターとファイルブラウザ、モード、チームページ、ファイルブラウザ、プロパティーサイドバー、コンポーネント、レイヤー、履歴、シェア、パブリッシュ、エクスポート（フー）
しかし、私たちはこの上にもう一つの軸を重ねるという過ちを犯しました。このカテゴリーを「ビジュアル」と「ファウンデーション」のレイヤーに分けようとしましたが、これは複雑すぎました。
失敗からの学び: 自分たちのUIリフレッシュのためのブレインストーミングでは分類について考えすぎないようにしましょう。あまり抽象的すぎない納得感のあるカテゴリーを見つけましょう。たとえば、プロダクトの「性格」はテーマとして抽象的すぎます。ほぼすべてのことが当てはまってしまいます。かといって、具体的すぎてもいけません。（たとえば特定のダイアログボックスだけに集中してしまうみたいに）
ミーティングの最後にデザイナーはそれぞれのテーマごとに整理整頓して共有テキスト文書に転記していきました。
ステップ3：スコープを狭める
私たちはブレインストーミングで自分たちができる以上のことを集めました。これらすべてを直すには二年以上かかるでしょう。急速に成長しているスタートアップにそれはできません。
そこで、三回目のミーティングではシンプルな思考実験でスコープを決めることにしました。「もし一週間あったら、ひとつだけ何を直す？」みんなはすでに答えを持っていて、それは私たちが進むべき方向性を示していました。
表面的な変更によって多くの差し迫ったUI上の欠陥を直すことができることがわかりました。「何でここは動かない？」と詳細を見ると、答えはたいてい「複数のオプションを持つポップアップウィンドウが作れるオプションを用意していなかったから、必要に応じていろいろと異なるポップアップウィンドウを作ったから」という感じでした。
私たちが用意したコンポーネントは自分たちがやりたいことをサポートしてくれていませんでした。なぜなら2015年からいろんなことが変わってしまったからです。
同時に、私たちはFigmaの（インフォメーションアーキテクチャー上の）基本構造はいまでも健在で、あまり多くの問題を抱えていないこともわかりました。もちろん、コメントモードからほかのモードにシームレスに移行することもできるかもしれません。しかし、それは「おしりに火が付く」ような問題ではありませんでした。
自分自身のデザイン見直しプロジェクトのスコープを検討するのであれば、どの道筋を通るかを決めておくのはいいことです。三つのオプションがあります。
- 表面（Surface）：UI上に現れることに集中する。たとえば、入力コントロール、アイコン、タイポグラフィー、ボタン動作など。
- 基礎（Foundation）：整合性やメンタルモデルに集中する。たとえば、モダリティやインフォメーションアーキテクチャーなど。
- ハイブリッド：表面レベルと基礎レベルの両方に取り組むこともできます。しかし、製品の一部にとどめましょう（そうしないと全部やるということになってしまいます）
Figmaでは部分的ではなく、全体に手を入れることでより大きなインパクトを得ることができると感じていました。そこで一番目のUIの表面レベルの問題に取り組む道を選ぶことにしました。
スコープをさらに絞り込むために、自分たちの作業時間を決めました。3人（デザイン、エンジニア、プロマネ）を5か月間選任でつけることにしました。この制約のおかげで、最初にいろんな決定をすることができました。つまり、UIのオーバーホールではなく、ビジュアルのリフレッシュにとどめることです。ペンキの色を変えたり、新しい家具を調達しますが、壁を取り壊したりはしません。
もちろん、これはつらい決断でした。デザイナーとしての仕事はこれらのことを大切にすることですし、デザイナーであるユーザーはそうした細かい部分に気が付きます。しかし、私たちは時間の制約ですべてを解決することはできません。おそらく、これが今回の最大の学びです。あきらめを決断しないといけない。
実体験からの学び：デザイナーがUIに関して「やりたいことリスト」を話しはじめたら、早々にコントロールできないくらい膨らんでいきます。チェックせずに作業をすると永遠に終わりません。デザイン変更をする際に最も重要なステップの一つはスコープ決めです。以下のことを自問自答してみましょう。
- もし一週間しかなかったら何を直す？
- 最も大きな問題は表面上の問題？それとも構造的な問題？
- どれくらい時間を投資できる？
次に、何に取り組むかを調べる
Figmaの表面レベルのリフレッシュに取り組むと決めてから、準備のために二週間ほどの調査を行いました。ポストイットで整理整頓したそれぞれのテーマを3、4名で構成されるグループに振り分けてました。
- 色
- タイポグラフィーとアイコノグラフィー
- 空白、グリッド、メトリックス
この調査のゴールはそれぞれのテーマにおいてアイデアを探り、方向性を見極めることです。私たちは現時点でどのようにやっているのか、ほかのソフトウェアは同じ課題にどのように対応しているのか。それぞれのグループはFigmaファイルを作り、発見と変更の提案を書き込んでいきました。たとえば、カラーのテーマに取り組んでいるグループからの提案は"Figma Blue"のコントラストまたは深度を強めることで、白が読みやすくなるという提案をしました。
それぞれのグループは以下のゴールを念頭に置いていました。
- UIのモダン化：時間がたつと、期待も変わります。これはシンプルな事実です。自分たちのUIのどこが年を取ったか？トレンドから正統進化と改善を切り離すか、モダンだと感じるものを切り離すか。
- 読みやすさとアクセシビリティ：読みやすさと色の対比を分析するやり方や考え方はたくさんあります。私たちは色のコントラストに関しては一貫性を保つために一つの方法を採用することが大切だと決めました。それはWCAG2です。タイポブラフィーも同様のカテゴリーにおける別のトピックです。
- シンプルさ：製品が高機能になり、複雑になると、パターンを減らす必要性が出てきます。たとえば、ふさわしいユーザーインプットコントロールになっている？UIのラベル付けは明確で的確な階層になっている？ツールバーに詰め込みすぎてない？などです。
- 使いやすさ：私たちは使いやすさと分かりやすさに集中したいと考えました。そこで、製品の発見性を詳しく見ていきました。ユーザーは角にあるアイコンからコンポーネントのスライドバーを見つけられる？ページの間を行き来するのは直感的でわかりやすい？
もちろん、暗黙のゴールもありました：人が気がついて気分を害さないようにチーズを動かせるか？もし、ユーザーがすぐに何が変わったのかわからなかったら、うまくビジュアルのリフレッシュを成功させたということなんだと思います。
そして、実作業
また一二週間後、チームで集まってお互いの発見を共有しました。私たちは提案された変更点について話し合い、大まかな変更点について合意しました。しかし、具体的な解決方法は決めませんでした。たとえば、「現在のFigma Blueはうまく機能していない」ことに合意しましたが、具体的にどの青を使うかは決めませんでした。
大枠で合意した後、一人のデザイナーを今回のUIリフレッシュプロジェクトのチャンピオン（私のこと！）を任命し、それを構築するフロントエンドエンジニアを任命しました。
デザインチームのすべてを最初のブレインストーミングと優先順位付けのプロセスから巻き込んだのは正解でした。これによって、全員が変更に関する決定に関わり、これから適用される変化についての背景を理解できたからです。
残りのプロセスはご想像通りです。一人のデザイナーしかフルタイムで携わっていませんでしたが、ほかのチームと毎日チェックインを行い、週三回正式なデザインレビューを行いました。日々、進捗について話をしていたので、だれにとってもサプライズはありませんでした。
自分の決断とともに生きる
このようなプロジェクトの場合、自分の決定が正しいか判断するためにも自分のデザインとともに生きる必要があります。そのため、最初のころ、社内でテストできる小さなリフレッシュをするために厳しめの期限を設定しました。（Figmaでは正式リリースする前にバグだしをするため、プライベートなステージング環境で日々の作業を行います）
具体的には、タイポグラフィー、色とグリッドの変更をエディターのベースレイヤーに適用しました。これらはツールバー、プロパティーサイドバーのように常に画面に存在する要素です。エンジニアが変更を適用すると、社内で使ってみて、何がうまくいき、何がうまくいかないのかを探しました。
もう一つの学び：自分のデザイン変更をそれぞれのステージでドッグフード（社内テスト）する場合、いろいろと混乱することがあります。たとえば、ツールバーだけ変更して、それ以外は何も触らなかったとします。ほかの要素を変更するまでつぎはぎのフランケンシュタインのようになることは理解できるでしょう。この点に関してはコミュニケーションしすぎるということはありません。会社の組織全般に直接でも、Slackやメールででもたくさんコミュニケーションしましょう。
プロジェクトがさらに進行して、いくつかの段階でユーザーリサーチを行い、問題がないかを確かめました。人々は変化を好みません。多くの製品ではデザイン変更はユーザーコミュニティーから懐疑的な目で見られます。私たちはこの変更で積極的にユーザーを傷つけたくありませんでした。
本当はもっと共有したいことがたくさんありますが、それにはさらに3000文字くらい必要になります。
私たちの経験と学びをお送りすることにします。もし、あなたがUI変更を行うのであれば、明確で実現可能なスコープを設定しましょう。そうしないと広大なデザインの土地で永遠にさ迷い歩き続けることになるでしょう。
皆さんがあたらしいFigmaを気に入りますように！ :–).
解説
久しぶりの翻訳記事です。この記事はデザインツールFigmaのデザイナーRasmus Anderssonさんによる最近行われたUIリフレッシュの社内プロセスを公開した記事の日本語訳となります。一応Rasmus AnderssonさんにはTwitter経由で翻訳の許可を求めましたが「いいね」の返事だけだったので、まあ「いい」ということなんだろうと判断して公開しています。ダメだと言われたら削除するかもです。
内容的にはよくあるポストイットによるブレインストーミングとグルーピングのエクササイズです。でも、それを実際に効果的に使えているところって少ないんじゃないですかね。思考実験とかスコープぎめとか、そういう考え方の部分がとても参考になります。
カタパルトスープレックスなかむらかずや
