「ユーザー調査」ってもっとカジュアルにならないかな？
ユーザー調査ってやったほうがいいの？
■ユーザー調査のないUXは、UXではない
非常によく考えられているデザインですら、実際のユーザーでテストするまでは仮説だ。様々な調査をすることで様々な疑問に対する答えは得られる。そうしたツールを理解し、使いこなそう。ユーザーを考慮しないことは選択肢に入らない。
■「ユーザーの声」を聞くと道を間違える理由
意識高い記事を読みながら、「ユーザー調査するべきだろうか」なんて話をしていると、
つい頭でっかちになってしまって、ユーザー調査はかくあるべき、とか、ユーザービリティとは、とかとか、、、
色々議論が発散して結局やらない。。ってこと多くないですか？
自分は多かったです、、、
そして、良く「UXを理解してくれない組織のせい」 みたいにしてしまっていました(；ω；)ダメダメや、、、
とりあえずやってみよう
自分みたいな駆け出しのUXデザイナーの皆様は、
「ユーザーの声聞いてみよう！」っと内なる声を聞いた時、
四の五の言うよりは、まずやってみたほうがいい！と最近の自分は思ってます！
この記事をみた後に、
メモ帳にでっかく「調査してみたい仮説」を書き出して、駅前に立ってみましょう。駅前がキツければ友達でもオカンでもいいです。
そして、声に出して質問してみましょう
使う時間は最短で30分くらいです。（やってみると、何だこんなものか？ッとなると思います。）
ユーザー調査を「カジュアル」な道具にしよう
これは自分の反省なのですが、
始めにユーザー調査の話をするときに、
考える時間が多くなりすぎ ＝＞ 話が大きくなりすぎ ＝＞ 結局やらない、、、
という負けルート入ってることが多かったです。
（インタビュールーム借りて？とか、サーベイを業者に依頼して？とか、予算はどうやって作って？、、、とか）
、、とは言え、いきなりそこら辺の話を始めるのって、「プロカメラマンになろう！」っと思って、いきなり露出補正とかホワイトバランスとかの、素人には難しい議論を始める感じに似てると思うのです。
もちろん実績のないカメラマンに高級な一眼レフを買い与えてくれる組織もないです(；ω；)
プロカメラマンになるためには、まず安いカメラを買ってイジって遊んで見て、
それでうまく行かなかったところを勉強してみる！ってのが良いんじゃないかなっと思う派です。
最終的には、「いい作品（サービス価値）作りたい！！！」ってことだと思うので、
もしかしたら、自分が作りたい作品（サービス価値）は、カメラ（インタビュー）じゃなくて筆（他の何か）で作ったほうがいい！ってなるかもしれませんが。。。
日常的に、ユーザーに耳を傾ける習慣をつける
近ごろ、多くの現場でユーザー調査が特別なものになりすぎている気がします。
実際は、良く人が「三年前の自分のデザイン（コード）ひでぇなー」、と思いながら成長していくように、日々使うことでより洗練されていくものだと思います。
予算がないとできない、上司の理解がないとできない、チームに必要とされてない正しい調査の仕方がわからない、、、
もちろん、プロフェショナルで大規模なユーザー調査も必要かもしれませんが、
考える→作る→学ぶ
の「学ぶ」の部分で、もっとデザイナーがカジュアルに使える道具になればなぁ、と思う今日この頃です。
批評（レビュー)で相手の120%を引き出すための３つの"プラス"
以前、DESIGN＋という勉強会に参加させていただき、ちょっと心に刺さった言葉があったので、その場での議論を元に自分なりにまとめてみました。
DESIGN+（デザインプラス） は、我々が普段扱う DESIGN にもう1つ発想をプラスする、ポジティブな創造活動に転換するなどと言った様々な「プラス」の要素を加えることで、DESIGN への新たな向き合い方を模索することを目的とした、 ＜人 / 声 / 知＞ が集まる「集合体」です。
誤った批評文化は「かけ算」を生まない
例えば、新しい企画を確認するとき、デザインモックを見たとき、コードレビューをする時、
誰かと一緒にモノづくりをする時に、必ず批評をすると思います。
その「批評をし合う」という文化は、非常に大切なもので、互いに批評し合える組織というのは、全てのベースになるものです。
しかし、
自分が正しいと思ったことをただ”そのまま”相手に伝えてしまっていませんか？
それでは、批評したの相手の能力を50％も引き出すことが出来ない、と自分は考えています。
（だからと言って、もちろん「本当に伝えるべきこと」を伝えないことは良くないことです。）
相手の力を120％に引き出しつつ、伝えるべきことを伝えたい。
そんなときは少しだけ以下のテクニックをプラスしてみませんか？
批評に３つの「プラス」をしよう
+思考にプラスする+
相手を尊敬する
ここでの尊敬とは、"スキルの高低" や "出来の良し悪し" だけではありません。
相手とそのアウトプットは、必ず自分には無い素晴らしい魅力を持っているはずです。
まずはそこを見定めて、キチンと相手への尊敬の気持ちを持ちましょう。
尊敬の念には、相手と自分の関係をフラットにする力があります。
+言語にプラスする+
「いいね！」でサンドイッチする
まず最初にそのアウトプットの一番いいところを探して、「いいね！」しましょう。
自分ならこうしたい！という気持ちぐっと我慢して、渾身のいいね！を贈ります。
その後ゆっくり自分の意見を述べます。
批評の最後も、「いいね！」でしめましょう
相手はあなたの意見を、ポジティブな気持ちでアウトプットに反映できるはずです。
+行動にプラスする+
相手の意見に傾聴する
批評をする上で、まず相手の意見をとっくりと聞く(傾聴する)ことが大切です。
その上でキチンと貴方の意見を「聞いているよ」と伝わるような行動をしてあげることは、意外に忘れがちです。（実はよーく聞いてる時ほど、ありがちです）
傾聴を伝える方法には「暗示的傾聴」と「明示的傾聴」の二種類があり、
暗示的傾聴とは、キチンと相手が話し終わって一拍置くまで待つ、など。
明示的傾聴とは、相手の言葉に頷く、オウム返しする、などです。
人は「自分が聞いてあげた量」より多くの言葉を聞いてくれない、、、と思っておいた方がいいでしょう。
批評の本質とはポジティブを生むこと
プロダクトづくりは、全てを自分では作れないが故にチームを組んで一つのミッションにあたります。
コラボレーションがあるから、一人では作れない大きな課題を解決できるのだと思います。
アウトプットの批評は、そのコラボレーションのひとつひとつの歯車です。
もしも貴方の批評がアウトプットそのものだけに向いてしまっているのだとしたら、
今回の「思想・言語・行動」を、少しだけプラスしてみましょう。
指摘内容を伝える ＋ 相手の心をポジティブにする、
そのことで、貴方と相手は「足し算の関係」ではなく「かけ算の関係」になれるはずです。
※補足
このプラスは、決して「いい人」になる方法ではありません。
前提として、必ず自分の意見は持ちましょう。
そしてむしろ、エゴイスティクに良いプロダクトを作ろうとするのであれば、仲間の力を200パーセント引き出して、共に新しい価値を届けましょう。
コラボレーションデザインについて、興味のある皆様にオススメの本はこちらです。
十二支に学ぶ、共通言語デザインの大切さ
今年もあと数時間で終わりですね。
鳥好きの自分は酉年の到来を心まちにしております🐣
そんな年の瀬にUXな小話をひとつ。
十二支に学ぶ共通言語の大切さ
皆さん、十二支って何のために生まれたかご存知ですか？
古くは中国の日付を表す記号だったそうです。
十二支は古く殷の甲骨文では十干と組み合わされて日付を記録するのに利用されている。 ~Wikipedia
それがなぜ12の動物たちに割り振られたかというと、、、、
単純に「庶民にも覚えやすいから」
だったそうです。（諸説あります）
なんだ、つまらない理由だなっと思ったかもしれません、、、
そこで、この庶民にも覚えやすい共通言語、がいかに大切かという話をしようとおもいます。
もし時間を表す言葉が無かったら
「時間を共通の言語で理解しコミュニケーションをとる」という文化は、今や当たり前かもしれませんが、
今、身近な所だと、出社や退社、駅などの交通機関、電子機器のタイマーからデートの待ち合わせまで自然と幅広く利用されています。
これらの共通の言語が世界から無くなった時を想像してみてください。
現在の文化や利益は、この時間という共通言語に支えられていることに気づくのでは無いでしょうか？
サービス開発で必須な共通言語
一気に話のスコープをサービス開発に移しますと、
これはEric Evansの『ドメイン駆動設計』にあるユビキタス言語の例でも例えることができます。
つまりは、
「世界」という新規サービスを開発している最中、「日本」というドメインモデルの中にある「時間」という概念を「十二支」という共通のユビキタス言語とすることで、
「じゃ、酉の刻にローンチな！」という厳密な約束をエンジニアと企画職とが結ぶことができる。
ようになったわけです。
十二支という共通言語のデザイン
ここで、最初の話に戻るのですが、
ユビキタス言語は定義よりも、浸透させることの方が難しい
という事実は、つい忘れられがちな現実です。
これらの時間の概念に、身近な動物という分かりやすいアイコンをセットすることで、数百万人というリテラシーの低いユーザーに、共通言語として認知させることができた十二支は、
ある意味で、デザインの大きな成功事例だと感じます。
識字率も高く無かったであろう当時のユーザーにとってもユーザビリティの高い、十二支という新しいデザインは、相当にイノベーティブだったのでは無いでしょうか？
十二支に猫がいないのも、当時の干支を設計したデザイナー（広義）達が、『猫は認知がまだ一般的でない』と検討した結果かも？？
未来の理想に名前をつけよう
ぼくらの開発チームは、これから3年間で作り上げたいサービスの理想像を「蝶」というユビキタス言語で定義し、浸透させました。
これはチームが大きくなり、長期計画が複雑すぎて現場に浸透しにくい、という課題に対する、自分なりのアンサーでした。
（詳しくはいえませんが、蝶という言葉には、美しい姿になるにはサナギという耐える時期も大切だ、という比喩など。サービスに沿った様々な意味が込められています。）
つぎの1年はこの「蝶」という共通言語がサービス開発の中で、現実のものとして羽ばたいてくれることを夢見ています。
サービスをデザインをするために今年読んだ本【ベスト5】
今年も暮れになります。
自分にとって今年は”ただのデザイナー”→"UXデザイナー 兼 プロダクマネージャー”に成長しようと七転八倒した年でした。
まだまだ力不足ではありますが、今年サービスを作る上で「この本役に立った！」と思える本をご紹介します。
Team Geek
Team Geek ―Googleのギークたちはいかにしてチームを作るのか
- 作者: Brian W. Fitzpatrick,Ben Collins-Sussman,及川卓也,角征典
- 出版社/メーカー: オライリージャパン
- 発売日: 2013/07/20
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (20件) を見る
自分はとてもギークとは呼べない人種ですが、それでも”モノづくりをする組織”として大切なエッセンスがギュギュギュ！っと詰まった本でした。
そのまま組織カルチャーの教科書としていいくらい、こういう組織を作りたい、こういう働き方で成果を出したい！。そう思える本です。必読。
UX戦略
サービスのUXについて、根底の哲学から実践的ハウツーまで広く通しで解説してくれています。
サービス作りを真剣に考えたとき、どなたでもまず読んでいただきたいです。
UXデザイナーになりたい！そう思い立ち、この本を読んで中に書いてあることはだいたい全部試しました。結果、UXデザイナーの端くれを名乗ってもいいかな？というくらいには自信をつけることが出来ました。
デザインの伝え方
デザインとありますが、デザイナー以外にもおすすめです。
なぜなら、この本で語られているデザインは「デザイン＝設計」であり、
"設計の意図を伝える"、"様々な意見を調整しアウトプットに落とす"、という文脈は、全ての職種に共通していると思います。
会議室に入る前の心構えの項は身につまされました。。。
今すぐ現場で使えるコンテンツストラテジー
今すぐ現場で使える コンテンツ ストラテジー ―ビジネスを成功に導くWebコンテンツ制作 フレームワーク+ツールキット
- 作者: ミーガン・キャシー,長谷川敦士,高崎拓哉
- 出版社/メーカー: ビー・エヌ・エヌ新社
- 発売日: 2016/04/21
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
正直、企画職用の初級者向けの本だと思いますが、
ただ「上流に携わりたいデザイナー」の中でも、実のところ上流の仕事をきちんと勉強したことのある人は少ないのではないでしょうか？
理解は共創の最初の一歩です、また読んでみると上記の「デザインの伝え方」とほぼ近しいことが書いてあることに気づけました。
ドメイン駆動設計
エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)
- 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子
- 出版社/メーカー: 翔泳社
- 発売日: 2011/04/09
- メディア: 大型本
- 購入: 19人 クリック: 1,360回
- この商品を含むブログ (131件) を見る
デザイナーが食わず嫌いしそうな本ですが、読んでみるとデザイナーこそ読みたい良書でした。
リーン等を勉強したデザイナーは、「あれ、聞いたことあるぞ」「共感できる」っとなる部分が多いのではないでしょうか？
また読んでみた結果、現場のエンジニアと共通言語で開発について語れることがこんなに有意義だとは思ってもいませんでした。
ただし、実装系の部分は読み込むと疲弊するのでお近くのエンジニアに「どこ読んだらいいかな？」っと聞いてみてください。
まとめ
サービスデザインといいつつ、デザイナー向け以外の本が多くなりました。
サービスデザインの本質とは、「如何にメンバーと共創していいプロダクトを生み出すか」だと感じます。
そういった意味で、他職種の言葉を知る、他職種と同じ土台で会話する、メンバーの掛け算を最大化する、ことが大事になるんだと感じた１年でした。
これからも、より広い目で、よりい大きなプロダクトを、より良いメンバーで作れるように日々精進していきます。
