2012年03月30日 15:07Fujii

UI設計は「あってもいい」と「なくてもいい」の戦い

IMG_3033

UI設計は「あってもいい」と「なくてもいい」の戦い

よく、こんな機能があるといいねという話がでます。アイデアはいいのですが、実際にUIに落とし込んだものが完成系ですので、最終的にどうレイアウトされるかが重要で、本来レイアウトを含めたもの自体がUIデザインにおけるアイデアと言えるかもしれません。

そこを考慮しないと「あってもいい」ということで、強引に要素が詰め込まれることになります。

実際には「あってもいい」は「なくてもいい」なので、UIを複雑にさせる困ったものです。

「あってもいい」は、多くの場合、例外的な機能である

「あってもいい」というのは、大抵、 ちょっとしたまれなコンテキストに対するアイデアだったりしますので、例外的なことが多いです。

また、例外的なアイデアこそ、ユーザーにここまで細かく配慮したということと同じだと思ってしまうこともあります。なので、よくアイデア自体では盛り上がります。「ここだけこうする」に人間は弱いのです。

思ってる以上にUIを複雑にする「てもいい」程度の優先度の低さ

しかしこの「あってもいい」は危険でもあります。その危険性の原因はまさに軽さです。

「てもいい」程度のことなので、本気で取り組もうとは決してならないからです。

本気で取り組まないけど、なにか入れなきゃいけない存在。非常にデンジャラスです。

UIの構造を変えるまでの話にならず余計こじらせる

デンジャラスなのはなぜか?それは、「本気で取り組まない」けど「イレギュラーな要素」であるからです。つまり、UIの構造を考え直してまで追加する気はさらさらない。

それが大きいため、UIの中で収まることがありません。

もちろん奥のほうにひっそり置くのであればいいですが、以外と「ユーザーにここまで配慮している」と思ってしまっているアイデアなので、「せっかくなので表に出そう」となります。

なので、まとめると「あってもいい」というのは「本気じゃないけど、イレギュラーな存在、なおかつ表にでてこようとする」要素なので、注意して扱わなければならないと思いました。極論すれば奥にいれるか、「なくてもいい」扱いにするか、表に出すなら本気で取り組むかです。

IMG_3893

UIの複雑さを売りにしないのならば

IMG_3029

複雑なことを売りにしないのであれば一度に見せるものは少ない方が良い。

店内に所狭しと物を積み重ねている安売り量販店のように、あえてものを見つけられないようにして探検させるというコンセプトでない限り、 一度に見せるものは少ないほうがよい。

写真一枚のように、情報の種類が少ない(撮影日などではなく純粋にサムネイルという情報のみの場合)のであれば多く並べても良いかもしれない。

それでも一度に見せる量は限られている。

印象的なプレゼンのように。

ひとつの画像、少ない言葉の組み合わせのほうが見ている人はフォーカスしやすい。

それは印象的なプレゼンと同じように。

この記事でも3つの表現がある

1イメージとショートテキストのもの、1ページのマンガ、そして今書いている文章。

1番フォーカスしやすいのは、1番最初のもので、次がマンガで最後が文章だ。

詳細に知りたい人でなければ文章は読まない。

IMG_3880

UIの要素を適切に管理するのは難しい

IMG_3027

要素は簡単に増える

「便利だから」と要素を増やすのは簡単です。

ここにこんな機能が欲しい、これを表現しなければいけないなどなどきっかけは様々。

適切に管理するのは難しい。

適切に管理するためにはひとつの要素でも条件分岐が必要になります。

こういった意味合いでここに、配置するといったことです。

そのほか、これと似ているから、これと似た用い方をするなどもあります。

まず作り手が混乱する

その条件が複雑になると作り手は混乱しやすく、管理不能になります。

いくら使いやすい、わかりやすいを求めても場当たり的に要素を配置することの悪いところは管理不能なUIを生むことです。

もちろん場当たり的なので、管理不能以前に一貫性もなくなってくることにもつながります。

作りてが管理不能になってしまっているようなUIは、それを使うユーザーにも良い影響を与えることはありません。

IMG_3862

2012年03月29日 09:51Fujii

基本的にレビュー回数と機能の要望は比例する

