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

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

積み上げられた結果だけを見ているという事実デザイナーは漠然としたアイデアから、見たり触ることができるモノが作れる人たちです。デザイナーだけではありませんが、作る仕事をしている人は、その作るためのスキルを磨くことが最も重要だと考えると思います。しかし、あまりに重要視することでデザイナーが本来しなければならない、もうひとつの仕事を怠ってしまうことがあります。 デザイナーの仕事は「作れる」だけでなく「話せる」ことも含まれています。しかし、デザイナーが自分のデザインを言語化できない人があまりにも多いと思います。デザイン批評について書き始めたのは 5 年前に遡りますが、当時の日本のデザイン関連の話題で足りていない部分と思ったのがキッカケです。また、「UX だ！」と高らかに宣言したところで、話すことができなれば何も前進しないと考えたからです。 UX デザインプロセスには、ペルソナ、カスタマージャーニー

明文化をテーマにしていた2016年 今年の初めデザイン SDK のようなものが欲しいという記事を書きました。開発者から提案されているフロントエンド寄りのスタイルガイドはコードの品質管理と、見た目の再現性を高める上で有効な手段です。しかし、これだとコードを理解していることがスタイルガイドの利用・関与の大前提になります。すべてのデザインがコードから始まるとは限らないですし、デザイナーであれば Sketch や Photoshop といった日々使うツールを活用して最低限の品質を保つ手段が必要になります。 共通言語を作っていく。 これは文字通り言葉だけでなく、UI を始めた視覚的な部分など、今まで好みや感覚で済ませていたこともきちんと言葉にすることも指しています。デザイン批評も共通言語を作り上げるために必要なプロセスです。 建築家クリストファー・アレグザンダーの著書「Pattern Languag

調査という行為は日常では当たり前 車や家など高い買い物をするとき、値段や見た目だけで買うことはないと思います。専門家や信頼できる知人に相談することがありますし、書籍やインターネットで情報収集することもあります。買う前に調査するのも「失敗したくない」「自分にとって最良なものが欲しい」という欲求があるからでしょう。値段が高いのであればなおさらです。 購入前の調査は車や家のような高い買い物だけではありません。食事、書籍、服など数千円のものでも調査をすることがあります。インターネットのおかげで情報と近くなったことから、あらゆることが調査しやすくなったかもしれません。 高い買い物であれば調査は必ずするといっても過言ではありませんが、web サイトやアプリ開発になるとそうでもなかったりします。高い買い物をしているにも関わらず調査をしないところが今もありますし、定量調査はするものの、ユーザーの声を聞くと

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

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

うまくハマらないユーザー調査 ユーザー調査という言葉を聞くと、どういうイメージを頭に思い浮かべますか？ 数週間のインタビューと観察。実施するための入念な準備期間。数十ページにも及ぶ調査レポートなどを想像する人は少なくありません。本格的な調査が必要な場合はありますが、早く動かなければならないプロダクト開発の文脈では現実味がありません。例えば以下の理由で調査をしない（できていない）現場をたまに見かけます。 アジャイルのような早いサイクルで成果物を作り続けるプロセスに、調査がうまくマッチしない場合がある 特にスクラム開発は調査・デザインとの相性が悪い場合がある プロセスに調査ができる人が参加していない場合がある 時間とお金がかかるというイメージが強すぎて手が付けられない 調査・プロダクト開発それぞれがもつ有益な情報が見えにくい 調査には「長くじっくり実施して、きちんとしたレポートを作る」という先

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

結果だけでなく過程も 途中経過を見せることはデザインへの誤解が生じると考える人はいるかもしれません。また、途中経過は『企業秘密』だから見せるべきではないと考える人もいるでしょう。そもそも恥ずかしいから見せたくない人も少なくありません。自分も最初は恥ずかしかったですし、そもそも途中経過は見せる必要ないと思っていたほうでした。 しかし、今は途中経過を見せなければ良いデザインが生まれないと考えるようになりました。手描きのものから、インタラクションがあるものまで様々な形状を作っては見せています。仕事現場だけでなく、Twitter や Instagram のような場でも見せることもありますし、このブログにしてもデザインにおける途中経過を文章として表していることが多いです。 完成されたモノをどう作るかというノウハウも重要ですが、デザインという『よく分からないもの』が生まれるまでのプロセスを見せるほうに

実装を考えながら作れなかった従来のツール 6年前になりますが、 web のデザインは枠のない世界であると説明したことがあります。様々なスクリーンサイズのことを考慮して作らなければならないと頭で分かっていても、デザインツールでそれを実現するのが困難でした。10年以上大きな変化がなかったデザインツールに対して、実装側はどんどん進化し続けていました。Web だとフロントエンド技術とワークフローに大きな進展がありましたし、ネイティブアプリも　1　年おきに OS と周りの開発環境がアップグレードしています。 開発は目まぐるしいスピードで変化しているのに対して、デザイン環境は大きく変わっていなかったことが、今私たちが抱えているデザインと開発の溝の根源ではないかと考えています。2010年代はデザインツールの革命期と呼んでも良いくらい様々なデザインツールが出てきていますが、今まで遅れていた分を取り戻そうと

