UI初心者がぶつかること② ～制約との共存～

UXをデザインするのに重要な要素の一つがUI（User Interface） 。

ユーザーが気持ちよく使えなかったら不満なユーザー体験しか与えられません。よいUXを提供したければ、利用品質を高めるUIにもこだわりたいです。

その満足度を細部までしっかり行き届かせるために考慮すべき要素が「制約」です。

今回は「制約」と共存して利用満足度をあげていこう。という話を書いてみます。

まず、制約と向かい合うためには、プロセスの改善から必要です。

制約は一見とても地味。

制約とUIとの関わりについて、重要性を知っていないと地味な制約は後回し(むしろ放置)にされがちです。

しかし、Webサービスやアプリを世に出すためには、それらを動作させる何らかのシステムやプラットフォーム（OS、データフォーマットなど各種）が必要です。

そして、どんなシステムにも必ず「制約」があります。なので、思い描くUXの実現にも制約がついてまわります。

制約の中で、どうやって理想的なUXを実現させるか。
そのために、ユーザビリティをどう担保するか。

ここにこそUI設計者の出番なのですが、UI設計者だけで解決できるわけではありません。
制約に詳しい実装担当者とノウハウを融合する必要があります。

では、

制約に詳しい実装担当者と、どうすり合わせしたらよいか？

このプロセスがなかなか難いのではないでしょうか。

UI設計と実装担当の関わり方は、開発プロセスによってまちまちかと思います。

私がこれまで見てきた中では、大きく２つのやり方がありました。
だいたいどちらかのパターンになっているかと思います。ただ、どちらにも欠点があります。

まずその２つのパターンを紹介し、その後に、おすすめのやり方を説明したいと思います。

UI設計者がずっと張り付くパターン:
実装フェーズまでUI設計担当者が張り付いて、仕様の構築から、グラフィックデザイナーとの調整、実装制約発生時の調整、細かいエラー表示決めに至るまでUIに関わることはすべて検討し、UI詳細仕様書を作成する。

このやり方も経験しましたが、やりきるには相当な工数がかかります。UI設計者の人数もそれなりに必要なので、プロジェクトによっては現実的でないかなと思います。

一方、これとは逆のパターンもあります。
※陥りやすいパターンがこちらと思います。

UIの要求仕様だけ出して終わりパターン:
要求仕様だけ出して満足し、実装フェーズに入ったら、制約事項のUI仕様もすべてエンジニアにお任せというパターン。

これは楽なようで実は問題が起きやすいやり方です。避けた方がよいです。

評価フェーズあたりでこの操作・表示変じゃない？といった品質問題発覚となり、呼び寄せられるUI設計者。
(お任せにしていた)動作の仕様調査から始める必要があり、かなり疲弊します。
手間もかかりモチベーションもあがらない作業なので…

よほどユーザビリティスキルがあるエンジニアが担当していたら別ですが、実装しながらユーザー視点に仕様を整えるのは不可能に近いと思います。

一見、計画時には工数負担が減るように思われますが、多大な手戻りが発生するので全体的には工数が増えるパターンです。ユーザビリティの配慮を専門家以外に丸投げするのは危険です。

では、どう制約をユーザビリティ観点で仕様化していくか？

折衷案風ではありますが、以下のやり方をおすすめします。
今もこちらのプロセスで運用しており、なかなかうまく回っています。

①UIの構想ができた段階で、詳細化する前に実装担当者にレビューしてもらう

明らかに実現困難か、そうでないかを見てもらうことで、全体の手戻りを減らせます。次に、

②必要に応じUI仕様を調整し、成果物として要件仕様を作成する
➡️要求はしっかり出す。要求は最後まで主軸になります。

それでもいざ作り始めると、実装できないケースや、この仕様はどうしたらよい？という相談事項が出てくるので、

③要求仕様を実装できないときや、追加の要件が発生したら、必ずUI設計者に相談してもらう

を徹底します。
相談内容に応じて要件仕様自体も更新します。

この方法も、それなりに手間がかかります。
でも、上の2つのやり方よりは効率良いです。
最低限のユーザビリティは担保したければ、③を抜かないことをおすすめします。

ここまでプロセスにも責任を持ってこそ、UXデザイナーと言えるのではないでしょうか。…と思っています。

……

プロセスができたら実際のUIをどう作って行くか？

制約の仕様化についてはケースバイケースなところであり、一言でこの方法という定義は難しいですが、考え方としては、

いかに、ユーザーにとっての「利用上」の制約にさせないか。

がポイントです。
ここで、わかりやすさのために、

システムの制約が、ユーザーの「利用上の制約」

になりがちな代表として、エラー表示と設定を例にあげます。

エラー処理は、UIに染み出てくるのが主にメッセージ表示であることと、内容がシステム寄りなので、UI設計の範疇ではないと思われがちです。

エラーが起きないよう実装してもらうことは必要ですが、システム上どうしても避けられない。
としたら、どう共存させるかをユーザビリティ観点で考える必要があります。

この場合は、

回避策を分かりやすく提示し、「一刻も早く」通常の利用状態に戻してあげる

方法を考えます。

避けたいのは、システムの仕組みをそのままメッセージにすること(本当にあります)。
ユーザーには何が何だか分からず、ますます制約事項にはまって利用上の妨害になるだけです。

システムの制約を少しでも負担に感じさせないために、起きている事象とその回避方法をユーザーの立場に立って提示する。
さらに、技術視点ではなく、一般的な世界の操作に翻訳して処理、説明することが重要です。

もし翻訳できない、つまり、ユーザーには理解できない専門的な技術要因の場合は、あえてその具体的な内容は提示しない方が良いです。

簡単なエラーメッセージに留めて、お問い合わせやコールセンター側に誘導し、その際に問題の切り分けと素早い解決ができるようエラーコードを出す、とするのが良いです。

次に、設定についてです。

設定は、UIのデザインパターンがある程度決まるので、そのパターンが確立されると、
(排他で選択するラジオボタンやプルダウン、複数選択するチェックボックスなど)
そのルールに則ればUIの構成自体は比較的誰でも作成できるかと思います。

デザインパターンはルール化できたとしても、中身の仕様は丸投げせず、次のようなことに注意して決める必要があります。

ありがちなのが、

システムの制約を押し込む先＝設定

とすること。
設定がカオス化するので、むやみに増やすのは避けたいです。

いくつもユーザーに手動設定を押し付けず、設定しなくても基本そのまま使えるようにする。
つまり、ユースケース上、最適な初期値を設定しておく、または、ある程度自動化する等の工夫をすると不満なく使えるものに仕上がると思います。

ただし、どうしても最初に設定をしないといけない場合もあると思います。その場合は、インストール時に初期設定として完了させ、普段の利用では不便に感じさせない、とするのも１つの方法です。

後から必要になった時にカスタマイズできるよう拡張性のために設定を設ける。

という思想で考えると良いと思います。

…

これらの実例からわかることとして、

システム制約をそのまま提示するのではなく、「利用上」の制約をできる限り感じさせないUI

を粘り強く提案していくことがポイントです。

最後は粘り強さ。

ユーザーの利便性をとことん追求していくことで、よりよいUIが見えてくるはずです。