2015年07月02日 22:55Fujii

Apple の Music はなぜ複雑なのか?

image

Music はなぜ複雑なのか?

Apple - Music - メンバーシップ http://www.apple.com/jp/music/membership/

WWDCで発表された新しいサービスを題材に。

このブログにはできるだけ普遍性のあることを書いておこうと思っているので、特定のサービスを取り上げることは少ないですが、何かありそうなので書いてみます。

新しいサービスは新しい概念が必要になります。既存の概念と共存する必要がある場合、シンプルに表現することが難しい場合があります。

Musicもそう感じるものの1つです。 一見曲という単純なものを扱っているように思いますが なぜなのでしょうか?

複雑になる理由

その理由は以下の2つです。

1「権限」

2「データの置き場所が複数ある」

1「権限」

これはひとつの曲でも「誰の」「どこで再生が許可されている」「どういう形式で許可されているのか」などが変わってくるため別の概念として扱わなければいけなくなる要因かと思います。

2「データの置き場所が複数ある」

デバイスにあるもの、CDからリッピングしたもの、オフラインで聞けるもの、同期してあるものなどなどによって、同じ1つの曲というものを複数の概念で扱わなければいけなくなります。

結果としてiCloud、コレクション、ライブラリ、ファミリー共有といった概念を生み出すことにつながります。

Appleであっても Music というよりも権限や、置き場所という複雑なものを相手に悪戦苦闘しているという感じでしょうか。

データの置き場所を隠蔽して自分の状態によってなんだか聞けたり聞けなかったりするという見せ方も1つのチャレンジですが、反面なにがおこっているのわからないという副作用も有ります。

音楽を聴き放題にもできるし、個別に買うこともできる、一度買ったCDの音源もiTunesで聞けるようになったらいいなあというようなことを実現してきた結果ですが、やはりこれらの2つのことがあるとどうしても複雑になってしまうのかという印象を持ちました。

さらにもう少し考えてみます。

抽象的なものの特徴

権限は条件分岐です。置き場所が複数あることも、ここではこれを再生、ここではこっちをということで、これまた条件分岐となります。

この抽象的な条件分岐というのを視覚的なUIで表現しようとすることにはある種の限界があります。

抽象的なものをGUIで表現するチャレンジをしたことのある方はわかると思いますが、条件分岐のメリットを追求すればするほど表現は複雑になります。そして使い物にならなくなります。

条件分岐の身近な例としてはプログラミングがあります。 これを視覚的に表現しようとすると、条件が柔軟であるほど分かりにくくなってしまいます。

「可視化」に気をつけよう

世の中には「抽象的なことを可視化するという目標」でなにかはじめるプロジェクトがありますが、何も考えずに進めると複雑さがそのまま可視化されただけの意味のないものになります。

反対にその難しさを知っていれば、どのあたりまでならいけそうかということも考えながら引き返すこともできます。 (今の状態のみみせる、または条件分岐のルールのみみせるなど)

2015年06月26日 13:37Fujii

自分はどっち?名詞で似る親子と動詞で似る親子

image

子はどこまで親の影響を受けるのか?

与太話シリーズです。

親子は似ていることが多いですが、似ていると言っても様々なパターンがあります。

血縁上遺伝子的に似るということもありますし、血縁関係がなくても家庭環境として親子であれば似ることもあるでしょう。

似るレイヤーによっては、一見全く似てないように見えることもあるのが興味深いです。

image

「和食料理をつくる親を持つ子が和食料理をつくる」というパターン。

これはわかりやすいです。

「和食料理をつくる親を持つ子がフランス料理を作る」というパターン。

これは作る料理は違うけれど、料理を作るというレイヤーで似たということになります。

「料理をつくる親を持つ子がおもちゃを作る」というパターン。

これはさらに深く、作るというレイヤーで似たということになります。 場合によっては似てないと思われることもあるパターンでしょう。

この表面的には似ていなくても似ているというのは次のようなケースもあります。

異なる意見を言っていて争っている親子は、頑固で曲げないというレイヤーにおいては似ていると言えます。

image

ここまでくると、はたから見ると全く似てないように見えると思います。

名詞親子と動詞親子

このように似ているといってもいくつかのパターンがあり様々ですが、大きくは2種類に分けることができます。

それは、名詞と動詞です。

名詞で似る親子を名詞親子、動詞で似る親子を動詞親子としましょう。

動詞親子は、前述のようなレイヤーは異なれど動詞で似るタイプです。

名詞親子は、名詞が似るパターンです。例えば「料理を作る親を持つ子が料理を評論する」パターン。ほかには「料理を作る親を持つ子が料理の作り方を共有するサイトをつくる」パターンなどがあります。

自分自身はどちらかというと動詞が似ているかもしれないなんて思ってます。

新たな発見のために

親子の「似ている」を考えた時に、どのレイヤーで似ているのか、名詞が似ているのか、動詞が似ているのかを考えると、似ている部分について新たな発見があります。

