ATOCHOTTO

あとちょっと良いサイト

「足し算」か「引き算」か

同じ「ユーザーのわかりやすさ」を求めるチームでも、「足し算」を使うのか「引き算」を使うのかで全く出来上がるものが異なるので注意しなければならない。

ユーザーのわかりやすさを求めるという意味では共通点のある人々でも、異なる二つのタイプに分けることができる。

それは、「わかりやすさ」のために「足そうとする」足し算タイプと「減らそうとする」引き算タイプだ。

足し算タイプ

足し算タイプの特徴は、一見ロジカルである。つまり、「ここがわかりにくい」から「ここに説明を加えよう」といった思考をする。

「一見」という言い方になってしまうのは、要素が増えればごちゃごちゃするから、 そのままわかりやすくなるとは限らないという点まではロジカルにつながらないからである。

自分で気がついた「わかりにくい箇所」に対して、なにか責任のようなものを感じてしまい、そのまま放置することはできないと思う人なのかもしれない。

放置しないということを前提にしてしまいがちなので、解決策が思い浮かばないときには、「とりあえず説明をしておこう」となってしまう。

そうすればその箇所に関しては「責任を果たした」気分になれるからだ。

結果的には、責任回避のための注意書きだらけの取り扱い説明書のようになる。

引き算タイプ

引き算タイプの特徴は、複数の箇所を同時に認識する絵描きタイプだ。

ひとつの箇所が問題だと考えたときに、そこをすぐに手を付けるのではなく、一歩ひいてほかの箇所と比較しながら考える。

あるルールがあって、それから外れているからわかりにくいのか？、あるルール自体が崩れかけているのか？、一度に把握できる数を超えてしまいそうだからなのか？などなど。

もちろん実際にそのタイプの人が絵描きかどうかは関係ない。ある意味「要素を増やせば、把握するのが大変になるからやめておく」という考え方なのでロジカルとも言える。

こういったタイプは、常にではないにしろ、結果的にあるものを減らすことで複雑さを減らす方法もありえることを前提に考える。

タイプが異なれば、目標が同じでも全く異なるものができる

スペースや人が一度に把握できることに限りがある以上、「引き算タイプ」の視点がなければうまくいかない。

足し算タイプでは、際限無く要素が増えてしまい、結局その限界に達してしまうからだ。

つまり、同じ「わかりやすさ」を求めてもタイプ次第では異なるものができてしまうのである。

実際のプロジェクトの経験からは、メンバー内にどちらのタイプも混在することが多い。リーダーが引き算タイプでも、ほかのメンバーは足し算タイプであることもある。

また、同じ人でもそのときの立場や役割によっては無意識のうちに足し算タイプになることもある。（例えば詳細なレビューを頼まれた場合など。）

偏見ではあるが、文章による説明が好きな人は足し算タイプが多いのかもしれない。もしくは、業務上、文章によることこまかな表現や説明を常日頃求められる人、プレゼンよりも論文など文書を作らなければ評価されないような人はついついより多くの説明を一度にしたくなるくせがあるのかもしれない。

UIの細部のさじ加減は「許容」がないと進まない。

UI設計の中で「許容範囲です。」という表現で説明することがある。もしくは「Aという点を許容することでBということになる」という表現を選択することもある。

複数のやりとりの経験からそういう言葉を選択するようになったのだが、どういうことなのか？

大きな理由は単純に、UI設計というプロジェクトを前進させることにつなげるためだ。

ダメな部分を認識しつつさらに複雑になることを回避する

「許容する」というのは、主にデメリットに対して使う。

デメリットを認識しつつ別の良い点があることを伝えたい時に使う。

別の言い方をすると、そのデメリットを受け入れなければ、いい点も無くなるということで、いい点が無くなるということは別の問題が発生するということだ。

別の問題と比べてみると、そのデメリットはむしろ許容してもよいということ。

そういった取捨選択をすることをつたえるために「許容する」という表現を使うことがある。

ユーザーが気にしない範囲の「わかりやすさ」のために場当たり的に「工夫」した結果、複雑になるならやらない方がよい

例えば、ユーザーが気にもしないようなことに焦点があたり進行が滞ることがある。

今までにも書いてきたが、例えばレビューを行うときは、躍起になってダメなところをあげようとする。

それらを許容するかしないかという視点で判断しないと、進まない。時間があったら良いというわけでもない。なぜなら、そういった問題というのは、細分化しようと思えばいくらでもできるからだ。

そういった問題は、さらに場当たり的な対処になることも多い。

例えば二階建ての家は家の中に階段がある。

二階をよく使うから、すぐに使えるようにしたら便利なのではないか？と考えるかもしれない。

玄関のそばにかけるのはそこが一番目立つからでユーザーにとっても良いだろうと。

