2016年12月28日 00:50Fujii

デザインの根拠

デザインの根拠

デザインをする時に、何かを根拠にしてデザインをする、ということによく遭遇します。いざそれを根拠に進めてみると、目指していなかったような結果になることもあります。そういった落とし穴にはまらないためには、作り手視点、使い手視点を行き来することが重要です。

数字にしろユーザビリティテストにしろデザインプロセスにしろ、何かを根拠にすればいいものができそうだし、意思決定も楽になりそう、という誘惑があります。

これは作り手視点です。

そのアプローチが本当に良いのかどうかは、使い手視点になってみると、実感を持って捉えることができるでしょう。

幸福の数値化

例えば幸福を数値化する。というアプローチがあります。

デザインは人を幸せにすることがゴールだから、幸福を数値化できれば、それを向上することを根拠に意思決定ができる。

そういった作り手の願望がこのアプローチの背景にはあります。

使い手視点になってみましょう。 自分の幸福を細かく数値にされることに違和感はないでしょうか?

「あなたは幸福度何点、前よりも10点上がってますね。」

といわれたら、なんだか奇妙な小説の世界に迷い込んだ気にすらなります。

IMG_5069

自分の幸福度がなぜ、あなたにわかるのか?

自分ですら比べたりすることは難しいのに、、単純ではない、いろいろな気持ちがあるし、、と思うでしょう。

しかも、誰にとってもわかるような不幸と幸福があるならば、誰にとってもわかるので数値化するまでもなく通じるはずです。

このように考えると幸福度の細かな数値化という手法を、実感を伴って捉えることができ、なにか変なことだとわかります。

目的への最適化

デザインは目的遂行のためにある、だから目的を特定し、それに最適化することがデザインの根拠となる、というやりかたがあります。

使い手視点になってみましょう。 目的に特化し最適化したものを普段どれだけ使っているでしょうか?

時には目的すらわからない、目的としていなかったことに応用したりすることもあります。メール、メッセンジャー、メモ帳などなど。どこまで目的が決まっているでしょうか。

IMG_5070

そう考えると、目的に最適化する手法を、実感を伴って捉えることができ、なにか変なことだとわかります。

正しいデザイン

そもそも、デザインとして正しいものというのは、あるのか?そんなテーマはどうでしょう。

正しいものがあれば根拠にできるので、デザインが楽になる。 これも作り手の願望です。

使い手視点になってみましょう。

自分が使う時に、これは正しいと思って使うでしょうか。

その時その時にいろいろなトレードオフがあり、ものを選択するでしょう。時には間違えるし、短期的に使っても、長期的にはゴミになったものもあります。それがデザインされたものと人との関係の現実です。使い手の道具の選び方、哲学めいたものも関係してきます。それは、センスともいえるし、思想ともいえます。

IMG_5071

そう考えると、デザインとして正しいものを求めるアプローチについて、実感を伴って捉えることができ、なにか変なことだとわかります。

作り手と使い手の乖離をなくす

IMG_5072

これまで述べたように、作り手と使い手をぐぐぐっと近づけて重ねてみると実感が湧いてきます。実際に、重なるとどうなるか?それは、自分のために作ることを意味します。これは自分のためのデザインと言えます。

IMG_5073

なので、自分のためになにかデザインするときの視点、これこそがリアルなユーザーの意思決定のサンプルになります。

部屋の片付け

部屋の片付けをやったりすることも、自分のためのデザインです。

家ではほとんど寝るだけといっても、玄関開けてすぐにベッド、、なんて配置にはしないでしょう。

IMG_5074

では、何を考えて意思決定するのか?いろいろな時を考えて決めます。つまり、1人の自分でさえ、いろいろな時でやることが違うということがわかってきます。

寝たい時には寝るところへ使い手が行く、必要に応じて人間が道具を選ぶ、または道具にあわせるともいえます。

このことで、道具が人間にあわせることが絶対、という考えは、何か変だということがわかってきます。

道具と人間の距離感

言い換えるならば、たった1人の自分という人間でさえ、何をどのようにやるのか、いつも同じやり方でやるか、それは決めることができない。なので、道具に役割を元にした性質を持たせ、というよりも役割をイメージして適した性質のものを選択し、置く。その時になったらそこへ行くことにする。

道具が人間にあわせるといっても、こういった距離感であわせるのだとわかってきます。

プロダクトのボーダーライン

