読者です 読者をやめる 読者になる 読者になる

酔いどれデザイン日誌 - Drunken Design Diary -

都内でデザインファームを営む酔っ払いが、UI/UX設計やデザイン思考論を書き殴ります。

都内でデザインファームを営む酔っ払いが、UI/UX設計やデザイン思考論を書き殴ります。

日本製UIデザインツール「STUDIO」は従来のツールと何が違うのか

UI UX アプリデザイン ツール

先日、私の古巣である株式会社オハコからスピンオフしたオハコプロダクツ社から、UIデザインツール「 STUDIO」のクローズドβ版がリリースされました。

国産のUIデザインツールといえばグッドパッチ社が提供するProttなどが有名ですが、β版を触ってみた感想と合わせて STUDIOの何がすごいのか?従来のUIデザインツールとは何が違うのか?ということを紹介してみたいと思います。

目次

これはプロトタイピングツールではない

まず、最初にSTUDIOを「UIプロトタイピングツール」ではなく「UIデザインツール」と記載したのには訳があります。近年はプロトタイピングの重要性が多方面で説かれているのに呼応するように、冒頭で紹介したProttをはじめ国内外からたくさんのプロトタイピングツールが登場しました。何の事前情報もなしにSTUDIOを開いてみると、確かにそれらのプロトタイピングツールの派生系に見えるでしょう。しかし、すこし触ってみるとこれが従来のプロトタイピングツールと設計思想からして全く異なるということがすぐに体感できます。実際にSTUDIOのUIに触らないで理解するのはなかなか難しいのですが、できる限りどういうことか説明してみます。

まず、アプリやWebサービスにおけるUIデザインは大まかに分けて4つのステップに分かれています。

  1. ワイヤーフレーム
  2. プロトタイピング
  3. グラフィックデザイン
  4. プログラミング

このうちプロトタイピングとグラフィックデザインは順序が前後する可能性もありますが、主だったポイントはこんなかんじではないでしょうか。これまで世の中に登場してきた代表的なツールに当てはめると、Prottはワイヤーフレームとプロタイピング。Sketchはグラフィックデザインの領域を得意としており、互いのツールを連携することで優れたUIをデザインすることを補助しています。

ではSTUDIOはこれらのステップのうちどこを得意としているかというと、私が触った印象としては1〜4の全ての工程をSTUDIOひとつで完結させようとしていると感じました。馬鹿げていると思いますか?しかしこれが事実であることは、STUDIOのサービスコンセプトが物語っています。STUDIOが目指している世界は「コードを書かずにサービスが作れる世界」すなわち、GUIでプログラミングまで含めたアプリ制作が完結する世界なのです。

これに気付いたとき、ワクワクせずにはいられませんでした。かつてGUIによってOS操作を実現したように、画面上でグラフィカルかつ直感的に要素を配置するだけでアプリやサービスが出来上がる世界がもうすぐそこまで来ているのだと。

具体的にどのような部分でそれを感じるかというと、まずXcode(アップル公式の統合開発環境)ではおなじみAuto Layoutが、しれっとGUIで実装可能になっています。この時点で結構な驚きです。まだβ版なのにAuto Layoutを優先して実装してくる時点でSTUDIOがXcodeに頼らず開発する未来を目指していることがよく分かります。

f:id:information_architecture:20170323175646g:plain

そのほかにも、Sketch等グラフィックデザイン支援ツールではお馴染みのレイヤー表示順の概念とグループ化がSTUDIOでは(おそらく)意図的に実装されていません。これは、最終的にアプリとして出力(β版では出力機能はありませんが)される際にデータ構造を正常に保つためだと思われます。ちなみに、わざわざ自分でグループ化やレイヤー順変更しようと思わなくても見た目上でブロックの中に配置されたオブジェクトは自動的に正しい順序が保たれた入れ子のツリーのような状態になるため、コンポーネントの区切りを意識することなく想像以上に快適に操作することが可能になっています。

なにより決定的なのが、要素に対してGUI上でAPI接続させる機能が標準で備わっていることです。ここまでで紹介した特徴だけではちょっと変わったプロトタイピングツールという認識になってしまいますが、β版の時点でAPI接続までサポートしようとしている時点でSTUDIOが本気でアプリ制作の全工程をカバーする気だということがひしひしと伝わって来ます。とりあえず、サンプルでspotifyのAPIを叩いてビートルズの名盤のジャケット写真を表示してみました。すげえ。

f:id:information_architecture:20170323180207j:plain

f:id:information_architecture:20170323180222j:plain

ここまでの紹介を読んで皆さんに誤解して頂きたくないのは、コードを書かなくてもサービスが作れる=エンジニアが不要になるということではないということです。プログラミングはデザインと同じく非常にクリエイティブな作業であり、ツールがあるからといってエンジニアの思考無しには成り立ちません。あくまでコードベースではなくGUIベースで組めるようになる点が革命的ということです。

