ウルトラマラソン と スクラム

4月28日に奥熊野いだ天ウルトラマラソンの100kmの部に参加し完走しました。天候にも恵まれ、ベストコンディションで走ることが出来ました。
奥熊野いだ天ウルトラマラソン – 神に見送られ仏に迎えられるウルトラマラソンへようこそ

100kmを走っていると色々なことについて考える時間があります。ブログネタについても考えていると、ウルトラマラソンはアジャイル、スクラムに関連することに気づき、記事にすることにしました。

ウルトラマラソン と スクラム

計画に従うことよりも変化への対応を

奥熊野いだ天ウルトラマラソンの制限時間は14時間40分です。この時間内に100kmを完走する必要があり、完走できるように計画を立てます。計画は練習時のペースや過去大会の経験(ベロシティ)から10km単位(スプリント)で通過できるタイム(ストーリポイント)を計算します。
しかし実際に走り始めると計画と実績で差が出てきます。計画時点では分かっていなかった体の痛みや天候、自分の調子が見える化されていきます。そのさい無理して計画に合わせようとするとペースが乱れて完走が難しくなってしまいます。そこで、アジャイルマニフェストにある「計画に従うことよりも変化への対応を」です。計画はあくまでも計画です。走る前と走っている最中では情報量が異なるので最新の情報で常に計画をアップデートしていきます。計画通りに進むことは稀です。

スプリント毎にスプリントレビューとレトロスペクティブ

マラソン中はふりかえりも大切です。10km毎に予定していた時間で通過できたか(価値を届けられたか)を確認(スプリントレビュー)します。また、体の痛みや栄養補給の状況などをふりかえります(レトロスペクティブ)。体に痛みがある場合は痛みに合わせてランニングフォームを変えてみたり、回復するまでペースを落とすことを考えたり、栄養補給を多めにとったりと改善案を考えます。そして、スプリントレビューとレトロスペクティブの結果を受けて、次のスプリント(10km)の計画を更新します。
今回の大会の場合、60kmの地点で足がつりそうになっていました。そして60-70kmの区間は下り道が続き無理をすると足をつってしまい完走できない可能性があったので、ペースは上げずに走ることを決めました。
ほんと、ふりかえりは大切です。

デイリースクラムでペースのチェック

10km毎の計画を立てて10km毎にふりかえりを行いますが、その10kmを予定通りのペースで走りきれるか10kmよりも短い間隔で確認(デイリースクラム)する必要があります。疲れてきたり、ゆるやかな上り坂で知らぬ間にペースが落ちていることもあります。一定の間隔でエイドが登場するので水分補給や栄養補給と同時に現在のペースで予定通り10kmを通過できるか把握します。

苦しい時はゴールを明確に、情報共有をこまめに

奥熊野いだ天ウルトラマラソンはアップダウンが多く、後半に激しい上り坂もあります。足の疲労もピークになっていて永遠に上りが続くような不安に押しつぶされそうになります。そんな時に助けてくれるのが、頂上まであと何kmの看板です。苦しい時に現状がどうなっているのか(残り何kmか)、解決するためにはどんな方法があるのか(走らないと間に合わないのか、歩いても間に合うのか)を把握することがとても重要です。こういった情報の見える化はスクラムイベントを行うことで高まるように設計されています。（スクラムでは見える化を透明性と表現しています）

この看板は1km毎に設置されていて苦しくても確実に進んでいる事が把握できます。

モチベーションを切らさない

100kmを完走するためにはメンタルが大きく影響します。いつ辞めても良い状況で苦しい中100kmを走るのですから、軽い気持ちで走る切る事はできません。僕も過去の大会で気持ちが切れて完走出来なかった事も多々あります。では、どうやってモチベーションを保っているのか考えた結果が以下です。

• 達成することは困難だけど不可能ではない
• ゴール後の喜びが想像できる
• 背中を押してくれる応援がある

僕にとって100km完走はギリギリの目標で達成できない可能性があります。そういった、背伸びしてようやく届くような目標にチャレンジすることはモチベーションになりますし、達成した後の達成感にも繋がります。走る前のワクワク感も他ではそう味わえません。また、沿道の応援も「頑張らねば」という気持ちになります。苦しい時の応援は心の支えになります。

さいごに