どこからどこまでをデザインの範囲にすれば良いのか?正解があるのだろうか。プロダクトのボーダーラインはどこにすれば良いのかの正解はあるのか?というテーマも考えてみます。

部屋のレイアウトをする時に「寝る」という境界の引き方から考えてみます。寝るときのベッドがある寝室、食べるときのテーブル、などのようにトイレ、キッチンといった概念があります。この線の引き方に正解はないでしょう。

IMG_5075

正解はないですが、なにか自分がいろいろな時にやる同じことのかたまりというのがあると思います。そのかたまりを担当できそうな道具を配置し、配置した後はその時になったら自分がそこへ行くでしょう。また、限られた空間、または覚えてられる頭の認知的な空間といっても良いですが、それら踏まえ道具を選択することもあるでしょう。

IMG_5076

これが現実なので、線の引き方に正解があるかというともちろん無い、自分の部屋に対するビジョン次第になります。

このことで、ビジョンが抜け落ちているデザインはなにか変だということがわかります。

デザイナーは自分のためにデザイン手法を自分でデザインする

デザインの手法で混乱した時は、このように考えると、なにか変だとわかったり、正解があるわけではない、時にはビジョンによる意思決定が重要ということも発想することができ、デザイン手法を実感を持って捉えることができ、応用への糸口となるでしょう。

人は部屋の中の片付けをするときに自分のために自分で部屋をデザインします。

デザイナーは自分のためにデザイン手法を自分でデザインする必要があります。

2016年09月16日 13:38Fujii

タスク偏重のデザインはなぜ生まれるのか?

タスク偏重のデザインはなぜ生まれるのか?

今回の「タスク偏重のデザイン」とは何を指すかというと、ナビゲーションが「学ぶ」「知る」「活用する」などになっているソフトウェアを指します。

こういったナビゲーションがなぜ生まれてしまうのか?をぼんやりと考えてみると以下のようなことが思い浮かびます。

  1. 要素や機能を動詞でグルーピングし、そのラベルを使ったケース
  2. ユーザーの行動を時系列でモデリングし、行動名を使ったケース
  3. ペルソナごとのキャッチフレーズを使ったケース
  4. 機能を「〇〇学習」「〇〇活用」と仕様書に記述しそのまま使ったケース

1と2と3はUCD、HCD、UXD、JTBDなどの手法が裏目に、4は手法とは関係なくソフトウェア開発の仕様書の書き方が裏目にでたケースとも言えるかもしれません。

1.要素や機能を動詞でグルーピングし、そのラベルを使ったケース

image

ユーザー視点でデザインするはずなのに、タスク偏重なデザインになってしまうのは、分類の罠にはまっている可能性があります。

デザインプロセスでポストイットを使う人もいますが、情報をまとめる時に、情報の山を分類し、グルーピングをします。

その際に、要素や機能をうまくまとめることができず、苦しくなって「学ぶ」「知る」「活用する」とか動詞のラベルでまとめてしまうのではないかと思います。

これをそのままナビゲーションにしてしまうとどうなるでしょうか?

「学ぶ」「知る」「活用する」と動詞が先に来ると「資料」がどこに入っているのかユーザーはわからなくなります。

また、ユーザーは資料を活用するかどうかは、資料の中身を「知って」「学んで」それから「活用する」はずで、先に決めることはできません。

ユーザーのための手法のはずが、結果としてユーザーにとって無意味なナビゲーションを提示することにつながってしまいます。

ポストイットで物事をまとめる時は、動詞ではなく名詞でまとめることで回避できます。

そこで失敗するとタスク偏重デザインにつながります。

2.ユーザーの行動を時系列でモデリングし、行動名を使ったケース

image

ユーザーのモデリングという手法があります。その中で、カスタマージャーニーマップや、ユースケース、シークエンス分析、Jobs To Be Done などがあります。

これらは時系列で、ユーザーが行うことを並べます。

行動なので大抵は「〇〇する」といった動詞になります。

この動詞をダイレクトにナビゲーションに用いてしまうと、タスク偏重デザインになります。

3.ペルソナごとのキャッチフレーズを使ったケース

image

2の派生とも言えますが、ペルソナなどユーザー像を共有する際に、キャッチフレーズをつけることがあります。

そのキャッチフレーズで
「Aさん:〇〇について学びたい」
「Bさん:〇〇について知りたい」
「Cさん:〇〇を活用したい」

