0→1フェーズのプロダクト開発における、とあるUXライターの働き方
これは、SmartHRの村だよ Advent Calendar 2021の11日目の記事です。
SmartHRは2021年10月28日に新しい有料オプション機能「人事評価」の提供をスタートしました。
今年の2月末、入社1年を経過した頃に、私はUXライターとしてこのプロダクト開発に携わりました。ここでは、私が人事評価の開発で何をし、何を得たかを紹介したいと思います。
UXライターとしてやったこと
１．ユビキタス言語の定義
チーム加入前の2月初旬、ユビキタス言語を決めようと、開発チームの呼びかけで、ドメインエキスパートとして社内の人事担当者とUXライターの私で集まりました。プロダクトマネージャーからモデルの説明を受けながら、実務ではどんな言葉で呼んでいるかをヒアリングしながら、名前をつけました。
早い段階で名前をつけ、物理モデルではなくユーザーも使う言葉で開発上のコミュニケーションができるようになったことは、メンバーの認識を揃える以上に、概念のわかりにくさを自覚し調整していく動きにも繋がりました。（実際、名前を変更したものもいくつかあります）
SmartHRのプロダクトデザイン原則の中に「言葉からはじまるデザイン」というものがあります。
これは、言葉で説明できないものは、その設計に矛盾が潜んでいたり、拡張性に欠けることがあるという意識から設けました。
開発初期にモデルに名前をつけたことは、この原則を体現できたという手応えにもなりました。
２．ユーザーの操作を邪魔をしない情報の配置
人事評価は、機能の柔軟性とマニュアルがなくても使えるUIを備えたアプリケーションを目指して作っています。 なるべく多く仮説と検証のサイクルを繰り返すべく、できあがった機能は社内の人事担当者に触ってもらいフィードバックを受けてきました。
そのなかで、レビュアーはSmartHRの社員なので業務アプリケーションのリテラシーが高いという前提はあるもののの、「UIテキストがしっかり読まれることは、やっぱり少ないよね」というチームの共通認識が形成されました。
UXライターはヘルプページの作成もしていますが、マニュアルがなくても使えるプロダクトを作ることは、私も目指しているあり方です。 それは、SmartHRのプロダクトにおけるデザイン原則の「ユーザーの時間は有限だ」でも意識されています。
しかし「ヘルプページを見なくても、わかるように伝えるぞ！」という気持ちが先走って、ヘルプページを書いている感覚でプロダクト上の操作を促すテキストを考えると、文章は冗長になります。
わかりやすい文章の条件には、「一文一義」という超基本があります。ユーザーのワーキングメモリ（作業記憶）が処理できる情報量に収めるため、1つの文章には1つのことしか書かないという考えです。
しかし日本語は、一文一義を守っても、情報を補う修飾節がつけばつくほど、ワーキングメモリを超え、読解が困難になってしまうケースが多々あります。語順の特性上、動詞にたどり着くまでに覚えておかなければならないことが増えるためです。
ユーザーの本来の目的は、文章を読むことではなく、業務のためにアプリケーションを操作すること。ユーザーを助けるはずのテキストが、ノイズになってしまいます。
そこで、テキストも含めたUIデザインでは、「ユーザーの操作を邪魔をしない情報量に抑える」ことを意識しました。
［具体例］
・バックグラウンド処理やエラーなど、ユーザーを戸惑わせる状況のフィードバックはしっかりと伝える
・仕様上の注意など説明が必要な操作は、潔くヘルプページに説明を譲る（リンクを設置する）
人事評価機能は、柔軟性を叶えるため設定が自在にできるため、使い始めに概念を理解しておく必要があります。ユーザーの初期学習を助けるために、ヘルプセンターには用語集を掲載しました。これは、先に紹介したユビキタス言語をさらにユーザーに向けて”翻訳”したものです。
また、仕様が理解しづらい部分は「よくある質問」としてコンテンツ化し、ユーザーが必要とした時にコンテンツに触れられるように準備しています。
まだまだ完全とは言い難いですが、このように、適切な情報量やコンテンツの置き場を意識しています。
３．GitHub・簡単な実装の習得
まず大前提として、私はすべてのUXライターがコードを書けるようになる必要はないと考えています。今、UXライティンググループには7人のUXライターがいますが、日常的にプロダクトのリポジトリにコミットしているのは私だけです。
私が参加した時点で、プロトタイプとして実装が進んでいました。私はその画面を確認し、修正テキスト案を考え、レビューを受け、プロダクトエンジニアに修正実装をしてもらっていました。しかし、1カ月後には、私はプルリクエストを出すようになりました。
実装できるようになる前の私は、UIテキストを考える時間よりもレビューを受ける資料作成に時間を費やしていました。また、修正実装の手戻りも発生していたので、チームの効率を下げていると感じました。
UXライターですし「一語一句に手間ひまかける」のバリューは体現していますが、SmartHRに入社後、スクラムやアジャイル開発に対する理解を深めるにつれ、実は「開発スピードを遅くするくらいなら、細かい文言にこだわる必要はないのでは？」と考えるようになっていました。
人事評価チームは、先ほども説明したように、なるべく早く動くものを作って、仮説を検証しようと動いていました。そんなチームメンバーの姿を目の当たりにし、自分の武器であるテキストを使ったプロダクト体験デザインにこだわりたいなら、自分も仮説検証の速度を上げる方に加担すれば良いだけだと、GitHubと環境構築を身につけました。（Web1.0のホームページは作っていたインターネット老人会の人なので、テキストの置き換え程度の読み書きはできました）
これができたのは、コードを書くことが当たり前の人たちが、私の「少しでも同じスタンスでやっていきたい」という気持ちに応えてくれたからです。感謝しかありません。
実装ができるUXライターになって、私が得たこと
１．業務アプリケーションのUXの解像度が上がった
チームの仮説と検証を繰り返す姿勢に馴染んでいくなかで、私は 「UIテキストは、動的な体験の中にある」と考えるようになりました。画面上にあるテキストは、実際は静的なものです。しかし、ユーザーが接触するテキストは、その操作過程で通り過ぎる一部でしかありません。
私は社会人としてのスタートが情報量の多い雑誌の編集者でした。そこで誌面のレイアウトを構成する技術を叩き込まれたので、Webディレクターになってからも、ユーザーの視線は意識はしていたのですが、画面を 「見る」と 「操作する」の見え方の違いを意識できるようになりました。
この感覚は、自分が考えたテキストを実装し、操作したときの印象をすぐに確認できるようになったことで得ました。「これまでも、UIモックにテキストを反映して、画面遷移を確認していたけれど、何が違うんだろう…」と考えてみて、気づきました。
UXライターと肩書きを変えた時から、「”UX”の冠がある以上、プロダクトを操作するユーザーの体験を良くするテキストを考えることが求められて当然」と意識はしていましたが、業務アプリケーションにおけるUXの解像度が上がり、アウトプットの質を高めるアプローチが取りやすくなったのは、実装ができるようになったおかげです。
２．自分が想定した”体験”の仮説を、自らその場で確認できるようになった
また、UIテキストもデザイナーが設けたテキストエリアに書くものという思い込みに囚われずに検討できました。テキストとコンポーネントの組み合わせをいくつか思いついても、実際に触ってみると見当外れなんてことはよくあります。誰かの手を借りなければ試せないアイディアはとりあえず作ってみることを躊躇ってしまいますが、自分でできるならいくらでも試せます。まずは自分で考えたことを自ら検証し、納得がいったものをレビュー依頼するというサイクルを生み出せました。
そして、ユーザーに伝えたい情報を1カ所にまとめて文章で書き上げるのではなく、操作する視線に合わせて散りばめるようになりました。
「はじめて」と「これから」
SmartHRでは、0→1フェーズからUXライターが開発に関わること自体、初のことでした。こうして振り返ると、このチームでの業務は私をたくさん成長させてくれました。これまでいなかった役割のメンバーを迎え入れることは、開発チームにとっては戸惑うこともあったと思いますが、こうした貴重な機会に恵まれたことを大変うれしく思います。
人事評価チーム自体も、0→1から1→10のフェーズになり、メンバーも増えて開発の進め方も変わってきました。今、私はUXライターとして、UIの仮説の検証を、今度は実際のユーザーからの声を元に進める準備をしています。
人事評価の提供ははじまったばかり。これから、よりよいサービスを提供できるよう、さらに、いろんなことを身に着けていきたいと思います。
この記事が気に入ったらサポートをしてみませんか？