次世代デザインツールはどこへ向かうのか　前編 次世代デザインツールはどこへ向かうのか　中編 デザインをスケールさせていく デザインツールの現在と未来を考えたとき、デザインシステムの存在は無視できません。今のデザインツールはデザインシステムの作成・運用に最適化するための機能実装がされています。 一貫性のあるデザインの作りやすさ コンポーネント（部品）として捉えた UI の管理 複数人のデザイナーによるプロダクトデザインの運用 コードへの書き出しなどエンジニアとの連携 ひとりのデザイナーに頼るのではなく、組織でデザインを運用していくためにデザインシステムのニーズが高まってきています。欧米ではここ数年でデザイナーとエンジニアの比率が小さくなってきている状況をみても、デザインが個人プレーからチームプレーになってきているのが分かります。 大企業でデザイナーの雇用（又はデザイン会社の買収）が増えていた

広がるデザインツールの役割 2016年はデザインツールのあり方が大きく変わった年でした。スマートフォンが主流になってから、平面な画面をひとつひとつ設計するのではなく、利用者の遷移や UI フィードバックを塾考するようになりました。多彩なデザインツールが出てきているのは、デザイナーの作り方だけでなく、役割も少し変わってきているからでしょう。ひとりの職人が閉じ籠って完成品に近いものを作るのではなく、デザインプロセスを共有しながら少しずつ作るというやり方に変わりつつあります。デザインのブラックボックス化を避けるための手段は今も増え続けています。 従来のデザインツールは、ひとりのデザイナーがデザインに集中するための道具であって、途中経過を共有したり、協力して作ることを得意としていませんでした。現在のデザインツールは複数のデザイナーがひとつのプロジェクトに取り組めるような仕組みが用意されていたり、デ

部品から設計することに慣れる デザインツールとして Sketch や Figma を推している理由のひとつにシンボルがあります。Adobe CC ライブラリのアセット管理とは異なり、デザインした部品（コンポーネント）を拡張したり組み合わせることができるのが魅力。様々なスクリーンサイズに耐えられるように作るのはもちろん、デザインを運用していくには、部品からしっかりデザインできるのはこれからのツールでは必須です。 コードが書ける人、コードを書く思考が分かる人であれば、部品から作ってレゴブロックのように積み上げるという Atomic Design 的な考え方は当然と思えるでしょう。なので、デザインシステムを作りましょうという考えに至りますが、画面の全体像から徐々にディテールを作るやり方でデザインしていた人には難しかったりします。いきなり部品から作ることに慣れていないですし、マクロ（画面全体）とミ

言葉で決まるアプリの印象 2 年前に発表されて以来、細かな更新が続いている Material Design。最近、UI の動きに関するガイドが大幅に改変されたことで、感覚的なところも共有しやすくなってきました。Android アプリにおける UI デザインの基礎を固める上で、Material Design は非常に参考になりますが、このガイドラインは見た目のことばかり書かれているわけではありません。 Material Design の中には「Writing」と呼ばれる言葉遣いに関する項目があります。ボタンのような操作 UI のラベルはもちろん、エラーメッセージや、挨拶文など、アプリに表示されるテキストすべてに関してガイドラインが制定されています。言葉は大事なインターフェイスですから、きちんと項目をつくって紹介してあるのは素晴らしいことです。 以下、「Writing」項目で紹介されているガイ

Design, Content, Experience

小さなパッケージとしてのカード 前回の記事で、メッセージのやりとりという文脈にカード UI が組合わさることで、新たな利用者体験を提供できるのではないかという話をしました。コンテンツを『ページ』としてではなく、『小さなパッケージ』にして利用者に配信することが主流になりつつある現在。これは、Web 上の情報のあり方を再考せざるを得ないと同時に、利用者にとって理解しやすい（ページに代わる）メタファが必要とされているのだと思います。小さなパッケージの表現方法としてカード UI は、無視できないデザインパターンのひとつです。 カード UI の可能性を最初に感じたのは、2010 年に登場したPinterest。たくさんの画像を全面に出しつつ、概要や操作を統一感を持たせてコンパクトに表現しています。Pinterest がブレークした頃、無限スクロールや、隙間なく敷き詰めたグリッド表現が注目されました。

批判ではなく批評 個人プロジェクトでない限り、公開前に誰かにデザインを見せる機会があると思います。相手はクライアントかもしれませんし、同僚・上司なのかもしれません。デザイナーの中には見せるのを躊躇している方もいるのではないでしょうか。知恵とスキルを出し切って作り上げた子供のような存在なので、万が一批判されたのであれば自分自身も批判されているように感じるのではないでしょうか。IDEOの Time Brown 氏が TED の講演で「デザインはデザイナーだけに任せるには重要過ぎる」という言葉を残しているとおり、デザインを皆で考える機会を作るべきです。デザイナーは早い段階から他の誰かとアイデアを共有するべきですが、会話が批判的なものになりすぎているのであればデザイナーも積極的に参加もしてくれませんし、デザインを前提とした会話にはならないでしょう。 「この色は違う」「使いにくそうだ」「分かっていな

語るより見せたほうが早い スマートフォンをはじめとしたタッチデバイスが世の出回って 5 年以上経つわけですが、タッチ & ジェスチャーをどうすれば良いのか分からないことがあります。アプリによって右スワイプというシンプルな動作のフィードバックが異なりますし、特殊なジェスチャーで機能へアクセスできるものもあります。分断化するジェスチャー操作は随分昔からの課題ですが、最近ではユーザーのオンボーディング体験を通じて、操作を学習してもらうといった対策がなされているところもあります。 特殊な操作をユーザーに学習してもらうには、どのような表現が適しているのでしょうか。 従来は明確なテキストや、スクリーンショットを通して説明することが多かったですが、最近では動画が使われる機会が増えています。OS X で関心したのが「システム環境設定」のなかにあるトラックパッドの設定画面です。通知センターや、辞書で調べると