例えば、一見全く似てないように見える親子がうまくやっているのは「ひとそれぞれ」という部分で似ているからかもしれない、と発見することができます。(これは「頑固で曲げない」親子の逆の仙人のような親子パターンですね)

また、「似ている」を考えることで「似ていない」部分も新たに発見することにもつながります。

さらに視点によって「似ている」とも「似ていない」とも言えることであれば、それは親子なのだからではなく、たまたま同じだっただけだということもわかるかもしれません。

余談ですが、今回の例のような親子だけでなく、親の親、友人、組織、チームなどなど人間関係全般で考えるとさらに発見がありそうです。

2015年06月19日 14:43Fujii

窮屈なUIデザインにしないために

窮屈なUIデザインにしないために

デザインする時にユーザーの目的を考えることは重要ですが、あまりに「目的」に偏ると窮屈なものができあがります。

今回は身の回りの具体的な例(プラス例え話)を集め、最後にその対処例のサンプルとして1つのアプリのアプローチを考察してみました。 (集めたものは偏りすぎているものばかりではありませんが、どのような方向に向かうと窮屈さが増すのかという点でサンプルになるかと思います。)

閉架式の図書館

image

タスク偏重の窮屈なUIとは、例えるなら閉架式の図書館。本棚を見ながら本を選べず、まず目録などで指定して手続きをしてようやく本というオブジェクトを見ることができるので窮屈になります。

窮屈な理由は「Aという本を借りる」という目的以外を受け付けないためです。

一本道RPG

image

タスク偏重の窮屈なUIとは、一本道RPG。対極は自由度の高いRPG。前者は目的が限定され、後者は目的が多種多様どころか決まっていないこともあります。前者は窮屈です。

窮屈な理由は「いくつかのイベントを経てボスを倒す」という目的以外を受け付けないためです。

文字つきのスタンプ(絵文字)

image

タスク偏重の窮屈なUIとは、LINEなどコミュニケーションアプリのテキスト付きスタンプ。コンテキストを限定するため窮屈です。

窮屈な理由は「絵と文字が状況にあっているときに使う」という目的以外を受け付けないためです。

実は絵のみのスタンプが一番複数のコンテキストを受け入れるため様々な状況で使えるのではないでしょうか?

IKEAやフライングタイガーに見られる順路固定のショッピング

image

タスク偏重の窮屈なUIとは、入り口と出口が決まっていて商品をみる順番が変更しにくくなっている店です。これは窮屈です。

窮屈な理由は説明するまでもないですが「その順番で商品を見る」という目的以外を受け付けないためです。

(実際のIKEAはショートカットも可能であったり、フライングタイガーは手にとった商品をレジで返品することも可能です。)

口うるさいコーチ

image

タスク偏重の窮屈なUIとは、現実にはいないと思いますが、スポーツでフィールドやコートに立つ前に「シュートを打ちたい?」「パスをだしたい?」と問うコーチ。

窮屈な理由は、コートに立つまえに一度決めた目的(例「パスをだす」)以外を受け付けないためです。刻一刻と変わる状況なのに、コートに出る前に判断を迫られる。こんなコーチはいたら困ります。

晴れの日は開かない傘

image

タスク偏重の窮屈なUIとは、実際には存在しないと思いますが、雨の日だけ開くことができて、晴れの日には開かない傘です。雨の日以外は絶対開かない傘は窮屈です。

窮屈な理由は「傘は本当に雨が降っているときだけに使う」という目的以外を受け付けないからです。

パッケージ化され過ぎたレゴ

image

タスク偏重の窮屈なUIとは、実際には存在しませんが、例えば自動車しか作れないレゴ。絶対に自動車しかつくれないならば窮屈です。

窮屈な理由は「自動車をつくる」という目的以外を受け付けないからです。

一本道のディズニーランド

image

タスク偏重の窮屈なUIとは、実際には存在しませんが、一本道のディズニーランド。もしも、シンデレラ城中心の自由に行き来する構成ではなく、一本道の遊園地になっていたとしたら、、、窮屈です。

窮屈な理由は、「Aというアトラクションに乗ったら次はBというアトラクションに乗って、、、」という目的以外を受け付けないからです。

窮屈なUIにしないために

やみくもにタスクに偏ったデザインをすると、ナビゲーションが複雑になり、様々な状況からくる要望を受け止めきれず崩壊することがあります。

そうならないためにはしっかりした基本構造をベースにしたうえで、コンテキストからくる要望を検討することが大切になります。

しっかりとした基本構造とは何かを考える際にこちらのアプリケーションがサンプルとして参考になります。

Textwell

このアプリケーションは自分もブログを書く際に使っていますが、アクションを後で選択できます。複数のアクションがあり非常に多用途でありながら、入り口はとてもシンプルになっています。

そのため、自分のように普段は書くだけのユーザーでも、時々段落を調整したくなってきたとき(=そういった状況や目的が発生した時)には、「Reorder Paragraphs」というアクションを選択することが可能になっています。

image

この「あとから何をするのか決めることができる」ことで、窮屈さが軽減され、なおかつ基本構造が崩れにくくなっています。

