見出し画像

ライティングを終える方法 / UX DAYS TOKYO2023 ワークショップ参加レポート

これ、締切まで余裕はあるけど、ライティングの決めのタイミングを見失う。
書いたはいいけど、編集作業すればするほど、ボロが見つかって「ぎゃー書き直しやん」という終わりのない作業をしてしまう。


そう、ライティングには終わりはないのです。知らない間に永遠に書いているかもしれません。




さて!コミュニティSaaSを提供するコミューン株式会社でUXライターをしているダイゼンです。
先日UX DAYS TOKYO 2023が開催され、コンテンツストラテジストで、Writing for designerの著者Scott Kubieさんのワークショップに参加したので、その時の学びをまとめてみました。

このワークショップで、わたしはライティング前のプラン作成と、デリバリー後のまとめが不足していたことに気がつきました。一度ワークフローをなぞることで、自分の抜けに気づくかもしれません。ではどうぞ!

*ワークショップ内でScottさんが手書きのプレゼンを用意していて、その手書きのイラストにインスピレーションを受け、随所にイラストを差し込んでいます。

どうやってライティングを終わらせるのか?

終わりはどんなタイプのライティングでも存在します。しかし、どのライティングでも、何を書くのか、どのような範囲をカバーするのか、ライティングのアサインメントを明確にする必要があります。

アサインメントが明確になると、どの段取りで進めるかの枠組みを作ってくれるワークフローが必要です。ワークフローは何回戻ってもいいし、ワークフロー内のプランを立ててステップごとに必要な時間配分やリソースを考えることができます。

最後に付け加えると、書く人が必要です。あなたのチームにライターはいますか?できれば専属の人が望ましいです。

アサインメントはPdMから与えられている!ライターは組織から任命されているわたしだ!しかし、ワークフローは誰からも与えられません。次の章ではアサインメントをもらってからライティングを終えるまでをなぞっていきましょう。



本題に入る前に、わたしの仕事で実際にあったタスク「アカウント登録画面でのメール受信設定のオプトアウトテキスト」を例に解説していければと思います。

ライティングをDoneするためのワークフロー

さて、さっそくワークフローに入る前に、最もわたしが苦手なことをしなければなりません。

そ・れ・は、プランを立てること


ライティングを終わらせることをゴールにして考え、ワークフローの中でどういう風にUXライターのリソースを使うかということを計画的に考えます。各ステップでどれくらいの時間を費やすか、何をするかを、ワークフローを始める前に決めておきましょう。

プランは強力です。それが見積もりになったりします。

準備は全体の50%、構成は20%、編集は20%、完了は10%くらいの気持ちです


1. Prepare 準備 📄

プランを立てたら始めましょう。ライティングのための準備をしましょう。一番時間をかけましょう。
準備をちゃんとしておけば、より多くのアウトプットを生み出すことができるし、他のステップをスムーズに進めることができます。


さて、準備ですることをチェックしていきましょう。

Article the assignment アサインメントを整理

ライティングの方向を定めるためにも、次の項目を整理します:

  • 役割

  • 締切

  • コンテクスト

  • 制約

  • 範囲

👉 アカウント登録画面でのメール受信設定のオプトアウト」での例
役割:UIテキストのライター
締切/期間:3週間
コンテクスト:ユーザーは、コミュニティのアカウントを持っておらず、登録する画面にいる。コミュニティ内で通知メールを送るため、メール送信の許可をアカウント登録時にチェックしてもらう必要がある。
制約:チェックボックスの横に表示され、スマホでも改行せずに見ることができる長さである。則る法律に遵守している。エンドユーザーだけでなく、クライアントの要望(通知をオプトアウトしてほしくない)も叶える必要がある。
範囲:登録画面に表示されるチェックボックスのテキスト

Collect inputs インプットを集める

アウトプットの参考となるものを探します。何が使えるかわかりません。以降のステップで検証するための、ヒットを打てるボールをたくさん集めます。

インプットには、ユーザーインタビューの結果やユーザーレビュー、会議での議事録、競合や類似サービスのベンチマーキング情報などを含みます。

👉 アカウント登録画面でのメール受信設定のオプトアウト」での例
UIの調整や法律要件の解釈で、何回もインプットをし直しました。
1回目
・法律要件を読む
・Slackを読む(なぜ開発するに至ったのかの背景を理解)
・いろんなサービスのアカウント登録画面のスクショ

2回目
・法律要件を再読
・UIでの制約アップデート

3回目
・法務担当者と顧客担当者のやりとりが見えるSlackを読む
・法律要件を再読

Generate ideas アイデアを出していく

アイデアを出している時は、ルールに関係なく可能な限りアイデアを出しましょう。アイデア出しに役に立つ方法をシェアします:

・マインドマッピング

思考を整理するために活用できそうです。これまで準備した情報をランダムに書いて、関連のあるもの同士で繋ぎ合わせます。
繋げることでアイデア(テキスト案)を形成することができます。さらにアイデアを繋いで、アイデア自体を深掘りし、関連性を発見することができます。

・フリーライティング
カフェで書いたり、散歩中にアイデェーションをしたり、環境を変えながらライティングしましょう。
ライティングをするときは、削除せず、書き直しもせず、履歴を残しておきます。
そして、一気に書き上げるのではなく、ひとつずつ案を出します。UIならコンポーネントごとのテキストをひたすら10個書いてみる、とかですね。


Create structure 構造をつくる

書けそうなアイデアが出始めたら、アウトラインを作ってみましょう。どんなアプローチなら解決できるか、ここでもアイデアを出しながらアウトラインを作っていきます。

「なんのために何を誰のために」が明確になっているストーリーからアウトラインを書いていきましょう。

👉 アカウント登録画面でのメール受信設定のオプトアウト」での例
最初の案ではツールチップを採用して、各メールの内容を細かく説明する仕様でした。
しかし最初のアカウント登録時では、多くの情報を提供しても、ユーザーにとってはノイズになるのでは、と考えました。
なぜなら人間の認知能力には限界があり、さらに早くオンボーディングしたいユーザーの気持ちを考えると、できるだけフラストレーションはなくしたいものです。もしくは、ユーザーの意思決定に影響があるような場面では、ユーザーはより慎重になっているため、多くの情報を読むことによって、メール通知を解除されてしまう可能性も出てくるでしょう。

UIデザイナーとも話し合い、ツールチップの使い方を考えても、この画面では相応しくないということで、ツールチップの配置をやめました。

この段階で、簡単なラフをPdMとUIデザイナーに共有をしました。意見をもらい、UIのチェックボックスの上にタイトルとなるテキストを挿入することにしました。
これで、大まかなUIとテキストの構成がLow fidelityで出来上がりました。

決まったドラフト

2. Compose 組み立てる 🔨

準備ができたら、書いたものを整理して、組み立てていきましょう。
最初は100%のパワーを使って書かずに、UXライターもLow fidelityから始めます。徐々に形を作っていき、High fidelityに仕上げていきます。

さて、どうやって書いていけば、要件にあうライティングに辿り着くことができるのでしょうか。
ScottさんはACBという方法を使ってライティングをブラッシュアップしていく方法を紹介しています。

Accurate 正確さ

制約には収めなくていいので、正確に伝えたいメッセージをすべて書きましょう。とにかく、伝えたい内容をすべて含めます。
関係者に内容の確認をお願いしたり、ヘルプページで事実であることを確認してもいいかもしれません。

Clear 明確さ

正確に書いたライティングを理解しやすいように書き直します。明確さは主観的であるため、他の人にもレビューしてもらい、客観的に明確であることを目指しましょう。
声に出して読み上げてみたり、録音してユーザーが使いそうな環境で聞いてみたり、1日テキストを寝かしたり、他のメンバーにレビューをしてもらったり、いろいろな方法で確認しましょう。

今回のワークショップで、Scottさんはペアライティングをオススメしていました。ライターと主題専門家(タスクのオーナー)に分かれて、主題専門家がライターに書いてほしい要件を伝えて、同期的にライティングを進めていく手法です。
書いている段階で、客観的な視点を取り入れられ、より要件に近づけられるようなライティングができます。

Brief 簡潔さ

最後のステップで、明確になったライティングをさらに短く削っていく作業です。Scottさんは、さらに10%減らす努力をするようにと言っていました。
読んでもらえなければ、ライティングの価値はゼロになります。だから読んでもらう、もしくは認識してもらえる長さにします。

わたしの場合、プロダクトにボイスアンドトーンが揃っていれば、ClearとBriefの間に間に「会話的である」や「ボイスに沿っているか」を入れてライティングをする時もあります。


このCompose 構成のステップでも、必ずライティングのログは残すようにしましょう。

3. Edit 編集 👀

編集は見直しや修正ではなく、Rewriteする、もう一回書いてみる作業です。

Rewrite 書き直す

Rewriteするときは、「何のために編集をするか?」というレンズによって編集のやり方が変わります。例えば次のようなレンズを通して編集してみます:

  • 要件通りか?

  • アクセシビリティに配慮されているか?

  • 一貫性はあるか?

  • 読み手にとって読みやすいか?

  • インパクトはあるか?

Tone is finger トーンを整える

「どんな風に聞いて欲しい?」「聞こえているべき?」ということを意識して、ライティングのトーンを調整します。ここは必ず人間が行う作業です。

