2012年06月29日 09:54Fujii

UIを検討していて「違和感がある」という話になったときに

IMG_4783

違和感だけを理由に設計を変えないほうが良い

「いいんだけれど何か違和感がある」という話になることがあります。

デザインというものも他の様々なことと同じようにバランスをとることが重要なので、「違和感」をきっかけに問題を発見することは常日頃あります。

それを前提とした上であえて「違和感だけで設計を変えないほうが良い」というのは、違和感の解消のみが目的になってはいけないということです。

解決方法が積み上げ式になることが多い

違和感の理由をまず探る必要があります。しかし、常日頃デザイン検討の中で違和感をきっかけとした問題発見は行っており、その際になぜ違和感を感じるのか?は探ったうえで進めていっているはずです。

なので、「違和感がある」止りになってしまうということは、「なぜ違和感があるのかわからないが」ということがセットででてくることが多いです。

この状態で、問題を解決しようとすると足し算的に説明を加えたり、割り切っていた部分を妥協することになります。

時々、あれ?これなんであるんだろう?みたいな要素はこういった時に生まれているのだろうと思います。

また、あまり問題が明確になっていないけれど「違和感」の解消だけのために作られる要素なのですが、プロジェクトによっては一度UI上に配置されると取り除くことが困難なこともあります。

世の中に違和感はつきもの

街の中に表通りと裏通りがあるように、道を一本はさめば怪しげな猥雑な雰囲気の世界が広がっていることはあります。

こういった境界線をまたぐときに人間は意外と敏感に反応します。

なので、違和感をきっかけにするのはいいのですが、本来境界線というのはいたるところにあるもので、その違和感も多くのもののひとつであるのです。

なので、違和感だけを気にするのではなく、どのような問題であるかを考えながらUIを作ることが必要になってきます。

2012年06月21日 09:37Fujii

シナリオが作れてもUIを作れるわけではない

IMG_4686

シナリオが作れてもUIがつくれるわけではない

シナリオ作ることができても、その人がUIを作るとボロボロであることがある。

シナリオが作れてもUIを作れるわけではない。

ある1人のユーザーのシナリオがあったとしても、UIがそれによって決まるということがないからだ。

使う人の個別のシナリオが線形であるからとかそういう話以前にものを作るということはそういうことなのだ。

ある一人の人のこのシーンのこの行動にあわせてものを作るというお題があったとしても作るものは人によって変わる。

映画などのようなものでも、ある一人の人のために作っても作る人によって出来上がるものはことなるだろう。

様々な行動をとるのはユーザーだけではない

つまり、当たり前のことだが、人間は様々なことをするのである。

先日の台風でも、傘を使う人、レインコートを使う人、家からでない人、などなど人間は様々な行動をとる。

ユーザーが様々な行動をとるのと同じように作り手も様々な行動をとり、それによって出来上がるものは異なる。

「シナリオからUIが作れるわけではない」というのは、例えば材料がありそれを機械に流し込むような作業で作るものではないという意味で、作り手自身が「決める」フェーズが必ず何度も出てくるものなのだ。

なので、自分自身で決めたくないため、決めた理由をすべて説明しようとするためにシナリオという方法に執着してもうまくいかない。

2012年06月14日 09:56Fujii

UIの複雑さを軽減する

IMG_4643

隠すか死ぬか

UIで表現できる数というのはある程度限定される。

単純にレイアウトできるスペースの量によって限界に達するときもあり、それとは別に人間が一度に把握できる量によっても限界に達するときもある。

前者は、限界を超えてなお要素を増やそうとすると、各要素の大きさを小さくする方向に向かう。

後者は複雑になっていることに対して敏感にならない限り限界を超えてなおとまらないことが多いかもしれない。すでに話題にしたが、「ユーザーのために」、「体験のために」などのスローガンのもとてっとりばやい責任回避の方法として、積み上げ式に要素を増加させてしまうこともある。

なので言葉にするぐらい複雑にならなければテーマとして扱われないこともあるだろう。「どうしてこうなった?」と。

どちらのUIも行き着く先は死である。

もちろんUIの話なので再度手術をして生き返ることもある。

隠す手術

手術のひとつの方法としては、優先順位をつけ「隠す」ことである。

最初の絵のように水面の上と下に世界が広がっていても、たいていは水面の上のものしかフォーカスされない。

それと同じようにまず分けてしまうことで、余計なものにフォーカスしないようにできる。

もちろん水面の下へつながる階段のようになんらかの入り口は必要にはなる。

たいていのプロジェクトでは要素は増える傾向にあるので、最初は必要最低限の要素のみに絞る。

多機能は複雑になりやすいが、一部の機能以外は隠してしまえば軽減されることもある。

機能をどこでひとつとするかにもよるが、例えば連携先のリストをすべて最初から出すのではなく、まとめて裏に隠すことなどができる。

もちろん大前提として何を隠すか優先順位をつけることができなければいけない。

責任回避のために積み上げられた要素であると、ここがなかなかうまくいかないこともある。

隠すことで誰かに責任が発生するようなチームだと難しい。