UX Days Tokyo 2016 振り返り

UX Days Tokyo 2016 に参加してきました。
気づいたことをメモします。

日時・場所

2016/03/18
@コングレスクエア日本橋:コンベンションホール 

f:id:thirose0726:20160320010249j:plain

プレゼン内容メモ

「拙いメモ」且つ「自己解釈」を大量に含みますが、よろしければ。

UX DAYS TOKYO 2016「16年の UX ワークから学ぶ16のレッスン」 - nan3’s blog

UX DAYS TOKYO 2016「混乱をどのように整理するか?」 - nan3’s blog

UX DAYS TOKYO 2016「「商品のストーリーボード化」 - nan3’s blog

UX DAYS TOKYO 2016「5日でプロトタイプと試作品を設計する方法」 - nan3’s blog

UX DAYS TOKYO 2016「SFにおける ”弱いAI:ANI" と新しい試み」 - nan3’s blog

 

Jesse James Garrett氏「16年のUXワークから学ぶ16のレッスン」

・ジェネラリストとして活動したからこそ、多くの気づきが得た
・大事なのはチームワーク

とおっしゃる Jesse さんのお話はどれも共感できるものでした。


プレゼンメモに 16 の内容を全て載せましたが、特に気になったのだけご紹介。


# 4. Go Father than you think you should

自分の領域のリミッターを外す。イノベーションを起こすには、時に非合理的な行動が必要とのことでした。

# 8. But as curious about your clients as you are about your users

「クライアントはデザインについて何も答えをもっていない」ではなくて、もっとクライアントに興味を持とうと。非デザイナーとデザイナーで争ってはいけない。 

# 14. Pay attention your failure

失敗についての姿勢についての話。「学ぶ」だけじゃ足りなくて、「この失敗は自分にどのようなメッセージを送っているのか」について深く考える。振り返りが嫌いな自分には耳が痛い話でした。

 

Abby Covert 氏「混乱をどのように整理するか?」

f:id:thirose0726:20160320010358j:plain

 

大好きな IA の話。


#「共通言語」で会話する重要性

誤解を招きやすい言語 (semantic dragon)が組織の生産性を落とすという話。「社内の共通言語を作る」、「NGワードを作る」という企業向けコンサルティングもあるのですね。私の社内でも、誤解を招きやすいワードが時折飛び交っているので、controlled vocabulary 意識してみます。


# IA は「正しい整理」ではなく「合理的な整理」の専門家である

絶対的な「整理」は存在せず、「ゴール」によって、「整理方法」が決まるというお話でした。

 

 

Kevin Cheng 氏「どうやって商品をストーリーボードにのせるのか」

f:id:thirose0726:20160320010445j:plain


ストーリーボードの重要性を、「漫画」を例にとって分かりやすく説明してくださいました。

 

  • コマ割りにより、「時間の広がり」「動き」を表現
  • 表情で、「文字」の効果をあげる

 

という効果を、

 

  • 動画よりも短時間

 

で実現できるのは効果的ですね。

 

---

「ホテルについてから」ではなくて「ホテルにつくまでの友人との楽しい時」を漫画で表現することにより、
ユーザの共感を得る。

「なぜ我々がここにいる必要があるか」を漫画で説明
---

等の事例も、内部の人の苦悩が伝わってくるような、具体的でわかりやすい内容でした。


Daniel Burka 氏「スプリント:5日間で試作品を作り製品テストをする方法」

f:id:thirose0726:20160320010708j:plain

  1. 最善な仮説
  2. 開発
  3. 検証

という流れには、

  1. 常に最善であることは難しい
  2. 開発には時間がかかる
  3. 売ってしまってから「やっぱり無しよ」はできない

というリスクがあるということについて警鐘を鳴らされたあとに、google sprint の実践方法についてお話しされました。

  • exective も巻き込む
  • 短期決戦
  • ユーザインタビューを必ず実施
  • 推測、仮説はガンガン捨てる勇気

等が必要とのことでした。


一方、四半期に1回くらいが限度で、それ以上やると疲弊しちゃうとのこと。


懇親会でお話しをさせていただきました。プレゼンでは早口でクールな印象でしたが、懇親会ではとてもフレンドリーで、アウトドアスポーツをたしなむ紳士でした。

 

Chris Noessel 氏「SFにおける「弱いAI:ANI」と新しい試み」

f:id:thirose0726:20160320010742j:plain


正解を導きだすには「正しいドメインモデルを定義する」ことが必要であり、ここでは AI を例にとって、

  • どれが AI か
  • どのような種類の AI か

ということについて、考えてみようという問いかけでした。

 

