私は仕事の中で、優れた開発者経験がプロジェクトの成功に大きく寄与していることを知りました。この記事では、デザイナーとしてプロジェクトに貢献するヒントを紹介します。
私は、スウェーデンのストックホルムでUXデザイナー、フロントエンド開発者として８年間働いています。これまでに参加したプロジェクトを振り返ってみると、すばらしいユーザー体験を提供することができたプロジェクトには、いつも優れた開発者体験がありました。一方で、開発者を無視したプロジェクトでは、期待された体験が得られないことが多かったのです。
少し単純化しすぎかもしれませんが、開発者体験（DX=Developer Experience）は開発者のユーザー体験であると言えます。
「開発者体験」という言葉は珍しくありませんが、相応の注目を集められておらず、相応に好かれてもいないと私は感じています。素晴らしい開発者体験のためには力を合わせる必要があります。このような開発者体験に対して、デザイナーは確実に貢献して、多くの場面でチームメンバーを助けられるでしょう。
批判を前向きに受け止める
新しいプロジェクトを始めるときは、チームと協力しやすいよう、ツールや方法を調整することに前向きになるべきです。それによって、好ましい第一印象を与え、チームワークに積極的に臨んでいることを示すことができます。プロジェクトを通して（短期的なフィードバックの段階などで）ツールや方法について定期的にフィードバックセッションを設けるといいでしょう。
開発者からのフィードバックを、ユーザーからのフィードバックと同じように扱って、協力して用いるツールや方法を改善しましょう。
成果物を作成して共有するためのツールや方法について、具体的なフィードバックを求めてください。もし今のツールや方法が以前のプロジェクトで役に立っていたとしても、改良の余地はつねにあります。開発者からのフィードバックを通じて改善する習慣をつけましょう。
たとえチームメンバーが新しいことを試したくなくても、彼らの言いなりにはならないでください。たとえば、うまく機能することが多かったツールの長所について議論して、InVisionで作ったクリック可能なプロトタイプや、Zeplinで出力したスタイルガイドなどを示しましょう。関わった人たちがどこで考えが変わるかはわからないものです。
コードをいくつか覚える
デザイナーはコーディングすべきでしょうか？ この問題は、ここ数年デザインコミュニティで多くの議論を湧き起こしています。
私の考えでは、基本的なフロントエンド開発を理解することには、次のような長所があります。
- すぐれたデザイナーになるために必須ではありませんが、理解していればデザインの習熟は早くなるでしょう
- すでに優秀なデザイナーなら、さらにスキルを向上できます
- 開発者体験に貢献するためには不可欠です
フロントエンド開発スキルを磨いて主要なデザインスキルを向上させたければ、「A Book Apart」シリーズが出発点として最適です。
少し私の話をします。６年以上前、私はまだフロントエンドWeb開発者としてクライアントの仕事を請け負っていました。あるクライアントのプロジェクトで、私はフロントエンドWeb開発について文字通りまったく知識のないアートディレクターと同じチームでした。彼が知識を持たず、チームに対して好ましくない態度をとっていたせいで、プロジェクトとチームの士気は損なわれてしまったのです。
たとえば、このアートディレクターは、以下のようなことをしていました。
- 開発者と同席して一緒に問題を解決することが１度もなかった
- 何百枚もの（名前すらついていないことも多い）レイヤーに分かれた乱雑なPhotoshopファイルを送ってきた
- 不十分なコントラスト、小さすぎるテキストといった基本的なアクセシビリティの問題すら理解せず、意識してもいなかった
- デザインや成果物に対して批判的なフィードバックがあるときに不快な態度を示した
- 私たちのデスクトップパソコンのモニターが、彼のMacbook ProのRetinaディスプレイのようにフォントを滑らかに表示していないと、私たちを非難した
これらのエピソードから、私はコードをいくつか覚えれば、開発者と協力する際に、肯定的なトリクルダウン効果が得られると考えます。たとえば、デザイナーがコーディングを覚えれば、次のようなことができるようになります。
- 複雑な問題を解決するプログラミングの性質をもっと尊重するようになる
- 技術的な可能性や限界への理解が深まる
- より詳細で優れたデザインの成果物を生み出せる
- 開発者への理解が深まり、彼らから敬意を払われる
- チーム内で自分の重要度が増す
コードを勉強する気になれないなら、開発者がデザインを実装している間、ときおり隣に座らせてもらうよう頼みましょう。開発者の働き方を見て、メモを取り、思いついた疑問を聞いてください。
この点について、デザイナーとコーディングについてのJared Spool氏のTwitterの投稿をかならず読んでください。
Digital designers who can code will deliver better designs to their teams than those who can’t. https://t.co/JuLn9OQ0Eq
— Jared Spool (@jmspool) April 20, 2018
コードが書けないデジタルデザイナーよりもコードが書けるデザイナーのほうがより良いデザインをチームにもたらすことができる
開発者と一緒に仕事をする
もしあなたがインターネットで一部の人々が言っていることを信じているなら、開発者はデザイナーのことを好ましく思っていないし、デザイナーも同じだという印象を抱いているかもしれません。
私はデザイナーとして、どのプロジェクトでもこのような隔たりを経験したことはありません。その理由は、私が最初から何でも受け入れる積極的な態度を示していたからだと信じています（もしかしたら非常に幸運だったからかもしれません）。
数年前、私はとあるクライアントのもとで、きわめてスキルの高い開発者と仕事をしました。そこには、その開発者たちと数年間一緒に仕事をしたフルタイムのデザイナーが２人いました。このデザイナーたちとは気持ち良く取引できましたが、彼らは開発者と協力することにはあまり時間を割きませんでした。彼らは自分たちの部屋で過ごし、忠実度が非常に高いスケッチをチームに手渡すだけしかしませんでした。チームに問題が生じたり質問されたりしたときには、いつも面倒がっていました。
私のアプローチはまったく異なります。私は開発者の隣に座ってデザインプロセスに巻き込みました。週に何度かの打ち合わせを設けて、一緒に紙にワイヤフレームを描き、ホワイトボードにスケッチを描きながら問題点や可能性について話し合いました。
開発者たちはこのアプローチを生産的で、斬新で、特にスケッチは楽しいと感じていました。その内の２人は、このように仲間に含めてもらえて非常に高く評価されていると感じたと、個人的に教えてくれました。
わかりやすくタスクの詳細を書く
多くの人は、未処理の案件や現在のタスクを記録し続けるために、おそらくJiraやTrelloなどのソフトウェアを使っていると思います。こういったツールは便利ですが、書き方が未熟で、タスクの説明が不明瞭なものを毎週のように読まされると、チームメンバーの活力やモチベーションはすぐに失われてしまうかもしれません。
すべてTrelloのカードを上手く書くことは、読んだ開発者の活力やモチベーションを少し高めるため、長期的に見れば重要であると私は確信しています。
JiraやTrelloといったツールは、タスクが上手く書き込まれている場合に限って効果的です。
私がよくTrelloのカードに書くのは以下のようなことです。
- １. 手元のタスクの背景情報
- ２. 解決すべき問題の詳細情報
- ３. ユーザー体験がどのように改善される可能性が高いか
- ４. デザインの変更内容（デザインリソースへのリンクを付けることが多い）
- ５. 発生しそうな障害やペインポイント
注意すべきこととして、パラグラフを長くしすぎず、小見出しや箇条書きを適切に使って読みやすくしましょう。Trelloのカードを開いたら巨大なテキストの壁に直面したい人はいないはずです。
チームメンバーの仕事に興味を示す
開発者は、自分たちの仕事に耳を傾け、興味を持つ人を好みます。このような開発者体験の社会的側面は、優れたデザインの成果物を作ることや、モチベーションが上がるようタスクを詳しく書くこと、デザインプロセスに開発者を参加させること以外にもあります。
ときにはランチやコーヒータイムに開発者に以下のようなことを質問するようにしてください。
- プロジェクトで使っているAPIや、使おうとしているAPIの可能性と限界
- 開発環境のセットアップ（どのエディタを使っているのか、なぜ使っているかなど）
- フロントエンドのフレームワーク（React、Vue、Material-UIなど）についての意見
- 前年に習得した新しいスキルやツール
- 定期的に直面している開発上の問題
- 自分たちの製品についてもっと知ってほしいこと
- 欲しいと思っているソフトウェア
開発者もデザインついて質問してくるかもしれません。私の経験上は絶対質問してくるはずです。
まとめと参考記事
優れた開発者体験を作り、維持するには、経営者やチームのさまざまなメンバーの協力が必要です。デザイナーがプレッシャーを感じすぎるべきではありませんが、貢献できることは間違いなくたくさんあるでしょう。
開発者体験についてさらに学びたい場合は、デザイナーが開発者と協力する部分以外の体験について論じている以下の記事をおすすめします。
- Developer experience (DX) – devs are people too（Justin Baker氏）
- The best practices for a great developer experience (DX)（Sam Jarman氏）
- Top 12 things that destroy developer productivity（John Lafleur氏）
