ブラウザ上で直接コードを書いてWebアプリデザインを行う「デザイニング・イン・ブラウザ」もしくは「インブラウザデザイン」。もう何年も前からそのメリットについて話す人も多く今更新しい手法ではないでしょう。

SketchやPhotoshopによるデザイン納品よりも多くのデバイスや環境で確認でき、animation,hoverをはじめ、ユーザーのアクションによる画面状態変化がリアルに把握できて、デスクトップやモバイルといった固定しない画面サイズにおいて実際の操作中にユーザーの誤操作やストレスを見つけやすいというメリットがあると言われています、ただ、あくまで手段のひとつだということも忘れてはいけないですね。

個人的にはページ数の少ないシングルページアプリケーションにおけるデザインには有効な解決手段だと思っています。

ただいいコトずくめに見える手法ですが、そのコードを開発側にそのまま流用しようとするプロジェクトに対して伝えたいこと、今回のデザイン・ラボは「インブラウザデザイン」におけるプロジェクトメンバーとの微妙な認識における話です。

本開発への流用

よくインブラウザデザインで調べると「開発にそのまま使える」というニュアンスで書かれている記事も見られます。
もちろんそういったケースもあるかもしれませんが（否定はしないけれど）、受け止め方によっては大きな誤解を招きそうに思えます。
そして本プロダクトで使うにしても全てを流用してはならないこと、ソースコードは再設計することを約束してもらうことです。
ただ、伝えたにも関わらず自然とうやむやになってくることもあります。難しく悩ましい現状。
インブラウザデザインの本来の目的は開発側の負担を減らすことではありません。
個人的には「早期発見、早期解決」というべきか。
そのため試行錯誤には作業スピードが求められる、割と負担が大きいです。
触ってなるべくユーザーにストレスを与えないために試行錯誤すると大抵は使わなくなった無駄なコードが無数に散らばる結果に。

設計段階ではソースコードの綺麗さを求めている場合ではなく、いかに試行錯誤のサイクルを早く回すべく、結局つぎはぎだらけのコードになってしまうのはここでは仕方がないと考えています。もちろんCSS設計など行っていない、行っていてもそのうち崩れる。JSに至ってはもうひどい、そのままローンチまで持って行ったら確実に不具合を起こしそう。

まさかこういった試行錯誤のコードのままリリースはしないと信じてはいますが…。

誤解されやすい

特にこういった手法に慣れていないPMや開発チームだと、画面設計における問題の早期発見や解決というより、開発スピードが上がるという方に魅力のウェイトを感じられているように思えます、むしろデザイナーの意図としては逆なんです。

いくつかのプロジェクトで「Bootstrapでインブラウザデザインできますか？」みたいな相談が来ますが、これはもう開発側に有利に進めたいというような意図を感じていました。
有利に進められることは大事なことです、しかし全てのデザイナーにフレームワークの知識があるわけではなく、フレームワークのドキュメントを読みながら画面設計というのは試行錯誤のスピードを著しく損なうし、精通していることに期待するべきでなはいと思います。

なぜこの手法を使うのか、その本質をどこか置き去りにしがちなプロジェクトやマネージャーには理解を求めています。

納期と納品の文化

プロジェクトを守るマネージャーにおいて納期は死守するべきと考えられているため、優先順位がスケジュールになるのは必然でしょう。
一部のプロジェクトは当初のスケジュール通りに進まず、設計段階で押してしまうので開発側が切迫して、表面上見えている納品物が揃っているか？だけを品質と考えてしまいがちです。
そういう状況の中でインブラウザデザインが行われたらもう、使えるものは使ってしまおうという考え方で納期優先になりやすく、おそらく最初に伝えたソースコード見直しの件は置き去りにされそうになるケースも。
そもそも文化の違いであり、納期を優先する文化というのは間違ってはいないと思います。
ただインブラウザデザイン手法が何のためにあるのかという考え方にチーム内で距離感がありすぎると、マインドそのものが違うということになる。
プロジェクトのアサインについても相性が違うとユーザー側に対する配慮へのウェイトまでも違ってくる。
ただ、納期優先という文化があってもインブラウザデザインのソースコードを見直さないプロジェクトには違和感を感じる。

