この記事はUI Design Advent Calendar 2015の19日目の記事となります。
はじめに
「UIは流行りのイケてる感じで」
よく、プログラマ/エンジニアからUIへのオーダーに使われる文句の一つです.
プログラマは比較的,ロジカルに物事を考え結論を出すことが要求される職業の一つだと思っていますが,
なぜUIに話が及ぶと突然 曖昧で, 感覚的な 結論に考えが至るのでしょうか.
システムとインターフェースは切っても切り離せないものです.
UIはシステムを扱うのと同じくらい最初から注意して扱われるべきです.
本記事では, プログラマがいかにUIと付き合っていくべきなのだろうか？ということを考えていきたいと思います.
あくまでこれから書くことは私が知る情報・経験をまとめたものであって絶対ではないと考えています.
意見・反論がいただければ非常に嬉しいです(きょうちょう.)
なお, 以下の本を読んでいる場合, 本記事を読む必要はありません.
私
前提として私が何者なのかを書いておきます。
Webデザイン2年/プログラマ2年という非常に中途半端な経歴の持ち主です.
なのでプログラマ目線と言いつつ一部デザイナ目線も入ることをご了承ください.
インターフェースとは
そもそもインターフェースとはあるものとあるものの境界を表す言葉です.
我々が使うUI(=ユーザ・インターフェース)とはシステムとユーザの境界を指し示すことになります.
ボタンや表, グラフなどの要素よりも本来はもっと広い概念です.
インターフェースを消す
究極的にはヒトとシステムのインターフェースを限りなく0に近づけることができれば理想的でしょう.
あるシステムから出力された情報をあるシステムへインポートするようなUIがあったとします。
インポートはCSVかもしれません、CSVにはある種のデータへの改変が必要かもしれません。
このようなケースではインポートにかかる手順を全て自動化すれば良いです。これは間に入る
余計なインタフェースを減らすことに他なりません.
ユーザがここで接するインタフェースは一番ユーザのしたいことに
近いものを表示・操作するものの一つです.
ここでインターフェースを消すための技術はエンジニアが一番持っているものです.
デザイナにはその判断・実装は難しいと思います.
関連してNo UIというキーワードを最近見かけるようになりました.
インターフェースを調節する
もう一つ例を挙げます。
これもシステムへデータを入力する際の話です.
入稿されたエクセル原稿から1件１件登録画面を通してデータ入力していく
画面の改善を任されたことがありました.
どんなUIコンポーネントを使ってユーザの負荷を減らせるかななんて最初は
思っていましたが, 最終的にはエクセルからシンプルなCSVを起こして
一括インポート処理することになりました.
新たに高度なUIをWeb上に用意するのではなく, 編集は使い慣れたエクセルに任せてしまうという発想です.
編集するための目に見えるUIはシステム上から消えました.
一つレイヤを削ることにより, システムのコアに近い部分にインタフェースを寄せた形になります.
この変更により実際の作業時間も大幅削減することができました。
これらの例はプログラマの皆さんならよくあることで取り立てた内容ではないと思いますが,
視覚的に具現化されないインタフェース を構築した例になります.
既に出来上がったシステムの中で
保守開発では出来上がったUIに手を入れる機会が多くあります.
これはとても辛い作業です.
- システム構築当時のUIと現在のUIにおける潮流がかけ離れてしまっている
- ユーザは既に学習してしまった
二つの相反する辛さがそこには存在します.
変えなくてはいけないのに, 変えてはいけません.
このジレンマに関しては以下の記事がとても参考になりますので, そちらを参照していただけたらと思います.
デザイン変更は抜本的にやるべきか、それとも、少しずつやるべきか
変える,ということについても分けて考える必要があります.
- スタイリングの変更
- フローの変更
- 統一
- 一般化すること
それぞれ見ていくこととします.
スタイリングの変更
雑に言うのなら イケてるUI にするということです.
世の中にはGoogleとAppleの(後Microsoft)デザインが溢れていますから,
ユーザの目は自然と肥えてきます.
スタイリングが良くないと目にも止めてもらえない可能性があります.
私はRedmineがとても苦手ですが, 見た目が気に入らないからです.
(どんなテーマへ変えようがダメです.)
スタイリングには使ってみよう, というモチベーションを湧かせる役目が一つあります.
ある程度複雑な操作を要求されるシステムで片方はイケてないデザイン, かたやイケてるデザイン,
それぞれを触るユーザの心情はどう動いて, 実作業にどう影響するかを想像してみてください.
もしかたら, 心理的バイアスがそのシステムを選択すること, 見ること, 操作することに
影響を及ぼしてしまっているかもしれません.
Boostrapがここまで受け入れられている理由の一つは,
最低限のスタイリングのハードルをクリアするためでは?とわたしは思っています.
ただ, この要素に注力しすぎることは避けなければいけないと思っています.
我々プログラマが力を注ぐべき領域でありません.
フローの変更
画面のボタンや色を変えることではなく, 画面ごとのつながりや機能自体
関連性を変えることです.
この変更ではユーザの作業フロー自体が変わりますので注意して行われるべきです.
一般的にフローは追加改修を加えれば加えるほど増加していく傾向にあります.
悪いことにこのフローの増加は既存機能を悪化させます.
なので, 常にフローを削れるチャンスを狙うべきです.
前述の通りフロー自体をなくせるのが一番だと思います.
統一
プログラマだけで作られたシステムにありがちなUIの問題に, 統一感がないということがあります.
ある画面では決定ボタンは右かつ赤, ある画面では左で緑というような
混沌としたシステムが出来上がってしまっています.
なぜこの問題が発生するかというと, 私たちは機能単位で構築を進めるからでしょう.
システムの全体を見通した上でインタフェースは考えられるべきです.
あるエリアの右端を見たら必ず追加ボタンがあるというような 明確なルール を
守ることでユーザの利便性は格段に向上します.
ある画面での体験がある画面でも応用できるようになるためです.
混沌としたシステムでは画面ごとにユーザは学習を繰り返さなければなりません.
(そしてユーザはそんなに暇ではありません)
ボタン一つ追加する, というだけでも全体のシステムに違和感なく溶け込むか
ということについて考えなければなりません.
CSSのスタイルガイド作成ははおそらく、このデザイン自体の統一も促進するでしょう.
一般化すること
我々プログラマはプログラマにしか通用しないような言葉・概念でインタフェースを考えがちです.
例えばあるデータをあるシステムへ取り込む際のメッセージを考えてみます.
- 「プロセスを開始します」
- 「データのインポートを開始します」
- 「データのシステムへの取り込みを開始します」
プロセスやインポートといったキーワードが果たしてユーザに理解されるでしょうか.
理解できないメッセージはユーザにとってさして意味を持ちません.
また言葉はシステム全体を通して統一されているでしょうか.
知識がある開発者にとってはある概念が複数の表現によって使われていても
無意識のうちに表現を共通化して理解します.
閉じられた世界でのみ許される多様性です.
一般的なユーザにとってそれ全て違うものに映るでしょう.
また, 私たちが使っているコンポーネントに頼りすぎていないでしょうか.
MacやWindowsの画面を隠した時ににゅっと縮んでいくようなアニメーションは
決しておしゃれではなく, システムの動作を概念として伝えるためのインタラクションです.
ユーザ目線に立って想像して考えてみることが大切です.
参考記事
本当に有意義なエラーメッセージを書くには
これらの変更がどれだけ同時に行われているか, 注意すべきだと思います.
一度に多くの変更を私たちは簡単に受け入れられるわけではありません.
特定の目的に絞って, 段階的に変更はしていったほうが良いと考えます.
反対に変更を加えることを怖がってもいけません.
ユーザは再び学習します.
CSS
スタイリングを行う上でCSSは欠かせません.
CSSに対して苦手意識を持つプログラマも多いと思います.
なぜなのでしょうか?
CSSも一つの言語で非常に仕様が複雑です.
勉強してください.
JavaやJavaScript, PHPなどといった言語と同様に良く書くには
良く勉強する必要があります, 片手間ではできません.
CSSは壊れやすく, 変更する際は他の言語以上に細心の注意と勇気が必要です.
Bootstrapのようなものを使うにしてもCSS自体を知らずに扱えるほど
高度に隠蔽化されたフレームワークはまだ存在しません.
Flat DesignやMaterial Designについて
- Flat Design
- Material Design
これらのデザインは 見た目 だけを目的として設計はされていません.
単純に一過性の流行りとしてこれらを捉えるのははっきりと間違いです.
(世の中にどう広まっていったか, はまた別の話です.)
これらはコンテンツ・デバイス(・言うなれば我々の生活)の変化をバックグラウンドに
合わせて提唱されたデザインであり,これだけ短期間で前提となるそれらが
劇的に変化していっていることを考えれば
デザイン潮流もすぐになくなる,または変化していくと考えるべきでしょう.
背景を考えずに見た目だけの模倣に走った場合, デザインを載せ替えるたびに
コロコロとユーザを混乱させるシステムが出来上がるだけです.
背景を見ればいつ変えるべきか?の問いにある程度答えることが
できるようになるのではないでしょうか.
デザイナーが考える過剰なデザイン?
よく批判の槍玉にあげられる,dribbbleなどで見かけるデザイナーによる行き過ぎたコンセプトデザイン
ですが, これはこれで必要でしょう.
先に述べたように,どの境界をターゲットにデザインをするか, ということもありますし,
現実の制約に縛られない自由な発想がやがて,実務的なデザインにFBされることも十分考えられます.
iOSにおけるUIも当時としてかなりオーバースペックなデザインではなかったのでしょうか.
見た目に惑わされてはいけませんし, 立ち止まってそのUIの意図を考えてから批判をするべきです.
コンテキストを考えずに表現のみに着目することは「行き過ぎた批判」に繋がるのではないでしょうか.
またそれらのデザインを参考にする我々が, 何の軸もなしに,闇雲な模倣に走ることは避けなければなりません.
最後に
ちなみにスタイリングという意味でのデザインは以下の本から学ぶことを強くお勧めします.
シャドウやテクスチャなどと言った小手先の要素ではなくもっとプリミティブな意味でのスタイリングが学べます.
書いてきたような考え方が, 無意識に私たちの作るインターフェースに反映されるようになるには, 考えて, 作って, 考え続けるしかありません.
答えも時代と環境によって変化をし続けます.
試行錯誤に終わりがありません.
私はこんなにもやりがいのある領域は他にないと思っています.