WebアプリケーションデザインにAdobeXDを採用してみた【調整編】

はじめに

テクノロジーディビジョン、アーキテクチャ・インテグレーションチームのhig-higです。

前回の記事でWebアプリケーション開発にAdobeXDを採用した事の目的や実際に何が変わったか。
といったテーマで記事を書かせていただいたのですが、今回はAdobeXDを採用したことで生じた要望や調整についてのあれこれについて書かせていただこうと考えております。

デザイナーと開発チームの理想は正反対

デザイナーと開発チームそれぞれが物作りを開始するにあたって頭に入れておきたい事として、デザイナーと開発チームの考える”理想”は基本的に相容れないということです。

もちろんWebアプリケーションを利用するユーザー視点での開発が一番大事ということは前提にありつつその中で、デザイナーは自己の創造性を存分に発揮してデザインを作成することが理想ですが、開発チームは効率よく機能開発を行う事を理想とするため、根本的に見ている物が異なるわけです。

例として、デザイナー視点での理想を松竹梅でランク付けすると下記のようになるかと思います。
【松】画面デザインの全てを自分の思う通りのデザインで実現する。
【竹】基本的に自分の思うデザインを実現するが、一部は既存の部品を採用する。
【梅】既存CSSフレームワークを採用し、そこに定義されている部品だけを組み合わせてデザインを作成する。

この松竹梅は開発チームの視点に置き換えると順番が逆になります。(納期も開発費も無限の場合は別ですが…)

プロダクトオーナー(以下PO)が気をつけること

POは担当するプロダクトの価値を最大限高めることが最大にして唯一のミッションとなります。
デザイナーが創造性をフルに発揮して作成したデザインであっても、ユーザーの立場で考えて使いづらいものであれば修正を求めなければなりませんし、既存ライブラリを組み合わせて作成した方が短納期で開発コストが抑えられるとしても、ユーザーの興味を引き付けられず利用されない物になってしまいそうな場合はデザインにかける比重を高める必要があります。
ユーザーへ最大の価値を届けるために、案件発注者(部門)・デザイナー・開発チームが納得できる着地点を常に模索して、そこに無事落とし込めるようにプロダクトの運営を進める粘り強さが必要となります。

デザイナーと一口に言っても千差万別

デザイナーと一口に言っても、CSSを駆使してWebサイト構成からデザインを作成する方から、PhotoshopやIllustrator等を使用してビジュアルをメインにデザインを作成される方もいます。
ここでは、後者のビジュアルをメインにデザインを作成されるデザイナーさんと相対した場合に押さえておきたい点をお伝えしていきたいと思います。

デザイナーにもCSS知識は必要

Webアプリケーションと一般的なホームページでは、画面の枚数や使用される部品の点数が異なります。
また、複数のページで同じ部品を使用するケースも多く発生します。
これらの事柄に柔軟に対応するためには、デザイナーにもCSSに関する知識が必要となってきます。
AdobeXDでデザインを作成する上でもきちんと考慮しておかないと、ボタンの色を変更するのに画面全部を修正しなければならないといった事態を招く場合があります。

また、AdobeXDでは効率よくデザインを作成できるようUIキットという便利なツールが提供されていますが、これらもCSS定義の集合体であるため、よりよく活用していくためにはCSSに関する知識はあったほうが良いでしょう。

一例ですがSemantic UIというCSSフレームワークはAdobeXD用にオフィシャルのUIキットが提供されているため、デザイナーと開発チームが同一のCSS定義を使用して開発を行うことが出来るようになっています。
参考:
https://semantic-ui.com/
https://blogs.adobe.com/japan/cc-web-semantic-ui-kit-xd-icons-templates-design-system/

プロダクトを進行していくにあたっては、担当するデザイナーのスキルをしっかりと把握しておく必要があります。
場合によってはCSSについての説明資料を用意したり勉強会を実施する等のフォローを行うなどして、一緒にプロダクトを築いていくという姿勢も必要です。
そのためには自分自身もしっかりと知識を身に着け、最新情報をキャッチアップする必要があり、常に勉強が必要で大変な面もありますが、その分やりがいもあります。

追加部品はしっかり管理

先に述べたUIキットを使用して、そこに用意された部品のみでデザイン作成が完結するのが一番スピーディーに開発を進めることが出来ますが、どうしても見た目が画一的になってしまい何処かで見たデザインを脱却出来ない事態が発生することがあります。 (前述の【梅】のケース)
かといって【松】のケースは期間や費用面から採用が難しいケースが多く、多くの場合【竹】のケースに落ち着く事が多いのではないでしょうか。

【竹】のケースを採用する場合には使用する既存部品・追加する部品をしっかりと決めて例外が発生しないよう管理することが非常に重要です。
きちんと定義を分ける、見えるようにコメント(メモ)をつける等混同しない工夫をすることで、開発がある程度進んでから壮大な手戻りが発生するという悲劇を回避できる可能性が高くなります。

POが調整の際に気をつけること

これはデザイナーと開発者間の調整に限った話では有りませんが、双方の主張にしっかりと耳を傾け理解しようとする姿勢が必要です。
デザイナーも開発者も職人気質の人が多く、そこってそんなに重要?と思ってしまうような部分にまでこだわりを持っている場合が多くあります。

限られた予算と期間の中で最大限良いものを提供するためには、そういったこだわりを切り捨てる判断を下す必要は発生しますが、そのこだわりの背景にあるものを汲み取ろうとするかしないかで得られる結果は大きく変わってきます。
人と仕事をすすめる上では基本中の基本ですが、時として忘れてしまいがちなことでもありますので自戒の意味も込めて書かせていただきました。

さいごに

色々と書いてまいりましたが、担当しているプロジェクトは現在進行系で進んでおりまして、反省と学習の日々を送っております。
技術的な話というよりは対人についての話となってしまいましたが、部署の全員がプログラムを書いている訳ではないんだなぁ位に捉えていただければ幸いです。

拙い文章でしたが、お付き合いいただきありがとうございました。
また別の記事でお目にかかれますよう