デザインとエンジニアリングの狭間で

2021.12.22

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

私は以前ウェブアプリケーションエンジニア(サーバーとウェブフロントが半々ぐらい)として働いており、今の会社ではデザイナーチームに所属しています。 ただし、コードもちょいちょい書いているので、既存の職種に当てはめると「UXエンジニア」・「デザインエンジニア」みたいなものになると思います。

UIデザインに手を出した時期が5,6年前で、SPAで企業向けのアプリケーションを作っていました。その際にUIデザイナーとして働き、エンジニアリングの経験を活かしたデザインで価値が出せると感じたこともありWebアプリケーションエンジニアとしてはデザイン寄りの働き方をしてきました。 それ以前からもPhotoshopやSketchを使ってデザインモックを作ったり、名刺・ポスター・パンフレットなどを作っていましたが、UIデザインの楽しさに気づいたのはそのタイミングでした。 今の会社にエンジニアリングのわかるUIデザイナー枠で呼ばれたこともあり、働き方を大きく変えることになりました。

そんな分野を横断した私の立場から「デザイン・エンジニアリングの狭間で我々は何ができるのか?」というのを考え直してみました。 なおこの記事中でのエンジニアリングは「Webフロントエンド」、デザインは「WebにおけるUIデザイン」として読みかえてください。

技術的な難易度・可能性を考慮できる

ウェブフロントエンド出身デザイナー、一番の強みは「技術的にできること・難しいこと」が把握できるというところです。 一枚のモックを作るだけだと、ウェブデザイナーとしてグラフィック出身の人たちにはかないませんが、そのモック上でどう動くか?という点ではウェブフロントエンドの知識を活かせる部分になります。

といったエンジニアが気になる点はもちろんですが

といったデザイナー的に気になる点も考えることができます。 もちろん、実際は本業のエンジニアと相談しながら進めることになりますが、ある程度エンジニア的な知識があった方が話は進めやすいと思います。

また、プロトタイプ的なタイミングではスマホのジェスチャーを使ったインタラクションを増やすときに何ができて、何ができないのかといったことをある程度把握した上で考えられます。FigmaやXDではカバーしていない範囲であっても、After Effectsで軽く作ってみたり、実際にコードを書いてプロトタイプを作るといったことも選択肢になります。

実際の例として一般的なUIから外れた画面を考える際1、JSでジェスチャーを含むプロトタイプをつくって関係者に共有し、合意をとった上で実装に入ったことがあります。 プロトタイプのためにコミュニケーションを取るのは精神的なハードルを感じていて、一人で完結するメリットを感じた瞬間でした。

英語を読む抵抗感が薄い

経験上ウェブエンジニアをやってきた人間は英語のツールやドキュメントに対しての抵抗感が薄い人が多いと感じています。

UIデザインをつくる上でGoogleのMaterial DesignやAppleのHuman Interface Guidelinesといったものを参照する場面は多いと思います。しかしこれらのガイドラインは英語で書かれており人によっては抵抗を感じるようです。 「日本語に翻訳されたものを見る」という選択もありますが翻訳の段階で抜け落ちる情報があったり、最新の情報に追いついていないという場合もあるので、原文を読むのがベストでしょう。

また、近年UIデザインのカバーする領域が広がっており、アクセシビリティやデザインシステムといったテーマが話されることが多くなっています。 これらの分野はまだ情報が少なく、調べる際に日本語だけだと限られた情報にしかアクセスできません。

本来原文で読むべき内容であっても要約してチームに伝えることはできます。チーム内で得意・不得意はあると思っているので、情報収集は積極的にやっています。

手触りや細部の表現まで意識できる

