「アクティブ数が増えない」 「コンバージョン率が悪い」 「リリースした〇〇が使われない」 「オンボーディングがうまくできていない」 デジタルプロダクトの改善する際に取り上げられるフレーズたち。これらのフレーズが多くの会話やアイデア発散の起点となることがあります。しかし、これらはすべて課題ではなく、症状です。「アクティブ数が増えない」のは、開発陣の行動やステークホルダーの判断の結果（症状）であり、課題そのものではありません。真の課題を特定するためには、「なぜアクティブ数が増えなかったのか？」という深掘りする問いかけが必要となります。 単に「アクティブ数が増えない」という症状だけを見て対策を立てるのは、医者が具体的な診断をせずに治療を始めるのと似ています。このアプローチで一時的な改善が見られることもあるかもしれませんが、真の原因を突き止めずにアプローチをすると、その結果から学ぶことは少ないでし

限定的な課題解決になる受身のデザインデザイナーは良くも悪くも、来た依頼に対して最大限の努力をする方が多いと思います。「〇〇の見た目を良くしてほしい」「△△を使いやすくしてほしい」といった課題を解決するには高いスキルと経験が必要ですから、専門家としての価値は出せるはずです。最初は来た依頼に対して解決策を提供する活動でも十分ですが、やることが決まった段階から始めるデザインは制約が多いだけでなく、限定的な解決にしかならない場合があります。 例えば、記事に紐づけるコメントリストをスレッド式に変えたいという要望が来たとします。やるコトが決まった状態からデザイナーが入ると、どうしても「見やすいスレッド」「返信しやすい UI」を考えて作ることが目的になります。 依頼に答えるデザイン活動も重要ですが、これを続けているとデザイナーの仕事が次第に限定的になり、付加価値を提供するという受身の立場になりがちです。

デザインにもある『負債』 作ってから指標を考えるのではなく、何を計測すべきか事前に決めたほうがデザインがしやすくなります。作る目的がハッキリしますし、目的に沿った デザインフィードバックができるのもメリットです。 プロダクト / サービスの成長のためには、適切な指標をもつことが必須です。しかし、すべての施策が計測できるわけではないのが悩ましいところです。例えば「ボタンの一貫性を整える」といった施策に取り組んだところで、クリック率は上がらないですし、ユーザーテストをしても判断が難しい場合があります。 だったらすぐにユーザーインパクトのある施策をしたほうが良いということになって後回しになりがち。こうした『しっかり考えて作ったほうが良いけど、優先順位が落とされてしまう施策』はたくさん眠っています。他にも大事なことがあるのは間違いありませんが、放置しておくとだんだんプロダクトの『負債』が溜まってい

楽しみながら上手くなれる ゲームは緊張感や派手な演出をテンポ良く見せるのが体験設計に欠かせませんが、アプリだと操作の邪魔にならない体験設計をしたほうが良いとされています。違うところはあるものの、アプリの UX を考える上で、ゲームデザインが参考になることが多々あります。 「おもしろい」のゲームデザイン の著者である Raph Koster さんは、「おもしろいは、学習の別名である」と言っているように、おもしろいゲームには遊びながら複雑なことができる学習ループがあります。スーパーマリオのステージ 1-1 は散々研究されている名ステージですが、任天堂が作るゲームは基礎を教え込むゲームデザインが優れているのが特徴です。 スーパーマリオ64 のインタビュー で、宮本氏は「まず最初に基礎を固め、次に時間と野心が許す限り、そのコアコンセプトの最大化に力を注ぎます」と語っています。プレーヤー（ユーザー）

誰でも「負け戦」は経験している デザイナーであればユーザーにとって価値のある何かを作りたいと思うはずです。しかし、仕事では思うようにいかないことがあるのも事実。「これは絶対にダメだ」と思うことでもやらなければいけない場合があると思います。 例えばこんな状況で何かを作らなければいけない場合があるとします。 企画側で作りたいものが明確に決まっている デザイナーからみるとユーザーのためになっていない施策だというのが分かる 代わりの案を作ってみたが「こんなのは頼んでいない」と言われる 簡単な調査をして別提案を作り「ユーザーはこちらに反応している」と説明しても　No と言われる 開発なら分かってもらえると思って提案するものの「これを作るために、予定より 3 ヶ月かかる」と言われる 誰に何を言っても通じない状況。 締め切りはもちろんあるので、仕方なく要件を飲んで作ることになるでしょう。妥協したくない。