こういった場合入り口が複数になり複雑になることと引き換えに実現することになる。

それを場当たり的に繰り返すと梯子だらけの家が誕生する。

梯子がある部屋とない部屋が混在することで混乱することもあるだろう。

これはUI設計でも少ないクリックでやるほうがよいということや、コンテキストを考慮したいということだけにとりつかれると起こりがち。レアなコンテキストに依存しすぎたタスクごとに改善をやろうとするのでそうなることが多い。

現実にはタスクは無数にあるからこういった改善は入り口のメニューを増やすことが多くなってしまい、あまりうまくいかない。

ゴールデンウィークですね。過ごしやすい気温のせいでしょうか、テレビを消して少し窓を開けて、黙々と絵を描く時間というのもなかなか楽しいです。

あったかくなったのでさっそく大好きなソーメンを食べました。

そして、うどんも食べました。ズルズル。

ヨーグルトをガブ飲みしたらお腹がちょっとゆるくなりました。

大型連休のかたは引き続き事故などに気をつけて休暇をお楽しみください。

いいとこ取りをしようとしても大抵良い答えは出ない

UI設計においても時間配分というものがあ る。

答えの無い問いかけをしたときに、その答えを急いで求めようとすると時間配分に失敗することもある。

答えのない問いとは、「いいとこ取り」だ。複数のやり方がある場合にそれぞれに良いところと悪いところがある。悪いところがあるからいいところがあるということを考えずに、その良いところだけを集めようとしても、答えはないようだ。

デメリットを許容することでメリットを得て時間を無駄にしないことも大事

いいとこ取りを目指すよりも、デメリットも踏まえてメリットを得るほうが進む。

メリット、デメリットで複数のやり方を比べるとなっている時点で案はできっていることが多い。

ほとんどの場合、解決策があるならばすでに出ている。

このフェーズでなお良いところだけをとろうとすると時間を無駄にする。

いいとこ取りをするならば、根本から考えるか、地道にそこ以外の部分も含めて取捨選択を重ねるかしかなく、それは急いだところで答えがでるようなものでもない。どちらかというと答えを考えること、つくることに近い。

そういう意味でいいとこ取りという問いに短期で答えを見つけようとすると、結局元の場所に戻ることになる。

最良を議論するのは基本的な部分ができてから

さて、全体にわたっていいとこ取りの考えがある場合にどうなるか？

その結果は、そもそもの基本部分が完成せずに足場がグラグラした状態で、議論だけは白熱した状態になる。

最良を求めて議論した結果が、基本的な部分を前提としていないならば意味がなくなることも多い。

要所要所の新しいアイデアの話は楽しいものだけれど、実は本当のアイデアは基本的な部分と密接に関わって切り離せないことのほうが多い気もする。

「とか」や「感じ」で考えるのではなく、実際にUIを描いてみることで問題が浮き彫りになることが多い

UI設計の段階で「とか」や「感じ」で話が進まない時がある。

おおよその方向を話しているときなのだが、当然その段階で具体的なUIを前提として話をしないと、後でやり直しになる。

口頭で詳細検討ができるのが理想だ。

しかし、UI設計をチームプレーで行う場合、なかなか難しい。

UIのジャンルによって個人個人の得意、不得意もあるのでイメージの共有はスムーズにいかない。

その段階で、言葉による検討は非常に無駄が多く遅い。そして意味がない。さっさとやめるほうがよい。

アイデアは常に絵で表現し、検討も絵をみながら、改良も絵をみながら行うほうが早い。

その過程で問題も浮かび上がることが多い。

順番はない

「考えてからだ、それを明確な言葉にする、その後に、絵を描くべきだ」というのは迷信だ。それらは別々に行われない。

実際にいくら考えていても、絵にしようとした段階で問題が起こる。

そこでまた考えるのでは遅い。

絵を描くというのは、なぞるわけでも塗り絵をするわけでもない。形にするのである。

その過程で考えもするし、言葉にもする。

さらにいえば頭の中で考えているときに、人はすでに描いているのである。少なからず何かを思い描いていなければ考えることはできない。

単なる言葉遊びをしたいのでなければ、描くことが大事だ。

描くこと自体が思考や検討や言語化のための手段なのだ。

UI設計は積み上げ式で加算されない

UI設計時はいろいろと不確定なことが多い。

ミーティングで検討する際に、まず細分化しようとすることがある。

細分化したものについて、よりよくするにはどうしたら良いか、工夫を凝らす。

ブロックを積み重ねるように、ひとつひとつ問題を解決しようとすることが多い。

一見まともなアプローチのようだが、これだけではうまくいかない。

単純にブロックに得点があって、積み重ねれば高得点になるかというものではないからだ。

