バージョン管理: UXライターが単語を慎重に選ぶ理由

製品デザインは、新しい物理法則を発明するようなものです。人、製品、機械、コードによって動かされる活動の宇宙を書き込みます。この宇宙をナビゲートするためには、他の主体がどのように振る舞うかを理解する必要があります。言い換えれば、落下とは何かを計算できなくても知っている必要があります。UXライティングはこのバランスを見つけることを目指しています。

これは、ユーザーからの「お願いだから、壊れやすいホットスポットのせいでイライラするのを避けるために、プロトタイプの『オフラインモード』を作ってほしい」というリクエストに応えたときの私の役割でした。FigmaのプロダクトマネージャーであるGeorgia Rustは、エンジニアを集めて簡易的な動作バージョンを作らせ、その後プロダクトデザイナーと一緒に改良しました。いくつかのUIやパフォーマンス上の問題が解消されれば、ほぼリリース可能な状態に見えました。しかしまず最初に、この新機能の内容と使い方を説明するための、わずか数語が必要だったのです。

プロトタイピングに関わったUXライターとして、私はメニューの文言について相談するようにタグ付けされました。チームの議論を読み進めながら、私はこう思いました。「ああ、またか」言葉によって、本当に何が起きているのかという深い問いが浮かび上がっていたのです。

バージョン1: 内部の仕組みは?

当初、代替表現として「Preload prototype (プロトタイプをプリロード)」が使われていました。これはプログラム上の機能を非常に正確に表現しています。

通常、プロトタイプは操作する画面ごとに順次ロードされ、一度にすべてが読み込まれるわけではありません。この新しいオプションでは、すべてを事前にロードして、提示するのに十分な時間保持できるようになります。コードの世界では、重要なアセットを早めにロードすることでウェブのパフォーマンスを向上させることを「プリロード」と呼びます。技術的な視点を持つ人には、この動詞は体験を適切に伝えています。

しかし、それ以外の人にとって「プリロード」は少し難しい表現です。正確ではありますが、人に時間のループに入るよう求めているようなものです。「プリ」は何かの前に行われることを示す接頭辞で、「オーブンをプリヒートする(予熱する)」の例と同じです。この例では、オーブンがオフからオンになることを期待します。しかし「プリロード」というオプションを見ると、すでにロード画面を経てプロトタイプが表示されている状態です。私たちが伝えたいのは、他の操作をする前に残りをロードできる、つまりオフラインで提示できる、ということです。しかしそれを理解するには、私たちが提供している情報以上の知識が必要です。

より理解しやすいコンピュータの操作としては、一般的な「ロード」があります。これでうまくいったかもしれません。

