この記事について
この記事では、前半、後半に分けて以下のことを書いていきます。
【前半】
『UI/UX デザインの原則』（平石大祐 幻冬社)で学んだこと
【後半】
「受託開発」におけるUI/UX
特に後半は、私の業務経験に基づき、問題点や解決策について書いきます。
『UI/UX デザインの原則』を読んで学んだこと
・UI/UXの違い
まずは前提のおさらい
UI：できていても差別化にはならない、できていないと離脱につながる
UX：競合との差別化、利益につながる
大前提の「使い勝手」を整えるのがUI
・ユーザー視点で考える
本書では、「ユーザー視点」で考えることの必要性を説いています。
しかしながら、WEB担当者とユーザーでは前提が違う。
ニーズがすれ違うことに注意しなければなりません。
特に意識すること
・機能の優位性
・機能が認識されない要因を探る（導線にあっているか、視線にあっているか）
・サービスの「利用前」、「利用中」、「利用後」に分けて考える
UXを考える際に、３つのフェーズに分けると考えやすいです。
利用前：不安の解消
↓
利用中：行き詰まったときのサポート、スムーズな導線
↓
利用後：結果の確認など
受託開発におけるUI/UX
ここまでを踏まえて、早速業務に活かそう！
と思っても、すぐにはできない。
なぜなら、自社サービス開発と受託開発では違いがあるからです。
・問題点
受託開発において、「〜〜の機能を作って欲しい」と依頼された際の問題点を挙げてみます。
情報不足
必ずしも以下の情報が提供されるわけではない。
・ペルソナ（ユーザーの情報、特徴）
・利用シーン（いつ、どこで、どのように）
納期
「UI/UXの優れた機能を作ること」が要件に入っているわけではない。
「UI/UX」より「納期」が優先されることが多く、トレードオフの関係にある。
UI/UXが重視されていない
そもそも、先方の担当者がUI/UXを重視していなければ、UI/UXについて意見するのは難しい。
うざがられる可能性がある。
ユーザーテスト
先方の方針に依存する。
やらないケースもある。
こちらは実装後のフェーズになるので、あまり気にしなくてよいと思う。
解決策
納期と情報不足
開発フェーズをざっくり
依頼を受ける→設計→実装
設計フェーズまでに以下をできる限りやる。
・情報収集
・UI,UXの議論（社内、先方と）
実装フェーズ以降は、UIの変更や議論をする余地はない。
なぜなら納期があるから。
UI/UXの重要性を認識
情報不足を解決しても、すぐにUI/UXが改善されるわけではないと思います。
ですが、重要視し続けることで、好循環が生まれればいいなと思います。
まずは、開発メンバでUI/UXを意識する
↓
先方といい感じの議論をする
↓
先方もUI/UXを意識するようになる
↓
良いサービスが生まれ、先方とも良い関係が築ける
楽観的ですが、、。
最後に
UI/UXを考慮しながら開発することは重要。
経験値として溜まっていく。
思いつきで書いたため、半年後に見返してアップデートしていきたい。
「受託開発」におけるUI/UXについての情報が見つからなかったので、
情報いただけたら嬉しいです。