ウルトラマラソンは変化の激しいスポーツです。体の痛みや天候、疲れ。状況は一歩一歩変わってきます。このような変化の激しい課題にチャレンジするとき、自然とスクラムのフレームワークが当てはまることに気づきました。リリース計画とスプリント計画を立てて、スプリント毎にふりかえって、計画を見直す。これの繰り返しです。改めてソフトウェア開発に限らず色々な分野に応用できるフレームワークだと感じました。

プロダクトバックログにプロダクト以外のアイテムは入れるのか

先日の京アジャでプロダクトバックログ（PBL）にプロダクト以外のアイテムも入れるのかどうかについての議題がありました。僕は入れる派で今のチームでも入れていたのですが、これで良いのかどうかについては前から悩んでいました。

色々な意見や考え方を聞いて、考え直す良い機会なので改めて考えてみました。
注意：あくまで僕の意見や考え方なので、これが正解と言うわけではありません。

スクラムガイド的には入れない

スクラムで困ったときに見るドキュメントはスクラムガイドですね。PBLに関する部分では以下のように書かれています。

■プロダクトバックログ

プロダクトバックログは、プロダクトに必要だと把握しているものをすべて順番に並べた一覧である。
・・・中略・・・
プロダクトバックログは、今後のリリースで実装するプロダクトのフィーチャ・機能・要求・要望・修正をすべて一覧にしている。
・・・中略・・・
複数のスクラムチームが同じプロダクトの作業をすることがよくある。そうした場合、プロダクトの作業は 1 つのプロダクトバックログに記述する。また、アイテムを分類するための属性をプロダクトバックログに追加することもある。

プロダクトに必要なものは入れると書かれていますね。どういったものをプロダクトに必要なものと判断するかはチームによって異なると思いますが、プロダクトに関係ないものは入れないと読み取れます。
レトロスペクティブの結果を一つ以上PBLに入れるって記憶していたからプロダクトに関係ないアイテムも自信を持って入れていたのですが、スクラムガイドを見直すとプロダクトバックログではなくスプリントバックログの項目でした。

■スプリントバックログ

継続的改善を確実なものとするために、前回のレトロスペクティブで特定した優先順位の高いプロセスの改善策を少なくとも 1 つは含めておく。

PBLとは別で見える化

プロダクトに関係ないアイテムはPBLに入れないことが分かりました。じゃあ、それらのアイテムはどうやって透明性を高めるのでしょうか。チームメンバーの誰かがプロダクトに関係ないけど、やらねばならない作業を抱えていた場合、共有したほうが良いと僕は思っています。スクラムの価値基準にも「公開」が含まれています。プロダクトに関係ないけど、チームメンバーに関係するアイテムは共有して、少しでも気持ちよく助け合えるほうが良いと思っています。
じゃあ、これからの作業を登録するならPBLだ！っと思って、一時期は全部PBLに入れてPOに優先順位を決めてもらっていました。しかし、POもすべてのアイテムを把握するのに時間がかかり、優先順位が正しく付けられなくなっていました。そこでプロダクトバックログとは別のバックログ（NPBL（NotPBL））を用意することにしました。NPBLはプロダクトに関係しない各個人が抱えるアイテムを入れておき、管理も各個人が行います。そして、スプリントプランニング時に、スプリントで作業したい旨を相談して、チームで合意がとれればスプリントバックログに追加します。NPBLに入っていることで、各個人がいつごろにどんな作業を抱えているか共有できるようになりましたし、POもPBLの優先順位がつけやすくなりました。

NPBLはチームのモチベーションも高める

好きな書籍 アジャイルコーチング の「4.4 チームをやる気にさせる」の項目に以下の記述があります。

開発者たちが延々と続くユーザーストーリーを処理しながら燃え尽きていることがあります。

プロダクトに必要なものだけ開発しているとモチベーションが下がるタイミングもあると思います。プロダクトに関係あるか分からなくても新しい技術にチャレンジすることは時に必要で、そういった状況を作る意味でもNPBLは役に立つと考えています。

さいごに

このやり方はまだ始めたばかりですが、以前と比べて優先順位をつけやすくなり、今のチームにはあっていそうです。
スクラムは細かい進め方の決まりはないので「あれ？この時どうするの？」って時はチームで考えて、自分たちのより良いやり方を見つけ出す必要があるので、これからも色々と考えていきたいなぁと思います。

色々参考にしたサイト