とした場合、そのキャッチフレーズをそのままナビゲーションにしてしまうと、タスク偏重デザインになります。

機能を「〇〇学習」「〇〇活用」と仕様書に記述しそのまま使ったケース

image

これは仕様書で記述する際に機能に名前をつける必要がでてきて、「〇〇学習」「〇〇活用」といった名称をつけて、それをナビゲーションにしてしまったパターンです。

機能拡張をしていくと、1のケースの分類の罠に陥ることもあります。「AA学習」「BB学習」という機能をまとめた名称が必要になることもあり、その結果「学習」にしてしまうこともありそうです。

コンテキスト中毒デザイナーは発想の転換をして抜け出すことが必要

タスク偏重のデザインは、ユーザーのタスクを定義したデザイナーが、その後、ダイレクトにソフトウェアに反映させてしまうことで起こっています。

コンテキスト中毒デザイナーにとっては、デザインの根拠がユーザーのコンテキストにあるので、その根拠をより強く主張するためには、よりコンテキストを限定しなければいけない。

出来上がったデザインは、ユーザーが最初から全ての目的や手段などを決めてからでないと使えないものになってしまいます。

ユーザーに近づこうとしたがゆえに、コンテキスト中毒に陥ったデザイナーは、名詞をユーザーの前に並べることを怖がることがあります。

これを並べてもわからないのでは?と。

このあたりはGUIの歴史の話になるので割愛しますが、抽象度の高い動詞でまとめようとすると結局は、GUIである以上「見る」になります。

(CUIに比べとっつきやすいGUIは、そもそも名詞を並べることが大前提になっていることは、Syntax(Modeless and Modal)で語られています。あたりまえのようにGUIを使っていますが、この世界観が非常に重要なことだと思います。)

現実には、ユーザーからしたら、「つねに見てるし」「むしろ何が見れるか知りたい」「見てから決めたい」となりますのでこれは無意味です。

また、多くの場合、動詞にしたとしても直後に名詞をユーザーに提示するでしょう。「学ぶ」のあとには、学ぶための「資料」を一覧するというように。

タスク偏重のデザインはユーザーに近づこうとする際の過程で陥りがちですが、抜け出すことができないわけではありません。

抜け出すためには発想の転換をすればいいのです。

「ユーザーはやりながらいろいろ考えて決めていく」という、もう一歩リアルなコンテキストを直視することで、この落とし穴から抜け出すことができるでしょう。

2015年12月14日 14:35Fujii

少しでも講義スタイルのイベントを有意義にするためのアイデア

badandgood

イベントにおける不満

イベントにおける不満に、 「聞きたいことが聞けなかった」 ということがあります。

その結果、 「視点に不足を感じた」「自分が抱えている問題についての話題がなかった」「講演に違和感を感じた」 といった感想につながります。

背景にあるビジョンや価値観

不満はさておき、大前提とする「イベントに対するビジョンや価値観」は以下になります。

・教えてもらうのを待っている人は不満を持ちやすい。

・不足があるなら、そのテーマについて参加者が発信すれば、場が活性化するし、ほかの人もうれしい。

・唯一の正解は無い、やりたいようにやればいい。それぞれの冒険の話を交換するだけ。

・「聞きたい」は「言いたい」の延長

という大前提があることを確認して、不満の解消を考えていきます。

「聞きたいことが聞けなかった」通常の質疑応答

通常のスタイルでは、講演後、質疑応答があります。 しかし以下の理由で「聞きたいことが聞けなかった」という不満が出ます。

・質疑応答の時間が短い

・登壇者の講演内容と「聞きたいこと」が異なる

質疑応答の時間が短いと、聞きたいことが聞けません。 しかし、大きく不満が出るのは登壇者の講演内容と「聞きたいこと」が異なる場合です。

聞き手のコンテキストにおいて発生するテーマに関することは、講演内容に納得していたとしても「聞けなかった」と感じます。 講演者のテーマと異なるので、遠慮して質疑応答で質問自体をしません。 仮にそれを承知でしたとしても、適切な答えが返ってこないこともあるでしょう。(「良い質問ですね」と言われたり。)

goodquestion

「聞きたいことを聞く」通常の交流会

イベント終了後、参加者でラフな食事会などがあります。 ここでは、参加者同士が任意で交流し、個別に「聞きたいことが聞けなかった」問題を解消します。

交流会に大きな意味があるのは、これが理由です。

