この記事について

この記事では、前半、後半に分けて以下のことを書いていきます。

【前半】
『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についての情報が見つからなかったので、
情報いただけたら嬉しいです。