@hikrrr です！はじめまして、デザインを生業としています。ReactとTypeScriptが好きです。
デザイナー間の絶えぬ論争の1つ、コーディングする／しない問題。これに対する私見は「デジタル製品のデザイナーならぜひともコード書いていこうぜ！」です。よりよいインタラクションの実現に欠かせない行為・過程と信じています。
でも、”しない派”と言い争うつもりは毛頭ありません。実のところ、エンジニアの皆さんをUIデザインの世界にお誘いしたいと思っているからです（コード書いてますよね？）。今回のテーマである”インタラクションデザイン”には、エンジニアリングとの汽水域が存在します。だからこちらへどんどんと進出してきてほしい！そんな思いを綴りました。
読んでほしいひと
- デザインに興味のあるエンジニア
- 少数でMVP開発しているエンジニア
- コーディングする派のデザイナー
インタラクションデザインとは何か
インタラクションデザインについて、まずはおさらいしましょう。
Dan Safferは、著書『インタラクションデザインの教科書』において下記の通り説明しています。
インタラクションデザインは、製品やサービスを介して人と人がインタラクション（対話）することを手助けするための技術である。そしてまた、範囲を限定していえば、何らかの「認識力」を持つ製品と人間とのインタラクションに関するものであるともいえる。1)
1) Dan Saffer著. 吉岡いずみ訳. インタラクションデザインの教科書（電子版）. マイナビ出版, 2014, p.14.
着目すべきは対話である点でしょう。一方向の流れなら”inter- action / 相互の- 作用”と言えません。
例えば、Aが何かアクションしたときBがレスポンスを返す。そしてBのレスポンスによってAがどのような感情や知識を覚え、次にどのような行動をとるだろうか――
他者との関わりがもたらす変化に言及してこそ、インタラクションデザインの土俵に立つと考えます。狭義にも広義にもそれは変わりません。ふるまいが互いに及ぼす影響を設計する点で、アプリケーションの機能と社会的機能とのあいだに本質的な違いはないはずだからです。
UIにおけるパラダイムシフト
当記事では狭義的な解釈をもとに、ユーザと製品のインタラクションに着目します。
そこでは予測可能性・学習可能性がキーになるでしょう。ユーザは「こう操作するとこんな結果になるだろう」と予測し、「こう操作したらこんな結果になった」と学習します。アフォーダンスやUIデザインパターンを活用すると、そうした操作・結果の連関がユーザに伝わりやすくなるはずです。
一方、そのパラダイムは常に変化していきます。GUI 黎明期から過渡期にかけて台頭したスキューモーフィズム（下図・左）をいま見かけることはありません。またPull-to-Refreshが典型ですが、その出現以前にはなかったインターフェイスが支持を得る例もあります。新聞の紙面を引っ張ってもニュースは更新されませんよね。
発明をユーザが受け入れ、他の製品にも伝播し、社会に敷衍することで”定型”へと化す。そうしたある種の社会文化的な学び・認知も、インタラクションデザインの大変興味深いところです。
デザインエンジニアになろう！
そうしたパラダイムシフトを引き起こすのは、なかなか容易でないでしょう。しかし普段の開発で「ユーザと製品とはどのようにインタラクションするだろうか」と意識してみるだけでもおもしろいかもしれません。
3つのモデル
Alan Cooperは著書『About Face 3 インタラクションデザインの極意』にて、ソフトウェアデザインが対象とするモデルは3つ存在すると述べました。
- Mental Models: 脳内モデル。ユーザの考えるシステムの動き
- Represented Models: 表現モデル。UIとして目に見えるシステムの動き（他2つのモデルを媒介する）
- Implementation Models: 実装モデル。実際のシステムの動き
脳内モデルと表現モデルとが近くなるほど使いやすいシステムになります。実際にどう動いているかについて、大半のユーザの関心は高くありません。一方で、実装モデルと表現モデルを”開発プロセスとして”近づけることの効果は大きいと考えています。
製品もユーザを予測・学習する
冒頭で「コーディングこそ、よりよいインタラクションの実現に欠かせない行為・過程」と述べました。正確にはコーディングというより、”実装モデルへの解像度が高いこと”ですね。予測と学習の一連（インタラクション）をデザインするうえでそれは有利に働く、と考えています。
ユーザの感情や思考を操作することは不可能に近いですが、開発者側からもユーザに対して予測・学習することはできます。まさしく相互の作用です。エンジニアリングの視点からは、製品の”手札”を熟知していますよね（例：このオブジェクトはこの場合にどういう状態になって…）。それを表現モデルに落とし込むことができれば、ユーザの脳内モデルを捉える確度はより高まると言えます。
ホバーするとサイズが変わるとか選択するとアイテムの色が変わるとか、そうした“インタラクティブ“な挙動（どちらかと言えばビジュアルデザインに近い）のことを指しているわけではありません。情報を提示する流れや粒度などを設計する場で、エンジニアの皆さんからご意見いただけたらと思っています。例えば、概要表示 → 詳細表示するシーンで「フローごとに取得するデータはこう変化するから、モデルはこういう風に切り分けておけるね」といった具合です。
プロトタイピングの速度・精度を上げるために
figmaやAdobe XDなどを用いてモックをいくら造り込んでも、ユーザの手元で実際に動くことはありません。ソフトウェアの奥行き（ユーザが回遊する階層構造）を、紙芝居的な2次元へ押し込めることの限界もあるでしょう。デザインプロセスの試作・検証のループにおいて、モックではカバーできない部分がどうしても出てきます。
上記に対する私の考えは「UIデザインとフロントエンド開発の統合的スキルにより解決されうる」です。特にViewとStore周辺については、取り扱うオブジェクトを型宣言することで（UIデザインの基礎となる）情報設計がおおかた済んでしまう感覚があります。さらに宣言的UIのおかげで、コードベースでレイアウトすることも可能です。特に初期検証用のミニマムなプロダクトでは、学びを得るまでのリードタイムを短縮する効果を得られています。
一般に、デザインエンジニアの役割はいくつか挙げられます。デザインシステムの構築、デザイナー・エンジニア間の”通訳”などですね。その中でも私は、高速・高精度のプロトタイピングこそ特有の価値でないかと思っています！（ポジショントーク）
不動産とデザイン
私たちestieの取り組む不動産ドメインには、デザイン的に解きうる課題がたくさんあると思っています。人びとが立ち、生活・仕事を営む場所となっている”不動産”のポテンシャルを拓いて行けたら、よりよい社会の実現に近づくだろう。そう信じています。
反面、インタラクションデザインは危険を孕むものです。悪い意味で誰かと誰かのコミュニケーションを規定し、その関係性を変えてしまうかもしれません。いまある世界を破壊することなく好循環を生み出すのは時に困難を極めますが、めげずにやっていきたいものですね。
まとめ
- インタラクションデザインとは、二者のふるまいとそれが互いに及ぼす影響を設計する技術のこと
- エンジニアリング的な”実装モデル”の観点とデザイン的な”表現モデル”の観点を併せ持ち、それらを行き来することで開発のスピード・精度が上がる
- もしもUIのデザインに興味が湧いたら、プロトタイピングツールの習得に走るよりまずはインタラクションデザインの一端に触れてほしい！（偉そうにすみません）
最後に
デザインエンジニア組織をつくりたい思いでいっぱいです。
デザインに興味のあるエンジニアの方、エンジニアリングに興味のあるデザイナーの方は、ぜひカジュアル面談にいらしてください。