私たちはベストプラクティス好き セミナーの質疑応答で「ベストプラクティスは何か？」と聞かれることがあります。 文脈によって正しさや評価が変わることがあるデザインですから、成功率が高い手法が知りたくなる気持ちは理解できます。 Web 上でも人気になる情報には、必ずといって良いほど『定番』『10選』『抑えておきたい』といったフレーズを添えてベストプラクティスと呼べる手段が紹介されています。 有名企業が実践しているから。RT や Like がたくさんあって人気だからという理由で「ベストプラクティスだから上手くいく」と考えがちです。模索・失敗を繰り返さなければ良いデザインは生まれないと語られるものの、「失敗したくない」「成功の近道を知りたい」と思ってしまうのが本心なのかもしれません。 1966年に「Hofling Hospital Experiment」という社会実験が行われました。この実験は、私

分析で価値が変わる ユーザー調査（ユーザーリサーチ）は始めるのも実施するのも大変ですが、分析するのも楽なことではありません。せっかく調査してもログがあるだけでは意味がありません。ユーザーの言葉を引用してポスターやスライドで見せるのは啓蒙目的であれば良いですが、本当に必要なのは次の開発へ繋げるための判断材料です。分析でユーザー調査の価値が決まるところがあるので、次へ繋げるためにも分析は欠かせないところになります。 分析もデザインと一緒でツールの使い方を覚えたり、綺麗なレポートの事例を見ただけでは上達しません。基本を覚えた上で、何度か実践を繰り返すことで少しずつ上達していくものです。定性調査でも定量調査でもつかえる分析の第一歩になるポイントを押さえておけば、レポートの質もグッと上がります。 目的を明確にすること 分析をする前に重要になるのが、調査の目的を明確にすること。分析手段を知っていても、

何でも屋が増えてもスケールしない「UXが付く肩書きがもつ不安感 」という記事で、UX デザイナーが『何でも屋』になっているのでは？という疑問を投げかけました。ひとりのデザイナーとして様々な分野に関わりたいと思うものの、UX の文脈で求められるスキルと知識の幅は広いので、すべてをカバーするのが極めて難しいです。また、ひとりですべてを抱え込むと、組織が求める品質とスピードに応えることができない場合があります。 初期は複数の役割を受け持つことになりますが、プロダクトと組織が成長していかなければいけないときも同じように何でも携わるというやり方が適しているとは限りません。専門性を伸ばしていくことでより高度な提案とアウトプットができますし、互いの弱みを補いながらチームとして動く意味も増していきます。 デザイナーをひとりしか雇えない環境では数多くの分野に精通している人のほうが良いですが、そういう人ばかり

メリットがメリットにならないとき 「〇〇は古いから新しい△△のほうが良い」 「今は△△であるべきなのに、なぜ変えないのか」 自分が信じるやり方への想いが強いと上記のような論調になりがちですが、残念ながらこうした言い回しで「よし、では変えてみよう」と思う方はほとんどいません。例えば「web デザインで Photoshop を使うより、XD をはじめとした他のツールの方が良い」と言って新しいツールのメリットを伝えることがありますが、あまり効果的ではないと思っています。 今までのやり方より新しい手段のほうが良い、といった伝え方には下記の問題があると思っています。 故意ではなくても相手を否定しているように聞こえてしまう 伝えている本人にとって得するようにしか聞こえない 結局、従来のやり方がその人にとって楽 メリットを伝える時、ツール・手法・プロセスにおけるメリットを伝えるのは単にスペック（仕様）に

2018年9月8日 builderscon tokyo 2018 （#builderscon）に登壇しました。様々なタイプのエンジニアが集まる大イベント。エンジニア寄りの話ばかりの中でデザインの話をしてきました。とはいっても、直球のデザインの話をしても面白くないと思ったので「デザイナーとうまく協働する方法」というコミュニケーションについて今やっているコトと今後の課題について話しました。 職種を超えた言語共有の難しさ ニュアンスだけでなく言葉ですら捉え方は様々です。デザイナーの間でさえ「デザイン」という言葉から思い浮かべる職域や働き方が微妙に異なります。「プロダクトのあるべき姿」であればなおさらです。人によって「良い」の定義が異なれば、優先順位も微妙に変わります。 こうした課題を解決すべく、言語化・視覚化があちこちで行われています。ペルソナを作るのもひとつですし、プロトタイプも方向性を共有す