学校のテストのように、得点を積み重ねれば良いと思っていると失敗する。

積み上げたブロックは減点対象にもなる

積み上げたブロックで何を作るかを想像してみる。

そこで家のようなものが浮かぶと積み上げるだけではダメなことがわかる。

闇雲に部分部分をよかれとおもって何か改良したとしても、家としてまとまりが出るということとは別だ。

重ねることで複雑化して、全体でみれば減点となることが多い。

UI設計だけでは無いが、こういったタイプのことは、全体としてどうなのかが大事で、もともとそれぞれを完全に分けて考えることができないのだろう。

見せる行為は引き算

一覧表で項目をどう見せるのが良いのか？

まず、前提として対象のすべてを見せることはできない。

そもそもその対象を的確に表すことができないということがある。

ある人間を対象にした時に、その人間のすべてを表すのは不可能。表そうとしたら、その行き着く先は、その人間そのものになる。

つまり、最初から引き算だ。

ある見せ方をすれば他の部分は見えなくなる

見せ方はコンセプト

たとえばタイムラインも、コンテンツのカテゴリリストからアーカイブされたものを見るのではなく、時間軸の上に様々な写真やメッセージや動画を区別せず並べている。

写真だけ見たいなどという人には不便だがそれよりもほかの見せ方を選んでいるのはコンセプトだからだろう。

見せ方を選択することはコンセプトを決めることにもなる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

要素は簡単に増える

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

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

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

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

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

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

まず作り手が混乱する

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

取捨選択が必要

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

できるとは？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

どうしてこうなった？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 全体を見て強弱をつけないとどれも目立たない

ウェブサイトのメニューの一番左にある「ホーム」について考えてみたいと思います。これは一体何なのでしょうか？検索エンジンから直接ページに移動することもありますので見ないこともあります。しかし、昔からあるこのページ。一体何なのでしょうか？

というわけで、ウェブサイトのインターフェースの基本的な部分の見直しのお話です。

何気なくあるメニューは、データの集合をある一定の基準に従って引っ張り出すための要素と考えると良いかと思います。

これらは別の要素なのであまり同じレベルで考えないようにすると、どこが操作するところだったかわからなくなったりするというトラブルが、後々減ってくるのではないかと思います。

ウェブサイトやブログに当たり前のように配置されるメニューですが、これはいったいなんだろう？と改めて考えてみます。

時に装飾もされるこの要素は一体何か？

サイトのそれは「見る」要素か「使う」要素か？のどちらかというと、「使う」要素です。ということは少なくとも、ごちゃごちゃ動かすものではなさそうです。

配置場所は、上にあるときもあれば、横にあるときもあります。サイトによっては、これが多すぎて、「見る」要素がとてもとても少なくなってしまっているサイトもあります。

これらは、サイト内の「見る」要素を分類していることが多いです。つまり、分類するために「使う」要素といえそうです。

当たり前に存在するよくわからないものを、確かめるためには一度とってしまうのがてっとりばやいです。

とったときに感じる違和感から、それが一体何か？のヒントが生まれることがあります。

ということで、いさぎよくとってしまうと、「見る」要素だけになります。分類のための「使う」要素を全部とると、残りは「見る」要素だけになる。

「歩く」とは身体的なこと。それも生まれてから、歩くようになってからずーっとやってきたはずのこと。それでも、何をしているのか自覚していなかった。

つい最近、ああ、こういうことをしているのか！なんて気づいたのでした。

「歩く」以外でも、人間は毎日やっていても無自覚、そしてやっているのが自分でもその仕組みのわかっていないことは実はたくさんあるのかもしれない。

お久しぶりです。

フェイスなんとか全盛の時代にブログ更新！

久しぶりになった理由は、パソコンの調子が悪かったのと、ほかにおもしろいことがあってこのブログのテーマと特に関係がなかったので、ここには描けなかったということです。

とかいいつつ、カメラを買って動画撮って編集してというのがそのひとつです。映像作品を作るわけでもなく趣味レベル。んー、でもこれがなかなか楽しかった。

でもって、こういったものをウェブサイトやらに載せるとウェブサイトが面白くなる。そー、考えるのも無理はないんですが、載せ方に注意が必要かと。

ウェブサイトには、「使う」要素と「見る」要素が大体混ざっていて、これが逆になるとなかなか使いにくくなる。もしくは楽しくなくなる。

この二つが混ざり合うと結構きつい。基本は明確にエリアなり分けたほうがいい。

Youtubeでコントロール部分がグニョグニョ動かないのは、誰もそこに動く何かを期待して、その様を見ていたいわけではなく、再生箇所を変えたり、音量を調節したり「使う」ためだからだと思います。

反対に、Youtubeの映像部分に、やたらと選択肢が出たり、何かすることを求められても、困ると思います。映像の部分は「見る」ためのもの。

