あらためてなるほどな、と思えるいい記事でした。
【これからのスキル】デザイナーとエンジニアの境界線がどんどん無くなる | freshtrax | btrax スタッフブログ
自分にも重なる部分があると思って経験と雑感込みで書いてみた、毎週水曜更新のデザインラボbyツクロア、今週私のターンではデザイナーがコードを書く意味についてです。

一枚絵では通用しないアプリデザイン

某携帯電話メーカーからAndroidアプリデザインの依頼があったときの話です。
電話着信画面や起動直後の待受ロック解除のデザインを含め、使い心地や操作感から画面構成まで一緒に考えてもらえるデザイナーを探しているということでした。
担当者いわく「静止画だけではアプリデザインの良し悪しが決められないんですよ」という話から始まり、では「実際うごくデザインモックを作りながら一緒に考えましょう」という作業の流れを提案して検証からリリースまでに至ったことがあります。
HTMLベースでデザイナーがコードを書いて画面検証を行ないました。

また別の案件でも、振り込みや残高照会機能を持つ銀行アプリも担当者と一緒に何度もディスカッションして早いスピードでトライアンドエラーを行いました。
1アカウントで複数の通帳口座を持っているとシームレスに口座を横展開しながら閲覧・操作しなければならず、そうなると内容量に違いが出て、高さがバラバラになるのでアコーディオンUIに…と機能が複雑になるともう静止画では見落としが大きいことが担当者の悩みだったようです。充分な検証の結果無事リリースできました。

振り返ってみると、開発担当者はもう何年も前から一枚絵で提出するアプリデザイナーに頭を悩ませていたことと思われます。

なのにデザイナーがSketchやPhotoshopだけでなく、コードで画面を動かすという必要性は周囲のデザイナーの中にはまだ実感できていない方も多いようです。
コードを書くことが目的ではないにせよ、何に向き合いどう行動するか？についてはデザイナーも手段をいくつか持っておくと良いかと思います。

最近ではプロトタイピングツールが普及していますので画面数が多く遷移の確認が実機で確認できてスムーズですが、逆にほぼ一画面内で情報が切り替わるシングルページアプリケーションであればHTML, CSS, JavaScriptを書きながらコードで本番さながらの画面デザインを行なうように使い分けて作業しています。

記事原稿はJSONで

特に記事系の画面デザインには記事用のJSONをもらうのが有効だと思っています。

記事一覧のページをデザインする際はもうPhotoshopなどは使わずに、開発側に「JSONファイルって吐き出せますか？」と相談することをデザイナー自身が行なうのです。
なんとかJavaScriptを書いて、外部JSONファイルの読み込み→（ローディングアイコン表示）→JSONファイル読み込み完了→（ローディングアイコン非表示）→0.3秒程度で記事本体をフェードイン…もしもローディングエラーだったら？といくつもの画面の状態について理解しながら動かすものです。

ダミーテキストは画面を構成する手がかりとしては非常に曖昧で誤解が生じやすいことがあります。文量が多い、少ないなど必ずあります。多すぎると「…」といった三点リーダーで切るなどの処理を加えなければならないのをデザイナーはわりと忘れがちです。
サービスによってはサムネイル画像を持たない記事があるにも関わらず、そういった想定外のことは考えないデザイナーも、多少は許せても、全く無頓着だと無責任と思われてもしかたがないでしょう。
最終工程になってそのことが発覚して「サムネを持つ記事と持たない記事の見せ方のパターンを別にしましょう」という話になったりすると開発工数がかさみ、スケジュールに余裕がなくなり、「心地よい操作」という最もユーザーに近い配慮が後回しになることもあり、とても深刻です。
だからこそもっと想定外に責任を持つこともデザイナーとしては重要なことです。
弊社では「ダミーテキスト禁止令」をルールとしています。

アニメーションやマウスオーバー（状態変化）の検証

これはもう静止画では伝えることができない領域で、感覚値で「ぬるっと」なんて伝えられても、少し画面要素が複雑になり始めるとあらゆるトランジションが発生します、例えばナビゲーションドロワーだったりツールチップやエラーメッセージの出現だったり、いたるところで静止画にない「状態変化」に対してもデザイナーは責任持たなければなりません。
そんな複雑な状態で「ぬるっと」なんて話をするだけでは必ずと言っていいほど見落としが発生します。
動きはCSSのtransitionプロパティで時間遷移の指定を行い、transformプロパティで移動を行えは済むことで、動きをつけるのも慣れたら難しいことではないはずです。

フレームワークのスキルはひとまず脇に置く

