UXライター歴2/3年の私が、UI文言をつくるときに考えたりやったりしていること
目次
こんにちは。ブログをNext.jsからAstroに移行した記念に、記事を書くことにしました。
私がUXライターとしてお仕事をはじめて、だいたい2/3年くらいたちました。本当は半年の段階で振り返りたかったのですが、時間が取れず…
今回は、UXライター歴2/3年の私が、今、プロダクト上のUXライティングをする上で気をつけていることを書いてみます。
正しい言葉かどうかに気を配る
当たり前に思えるかもしれませんが、正しい言葉かどうかに気を配るのは、UXライターとしてお仕事をする上での第一歩だと思います。
何気なく使われている言葉や記号に対し、「この使い方でよかったっけ?」という疑問を持てること。けっこう大切だなぁと感じています。
例えば…
- 設定することができます→設定できます
- 「することができる」は冗長
- 変更のない vs 変更がない
- 「ガノ交替」と呼ばれる論点で、どちらも文法的には正しい
- 「の」が続いて目が滑るなら、「が」に置き換えるとか
『日本語スタイルガイド 第3版』を読むと、こうしたちょっとした違和感に気づけるようになると思います。
ガイドラインを確認する
こちらも初歩的な教訓。ガイドラインに沿った文言かをチェックします。
幸い、弊社には文言に関するガイドラインがあるので、ライター間で揺れの少ない文言を作れます。本当にありがたい。
もし、社内にガイドラインがないなら、まずは自分だけの用字用語集や文言事例集を作ってみるのもアリだと思います。
用字用語や事例が増えてきたら、社内に共有してみる。社内のメンバーが興味を持って、メンテナンスに参加してくれる。
そんな感じでガイドラインに育っていくのかなぁと思っています。
スコープを意識する
プロダクトのUXライターをやっていると、「この文言、気になるなぁ…今回の機能追加のついでに直したいなぁ…」という場面に幾度となく遭遇します。
UI文言なので、その箇所だけを修正するのは、そんなに大変ではありません。
ただ、UI文言というのは、得てして他の箇所と複雑に絡み合っていることが多いです。
- あっちの画面の表記も、今回の変更にあわせて修正しないと…
- ヘルプセンターのスクリーンショット差し替えなきゃ
- いろいろ影響範囲を調査していたら、他にも変更したい文言が出てきたぞ…
良いUI文言を追求すること自体は良いことですが、スコープを意識することも大切だと日々感じています。UXライティングに限った話ではありませんが…
ユーザーからの問い合わせをウォッチする
プロダクトに対するユーザーの問い合わせをまとめています。
普段から問い合わせの内容に触れていると、わかりにくいUI文言に気づけるだけでなく、普段ユーザーがどんなふうに機能のことを呼んでいるのかも知ることができます。
問い合わせを受動的にまとめるだけでなく、必要であれば、ユーザーといつもコミュニケーションをとっているカスタマーサポートにヒアリングすることもあります。
既存ユーザーと新規ユーザーがいることを意識する
いまのところ、自分は「まったく新しいプロダクト立ち上げ」ではなく「既存プロダクト内の新機能」に関わることが多いです。
既存プロダクト内に新機能を追加するとき、いつも注意しているのが「新機能が追加される前からプロダクトを使っていた既存ユーザーと、追加されてからプロダクトを使い始める新規ユーザーがいる」点です。
ここを意識していないと、既存ユーザーにしか伝わらない文言を作ってしまいがちだなぁと感じています。
例えとして適切かはわかりませんが…
「コカ・コーラ ゼロ」っていう商品、ありますよね?砂糖が入ってないコーラ。
商品名の「ゼロ」は、「普通のコーラには砂糖が入っている」ことが前提になっています。
でも、コーラをまったく知らない人が、「コカ・コーラ ゼロ」の商品名を見たら、どう思うでしょうか?
「何がゼロなんだ?」と思う人がいるかもしれません。
他にも「現金」なんか、似たような事例かもしれませんね。クレジットカードや商品券など、「現ではない」決済手段が出てきた結果、古い方の手段を再定義したためにできた言葉です。
こんな感じで、ある概念を追加するときは、既存の概念との関係がわからなくても理解できるように意識して文言を考えています。もちろん、既存の機能とまったく無関係な命名は無理ですが…
コーラの例で言えば、「コカ・コーラ ダイエット」になる、という感じですね。
若干話がそれましたが、既存ユーザーと新規ユーザーで、持っているコンテキストが全然違うので、意識しています、というお話でした。
「ひと言め」を大切にする
何か新しい機能を開発するとき、その機能には必ず「仮の名前」が付けられます。
コードネームかもしれないし、とりあえずつけた機能名かもしれないし…
とにかく、開発メンバー全員がコミュニケーションをとる上で、機能に対してなんらかの名前は必要です。
私の考えですが、そんな「ひと言め」の名前は、開発中の文言検討に大きな影響を及ぼします。
例えば…
「システム上のデータをCSVでダウンロードできる機能」が、ユーザーから求められ、開発が決まったとします。
開発メンバーはとりあえず「CSVエクスポート機能」と、その機能を呼ぶことにしました。
仕様検討が進むたび、メンバーの中で「CSVエクスポート機能」という名前が定着していきます。
ある段階で、「そろそろ正式名称を決めようか」という話になり、UXライターが検討を始めます。
『うーん、「エクスポート」はITに詳しくない人には馴染みが少ないから、「書き出し」にしよう。CSVはそのままでいいかな』
こうして、「CSV書き出し機能」は無事リリースされました。
…「ファイルで保存機能」の方が、ユーザーにとってわかりやすい命名だったかもしれないのに。
こんな感じで、最初に「とりあえず」で命名した「CSVエクスポート機能」が、その後の概念・文言の検討の土台になってしまうことがあります。
もちろん、既存の概念にとらわれず、ユーザーの声を聞き、概念を定義し、わかりやすい文言を作るのがUXライターの仕事ではあります。
ただ、一度頭に入った名前が規定する概念から脱出するのは、相応のエネルギーが必要ですし、もともと名前がなければ不要なエネルギーでもあります。
UXライターの仕事を楽にするために、「ひと言め」をおさえにいくのが大切だと感じています。
同じような教訓に「自分が書いた文章は、一晩寝かせて読み返した方がいい」というものがあります。記憶は怖い…。
まとめ
UXライターは、言葉を武器にお仕事をする職業です。
そして、言葉は、UXライターだけでなく、誰もが使えます。この「誰もが使っているもの」を仕事道具とすることに、私は面白さを感じています。
プログラマーのように、コードが読めないと一緒に仕事ができないわけではないし、
弁護士のように、六法全書が頭に入っていないと議論できないわけでもない。
こう書くと怒られるかもしれませんが、UXライティングは、誰もが議論に参加でき、一緒に考えることができるテーマだと思っています。
いろんなバックグラウンドをもった人たちと、言葉という共通の道具を通じて、あーでもない、こーでもない、と悩み抜く。多様な視点が集まって、よい言葉が生み出されていく。自分の視点が、どんどん広がる。
その過程に魅力を感じています。
というわけで、書けばキリがないですが、いったんこのへんで終わります。また追記するかも。