駆け出しプロダクトデザイナーがエンジニアとの開発で学んだ５つの教訓

どうもこんにちは。株式会社アトラエでエンゲージメント解析ツールWevox（ウィボックス）のプロダクトデザイナーをしているLuluです。昨年10月にアトラエに入社し、早５ヶ月が過ぎました。

入社してから1ヶ月程度、私はWevoxのモーダル等の小さいデザインからデザイナーとしてのキャリアをスタートさせました。BtoB SaaS のプロダクトをデザインするのは、初めてだったので、最初の一ヶ月はドメイン知識をインプットする事が大変だったことを覚えています。

ちょうど入社して一ヶ月半ほど経過した頃、デザイナーの先輩からWevoxのRbac(権限管理システム)のデザインをやってみないかと声をかけてもらい、入社して1ヶ月半程度で、プロダクトの新規機能のUIデザインを任せてもらいました。

今回は、私がアトラエで初めてエンジニアと一緒にチームで担当したRbacのプロジェクトを通して学んだ教訓についてまとめたいと思います。

学んだこと①デザイナーだけで作ったデザインは何度でもひっくり返る

今回のプロジェクトを通して一番に学んだことは自分がデザインしたUIはエンジニアと開発(スプリントする)中で何回でもひっくり返るということです。

私はエンジニアにデザインを渡す前に２ヶ月間、自分なりに綿密にユーザーフローを作成し、ユーザーのアンチパターンの洗いだしをしたり、エンジニアに渡す時にはもうほぼ完璧の状態で渡せるようデザインを用意していました。

ところが実際にエンジニアとのスプリントが始まると、デザインの揺れ、バックエンドとのデータの兼ね合いからデザインが何回も変更し、最終的なデザインはスプリントをしていく中で変わって行きました。

今振り返ると、この過程でデザインが洗練されていったことは間違いないのですが、何回も変わっていくデザインに最初は戸惑いました。

デザインはエンジニアとのスプリントの中で、何回もひっくり返るというのを前提に、臨機応変に対応することの大切さを学びました。

学んだこと②エンジニアとデザインという共通言語を持つ大切さ

次に私が学んだのはエンジニアと共通言語を持つ大切さです。ここで言う共通言語はプロトタイプ、正確なユーザーフロー図の事を指します。

私はHTMLやCSSなどのマークアップ言語は書けますが、フロントエンドやバックエンドの言語はほぼわかりません。(今後は積極的に学びたい。。)なので、プロジェクトの初期段階で、APIやデータベースの紐づき方が今ひとつピンと来なくて、エンジニアとのコミュニケーションがうまくいかない時もありました。完全に経験不足でしかないのですが、だからと言って止まって泣いているわけにもいきません。そんなときに私がエンジニアとプロジェクトをすすめる上でのコミュニケーションを助けてくれたのが、自分がデザインしたユーザーフロー、プロトタイプです。プログラミングがわからなくても大枠のAPIの繋がりがわかれば後はUIフローを見せながら、説明できます。

解析度の高い正確なUIフロー図はエンジニアとの共通言語であり、その精度が正確であるほど、またプロトタイプがより実装に近いものであるほど自分の考えをより視覚的に説明し、チームでのコミュニケーションをより円滑に運ぶ事ができます。

今後のPJでもUIフロー図の作成、プロトタイプはエンジニアとの共通言語として積極的に活用していきたいなと思いました。

学んだこと③デザイナーの仕事の半分はコミュニケーションかもしれない

事業会社のデザイナーって実際どんなデザイナーなのだろう？その答えがこの半年弱でわかった気がします。デザイナーになる前はデザイナーって毎日figmaでもくもくとデザインしているイメージがありましたが、今はちょっと違います。

私はこのPJが始まって、エンジニアと実装に入るまで、Figmaをいじるのと同じぐらいの時間をビジネスサイドとエンジニアサイドとのUIデザインの対話に費やしてきました。

主にビジネスサイドとコミュニケーションをとった内容としては

・ボタンやモーダルのUI上の文言の確認：ユーザーにわかりやすい言葉を使っているかどうか。

・ユーザーフロー、プロトタイプの流れで、使いにくさはないか。

エンジニアととったコミュニケーションの内容としては、

・アンチパターンを理解してもらう事：アンチパターンを事前にFigmaで図解して説明する事によって、なぜこのデザインなのかを説明する。

自分はプロダクト開発チームに所属していますが、感覚的にはビジネスサイドとエンジニアサイドの中立にたって、ユーザーにとっても、実装にもハッピーエンドになるように落とし所を考える事が事業会社で働くデザイナーの使命なのだなと実感しています。

学んだこと④自分とデザインのアウトプットをデタッチする。

エンジニアとスプリントを開始していざ実装に入っていくという事は、自分が広げた"デザイン"という風呂敷をたたみにいくという事でもあります。

エンジニアにとってはデザイナーが広げた風呂敷を畳む、つまり現実的に実装可能かどうかを判断し、実装する事が仕事です。

正直、この畳むという段階は多くのデザイナーにとって楽しい時間ではないと思います。自分のデザインが称賛される事はなく(問題なければそのまま実装され)、もし、実装する上でデザインに問題があればつっこまれて、指摘される事を繰り返す時間です。

自分が丹精込めて作ったデザインが指摘される事は時にチクッと刺されるような心の痛みを感じました。プロダクトが実装され、ユーザーの手に届くまでに、これは必要なプロセスです。しかし、デザイナー１人、エンジニア3人という私のチーム構成上、必要以上に矢面に立たされているような感覚を感じてしまっていたのだと思います。

そんな時、先輩デザイナーから、自分とアウトプットをデタッチする事をアドバイスしてもらいました。

Takramメソッドのひとつ「デタッチメントとアタッチメント」。「人間は自分のアイデアを愛する」というバイアスの理解からがスタートです。 pic.twitter.com/8jQTQg09Qn

— 田川欣哉 / Takram (@_tagawa) May 1, 2017

私は自分が数ヶ月かけてデザインしたUIに愛着を持ちすぎてしまったために、デザインの指摘を受ける度に自分の人格、考え方、能力すべてが否定されているような気持ちになっていた事に気づきました。

デザイナーが作ったデザインをもとに、より良いものをユーザーに届けるためにみんながフィードバックをしてくれているのに、その事を先輩に教えてもらうまで気づく事ができませんでした。

正直、今でも作品と自分のデタッチが完璧にできるわけではないですが、自分がデザイナーとして開発に携わるで非常に大切なスキルだと思うで、アドバイスしてくださった先輩には感謝です。

学んだこと⑤継続すること、やりきることの大切さ

当たり前な事ですが、大きな事を成し遂げるには時間がかかります。駆け出しならなおさらです。エンジニアに渡せるデザインを作成するのにも時間はかかりますし、リリースできるプロダクトのデザインを作るのは本当に大変な事だと実感してます。

ただ、千里の道も1歩からだと思うので、毎日少しずつでも進んでいけたらと思います。

最後に

これからまだまだリリースに向けて解決しなければならない課題はたくさんありますが、一つひとつ解決し、リリースに向けてあともうひと踏ん張り頑張りたいと思います！

入社して初めて取り組んだプロジェクトである”Rbac”を通してたくさんの事を学ぶ事ができました。いつも支えてくれるチームメンバー、デザインチームメンバーのみんなには本当に感謝です。

アトラエでは、裁量の大きく、ダイナミックなプロジェクトを通して成長する環境があります。

興味がある人は是非、下からコーポレートサイト、採用サイトを覗いて見てください。

株式会社Atrae - Atrae, Inc.

‎Apple Podcast内のDesign Square