「他部門の人がどう考えて何をやっているか、エンジニアにどうして欲しいと考えているか話してもらうという企画を考えてるんですけど、ダイゼンさんにお願いしても良いですか？」

ある日、エンジニアの同僚からSlackでメッセージが届きました。

・
・
・

コミュニティSaaSコミューン株式会社でUXライターをしているダイゼンナツミです。コミューンに入るまではスプレッドシートでテキストを渡したり、Figmaでやりとりすることが多かったのですが、今はGitHubでコミットするようになってしまいました。

ふと考えると「エンジニアでもないし、コードを学んだわけじゃないのに、なんでわたし、コミットしてるんだろうー」と思う時もあります。
でも、UXライターとして実装までできると、見える世界がググッと広くなったことに気づきました。

UXライターの立ち位置

このすべての矢印をつなげるのが「言葉」で、一直線に繋げるのがわたしの役割です。

業界だけで使われている言葉がいくら馴染みがあっても、他の人には届かない時があります。
つまり、誰もが理解できる言葉に翻訳するのがUXライターの役割です（前職では通訳だったので、今も同じことをやってるということに改めて気付かされます）。

コミット前のUXライターのわたし

以前はUXライターはコードを覚える必要がないと思っていました。

使うツールが増えると認知負荷が上がってしまうし、そもそもテキスト体験から実装まで考える余裕がありませんでした。

さらにコミットする前までは次のような形で働くことが普通だったので、わざわざコードを覚える必要がありませんでした。

• Figmaでデザイナーさんが作ったUIにテキストを追加

• スプレッドシート上でUIテキストを作成

もちろん、自分で実装できないことによって起こるデメリットがあるということもすでにわかっていました。

• 実装されるまでどんな挙動かコンテクストかわからない

• すぐに変更できないので、担当者に都度お願いする必要がある

スプレッドシートでの作業はUXライティングでの仕事ではなく、スペイン語への翻訳だったので「半分翻訳だから仕方ないよね〜」ということで妥協していましたが、案の定追加で調整依頼が来ました。

だけど、わたしはHTML、CSS、Java Scriptをかじった程度。正直コードを触らずに生きていけるなら良いな〜と淡い幻想を抱いていました。

しかし、コードを触らないとプロダクトのテキストは一向に変わらないことはわかっていました。
その時タイミングよく、英語のテキストを翻訳してローカライズしていたグローバルチームでもテキストに関する課題があることがわかりました。

「一緒にやりませんか？」と、グローバルチームの同僚が声をかけてくれ、「UXライターがプロダクト内の日本語英語すべてのテキストを見ます！」とすべてのテキストの責任を負うことを決めました。
そして、TypescriptとJSONファイル内のテキストを触ってGitHubにコミットをするということを覚える事になるのです。

見えていなかった世界が見えてきた

何回かコミットを繰り返して、自分が判断したテキストがプロダクトに実装されるようになりました。

すると、コミットをする前では想像していなかった多くの良いことを発見できるようになりました。

UIを画面上見て体験できる

実際に動く挙動も自分で確かめることができます。前後のコンテクストを画面遷移をしながら体験することで、より最適なテキストを発見したり、既存のテキストの違和感を感じることができます。

使っている人は点で物を見ません。線で見ます。この線の違和感に簡単に気づくことができるようになったのです。

例え、すべての表記揺れを直したとしても、使っている人にとっては重要ではなく、気づかないことのほうがほとんどかもしれません。重要なのはユーザーフローの中で違和感がないかということです。
表記揺れを直すことに捉われるのではなく、文脈を理解できるので、「表記揺れ＝悪」という考えを捨てることができました。

マージされるたびに共通言語が作られていく

コードの言葉を変えて、プロダクトの言葉が変わると、自然と開発からエンドユーザーまで同じ言葉が使われているということに気づきました。

わたしが大声で啓蒙活動するよりも、コード経由で発信する方が早かったのです。

UXライティングで解決できる問題の発見がしやすくなった

コードの構造を知ることで、エンジニアやデザイナーが入らないといけなさそうな課題でも、テキストだけで解決できるということに気づくことができました。
実は角度を変えればテキストだけで解決できることってあったんです。

こうしてUXライティングで対応できるということが徐々に社内で浸透した結果、いいムーブメントが起きています。

UX負債がより立体的に

プロダクトをさわれば負債があることはわかるかもしれません。しかし、なぜ変更ができないのか、なぜこの状態になっているのか、そしてどうしたら解決方法を見つけることができるのか、ということがコードの構造を見ることで理解し始めていることに気づきました。

お作法を見出す

さらに、UXライティングをよりプロダクト開発の中に組み込まれていくに従い、開発チームのお作法を理解できるようになりました。

わざわざ外部ツールのドキュメントを見ない

書いたテキストはすべてドキュメントには残しており、Style Guideとして誰でもみれる形で残しています。
しかし、わざわざStyle Guideを見ることはないかもしれませんし、守るべきこととしてのドキュメントでもありません。

あるとき、エンジニアさんが新しいテキストのレビュワーとしてわたしをメンションしたときに気づいたことがありました。
すでに記法をそろえていたテキストを真似てテキストを書いてくれていたのです。

コード上に「プロダクトにはこう書く」というのをいろんな箇所で反映させておけば、それをエンジニアさんが真似してくれるんだと。

コードの中で見えないコミュニケーションが行われていたことに感動をしました。

レビュワーフレンドリーなコミットをしようと心がける

一刻でも早く、言葉の揺れをなくしたい。
だから、各ファイル1箇所しか変更がないにも関わらず、数10件のファイルを一気に変更して事故を起こしかけるということがありました。
そのときに気づいたのが、レビュワーさんの負担が増えてしまったということ。
テキストの改善はスクラムの中で行われていません。さらに、機能的に大きな変更をするわけではないので、もう少し細かく、変更を切り離して行うようになりました。
小さく何回もリリースする方が、大きく一気に行って事故が起きるよりよっぽど良い。

もちろん開発の難しさ、もどかしさを感じることがありますが、結果として、UXライターがテキストのデリバリーもできるようになりました。そして、言葉の細部までに責任を持つことができ、プロダクトのテキスト体験を結果として向上させることに繋がっています（と信じています）。

まとめ

はい、良いことしかありませんでした。

UXライターが仮説を立てて、軽くテキストを入れ替えて、社内やクライアント、ユーザーの反応を見ることができ、ダメだったら、また検証がすぐにできる。

そして、小さくサイクルを複数回繰り返すことで、テキストによる体験のインパクトが徐々に組織の中、ビジネスサイドにも届くようになったように思えます。実際に、社内から「xxってUXライティングで解決できない？」と相談があることも。

UXの負債をテキストで減らせるところは小さく動いて減らしていく。この活動ができるのもエンジニアさんの日々のサポートのおかげなので、改めて感謝したいと思います。

*後日談

エンジニアの会に参加した時の、Zoom内でのコメントが最高だったので、ここに載せておきます。UXライティングがゼロからイチ、ニ、サン、と大きくなってきたな〜をジワリと実感した瞬間でした。

それでは、どこかの誰かに役に立ったと信じて…！