コードベースでなくなることの何が良いかというと、ビジネスメンバーやデザインメンバーがエンジニアと同じ目線でサービスを作ることができるということでしょう。ビジネスメンバーやデザインメンバーはエンジニアの書いたコードを理解することができませんので、デザイナーが形にしないといけないわけなのですが、デザイナーもエンジニアの実現したいことが100%理解できるかというと、そううまく行くことばかりではないと思います。

つまり、エンジニアが素晴らしいアイデアを持っていたとしても誰にでも理解できる形にする手段が無いため誰にも理解されないまま埋もれてしまっているのです。その点において、GUIで機能と見た目を同時に作れることは非常に有効であると言えるでしょう。従来のプロトタイピングツールは、サービスづくりの「デザイン」の領域についてビジネスチームやエンジニアチームを巻き込んだ開発を可能にしてきました。STUDIOは、それらの特徴に加えて世界で初めてサービスづくりの「プログラミング」の領域についてエンジニア以外のメンバーを巻きもうとしているのかもしれませんね。

特筆すべきはシームレスな操作感

ここまでSTUDIOのコンセプチュアルな部分を紹介してきましたが、ここからはSTUDIOのUI/UXにフォーカスして紹介していきたいと思います。STUDIOを開発するオハコプロダクツ社はUI/UXデザイン会社であるオハコからスピンオフしたということもあって、こちらのプロダクトもインターフェース、特にインタラクションの部分について非常に細部までこだわって使用感が作り込まれています。

まず最初に気付くのは、ブロックを配置しようとしたときの挙動の面白さでしょう。こればかりは文章で説明するのが難しいので、STUDIOの公式サイトの「やってみよう」から体験して頂きたいです。左右上下辺からの距離によって要素の座標と大きさを決定するこのUIはプレスリリースによると特許出願中のようで、これまでのどのツールにも無かった独自の操作感を提供しています。実際に触ってみると非常に直感的かつスピーディに要素の配置をすることが出来ることに驚きます。これからドラッグ&ドロップで要素を配置する系のツールのデファクトスタンダードUIになりそうな予感がしますね。

f:id:information_architecture:20170323175736g:plain

β版ではまだLPで紹介されているスマートフォン同期プレビューは実装されていませんでしたが、それでも通常プレビューのシームレスさには驚きます。画像の再読み込みなどが極力走らないように工夫されているのか、一切の途切れなくまさにシームレスにプレビュー状態に移行します。画面遷移を行なっても画像の読み込みはほとんど感じられません。というより通常編集モードですでにプレビューと同等の操作(横スクロールなど)ができるので、プレビューの概念が揺らぎます。

他にも、要素をグリグリ動かすとalignがよしなに調整されてくれたり、画面上で順序を入れ替えるとレイヤー(ツリー)側の順序も入れ替わったり、色んな操作がシームレスに繋がっている感覚が新鮮でした。操作しているというよりもデュエットしているような感覚に陥ります。なんだその恥ずかしい表現。

これだけ色々なことができるツールでありながら、テキストによる説明一切なしで直感的に使えるのはすごいと思いました。ユーザーに学習させてから使わせるのではなく、触りながら学習するというのはUIにおける理想の状態だと思っているので、もっとこういう説明に頼らないUIが増えると良いなぁと思ったのでした。各UIの操作感については、β版を終えて改善が進んだ製品版の方が出た段階で改めてレビューさせていただこうと思ってます。

全員がMVPまで作れる時代

STUDIOがプロトタイピングツールではないことと、誰でも直感的に扱えるツールであることを紹介してきましたが、ではSTUDIOによってアウトプットされるものは一体何なのか?というと、MVP(Minimum Viable Product)であると考えられます。MVPについて改めて説明はしませんが、ここではプロトタイプとMVPとの明確な違いは何かということについて考えてみたいと思います。

MVPもプロトタイプも本開発に入る前のテスト段階でユーザー検証のために用意するもの、という漠然とした認識だと思うのですが、私はこの2つで明確に違う点があると考えています。それは、MVPは「最小限の価値」を確認するための試作品であり、プロトタイプは最終形も含む「状態」を確認するための試作品であるという点です。MVPは最小限という制約があるため、作り込むことに重点を置いていません。一方、プロトタイプは複雑に入り組んだサービスの後期段階でも用いられることから分かるように、最小限にすることに重点を置いていません。両者は包括関係にあるといっても良いでしょう。というより、Prott等のトランジション再現型のプロトタイピングツールもプロトタイプという大きな枠の中のごく一部分(画面遷移)しか試作できないため、厳密にはプロトタイピングツールと呼ぶのは相応しくないのかもしれませんね。MVPにはプロダクトと名がつくくらいなので、基本的な画面遷移に加えて最小限の価値を得られる「機能」が必要であり、機能が入って初めてユーザーは画面から「価値」を体験することができます。『ここで音が出ます』とか書いてあっても、それは本来のユーザー体験ではないですよね?音が出ると決めたらちゃんと音を出すことが、MVPにおいては重要になってくるのです。そして、MVPを作ることはサービスのスタート地点に立つことと同義です。こう考えると、STUDIOは最速でサービス開発のスタートを切らせてくれるツールと言えるかもしれませんね。STUDIOによって、非エンジニアも含めてメンバー全員がMVPまでは爆速で作り上げられる世界が作られることを期待しています。

