エンジニアの視点を学ぶ

デザイナーとエンジニアは仕事の仕方も考え方も異なります。しかし、良い製品をつくるためにはお互いの協力が欠かせません。考え方が違うからといってそのままにしておくと、品質の低下に繋がることがあります。

「デザイナーはユーザー(人)の声や行動に耳を傾けるべき」「彼らのニーズに合わせた提案や設計をすべき」といった論調を見かけることがありますが、これはユーザーだけでなく、一緒に仕事するエンジニアにも適応できます。すぐ側にいるエンジニアを考慮した提案ができないのであれば、ユーザー相手はもっと難しいと思います。

今でも仕事でビジュアルデザインを担当することがありますが、エンジニアと仕事をする際に以下の 6 点に気をつけています。

1. どういうタイプのエンジニアか知る

すべてのエンジニアがデザインに興味があるとは限りません。中には仕様を指示してもらえればそれで良いといった方もいます。しかし、エンジニアが全員デザインに興味がないわけではなく、アイデアやモックを積極的に作る方もいます。エンジニアそれぞれ考えがあって仕事しているわけですから、無理に変えようとすることはありません。デザインに興味がないのに全員参加のデザインプロセスに巻き込むことはありません。(興味をもってもらうための啓蒙活動は、別プロジェクトとして実践するべき)

2. 開発環境やツールを知る

エンジニアが使う開発環境やツールも、彼らを理解するためのヒントになります。円滑なコミュニケーションを実現するためには、開発環境に合わせてデザイン成果物を用意する必要があります。「自分が慣れているから」という理由だけで、Dropbox にファイルを放り込んでいては全体の効率は上がりません。エンジニアがコミットしてデプロイするまでのプロセスを知ることで、どのタイミングでどのような形状の成果物が適しているかを考えるヒントになります。彼らのプロセスに合わせた共有のための相談をすると、良いアドバイスがもらえることもあります。

3. 様々な形状を試す

どのような見た目の成果物が適しているのかは、相手にしているエンジニアと状況によって異なります。アニメーションひとつにしても、KeynotePixateAfter Effects といった複数のツールを使い分けています。もちろん、表現したい形を実現しているアプリを見せたり、手描きのスケッチで済むこともありますが、ひとつの表現方法では伝える幅が狭いことがあります。特に表層的な静止画を見ても理解できない今だからこそ様々な道具を使って、相手が理解・実装しやすい表現を模索する必要があります。

4. 少しだけコードを書く

アプリでもWebサイトでも、中身はコードです。仕組みを理解してデザインしているとしていないとでは、実装の際に大きな差が生まれます。もちろんエンジニアと一緒に機能開発することはありませんし、コードをマスターする必要もありません。例えば角丸の大きさを調整するといったことであれば、Webサイトであれば CSS、Android アプリであれば XML ファイルを編集するだけで可能です。デザイナーがコーディングに参加するためにも、Git のサブモジュールをつくるなどといった準備が必要になります。ただ、こうしたデザインの詳細をデザイナーが受け持つことで製品の質だけでなく、エンジニアからの信頼を得ることになるでしょう。

5. 早く見せる

エンジニアの仕事を1日追うと気付くのが、とにかく早いこと。その日にできあがったコードを何度もテスト環境で確認したり、数回コードをコミットすることがあります。スピーディな開発のなか、デザイナーがひとりだけ「3日後に何か出します」では完全にサイクルからはみ出たかたちになります。その日のうちに出す方法はあるか? 1時間後に出す術をもっているか?どの部分の質を(一時的に)落とすことでスピードが上げることができるか? 今の段階で伝わっていなければならないことは何か? こうした質問に応えることが、デザインのスピードを上げるキッカケになります。未完成品が開発プロセス参加のチケットです。

6. フィードバックを受け付ける

自分が試したデザイン成果物が開発プロセスの改善につながったかどうか聞くようにしています。やってはみたけど、うまくいかなかった。かえってプロセスを遅らせてしまうこともあります。その原因は何なのか、どのような成果物が好まれるのかは相手によって異なります。エンジニアもこうしたコミュニケーションの溝について悩んでいることも少なくありません。プロセスの改善はデザイナーをはじめ、参加している全員のもつ課題。一緒に受け持って考えることで、環境に合った最適な答えを見つけることができるはずです。