スプリントのキャパシティを明らかにする方法 | Ryuzee.com
プロダクトバックログに技術的な項目を含めるべきか？ | Ryuzee.com
スクラムにおける技術的スパイクの進め方 | Ryuzee.com
Pairs事業部全体での「カンバン」を作成しました。 – Eureka Engineering – Medium
技術的負債のユーザストーリーを作るべきか

新しい体験を見つけるためのヒントになる本 / 「融けるデザイン」を読んだ

UXについて書籍やWebなどで情報を収集し始め、ペルソナやカスタマージャーニーマップのようなUXに関する多くの手法がある事は分かってきましたが、手法以外の理解も深めたいと思って「融けるデザイン」を読みました。

融けるデザイン ―ハード×ソフト×ネット時代の新たな設計論

本書を読むと日常生活に融け込んだデザインを探したくなります。ドアの形状、なぜか人が集まる場所、地面のタイルとタイルの隙間にできる溝、あらゆるところにデザインがあり、新しい体験のヒントが隠れています。それらを観察、発見し、仮説を立て評価していくことが重要だと気づきました。新しい製品やサービスは誰かの頭の中から生まれるのではなく、日常に隠れた課題を発見するところから始まるんだと分かり、その課題を発見するための手法が前回読んだUXリサーチの道具箱に書かれている手法なんですね。
iucstscui.hatenablog.com

色々な手法を知り、引き出しを増やす事も重要ですし、その手法を使いこなすために本書のようなインターフェイスと体験を軸にデザイン発想の技術を学ぶこともとても重要だと思いました。デザイナーに関わらずモノづくりに関わる多くの方にお勧めできる本です*1。

それでは、特に印象に残った部分について、まとめていきます。

2-1 透明性へのアプローチ1 : 道具の透明性

本書で取り上げる透明性は道具を意識せずに目的を達成できるインターフェイスです。

たとえばハンマーのように、手に持つとそれ自体を意識せずに、釘を打つこと（対象）に集中できるようなあり方を理想であると考えるようになった。

使いやすさを意識して開発はしていましたが、「その道具や機能をどうやって使いやすくするか」を考えていました。しかし本来の目的は釘を打つことで、使いやすいハンマーを作ることではありません。ここを忘れてしまうと間違った使いやすさを探すことになりますね。
また、本書を読んでハンマーを使っている時にハンマーを意識してないことに気づきました(考えたこともなかったですが)。普段の生活の無意識な行動を意識することで、使いやすいUI発想が強化されると感じました。

2-3 インターフェイスデザインの役割 ー 「可能」のデザイン

「できる」と「やる」は違う。

その通りだと思いました。どんなに良い機能でも手順が多かったり、直感的でなかったりすると使われません。また、同じ機能でも直感的かどうかはユーザーによって変わるので、ペルソナだったり、カスタマージャーニーマップを使ってユーザーを知っていく事が大切だと思いました。

3-11 新しいUXの基礎

本書でUXは「自己帰属」させることが大切だと書かれています。自己帰属感とは自分の意図通りに道具を操作できることで、その状態は道具の透明性が高くなり自分の機能が拡張された感覚になります。この感覚を作っていくことがUXデザインだと書かれています。

最近ではスマートスピーカーに新たな拡張性を感じます。声をかけるだけで、音楽がかかったり、ニュースを受け取れたり、様々なことができるようになってきました。透明性の点ではまだ改善して欲しいと思いますが、声で操作するUIは今まで少なかったので新しい体験を生み出していると思います。

5-1 コンピュータ利用の文脈の変化

インタラクションデザインは人間の生活側に設計要素の中心がある。したがって人間の振る舞いの理解がまず必要であり、そこに入り込む意味でのコンピュータの振る舞いの理解もまた必要なのだ。

以前コンテキストに関する勉強会に参加して、UX＝「ユーザーのタスク」＋「コンテキスト」だと学びました。まさにそのことですね。色々な製品は日常の中で使われるので、どういった場面のどういった環境で使われるのかを理解する必要がありますし、製品に触れる前後の時間も理解することでデザインは変わると思いました。また、このようなことを考えているとユーザーの限りある時間を使って製品に触れてもらうのだから、その時間を期待以上のものにしたいとも思いました。

さいごに