まとめ

以上、一通りβ版STUDIOを触り倒してみて感じた率直な感想ですが、画面遷移の整合性チェックなどを素早くチェックするのが目的なら私はProttを使うなという印象でした。なんと華麗な手の平返し!やはりプロトタイピングという目的に特化したツールにはそれなりに工夫が詰まっており、使いやすいです。また、ビジュアルデザインについてもSketchの方がやはり出来ることが多く使いやすいと感じます。しかし、これらのツールはUIデザインの特定ステップに限定した場合に使いやすいのが特徴であるため、最終的なMVPの出力まで一気にやるようなケースではSTUDIOで作った方が総合的には早く形になるのだろうなということを強く感じました。STUDIOはまだβ版なのでこれから改善を繰り返していく段階であり、これからの動向が非常に楽しみなツールだと思います。

ところでわざわざこんな長文レビューを書いている理由ですが、古巣のプロダクトということは実は全く関係なく「コードを書かずにサービスが作れる世界」というコンセプトに純粋に惚れ込んでいるためです。私自身が何度かプログラミングに挑戦しようとして言語を覚える段階で挫折を繰り返している身なので、GUIベースのアプリ統合開発環境を切望しているのです。

もしこの記事を読んでSTUDIOにすこしでも興味を持っていただけたのであれば、一度触ってみてください。触ればこのコンセプトとすごさが実感できます!そして、思ったことは良いことも悪いこともバシバシフィードバックしてあげてください!ユーザーとして一緒に作りましょう、コードが必要でなくなる世界を。

すべてのデザインの基本「ユーザーヒアリング」を極めるには?

UX サービスデザイン 分析方法 考え方 ユーザー調査

せっかくブログをリニューアルしたのに全然更新できてませんでした・・・怠惰ですね。さて、最近よくユーザーヒアリングのテクニックとかあるの?コツとかあったら教えて!と言われることが多くなったので、私がユーザーヒアリングを行う際に意識している事を備忘録的に書き出してみたいと思います。スタートアップ企業や、大企業のCSやCX部門などユーザーと直接接する機会のある方はよろしければ見ていってくださいな。

目次

ヒアリングの3大落とし穴

勘所を知らぬまま長々と読んで頂くのもあれなので、先にアンチパターンをまとめます。気に留めながら自身のヒアリングを思い返して頂くと、かなりの確率で無意識にハマってしまっている方も多いのではないでしょうか。

  • 「やっぱりそうなんですね」と言ってしまうこと
  • 「それは○○ですか?」と聞いてしまうこと
  • このユーザーにはニーズが無かったと諦めてしまうこと

なにが悪いの?と言われそうなラインナップですが、これらはすべて確証バイアスをはじめとした様々な認知バイアスがかかっている時に無意識的に発言されるアンチパターンになっています。意識しながら話すとすぐにボロが出てることに気付けるので、ユーザーに会う前に社内でロールプレイングをしていくことを強くおすすめします。この中でも特に確証バイアスは厄介で、意図的に排除しながらヒアリングをするためには結構な回数の実践練習をしないと難しいと思います。

確証バイアスとは、平たく言うと仮説を裏付ける理由ばかりを優先して取り入れてしまい、反証する情報を無意識下で無視してしまう心理的な偏りのことです。あとで詳しく書きますが、バイアスがかかった状態でヒアリングを行ってしまうと、公平性を著しく損なう結果になってしまいます。

一応3大落とし穴の何が悪いか具体的に書くと、「やっぱりそうんですね」発言は、予め自分の中にあった仮説にフィットしたことに安堵している証拠(確証バイアスにハマっている)。「それは○○ですか?」は相手より先に思い込みで勝手に決めつけた具体例を言ってしまうことで回答の幅を狭める行為(相手にフレーミングを与えてアンカー効果を誘発している)。このユーザーにニーズが無かったと諦めることは、会話の一端をかいつまんで仮説にフィットしていないと判断している証拠(これまた確証バイアスにハマっている)です。

これを踏まえた上で『ヒアリングしてるときに何を考えてるの?』という冒頭のよくある質問についての回答ですが、何も考えてません。より正確には、意図的に何も考えないようにしています。何も知らない子供になったつもりで、すべての発言に対して「なんで?どうして?」という好奇心を持つことを心がけています。子供にはバイアスはありませんから、それに習って同じように一切の事前知識や雑念を取り払って当たり前だと感じる発言でも必ず理由を聞くようにすることが大切です。

ユーザーヒアリングの目的は仮説検証ではない

