2017年12月12日 19:16Fujii

SiriとGUIはどっちがすごいのか?

197EFF66-52F9-45A4-8E52-D6613D0D9FD8

Siriは便利。タイマーをセットするときに使っている。そして、それ以外には使っていない。

SFの世界に出てくることが実現しそうになると盛り上がる、あれの1つであることは間違いない。 空飛ぶ自動車、時計の電話に口を近づけ話す、チューブの中を車が走る、立体の投影動画、半透明のディスプレイ、立体的なスクリーンをジェスチャで操作、そして瞬間移動。SFでもオカルトSFというジャンルはファンタジーに近いものもある。ジェスチャーや言葉によるコントロールは、魔法使いの呪文のしぐさ、魔法の言葉にも近い。

Siriもその一つ。この流れはどうなるだろうか。 まず、タイマー以外に試したが、あまり使えるものではなかった。なので、自分の使用方法としては定着していない。

タイマーで使えるというのはむしろ発見に近いものがあった。ちゃんとSiriに通じてなおかつ有用な魔法の呪文をみつけたのだ。

これはどういうことかというと、Siriに通じる呪文は隠蔽されているのである。大げさに言えば呪文の書を知らなければ使えない。

もともと、この方向というのは何を目指しているのかを考えてみる。何に憧れているものなのか。

言えばやってくれる世界、だろうか。 これは、自分が曖昧に言っても、いいことをしてくれる世界といってもいいかもしれない。

まるで人のように。

コンピュータを人のように扱いたいのかは、人によるだろう。自分はコンピュータと話していたら何か淋しい気がするタイプだ。話すなら人と話したい。

そうでないタイプもいるだろう。では、人を目指すならば、ゴールは人ということになる。もしかしたらゴールではないかもしれないが通過点であることは間違いないだろう。ということで、人と人はどのようにやりとりしているかを考えてみよう。

人というのは言えばやってくれるが、その結果はまちまちだ。いい結果になる場合もあるし、そうでない場合もある。

曖昧な言葉で言えば伝わらないこともある。曖昧な言葉で言ってもいいことをしてくれることもある。 その過程では互いに言葉や、そのほかの様々な表現も使いながら擦り合わせているだろう。

それでも行き違いもある。

そもそもそれが人と人が関わるということなのだ。

なので擬人化エージェントに人との関わりを求めるならば、通じないことを怒ってはいけない。コンピュータでなくても行き違いはあるのだから。(いや、人相手にも怒ることはあるからいいのかもしれない。ただし、行き違い自体を無くそうとすることは、擬人化エージェントに対する「人よりもさらに通じる存在になってほしい」ということだろう。)

仮に擬人化エージェントとのやりとりの手段が音声だけであるならば、それは電話のみのやりとりに近い。単純なことならいいが、少し複雑になるとなかなか難しい。互いの近況とその感想を聞くくらいなら良いが、3番目にあるものを15番目に移動して、その中の不要なものは削除して、、なんてのはすぐにぐちゃぐちゃになる。

そして、擬人化エージェントに通じる範囲を考え、通じる言い方を探る、魔法の呪文問題を乗り越えながら見つけることが大事。アラジンの「開けゴマ!」のように。 このような世界はコマンドを知らなきゃ使えないインターフェースと近いだろう。

では、音声だけでない場合はどうだろう。

「これ」であってますか?「これ」の中から選んでください。そんなやりとりがあるだろう。

これは結局はGUIにつながる方向だ。

やはりGUIは発明だ。浸透しすぎて透明になり、音声コントロールに憧れるくらいに忘れ去られているが。

対象が示され自らが操作する、そのことがコンピュータを操作することと一体化しているので、(振る舞いが隠蔽されていることはあっても、)自分が何をどうしたかについての曖昧さはない。

やりとりを高度にしようとすればするほど、ユーザーは脳内に仮想のGUIをイメージしながら話をすることになる。結局、最初は音声だがほとんどGUIみたいなことになる。