名詞表現も試しました。「Load full prototype (プロトタイプ全体をロード）」「Load all screens (全画面をロード）」「Load all assets (全アセットをロード）」などです。しかし、いずれもユーザーとプログラムの間の信頼を損なうように感じました。プロトタイプをロードしたばかりなのに、なぜまだ全部揃っていないと考えなければならないのでしょうか?「ロードする」という行為は、コンピュータが代わりに行っていることを示す、とても印象的な動詞です。しかし完了したときには、本当に完了したと信じる必要があります。

バージョン2: 目的は何か?

ソフトウェアの文章を書く際には、ユーザーがなぜその操作をしているのかを考えることが重要です。目的は何でしょうか?この場合、明確でした。ユーザーはインターネット接続なしで確実にプレゼンしたいのです。「Present prototype offline (プロトタイプをオフラインで提示）」や「Prepare to present offline (オフラインで提示する準備）」は、その欲求に直接応えています。しかし、それらは正しい動詞を正しいフレーズで使っているでしょうか?

コンピュータの先駆者であるTerry Winogradは1987年にこう書いています。「人は言語を通して行動する」。メニューにフレーズを置くとき、それはユーザーの視点を形成することになります。これらのフレーズの多くは、プログラムに指示する命令形か、「I want to… (私は…したい）」という文章を完成させる傾向を持つものです。言葉は、ユーザーの思考とコンピュータの動作を結びつけ、何らかの結果を生む必要があります。思考、言葉、実際の動作との間にギャップが大きすぎると、その体験は崩れてしまいます。

両バージョンとも、そのギャップはかなり大きく感じられました。「Present… (提示）」をクリックしても提示されないのは、大きな遅延満足です。「Prepare… (準備）」をクリックしても、その準備が何なのか、どれくらい前もって呼び出す必要があるのかがわからず、曖昧すぎます。これらはいずれも、ユーザーが細かい操作を追う大きな体験設計があれば機能したかもしれません。しかし、それは私たちのUIではなく、どちらもトグルするメニューオプションとしては負担が大きすぎました。

バージョン3: 何をコントロールできるか?

すべてのプロダクト文章において、言葉がほとんど置き換え可能に感じられる瞬間があります。誰かが必ずこう言います。「結局、気付くのは私たちだけじゃない?」しかし、私は個々の動詞には独自の創造力があると信じています。それは、あなたと注意を向ける対象との間の関係を整えることができます。その行為の焦点を照らし、作業のための灯りを灯します。

では、Figmaを支援的なパートナーとして使うために、どのフレーズがユーザーを導くでしょうか?私たちは「有効化 (enablement）」に関する動詞を試すことができます。ユーザーからコンピュータへの優しい促しで、共に動作するように働きかけます。

「Make」は柔らかい命令形でありながら、ユーザーに確固たる権限感を与えます。船長でない限り、通常「Make it so (そうせよ）」とは人に指示しません。しかし、この動詞は世界に影響を与えることはあります。料理を作り(make dinner)、騒ぎを起こし(make a fuss)、意味を成し(make sense、物事を正す(make things right)。ここでは、ユーザーの役割は、今この瞬間Figmaに、プレゼン時に必要なことを指示することかもしれません。「Make (it) available offline (オフラインで利用可能にする）」です。

ほぼ正解ですが、まだ完全ではありません。「Make available offline (オフラインで利用可能にする）」だと、何かが永続的にコンピュータにダウンロードされるように思うかもしれません。さらに、オンライン状態でもプロトタイプのパフォーマンス向上を望む人にとって曖昧だと心配するチームメンバーもいました。そこで、最終バージョンに導くために、もう少し言語を加える必要がありました。

最終バージョン: 次になにが起こるか?

1983年、文化人類学の大学院生Lucy Suchmanは、新しい高速コピー機を使いこなすのに苦労する人々を観察するため、カメラを設置しました。あるビデオでは、2人の研究者が機械が何を知っていて、なぜ予期しないことが起きるのかを理解しようとしていました。

Lucyは後の文章でこう記しています。ユーザーが何をすべきか知ることだけでなく、コンピュータが何をしているのか、そしてなぜそうしているのかを明らかにすることも重要である、と。

私たちは、ユーザーにクリックさせるだけでは不十分であり、その行動がもたらす意味を理解させる責任もあることを忘れてはいけませんでした。そこで最終的な体験では、ファイル上部にアイコンの状態を追加し、より詳しい説明文を添えて、技術的な状況と体験の全体的な目標を結びつけました。

クラウドからブラウザセッションにファイルのアセットが移動する際に起こることを、「ダウンロード」という一般的な概念を使って説明しました(デバイスのストレージには保存されません)。準備が整うと、オフラインでプレゼンできることのリマインダーを表示し、将来それを行う際に取るべき行動と取るべきでない行動を明確に示しました。タブを開いたままにする必要があります。閉じるとダウンロードが消去されます。

本当にシンプルで、結局のところ、数語だけです: make、keep、present、close、clear。小さな行動の集合が、大きなFigmaの宇宙の中で互いに作用し合っています。

このプロジェクトに関わったすべての方に感謝します: Georgia Rust、Connor Skees、Tim Van Damme、Niko Klein、Jackie Chui、Jediah Katz、Stephanie Cheuk、John Lai。