ユーザーヒアリングの目的は、仮説の検証ではありません。仮説を検証するために必要な情報を集めることが目的です。ここを勘違いして、ヒアリングの最中に仮説との付き合わせをしはじめる人が非常に多く居るように感じます。よくある勘違いの例として質問項目をまとめた『ヒアリングシート』をあらかじめ用意し、その仮説に基づいてYesかNoかを問うというヒアリング手法が横行していますが、これはアンケート調査のように対面が現実的に不可能なボリュームに対して有効な調査方法であり、対面調査で用いてしまうと自分も相手も確証バイアスにどっぷりハマって結果が偏ってしまうため、私はおすすめしていません。

もうひとつ、ヒアリング中に具体的な提案をしてしまうのもよくありません。これは、アンチパターンの「それは○○ですか?」と同じくヒアリングしている相手をアンカー効果の罠にハメてしまうことになるためです。例えば背が低い人の「ボタンが押しにくくて困っています」という発言に対して『じゃあ、この位置まで下げたらどうですか?』と提案してしまうと「いいと思う!」となってそこで会話が終了してしまいます。もっと課題を深掘りできるチャンスだったのに、これでは非常に勿体ないです。背が低い=位置が高いから押しづらいのだと決めつけず、こういう場合は『なんで押しづらいんですかね?』と一見アホっぽい質問を投げてみましょう。それによって相手は今自分がそれを嫌だと思った原因を考え始めます。すると、実は思いもよらない原因によって嫌だと感じていることに気付くこともあります。例えば、どのボタンが何の機能であるのか理解してなかっただけとか・・・。

といった具合で、せっかく対面でヒアリングを行うのですから、バイアスを全て取り払って「なんで○○なんですか?」「どうして○○だとダメなんですか?」と、仮説がすでにある部分であってもガンガン掘り下げていきましょう。仮説検証なんかオフィスに帰ってから議事録とにらめっこしてじっくりやればいいんです。

表面的課題と本質的課題を見極めよう

課題には表面的な課題と本質的な課題があります。ヒアリングで真に探らなければならないのは本質的な課題に至るヒントのほうです。

表面的な課題というのは、『複合的な悪条件によって現出した課題の最も目立つ一側面』だと私は定義しています。ユーザーが最初に口にする課題はこの表面的な課題であることが大半だと思います。この本質的な課題と表面的な課題の関係性は、ちょうど本音と建前の関係性と同じようなものだと思うのですが、建前をいくら集めても本音に至れないのと同様に、表面的な課題をいくら議事録にしたためてもなかなか本質的な課題に至ることはできません。だからこそ「なるほど。」とか言ってインテリぶって受け流さずに「それはなんでですか?」と掘りすすめる必要があるのです。掘れば掘るほど本質に近づいて行けるのです。

このように、ユーザーの回答の第一声が課題の核心をついていると考えるのはナンセンスだと言えるのですが、唯一例外があります。それは質問に対して断言の形で即答ができた課題です。即答かつ断言できるということはユーザーが何度もその課題に直面した結果解決策を自分なりに考えた証拠であり、本質的課題に極めて近い情報として扱うことができます。

ただし、ユーザーの発言が課題の本質を的確に表現しているとは限りませんので、即答された場合はチャンスと思って積極的に掘り下げて行きましょう。本質的な課題というのはユーザー自身も気付いていないことが多いので、一緒に掘り下げてあげる事で意外な事実に気付けたりするものですよ。

結果の分析とよくやりがちなミス

こうしてヒアリングから出てきたユーザーの発言の数々ですが、どの程度信用し、設計に反映したらいいのでしょうか。私なりの結論ですが、ユーザーが口にする「課題」や「解決策」は大抵ずれているので鵜呑みにしてはいけないというふうに考えています。ユーザーが言うことが正しくないということではなく、自分の直面している課題の原因を正しく言語化できないという方が正しいでしょうか。

ヒアリングの結果は分析しないと意味を成しませんが、その際にユーザーの言うことを鵜呑みにしてしまうのは危険であるという具体例をひとつ。例えば、自動販売機のユーザビリティ向上を目的としてヒアリング調査を行なったとします。そこで「お札が入りにくいです。」という意見が多かったとき、『じゃあ読み取りセンサーの感度を大幅に向上しよう!すると偽札が使われる可能性も増えるので、偽札判別機能を追加しよう!ついでに投入口の形状も変えよう!』といったように、ちょっとした改修のはずがいつのまにか巨額のプロジェクトになってしまうという事がよくよくあります。これがクソだという理由は説明しなくてもわかりますよね。

このミスを回避するには、ユーザーのペインを技術と根性で解消するよりも前にユーザーが自動販売機に求めている価値を解き明かす必要があります。私はこの例の場合「コンビニよりも時間をかけずに飲み物を手にいれることができる」ことだと解釈しました。ユーザーはお札が戻ってくると何秒かの時間を浪費するので、それが嫌だと言っているにすぎません。すると、そもそもユーザーは100円の飲み物のために(投入成功しても大量のお釣りが出る)1,000円札なんか使いたくないのだというシンプルな事実に気付くことができ、電子マネー決済の導入というソリューションに行き着くことができます。