そうしないと何をどうするのかがはっきりしないからだ。

コンピュータと、何をどうするかについてGUI以外で共有できるならば可能性があるだろうか。脳内に仮想のGUIをイメージするよりも、身の回りのものが反応するような範囲の使い方。 音声による家電操作の類いの話になるかもしれないが、身の回りの家電が結果を直接表すし、操作対象も少なくまあまあ明確だ。「四合炊いて」「追い焚きスタート」とか。それでも二階のエアコンを、、なんてやりだすと直接操作感はどんどん薄れる。本当に操作できたのか確認するために、二階のエアコンの状況を教えて、、なんてのが必ずセットになってしまうかもしれない。

GUIならどうだろう。現実世界の「対象を選択し何かをする」ということを模していること、それでいて、ある程度抽象的な概念も扱えること、現実世界よりは間接的ではあるがイディオムも含め、デフォルメし箱庭的なサイズにできること(二階に行かなくても二階のエアコンの状況がわかる)などは、GUIの良さだ。

2次元で表現できるならばという制限があるが、これは弱点でありつつも、人間の理解も2次元のほうがいい場合もある。(やや強引な2軸4象限の図のほうが正確な3軸の図よりもとっつきやすいように)

結論は、GUIはやっぱりすごいということ。GUIの次のUIは?なんて思考になるけど、GUIというのは頭1つ以上飛び抜けていて、置き換わるのではなく併用するなら何があるのか?ということなんじゃないか。それくらいGUIは発明なのだと思う。

2017年12月02日 08:53Fujii

デザインの改善モデル

39D9A956-CAAF-4AEB-92A8-9DEE235C61CF

世の中には様々なデザインプロセスがありますが、発想部分によってアウトプットが大きく変わります。

一般的なデザインプロセスというのは、スポーツのルールのようなもので、アウトプットの質を保証するものではありません。実際にどうなるかは草野球と大リーグのようにやる人によってだいぶ違います。

もしデザインプロセスとその結果に課題を感じたことがあるならば、発想のブラックボックスの中をのぞいてみるとヒントが得られるはずです。

113298B5-9D19-4846-BD2E-F8B6B498108E

これが改善対象だとします。

3E0B39EE-F2CA-40FE-B796-91E3EC947855

ここに登場するのは宝箱です。 宝箱にはデザインパターンや考え方がはいっています。 これらはデザイナーの意思決定を助けます。

8C430F54-38A4-4AEE-A1C7-D4C75931E227

まずは既存のものをデザインパターンや考え方にあてはめます。

0506AD04-E7FB-4162-A7B6-ADA4AE9B86DF

あてはまらないものは切り分け保留しておきます。

おおよその形ができたあとに保留しておいたものをどうするか考えます。宝箱を見渡して使えそうなものがないか、より良くなるパターンを探したり、微調整します。

6C7F8FAB-5948-4E10-A021-A79E0AFADB84

考え方を変え別のパターンを使うこともあるでしょう。最後に職人芸的に意図的にはずす(一貫性を無視したり、特殊なパターンを選択したり)こともあります。

E5A64D07-84E5-49BF-9966-EDDAF7AF3588

要件を捨てた方がいい場合は捨てます。 デザインパターンは要件とつながっているので、あわないものは捨てることになります。この捨て方次第で出来上がるものが大きく変わることになります。

FB34750B-0772-4FFD-93C3-4AC319C12703

新規性の高いものであった場合も、抽象度のレベルは異なれど、このモデルはある程度当てはまるでしょう。

課題を感じたデザインプロセスのケースと改善モデルを照らし合わせることで、デザインパターンが不足していた、考え方が違っていた、要件を最重要なものとしていた、などなどポイントをはっきり認識する助けになれば幸いです。

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.実は古いパターンも残す

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

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

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

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

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

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