Product-Writing

SmartHR社内で2023年下期に開講した、第1期プロダクトライディング講座の初回講義のスライドです。

【更新情報】
2004年3月8日：第2期プロダクトライティング講座の内容に差し替え

Transcript

1. © 2024 Aguri Otsuka All Rights Reserved. プロダクトライティングの考え方 第2期プロダクトライティング講座
2. © 2024 Aguri Otsuka All Rights Reserved. 今日話すこと ・ プログラムとテキストの違い ・ 業務アプリケーションとメンタルモデルの関係 ・ 大切なのは視座の切り替え ・ 命名・分類・構造化 ・ プロダクトライティングの技術
3. © 2024 Aguri Otsuka All Rights Reserved. プログラムとテキストの違い
4. © 2024 Aguri Otsuka All Rights Reserved. して欲しい動作 〇〇して ほしい コード 処理 動く 〇〇する
5. © 2024 Aguri Otsuka All Rights Reserved. テキストもプログラムと目的は同じ テキストコミュニケーションの目的 読んだ人を、〇〇な状態にする
6. © 2024 Aguri Otsuka All Rights Reserved. 〇〇して ほしい 伝えたいこと テキスト ふむふむ 処理 〇〇 しよう！ 伝わる
7. © 2024 Aguri Otsuka All Rights Reserved. 伝えたいこと 〇〇して ほしい テキスト ふむふむ 処理 ▲▲ したく なった！ 伝わらない
8. © 2024 Aguri Otsuka All Rights Reserved. テキストコミュニケーションは うまく伝わらないことがある
9. © 2024 Aguri Otsuka All Rights Reserved. コミュニケーションの 主導権を持っているのは、受け手 伝わるかどうかの鍵
10. © 2024 Aguri Otsuka All Rights Reserved. 伝わるかどうかの鍵 コミュニケーションの 主導権を持っているのは、受け手
11. © 2024 Aguri Otsuka All Rights Reserved. 残念ながら読まれない場合もある… 出典：「論理が伝わる　世界標準の「書く技術」」倉島保美 　読み手は、まず、その文章を読み進むべきか、 読むとすればどの程度の優先度なのかを判断しま す。読み手は、手にした文章のすべてを、手にし た順に読んでいくわけではありません。詳細まで 読まなければならない文章もある一方、概略だけ で十分と思う文章もたくさんあります。今すぐ読 むべき文章もあれば、今週中に読めばいいと判断 する文章もあります。どんな文章であろうと、決 して全員が詳細まですべてをその場で読むわけで はありません。 　この判断が素早くできるよう、伝わる文章で は、大事なポイントが30秒で分かることが必要 です。
12. © 2024 Aguri Otsuka All Rights Reserved. 人間の“認知” 入力と出力の仕組み
13. © 2024 Aguri Otsuka All Rights Reserved. 出典：海保博之. 「心理学者が教える 読ませる技術 聞かせる技術 心を動かす、わかりやすい表現のコツ」 わかるとは、 入力情報が、人間の情報処理系の中で適切に処理されて、 頭の中に格納されている既有の知識に同化させることができたか、 あるいは既有の知識をうまく調節できることである 認知心理学における「わかる」の定義 既有の知識に 個人差がある 「わかる」の仕組み
14. © 2024 Aguri Otsuka All Rights Reserved. 「わかる」の仕組み 入力情報を処理するときに 作用するのが、 ユーザーごとのメンタルモデル
15. © 2024 Aguri Otsuka All Rights Reserved. ちょっとズレ埋め モデル？
16. © 2024 Aguri Otsuka All Rights Reserved. 認知心理学における「モデル」 科学的な
 モデル
 ではない！ 長期記憶の中に作られた「一貫した」知識のまとまり 知識を構成している要素間の様々な関係 によって、作られている
17. © 2024 Aguri Otsuka All Rights Reserved. メンタルモデルと科学的なモデルの違い メンタルモデル 「知識のまとまりをつけている関係が多彩」 科学的なモデル 「演繹論理」や「帰納論理」 さまざまな事実や
 事例から導き出される 傾向をまとめあげて 結論につなげる 一般的かつ普遍的な 事実を前提として、 そこから結論を導きだす