たった一つ「なんでお札が入りにくいと困るんですか?」という掘り下げの質問ができて、ユーザーが口にする課題を鵜呑みにするのは危険であるという前提があるだけで、巨額のセンサー研究開発プロジェクトが既成の電子マネーモジュールを組み込むだけでよくなりましたね。

余談ですが、ユーザーが自動販売機に求めている価値は時間短縮であるという仮説は、実際に駅で電車がホームに入り始めてから飲み物を買ってみる体験をすればヒアリングなどしなくてもすぐに気付くことができます。自分が体験をする事の重要性はこのブログで何度も説いていますが、人間とは不思議なもので実際に体験しないとこの単純な事実になかなか気付く事ができない生き物なのです。

ユーザーヒアリングはとても大切ですが、ユーザーの意見をどのように分析し、どう活用するか?という部分はまた別の思考法やスキルが必要になります。直接的なヒアリングのテクニックではないですが、ユーザーの意見の使い方として非常に重要な項目なので、あえて備忘録として書き残してみました。機能改善やモデルチェンジのような革新性の無い開発プロジェクトが巨額の予算になる場合それはすべてクソソリューションです。大事なことなので2回言いましたが、どうぞお気を付けください。

まとめ

途中で脱線したのでテーマがよくわからなくなりましたが、我流のヒアリングの極意としては

  • 確証バイアスを取り払え!
  • 子供になったつもりで掘り下げろ!
  • ユーザーの発言は鵜呑みにはするな!

という感じでまとまるでしょうか。もう一度言いますが、ヒアリングの目的は仮説を検証するために必要な情報を集めることです。より効果的な仮説を立てるためには元にする課題が本質的なものでなくてはなりませんし、本質的な課題を探るためにはなるべく多角的なヒントが必要になります。より多くのヒントを引き出すために皆さんにお伝えしたい最終奥義は何かというと、相手と相手の領域に興味をもつことです。ヒアリングテクニックでもなんでもないですが、興味を持つことで自然に「なんで?」「どうして?」ができるようになります。聞きたい領域について自慢をさせてあげられればベストですね。体感的には、相手8割自分2割くらいの割合で相手にずっと喋らせ続けるのが理想のバランスだと思います。これだけ喋っていれば本音がボロボロ出てきてヒントもたくさん手に入りますので、より精度の高い仮説を持って改善に臨むことができるでしょう。

ヒアリングが上手になりたい皆さん、まずは冒頭で挙げた3大落とし穴を意識しながらテーマを決めて近くの同僚とロールプレイングしてみてはいかがでしょう。バイアスをうまくコントロールできるようになったら、ヒアリング以外でも強みを発揮できますので是非マスターしてみてください!

ブログリニューアルしました

雑記

皆さんお久しぶりです、おりです。いろいろありまして1年以上更新できていませんでした。元「とある企画屋の体験設計(ユーザーエクスペリエンスデザイン)」のこちらのブログですが、2度目のブログ名変更を経てリスタートさせたいと思います。ということでまずはこの1年の軽いご報告を。

会社立ち上げました

まず更新が止まった頃から今までで一番でかいイベントがこれです。勤めていたUI/UXデザイン会社のohakoを辞め、独立しました。独立した理由や会社についてのご紹介については別エントリーで書きますが簡潔にまとめると、すでにwebデザインやUIデザイン・情報アーキテクチャ(IA)といったデザインプロセスの一部分だけを担当するという事が少なくなってきた為、より広義な意味でのDESIGNを実行する為、UI/UX専業を謳う組織に在籍するのは不適切と判断したので独立したという流れです。このブログのURL(ドメイン)が地味に変わっていることに気付いた方は多分居ないと思いますが、ENTAKU(エンタク)という会社です。どうぞよろしくお願い致します。

ブログ名について

次にブログ名を変えた理由ですが、これは単純にネタが古くなったからです。とあるシリーズが流行ったのってもう8年前なんですね・・・で、今回のブログ名ですが、当ブログの記事を書くときはだいたい一杯引っ掛けてるので『酔いどれデザイン日誌』にしてみました。「企画屋」や「UX」を外した意図としては、実務を進めていく中ですでにUXデザインすらも狭義的な概念だなと感じるようになったため、より広義の意味で「デザイン」のみにしたかったというのが大きいです。「企画屋」については、実行に移せない(企画までしかしない)デザイナーはクソという想いが強くなってきた為外しました。略称についてはなんとなくDDDにしたかったので・・・深い意味はないです。

当ブログの立ち位置について

はてなブログproを利用している関係上、URLがENTAKUのサブドメインになっていますが、当ブログの立ち位置は名称変更前と変わらず私個人の思想や研究についての備忘録です。ENTAKUという組織全体としてのブログではないのでご留意下さい。

