アプリの機能やラベルに明確な名前を付ける

ハイライト

AppleはBelongs、Expectations、Works everywhereという3つの基準と、Think-Feel-Doの導出フレームワークを使い、アプリ内の命名を文案の勘ではなく検証可能なデザイン判断へ変えています。開発者はこの方法で、自分のプロダクトにあるボタン、メニュー、機能名を1つずつ見直せます。

主要内容

命名に失敗するコスト

(00:11) アプリを開いた瞬間にどこへ行けばよいか分かる感覚は、設計されたものです。命名は見落とされやすい一方で、もっとも強力なデザインツールの1つです。悪い名前はユーザーを混乱させ、誤った期待を生み、信頼さえ壊します。

Apple Cashの残高表示は典型的な例です。チームは「Spending Power」という名前を検討しました。この言葉は魅力的に聞こえますが、十分に具体的ではありません。ユーザーは、それが与信枠なのか、スコアなのか迷います。金融の文脈では、曖昧さはもっとも危険です。さらに残高が0のとき、「Spending Power」は評価されているように聞こえ、金融プロダクトへの信頼を直接損ねます。

もう1つの候補である「Current Funds」は、説明としては正確ですが、スプレッドシートから持ってきたような言葉です。日常会話で「Current Fundsを確認しよう」と言う人はいません。

最終的にチームは「Balance」を選びました。業界標準の用語で、明確で、中立的で、説明を必要としません。この場面では、ブランド表現よりも明確さと信頼が優先されます。

命名の3つの基準

(01:18) Appleは3つの評価基準を提示しています。

Belongs（ふさわしい）: 名前はアプリらしく聞こえるだけでは不十分です。ユーザーがその場所で何を期待するか、すでに命名済みの他の要素とどう共存するかまで含め、あらゆる階層で機能する必要があります。

Expectations（期待）: ユーザーは名前を読んだ瞬間に、そこに何があるかを予測しています。正しい名前はその期待に応え、信頼はそこから積み上がります。

Works everywhere（どこでも機能する）: 名前は言語、市場、プラットフォームをまたいでも有効である必要があります。

この3つの基準は、すべてを同じ強さで満たさなければならないわけではありません。商標や業界規制など、独自の追加基準がある場合もあります。大切なのは、自分がどのトレードオフを選んでいるかを理解することです。

ユーザー視点から始める: Think-Feel-Do

(05:25) 開発者は、技術実装や機能の観点から名前を付けがちです。しかしユーザーは技術そのものではなく、「それが自分に何をしてくれるのか」を気にします。

Appleは導出のための練習を勧めています。まず対象ユーザーを明確にし、その機能に触れたとき、ユーザーに何をしてほしいかを考えます。

Think（何を考えるか）: この機能は簡単そう、有用そう、賢そうだと思ってもらえるか。
Feel（何を感じるか）: 名前を思い出せないカフェを見つけたときのうれしさか。データが暗号化されていると知ったときの安心感か。
Do（何をするか）: この機能を見つける、使う、場所を共有する。

Apple Mapsの「Visited Places」機能を例にすると、チームはブレインストーミングのあと、Ease（簡単に見つけ直せる）、Excitement（好きな場所を再発見する驚き）、Security（プライバシーと暗号化）という3つのテーマに整理しました。最終的に選ばれたのは「Visited Places」です。説明的で、Mapsの画面全体で多用される「Places」という語に自然に溶け込み、さらに「これらの場所はあなたのもので、Appleは読み取れない」というプライバシー上の期待も伝えます。

さまざまな命名スタイル

(09:35) 命名に唯一の正解はありません。Appleは、異なる設計目標を満たす3つのスタイルを紹介しました。

感情駆動: Photos Appの「Memories」は写真を自動で整理する機能です。ユーザーがPhotosを開いて5年前の写真を見つけたとき、「アルゴリズムがすごい」と考えるのではなく、思い出を探しています。「Memories」は説明ではなく、感情の角度から明確さを作っています。

説明駆動: Apple Podcastsの音声強化機能では、チームは実装を表す「Vocal Isolation」と、半分しか言い当てていない「Clarify Speech」を退け、最終的に「Enhance Dialogue」を選びました。これは「何を強化するのか」「誰のために強化するのか」の両方に答えています。さらにApple TVにも同名の機能があり、Appleエコシステムにふさわしいことも示しています。

組み合わせによる造語: Apple Musicの「AutoMix」は既存の単語ではありませんが、Auto（自動）+ Mix（ミックス）という組み合わせによって、曲間のつなぎを自動処理する機能だとすぐに分かります。造語の明確さは、単語そのものではなく構成要素から生まれます。

詳細

名前を具体的に評価する方法

(08:35) Appleはシンプルなテストを勧めています。候補名を日常会話やインターフェイス文言の中に入れてみることです。

たとえば「Private Memories」を試します。

“Hey, check out Private Memories”
“Just search for Private Memories”

読んでも聞いても自然でなければ、疑うべきです。「Visited Places」は会話の中で自然に流れることが、選ばれた重要な理由の1つでした。

命名におけるトレードオフ

(04:51) フィットネスジムAppのサブスクリプションプランでは、「Basic Access」と「All Access」は明確で分かりやすい名前です。これを「Lightweight」と「Heavyweight」に変えると、楽しくブランドらしくはなりますが、ユーザーはその2語が何を意味するのかを追加で理解しなければならず、学習コストが増えます。

ここに絶対的な正解はありません。明確さを優先する場面もあれば、ブランドを優先する場面もあります。重要なのは、その機能がどこにあり、どれほど重要かに応じて、どの基準を優先するかを決めることです。

命名は複利になる

(14:15) よい名前はパターンを作ります。あるページで「Places」を明確に使えれば、関連するすべての機能で同じ語根を再利用でき、認知コストと翻訳コストを大きく下げられます。1つのよい名前は、次の名前を付ける作業を楽にします。

重要ポイント

1. 既存App内のすべての名前を監査する

アプリを開き、すべてのボタン、メニュー項目、設定スイッチの名前を1つずつ確認します。Appleの3つの基準でふるいにかけます。このアプリにふさわしいか。正しい期待を作っているか。他の言語でも成立するか。

2. Figmaでのデザイン段階に命名レビューを入れる

開発段階まで文言を後回しにしてはいけません。デザイナーがFigmaでボタン名を付けるとき、開発者も一緒にThink-Feel-Doフレームワークを確認します。削除ボタンに「Let it go」という名前が付いていたら、Expectationsの原則で反論します。明確さが損なわれると、ユーザーの混乱に直結するからです。

3. 金融・取引系Appの命名ブラックリストを作る

Apple Cashの例は、金額、ポイント、限度額を扱うすべてのAppへの警鐘です。ユーザーの資産価値を主観的に評価するような語で表現してはいけません。「Spending Power」は残高が0のとき皮肉に変わります。「Balance」こそ安全な選択です。

4. 造語や比喩にはアクセシビリティラベルを補う

UI上の名前がブランドトーンのために比喩や短い造語になっている場合、accessibilityLabelで実際の機能を明確にする必要があります。見た目には「AutoMix」と表示されていても、VoiceOverでは「自動ミックス、曲をシームレスにつなぐ」と読み上げられるべきです。

5. チーム横断の命名用語集を作る

検証済みのよい名前を、チーム共有の用語集として整理します。Apple Mapsは画面全体で「Places」を一貫して使っています。この一貫性は偶然ではなく、意識的なデザイン判断です。あなたのチームにも「このAppにふさわしい言葉」があるべきです。