AI がどのように表現・評価されているかということについて、SF映画を例にとった考察をご説明頂きました。

 

SF映画の説明において、Chris さんの映画オタクぶりが徐々に聴衆を引き込んでいました。

 

映画を紹介しながら、時折、感極まっていらっしゃるのが印象的でした。

 

AI には、

---

1. General AI (汎用 AI )

人間のように考え、進化できる

2. Narrow AI (狭い領域における AI)

一つのドメインにおいて、知覚・行動できる
---

 

という二種類があり、主に「Narrow AI」についての説明でした。例えば、

  • やかん
  • ポット

等「機能する」と思ったものは、AI じゃなくて「物」として見てしまう。

 

他方で、SF映画上で、

  • 正解を知っているのに教えてくれない
  • 人間に危害を与えてしまうもの

等、人間にとって「融通が利かないもの」は、未成熟ゆえに「AIだ」と人間は認知してしまう。といった内容でした。 

 f:id:thirose0726:20160320010825j:plain

f:id:thirose0726:20160320010858j:plain

カンファレンスの総括

 

  • 質の高いプレゼンが多く、プレゼンターの情熱も高かった。
  • 運営スタッフの方が通訳をしてくださり、プレゼンターと長く会話することができた。
  • 宣伝も控えめで、ストレスがなかった。


その他気づき

「違和感に気づく」能力が薄まらない為の取り組みをしよう

「目の前の課題」との距離を、意識的に近づけたり、遠ざけたりすることが重要。


「改善策」を実現するために、擁護者を探そう。

・「デザイナ」対「社長」
・「デザイナ」対「会社」

というように、極端な対立構図を作ってしまいがち。

 

必要なデザインプロセスを考え、常日頃から、社内に発信し、仲間を作ることが必要。

 

また、最後の QA セッションでの『「デザイン」という言葉を使うことでデザイナが孤立する』という話が印象に残った。

 

自分たちの専門性を協調してしまうような言葉を使わずに、周りを巻き込むということも意識してみたい。

 

「大事なこと」を何度も口に出そう


「デザイナー業務における課題」「プロダクトマネジメントにおける課題」も抽象度をあげると Jesse 氏のプレゼンで離されたような「原理原則」にたどり着く

 

「原理原則」を自分にリマインドするには、定期的に書籍を読みなおすこと以外にも、人と話して「○○ってやっぱり大切ですね。」と声に出すことも有効に思う。

 

 

カンファレンス後に購入した本

プレゼンの中で紹介された本や、懇親会でお話しさせていただいた方から紹介いただいた本です。それぞれ勉強しまーす。

 

Amazon.co.jp: ユーザーストーリーマッピング: Jeff Patton, 川口 恭伸, 長尾 高弘: 本

Amazon.co.jp: アジャイル・ユーザビリティ ―ユーザエクスペリエンスのためのDIYテスティング―: 樽本 徹也: 本

今日からはじめる情報設計 -センスメイキングするための7ステップ : アビー・コバート, 長谷川敦士, 安藤 幸央 : 本 : Amazon.co.jp

UX Days Tokyo 2016「SFにおける ”弱いAI:ANI" と新しい試み」

プレゼン内容メモ
※ 誤記多いにあると思います。ご容赦ください。

 

15:30-16:20
Chris Noessel
「SFにおける ”弱いAI:ANI" と新しい試み」

 

正確な認識を持つことの重要性


デジタル展示の仕事をしていた際に、倉庫の後ろでバスケのシュートの練習をしていた。
中々ゴールに入れることができなかった。

リチャードから、「バスケットボールの目線で考えたみたらどうだ」というアドバイスをうけた

バスケットボールから見れば、ゴールに、一番入りやすい形は、ゴールに対して上からはいることであることがわかった。

その後ボールをゴールよりも上に投げることがシュートが入るようになった。

正確なメンタルモデルを持つことは重要であることに気づいた。


AI の種類

General AI

汎用的な AI のことをさす
人間と同じように考える

General AI に「あなたと同じAIを作ってください」と依頼すると、「少し知能が高い AI」を作ることが想定される。
それが続くと、「Super AI」が完成する。

人間が脅威を感じているのは「Super AI」である。

Narrow AI

一つのドメインにおいてうまく機能する
当該ドメインであれば、知覚し、意思決定を下すことができる
当該ドメインにおいて、学習も可能

ナレッジの汎用化はできない。

(例)
・アルファ碁
Google 翻訳
・Sportify

Narrow AI is hard to see


・Narrow AI を普段の生活で認識することは難しい
・「機能する」と思った時点で、「物」と捉えてします。

SF映画の紹介:Leave It to Roll-Oh (1940)