以上、ブログ名変更 & URL変更のご挨拶でした。どれくらい更新できるかわかりませんが、この1年書きたかった事は山ほどありますのでちょっとずつ書いていきたいと思います。今後ともどうぞよろしくお願い致します。

ウェアラブルに適したアプリとは?ちょっと未来のIoT-UXデザイン

UI UX アプリデザイン ウェアラブル IoT

先日参加したアプリ開発者向けセミナーのあとに他社エンジニアやデザイナーの方と話した「AppleWatchをはじめとしたウェアラブル端末に適したアプリとはどんなものか?」という議論が面白かったので、個人的な考え方を備忘録的に残しておきたいと思います。今はまだもの珍しさが先行するウェアラブル端末界ですが、使い方とアイデア次第では爆発的な革命を起こりそうな予感がしてます。

目次

ウェアラブルにしか出来ない事と、スマホでも出来る事

AppleWatchが発売されると同時に有名サービスのアプリが多数リリースされましたが、中にはスマホアプリの機能をほぼそのままウォッチの画面に最適化して表示しただけ、といったようなものもあるように感じました。では、スマホとウェアラブル端末で、本質的にはどこが違っているのか?というのを考えてみました。

予期的UXの観測が可能になる

まずスマホとウェアラブル端末の最大の違いは、その「常駐性」にあると思います。スマホは常時電源オンと言ってもポケットやカバンの中に突っ込まれている事がほとんどで、利用者の肌に常に触れているということはありません。ウェアラブル端末がウェアラブルたる最大の理由は、利用者が常に身に着けているという一点に尽きます。これにより何が可能になるかというと、スマホでは画面を見ている間のUX、「利用中UX」しかコントロールできないのに対し、ウェアラブル端末であれば利用者がアプリに触れる前から触れるまでの体験、「予期的UX」を観測する事が可能となり、コントロールできるUXの軸が大幅に拡張されたことになるのです。これは地味なようで革命的な可能性を秘めています。例えば、IoT技術と融合することでオフィスの社員全員がウェアラブル端末を装着して体温と発汗量をモニタリングし、室温・湿度が不快領域であるという予期的なUXを観測する事で空調を自動調節する、などの体験の提供が容易に可能になるのです。

ウェアラブル端末同士のIoT

スマホとウェアラブル端末が異なる点の2つ目は、スマホは何台持っても「たくさんのスマホ」であるのに対して、ウェアラブル端末は装着部位に応じて相乗効果を引き出す事が可能という事が挙げられます。例えば、(販売終了してしまいましたが)GoogleGlassのようなメガネ型のウェアラブル端末とAppleWatchのような腕時計型のウェアラブル端末をIoTで組み合わせる事で、視覚と触覚を直結させる事が可能になります。これの何が革新的かというと、受信機兼発信機でしかなかったスマホでは達成できなかった人間の感覚野の拡張が容易に可能になるという事です。たとえば、GoogleGlassのようなメガネ型端末を、後頭部側にかけてみましょう。すると物体が背後に近づいた事を手首に付けた時計型端末でフィードバックできるようになります。利用者の視界が疑似的に360°に拡張されるのです。自動車運転時の居眠り防止にもこういったIoTは生かせるかもしれません。使い方次第ですが、感覚を拡張するためのウェアラブル端末同士のIoTには大きな可能性があると個人的には考えています。

操作を必要としないUXのデザイン

これまでもスマホの音声コントロールであったりKinectのモーションコントロールであったり、直接的な操作を必要としないインターフェースは存在していました。しかしウェアラブル端末は上記で挙げたような特性から使用者を常にモニタリングし続け、自発的にアクションを起こす事が出来るという大きな強みがあります。これが具体的にどのようなシーンで活かせるか?というのは以前寄稿した記事のこの部分で解説しました。

ステータスをモニタリングしていると、具体的にどんな事が出来るか?というと、例えば急病で突然あなたが倒れた時。スマートフォンを常に肌身はなさず携帯していたとしても、自分で救急車を呼ぶ事が出来ない状態であれば意味がありませんよね。しかし、AppleWatchのようなバイタリティをモニタリングするウェアラブルデバイスを装着していた場合、 デバイス自体が状況を判断し、自らを操作してアクションを起こすことが可能になります。
Appleはついに、人間とデバイスの間にあった「操作」という関係性すらも、ユーザー体験として切り離してしまったのです。
(出典:UI/UX JAPAN)

このようにアプリに対するUXデザインの考え方から「操作」という部分が完全に切り離され、純粋なUXとして提供する事が可能になりました。「UIの操作」を必要とするデバイスは、本質的にいくら小型で携帯性があったとしてもウェアラブルデバイスとは異なるものなのです。

ウェアラブル端末に適したアプリとは

