”Why Visual Designers Are Now Frontend Developers”という記事を翻訳しました。主張にひどく共感したので、@andreehuk氏に個人的に許可を取って翻訳させてもらいました。

 ここから本文 

[一部省略]

進化する”ディベロップメント”

私は’’ディベロップメント“という言葉をその言葉の意味どおり使いたい、すなわちそれは”｢誰か｣や｢何か｣が成長したり、変化してより良いものになるプロセス”のことだ(より詳しい説明はケンブリッジ辞典を見て欲しい)。

肩書には｢ディベロッパー｣ではなく｢デザイナー｣を使うようすることもできた。しかし、｢デザイナー｣という言葉だけでは、ソフトフェアデザイン業界で今まさに起きている根本的変化を充分に伝えることができない。

フロントエンド、ビジュアル、そしておそらくは戦略的な部門におけるデザイナーの重要性を強調することも出来ない。知っての通り、ビジュアルデザインは単なる表層的な美しさや、デザイン部分のコードを書くことだけにとどまらなくなっている。

ビジュアルデザインからデザインディベロップメントへ

今日の市場には、数多くの職業の他にビジュアルデザイナーとフロントエンドディベロッパーがいる。その中でもフロントエンドの開発スキルを持っているごく一部の人たちは先進的な目を持っていると言える。

このスキルセットを持っている人は決して多くはなく、またチームに大きく貢献できるので常にどのチームにも歓迎される。開発がデザインに大きく近づいてきているがゆえに、ソフトフェアをデザインするプロセスには根本的な変化が起きているのであろう。

本記事で触れる2点

• 1.デザインシステム思考
• 2.ディベロップメントにおけるマインドセット

デザインシステム思考

静的なビジュアルのデザインから、ビジュアルコンポーネントの設計と製作への変化は水面下で進行してきた。実際に(blended.ioのような)デザインと開発を行う制作会社やデザインエージェンシーは、すでに何年も前からこの変化を推し進めてきた。

ただし元来のデザインツールを使ってそのような方法でデザインを行うことは容易ではなかったので、幾つかのポイントに限定してのことだ。すべてを行うことが可能かと言われれば可能だったが、手作業や同じことの繰り返しが作業の大半を占めていた。プロジェクトが大きければ大きいほど人の手による努力を正当化してしまいがちだ。ランディングページや静的なウェブサイトなどの小さなプロジェクトでは、そのような手作業を行うことは経済的ではない。

デザインツールが進化するにつれて、よりシンプルな短期間のプロジェクトにおいて、それらの努力が圧倒的に少なくて済むようになった。なぜか。例えばUIキットとその中のコンポーネントを複数のプロジェクトでカンタンに使いまわせるようになった。Sketch Materialではコンテンツと視覚的にデザインされたコンポーネントを見事な方法でまとめ上げている。Adobeイラストレーター10を使った場合や、5年前にこれを行ったら…と想像してみて欲しい。また、別の例としてオーバーライド機能によってネスト化されたSketchのシンボルが挙げられる。

ディベロップメントのマインドセット

適切な専門用語を見つけるのは少々難しいかもしれない。｢フロントエンド｣という言葉が、どうもウェブエンジニアリングに傾倒しすぎているように感じられるので私はここで”フロントエンド”という言葉をあまり使いたくはない。｢デザインエンジニアリング｣と言えば、少しテクノロジーサイドから離れすぎてしまい、誤解を生んでしまうかもしれない。

デザインディベロップメントが意味するものは何なのか。例えばインタラクションデザインフローとビジュアルのレイアウトは、真っ白の何もないキャンバスから時間をかけてつくられる。

デザインディベロップメントにおいてほぼ全ての起こり得るユースケースと、問題になり得るボトルネック、そして開発実装の際に発生する問題を、デザインツール内で開発チームの協力をなるべく仰がずに正しく導き出すことができる（これが普通のデザイナーとの大きな差なのだが）熟練したデザイナーの責任について触れておきたい。

おそらく今更何を言っているのだと思う人もいるかもしれない。確かにそうだ。しかしそれはデザイナーが、バラバラのデザインスペックとして、全ての潜在的な条件下のプロトタイプを作成する場合に限られる。それらの仕様を作り出すまでのプロセス全体はとても退屈で、間違いを犯しやすいということはご存知のはずだ。

さらに、デザインツールを使って即座に技術的フィードバックを得ることは単純に不可能だった。いや、他の誰かにHTMLのダミーモックアップを作ってもらうか、開発チームに実装をお願いしなければならなかった。

実際、最新バージョンのスケッチ上でデザインする時に考えなければならないことは、(フロントエンド)エンジニアが考えるべきそれと非常に似ている。それはすなわち、５つの異なる幅と、２つの異なる種類のフォームに最適なコンポーネントを作るということだ。

スケッチを使えば素晴らしい方法で実現できる。エンジニアの考え方を理解していなくても要素とコンポーネントをデザインし、定義することはできる。

スケッチでデザインすることは、デザインツールがどういう役割を担うべきかというメンタルモデルと一致している。(最終実装後に)どのようなコードが書かれるべきかなどということを理解している必要はない。

しかし思うに、Sketchでデザインし、定義していくという新しい手法はエンジニアリングのプロセスに似ているという事実は、大抵の人にとってはよくわからないものだと思う。たとえばレスポンシブなウェブサイト用に作成したSketchコンポーネントは、CSSで実装されたコンポーネントのウェブブラウザ上での動きととても良く似ている。今後さらにフロントエンドエンジニアリングによく似た特徴が、形を変えてSketchに出現するだろう。

デザインディベロップメントの考え方は、シニア職以上の人々にとっては特に重要だ。このマインドセットはトレーニングか技術系のチームと働くという経験によって培われる。今日では、駆け出しや中堅のデザイナーを含む全ての人間がこのノウハウに触れることが出来る。最高でしょ？

[以下省略]

 ここまで本文 

まとめ

シンボルやオーバーライド機能など、Sketchの進化は目覚ましいものです。デザインシステムの導入で、単純作業や繰り返し作業などをほとんどやる必要がなくなりましたが、それと引き換えにデザインチームの考えるべきことと負うべき責任の範囲は遥かに広がっています。

汎用性が高く、アップデートが難なく行えるコンポーネントをどのように作るか、といったようなディベロッパーのマインドセットを持つことも要求されるようになってきました。しかし同時にJavascriptやCSSなどの開発言語を理解していなくても、Sketchなどデザインツールの恩恵によって、一部のフロントエンドディベロッパーが担っていた業務をデザイナーが担うことができるとも筆者は主張しています。

デザイナーがインターフェイスと名の付くもの全てに徹頭徹尾責任を持たなければならないようになったことで、今後のデザイナーの働き方に大きな影響を与えるのは必至です。デザインディベロッパーという呼称が一般化するかどうかはわかりませんが、やはりデザインシステムを使いこなし、ディベロッパーのマインドセットを理解すること、この２点こそがチームに大きく貢献できるデザイナーの必要条件になってくるのだと思います。