・コーヒー
・やかん
・ポット
・トースター

が AI として説明されている。
一方、現時点においてこれらが AI として認知されることは稀であろう。


SF映画の紹介:Iron Man (2008)

様々な手が主人公の操作を助ける。
「様々な手」は、中々融通が聞かないので、「AI」として認知することが出来る。

SF映画の紹介:fifth elements (1995)

キャラクターの指示で、「掃除機」が自動で動き、また「水」や「食べ物」が自動で出てくる


Narrow AI is hard to write

表現方法についても工夫が凝らされている

SF映画の紹介:Space Odyssey (2001)

カメラレンズのAIが出てくるが、これは general ai である。
ここで、general ai は「悪」として描かれている


SF映画の紹介:Starship troopers (1997)

宇宙船の航路を計算する AI
「航路が誤っていたとしても、人間が確認するまでは回答しない」というシーンがあり、「融通が利かない」ような表現がされている。

SF映画の紹介:Firefry (2001)

空中の敵を撃ち落とすための装置において、焦点をあわせる AI が描かれている。

本来は、「焦点をあわせる → 打つ」までを AI が担えばいいわけであるが、敢えて判断を「人間」に任せることで、「AI < 人間」という関係性を表現している。

SF映画の紹介:wargame(1983)

「世界戦争の戦略を立てる」という機能をもつ、AI に「○×ゲーム」をやらせる。

○×ゲーム」により、「絶対的な勝者は存在しない」と理解する

「戦争自体をそもそもやめること」しか解決策はないという回答を導き出す。

AI は「良い判断をした」とも言える一方で、「短絡的」とも言える。

Narros AI if the AI of now


理解して設計することで競争優位性を発揮できる
Narrow AI には2つのタイプがある

Assistine

動作を補助してくれる


Agentive

代理でやってくれる

 

・ルンバ
代理で掃除やってくれる

 

・Narrative Clip
体につけると 30秒ごとにカメラを撮影

自宅に戻ると wifi に自動でつなげて写真をアップ

「場面」「重要度」を判断してカテゴライズ

その後携帯に送ってくれる

 

google 自動運転車

 

A Conversation Model

ユーザインタビューをして、良いモンタルモデルを作ろう

ユーザへの効果的な問いは

「無限大の知識を持っているアシスタントをつけれるなら、何をさせたい?」

というものである。

その答えが製品となる。


最後に

アニメの知識がないので、日本のみなさんには、「AI が表現されているアニメ」を教えてほしい。

QA


Q:
ドラえもんや鉄碗アトムは、Narrow AI か?

A:
「キャラクター」と言われるのは、たいてい General AI


Q:
Narrow AI はどのように見分けることができるか?

A:
前提として、General AI / Narrow AI の線引きは未定義である。

見分け方としては、
・一つのドメインだけを見ていないか?
ドメインを超えた判断が出来るか?
等がある。


スピーカー全員とQA


Q:
日本企業における UX の問題点は何だと思うか?

A:
・Abby さん
Exective の理解が薄い。
プロセスに経営陣を巻き込む必要がる。
どうすれば経営陣をプロセスに巻き込めるかを考えよう。
売り込むだけじゃだめ。経営の課題を一緒に考えよう。


・ux london 運営者の方
デザインが組織に取り込まれていないのは、組織の問題ではなく、デザイナの我々の問題と捉えよう

・Jesse さん
仲間になる人を探そう
一人の擁護者 (champion) がいるといい。

・Daniel さん
デザイナが出来ることは、相手のアイデアを具現化してあげることである。
「みんなで作る」という状況を作るのが大事。

・ux london 運営者の方
企業において、「どのようなプロセスが必要か」は、沢山の文献が存在する。
上手く言った企業はプロセスを活用している。
成功事例は沢山あるので、それを提示したら良い。

シリコンバレーの企業も日本企業と一緒の悩みを抱えている。
彼らはアイデアをすぐに実行しているだけ。

・Daniel さん
シリコンバレーのデザイナーも常にイライラしている。
成功例だけが伝わっているだけで、普段対面している課題は泥臭い。
自分たちで課題を考えるおも大事。


Q:
Design Sprint について、デザイン以外に適用可能か?

A:

・Daniel さん

様々なものに適用できる。

例えばマーケティング。
「価格が安い」「効果的」「Universal」のどのワードが刺さるかと迷ったとする。
フェイクブランドを作って、ユーザインタビューを実施する。「なぜそれを選んだか」と質問する。

・ux london 運営者の方
Excecutive は最終形しかみない。それじゃ駄目。
プロセスに参加させると、必ず変わる。「知らしめる」のが第一歩。


・Kevin さん

