2024-09-01
🏤メモ: “UIデザイン みんなで考え、カイゼンする。”
1章 Webサービスの”カイゼン”と運用
- 現状において何が価値で何が問題となり得るのかを把握することが改善のスタート
- ペルソナは具体的な人物像のイメージをチーム内で統一するために必要
- 理解 → 観察 の流れは逆かなと思ったけどどうだろう
- 施策ありきではなく、仮説ありき
- ユーザ視点 → 行動の理由や利用状況、ユーザの本音を知りユーザの理解に近づく
- 問題は原因そのもの、課題は原因を改善するための取り組み
- PDCAは何らかの課題を解決するためのフレームワーク
- PDCAは、そもそも工程が明確になっていないものに対しては効果的ではない
- Howを考えるのに効果的
- OODAはは意思決定するためのフレームワーク
- 共通の理解がない → プロダクトのクオリティ低 → 体験設計が加味されない → 開発の大きさがリスクになる
- ダブルダイヤモンドの展開て何だっけ
- 1-9 UIデザインの段階でデータの関連はどこまで考えられるものなのか気になる
- プロトタイプを完成物として認識しないこと
- プロトタイプを確認してもらう際は、どの部分を確認してほしいのかを明確にすること
2章
- サービスフローとスキルマップの図わかりやすい
- 情報を時系列で整理するとよい。利用シーンを漫画にすることで漏れに気づける
- UIフローあると嬉しい。どこでどんな情報が必要で、何をするとどこに行くのか見てわかる
- 仮説や仕様がぼんやりな初期フェーズでは、あえて荒い下書き状態にするほうが、ビジュアルではなくアイデアや情報設計に焦点を当てて議論しやすくなる
- スタイルガイドはサービス提供者側のメリットばかり考えていたが、サービス利用者にもわかりやすいサービス体験を提供できると知った
4章
- ユーザーリサーチは、チームでドメイン知識やユーザー行動を学ぶ機会、サービス改善のPDCAサイクルをもたらす
- ユーザーモデリング = 調査データをもとに、サービス開発で活用できる次元の情報に翻訳するまでの過程
- ユーザーインタビューは何かを決めるための議論ではなく、相互理解を通じて新しい捉え方や気づきを生むための対話
- リクルーティング = ユーザーインタビューの対象を集めること
5章
- デザインシステムを構築、運用していく上で、「良いデザイン」を誰もがわかる形で明確にし、共有することが必要
- 機能パターンと認知パターンあんまりイメージついてない
- デザインシステムは構築にかなりのリソースを要するため、一つの作業ではなく「プロダクト」として取り組むことを前提としなければならない
- デザインシステムは構築から運用に載せるための戦略性や計画性が必要になる
- スマートフォンだけで100ページを超えるような大きなサービスをフルリニューアルするのは膨大な時間がかかる。A/Bテストの実施は辛い
- デザイナーとエンジニアの深刻な分業問題と知識の断絶
- サービス内のページやUIパーツごとにデザインファイルが管理されており〜
- デザイナーとエンジニアで用語の定義が異なっているパターン
- UIイベントリ ＝ デザインガイド？
- デザインの構築動機は、継続運用したり、成長させたりする対象のプロダクトやサービスあってのこと
6章
- 技術の特性を理解できることで、デザイナーは最適な体験の設計ができる
- どのようなユーザーにどのようなシナリオで価値を提供するか、常にビジョンを共有する
- 視点によってUXの意味が異なる
- UXデザインを実践する上で必要になる情報は膨大。チームでの協業に加えて、共に学ぶという姿勢も必要になる
けけずん積読消化記録