← エピソード一覧に戻る Episode 189 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― 文章は飾りではなく、業務フローそのもの
タカシ
今日は SaaS デザインのコンテンツデザインです。見た目は整っているのに、なぜか設定で詰まる、通知の意味が分からない、エラーを読んでも直せない。そんな SaaS は、機能不足より先に言葉の設計で損をしています。
ミカ
たしかにあります。画面はきれいなのに、ボタンの言い方と通知の言い方が違っていて、結局これ何が起きたのってなるやつです。文言って最後に入れるおまけみたいに見えるけど、実はかなり本体なんですね。
タカシ
その通りです。Shopify はアプリ向けの公開ガイドで、平易な言葉を使い、読む負荷は米国7年生レベルを目安にし、さらに重複した説明を避けるよう求めています。つまり良い SaaS は、読む量より迷う量を減らそうとしているんです。
ミカ
7年生レベルって、かなりはっきりした基準ですね。難しい言い回しで賢く見せるより、すぐ動けることを優先している。B2B SaaS って高機能だからこそ、言葉で賢ぶると逆に導入が遠のきそうです。
Chapter 2 原則 ― コンテンツデザインは、UIの説明ではなく判断の設計
タカシ
GOV.UK の UI ライティング指針には、もし画面の使い方を言葉で説明しなければならないなら、設計自体に問題がある、とあります。これは SaaS にもそのまま当てはまります。文言の仕事は説明を増やすことではなく、迷いを消すことです。
ミカ
なるほど。ヘルプを増やす前に、そもそもそのボタン名や順番で迷わないかを疑うべきなんですね。たしかに『この画面の使い方はこちら』が長い SaaS って、ちょっと嫌な予感がします。
タカシ
さらに重要なのが用語の一貫性です。GitHub Primer は、操作を起こした UI の言葉と、その結果を示すフィードバックで同じ用語を使うべきだと書いています。ボタンは transfer なのに、通知では moving と書くと、それだけで認知負荷が上がるんです。
ミカ
それ、SaaS でよくありますね。営業資料ではワークスペース、ヘルプではプロジェクト、画面ではボード、みたいな。機能は同じでも、言葉が揃っていないだけで学習コストが増えて、サポート窓口が通訳みたいになります。
Chapter 3 実務 ― Shopify、Atlassian、GitHub、Mailchimpは何を揃えているか
タカシ
Shopify は、見出し、箇条書き、短い文でスキャンしやすくし、CTA は強い動詞から始めるよう勧めています。加盟店は世界中にいて、英語が第一言語とは限らないからです。グローバル SaaS ほど、平易さは優しさではなく競争力なんですね。
ミカ
たしかに『設定を完了するための処理を開始』より『設定を保存』のほうが速いですもんね。難しい概念を載せる画面ほど、文言は簡単でないと読み切れない。SaaS の高機能化と、言葉の単純化はセットなんだなあ。
タカシ
Atlassian のメッセージ指針も実務的です。成功メッセージは1から2文、CTAは1から2語、不要な技術情報は入れない。『Success!』と祝うより、何が終わったかを確認し、すぐ仕事へ戻れることを優先しています。通知が多い SaaS らしい設計です。
ミカ
通知って短いほうがいいのは分かるけど、短ければ何でもいいわけじゃないんですね。状況が分かって、次の一手も見える長さに整える必要がある。短文って、実はかなり設計の密度が高いんだなと感じます。
Chapter 4 フォームと通知 ― 良い文言は、修正できる失敗だけを残す
タカシ
GitHub Primer のフォーム指針では、ラベルは3語以内を目安にし、足りない説明は caption へ分け、placeholder をラベル代わりに使うなとしています。エラーも『Field required』ではなく、何が足りないかを具体的に書く。直せる失敗に変える発想です。
ミカ
『入力が正しくありません』だけ出るフォーム、ありますよね。どこをどう直せばいいのか分からないから、結局やり直しか問い合わせになる。エラー文って、謝る文章じゃなくて、次の一手を示す案内なんですね。
タカシ
Mailchimp も面白くて、ボタン文言には必ず動詞を入れ、面白さより明確さを優先し、相手の感情に応じて tone を変えると公開しています。請求や障害通知で軽口を叩くのは逆効果です。SaaS の言葉は、文才より状況判断なんです。
ミカ
確かに、キャンペーン作成では少し軽くても、請求失敗で『おっと』は嫌ですね。トーンってブランドの個性というより、その瞬間のユーザー心理への配慮なんだ。コンテンツデザインって、かなり接客に近い仕事ですね。
Chapter 5 まとめ ― 用語集とルールを持つ会社ほど、SaaSは伸びやすい
ミカ
今日の失敗パターンをまとめると、文言を最後に埋める、部門ごとに用語が違う、エラーが曖昧、トーンを遊びすぎる、翻訳や更新の運用を持たない、このあたりですね。見た目より静かな問題だけど、全部じわじわ効きそうです。
タカシ
ええ。まずは新規登録、初回設定、検索、請求、権限変更の5フローで、画面名、ボタン、通知、エラー、ヘルプ文を棚卸ししてください。そして同じ概念に同じ用語を割り当てる。ここを揃えるだけで、体感品質はかなり上がります。
ミカ
ルールとしては、ラベルは短く、CTA は動詞で始める、補足は必要なときだけ、エラーは直し方まで書く、って感じですね。これをデザインシステムに入れておけば、新機能を作るたびに文言がバラけるのも防げそうです。
タカシ
その通りです。コンテンツデザインはコピーの磨き込みではなく、顧客の判断コストを減らす経営施策です。言葉が揃った SaaS は、導入も運用もサポートも速くなる。ぜひ皆さんのプロダクトでも、まずは用語の棚卸しから始めてみてください。