第10回_業務システムのUX/UIデザイン改善によくある間違いとその解決策

Transcript

1. 業務システムのUX/UIデザイン改善に よくある間違いとその解決策（PART 1） SIer/情シス向け「ITとデザインは仲良し︕」シリーズ 第10回 2022/3/3
2. 2 今⽇のスピーカの紹介 2 ۚ ੒఩ 3PZ
   ,JN 69
   &OHJOFFS
   
   $&0
   PG
   'JYFM *OD 商社マン プログラマー ITコンサルタント/アーキテクト プロダクト オーナー アプリ開発者/システムアーキテクト UXデザイナー、サービスデザイナー グランスフィア株式会社 （現 GMOシステムコンサル ティング株式会社） ⼤林コーポレーション（株） BEA Japan Oracle Japan EMC Japan Agentec株式会社 NCデザイン＆コンサルティング 株式会社 （現NCDC株式会社） Fixel株式会社 ΩϟϦΞ 5年 10年 12年
3. 3 今⽇のスピーカの紹介 3 ۚ ੒఩ 3PZ
   ,JN 69
   &OHJOFFS
   
   $&0
   PG
   'JYFM *OD 営業 テクノロジー UX/UIデザイン 経営 5年 10年 12年 ある程度は、俯瞰できます︕