この順序については「名詞 → 動詞」に詳細があります。

このアプリケーションの紹介に「アイデアはいつもそれを何に使うか決める前にやって来るのに、100個もあるアプリの中からどうやって最適なものを選ぶのでしょうか。」という強烈かつ象徴的な文章があります。これは「状況や目的は使いながら変化する、書きながら、または書いた後に決める」ということを前提としているといっていいと思います。

やみくもに目的をベースにデザインする手法とは異なるアプローチと言っていいかもしれません。

とは言っても状況や目的をないがしろにしているのではなく、「状況や目的は使いながら変化する、書きながら、または書いた後に決める」というむしろリアルな「状況や目的」を前提にしているのだと言うことができます。

こういった点で Textwell はデザイン手法の面からも興味深いアプリケーションです。

2015年05月08日 19:00Fujii

絵本「ぼくのニセモノをつくるには」をデザイン手法の本として読む

image

「ぼくのニセモノをつくるには」という絵本を読みました。

この本は、こどもが自分のニセモノをつくるために自らを改めて考察する、または表現することを考察するというストーリーです。

プロフィールや趣味嗜好に加え、場所による変化も出てきます。

絵本の中の「ぼく」を「ユーザー」に置き換えてみると、ペルソナやシナリオ、またロールやタスクといったものにつながりそうな表現が出てきますので、誰かに説明するときにも傍らにあると役に立ちそうです。

例:「ペルソナのプロフィールはこれにあたる」「ロールはこれみたいな感じ」「基本的な欲求はこれ」

絵本ですのでUIデザイン手法の本として注目されることはまずないと思いますが、普通であれば長い文章で記述するしかないようなことを、とっつきやすい簡潔な絵で視覚的に表現しているのでおすすめです。

この本は「ぼく」に関することなので、デザイン手法でいえばユーザーに関することだけです。プロダクトに当たるものは登場しません。

ですので、様々な「ぼく」を相手にプロダクトをデザインするときに、どこまで「ぼく」を考慮するとよいのか、どこから考慮しないほうが振り回されないのかを考えながら読むとまた発見があると思います。

ぼくのニセモノをつくるには
ぼくのニセモノをつくるには

2015年05月07日 19:12Fujii

Pixarのブレイントラストを参考にリサーチとUIデザインの距離感を考える

image

リサーチを根拠にしてデザインを決定するというプロセスの課題

リサーチから流れ作業的にプロダクトのデザインができるわけではないので、そこにはある種ビジョンを持った人がいて、取捨選択し決定しなければ、発散するばかりかと思います。

リサーチを根拠にしてデザインを決定するというプロセス有りきだと、ペルソナにしろインタビューにしろ、ユーザビリティテストにしろ、それらの結果に強く結びついたデザインにしかなりません。

例:ユーザビリティテストでの発言ひとつひとつを根拠として変更したことを「改善」と呼ぶといった手法 (このことの問題はインタビュアーが聞くかどうか、ユーザーがたまたま言語化するかどうかということに大きく左右されてしまう)

このことを避けるためには、リサーチとプロダクトのデザインはある程度、距離をとる必要があるのではないかと感じています。

映画作りにおける意思決定と権限の一例

以前に、Pixarの映画の作り方として、様々な人の意見を聞いてつくるというエピソードを目にしました。印象としては「独裁ではなく共同でつくる」というようなニュアンスの話でしたので疑問が浮かびました。

「創造的な映画作りにおいて、意見を聞いてどのようにまとめるのか?」

ということです。

Pixarではこの話し合いのことを「ブレイントラスト」と呼んでいるようですが、少し調べてみると、やはり、「共同で」といっても最終決定権限は監督にあるとした上でざっくばらんにエキスパート同士で意見を交換するということでした。

過去の失敗例としては、ブレイントラストに権限を与えすぎて失敗したということもあったそうです。(権限を与えすぎ=その場ででた意見や改善をおこなわなければいけない、というようなことかなと)

大ヒット作『アナと雪の女王』も「ピクサー流会議」から生まれた

”映画監督や制作チームは作品づくりにのめりこむうちに、最初は森全体が見えていたはずなのに、いつしか木しか見えなくなることがよくあるそうです。その視点を取り戻させるためにブレイントラストはあるのだとキャットムルは言います。”

という存在意義はあるようですが、以下のような考え方が根底にあるようです。

”しかし、それ以上のことは望んでいません。「ブレイントラストが考える解決策は、おそらく監督やその制作チームが考える解決策ほど優れたものにはならないから」です。”

リサーチとプロダクトデザインの関係

リサーチとプロダクトのデザインというのも、少し似ていて、リサーチに権限を持たせずに、プロダクトデザインに権限を与えたほうがうまくいくような気もします(そもそも現在リサーチをプロダクトデザインに実際に取り入れている企業はそうしているかもしれません)。

ちなみにこのブレイントラストというものの参加メンバーはそもそもエキスパートだと思うので、デザイン系の手法(普通の人がそこそこのものをつくれるための底上げ的な手法)とは少し意味合いが違うとは思っています。