IMG_2978

基本的に多くの回数と多くの人にレビューをすると、機能の要望は増加する。

前回描いたように複雑になるかどうかを考慮したレビューが少ないということは、レビュー回数が増えれば増えるほど、機能に対する要望は増えます。

「何か余分なものはないか?」という視点でレビューする人は少ない

ユーザーが複雑さにフォーカスするときは複雑になった時だけです。

機能追加をして複雑になった時などですが、それ以外では今ある機能に余分なものがないか?余分なものをとってしまったらよりよくなるのではないか?とは考えません。

なのでそういったレビューも少ない傾向があるようです。

IMG_3841

チームによってはナイーブにユーザーの声を指針にするため、社内レビュー時には注意が必要になってくるでしょう。特にたくさん意見を聞いた以上反映させないとマズイと考えると、UIは必ず複雑になっていきます。

2012年03月28日 23:23Fujii

ユーザーレビューの要望は取捨選択する必要がある

IMG_2974

「こういう機能が欲しい」というレビューは開発に影響を与える

開発者以外の人のレビューはどれだけ開発に影響を与えるのか?を考えてみます。

開発チームの思想に左右されますが、開発に影響を与えるケースがいくつか挙げられます。

まず、前にも描きましたが「ユーザーの意見」を重視するチームは影響をうけるでしょう。

手詰まりでノーアイデアなチームも影響をうける可能性が高いです。

アイデアは多くても、意思決定ができないチームもユーザーの意見によって決定しようとして、影響をうけることがあります。

「複雑になるなら不要」とレビューするほうが難しい。

様々な要因で影響をチームに与える可能性がある「ユーザーのレビュー」ですが、どのように生まれてくるのか考える必要があります。

何かのレビューをしてくれというときに、多かれ少なかれ人は問題を探そうとします。

IMG_3825

スムーズにいかなかった、できなかった、よくわからなかったなどの問題がすぐに思いつくでしょう。

場合によっては、ショートカットボタンや、わからなかったことに対して説明文があれば良いなどと考えます。

結果的にレビューをする立場としては、うまくできたと思うことでしょう。

しかし、特定の状況に依存した問題をあげることが多く、全体の複雑さやバランスというのは考慮されません。

なにか機能が欲しいというのは簡単ですが、複雑になるなら不要とレビューするのは難しいことなのです。

「複雑になった」や「UIがシンプルでわかりやすい」はありますが、将来のことに対して、「複雑になるならば不要」というレビューはなかなか目にしません。

要望は見てみたいと同じレベルであることが多い

複雑になるなら不要というレビューが少なく、要望が多いですが、この要望は複雑になるかどうかが考慮されていないため、実際に実装しても、当のユーザー自身さえ複雑さを嫌って使わないことも考えられます。

つまり、要望は「見てみたい」と同じレベルの話であることを頭においておく必要があります。

取捨選択が必要

最初に書いたようなチームは特に影響を受けやすいですが、見てみたいと同じレベルである要望は取捨選択が必要になります。

それは、レビューにあがりにくい「複雑になるかどうか」ということと常に天秤にかけながら判断するほうが良いと思いました。

UIの要素が多くなるのは、一度に多くのことを話すのと同じで結局伝わらない

IMG_2971

UIの要素が多くなるとは?

UI設計では要素が多くなりがちです。

特にすでにあるものに対して、何か機能追加をする際には、要素も追加されがちです。

どんなに言いたいことであっても

その機能がどんなに大事でも、一度に多くのことは伝えられません。

そういったフェーズにおけるアイデアとは、見せ方ではなく、ボタンを減らして、明示するのをやめて、そのかわりに新しいものを置くという決定を下すこと以外にありません。

大事なことほど、一度に多く言わないほうがよいのと同じなのかもしれません

IMG_3802

2012年03月27日 20:35Fujii

ユーザーがUIを理解するとはどういうことか?

IMG_2966

UIを理解できるかどうかに関係するユーザーの特性

ユーザーがUIを理解するというのはどういうことなのでしょうか?

というのも、ユーザビリティテストなどでこういうことがあります。

新しいもの好きのユーザー、無頓着なユーザー