4. 4 l Fixel株式会社の経験からの抜粋です l 偏った内容である可能性があります l 今⽇話す内容は現段階の話で、⽇々の業務から得る知⾒によって、常に変 わっています l 業務システムのUX/UIデザインを⾏う⽴場（UX/UIデザイナー）の話です l ただし、それを頼む⽴場の⽅にも参考になるかと思います l 今⽇は全体の内容からの⼀部だけになります l 全部で３回のウェビナで構成される予定です 前提
5. 5 今⽇話す内容の対象範囲 提案 と 契約 UXデザイン UIデザイン デザイン システム 作成 実装⽀援 デザイン レビュー アセスメン ト
6. 提案と契約
7. 7 u 課題 顧客 ︓「え︖成果物って、HTMLのコードではないの︖」 デザイナー︓「いや、デザインするとは⾔ったけど、コーディングは⾔ってま せん︕」 u 解決策 l 提案書の中の⽤語で具体的に何を指しているかを明確にする l デザイン︓Figma? HTML&CSS? l プロト︓Figma? HTML? アプリケーション? 提案時は成果物を明確に定義する
8. 8 u 課題 デザイナー︓「本当の課題って、実は別にあったのではないですか︖」 顧客 ︓「確かに︕しかし、契約の内容が決まっているので困る︕」 u 解決策 l できれば準委任契約にする l アセスメントだけを分割契約して、ズレをできるだけ事前に防ぐ l 請負契約なら、提案書と契約書の中に但し書きで柔軟性を担保 「ただし、作業開始後、貴社との調整の上、作業内容や成果物を変更させてい ただく場合があります」 柔軟性をもつ契約を結ぶ
9. 9 u 課題 デザイナー︓「蓋を開けてみないと、どれくらい⼯数かかるかよく分からない ので、バッファを持つしかないですね」 顧客 ︓「しかし、⼤きな⾦額をいきなり契約するのは怖い」 u 解決策 l 契約を分割して、段階別に次のフェーズの⾒積もりを作成することで精度を 上げる l 分割例︓アセスメント（準委任） ⇒ UXデザイン（以降、請負） ⇒ UIデザイ ン＆ビジュアルデザイン ⇒ デザインシステム作成 ⇒ フロント実装 l 最初の提案時に、概算を前提に全体の⾦額感の共有は必要 契約を分割することで⾒積の精度を上げる
10. 10 良くある契約の分割パターン アセスメント UXデザイン UIデザイン 再⾒積 再⾒積 初期⾒積 デザインシステム 作成 実装⽀援 デザインレ ビュー 再⾒積 契約１ 契約２ 契約３ 契約１（All In One） 契約１ 契約２ 契約３ 契約１ 契約２ 契約３ 契約４ 契約４ デザイン チケット＊ ＊デザインチケット：デザイナーの稼働をチケットの形態に事前に購入し、必要な時に即時に使う 再⾒積
11. アセスメント
12. 12 l 既存システムの分析 l 課題の整理、優先度付け l デザインのゴール、KPIの定義 l プロジェクト全体のスケジュール作成 l 後続する契約単位の⾒積もり作成 アセスメントフェーズでのタスク アセスメント UXデザイン UIデザイン デザインシステム 作成 実装⽀援 デザインレ ビュー
13. 13 u 課題 顧客 ︓「これが課題の⼀覧。あ、それは技術的な課題だから対象外ね」 デザイナー︓「いや、それも⾒せてください」 u 解決策 l ユーザー、カスタマサービス、営業、システム側の話を聞く l 技術的な課題は実はUXの課題であることが多いので必ず確認する l ヒューリスティックテストを⾏い、デザイナーの視点での課題を追加する l Great!⇒Good⇒Not Good⇒Bad! l GreatとGoodをうまく混ぜる l 課題の共有と重要度と優先度を合意する お客様の⾔葉を信頼しない
14. 14 u 課題 顧客 ︓「ユーザーが触りたい、使いたいと感じるUIにしてください」 デザイナー︓「これ、不良品検査⽤のシステムですけど︖」 u 解決策 l 業務⽤のシステムに求められるデザインのゴールはB2Cのそれとは異なる l 対象のシステムに求められるUXを適切に定義する。 l 例えば、 l 作業効率を上げる、ミスを防ぐ l 初期トレーニングの時間を減らす、問い合わせ数を減らす l 営業・マーケティングで有効 デザインのゴールの適切さを確認する
15. 15 u 課題 顧客 ︓「初⼼者でも使い易く、熟練者の作業効率を上げるものにしたい」 デザイナー︓「ご注⽂は、熱いアイスコーヒーですね︖」 u 解決策 l みんなを幸せにはできない。幸せにしたい⼈を選ぶ l マニュアルなしで使えるもの vs ⽞⼈⽤、どちらが必要か︖ l 両⽅を求められるなら、モードを分けるか、フェーズを分ける l ⼆股は時間と努⼒が必要︕ l そして、多くの場合、幸せになれない デザインのゴールを適切に定義する
16. 16 u 課題 顧客 ︓「最⾼のデザインにしてください」 デザイナー︓「それ、不要です︕」 u 解決策 l toBやtoEの場合、デザインに対する過度な投資はコスパが悪い l ビジネスに必要なレベルのデザインを⾏う。それ以上は無駄。 l デザインは⼿段であり、⽬的ではない l 外販するプロダクトの場合、競合のデザインを分析し、⼀つの基準にするこ とも有効 最⾼でデザインではなく、最適なデザインにする
17. 17 デザインに対する無駄な投資をやめる [UX Pyramid] 今はどのレベルか？
18. 18 デザインに対する無駄な投資をやめる [UX Pyramid] 今はどのレベルか？ 競合はどのレベルか？
19. 19 デザインに対する無駄な投資をやめる [UX Pyramid] 勝つにはどのレベルが必要か？ 競合はどのレベルか？ 今はどのレベルか？
20. 20 デザインに対する無駄な投資をやめる [UX Pyramid] 勝つにはどのレベルが必要か？ レベルアップに かかる費⽤は︖ そして、その価値は︖ 競合はどのレベルか？ 今はどのレベルか？
21. 21 デザインに対する無駄な投資をやめる 品質 時間 初回UXデザインプロジェクトの 効果が最も⼤きい フェーズ 1 フェーズ 2 Quality of UX
22. 22 u 課題 デザイナー︓「これは、６ヶ⽉はかかりますね。」 顧客 ︓「いや、実装部隊がもう待っていますけど。」 u 解決策 l プラニングの時から、実装のスケジュールを確認し、それから逆算してデザ インのスケジュールを調整する l 五⽉⾬式に成果物を出すように調整することで最⼤限の作業時間を確保する l ワイヤフレーム ⇒ 基本設計 l ビジュアルデザイン ⇒ 詳細設計 l デザインシステム・UIコンポーネント ⇒ 実装 デザインだけでなく、実装のスケジュールを意識する
23. 23 ITのスケジュールを考慮したデザインの成果物提⽰を意識する ＊過去のウェビナ資料から抜粋
24. 24 ⽉ 1 2 3 4 5 6 7 〜12 Fixel 外部 ベンダー 契約単位 契約１ アセスメント 契約２ 要件定義・フィジビリティ検証 契約３ 設計・実装 実際のスケジュール作成例 現状把握、業 務理解、プロ ジェクト計画 要件定義 （ワイヤーフレーム作成） ビジュアルデザイン 実装、テスト、納品 要件定義完了 （ワイヤーフ レーム更新） フィジビリティ検証 連携対象システムの設計 〇〇◯設計 実装、テスト、納品 ✔ 上記の⽇程は仮のものです。ある程度の調整幅はあり得ますが、全体期間を1年に⾒ております ✔ フィジビリティ検証には、場合によっては上記の想定以上の時間がかかる可能性があります ✔ フェーズに分けて、複数回の⾒積更新を⾏い、⾒積の精度を上げて⾏くことで、無駄なバッファーを減らします ✔ 契約の単位も上記の再⾒積実施の時期を基準に分割できるかと思います 機能要件 整理 再⾒積 再⾒積 初期積 ユーザー テスト ユーザー テスト サンプル
25. UXデザイン︓分析と仮説検証
26. 26 アセスメントフェーズでのタスク アセスメント UXデザイン UIデザイン デザインシステム 作成 実装⽀援 デザインレ ビュー 反復 コンテキスト分析 ジャーニーマップ 作成 メンタルモデル 分析 ワイヤーフレーム作 成 ユーザーテスト 評価と改善 ゴールと 範囲の設定 評価基準の検討 ペルソナ定義 ① 計画フェーズ ② 分析フェーズ ③ 実証フェーズ プロトタイピング
27. 27 u 課題 顧客 ︓「じゃあ、デザインの改善案を出してください」 デザイナー︓「先ずは、業務を教えてください。」 u 解決策 l 多様な業界の異なる業務を迅速に習得する必要がある l 短期間で、効率よく学べる⼿段をお客様に提供していただく l 業務の説明を受ける、現場を⾒学する、経験する l 教育やトレーニングを受ける l 経験が溜まると、短期間で学習できるようになる︕ 先ずは、業務を学ぶ
28. 28 先ずは、業務を学ぶ コールセンターの業務トレーニング（1.5ヶ月） モーター制御方法の学習（１ヶ月）
29. 29 u 課題 顧客 ︓「渡部さん（ペルソナ）は明るい性格で、猫を飼っています」 デザイナー︓「それ、関係ないです。（ちなみに、私は⽝派です。）」 u 解決策 l ペルソナの私⽣活における個⼈的な差はあまり意味がない l 業務はユーザーの特性とコンテキストを制限するので、考慮すべき項⽬は減る l 業務を⾏うというコンテキストで考慮すべき特徴だけをペルソナの特徴とし て定義する l 業務熟練度やITリテラシーは結構有効な特徴 l アクセシビリティは案外重要ではないことが多い 2Cのサービスに⽐べ、ペルソナの定義はシンプルに
30. 30 u 課題 顧客 ︓「ユーザーに対するアンケートも⾏ってくれるんですね︖」 デザイナー︓「それ、本当に要りますか︖」 u 解決策 l やたらとアンケートなどの定量的なリサーチを⾏いたいと思っている、また はそれをやるのが当たり前と考えているお客様が多い l 業務システムの場合、ユーザーに直接会える、観察できることが多いので、 アンケートが必要なことはあまりない l アンケートで得たいものを確認し、より適切な⼿段を提案する アンケートよりはヒアリング、その後に観察
31. 31 u 課題 顧客 ︓「ユーザージャーニーマップって、業務フロー図と何が異なる︖」 デザイナー︓「…。」 u 解決策 l ユーザージャーニーマップはユーザーの視点から記述され、ユーザーが感じる 不満、隠れたニーズに気付くことができる l 各業務の前後のユーザーの⾏動まで記載することで、より広い範囲で捉えるこ とで新しい改善点を⾒つけることができる l コンテキストを追記することで更なる改善点を⾒つけることができる ジャーニーマップって、業務フロー図じゃないの︖
32. 32 u 課題 顧客 ︓「ユーザージャーニーマップって、業務フロー図と何が異なる︖」 デザイナー︓「…。」 u 解決策 l ユーザージャーニーマップはユーザーの視点から記述され、ユーザーが感じ る不満、隠れたニーズに気付くことができる l 各業務の前後のユーザーの⾏動まで記載することで、より広い範囲で捉える ことで新しい改善点を⾒つけることができる l コンテキストを追記することで更なる改善点を⾒つけることができる ジャーニーマップって、業務フロー図じゃないの︖
33. 33 u 課題 顧客 ︓「ユーザージャーニーマップって、業務フロー図と何が異なる︖」 デザイナー︓「…。」 u 解決策 l 新規サービス、システム作成の場合はかなり有効︕ l デザイナーが業務を理解するための有効な⼿段 l 顧客やユーザーは⾃分達の固定概念に気付くことができる l ⾃然に改善点の話になる l ⾏動と⾔葉の相違を⾒つける。 5Whyを有効に活⽤ l ジャーニーマップからコンテキスト追記、そしてサービスブループリントに 発展させて⾏く ジャーニーマップって、業務フロー図じゃないの︖
34. 34 ジャーニーマップからサービスブループリントに、徐々に発展させて⾏く︕ https://fixel.co.jp/blog/service-blueprint/ エンジニアとの 共同作業が望ましい
35. 35 ジャーニーマップからサービスブループリントに、徐々に発展させて⾏く︕ https://fixel.co.jp/blog/service-blueprint/ エンジニアとの 共同作業が望ましい 詳細は次回に︕
36. 36 u 課題 デザイナー︓「こう処理した⽅がもっと便利そうですね。」 顧客 ︓「法律な制約があって、無理です」 u 解決策 l 業務フローは取り扱う情報とその処理を元に定義されることが多い l ユーザーの利便性より、優先される要件や制約がある l 法律、セキュリティ、契約条件、物理法則、安全、製品の品質など l これらを満たしながら、ユーザーが使い易くする必要がある l 結果的にUIレベルで対応せざるを得ないこともある l 事前に（業務の学習の際に）、考慮すべき制約事項を確認する ほとんどのものには、理由がある
37. 37 u 課題 デザイナー︓「このUIはひどいですね︕変えましょう。」 顧客 ︓「業界の共通的なガイドラインなので、無理です」 u 解決策 l その常識（ガイドライン）は本当に従うべきか︖を確認する l 常識には理由がある。それを確認する l 守るべきものは、思いなのか、形なのかを確認する l 趣旨を守りながら、形を変えることはできる l 勇気を持つ︕あるいは、⼩さく始め、試してから広げる 業界の常識を無視するか︖
38. 38 デザインガイドラインの趣旨は⽣かしながら、新しい解釈を提⽰する After：Fixelの新しいデザイン Before：業界のデザインガイドラインに準拠
39. To Be Continued…
40. 最後に l 業務システムのUX/UIデザインに興味があるデザイナーを募集しています。 l デザインシステムに興味があるデザイナーを募集しております。 l 周りに興味のありそうな⽅に、 是⾮ご紹介ください。 l 申し込みは弊社のウェブサイトから お願いします︕ https://fixel.co.jp/blog/recruit-20210929/
41. MAKE DESIGN EASY SIer/情シスのデザインパートナー ありがとうございました︕ アンケート記⼊のお願い