デザイナーとエンジニアの間には、古くから大きなギャップがありました。このギャップは、デザイナーとエンジニアがいつもお互いに対して苛立ったり、いがみあっていることから生まれています。というのも、デザイナーはエンジニアが自分たちのデザインしたものを認めていないと考えており、対してエンジニアはデザイナーが実装可能かどうかをきちんと理解していないと考えているのです。
しかし、今日(こんにち)エンジニアリングが主体の会社は、デザイン関連の人材をどんどん採用しています。つまり、私たちの最新の無料ポケットガイド『Building Mockups Developers Won’t Hate』で詳しく検証したように、今ではもっと互いに協力し合わなければいけないという独自の課題があるのです。
私たちは先日、QuantcastのUXデザイナーのリーダーであるJonathan Smiley氏と対談し、「エンジニアリング主体の会社をデザイン主体の会社に変えるには何が必要か?」ということについて話し合いました。その対談でのJonathan氏の話を紹介しましょう。
デザインはもはや「あったらいいな」というものではない
JonathanはQuantcastに入社する前、ZURBでパートナー兼デザイン主任として5年間働いていました。 ZURBで彼は McAfeeなどの多くの大企業とともに様々なデザインプロジェクトに携わってきました。また、オープンソースフレームワークであるFoundationの構築にも関わっていました。
他の多くのエンジニアリング主体の会社同様、Quantcastはサービスの寿命に対するデザインの重要性に気がついたため、現在彼はそこのデザイン部門のディレクションをしています。
「デザインを重視することは、単に差別化をはかるではないということに企業は気づき始めています」とJonathanはUXPinに語りました。
2014年に行われた調査によると、デザインを重視してきた企業は徐々に業績を伸ばしています。研究者によると、これらの企業は2012~2013年の間に299パーセントの成長率を実現しました。研究者は、調査についてこのように述べています:
優れたデザインは、製品やサービスをより美しいものにし、かけがえの無いものにし、そして急激に変化している世界で、それらをより価値のあるものにするのです。
「至る所に発達したテクノロジーがある」という状態になってきていることで、デザインに対する敷居はますます高くなっているとJonathanは付け加えています。特に米国のシリコンバレーは完全にこの状態になっています。テクノロジーは常に私たちの周りに存在しており、デザインを今までにないほど重要なものにしています。
「デザインはもはや『あったらいいな』というものではありません。『なくてはならない』なものなのです」とJonathanは言います。
さらに彼は、企業の義務とは新しいガジェットを生み出すのではなく、今あるモノを使ってできることを増やしていくことだと主張しました。また、もっと簡単に使えるモノをデザインできなければ、ユーザーの手に余ってしまうことも付け加えました。
デザイナーはガジェットをもっと使いやすいものにする必要があると彼は強調します。彼が言うように、エンジニアリングが正常な動作を可能にする一方、デザインは、人々が物事を行う時、どのような動作であれちゃんと実行できるようにするためにあるのです。
転換は難しい
Quantcastは、100名以上のエンジニアを抱えており、今もエンジニア主体の企業として存在しています。同社のデザインチームは他社と比べてとても規模が小さく、わずか5名強です。といっても、デザインを軽視しているわけではありません。
Jonathanによると、同社の共同創設者兼CEOであるKonrad Feldman氏は、デザインの重要性を主張する一人です。デザイン以外の部署にもデザインを持ち込もうというクリエイティブな文化がQuantcastにはありますが、かといって簡単にエンジニアリング中心からデザイン中心の組織にシフトできるというわけではありません。
「これは難しい転換です」とJonathanは語ります。
デザインチームにとっての最大の課題は、エンジニアと一緒に仕事をしていくということです。「状況は良くなってはいますが、まだ私たちの技術レベルがエンジニアたちと同じではないため、未だに実践における問題はたくさんあります」と彼は言います。
このような技術レベルの差は犠牲を伴う可能性があり、フロントエンドコード上で制作する必要があるデザインチームに余計な負担がかかるかもしれません。
Quantcastのエンジニアリングチームは、HTML/CSSだけに留まらず、あらゆることをこなせるフルスタックエンジニアで構成されています。デザインチームは、Flexboxやインタラクション、アニメーション、そしてレスポンシブウェブデザインといった、エンジニアが知らない多くの技術を使っています。
Jonathan曰く、エンジニアは彼のようにフロントエンドに精通しているデザイナーがコーディングをサポートしてくれることに感謝するといいます。しかし、デザインチームにはすべてのコーディングができるほどの余裕はありません。そしてこれが、Quantcastのプロジェクトのためにコーディングする技術をまだ持っていないエンジニアたちをイライラさせてしまうのです。
同社は、フロントエンドコーディングにおけるエンジニアの負担を減らせるようにデザインチームを成長させたり、またはフロントエンドコーディングを自分たちで出来るようにトレーニングするなど、最適なソリューションを見つけようとしているそうです。現時点では、エンジニアリングチームはフロントエンドに時間を取られてしまっていますが、両者を近づけるためにできるだけのことはやっているようです。
とにかく、Jonathanやデザインチームはエンジニアとデザイナーの間に古くからある隔たりを埋めようとしています。今までとプロセスを変える事でデザイナーの業務にエンジニアを巻き込むなど、より結束力のある関係を持とうとしています。
もっと良い方法とは?
初めてQuantcastに来た時、Jonathanはいつも通りの行動をしました:つまり、エンジニアたちに仕様書を持っていったのです。彼は、自分のデザイン方法に関する詳しい説明が載ったモックを送ったのです。エンジニアたちはさっそく作業に取りかかりました。出来上がったものは完璧でした。しかし厳密に言うと、ピクセルは完璧ですが、複数の画面サイズ向けにデザインする場合には機能しないものだったのです。
「彼らは実際にデザインを正確なピクセルサイズまで縮小して考えてしまったのです」とJonathanは述べました。彼は、効率的に作業を進めるためにもっと良い方法があるはずだと思いました。
Jonathan氏は、まずエンジニアたちがマークアップを行うのをサポートし、さらに自分がやったことを説明することにしました。彼の目的は、デザインチームが精通している全ての最新のフロントエンド技術をエンジニアたちに教えることでした。
Quantcastは、デザイナーとエンジニアどちらも参加できるコーディングのイベントを行うことで、デザイン中心の考え方を促進しました。さらに、タイポグラフィーを含むデザインのワークショップも開催しました。
だんだんとデザイン中心の考え方に
Quantcastのデザイナーは、他のデザイン中心の組織と同じようなプロセスを採用しています。彼らはSketchやInVisionなどのツールを使用してワイヤーフレームやプロトタイプをつくり、デザインをさらに洗練させるために、出資者と共にそのワイヤーフレームやプロトタイプの見直しをします。同社のデザインチームはさらに、完成されたビジュアルパスも行います。
彼らはユーザーテストも実施しており、研究者が2週間ごとにインタラクティブテストを行っています。最終バージョンが出来上がると、デザイナーはデザインに十分なコーディングを行い、エンジニアがそれを基に構築できるようにしています。
しかし、コーディングについては、JonathanがZURBで人気のFoundationのレスポンシブフレームワークのディレクションをしていたにもかかわらず、Quantcastはフレームワークを使っていません。なぜなら、会社が特定のブラウザサポートの条件を指定していないことで、デザインチームがあらゆるツールを使用できるようになるからです。彼らが使用しているツールの1つにFlexboxがあります。Flexboxはレイアウトを簡単にしてくれるため、デザインチームが一から物事を作る事ができるとJonathanは言います。
同社のデザイナーはエンジニアにできる限りのサポートをしています。複雑なものを作る場合は、Jonathanは常にエンジニアをサポートして、彼らがその作業をやり遂げられるようにしたいと思っています。
Jonathanは一連のプロセスについて、「状況は前よりも良くなっています」と話します。おそらくまだ発展途上でしょうが、そのプロセスはデザイナーとエンジニアを隔てるのではなく、むしろ彼らを結び付けようとしているのです。
UXPinでも、デザイン中心で協力的な環境を皆さんの組織で実現するのを支援することができます。無料トライアルをぜひお試しください。