この瞬間は、参加者に大きな自由があり、自由であるがゆえ活発に意見交換がなされます。

その際の参加姿勢によって、その人自身が、自分の参加者体験を作り出していきます。

この体験はコントロール不可能ですし、コントロールする必要もありません。

人は1つのテーマを、自由に自分のコンテキストにあわせ工夫して「使う」のです。アプリにするとこんなイメージになります。

Action1
Action2

一方でこのときの会話は、場のほかの人にはあまり還元されない側面があります。 せっかくの「いい話」が場に伝わらないのです。

アイデア

聞きたいことを聞けるようにするために「交流会」をとりいれる。

シンプルに、「聞きたいことを聞く」ことができている場があるならば、 そのデザインパターンを使おうという考えです。

もともとのビジョンにもある、 「唯一の正解は無い、やりたいようにやればいい。それぞれの冒険の話を交換するだけ。」 という点とも親和性が高いです。

adventure

実現方法

1.登壇者と参加者というスタイルを破壊。

2.参加者全員がテーマを考え、参加者全員が考える。

3.ラフな空間に近づける

4.実は古いパターンも残す

1.登壇者と参加者というスタイルを破壊。

登壇者と参加者というスタイル、これは教える人と教わる人という形になるので、情報を受け身で聞いてしまいます。

もちろん完全に「教えてもらう」という状態で参加している人もいますが、実はあまりこのアイデアのスコープにはいっていません。

少し「受け身」だけれど、あとで「聞きたいことが聞けなかった」と思うような人がスコープです。

というのも、不満を持つ人は、その人なりのテーマが心の中にあります。ですので、なにかしらの「聞きたいこと」(=言いたいこと)があるという意味では、単に「教えてもらう」というスタンスの人よりも、少し登壇者側に寄っているわけです。

であれば、答えの出ない問いだとしても、それを積極的に発信する方が場として有意義になると考えます。

具体的な破壊方法は、円卓にすることです。対面ではなく平等に席につくので「教えてもらうという」意識が軽減されます。

roundtable

イメージとしては、サミット。 SF映画で惑星代表が集まる、そんなイメージです。どんな小さな星であっても代表者として並んでいる、、そんなイメージです。

2.参加者全員がテーマを考え、参加者全員が考える。

聞きたいことを聞き、答えることができる人が答えるという交流会の要素をとりいれます。

なおかつ、そのテーマを場に共有し、1対1で閉じないようにして、場に還元されるようにします。

そのため交流会よりも、似たようなことを聞きたかった人にも届きます。

これは、「ネット上の公開されたやりとり」というデザインパターンに似ています。

conversation

誰でも発信できて、誰でも答えようと思えば答えることができて、知りたい人は読むことができる、そんなネットのパターンに近づく状態を作ります。

あとで不満を残すよりも、その場で聞いて、誰か分かる人が答えれば、みな有意義だという考えです。

likeinternet

3.ラフな空間に近づける

「交流会」というデザインパターンをとりいれます。 何かを食べる、飲む。あとはざわめきです。

likebar

人数が多い場合は、小分けにして、話しやすいようにする。

tablelayout

その際に知り合いを固めすぎないなど。

notlocalonly

人の会話はBGMの音量に左右されるので、少し大きめにかけます。クラブまでいくとやり過ぎですが、エンジンが完全に止まったバスのように、シーンとしていたら話しにくいでしょう。

また、「答えを出さない」ことも重要です。

たとえ答えが出なくても、聞けないよりは、問題を言って、ほかにも同じように悩んでいる人がいることを知る、その思考過程を聞くだけで有意義なはずです。

4.実は古いパターンも残す

時間は有限なので、実は何か大きなテーマを残すほうが交流は促進します。 まったくの初対面の人同士、共通のテーマがなければ話しません。

対して、初対面でも重い荷物を二人で持たなければいけなかったら、持ったあとに「重かったですね」「こう持つといいですよ」などという会話が生まれます。

なので講演者と参加者というスタイルは、テーマを投げるためにあっても良いのです。 そして個別最適化のために、交流会というスタイルも残しても問題なし。

そのほかの展開のアイデア

実験的な試みとして、流動性を高めるため、机を減らしたいが、止まり木としては残す。

座る場所の流動性を高めるために畳だけにする。

2015年08月05日 16:19Fujii

「問題解決」とはそもそも何か?

image

エスカレーターの使い方が変わろうとしている

