UXライティングの重要性
s-umemoto
はい、始まりました。デザインの味付け。この番組は株式会社ajike代表の梅本とその仲間たちがデザインについて雑談を交えながら話す番組です。
今日のお相手は原さんです。原さん、よろしくお願いします。
よろしくお願いします。
この私のタイトルコールをコンポーネント化してないのすごくないですか?
n-hara
毎回言われてますね。
s-umemoto
毎回言ってますね。
これ今だから120回か。一番最初2,3回は言ってなかったかもしれないですけど、たぶん4,5回目ぐらいから言うようにしてるんですけど。
だから100回以上言ってきたら、今何も考えてなかったけど全部言えてましたね。
n-hara
すごいですね。もう無意識の中で。
s-umemoto
そうなんですよ。
私無意識で般若心経が唱えられるように、このタイトルコールも無意識で言えるようになってきました。
n-hara
100回も言うとそうなるんですね。
100回ぐらいがまだにしみつく。
s-umemoto
100回ぐらい言うとしみつくんじゃないですかね。繰り返し言うと何でも言えるようになるもんですね。大事ですね。
さて、今日のテーマは何でしょうか。
n-hara
今日のテーマはUXライティングの仕組み化によって効率と品質が上がった話です。
s-umemoto
ちょうど先週UIデザインとビジュアルデザインの違いを再認識した話ということでお話しましたが、
そのときにちょっとUXライティングっていうのが一部話したと思いますけど、それにつらなるテーマですね。
そうですね。
このテーマにしたか、原さんのほうからも教えてもらっていいですか。
n-hara
直近ですね、先週の話もそうなんですけど、Azure系の社内でも結構UXライティングの取り組みが活発になってるなというのは思っていて、
s-umemoto
理由としては、最近ですね、商品開発のほうのメンバーでUXライティングのガイドラインみたいなのを設計してくれたんですよね、社内で。
n-hara
今まで高校でスキルとして持ってやってたっていうのが実情であったんですけど、
それを組織として体系的にガイドラインにするみたいなところの取り組みが今年できたっていうので、
結構直近その辺が案件のほうでうまく活用されてきてるんじゃないかなというのを感じているので、
s-umemoto
今日はその話をしたいと思います。
エラー文言の改善
s-umemoto
なるほど。じゃあ、Azure系で作ってくれているUXライティングのガイドライン、これどういうものか教えてもらっていいですか。
n-hara
まずUXライティングをちょっと簡単にお伝えすると、UIデザインするときに必要になるようなものになるんですけども、
ユーザーを主語にしてですね、ユーザーにとってわかりやすい言葉にしていくっていうところが基本、本当に解説まで言うとそんな感じのものになっていて、
画面の中にあるボタンとか伝えなきゃいけない情報ですね。文字情報っていうのはわかりやすくライティングする技術ですね。
これをUXライティングとまず捉えてもらったらいいかなと思っています。
UXライティングのタイミングがどういうときかっていうところの話なんですけど、
例えばUIデザインするときに情報設計のタイミングだったりとか、あとは実際にデザインですね、
カラリングとか設定して画面のデザインをしていくようなタイミングとかで、
そのプロダクトの用字用語と言われる決まりですよね。
そういうこの言葉をこれで統一しようとか、この会社さんこの言葉でルールが適切されているので、それで統一していきましょう。
そういった整理をしていくタイミングが出てくるんですけど、
そのときにUIのテキストですね、ボタンとかリンクだったりとか見出しだったりとか、
いろんなUIパーツで出てくるテキストの一貫性を持たせて設計していくっていうタイミングが出てきます。
なんでこれをアジケのほうルールブック的なところをオリジナルで商品開発のメンバーが作ってくれまして、
さらにそれをただドキュメント化しただけじゃなくて、
アジケは今ジェミニ使ってると思うんですけど、
ジェミニに学習できるような状態にしてチェックできるような仕組みまで落としてくるっていうのが、
s-umemoto
かなりロッキングに各メンバーが使えられる状態になってきてるところかなと思うんです。
n-hara
すごいじゃん。
s-umemoto
自分が言ったらよくないんか、すごいじゃんとかね。
n-hara
すごいですよ。
s-umemoto
結構単純にやってくれたので、すごいなと。
例えばどういうところにチェックを入れてるんですか。
n-hara
イメージしやすいところで言うと、
エラーの文言とかって結構UIデザインするときに悩むポイントだったりとか、
UIデザインなどもあると思うんですけど、
普通にエラーの文言をその状態で考えるとしたときに、
エラーっていうのは何かできなかったときに出てくる言葉なので、
あれはできませんでしたとか、
そういうようなシンプルな表現っていうのがまず浮かぶと思うんですけど、
そういうときに出てくる言葉って、
システム側の要件だったりとか、
事業側の要件、こういう理由でできなかったよ、
こういうのが今こういうのができなかったよ、
みたいなことを伝えるっていうライティングになっちゃうことが多いんじゃないかなと思うんですよね。
それをお客さんに伝えるみたいなことを意識してもらうというか。
エクサイティングで基本とされているのは、
原因と対象と事象っていう3つの要素をちゃんと伝えましょうみたいなのを、
考え方として自由視されているところがあるので、
結構その辺を考慮して設計をしていくみたいなこととかができると、
ユーザーさんにとっても分かりやすいエラー文言になってるっていう形になります。
優先度もあって、まず原因をちゃんと伝えるっていうのが一番優先度が高いですね。
どういう理由で起こってるのかっていうのを明確に伝えるっていうところですね。
次に対象、何をしたら解決するのかっていう、
ユーザーさんで何をしたら、自分が何をしたらいいんだろうかみたいなことをちゃんと分かるっていうところの優先度が2番目に高いのと、
最後に事象で何が起きてるのかっていう、今これがどういう状況なのかみたいなことを伝えるみたいなのが、
基本の優先度としてあるので、
多分エラーっていろんな画面で出てくるところであるので、
情報のエリアの制限によっては、
全部を出すのは難しい、原因、対象、事象全部をライティングするのは難しい場面とかがあるので、
そういう優先度で考慮して各UIパーツを設定していくと、
分かりやすくなっていくかなというのがあってですね。
そういうのがチェックできるようになったっていうのが一つ。
社内での効率化
n-hara
他にもあるんですけど、仕組みがあったっていうのがすごく便利ですね。
s-umemoto
なるほど。
n-hara
さっきエラーの話でいうと、
NGのパターンとかでエラーが発生しましたとかでよく見る。
s-umemoto
見るよ。
n-hara
見ますよね。
多分ユーザー、自分もそういう画面になったときに、
何なのこれみたいな、何をしたらいいの?
どういう状況?みたいな、ハテナしか浮かばないと思うんですよね。
エラーが発生しました。
あとコードが出てて、エラーが発生しました、○○コードみたいなのが出たときに、
完全に何をしたらいいの?みたいなところの、
理由もわかんないし、状況もわかんないし、何をしたらいいのかわかんないしみたいな、
状況が本当に良くないエラーの本当にスタンダードな例なんですけど、
さっきの軸で置き換えていくと、
例えばログインのページとかだったとしたときに、
ログイン情報に誤りがありますみたいな。
何が理由なのか、原因を伝えた上で、
例えば対処法として何がどういう風に入力したら解決するのかっていうのを伝える。
自分で解決できるし、状況もわかるので、
そういうふうに書き換えていくことができると、
それはEXIDができている状態だったので、
もし今自身のプロダクトとかでエラーが発生しました、
画面がある方はぜひちょっと改善してほしいなという、ユーザーとしては思いますね。
結構あれストレス。
s-umemoto
なんでってなるよね。
n-hara
こういう本当に細かい話ではあるんですけど、
いわゆる中でも一つの要素ではあるんですけど、
結構こういうことが出かかったりとかもするので、
その辺がサービスで揺らぎなく整理されてたりすると、
結構ストレスがあるんですよね。
これがAzureとしてちゃんと仕組み化できたっていうのを、
商品開発の取り組みとしては正確かなと思っています。
これは今どういうものかっていうのを説明してもらったんですけども、
実際にこれをお客様に提供していると思いますけども、
s-umemoto
UXライティングガイドラインでお客様から支援を受けたら、
例えば、このUXライティングガイドラインで、
お客様に提供していると思いますけども、
UXライティングガイドラインでお客様からしたら、
どんな効果が出ているんですか?
n-hara
そうですね。
まずは社内的なところが一つ大きいところではあるんですけど、
揺らぎがないので、
Azure系のデザイナーとかメンバーの中でも、
この人はこういう表現をしていて、
この人はこういう表現をしていて、
人による揺らぎがなくなるので、
デザインを提出するときにも、
ちゃんと一過性が担保された状態で、
アウトプットが出てくるというところが、
個別の具体でそれぞれ毎回フィードバックして対処するとかじゃなくて、
考え方とか軸みたいなのがあった上での、
UIのパーツに対しての例っていうのが、
ちゃんと定義されているようなガイドラインになっているので、
それを担当者が個人で判断してやるみたいな範囲が、
すごく狭まるというか、
こういう時はこういう風にしたら間違いないなとかっていうのが、
できるようになったので、品質もそうですし、
独人化みたいなところの内部の状況みたいなのも、
結構改善してるんじゃないかなっていうところと、
例えば時間的なところですよね。
ゼロから考えるとかっていうところが必要なくなるので、
ベースがあるっていうところが基本になるので、
それから作れるっていうのは、
自分自身で例えばそれが正しいかっていうのを
自動でチェックすることができるようになっているので、
やっぱりそういう時間的な部分っていうのは、
特に効率化されていると思いますし、
GLデザイナーの場合だと、
自分がデザインしたものを先輩デザイナーに見てもらって、
データバックもらうみたいなのが基本になると思うんですけど、
その前に自分でチェックして、
この軸でできてれば大丈夫だろうみたいなのが、
自分でチェックができるようになっているので、
やっぱりそれが結構、
独人のコストだったり、
考えるコストだったりとかっていうのは短縮できてるっていうのは、
結構内部の話になっちゃいますけど、
でかいんじゃないかと思いますね。
もう1個はお客さんのとこでいうと、
これはうちのチームとかAzure Kの中だけのものじゃなくて、
お客さんの環境にも使えるようなものではあると思うので、
Azure Kの社内もチェックすることもできますが、
お客さんの担当者の方が、
自分でコーライティングをチェックするっていうこともあるので、
例えば何か先のワイヤーとかこういうのを作ってほしいですみたいなときに、
ちょっとライティングを考える場面で、
デザインじゃなくて、
そのときプロダクトのルールというか、
みたいなところをたくさん自身もチェックして、
元を作れるっていうのは結構、
味気だけの話じゃなくて、
専門家だけがやってるみたいなものじゃなくて、
チームでやってるみたいなところができるので、
すごくいいかなと思ってて、
UXライティングの取り組み
n-hara
ちょっとこれはまだ試験運用中のところはあるんですけど、
Apply開発のAzure Kは使ってたりしますが、
チェックツールを使って、
そこでチェックできるようにしていったり、
っていうのを今試験とか、
ちょっとフィギュアのプラグインを作ろうとしてたりとかもするので、
ちょっと社内の取り組みではなくて、
もうちょっとチームとかプロダクトとか、
お客さんに向けてみたいなところも、
ちょっと範囲を広げようとしてるので、
その辺ったら今後また効果が出てくるんじゃないかなと、
思っています。
AIの活用とその効果
n-hara
なるほど。
s-umemoto
はい。
n-hara
そうだね。
s-umemoto
お客さんの悩みはさっき言ったみたいに、
結構お客さん自身も課題に気づいているお客様がほとんどだもんね。
そうですね。
n-hara
ライティングの悩みを結構お聞きしますね。
s-umemoto
うちの今のサイトとかアプリケーションは、
結構ユーザーにとって分かりづらい文言がめっちゃ多いんですよね、
みたいな。
n-hara
よく聞きますね。
s-umemoto
それをよくしたいってなったときに、
結構表記の問題とか各社、
大きい企業さんであればあるほど持ってるから、
そうですね。
それを遵守した上で、
分かりやすい文言とか自分たちの新しいパターンみたいなのを
何にしたらいいんだろうっていうのがやっぱり悩まれてるから、
それがもし統一できると、
先にいらっしゃるお客様ユーザーも分かりやすくなって、
顧客満足度も当然上がりますし、
使いやすいサービスだなと思ってもらえるもんね。
n-hara
そうですね。
特に自分の場合、銀行さん系が多かったりとかするので、
そういう金融系の言葉って難しくしてしまうことが多かったりとか、
伝えられない自体がそんなに簡単なものではないと思うので、
伝えなきゃいけないこととか、
その辺はやっぱりクライアントの担当者の方も悩まれると言わなきゃいけないんだけど、
それそのまま伝えられなくなっちゃったりとか、
漢字ばっかり難しくなったりとか、
これ読まないよなと思いながら書いてたりとかするので、
すごく需要悪いよね。
そうだよね。
s-umemoto
法律に違反してないかとかね。
法務のチェックが入るもんね、だいたいね。
n-hara
そうですね。
s-umemoto
ただそれを今まで人力でやっていたけども、
AIのうまい使い方っていうのは、
一回それである程度ルールに合わせて統合させて、
そこから最終人間のチェックっていうふうにすると、
少し楽になるよね。
n-hara
そうですね。
AIに登録するってことは、
ベースの考え方とか軸とかっていうのは明確になってるから、
AIに登録できる。
それは人も同様で、
その人がAIみたいなもので、
ちゃんと自分がチェックできるようになると思うので、
各プロダクトに入れていきたいものではありますね。
s-umemoto
なるほど。
原さんはもうUX、
ライティングの方も意識は最近使うようになってきたと。
ライティング、重要ですね。
入社したときはグラフィックから始まり、
そしてUIからサービスデザインまでやって、
今はもうライティングでお客さんにも
AIを使ってライティングした方がいいよと言うようになってる。
学生時代こういうことを勉強してきたこと、
何か意味あるなとか、
気づきとかあったりするんですか。
n-hara
そうですね。
デザイナー、私がアジキ入って初めてデザイナーみたいな
職種で働き始めたところがあるんですけど、
そのときに意外とデザイナーって論理的思考だったりとか、
勉強とデザインの重要性
n-hara
数学的思考だったりとか、
そういうのがいるんだなってすごい思ったんですよね、
デザインするときに。
意外いるんだと。
もうちょっと感覚的なものだと最初思ってたんですけど、
そうじゃなくてロジカルだったりとか、
本当に計算した上でそのデザインがあるみたいなものだと思うので、
だからそれは最初そうなんだってやってみて感じたところではあるんですけど、
それは今重要だなと思いつつ、
それが今ライティングの話につなげると、
ライティングって重要だなと思ってて。
s-umemoto
そうだね。
n-hara
学生のときに出てきたような左辺変革活用とか出てくる。
s-umemoto
左辺?
n-hara
左辺変革活用って。
s-umemoto
せいしするするするせい。
n-hara
動詞の扱いとかですね、イメージの扱いとか。
あの辺を出てくるとこで、
これ学生のときに出てきたなみたいなのがあるので、
そういうことをちゃんと勉強しなきゃよかったなって。
s-umemoto
今勉強してる。
n-hara
尊敬語と謙譲語で、今謙譲語めちゃくちゃ多いもんね。
s-umemoto
〇〇させていただきますみたいな。
よくわからないみたいなのがみんな見てるけど。
〇〇しますって言えばいいじゃんみたいな思うけどね。
n-hara
でもそういうのも勉強が大事ってことですか?
そうですね。
両方大事だなっていう。
数学的、論理的とこも大事だし、
そういう語彙力みたいな。
s-umemoto
日本語難しいなって思いながらやってますね。
わかりました。
ということで、
今日のテーマはUXライティングの仕組み化の話させていただいて、
それに対してやっぱり効率とか品質が上がってきたので、
ぜひ皆さんもAI活用してみてはいかがでしょうか?
みたいな話をしてみました。
今日も聞いていただきましてありがとうございました。
編集後期、お疲れ様でした。
お疲れ様です。
学生時代に勉強しておけばよかった問題は、
学生が終わってからしか気が付かないっていうもので。
そうですね。
n-hara
自分、学生時代にもっと勉強すればいいって気づいて勉強してるやつほとんど見ないんで。
s-umemoto
いるんかな?
言ってないだけで、まあいるっちゃいるんかでもね。
なんか業務で必要になってっていう感じですよね。
n-hara
それ以外にプライベートでやるってなかなか意欲がある人ですよ。
s-umemoto
そうだね。
お医者さんになるために勉強しなきゃみたいな、
なりたいものに対する勉強はあるかもしれないけど、
勉強大事だから勉強しなきゃみたいな話はあんまりないかもしれない。
原さんはデザイナーになってから勉強大事だって気づいたんですか?
n-hara
勉強はそうですね、そういうのがやっぱりいるんだなっていう。
本当に算数とかもそうですよね。
そういうのって意外と社会に出たらどういう、
本当に足し算引き算割り算とかそういうレベルしか想像してなかったんですけど、
普段お金とかそのあたり。
でも実際やっぱり出てくるんだなっていうのは、
そこから逆算すると、やっぱり学生の時に勉強しするんだなっていう意味があるんだなって実感します。
確かにね。
s-umemoto
自分も経営の時に当然数学というか算数みたいなのを使ってるけど、
読み書きソロ版みたいな話ですけど。
デザインでも、自分はそっちの領域はそこまで得意じゃないですけど、
三角関数というかサインコサインみたいなのがあるんですけど、
あれで気化学上の模様を作るのにものすごく美しい模様を作るのを、
プログラミングで作る人とかいらっしゃるじゃないですか。
ああいうのを見てるとやっぱり数学めっちゃ得意で、
それが美しさに直結してるんだみたいなのを見ると、
n-hara
すごい才能を持って勉強って大事なんだなって思いましたよね。
繋がってるとは学生の時は思ってないです。
s-umemoto
思ってないね。
n-hara
そして今もそれができると思って勉強してないから結局できないんだよね。
s-umemoto
あれはプログラミングというより本当数学的才能のような気がするな。
n-hara
そうですね。
ゼロの美しさを証明してやろうみたいな、やっぱりならないもんね。
s-umemoto
何かの定理を解いてみよう。美しいみたいな。
なったことないわ。
n-hara
なったことないですね。
s-umemoto
今はそういう話じゃないよね。
デザイナーにも勉強は役立つ部分はいっぱいありますよという話でしたね。
はい、出てきましたね。
これからも多分いろいろ学習しなきゃと思う場面はあると思いますので、
その都度頑張っていきましょう。
はい、ありがとうございました。
ありがとうございました。