UXを少しずつ学んで得た断片的な知識の隙間を本書は埋めて繋げてくれた感覚になりました。
ユーザーの生活を知ることはものづくりのために大切なことで、ユーザーを知らないと作っても使われない機能になってしまいます。そのためにペルソナを作ってユーザーの特性を理解し、カスタマージャーニーマップやユーザーストーリーを作ってユーザーの生活を理解することが大切になります。また、日常をよく観察することが優れたUIやUXを生むことも本書は教えてくれたので、日々を意識して過ごしていきたいなぁっと思いました。
とても良い本でした。

コンテキストに関する勉強会の記事はこちらです。
iucstscui.hatenablog.com

*1:私もデザイナーではありません

ペルソナを作るメリットを考えてみた

UXでよく登場するペルソナ。
ペルソナとは作っている製品を一番使ってほしい人物像のことで30代男性のような幅広いターゲットではなく、電機会社で営業している日本太郎さんは映画が大好きで。。。のように具体的な一人を設定します。

このペルソナを作ることでどんなメリットがあるのか、調べ、考えてみました。

企画者、開発者が同じ方向を向ける

新しい機能を作るとき企画者の想いを開発者にコピーすることは出来ないので、認識のズレが発生します。
ペルソナがあると、なぜこの機能が必要なのかについてペルソナを軸に会話できるため、ズレが減り同じ方向に向きやすいと思います。また、開発者も作りこむ段階でペルソナを基準に様々な考慮ができ、思いやりのある製品ができると思います。

客観的に製品を見れる

いつも使ってくれる人の事を考えながら開発をしているつもりでも、いつの間にか作り手の目線で開発をしてしまうこともあります。「この機能は使いにくいと思うから・・・」と考えるときも、「私が使いにくいと思う」にならず、「日本太郎さんが使いにくい」と話せるようになり、客観的な視点を保って開発ができるようになると思います。

開発工数が削減できる

ペルソナを企画者、開発者で共有できている場合、認識のズレによるミスが減ります。そのため、手戻りが減り工数が削減できると思います。また、開発者が仕様を具体化していく際も誰に向けて作っているのか迷いがなくなり、スムーズな開発が期待できます。

さいごに

ペルソナは商品開発の中心に置くことで効果がでる手法だと思いました。また、企画者、開発者がペルソナについて同じ認識を持っていないと結局ブレにも繋がると思いますので、誰か一人が作って共有するのではなく、複数人でコミュニケーションを取りながら作り上げることも必要なのではと思いました。

参考

UXデザインにおけるペルソナの作り方を徹底解説！：えそらLLC UX ブログ
UXデザインにおけるターゲットとペルソナの違いと設定するメリット | HATLUSH Inc.
みずほ情報総研 ： “UX”やってみた

勉強を継続するための7つのヒント

書籍を読んだり、podcastを聞いたことを人に話していると「よく勉強してますね」って言われることがたまにあります。
まだまだ勉強が足りないと感じますが、僕が仕事以外の時間を使ってまで勉強するモチベーションは何だろうと考えたので書いてきます。

成長を実感する

長らく同じ業務をしていると現時点の知識で出来る事が多くなります。すると、成長を実感出来なかったり、マンネリを感じたりします。あまり知らない事を勉強対象に選ぶと成長を実感しやすく、モチベーションアップに繋がります。すると、また勉強したくなります。

知らないことを繋げていく

書籍を読んだり、勉強会などに参加すると分かることは増えますが、分からないこと(単語とか)も増えます。その分からないことを放置せず勉強します。すると、また分からないことが増えます。これを繰り返していくと、終わらないんです。また、これを続けていくと元々始めたジャンルから異なるジャンルを勉強することもあり、知識の幅が広がっていきます。*1

学んだことを現場に持っていく

僕は新しいもの好きなので勉強したことを現場で試したくなります。チームに影響がある場合はどんな目的で、どんな技術で、どういう風に取り入れたいかを説明する必要があります。説明の準備をしていると分かっていなかったことに気づき、追加で勉強をします。そして現場で試すと理解が浅かった部分や間違って理解をしていた部分で失敗します。なんで失敗したのかを考えたり、話し合ったりすることで次の勉強へ繋がっていきます。また、勉強したことが現場に活かせるので勉強した効果を感じられます。

現場で試す注意点としては本や他社事例と自分の現場は違うのでそのまま取り入れようとすると合わないことが多い点です。自分の現場に取り入れるにはどうすれば良いかは別途検討が必要になります。

勉強すると他の人より詳しくなれる