エスカレーターをユーザーが工夫して使った。片側は普通に乗る人用、もう片側は空けておいて、歩くことができるようにする工夫だ。これは、急いでいる人と楽をしたい人を分け、前者がいらいらするという「問題」を解決した。そして、それは広がっていった。しばらくしてその工夫は「危険」という副作用があり禁止。エスカレータで急ぐ人が周りの人にぶつかったりするのだ。少し俯瞰してみてみると、このように人間が使い方をあれこれ変えている一方、道具は佇んで変わらない。「UIデザインの比較とは」に似てる。

上記のようなことを最近のエスカレーターの使い方をめぐる変遷を見ていて思いました。

「問題解決」とはそもそも何か?

問題解決型デザインなんていう言葉もありますが、エスカレーターの件はそもそも何が起こるのかを考えるいいトピックです。以下のような現象が起こるようです。

解決策が別の状況を生む。

別の状況は別の問題を生む。

といってもそもそも問題とするのかどうかは、視点や価値観、未来に対するビジョンによって決まる。

状況は変わりやすい。

問題は使い方を変えれば解決することもある。「もの」が変わらなくてもよいこともある。

使い方を変えると別の問題が発生する。「もの」はもちろん変わっていない。(最初の「解決策」で片側荷重になるのでチューニングはされたとは思いますが)

「もの」はどちらの使い方も受け入れていた。

「状況」というのは新たな問題がでてこなければ認識もされないこともある。 (「エスカレーターで急いでいる時にいらいらする」という状況だったはずが、「そもそも安全に使う」という「状況」が新しい問題が生まれることでようやく認識された)

2015年07月17日 20:06Fujii

赤ちゃんはおもちゃに興味があるのではなく、大人とのコミュニケーションに興味がある?

image

新しいおもちゃにすぐに飽きる赤ちゃん

おもちゃ屋さんでおもちゃを見ると、色々な宣伝文句が書いてありますが、買って渡すと大抵その通りに赤ちゃんは遊びません。

興味を持たなかったり、興味をもってもすぐに飽きてしまいます。

これはなぜなのかを考えてみました。

赤ちゃんにおもちゃという概念はない

まず、赤ちゃんには何がおもちゃで何がおもちゃでないのかは区別がないのではないかと思います。

家の中にある様々なものと同じで、何か身の回りにあるものとしか捉えません。

大人がもっているような、おもちゃという概念、おもちゃ屋さんという概念、お金という概念、新しいという概念などもまだないので、「せっかく新しいおもちゃを買ってきたから遊ぼう」という概念もないのではないかと思います。

飽きたおもちゃに再度興味を持つ

最初に興味を持って、ひととおり検品したら終わりです。

動かして、起こることを見たり驚いたり、それを拾ったりします。その後ぽいっとします。

ここで大人は「お、もう飽きちゃったなー」と思います。

ところが、赤ちゃんが戻ってくることがあります。

それは、大人が飽きちゃったおもちゃを一生懸命触ったりしている時です。

なぜなのでしょうか?

おそらく「大人が触っているものを触りたい」ということかなと思っています。

または、すでに検品したものではなく別の何かに見えるのかもしれません。

手段と目的

赤ちゃんにとっておもちゃは手段なのでしょうか?

「大人が触っているものを触りたい」というのは目的と言えますが、ここでいう大人が触っているものは手段になるのでしょうか?

単なる手段ならば、大人が触っているものでなくても良いのでしょうか?

しかしそれだと目的の中の「大人が触っているもの」ということが欠けてしまいます。

「大人が触っているものを触りたい」のではなく「大人とコミュニケーションをとる」ことが目的だという見方もできます。

仮にそうだとすると、大人がおもちゃを触っていない時よりも、触っている時の方が勢いよく近づいてくるのはなぜ?という疑問も湧きます。

ということで、現実を見てみると、全部やりたいのでは?ということが見えてきます。赤ちゃんは、新しいものを触りたい。大人とコミュニケーションをとりたい。大人が触ってるものを触りたい。

目的は、具体的なものも含まれるし、行動も含まれる、無形のコミュニケーションも含まれます。

そして、そもそも触った先、コミュニケーションをとった先に何がしたいのかという目的は持っていないように見えてきます。

このように「目的」というのはなかなか複雑なので、扱う時はざっくりいかないと話が進まないし、粒度によっていくらでも変わることがあるもののようです。