サービスデザイン: フレームワークと事例で学ぶサービス構築 | 山岡 俊樹 |本 | 通販 | Amazon という書籍を読んでいて、5章の汎用システムデザイン方法 フレームワークの手法が気になったので、手法について調べた結果をまとめます。
フレームワークの手法
以下の手法が定義されています。
- 2つの評価軸
- コレスポンデンス分析
- 観察法
- 3P タスク分析
- 5P タスク分析
- ユーザビリティタスク分析
- UX タスク分析
- UX 表
- タスクシーン発想法
- 評価グリッド法
- 許容範囲測定法
- プロトコル解析
- REM
- AHP
- GUI チェックリスト
- パフォーマンス評価
- SUM
- SUS
- サービス事前・事後評価法
- 簡易サービスチェックリスト
各手法を調べる
2つの評価軸
書籍の98Pに記載があります。
製品やサービスの評価に適した2つのキーワードで5段階評価のアンケートを行う。
3つ以上のキーワードの場合、2つの組み合わせで軸を作り同様の作業を行えばよい。
2軸でデータの可視化が容易な手法なので、気軽に使えそうに思いました。
ただ、2軸として何を設定するのかが素人には難しそうに思います。
コレスポンデンス分析
書籍の99Pに記載があります。
2軸で評価するよりも、より厳密に深く検討したい場合に、コレスポンデンス分析(correspondence analytics) とクラスター分析を活用する。
マーケティングで、市場での状況把握(ポジショニング)に使われる手法です。
-
参考
-
Google Analytics のデータでコレスポンデンス分析をした記事
そういえば、過去にGoogle Analytics のデータでコレスポンデンス分析を実施していました。
観察法
書籍の83Pから記載があります。
マクロ、ミクロ視点があり、それぞれ以下のような観点ポイントがあります。
-
マクロ的視点から観察する
- 環境面から観察する
- 運用面を観察する
- 痕跡を観察する
- 仮想コンセプトを考える
-
ミクロ的視点から観察する
- 基準の動作との差異を観察する
- 多様なユーザの特徴を理解し観察する
- ユーザや作業の流れを観察する
- サービス提供者と顧客のやり取りを観察する
- 70デザイン項目の視点から観察する
-
参考
3P タスク分析
書籍のP90から記載があります。
情報入手
、理解・判断
、操作
の3つの観点から分析し、予測される問題点を抽出する手法です。
個人的に、シーンの特定という手順があまり考えたことのない手順で、印象的でした。
5P タスク分析
書籍のP92から記載があります。
3Pタスク分析に空間や運用面なども加味し、システムやサービスの問題点や要求事項を抽出する場合に使う方法です。
以下、5つの側面から、問題点なり要求事項を抽出します。
1. 身体的側面
2. 頭脳的側面
3. 時間的側面
4. 環境的側面
5. 運用的側面
5Pタスク分析に以下のサービス3項目を追加したサービスタスク分析もあります。
1. 気配り
2. 適切な対応
3. 態度
ユーザビリティタスク分析
書籍に説明がなかったように思いました。
ユーザビリティタスク分析で要求事項を抽出する - J-Stage の説明文書を引用します。
各タスクに対して,良い点,悪い点を実験協力者に回答してもらうか,実験者自ら記入しても良い.そして,各タスクの評価を行う.
評価は,製品の場合は5段階評価,GUIの場合は3段階評価で行う.
各タスクについて、良い点、悪い点を回答者に評価してもらうもので、汎用的に使えそうに思いました。
自由回答なので結構サンプル数が必要に思います。
UX タスク分析
書籍のP35 に記載があります。
分析の方法は以下の通りです。
1. どういう仕事や作業を分析するのか決める。
2. 仕事や作業を分解して、タスクを書く。
3. タスクに関する、やり取りのUXの要求事項を書く。
4. 3.
で求めたUXの要求事項に関するUXに係る感覚を書く。
5. 4.
で抽出したUXに係る感覚に対して生じると思われる感情を書く。
表形式でアウトプットが作れます。
スプレッドシートでテンプレートを準備しておくと良いかもしれません。
UX 表
調べてみましたが、情報を見つけられませんでした…
タスクシーン発想法
書籍のP95に記載があります。気になった記述を引用します。
タスクシーン発想法は、ブレインストーミングや、ブレインライティングのようにモニターの発想能力に依存するのではなく、簡単なフレームワークが決めらられており、これに従ってニーズを抽出する方法である。
時間軸上のタスクに対して、使いたいシーズが対応できるのかチェックする方法である。
時間軸と、シーンの軸 2軸で表を作る雰囲気で、シーンの軸は、日常生活系と、非日常生活系の2つに分けられます。
1. 日常生活系
家庭軸、オフィス軸、通勤軸、公共環境軸
- 非日常生活系
旅行軸、出張軸、イベント軸
評価グリッド法
書籍のP89に記載があります。
ユーザーに調査したい商品やサービス群のうちから、評価をしてもらい、その理由を聞いて、ユーザーのそれらに対する価値観を探る方法である。
回答の上位概念と、下位概念を探るためのラダーリングという言葉に興味を持ちました。
- 参考
許容範囲測定法
書籍には記載がありませんでした。
木製筋力トレーニング椅子のデザイン提案 - J-Stage の記述を引用します。
許容範囲測定とは, 実験参加者が自分で許容できる刺激の上限値, 下限値および最適値の 3 つの値を申告する方法である
プロトコル解析
書籍のP125に記載があります。書籍の記述を一部引用します。
プロトコル解析は実験者が実験協力者に対し、製品やシステムを操作させてもらい、そのときに困ったことや感じたことを述べてもらい、問題点を抽出する方法である。
プロトコル分析
とも呼ばれる手法で、元々は心理学で使われていた手法のようです。
REM
書籍のP93に記載があります。書籍の記述を一部引用します。
サービスを受けたときや製品・システムを操作したときに、悪いと感じた事項を基に、どの根本原因あるいは究極の目的を求める方法である。
個人的にこの図はシステム開発のプロセスの問題点分析にも使えるように思います。
AHP
書籍には記載がありませんでした。集団AHP – U-Site の記載を引用します。
AHP(Analytic Hierarchy Process:階層化分析法)は、消費者が商品を選んだり、魅力を評価したりする際の感覚的な判断基準を定量的に捉える手法です。
評価基準を切り替えながら、重要度が高い要因を分析するための手法です。 RとPythonでライブラリがあり、興味を持ちました。
- 参考
GUI チェックリスト
一般的なチェックリストはいくつか見つかりましたが、情報を見つけられませんでした…
パフォーマンス評価
書籍のP127に記述があります。書籍の記述を一部引用します。
あるタスクに対する作業成績をパフォーマンスという。パフォーマンスの視点から、作業時間やエラー率などでタスクの効率などを定量的に評価する。
パフォーマンス評価は、ソシオメディア | ユーザーエクスペリエンスの測定 の、パフォーマンスメトリクス と同様のものかと思います。
- 参考
SUM
書籍には特に記載はなかったです。Single Usability Metric (利便性の尺度)
という指標です。
- 参考
SUS
書籍には特に記載はなかったです。System Usability Scale のことです。
以前、まとめた記事を投稿していますので、記事のリンクを記載しておきます。
サービス事前・事後評価法
書籍のP123に記載があります。書籍の記述を一部引用します。
サービスの評価は、サービスに対する顧客の事前期待と、サービス提供後の事後評価との差分によって行われる。つまり、「事後評価 - 事前期待」の差によってサービスの評価がなされる。
サービス内容を、メインサービス、サポートサービスに分け、メインサービス、サポートサービス、価格の事前期待を計測し、それぞれの事後期待を測りそのポイントの差を測定します。
- 参考
簡易サービスチェックリスト
書籍のP126に記載があります。
以下の7つの項目と総合評価に対して、5段階評価でチェックをしてもらい、部分的にサービスの評価を得る手法です。
- サービスを受ける際、顧客が不安を抱かないよう配慮されていたか?
- サービス提供者にスキル、知識はあったか?
- サービス提供者の態度は良かったか?
- メインサービスは良かったか?
- サービスは効率よく行われたか?
- 環境は良かったか?
- 設備は良かったか?
- 総合評価
感想
以下のような感想を持ちました。
- サービスデザイン なので、Webシステムから離れた部分の評価手法も含まれるのは興味深い。
- ITエンジニア職視点で使う場合は、プロダクトに関わる立場にもよるが、Webシステム側とオペレーションとかで少しテーラリングしておくのが良さそう。
- パフォーマンス評価 、AHP はPython 文脈で深掘りしてみたい。
- REM は実際にとりあえず個人で実施してみたい。
参考
-
政府CIOポータル
政府CIOポータルサイトに、サービスデザインの関連文書がいくつかあります。 - サービスデザインの時代 - J-Stage https://www.jstage.jst.go.jp › article › johokanri › _pdf
- 観察工学の考え方と方法 - J-Stage
以上です。
コメント