外向的な方が多い仕事現場 デザイナー以外の方たちへデザインを伝えるには、あやふやな表現の言語化がスタートになりますが、「ハキハキと前へ出て話をしましょう」という意味ではありません。一歩前に出て意見を述べることができる外向的な性格であれば良いですが、誰もがそうではありません。内向的な人が無理な行動をしてもかえって負担になるだけでなく、伝えるべきコトが伝わらない場合があります。 声が大きい人が多い場所、明らかに立場が上な人たちと意見交換をするのは至難の業。リモートでの情報共有はさらに難易度が上がります。ニュアンスをはじめとした非言語コミュニケーションが共有されていないと、どんどん取り残されてしまいます。内向的な方にガンガン攻めていきましょうというのは酷ですが、内向的であることを言い訳にして伝えることをしないのも良くありません。 思ったことをドンドン口にする人との会話は難しい。 自分のペースを設

UIデザインにもあるバグ 今年の WWDC 2019 で印象に残っているセッションのひとつが「Introducing SwiftUI: Building Your First App 」。SwiftUI は開発がよりスマートにできるようになるだけでなく、デザインツールの新しい可能性を示しているように見えました。SwiftUI はとてもエキサイティングですが、個人的に刺さったのが上の写真。改めて意訳した図を作りました。 UI デザインは単に理想型を作れば良いのではなく、様々な状態（ステート, State）を考慮する必要があります。情報量に応じてどう見せるかだけでなく、様々な種類のエラーにどう対応するか考えなければいけません。How to fix a bad user interface で紹介されている UI Stacks のように、少なくとも 5 つのスクリーンデザインが必要になります。

難易度が高過ぎな海外事例 Web で公開されているデザインシステムは、インスピレーションにはなりますが、最初に目指すものとして相応しくない場合があります。好例として紹介される Salesforce の Lightning Design System が最初に GItHub にデプロイされたのが 2015年の9月。プロジェクトが始まったのはもっと前だと思うので 4 年くらい続けているはずです。Salesforce で働くデザイナーの数は分かりませんが、 LinkedIn で調べると 300 名以上のデザイナーが検索結果に表示されます。 少なくとも 300 名のデザイナーが働いている組織が 4 年くらいかけて作っているものと同等なものは作れません。欧米の事例は「自分たちでツールを作ることもあります」と言うような大規模組織が多いことから、参考にならない場合があります。 ひとまず原則や色から始める

先日、帰省した際に母と家電量販店を訪れました。そこで、いろいろな製品を見学したり質問に応えながら雑談していたわけですが、母が興味深い言葉を残していました。 「私とあなたではシンプルの意味合いが違う」 例えば Apple TV は、TVに接続するとパソコンからメディアをストリーミングしてくれるだけでなく、TV番組や映画、YouTube も見れるようになります。録画して残すという考えから、クラウドを利用してオンデマンドでいつでも好きな時間に見るこという考えに変わります。何が出来るのかを理解しているのであれば 1台で様々な役割を果たす Apple TV のようなデバイスは便利でシンプルです。 しかし、1台で何でも出来るということがシンプルにならない場合があります。使い方によって様々なメディア体験ができる Apple TV より、録画・観覧するためのデッキ、ケーブルTVをみるためのチャンネル、ゲー

コラボレーションは難しい コラボレーションは今日のデザインプロセスにおいて必須です。様々な分野の専門家たちが集まるからこそ、より良い製品へと進化していきます。専門家だからこそ出せるインプットによって、最適な解決策が見つかる … はずなのですが、実際そうはいかないことがあります。立場が違えば、物事の捉え方も違います。それぞれが置かれている状況によって、意見が分かれることがあります。意見が一致すればコラボレーションとしての相乗効果が生まれますが、そうでないときは、不平や妥協する人が出てくるでしょうし、最悪の場合は製品の利用体験を損なうものを実装してしまうこともあります。 コラボレーションは響きの良い言葉ですが、一筋縄にはいきません。意見が合わないとき、私たちはよく自己防衛の姿勢になりがちです。「これは違う」と言われると、反射的に「そんなことはない」と言うことがありますが、こうしたやりとりがコラ