まとめとして冒頭で示した「AppleWatchをはじめとしたウェアラブル端末に適したアプリとはどんなものか?」という議論の結論を述べると、

  • 利用者の状況のモニタリングが必要であるもの
  • 利用者の五感に直結した拡張性を提供するもの
  • 直接的な操作を必ずしも必要としないもの

この3点に集約されると私は考えています。逆にこの3点のどれも必要としないアプリであれば、それはスマホアプリとしてリリースした方が良いという事になります。ウェアラブル端末の世界はまだまだ一般層に浸透し始めたばかりの黎明期ですが、この大きな可能性を秘めた転換期をうまく活用していきたいですね。

ユーザー中心設計の解釈について

UX 人間中心設計 考え方
  • 【要約すると】
  • ユーザーに質問しても「答え」は返ってこない
  • 「何故?」を徹底追及するのがUXデザイナー
  • より質の良い仮説を生み出す為には街に出るべき

「ユーザー中心設計とは、ユーザーの求めるものを提供するための設計である。」 ←この文章に違和感を感じなかった方、どうか最後まで読んで行ってください。もしかしたら大きな機会損失をしているかもしれません。

申し遅れました、UXディレクターのおりです。現在はオハコ(OHAKO-inc)という、日本では珍しくUXデザインを専門に扱うスタートアップ的な会社で働いてます。

私のほうは先日、HCD-Net認定の人間中心設計スペシャリストとなった訳なのですが、人間中心設計もしくはユーザー中心設計というものについて、時折「んん?」と首を捻る解釈をしているものを見かけるので、例を挙げつつ考えていきたいと思います。

ユーザー中心設計の認識として最も多くの誤解を生んでいるであろう部分は、以下の部分です。

UCDでは、まずユーザーとそのタスクや目標について様々な質問を行い、その答えを使って開発と設計に関する判断を行う。

(出典:Wikipedia ユーザー中心設計:目的)

これは、質問によって出てきたユーザーの意見を参考として思考し、デザインせよ。という意味なのですが、時折ユーザーが言っている通りの物を提供すれば良いという解釈でデザインされたものを見かけるのです。「ユーザー思考を中心とした設計」と「ユーザーが求めているものを作る」は、似ているようで全く異なります。どういうことでしょうか?

目次

ユーザーは自分の求めるものをうまく言語化できない

皆さんはデザインって何だと思いますか?私は、思考だと思っています。思考の無いプロダクトやサービスは、ただの偶発的な産物にすぎず、それをデザインや設計とは呼べません。

冒頭で示したユーザー中心設計の手法の一つ「質問」について、最も愚かな例を挙げます。

あなたはこれ(サービスやプロダクト)がどうなっていて欲しいですか?

飽きれてしまいますよね。でも、こういう質問が実際行われています。それも名だたる有名企業のアンケート調査などで日常的にです。それを集計してパーセンテージを算出し、円グラフや棒グラフにまとめたプレゼン資料が作成され、「今、ターゲット層に最も需要のある要素はこれです。」と言ってしまうドヤ顔の担当者が存在することによって、日本の経済は回っているのです。

もっと身近な例にたとえましょう。あなたは部長です。辞表を提出してきた部下に対して「あなたは何故、会社を辞めるんですか?」と聞いて、本当の答えが返ってくると思いますか?そんなわけありませんよね。しかしここで着目すべきは、言い辛い理由が無くても、本人が何故?というのを具体的な言語として表せない事が存外多いという点です。

普段デザインをしていると感覚が鈍りがちですが、一般企業に勤め、ごく普通のサラリーマン生活をしている人たちにとって「何故?」を考えるというのは、意外と難しい事なのです。そして、その「何故?」を彼らの代わりに考え、ソリューションとして提供するのが我々デザイナー、特にUXデザイナーという専門職の人達の役割でもあるのです。

「痴漢抑止シール」に見るダメなユーザー中心設計

先日、埼玉県警が画期的と自負する痴漢対策の秘密兵器を発表しました。「痴漢抑止シール」です。

痴漢犯罪の撲滅を掲げる県警鉄道警察隊が「チカン抑止シール」を作成し、無料で配布する活動を進めている。携帯電話などに簡単に貼ることができ、痴漢に対する強い警戒心をアピールできるメリットがある。「怖くて声が出せない」などという痴漢被害者の声を基に、女性隊員が中心となって考案した。沢登真珠枝・同隊長は「痴漢防止への意識が高まれば」と効果に期待を寄せる。

(出典:朝日新聞デジタル)

このシール、見せる事で声を出さずに相手に警戒心を伝えることが出来、更には直接「スタンプ」する事で動かぬ証拠を残せるといった代物だそうなのですが・・・そうです。これが冒頭で挙げていた「んん?」と首を捻ってしまうようなプロダクトです。

私はこれをダメなユーザー中心設計の典型例として挙げさせて頂きます。埼玉県警さん、遺憾であればご連絡ください。もっと良いもの考案させて頂きます。

