サービスにおけるデザイナーとエンジニアの関わり方
デザイナーの林(＠taka_piya)です。弁護士ドットコムに入社して1年が経ち、今は新規サービスの設計とデザイン、フロントエンドの実装を担当しています。
12/18に弊社デザイン部が主催した 「DesignerMeetUp+#2 デザイナーとエンジニアの関わり方」でLTしてきました。今回は当日の内容...サービスを作る時に、デザイナーとエンジニアはどう関わればよいかという内容をまとめて記事にしようと思います。半分ポエムです。
要約
デザイナーとエンジニアはアウトプットが違うので、別々な物を作っていると思われがちです。
しかし実際は「①デザイナーとエンジニアは『情報』を表現しているプロダクトを作っている点は共通していて、②『情報』がわかるように翻訳する対象が、人間かコンピュータかの違い」なのではないかと考えています。
このスタンスに立つときあるべきか関わり方は「表現対象である「情報」の認識を職種関係なく揃えることからスタートすること」という話です。
はじめてUIをデザインしたときの自分の失敗
はじめて新規サービスに携わり、企画から設計、UIデザイン、フロントエンドの実装と担当してきました。今日はそのなかで1つの失敗を紹介します。
チームはPdM、エンジニア、デザイナー(自分)の3人でサービスを作っていますが、実装に入る前に
1. 課題仮説を出す解決されるストーリーを出す
2. ストーリが実現できるFigmaによるUIプロトタイプを作成
3. チーム内でフィードバック
サイクルを回しプロダクトのあるべき姿を探っていました。
このサイクルを導入した当初は、目に見えるアウトプット = プロトタイプを作るだけでチームの認識が揃っていくように感じ、順調に見えていました。
しかし、途中から何度プロトタイプを作っても認識が揃わなくなってきました。いつまでも議論が終わらないということがありました。。
いま振り返って見ると、UIを起点にコミュニケーションをしていたのでズレが生まれていたのだと気づきます。つまるところ原因は、自分が「UIデザイン = UIを作る」という認識でメンバーにコミュニケーションしたことです
例えば具体的には、DribbbleやPinterestとか、競合サービスのUIを参考にしていました。これはこの段階ですべきではありませんでした。これはスタイリングの参考にはなるのですが、その背景にある「なぜこのUIなのか？」までは自分たちのサービスには適用できないので、見た目以上の話ができないのです。
この失敗がなければもっと本質的な部分に議論の時間を裂けたと思うので本当にもったいないことしました。
プロダクトは「情報」を表現している
この失敗から、そもそもデザイナーは「UIで『何』をユーザに表現しているのか」、更にいうとエンジニアとデザイナーは協力して「プロダクトで『何』をユーザに表現しているのか」という疑問を抱きました。
答えとしては、プロダクトは「情報」を表現し、ユーザーに届けていると考えています。では情報を表現するとはどういうことか？「情報デザイン入門―インターネット時代の表現術」では情報デザインとして、このように定義されています。
身の回りにあふれるデータ、あるいはコンテンツに「まとまり」をつけ、そこに何らかの「秩序(文脈)」を与える
この定義を見て、エンジニアの方は「それってモデリングなのでは？」と思った方もいると思います。そうです。UIを作るもコードに落とし込むも、表現先が違うだけで、エンジニアもデザイナーも実際の出発点は同じなのです。
改めて失敗を見直してみる
自分の失敗はUIを起点にコミュニケーションを取ったことです。
このスタンスに立つと、「どう見えているか」が観点になります。すると、このUIをどう実装するのか？そもそもどういう情報構造なのか？というコミュニケーションになり、情報のパターン、実装が持つ振る舞い、UIのパターンが無限に生まれ発散してしまいます。そうするとデザイナーとエンジニアが別々に、同じようなことを考えなければならず、コミュニケーションロスが大きくなります。
あるべきだったデザイナーとエンジニアの関わり方
そうではなく「プロダクトは情報を表現する」スタンスに立つと、情報が伝わるか？ということが観点になります。情報の認識が揃っているので情報のパターンが一意になります。実装が持つ振る舞いも、UIも情報が伝わるか？という軸が生まれるので、コミュニケーションが取りやすくなります。
具体的にやったこと
「プロダクトは情報を表現する」というスタンスに立つともうやることは、みんなで情報の認識を揃えることと、それを実装することです。
①言葉を洗い出す
プロダクトでの肝となる「データのまとまり」を作り、名前をつけみんなで合意します。
ここでいうプロダクトの肝は、同じタスク管理ツールでもTrelloだと、ボード、リスト、カードだし、Todoistだとプロジェクトのようなものです。どのプロダクトにもキーとなる言葉がある思います。
②言葉の関係性を決める
そして洗い出した言葉同士はどういう構造を持っているのか合意します。
(Trelloだと、ボードはリストを、リストはカードを内包しています)
③それを表現する
ここで初めて職種が意味をなします。合意した言葉と関係性を、表せるようにエンジニア・デザイナーがそれぞれ人間がわかるようにUIや、コンピュータがわかるようにコードに翻訳します。
まとめ
デザイナー、エンジニアの越境が話題になっていますが、そもそも私達はプロダクトを通して「情報」を表現しているという出発点は同じです。
UIやコードから出発するのではなく、互いに情報は何か？を合意するところからスタートすることが、サービスを作る時にあるべきデザイナーとエンジニアの関わり方だと思います。
「情報」がエンジニア・デザイナーの共通の出発点であり、翻訳しているという認識を持てば、その関わり方は明らかになります。
コードを読めるようにする、UIデザインについて理解しようとする前に、この3つが意識することで、エンジニアとデザイナーの関わり方はスムーズになるのではないでしょうか。
参考
この記事が気に入ったらサポートをしてみませんか？