プロセスを知ってもらうのは本当に大事。
Twitter は、デザインスタジオのクリアケースに「デザイン工程」を一般公開している。

・ux london 運営者の方

デザイナの仕事は、美しいものを作るだけではない。デザインプロセスをデザインすることもデザイナの仕事だ。
一人で頑張るのではなく、チームでやる。
デザイン思考を学ぶべきである。

・Daniel さん

なぜ いちいち「Design」をつけたがるのか。我々は単に「Sprint」と及んでいる
「Design」という言葉を使うと、デザイナが孤立に向かう。
他の人の意見を積極的に聞こう。

UX Days Tokyo 2016「5日でプロトタイプと試作品を設計する方法」

プレゼン内容メモ
※ 誤記多いにあると思います。ご容赦ください。

 

14:30-15:20
Daniel Burka
「5日でプロトタイプと試作品を設計する方法」


Google Ventures のプロダクトデザイナー
幅広い規模の企業に投資しており、投資先企業のデザインをしている。

デザインの位置づけについて

1年半前にイギリスの企業家とランチをした。
「デザインとは何か」という問いに対して、緊張した面持ちで、

ブランディングにおいて重要である。
・製品は美しいデザインであるべき

という答えが返ってきた。一方で、「ビジネスパートナーとして何に向き合っているか」という問いに対しては?

事業上の課題
・新しい機能が顧客に届くか
・組織の課題

などがあがってきた。

「デザインが、今抱えている重要事項に対して意味を持つ」ということを伝えると顔色を変えた。

Design Sprint の必要性


デザインの発言権は少しずつ上がってきているが、

1. 最善の仮説を立てる
2. 構築する
3. 検証する

というプロセスにはリスクがある(同時にチャンスもある)

1. → 「最善」の仮説を立てるのは大変
2. → 開発には時間がかかる
3. → 発売してしまうと中止は難しい


Design Sprint 事例


Google Ventures では、 Design Sprint を実施している。

Savioke社
http://www.savioke.com/
課題:ピーク時間にはサービスレベルが低下する
解決策:ロボット (Relay) がタオルを配膳


適任者を選ぶ

・デザイナー
・エンジニア
・CEO
・ロボット専門家
・COO

時間の制約を設ける

以下により良いプレッシャーが生まれる
・締め切りは2-3週間後
・1週間ごとに成果物を出す


金曜日にユーザインタビューを実施する


・ホテル生活に慣れすぎているユーザ(ex. 週1でホテルを使う)
・ターゲットにならないユーザ(ex, ホテルを使わない)

などは外す。

漫画でプロセスを示す

チャンスもあると同時にリスクもあることが明らかになった。

ロボットの振る舞いはどうあるべきか?
世間のロボットのイメージは、ウォーリー (pixer) のような洗練されたものであろう。

期待値を下げておく必要が有るかも知れない。


タオルを届けた時の振る舞いを考える

・顔は?
・音は?
・話せるようにする?
・ダンスできる?
etc.

ブレストは、意見の強い人に引っ張られるためしない。
1人1人にソリューションを考え、スケッチしてもらい、全員で投票する。
組織の意思決定者には投票に重みをつけた。

3週間後のリリースを目指す上で、ダンスのような大きな機能 (feature) をつけるのは一般的にはリスクである。

プロトタイプ作成

制作時間は 8h

ツールを駆使して、モニターに投影する紙芝居をつくる

keynote
・flint
・InVision

クオリティは、紙とモックアップの中間
サウンドエンジニアは音響を作る
デザイナはインタラクションを作る
モニタのコントロールを、PSのコントローラーで遠方から出来るようにした。
1周回る程度の簡単なダンスも簡易的にプロトに入れた。

research (ユーザインタビュー)

ロボットを全員が好評価

一方で以下の問題もわかった
・名前がないので「呼べない」
・UI がゆっくりすぎる

「ダンス」についても、短期間で価値があることがわかった。

ユーザインタビューにおいては、「試作機です」と渡すのではなく、「完成品」と思って触ってもらうほうが有益なフィードバックが得られる。


最後に

Design Sprint で重要な点は以下である。

・適任者の選定
・期限を決める
・早く research する
・推測や仮説をどんどん捨てる


QA

Q:
デザイン投票は「デザイン性が高い」「実用性はないが面白い」ものに投票が集まってしまわないか?

A:
そういう時もある。

・悪いアイデアでも施策してみる
複数の施策を作ってみる

というのが解決策の一つかも知れない。

Q:
自社で sprint を実施している。メンバーが疲弊しないよう気をつけるべきことはあるか