社会人は学生と違って皆で同じ教科を学ぶことはありません。そのため、会社の中で手薄な分野に興味を持って勉強をすると、その分野について社内で詳しい人になりやすいです。すると、質問や情報が集まってくるのでさらに詳しくなれます。これは成長を実感できますし、モチベーションアップに繋がります。

podcastはながら勉強に丁度いい

趣味でランニングをするのですが、podcastを聞きながらのランニングすることが多く、身体も脳も成長するので一石二鳥です。ランニングも続きにくい趣味なのでpodcastを聞くために走ろうっとなりやすく、相乗効果があります。

podcastは聞くだけで勉強になるので、他の作業をしながらできる勉強だと思います。
私が最近よく聞いているpodcastもまとめておきます。(説明文は各ページからの引用です)
omoiyari.fm(https://lean-agile.fm/)
　リーン / アジャイルが好きなおふたりが、それらについて思いやりを持って語ったり語らなかったりする Podcast
Fukabori.fm(https://fukabori.fm/)
　何らかの技術に詳しいゲストを読んで、その技術の入門から応用的な内容まで深掘りしていくPodcast
EM.FM(https://anchor.fm/em-fm)
　Engineering ManagerによるEngineering ManagerのためのPodcast
アジャイルラジオ(https://agileradio.github.io/)
　アジャイル開発に関するありとあらゆる情報を取り上げ、語り尽くす番組
Automagic(https://automagic.fm/)
　Webやアプリのデザインの仕事に携わる長谷川恭久さんが、今活躍していらっしゃるプロの方を招いていろいろな話

ブログ書くために勉強する

ブログを始めてからほぼ週1回は記事を書いています。ブログを書くためには何か新しい事が必要で、追われるように勉強しています。勉強は自己啓発なので仕事のように締め切りもないですし、プレッシャーも少ないです。そうすると怠けてしまいがちなので、週1回ブログを書くと決めてしまって、締め切りとプレッシャーを自らに課しています。

勉強しようと思ったときにすぐできる状況をつくる

私は本で勉強することが多いです。どこか出掛けるとき、勉強するつもりがなくても本を読みたいなと思ったら取り出せるように、大抵本を持ち歩いています(最近はkindleを持ち歩くことが多いです)。また、podcastもダウンロードして聞ける状態にしています。思い立ったが吉日っという言葉もあります。いつでもどこでも勉強できる状況を作っておいて勉強のモチベーションを下げないことも大切だと思います。

まとめ

勉強していない状態から勉強を開始するハードルは高いと思いますが、そこを乗り越えられると継続しやすいと思います。
勉強を開始するきっかけは人それぞれだと思いますが、始めだすと勉強することが楽しくなってきます。何か勉強してみようかなと思った場合は取り組みやすいpodcastから始めてみてはいかがでしょうか。

*1:僕もアジャイルから始まって、今はUXについて勉強しています

UX調査で使われる手法を学んだ / UXリサーチの道具箱

UXに関してプロセスや考え方の部分はwebで色々な方々が情報を公開されていて、参考にさせてもらう事で自分なりにUXが何なのか分かってきた気がします。でも、ユーザー体験をどうやって高めるのか、具体的に何をすればいいのか分からずモヤモヤしていました。調べているとキーワードとしてインタビューやカスタマージャーニーマップ等を知りますが、その手法を「いつ」、「どうやって使うか」に関する情報を上手く見つけられなかったので、本書を購入して読みました。

UXリサーチの道具箱 ―イノベーションのための質的調査・分析―

タイトル通り、UXで使われる手法の使い方を知ることができ目的は達成出来ました。あとは実際に使ってみて経験を積み、上達していければ良いなと思います。

本書を読んでみて考えた事についてまとめておきます。紹介されている手法については本書を読んで頂ければと思います。

ユーザーは自分の欲しいものに気づいていない

UXだったり、HCD(人間中心設計)だったり、デザイン思考だったり、色々な考え方があります。それらで共通していることは「ユーザーも気付いていない潜在的なニーズを発見すること」だと思います。そのためのアプローチは少しずつ違いますが、目指すべき場所は一緒だと感じました。

本書でも引用されている「人はドリルが欲しいのではない、『穴』を開けたいのだ」はモノ作りする時に考えておく必要がありますね。

ユーザーの欲しいものに気づく調査

UXリサーチの手法は潜在的なニーズを発見する手法だと言えます。インタビューはユーザーの体験を聞き出し、ユーザーも気づいていないニーズを発見する手法です。そのための質問の仕方だったり、質問の設計方法、インタビュー後のデータ分析方法を知ることが出来ました。

ユーザーが欲しいものに気づかないという点は、自動車で有名なヘンリー・フォードさんの言葉があります。

もし顧客に、彼らの望むものを聞いていたら、
彼らは「もっと速い馬が欲しい」と答えていただろう。

こういったユーザーも気づかないニーズをユーザーと向き合い、見つけて課題化しプロトタイプを作って評価してを繰り返していくことがUXなんですね。

課題を解決するためにはUIの知識がいる

UI/UXが一緒のキーワードで登場する理由はUXの知識だけではモノを作れないからだと思います。How(どうやって作るのか)はUXで語られないためUIの知識が必要になります。また、仮説検証を早く回すためにはUXとUIを出来ることは強みになるので、一人で両方できるとスピード感のある開発になりそうですが、負担も高そうですね。

また、モノを作るのはUIの知識だけでなく、ソフトやハードの知識も重要です。このように、誰か一人がUXを知っていれば良いわけでないですね。みんながUXについて興味を持ち、調査で分かったニーズにチームが合意して、同じ方向を向くことも重要だと思いました。

スクラムとも相性がよさそう

本書の中でもスクラムが登場しました。素早く仮説検証を回すためにはスクラムのフレームワークとUXのプロセスは相性がいいんでしょうね。ほかにもユーザーストーリーマッピングが紹介されていて、アジャイルやスクラムについて学んだことがUXと紐づくとは思っていなかったです。スクラムとUXを学んでいくことで良い相互作用が生まれそうでワクワクします。

まずはユーザーを知る事

UXを勉強し始めたときはペルソナやカスタマージャーニーマップを作れば良いと思っていました。しかし、ペルソナやカスタマージャージニーマップよりも前にユーザーを知る必要が分かりました。そのためにユーザーにインタビューするなり、社内でユーザーに接する機会が多い人に教えてもらおうと思います。

過去記事

UXとは何かの部分は以下の記事にまとめました。こういったまとめを行ったおかげで少しずつUXの理解が進んでいると実感します。
iucstscui.hatenablog.com
iucstscui.hatenablog.com

UXの分かりにくかった点が整理できた / UX白書 を読んだ

UX白書

UXについて調べていると"UX白書"というpdfを見つけて読みました。

UX白書(日本語訳版).pdf

表紙を含めても20ページと少ないページ数でUXの概念を理解するために必要な情報がまとめられていました。具体的な実践方法には触れられていないため、これだけでUXをデザインすることは難しいと思いますが、UXに興味を持っている方は短時間で読めるので一読されてはいかがでしょうか。

具体的な内容は本書を読んで頂き、私が読んで新たな気づきを得た点についてまとめていきます。

UXという言葉が分かりづらいのは、色々な視点や観点で語られるから

本書の「はじめに」にUXは多くの分野で使われているため、色々な視点や観点で語られ一言で説明できないと書かれていました。分野は「現象としてのUX」「研究分野としてのUX」「実践としてのUX」の３つに分類されていました。

これが私のような初学者を悩ませるポイントだと思います。勉強を始めた頃はUXをツールだったりプロセスだったり、具体的な何かだと思っていましたし、そのような情報を求めながら調べていました。すると「ペルソナ」や「カスタマージャーニーマップ」のような手法に出会いますが、これらは「実践としてのUX」で３つの視点の内の１つです。調べていくうちに他の視点のUXもインプットされ、混乱してしまっていたと気づきました。

3つそれぞれもUXだし、まとめてもUX

３つに分類はされていますが、まとめてUXと言えます。１つ１つもUXと呼んで間違いないと思いました。それぞれは独立し、関連しあっています。
「現象としてのUX」をより良くするために「実践としてのUX」があり、「実践としてのUX」をより良くするために「研究分野としてのUX」があります。

UXはユーザーがシステムに対して受ける感情です。そして、それを良くするための行動もUXです。UXはユーザー体験にまつわるコトなんですね。

UXを学んでいくときの手助けに

UX白書でUXの3つの分野について知ることができた。今後UXについて調べたり学んだりする際はどの分野の事か意識することで理解の手助けになると思います。

参考

以前にUXとは何かを掴もうと、エレベーターピッチを使ってUXを説明しました。
iucstscui.hatenablog.com