これから10代～20代の若手Webデザイナーがエンジニアとの境界線を超えて課題解決に向き合うだろうと言われています。
それ自体はとてもいいことだと思うんですが、問題はそういった若手のチャレンジな行動に理解を示さなければならないのは上司となりマネージメントする30代以降の中堅どころのマインドあるのではないかと思う。
デザイン手法に対する理解は業界内でも広まってきているとはいえ、中堅どころがその文化を理解しなければ若手もなかなかチャレンジできずに育たず、また離れていくこともあるのでは。

おそらく企業単位で考えるより個人単位でマインドの違いを見極めてメンバーをアサインしたほうがよいのではないだろうかと。

開発者と話をして「開発者も万能ではない」という

たまたまソフトウェア開発を行っている友人の白石俊平さんに開発者としての気持ちを聞いてみました。
彼らのプロジェクト、TechFeedではiOS／Android向けモバイルアプリのデザインをお手伝いしています。
IonicというHTML5フレームワークで開発しているためこちらでつくったインブラウザデザインのソースコードは一度きちんと見なおしてIonicのパフォーマンスにチューニングしている、それでも細かい調整にはさらに試行錯誤を行っているようです。

インブラウザデザインから開発された現在プレビュー版のiOS版TechFeedの画面デザイン、ドロアが開くスピードもデザイナーが伝えることができる
白石さんと話をして聞いたのが、UIのトランジションやアニメーションの実装は、必ずしも開発者が得意とする分野ではないという話。
つまり開発者も万能ではないため、ユーザーが接するUI部分の実装面においてはデザイナーが介入しないと難しい面もあると言います。
またCanvasのアニメーションなども全ての開発者が実装できるわけではないということも。
確かにGLSLのようなシェーダー言語をちょっとだけ書いて試したことがありますが、あれはもうWebエンジニアとは別のスキルが必要な気もして、全て「デザイナー」「エンジニア」という肩書に分けて能力に依存するだけではなくお互いを理解しながら一緒に実装面について話しあったりするという意味では、開発側にデザイナーが関わっていける場面もあるのかもしれないと感じています。

責任分界点

白石さんが発した言葉なんですが、そういえば他のインブラウザデザインを行ったプロジェクトについてもこの「責任分界点」という言葉を何度か聞いたことを思い出してしまう、流行っているのか？とも。。

決して責任逃れをするつもりではないわけで。
だれがどの部分の品質を担保するのかインブラウザデザインではわかりにくくなることがあります。
本開発に流用したいのか、インブラウザデザイン上での微妙な不具合があったらインブラウザデザイン側で動くように修正を求められることがありますが、断片的に動かない部分だけ動かすくらいなら全ての設計から見なおさなければそもそもアプリケーションの品質にはつながらないことが多々あるものです。その修正にデザインの段階で手間がかかるのであれば別の手段に切り替えるコミュニケーション力も必要だと思います。

「完璧なモック」が本質ではないと考えています。
それが理解できないプロジェクトにはアートボード100枚くらいのSketchファイルを出してこの通りにつくってねと言ったほうがソースコードは1から作るので質の高いプロダクトになるかもしれない、というのはある会話の中で出た冗談ですが本気で考えたこともあります。

反面、目の前に動くモックがあると予算や工数を考えて「それでいいじゃん」と思いたくなるPMの立場も分かりますが、それまでの経緯を見続けていれば何度かのディスカッションの中でたくさん試行錯誤しているばず。ソースコードを読めない指示側の立場の方はデザイナーの意見にも耳を傾けてほしいと思います。

まとめ

インブラウザデザインはひとつの手段であり目的にあらず、本開発での流用はその多くで懸念すべし。