A:
変な時間に働かない。
適切なものに時間を使う。
プロト作成に時間を使わない
sprints は、多くても 2,3ヶ月に1回。四半期に1回程度


Q: 
design sprint をどのように自社に適用すればよいか?

A:

四半期に1回、尤も重要な問題を sprint の対象にする。
sprint は短期間で「方向付けする」ものと考えればよい。


Q:
時に1日で desgin sprint を実施するような workshop もあるが、時間が短いものは効果あるのか?

A:
悪くはないが、発見は少ないであろう。

ユーザリサーチをする時間がなくなるので、自分たちの想像で進めることになる。
きちんと1日ユーザヒアリングに時間をかけることで、多くの発見を得ることができる。
思いつきをプロトにしてもうまくいかない時がおおい。

きちんと立ち止まって問題を深くみることが重要。

UX Days Tokyo 2016「「商品のストーリーボード化」

プレゼン内容メモ
※ 誤記多いにあると思います。ご容赦ください。

 

13:30-14:20
Kevin Cheng
「商品のストーリーボード化」

 

事例

---
事例:google chrome

2008年に google chrome が誕生
googlemozilla が好きであり、mozzila が存在するのに、なぜ chrome が必要かを説明する必要があった。

長文のホワイトペーパーを出したが伝えるのが難しかった。

コミックスのゴッドファーザーと呼ばれる方を雇い、コミックを書いたところ、とても伝わりやすいものになった。
---


漫画をどうビジネスに活かすか。
「漫画は子供だけが見るもの」という価値観の国が多い。
日本の場合、大人も読む。


---
事例:アメリカ航空母艦

「なぜ我々がここにいる必要があるか」を漫画で説明した
---


映画の世界においても、映画を作る前に漫画を作る
「ストーリーボード」と呼ばれるものである。


---
事例:Airbnd

ユーザの経験を漫画にした。
「ホテルについてからの体験」ではなく「ホテルにつくまでの体験」を重視した。

事例:Ebay
スタッフ同士で活用。
買い物プロセスを漫画で可視化
---


漫画の有効性について


「Communication (コミュニケーション)」

昔の壁画に書いてある絵は、コミュニケーションツールとして成立していた。
文字を読めない幼児も、絵を見て笑うことがある。


「Imagination(想像力)」

複雑な人の描写は、特定の人を思い浮かべる。
一方、単純な人の描写は、色んな人を当てはめることが出来る。自分を重ねることも出来る。

感情は、文字よりも「表情のイラスト」を使った方がより使わる。
「文字」「表情のイラスト」を組み合わせるとさらに効果的である。

極端な話「目のイラスト」だけでも感情を伝えることが出来る。


「motion (動き)」

効果的なカット割を考える。
「空白」のカットを入れると、時間の広がりを見せることができる。
「同じカット」を繰り返し見せることによっても、同じく時間の広がりを見せることができる。


漫画の書き方


「あなたはアーティストか?」という問いに対して、子供は全員手を挙げる。
年齢があがるにつれて「アーティストではない」と応える。

漫画はやり方さえ学べば、誰でも描ける。


「What's your comic story」

・誰に見せる?
・時間は、夜、昼?
・場所は職場?
・どのようなアクションが必要?
・会話(現実的で説得力のあるもの)


「Laying out」

・どの視点で見せる?
・クローズアップ必要?

「Dawing and refining」

・ポーズをとった写真をなぞるのも ok
・ポーズのテンプレートは沢山ある
designcomics.org 他

ツールも沢山ある
manga studio 
bitstrips


最後に

「漫画の導入について、会社から許可を得るにはどうすればいいか?」とよく聞かれる。

・リソースや時間の節約になる
・作るのにもリソースがほとんどいらない
・書き直しも簡単

というように伝えると良い。


Yahoo のプロジェクトにおいて、漫画のようなビジュアル情報がなかったがゆえに、
最後の方になって駄目だということがわかったことがあった。

ebay, google, ikea, yahoo, lego を初め、多くの企業が漫画を使っていることも、良い pr になるであろう。
漫画の場合翻訳も時に不要である。

「製品説明のストーリーボードを作ったから見てくれ」と自信を持って言おう。

また、「漫画」は、万能薬でなく、あくまで数あるツールの一つと捉えた方がいい。


QA

Q:一番効果があった事例を教えて欲しい


スタートアップの web ページにおいて、説明の為に漫画を使ったところ、cv が2倍になった。
当社 ceo は漫画を使うことに反対であった。


Q:漫画をプレゼン以外で使ったことはあるか

ディスカッションのツールとして、「チーム全員で漫画をつくる」ということもやった。