ChatGTPでもライティングはできるかもしれませんが、文脈を読んだり、トーンを調整するのは人間です。
ギターの弦は音を聞きながら調整しますよね?

Feedback フィードバックを受ける

客観的なレビューを受け入れましょう。積極的に関係者を巻き込んでレビューを依頼しましょう。


さて、編集ステップでは「どんな意図」で、「何を変更するのか」を明確に文章にしておくことが重要です。何回も強調しますが、ログを残しましょう。

そして、ユーザーにとって本当のことが書かれているか、客観的な視点で確かめます。
この編集ステップは急がず、フォーカスしていることから離れず、質の高いテキストをアウトプットを出すように意識しましょう。

👉 アカウント登録画面でのメール受信設定のオプトアウト」での例
他のメンバーからのレビューでは、ABCすべてのバージョンを作ってシェアしました。
以下は実際に書いたオテキストです:
Accurate: 「コミュニティの最新情報や通知をお届けします。受信を希望しない場合はチェックボックスの選択を解除してください。メールの受信設定はマイページからいつでも変更可能です。サービス利用上の重要なお知らせは設定に関わらず送信されます。」
Clear: 「コミュニティの最新情報や通知をお届けします。メールの受信設定はマイページからいつでも変更可能です。サービス利用上の重要なお知らせは設定に関わらず送信されます。」
Brief:「コミュニティの最新情報やあなた宛の通知をお届けします。マイページからいつでもメールの受信設定を変更できます。」

実は、このACBのレビューをしてもらうまで何回かドラフトを共有しましたが、法律要件を満たせていなかったりと、Compose と Editは何回も行き来しました。
法務的にBriefでは言葉が足りない部分もありましたが、カスタマーサクセスチームへのヒアリングを行い、最終的にBrief案で決定することになりました。
今回は法律、ユーザー、クライアントにインパクトがある変更であったため、多くの人からフィードバックを受けて最終的な案を決めるに至りました。

また、わたしは多言語化のテキストも担当しているため、日本語のテキストの方向性が決まった時点で英語のテキストをComposeとEditを行き来しながら進めていきました。
アメリカ市場版のPMMにローカライズチェックをしてもらい、英語版も同時にリリースまでに揃えることができました。

4. Finish 完了 🏁

このステップは、あなたが書いたコンテンツに主導権を持たせるリリースの時なのです!(やったー)
毎回我が子を送り出すような感覚でリリースをしています。

このステップでは、テキストに綴り間違いがないかなど、チェックリストで品質を確認します。

そして、今まで残していたログなどをまとめ、ドキュメント化します。具体的には「誰が何をいつなんのためにどんな変更をしたのか」を残しておき、未来のために、またなぜ変更したのかという背景を問われた時のために記録を残します。
さらに、可能であれば他の部署にもシェアして、背景を理解してもらうということも行ってもいいかもしれません。

Finishの最後もきちんと時間を費やしましょう。
このタスクを見つめ直し、ワークフロー自体を見直します。必要であれば品質を管理するチェックリストも更新。コンテンツをトラッキングしているなら、更新を忘れずに。

👉 アカウント登録画面でのメール受信設定のオプトアウト」での例
最後はFigmaのファイルに新しいページを作成し、FIXした日英テキストとデザインを置いておきました。
Figmaはエンジニアがテキストをコピーする場所なので、ここの誤字脱字がないかを最終チェックします。
最後は、追加したテキストや変更したテキストの更新履歴をテキストトラッキングシートに反映させてクローズしました。

実際のワークフローに反映させてみて

2週間ほど、Scottさんのライティングのワークフローを導入してみて良かった点がありました:

  • ワークフローをなぞることで、ライティングフローの中での穴が見つかった

  • フローの行き来が簡単

  • ドキュメント化する前提でワークフローシートを作ったので、最後の整理が楽になった

  • 削除しない、上書きしないを意識することで、なぜこのアウトプットに至ったかの理由が明確になる

もちろん組織のあり方やプロジェクトの進め方によって、不必要な部分があったり、追加することもあるので、カスタマイズして活用できるのかなと思います。





オフラインでUXライティングに関するワークショップに参加したのは初めてで、ライティングに関わる人たちと関われたり、他の組織でのライティングの関わり方を知る良い機会となりました(ひとりでやってると「だよねー」という共感が欠けてしまって、負のスパイラルに陥ることがある)。

いやー、楽しかったです。プランの立て方や準備の重要性、そしてアサインメントの整理方法について学べたかと思います。このnoteを通して、ライティングに携わる人たちがより良いアウトプットを生み出せるようになることを願っています!


この記事が気に入ったらサポートをしてみませんか?