この痴漢抑止シール、女性隊員らが中心になって考案したそうなので、恐らくはユーザー中心設計を意識しての事だと思いますが、やり方が完全に間違っています。

記事を見る限りでは「怖くて声が出せなかった」という意見が痴漢被害者のアンケートで最も多かったのでしょうが、「じゃあ声を出さないでもヤメテって言えるものがあればいいよね。」というのは、あまりに短絡的すぎませんか。しかもよく見ると2009年に作られた痴漢撃退シールという製品のアイデアをそのまま流用しており、6年経ったのに全く進歩していません。

被害者たちは、なにが「怖かった」のでしょう?声が出せないほど怖い何かって、何でしょう?この「何故?」の思考が、このプロダクトからはごっそり欠落してしまっています

私は、被害者女性たちは「追い詰められた犯人がどういった反撃をしてくるのか分からないという怖さ」があったのではないかと推測しています。そうです、仮説です。でもこの仮説が真実だとしたら?相手に痴漢するなという意思を伝えてしまってはいけないという事になりますよね。だって、密室で相手を追い詰めるような意思を示してしまったら、その後刺されたり、逆ギレされたり、降りた拍子に暴力を振るわれるかもしれないですからね。

別のパターンで考えると、「もし万が一この人が故意じゃなかったら私が声を上げると人ひとりの人生を破壊する事になる。ならばちょっとの間自分が我慢しよう。」という、良い人ならではの怖さがあったのかもしれません。これも仮説です。ただ、仮説はどこから導き出されましたか?私は今、満員電車での体験という自分自身の経験と、「怖くて声が出せない」というアンケート結果の一部のみでこの仮説を導き出しました。この導き出すプロセスこそが、UCDです。顕在化したニーズを元に、自分に置き換えて思考し、潜在的・本質的なニーズを導き出す思考法です。決して、顕在化したニーズをそのまま形にする事ではありません。

もっというと、痴漢されてしまうようなオシャレや美について敏感な若い女性が、自らの半身であるスマホに痴漢抑止シールなど、貼るでしょうか?さらに満員電車でいちいちシールを剥がして相手に押し付けるといった所作が可能でしょうか?周りの関係ない人にもインクが付着しませんでしょうか?ターゲットユーザーや利用シーンが全く想定されていないと言わざるを得ません。ユーザー中心設計は、ユーザーの奴隷ではありませんし、ユーザーにとって最も心地よい体験を提供するための設計でなくてはならないのです

したがってこの記事の冒頭で違和感を問いかけた、「ユーザー中心設計とは、ユーザーの求めるものを提供するための設計である。」という文章は、正しくは「ユーザー中心設計とは、ユーザーの求めるものが何であるか考え、調査・仮説・検証の上で提供するための設計である。」です。これだけの違いですが、最終的には大きな違いになってしまいます。

UXデザイナーはユーザー視点のストックを増やすべき

上の例で私は自分の経験則を元に仮説を立てると言いましたが、このような発言をするとアカデミックなユーザー中心設計を嗜む方々から反発があるのではないかと思います。そういった人達には私は必ずこの一言を投げかけます。「勉強会やセミナーの会場に、ユーザーは居ますか?」と。

ユーザーエクスペリエンスデザインは、最も現場に近いデザイン思考です。優秀なアナリストを抱えてしまうと、とかく正確なデータが上がってきますので数字にとらわれてしまいがちですが、数字はあくまで参考資料です。ユーザー体験の世界において、数字は答えにはなり得ません。

「○○という機能に 満足 と答えたユーザーは80%を超えた。」よくありますよね。でもどうなんでしょう?回答してくれてるユーザーがそもそも満足度の高いユーザーだけなのでは?という見方もできますよね。全てはユーザー側の主観によるものの結果でしかなく、いかなる数字も仮説の域を出ません。であれば、無機質なデータから得られる仮説よりも、街に出て実際にサービスに触れている人達を観察しながら思慮した仮説の方が、数段イケてると思いませんか。もっと言うと、その感覚を以て、優秀なアナリストの出したデータを紐解いていけば、「最高の体験を生み出す仮説」が出来ると思いませんか?

何度も言いますが、ユーザーに質問しても「答え」は返ってきません。ユーザーのくれた顕在化したニーズ(ヒントの山)から潜在ニーズを探り、解決策を導き出し、仮説としてユーザーにフィードバックを行うのがUXデザイナーであるべきだと考えています。ただの御用聞き営業なんて誰でもできるのです。あなたは、専門家でしょう?

私は、UXデザイナーはもっと街に出るべきだと思います。色々な人と話し、仲良くなりましょう。多様なユーザーの潜在的なニーズを解決するには、そうやって「ユーザー視点」のストックを増やす必要があるのではないでしょうか。

勉強会や交流会に意欲的に参加するのも良いですが、たまには週末、田舎のおばあちゃんたちが何を考えてどういった価値観で生きているのか、触れあってきてはどうでしょう。きっと見えなかったものが見えるようになると思いますよ。