また、yahoo 時代に、ユーザ向けに見せたこともある。「これで問題が解決出来ると思いますか?」という投げかけを行った。

 

 

UX Days Tokyo 2016「16年の UX ワークから学ぶ16のレッスン」

プレゼン内容メモ
※ 誤記多いにあると思います。ご容赦ください。

 

10:40-11:30
Jesse James Garrett
「16年の UX ワークから学ぶ16のレッスン」

 

16年 UX デザインをやってきた。
デザインについては勉強をしたいことがない。
元々ジャーナリズムの世界にいて、ライターとして仕事をしていた。
デザイナーとしての成功はデザインに依存することがわかりわ IA について独学を始めた。
ライティングは他者に任せ、IA に集中できろようになった。
サンフランでは広告系の仕事をやっていたが倒産し、デザイナとして混沌とした時期を過ごした。

その後カリフォルニアでデザインコンサル会社 Adaptive Path を設立
UX について語れるようになった

本レッスンの内容は全て、「個人の気付き」である。
大事にしているのはクライアントとのチームワークである。

 

1. Go abroad

様々な業種、業態の方と仕事をした
専門家ではなく、ジェネラリストである。
特定の業界で得た知識は、他の業界でも活かせることが分かった。
異なる問題をつなげて考える事が出来るようになった。

2. Go deep

プロジェクトに参画する際は、様々な問題を深掘りすることが大事

・文化
・市場
・経緯
・歴史
・風土

出来るだけプロジェクトに没頭することが大事

・意思決定方法を理解する
・創業者のことを調べる。
- 個性
- 人格

創業者の個性は社風の一部になる。

デザイナーは複数 project を持たない状態をつくり、深くクライアントの理解が出来る状況を作った。

3. Go for a walk

夢中になると、人は周りが見えない
入力要素を変えるのが重要。
感覚・経験を変える

---
例:科学者

何十年考えても分からないことがあった
ランチ後に散歩をしていたところ、あるものを見つけ、それを見たことで何十年の悩みが一気に解決した
---

ちょっと変えればいい。
・オフィスから出る
・考える場所を変える


4. Go Father than you think you should

「この問題についは、このくらい考えればいいだろう。」というリミッターを外すと世界は広がる
自分が未知な体験をすることは怖いものである。
イノベーションを起こすなら、非合理的でなければならない

---
例:us の保険会社における顧客管理システムを構築する pjt

全国のオフィス環境を見て回った。
彼らの作業はとても退屈そうであり、顧客管理システムの導入は彼らにとっては unhappy であることに気づいた。

そこで、ユーザが喜んでいる方法を考えだした。
今後はオフィスではなく、「おもちゃ」「ゲーム」等を学び、この経験をもとに開発した。

プロトタイプを見た女性が笑いだした。
退屈なアプリケーションが、「楽しいもの」に変わった瞬間に感動を覚えた。
---

自分の領域を広げて「おもちゃ」「ゲーム」まで手を伸ばしたからこその成功であり、自分の領域を決めてしまっては、この成功はなかった。


5. Put away your note

リサーチをしていると細かいものにばかり気をとられがちである。
「人間らしい問題」に対して「人工的な計算」ばかりしてしまうのである。
あえて、手元のメモを見ないようにする時間を作ることも重要である。
デザインについて「直感的な魅力」を考えるのである。


6. Learn to spot your assunmptions

自分が考えている世界の構成要素は、事実と異なることが往々にしてある。

なぜそのように構成しているのかを「声」に出してみる。事実との相反に気づくことができる。

7. Stay curious

好奇心を持ち続けよう。

人は、
「あ、これはあのパターンね」
「この問題は解決したからいいや」
と考えてしまいがちである。

クリエイティビティを伸ばそう。

「exciting ではない」と感じる問題も多い。
表面上だけ見るとたしかにつまらないが、「好奇心」を持ち続ければ
全然違う「見え方」が生まれるはず。そして誰も思いつかない「解決策」が思いつくはず。


8. But as curious about your clients as you are about your users

クライアントについて興味をもとう
「デザインについて何も教えてくれない人たち」と考えてはいけない。
「デザイナー」「非デザイナー」の間で闘いを起してはいけない。


9. Hang with different crowds

異なる職種の人達とつるめば、異なる目線が得られる。


---
例:

Ajax についての記事を書いたところ、色んな職種からメールがきた。
エンジニアから javascript の修正依頼がきた。
js についての知識は浅かったが、「エンジニアの問題解決方法」を学び、より自信を得た。


10. Cultivate allies


コンサルをしていた際、 UX の地位はとても低かった。

・ユーザ体験を俯瞰してみよう。UI の問題ではない

ということを都度教えるが、常にクライアントと一緒にいれるわけではない。