今までも何度か デザインシステム に関する記事を書いてきましたが、手段や考え方が中心でした。今回はプロセスに注目して、代表的な課題を図にしてみました。すべてのケースに当てはまるわけではないですが、参考にしてください。 大まかな進め方 「デザインシステムを作りました！」とドカンと発表したほうがインパクトがあるように見えますが、苦労したわりには誰も使わないものになる可能性が高いです。実際はデザインシステムの中にあるものを小さく切り出して少しずつ変えていくことになります。 正攻法であればデザイン原則から始めたほうが良いと思っていますが、組織としてどうあるべきかといった根本的なところが明文化されていないのであれば、そこからスタートしたほうが良いでしょう。デザイン原則があったほうがデザインの議論がしやすくなるので早期にもっておきたいですが、1 日でも早く成果を出したいのであれば、まず色からはじめてみ

デザインツールのもうひとつの未来 「次世代デザインツールはどこへ向かうのか（後編）」で、デザインプロセスはよりチームスポーツのようになると書きました。デザインツールはより開発との連携がしやすくなり、より実装を考慮したデザインがしやすくなるのでは？と仮説しました。しかし、デザインと実装の溝がなくなることだけがデザインツールの未来の姿ではないと思います。 デザインツールにあるもうひとつの可能性が、ジェネレーティブデザイン（generative design）です。 ここでいう『ジェネレーティブ』とは、コンピューターアルゴリズムで何かを生成・構築するもの。ジェネレーティブアートであれば随分昔からあります。例えば Gerg Nees の Computergrafik は、コンピューターアルゴリズムによって作られたグラフィックアートを 1965 年に発表しています。最近だと Processing の

価値の説明が下手なデザイナーIBM の社長だったトーマス・J・ワトソン・ジュニアが「良いデザインは良いビジネスである」と言ったのが 1973 年。最近だと Design in Tech Report 2017 (PDF) のなかで、 デザインは見た目の美しさだけでなく市場に合うものを作り成果を出すものとし、ビジネスと密接な関係にあるものとしています。今も昔もデザインはビジネスにおいて重要なポジションにあるべきだと言われていますが、未だにあちこちで『説明・説得』があるということは、うまく伝わっていないのかもしれません。 私は価値が伝わりにくいというより、価値の伝え方が上手くないではと考えています。ここで言う「伝える」とは、ただ言葉にするだけでなく体系化も含まれています。 プロセスと価値が結びついていないUX やデザイン思考のような言葉がビジネスシーンでも流行したことで、見た目が良いものを作る

ようこそ、ブラックミラーへ ユーザーデータは今のデザインに欠かせない存在です。レコメンデーションや操作の省略など、ユーザー体験の向上に役立っています。また、デザインを提案するときもデータがあるとないとでは説得力が違います。 「ユーザーのため」と耳障りの良い言葉を添えてユーザーデータを集めた先には何があるのでしょうか。それは本当にユーザーのためになっているのでしょうか。Google 社員向けに作られた「The Selfish Ledger」というビデオがユーザーデータを集めた先の世界を描いています。 2016年に作られたこのビデオは Google のプロダクトビジョンを描いたものではなく、Google のデザイナーの教育向けに作られたそうです。このビデオで描かれている世界を目指すべきなのか、それとも別の道や考え方を模索すべきなのか。見る人によって様々な意見が生まれそうです。 ビデオでは全人類

メンタルモデルから始めるデザインする上でユーザーのメンタルモデルの理解は欠かせません。 UI やコンテンツに出くわしたとき、それをどう解釈・判断し行動するかを決めるのがメンタルモデル。 Web サイトであれば青色の文字に下線が入っていればリンクであると判断するのも、過去の経験や知識を基にメンタルモデルが築かれているからです。私たちが「使いやすい」「直感的」と感じるのもメンタルモデルとインタラクションが一致しているからと言えます。 同じデザインでも評価は変わるデザインをチームで評価するとき、メンタルモデルが共有されていないために議論が思わぬ方向へ進む場合があります。Web サイトのリンクのように広く使われているものであれば共通のメンタルモデルが築かれていますが、多くの場合そうでははありません。オンボーディング、アイコンの見た目、通知のコピーなど、UI に関わるあらゆる部分で意見の相違が発生し