デザインの悲劇を減らすためのIA

2018年2月25日 18:03

良いプロダクトを組織として作っていくにはどうすればいいのか。

今回はユーザ価値を積み上げるためにはどんなプロセスを踏めばいいのか　というテーマで社内発表したことを書きたいと思います。

開発現場で頻発していた悲劇

僕はUI/UXデザインを始める前は開発サイドのPMだったのですが、プロダクト作りにおける悲劇はデザインだけでなく開発の現場でもよく起きています。

こういう話が本当にたくさんの現場で起きていました。SEがブラックだみたいなイメージがついたのはそのせいじゃないかなと。

こういった悲劇を打開するためにどうするかという話で、最初は「ちゃんと考えて作る意識を非エンジニアも持とう」みたいなことで設計にかける時間を増やそうとするんですけど、人間は神様じゃないので最初からすべてを想定した完璧な設計って不可能なんですね。

そういった中で、↓のような発想とプラクティスが生まれました。

実物を見る工程が１番最後のテスト工程しかないのが悪い

やっぱり、ものづくりは上流から下流に工程が進んでいくものなので、上流工程で認識がズレていたらそもそもアウトだし、上流のアウトプット品質がすべての質を左右するんですね。

そういったことに注目した結果、上流での認識齟齬に早く気付くための開発手法として「プロトタイピング」とか「アジャイル開発」が目立つようになっていきました。

僕は、UI/UXデザインと開発は「ものづくり」であるという点で、そこそこ似ていると思っています。

別の言い方をすると、「抽象的な要件から情報を積み上げて具体化していく」という工程が似ていると思います。

プロセスが似ているということは、同じような悲劇が起きやすいということでもあります。実際にデザイン現場で起きている悲劇として、こういうものがあります。

デザインする側からすれば「言ってること違うじゃん」という話なのですが、現実にはデザイン側は偉い人の言う方向で作り直しに応じざるをえない　ということがよく起きています。

開発とデザインで同じような悲劇が起きているなら、同じようにプロトタイピングで解決できるのではないか　と考えるのが自然ですが、残念ながらそう上手くはいかないのが現状です。

なぜ上手くいかないのかというと、「実物likeなもの先に作る」ということがデザインでは難しいからです。

UI/UXデザインでもプロトタイプとして操作イメージ等は共有しますが、あくまでそれは操作イメージであって、UIデザインやビジュアルデザインのアウトプットとして見るのは無理がある「ハリボテ」にすぎません。

プロトタイピングは開発の悲劇を減らす非常に優秀な手法であることに間違いありませんが、デザインの悲劇を解決するためには足りないということです。

特に、一般的なユーザ感覚だと、デザイン工程の根幹にある抽象的な部分よりも、最終工程であるビジュアルデザインやインタラクションの良し悪しが気になってしまうのですが、それは課題解決と関係ないので論点がズレてしまいがちという問題もあります。

デザイン現場で、上流工程での認識ズレを減らしたり、上流工程のアウトプット品質を高めるためには何をすればいいでしょうか。

開発の時は、それがプロトタイプでした。実物likeなプロトタイプを触りながら、みんなで「あーだこーだ」言ってブラッシュアップしていくことができました。

デザインでは、実物likeなものを先に作ることができません。デザイナーとノンデザイナーの間で、上流工程について会話できる新たなレイヤーが必要です。

僕は、それが情報設計（Information Architecture: IA）だと思います。

情報設計に対してフィードバックを受けたり、プロトタイプのA/B案を見せて情報設計の違いを説明したりしながら、ノンデザイナーと一緒にデザインの上流工程を詰めていく。

デザイナーは情報設計を説明しながら議論をリードする力を求められるし、ノンデザイナーはちゃんとプロダクトを情報設計レベルで理解して意見し、合意形成することを求められます。

↓こちらのスライドで、IAについて事例も入れた簡単な紹介をしているので興味を持っていただけた方は是非見てもらえると嬉しいです。

デザイナーとノンデザイナーの間で上流について会話できるレイヤーがない場合、デザイナーは自分をデスマーチから守るために会話を諦めて「流す」という選択をとらざるをえないケースもあるかと思います。

そういう場合、「とりあえず作って、何となくフィードバックもらって修正して・・というループを期限まで（あるいは目安的に3回くらいまで）繰り返して納品」というワークフローになってしまうかと思います。

これでは、いわゆる「理由のないデザイン」になってしまい価値が積み上がらないので、プロダクトをちゃんと作ってユーザに価値を届けたいと考えている場合は、早めに会社として舵を切った方がいいかと思います。

今回の話は社内で実施しているデザインLTの内容を抜粋しながら記事化したのですが、こういう話をしようと思った経緯や、LTで質問が出た内容の紹介などをこちらの記事で紹介しています。良かったら読んでいただけると嬉しいです。

それでは。

IAの話と切っても切れない話として、仮説検証について記事を書きました。

仮説検証における結果解釈の難しさと誤検知について書いています。チームでこのあたりについて認識が揃うと、とても強いチームになるんじゃないかなあと思うので是非読んでみてください。

最後まで読んでいただき、ありがとうございます。またタイミング見て記事を書くので良かったら見にきてください。