良くこの手の作業でプロジェクトリーダーから相談されたケース、最も多いのが
「UIフレームワークを使って作業できませんか？」という相談です。
例えばIonicframeworkだったりBootstrapだったりFoundationだったりを使って欲しいと言われることもありました。
（邪推しますが、本開発の負担をここで減らしたいという狙いも感じますが、そんな予算と工数は見積もっていないので）
私の場合これらは全てお断りしてきました。もちろん、使って悪いわけではありません。
ただ、そもそもの話ですが画面に対する問題を明確にすることが目的であって早いトライアンドエラーが目的です、UIフレームワークのドキュメントを読みながら修正するのは、ほとんどのデザイナーは無駄な時間をかけることになり本末転倒です。
もちろん使い慣れていれば問題ないですが、だいたいデザイナーがこのようなフレームワークを使い慣れていることはほとんどありません。
目的を達成するため、最短の方法で解決するように心がけるべきでしょう。

キレイなコードは必要ない

バグだらけ、つぎはぎだらけのコードを気にする必要はありません。ここで重要なのは安定動作よりも画面デザインの検証です。
なので実際のHTMLベースで表示していて、動作している状況でいかに心地よくストレスなくアニメーションもスムーズに表示内容が読みやすいか、これがデザインで検証できることが本質なので、極端に言うとデザイナーが書いたコードにバグがあっても構わない、重くなってフリーズしたらブラウザの更新ボタンを押してもう一回表示してみます。

実際の本開発はAngularベースでやると決まっていても、デザイン段階ではjQueryベースでやっています。
それは単に多くのデザイナーがAngularのスキルを持っていないだろうという理由です。
一番早い方法で「ダイナミックなデザイン」を検証するにはDOM操作がほとんどなため、デザインの動く部分はjQueryで充分行えます。
ただ、これもスキルの違いでデザイナーの中でもAngularのようなMVW(Model-View-Whatever)系のフレームワークを理解する人もいると思いますし、今後も増えてくるだろうと思いますが、今解決するべき問題に向けてスピードと効率を優先し、ツールはデザイナーのスキルに合わせて選べばよいと考えています。

開発フェーズとの境界線

よくデザイナーが画面デザインをコードで書くと、依頼者や周囲の開発者は「あ、もう実装をしてくれているんだ」なんて誤解し始めることがあります。これがデザインフェーズだと最初に伝えたにも関わらず、だんだん開発フェーズとの境界が見えなくなってくるから注意しています。
私の経験ではほとんどの案件で「自分の書いたコードは使えないと思います」と釘を刺したうえでプロジェクトを進めるようにしています。（結局使われていることが多いですが、その場合もちゃんと見直すようにお願いしています）
それにしても、今までデザイナーに頼んでいたPhotoshopやSketchで作られた何十枚に及ぶ画面デザインが、実機やブラウザでこうやって動かしながら検証できるというのはむしろ歓迎されるケースが多いので、もっとデザイナーが自信を持って発言して前に出てどんどん問題について話し合うと良いでしょう。

あまりにも変更が多い場合はワイヤーフレームへ戻す

毎回お客様やテストをしてくださる方と議論を交わすことがありますが、検証しつづければ画面のレイアウトや仕様が変わる場合があります。
あまり変わりすぎるとHTMLベースのデザインだと逆に問題解決へのスピードが遅くなることもあります。
なので状況を見て、作業を最も適切な手法へと切り替える判断も必要だと感じています。
律儀にコードだけで修正しないでいいように、検証サイクルが大きい場合はワイヤーフレームをベースに議論することも大切だと考えています。

リアルな問題解決こそデザイナーのスキル

冒頭でデザイナーがSketchやPhotoshopだけでなく、コードで画面を動かすという必要性は周囲のデザイナーの中にはまだ実感できていない方も多いと書きましたが、個人的にはやはり必要だと考えています。
「コードなんて書きたくない」というデザイナーもいるでしょうが、では静止画だとダイナミックなコンテンツデザインにおける課題をどう解決するか？を自ら答えられなければ話は進まないでしょうし、結果的に解決できなければ残念ですがそのデザイナーの評価は上がることはないでしょう。今は1つのページがダイナミックに切り替わることが当たり前の時代で、エラー処理の中にもどういったエラーケースがあるかを理解しながら、画面を構成していく必要があります。
コードを書くことがデザイナーのゴールではないです、しかし自ら検証したい材料を早い段階でこういったカタチにして積極的な解決行動をとるデザイナーを求められているように思えますし、自分のスキルを広げようと努力している人にこそ強い武器が備わるものでしょう。
これはデザイナーにとって考えずにはいられないところだと思います。

これから学習したい方へ

もしもこれから、という人でしたら、HTML, CSS3, JavaScriptの基礎知識とjQueryのaddClass, removeClassによるクラス付け替えの状態変化への理解、モーダルウインドウやトーストは、jQuery BlockUI Pluginくらいの組み合わせをまずは第一歩として少しずつでも学習するとよいでしょう。弊社内では外向けに勉強会も検討中です。

さらに弊社ではそういったコードによる問題解決を目指すデザイナーを随時探しています。

自分なりのデザインとコードについて次回も続編を書いていきたいと思います。