あるユーザーは新しいもの好きで、新しいデバイスを利用しています。それなりに、使っているので、デバイスの基本的な操作もできます。

対象のシステムもそれなりに理解することもできました。

さて、今度は別のユーザーがいます。

こちらは、特に最新のデバイスを使用しているわけでもなく、至って普通か無頓着なので少し古いデバイスを使っています。

ところが、このユーザーは、対象とするシステムに対して、平均程度には戸惑いますが、すぐにできてしまいました。

結果としては必ずしも新しいデバイスが好きであったり、常日頃触れているユーザーの方が、無頓着で古いデバイスを使いつづけるユーザーよりもできるということはなかったのでした。

できるとは?

この場合の「できる」とはどういうことか?

それは、「UIの構造を理解する」ことです。

また、同時に「サービスの概念や仕組みも理解する」こともあります。

話を戻すと、この「UIの構造やサービスの概念や仕組みを理解する」ことと、新しいデバイスに慣れているかどうかは関係がないのかもしれません。

モデル化し、パターンを見つける能力

例えばどこか新しい場所にきたときに、歩くたびに、頭のなかに道を描き、道と道の似ているところ、向かう方向、交差の具合を組み立てる人がいます。

別の人は、新しい場所にくるのは好きでも、特に頭の中に道は描かず、思いのままに手当り次第に道を曲がるかもしれません。

こういったことがあるように、UIや新しいサービスの概念や仕組みに対しても、どのように受けとめるかはユーザーによってもわかれるのかもしれません。

UIやサービスの概念や仕組みを素早く理解することができるかに関係しているのは、実は新しいデバイスに慣れているかよりもそうした受けとめ方の違い、広い意味でUIを記号として認識し、その意味を常に変換しながら操作していくかどうかのほうが、大きいのではないかと思いました。

2012年03月26日 20:24Fujii

「ユーザーのために」がUIを複雑にする時がある

IMG_2960

複雑なUIはなぜ生まれるのか?

以前から思っていたことですが、UIを設計する際に、「ユーザーのために」と思っているメンバーが集まっているにも関わらず、かえってUIの要素が増えることがよくあります。

一体なぜ、ユーザーのためにと思っている人が集まってもそういったことが起きてしまうのか不思議でした。不思議であるとともに、とても皮肉なことだと思いました。メンバーの思いがあるにも関わらず、最終的には要素が多く複雑なUIができてしまうからです。

そんなわけで、その理由を少し考えてみました。

「使いやすくしよう」が原因のひとつ

考えてみると、やはりUIが複雑になる原因のひとつが「使いやすくしよう」です。

ある不便なところをひとつ見つけたときに、「ユーザーのために」なにか対策を行おうとします。

ショートカットボタンの落とし穴

よくあるのはステップを短縮するショートカットのボタンをおくことです。

例えば、何かをする際に2回クリックしなければいけない場合に、1回のクリックでできるようにしようということです。そうすればユーザーは便利だろう、使いやすいだろうというわけです。

このときに、ユーザーに 意見を聞いてみようとする人もいます。「こんなことが今できないと思いますが、ボタンがあったら使いますか?」と。このときに、ユーザーが「使います」と言った場合に、チームプロジェクトとしては、想像以上に大きなインパクトを与えるときがあります。聞き方にもよりますが、ユーザーは実際に使うかに関わらず使うかもしれないと思い、「使います」ということもあるでしょう。

プロジェクトにあたえるインパクト

特に「ユーザーのために」という思いで集まっているメンバーであるほど、ユーザーの意見を大きく受け止めてしまいます。

また、仮に意見でなくユーザビリティテストのようなものでも、タスクに直結したショートカットボタンが目に入れば多くのユーザーが使用します。

ユーザビリティテストに至ってはさらに大きなインパクトを与える可能性があります。

結果的に、UIの要素が多くなり複雑なUIが出来上がってしまう現象が起きてしまいます。

2012年03月25日 15:17Fujii

ユーザーにとって意味のある表現にする

image-20120325151659.png

以前に、全体を見て強弱をつけないとどれも目立たないという記事で駅の発券機を取り上げました。実際の生活のなかにも気づきのきっかけはほかにも潜んでいます。