クライアントの組織内に「後見人」がいないと、やがて空中分解する。自分達の仕事が意味をなくしてしまう。

一番の味方はデザイナではなかった。
組織の色々な人が、我々の代わりに代弁してくれることがわかった。

関係を構築し、積極に情報提供をしよう。


11. Pick your battles

「産みの苦しみ」とは常に隣りあわせである。
「産みの苦しみ」に対して、常に勝利を味わうのは難しい


自分への正しい問いは、「何が戦うにふさわしいか」である。

戦う「要」を考えて、

・必ずそれだけはデザインにいれる

という意思決定をするのが良い

---
例:ニュースサービスのデザイン

どのようなニュースを見るのかをリサーチした。
結果、今までにないニュースナビゲーション方法を考えた。

クライアントはリスクが高いのではと懸念したが、
リサーチ結果を見せて「やるべき」と伝えた。

プロジェクトを進める中で、「プロジェクト成功」において、そのデザインアイデアは不可欠で無いことに気づき、
「捨てる勇気」が持てた。

結果、デザインアイデアはプロジェクトに含まれることはなかった。
---

12. Good work doesn't speak for itself

自分で「自分の仕事」を語ることが出来る必要がある。

・なぜこのデザインが良いデザインなのか。そしてそれをやらなければいけないか。

を理解できるように伝え、説得する。

クライアントが我々の仕事を信奉していないと、「Cultivate allies」と同じく空中分解する。


13. Changing a desing is easy, changing mind is hard

我々が向き合うのは「偏見との闘い」である。

・このプロセスはこうあるべきというプロセスへの思い込み
・detail へのしつこい要求
・良いデザインはこうあるべき
・これはうまくいく、これはうまくいかない


違う手法をやるには、自分達の組織に根付いた考え方を変える必要がある。
慣れ親しんだものを変えるのはとても難しいことだ。

14. Pay attention your failure

成功できなかった時は「失敗から学ばなかった」時であった。


LEANデザインとは、「うまく行かなかったことに注意を払う」ものである。
「学ぶ」というレベルでは駄目。
失敗したことは、自分に対して「どのようなメッセージを送っているいのか」を考える。

「失敗の規模」と「学びの大きさ」に相関関係はない。


---
例:ajax

ajax という仕組みにおいて、明示的に「saveボタン」をつける必要ない。
ゆえに不要と考えていた。

「作業が保存されているのか分からない」という不安は、信頼感低下に繋がることを学んだ

何の機能も持たない「saveボタン」をつけた。


・テクノロジがどう機能するか

だけでなく

・ユーザの信頼を得るものであるかどうか

についても考える必要があることを知った。
---

15. Everythins is always changing

before / after があるわけではなく、常に変化はしている。

・テクノロジー
・ビジネス

常に小さい変化が起きている。たまに

iPhone の発明

のような大きな変化が起こる。

「気づかないところ」で小さな変化は積み重なり、大きな変化へと繋がる。
「大きな変化が起きたら、気づけるはず」という思い込みは駄目。
小さな変化に気付こう。

ajax」は、小さな変化が集まって大きな変化に見えただけ。

テクノロジやデザインの法則は進化し続けている。
変化を受け入れるとともに、波乗りを楽しむように変化の波を楽しむ。

16. We are all in this together

世界中の人と話していると

・アメリカほど進んでいない

と言われるが、そうではない。

直面している問題は同じである。世界中でコミュニティを作ろう。

UX Days Tokyo 2016「混乱をどのように整理するか?」

 

カンファレンス概要
http://2016.uxdaystokyo.com/conference/

 

プレゼン内容メモ
※ 誤記多いにあると思います。ご容赦ください。

 

11:40-12:30
Abby Convert
「混乱をどのように整理するか?」

I love making sense of meses

私達の世界は混乱だらけ。
明日はさらに課題が増えている ex. 近所の窓ガラスが割れた

 

Thinking About Information

「情報」を「素材」として捉えることが大事
物理的なものだけが「素材」ではない

---
例:パンケーキ屋でクッキーが並んでいる写真。片方は残り1個、もう片方は沢山積まれている

・片方が人気のようだ
・片方は焼きたてだ

など、「多分こうだろう」と人は推測する

脳に空間(分からないことがある)ができる状態を人は嫌う
人によって「理解」は異なるものだ。
個人は情報を知覚する。

Information (知覚した情報) ≒ Contents (事実)
---

パーツを並べて理解しやすい情報を作るのが、IA

 

Language Matters (言語が重要)

人は、同じことについて、沢山の言い方をする。
そして、いつしか「違うことを言っている」と勘違いしてしまう。

