# UXを損なわないUIについて個人的に気をつけていること
## 仕様外のUXの改善は開発サイドが攻めなければ放置される

大枠としてのUXは画面上の表現に留まらずビジネスデザインと直結するものであるため、UIがUXの全てであるという認識は完全に間違っていますが、一方で目的のUXを極力妨げないようにUIを詰める作業に関しては両者は狭い問題領域で密結合しています。

特にデザインとコーディングが分業している場合、そうした細部の詰めを全て仕様として言語化するのは無理があります。ここで開発サイドが主体的に働きかけずに仕様を満たす事だけに専念してしまうと、結果そこが空白地帯になってしまい、全体としては雑な印象の残念なプロダクトになってしまいかねません。

というわけで、とりあえずここの辺りの一種の職人的な領域について、個人的に気をつけていることをメモっておきます。全体的にモバイルアプリ／ハイブリッドWeb寄りで、多くは既に言われていることの焼き直しかもしれませんが、自分の言葉でも書いてみます。

基本的な方針は3つです。

* 釘を打つ
* ヤスリをかける
* ニスを塗る

## 釘を打つ

### 部品の位置に一貫性を持たせる

 * 同じ恰好の要素があちこちから現れたりずれたりすると、雑で分かりにくい印象を与えます。

同じ形をしている部品が遷移毎に異なる位置に登場するというのは避けるべきです。
HUDやガイドなんかが典型的で、相対位置だけではなく、絶対位置も一貫させます。
レイアウトのサイズに関しては変にグリッド化したりして完璧さを求める必要は無いと思いますが、
一度決めた位置に関しては1ピクセルも妥協しないようにします。

### 戻ってきた時は同じ場所に戻す

 * 戻ってきた後に様子が変わっていると、面倒な印象を与えます。

戻るボタンなどで画面遷移する際は、ユーザーが操作した状態を保持し、表示物の画面位置が完全に一貫するようにします。
そうしない場合は繰り返し同じ操作をさせてしまう事に繋がります。
これはアプリやブラウザを終了して戻ってくる時も同様です。
もしもそれがサービス的に無理である場合は、十分に説得力がある遷移を設けます。

### 触られたら勝手に動かさない

 * 触った後にも勝手に動くものは、制御不能な印象を与えます。

特にバナーなどでよくありますが、普段自動的に状態を切り替えるものをユーザーが触れるようにした場合、触った時点で制御を渡すようにします。
動いているものを触るということ対して、何が期待されているかを予測（出来れば計測）し、地に足の着いた反応を返すようにします。

## ヤスリをかける

### 原則全ての表示制御にトランジションを付ける

 * 表示物が唐突に点いたり消えたりすると、雑な印象を与えます。

自然界には16ミリ秒で突然消滅したり姿を変えるものは存在しません。
部品を片付ける際や画面を切り替える際には即座に切り替えずに、極端な話例え2フレームであってもフェードや移動アニメーションを付けます。
演出を見せるのが目的ではないので、この目的で使用するアニメーションはごく短く、自然な表現のものにします。
即座に切り替えたり、遅くしたり、沢山のアニメーションを見せる場合は結果として表示非表示に主張を持たせる事になるので、それらは強い理由付けの元に行います。

### 表示物のバリやノイズを取る

 * あからさまに接合部が見えていたり、ノイズが乗っていたりするパーツは、汚い印象を与えます。

制作物として納品されたものをテクスチャ化したり、リサイズや切り貼りしたりといった過程で、最終的に目に見えるものにゴミが付かないようにします。
例え1ピクセルのゴミであっても、見えている限り無意識に汚い印象を植え付ける効果があります。
また、昨今はRetinaや4K等の高解像度に対応しつつ、コンテンツのデータ量も削減しなければならないといった矛盾を解決しなければならない状況があります。
その過程で、スケーリングによるジャギー、エンコードによるモアレ、減色による色調の崩れなどが見落とされないように注意します。
特に開発フレームワークのシミュレータだけで確認していると、実機でしか発生しないこうした問題に気付かず、対策が遅れるということがよくあります。
この問題については確実に開発サイドが主導権を握る必要が有ります。