画面に表示されるものとしては全画面にしない限り、この両者は混じっています。ほんとはあんまり混ざるのはよくない。どこが「見る」でどこが「使う」かをいちいち判断しないといけないからです。けれど、このよくないことを踏まえ、それでもひとつの画面に表示させるのであれば、せめて、明確に両者のエリアを分けよう！というのが今の形だと思います。

3種類のサービス の続きです。

結構こういったタイプの現象というのがあると思います。

例えば、ダイビングなんかでもやろうと思えばできます。「イルカ検定」というのをはじめて、どれだけイルカをみたのかを基準に級をつくります。そこに海をかけあわせてもいいです。

たくさんの海でたくさんのイルカを見ると級が上がっていく。そういった仕組みをつくるということが一体どういう事かというと、ダイビングというものを変えてしまいます。

変えるというかひとつのフォーマットができるといったほうがいいかもしれません。

イルカ検定が普及すると今度はイルカ検定に合格することこそダイビングであるということになってきます。

イルカの数値を上げることに一生懸命になるイルカ探しマシーンのような人達が量産されることも考えられます。

このようにもともとはどこの海に行って何を見てもよかったダイビングというものが、少しづつイルカ探しに変わってしまうというようなことがあるのではと思いました。

なので級をつくったとしてもその級が作りあげるものと、もともとのものとの差異は必ずあって、へたをすると別のものになるということも忘れないようにしないとなと。

実際検定にはなってなくても、スペック検定のようになってしまったりというのはカメラとかの世界でもあったりする気もします。それは写真を取るということとはもはや別のものになってしまっていたり。

検定の特徴としては、基準は常に単純化されて、なおかつ数値化しやすいものにするしか無いからかと思います。

そのときに、数値化できないものが抜け落ちてしまう。なので、そういった基準ができたときには必ず抜け落ちた面はあるというのをセットで気に留めておくといいのかもしれません。

サービスは1つではない

ひとつのサービスに見えるものも複数のサービスの集合体なのではないか。

1. 消費するサービス
2. 教わるというサービス
3. 材料を手に入れるサービス

レストランで消費するサービスにあたるのは「料理」、教わるというサービスは「料理教室」、材料を手に入れるサービスは「具材または道具の提供」になりそうだ。

スポーツ施設で消費するサービスにあたるのは「利用される施設」、教わるというサービスは「スポーツ教室」、材料を手に入れるサービスは「ウェアなどの装備の提供」になりそうだ。

どのサービスを利用するかによって行動パターンや文化が異なってくる

サービスの集合体であるので、どのサービスを利用するかによって行動パターンや文化が異なってくると思う。

例えば消費するサービスをメインに利用する人と、教わるというサービスをメインに利用する人では行動パターンや文化が異なる。

特に、この教わるというサービスによってどんなことが起こるのかということを次回にメモしてみたいと思う。

「調べる」の仕組みについて考えてみた。

「知っていることで調べることのできる範囲」というものと「知っていること含んでいる範囲」と「知らなかったので調べられない範囲」の3つを考えてみた。

人によっては「3つあわせて『知っていることで調べることができる範囲』だよ」と思うかもしれないが今回はこのように分けることにしてみた。

「調べる」という行為はこのように、スポットライトが次々に増えていく過程を指す。

この中で、特に重要なのは2個目のスポットライトであると思う。3個目のスポットライトというのは実はどうやっても最初からはスイッチをいれることができない。

なので2個目が大事になる。

「調べる」というのは何かに一直線に向かう訳ではないと感じるのはこういった仕組みを持っているからだと思う。

また「最適なもの」という条件をつけて調べると、なかなか時間がかかるのも、暗闇の中にあるかもしれないスポットライトの当たっていない何かすべてを対象としてしまうからである。

• 行動や文化は「変容するもの」という前提で考える
• 行動には何らかの文化がある
• 「◯◯とは何か？」となぜ問いかける必要があるのか？

変容するということは前提にして、前回のステップのひとつをもう少し考えてみるとこうなる。

前回の「人の映像機材を知る」という1ステップに省略されていたことに当たると考えて良いと思う。

何かを捉えるときに省略されたところを考えてみると、色々やっていることもあったりしておもしろい。

ここでは「調べる」ということをやっている。

大きな特徴は、システムやサービスの複数回の利用があるということ。

Vimeoなどの動画サイトも、最初の時と、新しく知った時と2回利用されることになる。目的も異なってくる。

ただし、全く異なる目的なのかというとそうではなく、比重が変わってくるのだと思う。

• 行動や文化は「変容するもの」という前提で考える
• 行動には何らかの文化がある
• 「◯◯とは何か？」となぜ問いかける必要があるのか？