フロントエンドエンジニアがデザイナーとの出会いと別れを経験したときの話

この記事は「エンジニアリングに興味があるデザイナー、デザインに興味があるエンジニア」の18日目のものです。

はじめに

私は現在事業会社でフロントエンドエンジニアとして働いています。フロントエンドエンジニアとして働き始めたのは今の会社からで、UIデザイナーとの協業も今回が初めての経験でした。
前職ではデザインが必要な場合があったとしてもそれは完全に外注で、デザイン資産は全て自身の至り知らぬところで完成していました。しかもその発注したデザインはメンテナンスを必要とするものではありませんでした。
しかし、今現在は成長するサービスに携わっているため、デザイン資産のメンテナンスは欠かせません。
今回はそのような成長段階にあるサービスの開発を担当していたときに起きた悲しい出来事を中心に振り返っていきたいと思います。
記事の中でデザイナーの業務内容について触れていますが、あくまで側から見た視点で語っているので、間違っている箇所があるかもしれませんが、ご了承ください。

開発チームにおけるUIデザイナー

まずUIデザイナーは、類似サービスについて調査し、プロダクトオーナーやその他のステークホルダーにインタビュー等を行います。プロダクトオーナーの要望や想定利用者のペルソナをもとに、利用者が目的を達成できるUIに落とし込みます。
デザイナーがUIに落とし込む作業の際、フロントエンドエンジニアも画面の最小サイズや使用するUIコンポーネント、CSSフレームワークの選定を一緒に行いました。
この過程でスタイルガイドなどのデザイン指針も成果物として上げてもらいました。
そして一通り必要な画面のデザインが出揃うと、一気にアプリUIの解像度が高くなります。ここまでは非常に順調でした。
続いてフロントエンドエンジニアは、上記で上がってきたデザインから実装に落とし込む作業に入ります。
ここでフロントエンドエンジニアは実際に手を動かして実装する中で、デザイナーが意図するものと実装内容のすり合わせを随時行います。
今回はエンジニア経験のあるデザイナーと協業していたので、ここでのコミュニケーションはかなりスムーズだったと思います。
開発の文脈をある程度把握してもらっている分変更に対応(許容)して頂いたと感じています。非常に有り難かったです。
思い返せば私はこのとき、デザイナーの優秀さに甘え、考えることを半ば放棄していたと思います。

デザイナーとの突然の別れ

その日は突然やってきました。
ある日、「ごめんなさい、辞めることになりました」というアナウンスがあり、チームからデザイナーが去ってしまいます。それからは代わりのデザイナーが現れるまではエンジニアがデザインをするしかない状況になってしまいました。
サービスの主要機能のデザインは未完成で、これから複雑な画面が待っているというタイミングでした。
タイミング自体は全く問題ではないのですが、社内調整がつかず私がデザイン業務に本腰を入れなければならなくなったのです。
その際、困ったことがたくさんありました。今回はその困ったことの一部を紹介します。

余白の決め方って…結局どうなってるんだっけ？

例えばタイトルと本文、ラベルとインプットの間のマージンはどれくらい取るべきなのか、という細かいところはスタイルガイドにも明文化されていませんでした。
これは地味に困る部分の一つでした。特に、サービス内で似たようなインターフェースがなく、新規で作成する際は何を基準に余白を取れば良いのかわからなかったのです。
一般的に使用されるタイトルとそこに続くコンテンツの余白やフォームの余白などはスタイルガイドに具体的な値を明記しておいた方が良いなと思いました。
根拠のない実装はモヤモヤするし、何より「どうしてこの余白なのか」と突っ込まれたときに論理的に説明できないという弱点があります。

統一感のない文言

ボタンのラベルを体言止めにする、しないだったりサービス特有の固有名詞だけは英語表記にする、などの表記ゆれに対する最低限のルールはデザインの初期段階で作成していただいていました。
しかし、開発が進むにつれ余裕のないスケジュールと共に文言の表記などの細かい箇所のレビューは大雑把になり、また複雑な表現も増えたことから、表記ゆれが見受けられるようになりました。
文言に関しても、ルールを随時更新、改訂していく必要があることは認識していましたが、当時は忙しさにかまけてこの工程をスルーしていました。

UI決定における主導権の所在不明

エンジニアがUIのデザインと実装を行い、プロダクトオーナーにレビューを依頼すると、デザインしたUIが覆るような意見が出ることが多々ありました。
デザインレビューの段階では通ったけど実装してモックの動きを見てもらうと「想像よりも〇〇だった」と言われることが増えたのです。
最初はその指摘に対して「じゃあ変えてみます」と安請け合いしていましたが、次第に違和感が生じるようになりました。
このとき一緒に働いていたプロダクトオーナーはUIデザインについての知識がそこまで豊富ではなかったのですが、「なんとなく違う」という曖昧な感覚値で意見を出されることがありました。
しかしエンジニア側がその意見に全て対応しようとすると、UIから一貫性が失われたり、特に重要でもない機能があたかも重要な機能かのように配置されてしまったりしてしまいます。
プロダクトオーナーが一番強い決定権を持っているプロジェクトの中で、このときフロントエンドエンジニアはUIに対する主導権を握れていませんでした。
そのためプロダクトオーナー含めたメンバーに対し、説得・納得させるという作業に時間を要するようになりました。UIデザイナーは（少なくとも当時のチーム内では）ここの説得的コミュニケーションの大部分を担ってくれていたということを実感しました。

私は何をするべきだったのか

プロジェクト初期段階におけるデザイナーとのコミュニケーション

デザイナーが一番手を動かすプロジェクトの初期フェーズの時点で、もっとコミュニケーションを取るべきだったという大きな反省がまず一つ挙げられます。
余白の設定における法則や、共通言語（ユビキタス言語）の定義をこの段階で一緒にやっておくべきだったと思います。特に共通言語の定義は、初期段階でなるべく細かく洗い出して定義しておくことで後の作業がかなり楽になると思います。
表記ゆれを後から修正する作業時間はとても不毛で悲しい時間でした。

説得的コミュニケーションの鍛錬

UIデザインを行うにあたり、他の画面と似通ったインターフェースだったとはいえ私もデザイン作業は不慣れでした。
それでもチームメンバーは皆UIに関するインプットは意識的に行っているメンバーだったので、メンバーが根拠を持って組み立てたUIに関して、ふんわりした意見に寄せて覆すべきではありませんでした。
感覚的な要望に左右されるべきではないのは当時も既にわかっていたことではあったので、私たちが相手にわかりやすく、かつ論理的に「このUIにした理由」をきちんと説明する義務があったと痛感しています。
善意によって「こうした方が良いんじゃないか」という意見をもらえるのはありがたいのですが、ボタンやリンクの位置一つとっても「なぜここに配置したのか」を考えてやっているので、それをしっかり伝えなければいけないと思いました。
ここに苦手意識を持つエンジニアは多そうだなと勝手に思っています。
これに関しては場数を踏む必要があると感じました。

まとめ

今回は、デザイナーとエンジニア、そしてステークホルダーとのコミュニケーションに焦点を置いた内容でした。
結果たくさんの反省点を思い出ししょんぼりしました。
全然エンジニアリングの話ができなかったのですが、改めて振り返ると初期フェーズの地盤固めの大切やコミュニケーションの鍛錬の必要性を実感しました。
チーム開発は必ず思い通りに進まないので、不測の事態に陥ったときに対応する力を養っていきたいですね！
デザインに興味があるので、うまく協業しデザイン業務をさらっと巻き取れるのが本当は理想的だなと思っています。
デザインできるようになりたい。