18. © 2024 Aguri Otsuka All Rights Reserved. メンタルモデルの具体例を見てみよう！ 出典：海保博之「心理学者が教える 読ませる技術 聞かせる技術 心を動かす、わかりやすい表現のコツ」 　我々は、自分の身のまわりの環境について、一定のまとまりのある認識を持ち、それに基づ いて環境に働きかけている。机があり、パソコンがあり、本箱があり、……という認識ではな く、「机の上にパソコンがあり、机の左側に本箱がある、……」という具合に、あるまとまり をもった世界、別の言い方をするなら、部分と部分との間に関係のついている世界を自分の頭 の中に作り上げる。そのような一貫した認識があるからこそ、本を取るときは左手をのばし、 パソコンを使うときは机の前に座るという行為がスムーズにできる。 　文化や生活習慣がまったく異なる外国へ行ったときのように、きわめて目新しい場面に直面 したときや、瞬間的に強いストレスにさらされたりして自分の情報処理系が何らかの理由でう まく働かなくなってしまったときなどには、ばらばらな認識が発生する。そして「何が何やら わからない」「何をどうしていいかわからない」となる。 　人間は、普通、自分の身のまわりについて、それなりのまとまりをもった認識をしている。 時には、あまり適切でなかったり、誤っていたりすることがあっても、である。この認識を成 立させているのがメンタルモデルである。
19. © 2024 Aguri Otsuka All Rights Reserved. メンタルモデルの具体例を見てみよう！ 出典：海保博之「心理学者が教える 読ませる技術 聞かせる技術 心を動かす、わかりやすい表現のコツ」 　我々は、自分の身のまわりの環境について、一定のまとまりのある認識を持ち、それに基づ いて環境に働きかけている。机があり、パソコンがあり、本箱があり、……という認識ではな く、「机の上にパソコンがあり、机の左側に本箱がある、……」という具合に、あるまとまり をもった世界、別の言い方をするなら、部分と部分との間に関係のついている世界を自分の頭 の中に作り上げる。そのような一貫した認識があるからこそ、本を取るときは左手をのばし、 パソコンを使うときは机の前に座るという行為がスムーズにできる。 　文化や生活習慣がまったく異なる外国へ行ったときのように、きわめて目新しい場面に直面 したときや、瞬間的に強いストレスにさらされたりして自分の情報処理系が何らかの理由でう まく働かなくなってしまったときなどには、ばらばらな認識が発生する。そして「何が何やら わからない」「何をどうしていいかわからない」となる。 　人間は、普通、自分の身のまわりについて、それなりのまとまりをもった認識をしている。 時には、あまり適切でなかったり、誤っていたりすることがあっても、である。この認識を成 立させているのがメンタルモデルである。 バグの要因 ありすぎ！
20. © 2024 Aguri Otsuka All Rights Reserved. ちなみに、辞書では…
21. © 2023 Aguri Otsuka All Rights Reserved. 語釈は、こう 実際の、仮の、 想像上の状況に対する 心理的なイメージ
22. © 2024 Aguri Otsuka All Rights Reserved. メンタルモデルの特徴
23. © 2024 Aguri Otsuka All Rights Reserved. 1 個人の既有知識によって作られる恣意的なモデルである 2 個人的な体験に基づいて、一貫している 3 世の中や科学的モデルから見て、現実的でないことがある 4 状況に対する知識の量・質に応じて、変わる 5 試行錯誤的に突然変わることがある メンタルモデルの特徴
24. © 2024 Aguri Otsuka All Rights Reserved. 出典：海保博之「心理学者が教える 読ませる技術 聞かせる技術 心を動かす、わかりやすい表現のコツ」 メンタルモデルは、恣意的である モデルはこうでなければならないということがない。 長期記憶にある既有知識の中から、当面する世界と対処するのに使え そうなものを見つけて、「勝手に」一つのミニチュア世界のモデルを 作る。 したがって、同じ文字入力についてのメンタルモデルでも、手書きの経 験しかない山田さんと、パソコン入力を得意とする高橋さんとでは、 まったく異なるモデルを作り上げることの方が、むしろ普通である。
25. © 2024 Aguri Otsuka All Rights Reserved. 出典：海保博之「心理学者が教える 読ませる技術 聞かせる技術 心を動かす、わかりやすい表現のコツ」 メンタルモデルは、一貫している 一度作り上げたモデルは、そのモデルの中では一貫した知識の構造を持っている。た だし、この「一貫した」は、科学者が作り上げるモデルのように論理的に一貫してい るという意味ではない。同じ状況に対しては、いつも同じモデルを使うとか、ほぼ同 じ行動を導くとかいった意味で、一貫しているということである。 この一貫性を支えているのは、個人的な体験である。 状況との体験的なかかわりを通して、メンタルモデルは作り出される。したがって、 知識要素間の関係を特徴づけるのは、論理的な関係よりも、むしろ「あれをしたらこ れが起こった」（因果関係）、「あれとこれとはよく一緒に起こった」（相関関係） などが中核となる。
26. © 2024 Aguri Otsuka All Rights Reserved. 出典：海保博之「心理学者が教える 読ませる技術 聞かせる技術 心を動かす、わかりやすい表現のコツ」 メンタルモデルは、世の中の状況との対応は完全ではない その対象となっている世界との対応は「完全なもの」ではありえない。 だからこそ、いろいろなモデルが作られる。 ましてや、ひとりひとりの心の中に「勝手に」作られるメンタルモデルでは、他人か ら見れば、あるいは、科学的なモデルから見れば、およそ現実的でない、ということ があっても不思議ではない。 ただ、その人にとっては、その対象となっている状況とかかわるのには、当座のとこ ろ不都合はない。だからこそ、一貫してその人はしつこくそのモデルを持ち続けてい るのである。
27. © 2024 Aguri Otsuka All Rights Reserved. 出典：海保博之「心理学者が教える 読ませる技術 聞かせる技術 心を動かす、わかりやすい表現のコツ」 メンタルモデルは、状況に応じて変わる 非常に抽象的な場合もあるし、具体的な場合もある。 また、粗い場合 も、精緻な場合もある。 状況についての知識の量と質に応じて、メンタルモデルは自在にその レベルや内容を変える。 一般には、状況についての知識が貧弱なときにはマクロなメンタルモ デル、 豊富なときはミクロなメンタルモデルが構築されるようであ る。
28. © 2024 Aguri Otsuka All Rights Reserved. 出典：海保博之「心理学者が教える 読ませる技術 聞かせる技術 心を動かす、わかりやすい表現のコツ」 メンタルモデルは、試行錯誤的に状況とかかわらせる エラーをしながら現実の世界からのフィードバックを受けて、モデル は変更されていく。 その変更は、おおむね、突発的で必然性がない。
29. © 2024 Aguri Otsuka All Rights Reserved. つい、“UI/UX”って言っちゃうわけ｜aguringoの個人的な見解です メンタルモデルの特性から考えると、"ユーザーが解釈した"一貫した体験があることは確 かで、自身の経験が一貫していると認識しているので、UIとUXの境目を自覚できないの だと考えられます。 しかし、"ユーザーが解釈した"一貫した体験が提供者が意図した体験とはまったく別物 になる可能性があること、人の認知のシステムから生じる結果は多様でアンコントロー ラブルだということは、プロダクト開発をするうえでつねに意識しておきたい。 個人的には、UIつまりユーザーとの接点を考え作る人たちが無意識に「一貫した体験」 と言ってしまうことは驕りでしかなく、早く捨てた方が良いと思っています。ちゃんと 理解したうえでの謙虚さというか、一種のあきらめを胸に秘めつつ抗う手段が、愚直 に"一貫したものを作る"なんだよなぁって、いつも考えています。
30. © 2023 Aguri Otsuka All Rights Reserved. 広義に捉えられることもあるよ（フォロー） 出典：「UX白書｜はじめに」 ユーザエクスペリエンスという用語は、 ユーザビリティ、ユーザインターフェース、 インタラクションエクスペリエンス、 インタラクションデザイン、顧客経験、 ウェブサイトアピール、感情、＂ワオ効果＂、 一般的経験の同義語として、 また、 これらの全てや多くの概念を包括した用語 として、よく用いられます。
31. © 2023 Aguri Otsuka All Rights Reserved. 広義に捉えられることもあるよ（フォロー） 出典：「UX白書｜はじめに」 ユーザエクスペリエンスという用語は、 ユーザビリティ、ユーザインターフェース、 インタラクションエクスペリエンス、 インタラクションデザイン、顧客経験、 ウェブサイトアピール、感情、＂ワオ効果＂、 一般的経験の同義語として、 また、 これらの全てや多くの概念を包括した用語 として、よく用いられます。 定義は 時と場合による
32. © 2024 Aguri Otsuka All Rights Reserved. キリがないのでおわり
33. © 2024 Aguri Otsuka All Rights Reserved. 業務アプリケーションと メンタルモデルの関係
34. © 2024 Aguri Otsuka All Rights Reserved. いきなりですが、質問 ユーザーはどんな目的で SmartHRを使っている と思いますか？
35. © 2024 Aguri Otsuka All Rights Reserved. ユーザーは、 効率良く仕事したいから 私たちの製品を使っている
36. © 2024 Aguri Otsuka All Rights Reserved. ユーザーの時間は有限だ｜SmartHR デザイン原則 https://smarthr.design/products/principles/
37. © 2024 Aguri Otsuka All Rights Reserved. なぜ「メンタルモデル」を意識するか メンタルモデルを使って ショートカットする 情報処理の 効率を上げる メンタルモデルの適用を慎重に ゆっくり時間をかける よく観察し 情報を精査し判断して 誤らないようにする たくさんのことを「速く」「一気に」処理しようとする時、 人間はメンタルモデルに頼らざるを得なくなる
38. © 2024 Aguri Otsuka All Rights Reserved. 出典：ジョン・ウェイレン「脳のしくみとユーザー体験 認知科学者が教えるデザインの成功法則」 「直感的に使える！」の感想のワケ ほとんどの人は論理を無視して心の近道を使いがちだし、 余裕がなくなれば、経験則に頼って「サティスファイシング」を行う。 つまり、よく考えて意思決定を行うのではなく、思い出しやすく、 正しいように感じる選択肢を選ぶ。
39. © 2024 Aguri Otsuka All Rights Reserved. 業務アプリの「当たり前」を 提供するため、 メンタルモデルを考慮したい
40. © 2024 Aguri Otsuka All Rights Reserved. 人間から期待する動作
 を得るためには、
 考えることがたくさんある
