DroidKaigi2019でRoomClipのデザインガイドラインを公開した話
2019年2月7〜8日に開催されたDroidKaigi2019で、RoomClipは企業スポンサーとして参加しました。
（パーティでご好評いただいたケーキの会社です🧁✨）
そこでデザインガイドラインを（抜粋ですが）公開したところ、私からしてみると意外にも好評だったようで、少しでもエンジニア・デザイナー間のやりとりが円滑になったらいいなぁを応援したくて、いただいた反応やらエピソードやら記事に書くことにした次第です。
前置き
実は、アンドロイドチームから『DroidKaigi2019にデザインガイドラインを公開したい』という打診があった時は正直ぜんぜん気乗りせず。
というのも、デザインガイドラインなんて先人がいくらでも知見を発揮していますし、「今やみなさんどこでも作ってるでしょ」という思いから、採用ベースでもエンジニア目線でも特に目新しくもなく、大したフックにはならないんじゃないかと思ってたからです。
とかあんまり前向きに考えずに当日蓋をあけてみたらずいぶん足を止めてもらえるきっかけになり、なんなら「デザイナーさん来るならその頃また来ます」という方とか、「会社のデザイナーに共有します！」と言っていただけた方が何人もいらっしゃったとかで。
なにそれ超ありがたしです。
思えば、社外のデザイナーさんとの交流はちょいちょいあったのですが、自分のデザイン業務に対してエンジニアさんからご意見頂く機会はあまり無かったなと。
嬉しい反応を受けたことでチョロくも調子に乗って記事にするにあたり、ガイドライン作成についてのあれやこれや描き始めたら、それはそれは長くなってしまったので、それは別記事で改めてガイドライン作成シリーズをまとめる予定です😋
当日のブースの様子と公開の仕方
弊社では、デザイナーとエンジニアの連携は全部zeplinです。
ガイドラインをどういう形でイベント用に持ち込もうかと迷ったのですが、結果としていつも弊社でやりとりしてるzeplinのまんま見せてみることにしました。
その方が社外エンジニアさん達の反応も新鮮に拝めるかも、と思いまして。
良かった点
・撮影OKにしたことで多くの人に足を止めてもらえるフックになった（らしい）
・デザインとエンジニア間のリアルなやりとり状況をお伝えしやすく、疑問質問につながる好感度が高かった（らしい）
改善できそうだった点
・「Androidのイベントだし」と思ってiOS用のガイドラインはあえて伏せたんですが、iOS関係の質問もけっこう飛んだらしく、別に出しちゃってもよかったぽい
・用意した専用ラップトップ１台では画面が狭すぎたらしい
RoomClipのデザインガイドラインの特徴
今回の記事で内容の詳細は端折りますが、RoomClipのデザインガイドラインにおいてちょっと特徴的だと思われる部分がありまして。
やっぱりこのへんに対する反応が大きかったような気がします。
web／Android／iOSにおいて、共通化できそうなパーツはすべて共通化している
・アウトプットに関わらず、プロダクトを跨いでもエンジニア全体でスタイルの相互監視ができる態勢になってる
・デザイナーもクオリティ確保のコストかなり削減◎
基本的にGoogleのマテリアルデザインファーストで他のプロダクトのスタイルも定義している
・理由は初代マテリアルデザインがあまりにも数値がガチガチすぎたせいで（今はそんなことない）iOS先行で作るとうまく行かないケースが多発し、Androidに合わせることでストレス無くなりました。
・やっぱり世の中iOS先行でデザインしてる企業さんが多いらしく、その辺についてはアンドロイドエンジニアさんたちから興味を持たれた
基本的に数字で指定しないようにしている
・ガイドラインに数値はもちろん定義しますが「大・中・小」とか「濃い方・薄い方」とか、「00〜006のナンバリング」とかで全員が通じ合えるようになってます
・数値に変更を入れても一括で直せる体制に
フォントサイズを大中小の３つだけで全部定義している
web、iOS、Androidそれぞれの数値設定はありますが、どのプロダクトも「大・中・小」だけでやりとり可能です
実際あった反応を抜粋
実は、そこまで反応があると思ってなかったものですから、自分は初日にちょこっとブースを冷やかしに行っただけでしたので、ほぼ後から聞いた話になります😅もっと居ればよかったです。
「どうやったらデザイナーさんにアンドロイドリテラシーを上げてもらえますか？」
多いと感じたのは「iOS先行」とか「ものっそいwebっぽい」デザインが上がって来て、がんばってAndroidで実装していて苦労している、という内容でした。
これ、超わかります。（デザイン側の気持ちが）
そして多分あるあるです。
ユーザー数がiOS＞Androidのところは多く、よほどマンパワーのある会社は置いておいて、まだ人数の少ない開発チームやスタートアップだと、どうしてもいろいろがiOS優先になることが多いと思います。
あとは、webサービスからアプリ開発につながり、webのデザインはやったことあるけどアプリは初めてやるデザイナーさんとか。
結論から言えば「デザイナーさんはAndroidエンジニアさんが苦しんでるとあんまり思ってない」です。なぜなら、デザイン渡した時にちょっと苦々しい反応は返ってくるものの、結局組んでくれるから！
エンジニアさん側から素直な声を上げたほうがいいです！私がそうでした！
「このパーツもこのパーツも。公式のコンポーネント使えば楽なのに、iOSに寄せないとそんなにダメなのか」「もっと勉強してくれつらい」とまで言われてやっと「あ、私ひどいことしてたんだな」って気づき、エンジニアさんからの強い圧もあって勉強しなおし、今に至ります。
（今もまだ勉強しきれてないですが…！）
「うちもこういうの作りたいけどデザイナーとコミュニケーションが取れない」
物理的にフロアが離れてるから、とか、そんな密にやりとりできないみたいな声をお聞きしました。
弊社の例ですが、お互いのガイドラインリテラシーを高めるために、合同でガイドライン読み合わせ会をやりました。
ガイドラインは英語だし、残念ながらみんながみんな頑張ってゴリゴリ読み進められるものではないんですよね。なので、強制的に毎週時間を取って、分担を決めて、全員で読み合わせ会をやりました！
結果的にエンジニアもデザイナーも全員が当事者性UP！かつ、全員がガイドライン準拠を監視できるという頼もしい企業体制にレベルアップしました！
ただ、発表形式にしたことで、まじで読み終わるのに確か半年くらいかかってますし、正直参加者達の睡眠を深刻に害しました…笑
もうちょっといいやり方はあると思います。
「フォントサイズ3つでデザイナーさん大変じゃないですか？」
逆に、モバイル画面作っててあんなちっさい範囲でそんなにたくさんパターンあったらただゴチャつくし、デザイナ間でさえも属人の感覚頼りになるしで整合性取れなくて大変になりました。
弊社のデザイナー内の結論として
『手のひらサイズの画面にそんなたくさんパターンいらん』
『サイズは３パターンでも、色x３、透明度x3、太さx2で実質54パターンある^^;』
になりました。
シンプルでフロントエンジニアさんとのやりとりも軽快です。
ただしPCだけはさすがに画面が大きいのでもう１サイズ用意してます。
「共有はZeplinだけど、デザインモックとかにはどんなツール使ってるんですか？」
うちはXDです。
余談ですが、デザイナー主導で社内Xdワークショップを催したところ、エンジニアのみなさんがXd使えるようになり、勝手に画面が量産できちゃうようになるという素敵な事態に発展しました。
でもいろいろ難点もあり、現在フォーマットファイルとかシンボル整理でうまくやれるよう現在調整中。
ちなみにfigmaも気になってます。
「どんな風に実装してますか？」
（詳しくわかってないのでエンジニアさんの発言をそのまま載せます^^;）
iOS→UIButtonやUILabelのカスタムビューを作ってデザイン仕様を実装してて、アプリ内ではカスタムビューの方を使わないといけないようにする、というような運用でやっているそうです
Android→style定義してます
「一般公開しないんですか？」
「これ、出版してくださいよ。有料でも買いますよ」
まじすかー！！嬉しすぎる反応ありがとうございます（^p^
いまのところまだ未完成／リニューアル改修中／てれくさいなどの理由で一般公開する予定はないですが、今後のエンジニアとデザイナーが少しでも平和な関係になる手助けになるならと、作ってて学びのあった点アレコレは、熱の冷めないうちに今後記事にしていこうと思っています！
さいごに
いろいろと反応が興味深くて、もっとブースに入ってれば良かったなーでした。
本当に嬉しかったのは「これだけ仕様がちゃんと決まってたら、エンジニアとしても実装しやすくていいですね！」と他社エンジニアさんに言ってもらえたことですね…！作ってよかった…！
実はうちのエンジニアさんは幸せなのでは！？笑
ちなみに、以前会社を跨いだデザイナー同士の「デザインガイドこっそり見せ合いっこ会」をしたことがありまして、それめっちゃ楽しかったんで誰かまたやりませんか！アプリ開発デザイナーさんぜひ！！！
もしこの記事見て、気になる点などありましたらお気軽に聞いてもらえるとウレシーです！
長々読んでいただきどうもありがとうございました！