はじめに
メリークリスマス。松森です。皆さん如何お過ごしでしょうか？
今回、担当プロダクトで、リリース前のUIをプロトタイプも用いてユーザビリティテストにかけることになりました。
その過程でリサーチャーさんから、とあるオーダーを受けたことをキッカケに、figmaのプロトタイプとバリアブルを活用して想定していた仕様を再現しようと試みたものの、いろいろ大変だった話をしようと思います。
バリアブルとは？
皆さんちょっと前にfigmaに実装された、バリアブルという機能はご存知ですか？端的に何ができるか説明すると以下のようなものです。
- figma上に変数が作れる。
- 色、数字、文字列、ブール値の種類で定義できる。
- 変数を入れ子に設定もできる。
- デザイントークンが作れる。
- figma上で作りプラグインでjson形式で書き出して実装と連携することもできる。
- モードで切り替えることができる。
- 指定した変数をライトモード、ダークモードで指定した内容に変更するといった活用方法も可能。
詳しくは公式ドキュメントもありますので、見てみてください。
プロトタイプとは？
随分と初期からあるfigmaの主要機能の一つです。
実装コストをかけずに、デザイナーのみで遷移や簡単なインタラクションを再現でき、デザインや仕様に関するコミュニケーションを円滑に進めることができます。
プロトタイプの制約
プロトタイプで状態変化を扱う際に大きな制約になってくるのが以下の条件です。
- アクションを行ったオブジェクトにしか変更を加えられない
具体的な例でいうと以下のような感じです。
- Aのボタンを押して、Aの色が青から赤に変化させる→できる
- Aのボタンを押して、Bのボタンの色を青から赤に変化させる→できない
制約の突破手段
この制約をどう突破するか？となると通常ではいわゆる「紙芝居戦法」です。
紙芝居戦法とは、同じ画面をまるっともう一つ作成して、該当箇所だけ編集し、変更箇所の差分で表現するようなやり方です。
多くの方は多分これで大半のことは切り抜けてきたのではないでしょうか？私もそうです。
その他にもいろいろなことができますが一旦割愛して、詳しくは公式ドキュメントを御覧ください。
課せられたミッション
今回のテストにおいて、リサーチャーさんからあるオーダーをいただきました。
「実際のプロダクトの仕様と同様に、12個のオブジェクトをユーザーが1つずつ選んで、選択エリアに追加できるようにできないか？」というものでした。
上記で記載した通り、画面の差分で表現する「紙芝居戦法」では複雑すぎるし、冗長すぎて、修正が発生した場合、死が待ち受けていることは容易に想像が付きます。
プロトタイプの「アクションを行ったオブジェクトにしか変更を加えられない」という制約を紙芝居戦法以外の方法で突破しないと無理だと判断し、いろいろインターネットを調べてみると下記のようなドキュメントを見つけ、取り入れてみることにしました。
プロトタイプとバリアブル
具体的にどんなことができるかを、ざっくりご説明しますと以下です。
- if文が書ける。
- バリアブルの変数を経由して、アクションを行ったオブジェクト以外のオブジェクトに変更を加えられる。
- 変数の内容を編集できる。
是非公式サンプルファイルも公開されているので触ってみてください。
https://www.figma.com/community/file/1234939241273272375/advanced-prototyping-playground
if文について詳しく知りたい方はこちらから
一通り内容に目を通して自分は思いました。
イケる！イケるぞ！これで勝てる！そう思っていました。
でも現実はそう甘くない。
ミッション失敗と直面した壁
動作が重すぎる。
特にHoverの挙動の遅延がひどく、テストに影響しそうでした。
いろいろ調査しましたが、さすがにfigmaのレスポンス遅延の原因究明まではデザイナーの自分にはできませんでした。
少なくとも影響してそうな点は以下です。
- バリアブルを用いると重くなる。（原因不明。いろいろと意味ないと思う。）
- 画像類はプロトタイプで使用したものをそのまま表示しているので重い画像を使えばその分重くなる。
figmaプロトタイプでは、今回のケースのような使い方はどうも想定されていないことがわかり、ミッションとして課せられた挙動の再現は諦め、特定のオブジェクトをクリックすると12個すべてが選択されたことになる挙動でプロトタイプは作成し、テスト時は「これらの挙動は実際は一つずつ選択することができます」と口頭で説明してもらう形でテストに挑むこととなりました。残念！
今回わかったこと
プロトタイプはデザイナーの「強力な武器」
プロトタイプは冒頭でも書いたように、実装コストをかけずに、デザイナーのみで遷移や簡単なインタラクションを再現でき、デザインや仕様に関するコミュニケーションを円滑に進める上でとても強力な武器になるのはたしかです。
デザイナーとしてやはり「作ってなんぼ」言葉でわかりづらいなら作って見せるが自分たちの商売道具ですから、そういった点では便利な機能です。
やっぱり餅は餅屋
最適なレスポンス、仕様通りの挙動等を突き詰めるとプロトタイプでは荷が重いということがわかりました。
より本番に近いものを求めるのであれば、それなりのコストを承知でエンジニアさんをアサインするべきなのだなと痛感しました。
あくまでプロトタイプはその名の通りプロトタイプでしかないので、ハリボテでできること、確かめられることってなんだっけ？という問いは肝に銘じておいたほうが良いなと・・・。
プロトタイプを過信しすぎて、ディレクターや企画職の方たちにも過度に期待させてしまうようなコミュニケーションも取らないように気をつけたほうがよさそうです。
できることも知りつつ、できないこともちゃんと知っておく重要性を痛感しました。
今回感じたプロトタイプ&バリアブルの可能性
今回はあらゆる機能が連携している状態の、プロダクト全体をプロトタイプで再現するスコープで挑み、失敗したわけですが、特定の機能に限定してプロトタイプ化し、バリアブルを用いて作り込めば、効果を発揮すると思います。
こういった前提で考えると、やはりユーザビリティテストに用いるというより、開発メンバーとのコミュニケーションを補強するような使い方をおそらく想定されているのだなと改めて思いました。
最後に
パソコンが普及し、スマホが登場し、AIが流行り言葉になって、いわゆるツールがどんどん便利になっていく昨今、その使い方を正しく理解するのが難しくなっているように思います。
UI/UXデザイナーとして、こういったツールの使い方や、そのツールがどういった思想で作られているかに対して感度を高めて、1ユーザーとして触れられるかはとっても大事な観点です。
UIを通して、システムとユーザーの対話を助ける側面もありますが、作り手と使い手とを繋ぐ橋渡しという側面もあると思います。
高度なことができるようになればなるほど、これらのコミュニケーションは必然的に複雑になりますが、こういった「難しさ」をいかに減らせるかが、UI/UXデザイナーを筆頭にプロダクト開発に携わる、みんなの課題だよなと感じます。
いろいろ書きましたが、プロトタイプ&バリアブルはデザイナーのできることを拡張してくれる存在であるのは確かです。
是非触ってみて、たくさん失敗しよう！
松森 裕真 Yuma Matsumori
プロダクト統括部 クライアントサービスデザイン部 デザイン第1グループ サブマネージャー
2020年に中途入社。ウルトラマンとレゴとどうぶつの森に夢中な娘（5）息子（3）にワチャワチャにされて生活しています。
※2024年12月現在の情報です。