41. © 2024 Aguri Otsuka All Rights Reserved. 〇〇して ほしい 伝えたいこと テキスト ふむふむ 処理 〇〇 しよう！ 伝わる ユーザー求める行動を
 ユーザーが理解できる
 ように翻訳する
42. © 2024 Aguri Otsuka All Rights Reserved. 考えることを整理するために 何を考慮すれば
 良いのか
 不安しかない…
43. © 2024 Aguri Otsuka All Rights Reserved. テンプレートを使おう！！！
44. © 2024 Aguri Otsuka All Rights Reserved. プロダクトライティング講座謹製テンプレート https://codimd.kufu.tools/42uDMqJbSXCzWeLRA37Fiw
45. © 2024 Aguri Otsuka All Rights Reserved. ライティングのダブルダイヤモンド
46. © 2024 Aguri Otsuka All Rights Reserved. ライティングのダブルダイヤモンド ２. 整理 　 する １. 集める 　 調べる ３. 意図を 　 明確にする ４. 書く ５. 磨く 発 散 収 束 収 束 発 散 イギリスのデザインカウンシ ルが提唱したデザインプロセ スのモデル、「ダブル・ダイヤ モンド」から発想を得てます https://note.com/aguri/n/n428d4cc42af4
47. © 2024 Aguri Otsuka All Rights Reserved. プロダクトライティングのダブルダイヤモンド ２. 整理 　 する １. 集める 　 調べる ３. ユーザーが 達成したいこと 　 明確にする ４. 書く ５. 整える 発 散 収 束 収 束 発 散
48. © 2024 Aguri Otsuka All Rights Reserved. 集める・調べる、整理する、ユーザーの目的を明確にする １. 集める 　 調べる ２. 整理 　 する ３. ユーザーが 達成したいこと 　 明確にする ４. 書く ５. 整える 発 散 収 束 収 束 発 散 ‹ どのUIで表示されるŠ ‹ UIテキストの役k ‹ だれに (担当者・従業員f ‹ いつ・どのように 
 (テキストを目にする状況f ‹ 何をして欲しいのか
49. © 2024 Aguri Otsuka All Rights Reserved. 集める・調べる、整理する、ユーザーの目的を明確にする １. 集める 　 調べる ２. 整理 　 する ３. ユーザーが 達成したいこと 　 明確にする ４. 書く ５. 整える 発 散 収 束 収 束 発 散 ‹ どのUIで表示されるŠ ‹ UIテキストの役k ‹ だれに (担当者・従業員f ‹ いつ・どのように 
 (テキストを目にする状況f ‹ 何をして欲しいのか
50. © 2024 Aguri Otsuka All Rights Reserved. プロダクトライティングで意識してほしいこと テキストだけで考えない
51. © 2024 Aguri Otsuka All Rights Reserved. 大切なのは、視座の切り替え
52. © 2024 Aguri Otsuka All Rights Reserved. GE 画面単位で見る（最低限0 (E ユーザーストーリーで見7 3E 拡張性で見る 視座の切り替えとは？
53. © 2024 Aguri Otsuka All Rights Reserved. ユーザーストーリー単位で UIテキストを仕上げる PH ユーザーストーリーで見る
54. © 2024 Aguri Otsuka All Rights Reserved. ・ テキストもUIの一部で、インタラクションの中に含まれる から（操作を進めながら、目に飛び込んでくる。ユーザー は文章を読むために操作しているわけではない） ・ オブジェクト違いの同じ操作画面間のテキストを揃えたい ・ ユビキタス言語としてオブジェクト名が決まっていて、実 装時にライティングガイドに則れば、さほど大きなブレは 生じないので、最後に見直しても手戻りは少ないはず… なぜ、ユーザーストーリー単位なのか？
55. © 2024 Aguri Otsuka All Rights Reserved. ・ ユーザーストーリー単位で操作ができるようになったら、 UIテキストを修正 ・ ユビキタス言語の見直しをした場合には、ドキュメントも 修正 実例：スキル管理のUIテキスト実装の流れ 開発のチケットは なるべく小さくしている SmartHRのfigmaの データは中間生成物 ではない 仮説検証を繰り返し ながら開発するうえで 欠かせない
56. © 2024 Aguri Otsuka All Rights Reserved. ・ 従業員のスキル情報の一括登録ストーリーの文言修正 ・ マスターデータ設定周りの文言修正 ・ 【文言修正】KAT-686｜申請ストーリー ・ バックグラウンド処理の文言修正 興味があったら、Pull Request見てみてね
57. © 2024 Aguri Otsuka All Rights Reserved. プロダクトの未来を意識する BA 拡張性で見る
58. © 2024 Aguri Otsuka All Rights Reserved. 1stリリースでは管理者から従業員へ情報の登録を「依頼」するだけ だったので、「依頼」というオブジェクトになりそうだったところ を「申請」に変更 https://smarthr-inc.docbase.io/posts/2903773
59. © 2024 Aguri Otsuka All Rights Reserved. 「マルチプロダクトを当たり前にしよう」
 時代には、より視座の切り替えが
 大事になってくる
60. © 2024 Aguri Otsuka All Rights Reserved. 命名・分類・構造化
61. © 2024 Aguri Otsuka All Rights Reserved. 「わかる」と「わかりやすい」 わかる わかり やすい 「何と同じか、何と違うかX U どのカテゴリに属すのS U 属するカテゴリの他のものとはどう違うのか? 「何と同じか、何と違うか」が自明な状w U カテゴリが意識されてい” U 同カテゴリのものの違いが名前から理解できる
62. © 2024 Aguri Otsuka All Rights Reserved. 3つの関係 命名 分類 構造化 教科書的には「構造化→組織化→ラベリング」の順に情報整理する と言われていますが、「これでユーザーにわかるかな？」というレ ビューすることを忘れない！
63. © 2024 Aguri Otsuka All Rights Reserved. 「名前」は便利だけど、あやうい
64. © 2024 Aguri Otsuka All Rights Reserved. 情報密度の高い言葉を使う時に気をつけたいこと リーダブルコードでは、 コードレビュー時のコメントを簡潔にするため 「情報密度の高い言葉を使う」ことを推奨しています 情報密度の高い言葉、 つまり概念を一言で表した名前は、 ひと言で多くの情報を伝えられるので、便利 一方で、言葉の意味・解釈が違っていた場合には、 コミュニケーションのズレに繋がります
65. © 2024 Aguri Otsuka All Rights Reserved. ユビキタス言語
66. © 2024 Aguri Otsuka All Rights Reserved. https://note.com/aguri/n/nc3478ea605b7 ユビキタス言語については　　読んでね
67. © 2024 Aguri Otsuka All Rights Reserved. 出典：ジョン・ウェイレン「脳のしくみとユーザー体験 認知科学者が教えるデザインの成功法則」 主役は「仕様」ではなくてユーザー 顧客が実際に発する言葉に耳を傾ければ、彼らがよく使っている言葉 や、持っている専門性のレベル、ひいては想定しているプロセスがわ かってくる。 それを活用すれば、顧客が期待しているものに近い体験をデザインした り、プロセスが予想と異なっていることへの注意喚起をしたりでき る。
68. © 2024 Aguri Otsuka All Rights Reserved. ・ どんな言葉を使っているか ・ その言葉をどんな意味で使っているか ・ （使っている言葉から）どの程度の知識がありそうか 商談やチャットログから　　が把握する観点
69. © 2024 Aguri Otsuka All Rights Reserved. 実例：スキル管理機能で「証跡ファイル」→「証明書の写し」に オブジェクトの名前を商談議事録などの 記述から、変更
70. © 2024 Aguri Otsuka All Rights Reserved. 環境の変化によってメタファーが通じなくなることも https://note.com/47178/n/n749c31e82edf https://note.com/47178/n/n749c31e82edf トレー… お盆？ タスクを溜めておく場所→「トレイ」
71. © 2024 Aguri Otsuka All Rights Reserved. プロダクトライティングの技術
72. © 2024 Aguri Otsuka All Rights Reserved. 考え方はここまで
 最後にテクニックの説明をします
73. © 2024 Aguri Otsuka All Rights Reserved. ・ 概念の定義や命名は必要？　必要だったら… プロダクト内にすでに似た用語はないか？ 一般名詞と混同されないか？ ・ どうやってユーザーのメンタルモデルを構築する？ できる限り自然な動線上でインプットを試みる フィーチャー開発するぞー！という時のライティングの難所
74. © 2024 Aguri Otsuka All Rights Reserved. ・ 概念の定義や命名は必要？　必要だったら… プロダクト内にすでに似た用語はないか？ 一般名詞と混同されないか？ ・ どうやってユーザーのメンタルモデルを構築する？ できる限り自然な動線上でインプットを試みる フィーチャー開発するぞー！という時のライティングの難所 考え方として説明済み
75. © 2024 Aguri Otsuka All Rights Reserved. ・ 概念の定義や命名は必要？　必要だったら… プロダクト内にすでに似た用語はないか？ 一般名詞と混同されないか？ ・ どうやってユーザーのメンタルモデルを構築するか できる限り自然な動線上でインプットを試みる フィーチャー開発するぞー！という時のライティングの難所 考え方として説明済み
76. © 2024 Aguri Otsuka All Rights Reserved. ちょっと思い出してみてください PageDescriptionを
 書くのに、
 どれくらい時間を
 割いていますか？
77. © 2024 Aguri Otsuka All Rights Reserved. 操作中、人は文章を読まない 悲しい現実
78. © 2024 Aguri Otsuka All Rights Reserved. ユーザーの注意 Descriptionは、 よほどの関心がないと瞬殺される と考えておく 操作の 選択対象なので 視線も注意も届く
79. © 2024 Aguri Otsuka All Rights Reserved. テクニック1 名前を付けたものは操作対象にする
80. © 2024 Aguri Otsuka All Rights Reserved. 実例：組織図の「従業員カード」と「従業員プロフィール」 従業員カード 従業員プロフィール
81. © 2024 Aguri Otsuka All Rights Reserved. 名前を付けたものは操作対象にする 「従業員カード」と「従業員プロ フィール」は、ユーザーのメンタル モデル構築が必要な新しい概念 新しい用語は、Descriptionにだけ書 いても読まれないのでユーザーが選 択するラベル名として明示 Before After
82. © 2024 Aguri Otsuka All Rights Reserved. テクニック2 「構造」を意識できるように マークアップする
83. © 2024 Aguri Otsuka All Rights Reserved. 情報の格を揃える Before After 情報を整理して、［表示する従 業員項目］を小見出しに昇格
84. © 2024 Aguri Otsuka All Rights Reserved. 同格の画面の見出しの扱いは、 きちんと揃える
85. © 2024 Aguri Otsuka All Rights Reserved. テクニック3 「チャンク」を利用する
86. © 2024 Aguri Otsuka All Rights Reserved. chunk チャンク
87. © 2024 Aguri Otsuka All Rights Reserved. ぱっと見たときに
 「まとまり（意味的な塊）」
 を感じる単位 チャンクとは？ 認知心理学の用語です
88. © 2024 Aguri Otsuka All Rights Reserved. 実例：スキル管理機能のCSVでのマスター追加 Before スプリントレビューで、 ヘルプページのリンクを用意していたが、読まれなかった…
89. © 2024 Aguri Otsuka All Rights Reserved. 情報量を増やせば良いというわけではない After こちらに決定 テキストでめっちゃ説明したVer. 情報の塊を目に入りやすくしたVer.
90. © 2024 Aguri Otsuka All Rights Reserved. しっかり聞いている人は、「あの続き」が気になっているでしょうか ダブルダイヤモンドの
 「書く」と「整える」は？
91. © 2024 Aguri Otsuka All Rights Reserved. テクニック4 テクニカルライティングを
 身につける
92. © 2024 Aguri Otsuka All Rights Reserved. ・ 一文一義で書く ・ 主語や目的語を明確にし、述語と近づける ・ 二重否定は避ける ・ 指示語を使わない ・ 冗長な表現を使わない テクニカルライティングは難しくない
93. © 2024 Aguri Otsuka All Rights Reserved. ・ 一文一義で書く ・ 主語や目的語を明確にし、述語と近づける ・ 二重否定は避ける ・ 指示語を使わない ・ 冗長な表現を使わない テクニカルライティングは難しくない “型”があるので、覚えやすい 各チームへの
 出張講座
 やってます！
94. © 2024 Aguri Otsuka All Rights Reserved. テクニック5 「SmartHR Design System」
 を利用する
95. © 2024 Aguri Otsuka All Rights Reserved. 書く、整える ２. 整理 　 する １. 集める 　 調べる ３. ユーザーの 　 目的を 　 明確にする ４. 書く ５. 整える 発 散 収 束 収 束 発 散
96. © 2024 Aguri Otsuka All Rights Reserved. ライティングガイドラインの 成り立ち
97. © 2024 Aguri Otsuka All Rights Reserved. 出典：「ちいさくはじめるデザインシステム」 UIテキストの作成プロセスとガイドライン UIテキストは、おおまかに「調査・分類・抽象化」の流れで作成して いきます。まず、既存のUIテキストを網羅的に調査します。具体を把握 しなければ、何が「当たり前」なのかわかりませんし、何に対して「整 合性」を担保すればいいのかもわかりません。 そして、既存のUIテキストの共通点を見つけて分類し、どのような概念 や操作体系を示してい るのかを抽象化します。事例の集まりに「意 味」を見つけ、UIテキスト作成に利用できる情報へと変化させるプロ セスです。最後に、揃えるべき点や変えるべき点を判別したうえで、言 葉を選びます。
98. © 2024 Aguri Otsuka All Rights Reserved. 実例：ダイアログタイトルのライティング https://smarthr.design/products/components/dialog/#h2-3
99. © 2024 Aguri Otsuka All Rights Reserved. 実例：「入力必須」か「必須入力」か https://smarthr-inc.docbase.io/posts/2178376 正）　項目を指す時［入力必須項目］
 　　　設定時のラベル：［入力必須］もしくは［必須］（UIによって判断）
 　　　フォームラベル：［必須］ 
 誤）　項目を指す時［必須入力項目］
 　　　設定時のラベル：［必須入力］
100. © 2024 Aguri Otsuka All Rights Reserved. コンテンツは十分ではないし、 既存も“絶対”ではない WIPだよ!！
101. © 2024 Aguri Otsuka All Rights Reserved. 第1期生の成果 PRのプロデザレビュー後の
 修正中で
 まだ公開できてません…
102. © 2024 Aguri Otsuka All Rights Reserved. #design_system_相談 プロダクト開発時の UIのテキストの相談 ガイドラインの内容に 疑問や要望がある時
103. © 2024 Aguri Otsuka All Rights Reserved. 認知に関するおすすめ本
104. © 2024 Aguri Otsuka All Rights Reserved. さあ、開講です！ やってこ。