### 無駄な通信を根絶する

 * 直感的に通信が不要と思われる画面でローディングが発生すると、超もっさりした印象を与えます。

これはUIに現れる影響から比較して実装工数が割に合わないと過小評価されがちですが、やります。
モバイルの時代では通信量よりも遥に通信回数の方が重要です。
例え10ミリ秒で通信が終了したとしても、ローディング画面を出す限りもっさりした印象は拭う事が出来ません。
また、これを回避するためにローディングしている事実を隠す事は、逆に不安定な遅延を印象付けることに繋がり、より悪い結果をもたらします。
通信が許されるタイミングでクライアントに情報を最大限落とし、キャッシュとローカルストレージを駆使して状態変更が発生するギリギリのタイミングまで通信を遅らせます。
理想は、ユーザーが意識的に情報を操作したと自覚するタイミングでのみロードを発生させること、から一歩先にあります。
過度な複雑化は避けるべきですが、通信インターフェースは自動生成に非常に向いている領域なので、プログラマの腕の見せ所だと思います。

## ニスを塗る

### フレームの隙間を空けない

 * 一瞬でも真っ白や真っ黒な画面が入ると、アマチュアっぽい印象を与えます。

これは主に描画エンジンを使いこなせていない証拠ですが、シーンの切り替えなどのスクリプティングの境目で一瞬全景が消えて背景が見切れる事があります。
通信で次の画面を呼ぶような場合も典型的です。
多くの場合は単に実装上のミスであるため、こうしたケースは全力で阻止します。また、物理的にそうした状況が回避出来ない場合は、道具が間違っているので捨てます。
特に開発用の高速LAN環境や最新端末だけでテストしていると、性能的な問題で生じるケースを見落とす事があるので、最低性能のセットアップで注意深く観察します。

### 画面をチラつかせない

 * 画面がチラチラ・ピカピカすると、目が疲れて嫌になってしまいます。

明るい事務所の中で常に端末を見続けてテストしていると、演出の際に過剰な輝度変化が起きている事を見落としてしまったり、常に見続けて慣れてしまったりという事があります。
普通のユーザーはずっと画面を見ているわけでは無いですし、少し暗い風呂場や寝室で画面を見ている可能性があります。
過剰なエフェクトや画面の配色変化で視覚を攻撃するのは避けるように、輝度の調整と一貫性に注意します。

### 手触りを良くする

 * 思ったように値が調節できないバーやボタンは、イライラします。

モバイルでは基本的に画面をタップして操作することになります。
時々忘れがちになりますが、画面をタップした指の正確な位置を検出するという技術はもの凄いイノベーションであって、まだまだうまくいかないケースがあります。
例えばスライダーはドラッグにより操作しますが、値を決めた後に位置をずらさないように瞬間的に指を離すというのはかなり難しいものです。
こうした場合は静止時間から判定してスナップするなどの配慮をします。
マルチタップでは、タッチ検出デバイスや画面の劣化で複数タップがシングルタップやドラッグに変換されたりするという事がよくあります。
通常これらは意図しない結果を引き起こしますが、デバイス自体はどうしようもないので、なんとかソフト的に解決する必要があります。
また、ボタンの大きさについても、開発画面では拡大されていたりするのでサイズ感を忘れがちになります。
慣れているから押せるボタンでも、初見の人に触らせるとなかなか押せないということがよくあります。
このような場合は見た目よりも判定領域を大きくしたり、典型的な操作パターンに応じて判定領域サイズを変更するなどで対応します。

## まとめ

とりあえず思いついただけでしたが、これ以外にも気をつけなければいけないことは沢山あると思います。こうしたことを全て言語化して仕様に落とし込もうとするととんでもない事になるので、誰かに指示されるまでもなく、自分自身やまわりの人に触らせて鬱陶しいと感じた挙動を執念深く取り除き、問題を透明化してしまうことが肝要です。
また、製品に愛着があり、適切な裁量が与えられていれば、殊更に言わずとも自然とそうなるものでもあると思います。一番楽なのは、デザインも含めて全体の問題領域をカバーすることです。まだまだこの業界は分業するには未熟と言えます。