協働のためのデザイン思考の再構築

2016年9月3日HTML5 Conference 2016が開催されました。1,200 人を超える参加者。6トラック同時進行という巨大イベント。どちらかと言えばエンジニア向けのセッションが多いイベントですが、そういう場だからこそ「ぜひ話したい」と思えたところがあります。

今回「協働のためのデザイン思考の再構築」という題名で話しました。以前からエンジニアとデザイナーとの間をどう繋げるかという課題について話したいという欲求がありました。ただ、こういうトピックはデザイナーばかりの場で話すのは意味ないですし、逆もしかりです。HTML5 Conference 2016 は、デザイントラックもあったことから、両方へリーチするには好都合。幸いエンジニアの方も私のセッションに参加していただいたみたいで、非常に嬉しかったです。

デザインシステムの課題

私は HTML, CSS, JavaScript は書けますし、PHP も多少書けます。コードがある程度分かると、全体構成からではなく部品からデザインするという考え方はスッと入ってきます。スタイルガイドを作りましょうという声も、どちらかと言えばフロントエンド側ですし、世に出回っている CSS フレームワークを見てもコードの理解があることが大前提です。

Atomic Design が 3 年くらい前に登場して以来、『デザインのシステム化』が各地で実践されています。コンテンツを運用するだけでなく、デザインも運用をしなければならなくなってきた今日。「Web サイトは立ち上げてから本番です」という話は、運用側だけでなく、制作者にも課せられた課題になったわけです。これはアプリ開発にも同様で、バグフィックスといったシステム側だけでなく、持続的な UI 改善が求められています。

スピードや柔軟性はもちろん、誰が実装してもある程度の品質が担保できるシステムを作ることは、今後ますます重要になっていきますが、部品から作ることはデザイナーにとって難しいことがあります。

部品から徐々に積み上げるのではなく、全体構造からディテールを考える傾向があるデザイナー

コードが書けると、部品から作ってレゴブロックのように積み上げるという Atomic Design 的な考え方は当然と思えるかもしれませんが、デザイナーはどちらかと言うと全体から考える傾向にあります。大まかな構成、つまりレイアウトを考えてから少しずつ中にあるパーツを作り込んでいきます。 タイポグラフィ、ボタンといった最小単位の部品を作ってから、大きな構造を積み上げていくという考え方とはまったく逆の思考になります。

「部品を作りましょう」と指示しても手を動かせないデザイナーがいたとしても、それは才能がないからではなく、逆立ちして作れと言われているように聞こえるからだと思います。この思考のすれ違いが、エンジニアとデザイナーとの間に溝を作っているのではないでしょうか。これを放置したまま、ツールに頼ったとしても、それは小手先の解決にしかなりません。

デザイナーはコードを学ぶ。エンジニアはデザインの理解を深めるといった歩み寄りは必要です。ただ、それだけで上手くいくわけでもないですし、限界があります(全員フルスタックにはなれないですし)。同じ視点で、同じ思考順路で、アプリや Web サイトを使う人たちの問題解決ができるとしたら、作り方にも影響するのではないでしょうか。

オブジェクトから考える

Web サイトであれ、アプリであれ、リリース後も維持・管理が必要になるので、作っては壊す、新しいものを常に付け加えなければならない状況を避けなければいけません。そこでデザイナーも画面設計、もしくは画面遷移という全体像をいきなり描くのではなく、少しでも部品を意識できるような視覚化が必要だと考えています。

いきなり最小単位から始めても、他の要素とどう関係するのかハッキリしませんし、全体像も見えてきません。だからといってひとつひとつ画面を作ると、整合性がとれていなかったり、様々な状況に堪えられるデザインになっていないことがあります。そこで Web サイトやアプリという画面に表示される枠組みを考えるのではなく、ユーザーが触れる『オブジェクト』は何かを先に考えるようにします。

コンセプトによって変わるオブジェクトの構成や名称

例えばカメラアプリであれば、写真、撮影者というオブジェクトが存在するでしょうし、それぞれタグや名前といった要素が含まれるでしょう。利用者の頭の中に浮かび上がるモノ・コトの多くはオブジェクトとして捉えることができます。どのような言葉を使っているのか、物事をどのように見ているのかは枠組みを見つけるヒントになります。

こうしたスクリーンでの見た目から外れてオブジェクト設計するというやり方は、コンテンツモデルシングルカラム情報設計で実践していましたが、エンジニアとデザイナーが一緒に設計するときに最適だと思います。エンジニアはデータベース設計など元々こうした考え方をもっていますし、デザイナーも利用者視点という切り口からオブジェクトを考える良い機会になるはずです。

リミックスがWebの真髄

製品やサービスをオブジェクトとして捉えて全体像を視覚化し、ひとつひとつ言葉を合わせていきましょうという考え方は、エンジニアもデザイナーも注目しています。エンジニアからは Domain Driven Design(ドメイン駆動設計) 。デザイナーからはObject Oriented UX(オブジェクト指向UX)。呼び名だけでなく、ニュアンスも少し違いますが、オブジェクト(ドメインモデル)から考えるというアプローチはすごく似ています。

DDD も OOUX もまったく新しい概念というわけではなく、オブジェクト指向プログラミングから進化・派生したものです。新しい用語が増えることで誤解と混乱を招く可能性はありますが、今の時代に合わせて言い回しを変えるのは良いことだと思います。

今回の講演では、上記の考え方と合わせて、以前紹介したことがある Job to be done フレームワークを組み合わせた手法を提案しました。オブジェクトは製品・サービスのコンセプトによって様々な切り出し方ができます。設計しようとしているオブジェクトが正しいものか見極める際に、利用者の動機や結果を引き出すことができる Job to be done は有効です。これも随分前からある考え方ですが、オブジェクト指向と組み合わせることで、今までと少し違う角度からデザインを考えることができるのではと考えました。

ideas-associations

こうした現存のものを少し洗練させたり、別のものと組み合わせるのは Web らしいアプローチだと思います。世界中にいる優秀な方々がアイデアを出しているからこそ、「もしかすると、こんな組み合わせをすると面白いかもしれない」という別のアイデアが生まれる原動力になるわけです。今回の講演は、私のアイデアを真似してほしいというより、組み合わせや工夫次第で現場に合う答えを見つけることができるかもしれないということを伝えるのが目的でした。

教科書通りにやるのも良し。けど正攻法に固辞することないですし、ちょっとアレンジすることを恐れる必要はないわけです。それはデザインそのものにも言えますが、手段・手法にも言えます。

まとめ

物事を前へ進めることは簡単なことではありません。それぞれが分かったつもりにしないためにもデザイナーはデザインを説明できるようになるべきですが、言語化の課題はそこだけはありません。私たちが何気に言ってる UI の名称も、聞き手は違うものを考えている場合がありますし、開発だと、また違う名称へ変換しなければならないかもしれません。同じものを指しているのに、用語が違うばかりに通じない … ということを回避する必要があります。

ツールやワークフローも大事ですが、言葉という根本的なところが合っていないせいで複雑な進行になっていてはツールの力を最大限に活かせなくなります。部品から作ることを推奨する前に、部品が作りやすい構造設計と、言葉合わせが先です。そこにひとりひとりのデザイン思考の再構築があると思います。

Yasuhisa Hasegawa

Yasuhisa Hasegawa

Web やアプリのデザインを専門しているデザイナー。現在は組織でより良いデザインができるようプロセスや仕組の改善に力を入れています。ブログやポッドキャストなどのコンテンツ配信や講師業もしています。