皆さんの会社でどのくらいの言葉が飛び交っている?
・名詞
・目的語
・ラベリングしていること


一方では edit 一方では modify とか


いくつかの言い方をするのが駄目なわけではない。全て簡素化することを推奨しているわけでもない。

何かを変更するときに「ラベルの変更」なの「モデルの変更」なのかわからなくなるのは問題

共通言語があれば共通認識が早い。


そんな時は「コントロールボキャブラリ」が便利

とても地味なもの。
組織の中での言葉の定義を決める
逆の発想で、「誤解を招きやすい言ったら駄目な言葉 (semantic dragon)」を決めることも大事
アメリカの連邦組織でも実践している。

言葉というのは常に存在していて、野放しにしていると semantic dragon にやられてしまう。
「必要ないのでは?」と思われるが、コントロールボキャブラリは効果的であり、今まで納品したクライアントは多いに喜んだ。

 

There is no right Way

 

私は正しいやり方で整理する専門家ではない。
「合理的」なやり方で整理する専門家である。

---
例:八百屋の web サイトの案件

もっと売るのが目的
どう整理するのが良いか。

進める中で、ユーザは「果物であるものを、野菜と認識している」ことに気づいた。

結果として「ユーザの頭の中の分類」を優先し、野菜を分類した。

もし、科学を優先して、「果物」と整理したら、誰もたどり着かず、ビジネスは成功しなかっただろう。

一方、「植物を正確に分類する」ことがゴールのサイトであれば、「果物」と分類するべきだ。

「ゴール」を理解した上で、「整理方法」を決めるのが大事

「○○を買わせる」「○○を科学的に理解させる」のは全然違う
---

AI の世界で、企業がよく陥りやすい「Corporate Underpants (企業のパンツ)」という罠がある。


例えば、企業の HP の中に、組織図を描くとする。
その時、企業はユーザの理解ではなく、自社の組織に基づいて整理をしてしまうものである。それは時にユーザにとって分かりにくい。

「自分達の頭の中の組織図」から離れられないのである。


そのような際、企業を説得させるのは難しい。
デザイナーがやるべきことは、今までの整理案を手離すために「代替案の提示」である。

また、「Card Sorting」は効果的な分類を助ける
コンテンツごとにカードを作る。

We Need Picture

指差す図がないと結論はでない。
図解すれば一発で分かるものを、何ヶ月も考えてしまうことがある。
図は、共通認識ができる。同じ文脈を考えていることが分かる。

解決策としてのワイヤーフレームを書くのではなく、「解決すべき問題」を図解する。


---
事例:Nike の生産管理を助けるシステム構築 pjt

何ヶ月もヒアリングを重ねた。
正しい質問をして、複雑な状況を把握した。
単純にして全組織の人が理解できるようにした。「単純にする」ことは難しいことだ。


今度は、関係者に「簡単だからシステムも簡単なもので十分だ」という誤解を与えた。

そして、再度図を書き直した。「とても難しいことをしているのだ。色んなことを同時進行しているのだ」と分かるような現実に即した図にした。
---

Be careful of Reductionism

---
事例:ピザのトッピング指示を記載したあいまいな図

この書き方じゃ「トマトソース」や「チーズ」をどこにのせるかハッキリしない。
---

ワイヤーフレームも一緒。ワイヤーフレームだけじゃ理解できないこともある。
結果だけじゃなくてプロセスを見せるのが大事。

「解決策」を色んな人に図解させたとすると、人によって全然図は変わるはずである。
「解決策」を図解して、コンセンサスを取れたとしても、「後から変わる」と思った方がいい。

 

まとめ

合意を取ることの重要性について話した。
大事なことは以下。

1. Simplify the language used in your organization
2. Show an alternative way of organizing someting
3. Make a picture of the monster in everyone's head


IA はスペシャリストがやらないといけないわけじゃない。
みんながやることである。
世界をクリアな状況にしたいので、AI を広めて欲しい。
AI についての重要なレッスンを学べば理解が広まる。

著書
http://www.amazon.co.jp/dp/4802510012

 

 

QA

Q : どのように組織の人間を巻き込めばよいか

意見を聞き入れてくれない場合は、「1対1」の場をもって話すのが有効


Q:コントロールボキャブラリについて、どのように Exective を巻き込めばよいか

・メール
・口頭
・パワーポイント

だけでは駄目。

わかりやすくしつける。自分の場合は、Exective が semantic dragon を発したら、笛を吹いて怒っていた。

 

Q: 時間の制限がある中での説得はどのようにすれば良い?

問題を明確にしてあげる
ロードマップを敷いて、得られる効果を見せる。