手触りという意味ではネイティブアプリライクな画面を作る機会もありました。どうしてもウェブだと「アプリほど気持ちよくない」とか「没入感が弱い」となりがちですが自分はウェブでもよりよい手触りが実現できると考えています。 基本的な実装技術の欠落により操作感が落ちることはあるのですが、UIパーツごとの最適化不足による体験の悪化もあると思っています。 Webではリソースの少なさから既存のUIライブラリに頼ることが多いと思います。そういった理由から理想のインタラクションを諦める場面も多いと思います。エンジニアリングの経験があることで実装の可否とコスト感がわかり実現できる場合もあります。 理想のインタラクションが実現できたときは本当に感動しました。

また、今の職場は業務に直接関係しない研究が推奨されているのでユーザーの投稿したコンテンツや自動生成の画像・動画の質を高めるといったテーマは一貫してやっていました。JSで自然言語処理を行い改行位置の調整や画像に対してオリジナルフィルター、CSSでできる文字詰めはもちろん、縦書きCanvasの文字詰めにも挑戦してきました。アニメーションを実装する際は、YouTubeのAfter Effectsのチュートリアルを見ながらレイヤーの構造や動かし方を理解するフローを試したりしました。 こういった細かい部分はエンジニアだけでもデザイナーだけでも進めにくいのでまさに自分にあったテーマだと思います。

今後はクリエイティブコーダー界隈やゲーム開発界隈のように更に別分野から知識を取り入れていけば面白いものができそうな気がしています。

デザインとエンジニアリングの溝を埋められる

どちらともの分野に踏み込んだ人間に多くの現場で求められるのが、デザイン・エンジニアリングをまたぐような分野と、その溝を狭めることだと思います。

例えば、自分はFigmaの普及活動をやっています。非デザイナーに対してはFigmaで作図や簡単なワイヤーを書くワークショップを、デザイナーにはAutoLayoutやComponent, Libraryなど再利用しやすいFigmaデータの作り方をレクチャーしました。 このおかげかどうかはわかりませんが、あるPdM(プロダクトマネージャー)はワイヤー段階の作業をFigmaで行ってくれましたし、XD派だったデザイナーの人はFigmaに興味を持ってくれてFigmaを積極的に触ってくれるようになりました。 一方で、グラフィック出身のデザイナーと関わる機会も増えて、ウェブ出身のデザイナーとは違った文化であったりツールセットの知識なども増えてきています。

また、デザインシステムやアクセシビリティについて考える機会も増えています。 今の職場では小さい規模感のアプリケーションがたくさんある、という感じなのでデザインシステムを作るといった話はありませんが、デザイントークンの定義やデザイナー・エンジニア間でのワークフローの話は盛んに行われています。そういった場面でもデザインとエンジニアリングの経験が活きていると感じています。

まだまだ道半ば

ここまでデザイン・エンジニアリングの狭間でできることを書きましたが、実際のところ中途半端な場面は多いと感じています。

デザインの成果物で重視されがちなビジュアルやグラフィックの面では他に得意な人がいて任せがちなのもそろそろやめられるといいなと思っています。 プライベートではグラフィック寄りなものや、同人誌の表紙なども作っていて以前よりはだいぶ苦手意識が薄くなっています。以前は全く理解できなかったIllustratorも、今では和解してお気に入りのツールになりつつあります。

これは意図しないことですが、プロトタイピングはかなりうまくなっていて「これを作りたい」と思ったものを手っ取り早く具体化することができるようになりました。 プロトタイピングの中でも手をかけるべきところと手を抜くべきことの判断はうまくなりましたし、いろいろなデザイン・コード資産も溜まってきてクオリティも徐々に高くなってきました。2あとは実際にリリースできる打率を上げられればまた別の価値を出せる気がしています。

中途半端な器用貧乏から、二刀流を自称できるぐらいの結果を出せるよう頑張っていきます。俺たちの戦いはこれからだ!

注釈

  1. 本来、一般的なUIパターンを利用しユーザーの慣れを利用するのが原則です。

  2. 今年は特にCanvas(2D)への理解が深まりました。来年はWebGLもちゃんとやりたい。