富士急ハイランドへ行くためにバスチケットの予約するときに

昨日、富士急ハイランドへ行きたいな〜とおもいました。お酒も飲みたいので、バスか何かでいけたらいいなと思い調べてみることにしました。基本は電話予約で番号をもらいコンビニ発券のようですが、あいにく、夜中で時間外でした。ありゃまこりゃま残念、、とおもいましたが、少ない人数であれば、発車オーライネットというところでネットから番号をもらうことはできそうでしたので、ふむふむ、これは便利だと思ってやってみることにしました。

まず利用するためには会員登録が必要らしく、せっせと入力をしました。次に認証のメールが届いたりしまして、再度メールアドレスを入力して、認証が完了しました。

このサービスは複数の会社のサービスなのでせっせとバス会社を探し、せっせと目的の路線を探しました。そして、せっせと出発日時を入れてポチッと空席照会をしてみました。

物語の結末は突然やってくると何処かで聞いたことがありますが、こんな画面がでてきたのでした。

error message

何となくわかるような、よく考えるとわからないような、なにか試されてるような、言葉にしない部分をおしはかってくれとコンピュータに言われているような、そうか、、そうか、言葉にできない部分ね、、まかせとけ、、っていやいや、今この深夜になんでそんなことをしにゃいかんのだ、君!、、、といったことが頭を駆け巡り、不思議な空気がiPhoneと僕の間に流れました。

最終的には画面の様子から先に進めないことは理解しましたが、つまりどうすれば良いのかはよくわからずじまいでした。見れば見るほどじわじわくるメッセージではありましたが、これは一晩あたまを休めて明日電話越しに人間に話したほうが良さそうだと決めて床についたのでした。

どうしてこうなった?

なぜこうなってしまったのか?

おそらくこうだったのではないかと思います。ある一定の時間、期間しか受付ができないシステムであり、作った人は、その時間に当たってしまった場合には、そのことをそのままユーザーに表現しようと考えたのだと思います。それ以上でもそれ以下でもない正確なシステムの現状をそのまま表現することがユーザーにとっても良いだろうと考えたのかもしれません。

ユーザーにとって意味のある表現にする

エラーの起こるシステムの仕組みを想像するのには役に立ちましたが、この時は残念ながらそれ以上のことがわかりませんでした。

どちらかというと、システムのモデルよりも、予約するためのモデルに関して知りたかったので、メッセージはあまり意味がありませんでした。

細かい仕組みを知らせるのがユーザーにとって良いのか?

システムの仕組みを正確にユーザーに伝えようとすると、システムそのものをそのまま理解しなければいけなくなります。ですので、どこかでシステムの仕組みをユーザーがわかるようなレベルまで置き換えなくてはいけなくなります。

例えば、予約するための仕組みというモデルにして、時間外ではシステムを利用できないことをユーザーに事前に知らせるなどです。ユーザーにとって、エラー条件のモデルよりも、予約するための仕組みとして、そのシステムを選択肢にしてよいのかどうかのほうが大事で、理解しやすいはずです。

悩ましいのは、新しい概念、複数の場所の概念、複数の権限、ステータスの要素が混ざっているときなどはユーザーにとっての意味を考えて下手に丸めてしまうと破綻する場合もあります。その際は、理解が難しくても、構造をそのまま出したほうが最終的にはなんとかおさまりがつくでしょう。

ただそのときも、可能な限りユーザーにとって、重要な部分をシンプルな概念にまとめることが大事になるとおもいます。

とはいえ、今回の場合は何か複雑な概念を表現するためにわざとしている説明ではなく、システムの状況を単に表現したのだろうと予測されます。

説明のメッセージの文言も大事ですが、その大元のユーザーにどういったモデルで表現するかが大事になりそうです。メッセージの問題と考えると、ユーザーにとっては学習可能なことも毎回メッセージで知らせるなど、どんどんややこしくなってしまうこともあり、別の問題(メッセージが多く、煩わしい)を作ってしまうかもしれません。

どこまでわかってもらって、どこまで丸めるか、またそのことをどのようにユーザーに学習してもらうか?というのは大事だとおもいました。

このサイト内の関連記事: