UI＋FE合流点 - UIデザイナーから見た実装の話 イベントログ
こんにちは！プレイドのデザインチームのなんでも屋さん ayacchi ( @222078 ) です 🙌🏻
今回は、2月6日に Gaji-Labo さんと共催させていただいたイベント「UI＋FE合流点 - UIデザイナーから見た実装の話」について、プレイドから登壇したデザイナーの鳥越の発言を軸としたログを掲載させていただきます。
「UI＋FE合流点 」という名称の通り、UIデザイナーとフロントエンドエンジニアとの狭間になりやすいポイントを ”境界” ではなく “合流点” として語るイベントです。
当日は鳥越のほか、SmartHR クリエイティブディレクター 関口さん、スマートバンク デザイナー 福嶋さん、Gaji-Labo UIデザイナー 今西さんが登壇され、Gaji-Labo 代表 原田さんのファシリテートのもと、座談会形式でお話をさせていただきました。
こちらのログは当日のトークテーマのなかでの鳥越のコメントを抜粋して掲載させていただくため、各トピックの流れが掴みづらい部分もあるかと思いますが、ほかの登壇者さんの発言も含めた全体を通じてのレポートを Gaji-Labo さんが掲載されているので、イベントの全体感が気になられた方はぜひこちらもご覧ください。
自己紹介
こんにちは、プレイドのプロダクトデザイナー、鳥越です。社内では tori と呼ばれています。本日は、プレイドにおけるプロダクトデザインに対するアプローチについてお話しします。
プレイドではプロダクトデザインをメインで担当しております。プレイドのカルチャーとして「この役職・職種はこれをやるべし」みたいなものはなく、「プロダクトに必要だと思うことを能動的に考え、役割にとらわれず挑戦できる」という社風です。
自分が担当してるプロダクトに関しては私自身も、プロダクトデザイン以外にコミュニケーションデザインや必要なことは何でもやるという姿勢で働いております。
他にも、デザインエンジニアのメンバーとデザインシステムを作ったり、Design Department（デザイナーやデザインエンジニアが所属するグループ）の運営を担う Design Program Manager をやっていたりと、色んなことをしております。
今日は色々とざっくばらんにお話ができると嬉しいなと思っておりますので、よろしくお願いします。
個々の強みと弱みを互いに把握して共創する
トークテーマ：普段どういった動き方をしていますか？
前職では15年間ずっとクライアントワークをしており、2021年6月にプレイドへジョインすることで初めて事業会社に所属しました。15年前当時はネイティブアプリが市場としてぐっと伸びていた時期で、UX を頑張りたいというクライアントさんも多かったんです。
その時に求められていたのは「どう作るか」よりも「何を作るか」についての必然性を高めるところでした。ユーザーリサーチをして、インサイトを元に競合と照らし合わせてプロダクトの強みを紐解き、カスタマージャーニーマップの作成や、体験を軸にプロダクトを設計していく、というプロダクトを作る前のフェーズが殆どの仕事です。
プレイドに入った時に開発メンバーに聞かれたことが「コード書けないんですか？」という質問で、そこで「あれっ？」てなったのが最初で。プレイドには数名ですがデザインも実装もできるデザイナーも所属していて、とても活躍していました。ネイティブアプリの開発はデザインと開発の分業がきっちりしていた印象だったので、ギャップに驚きましたね。
私のスキルとしては総じてコーディング以外のところが強めです。特に昔のモバイル端末全盛期の時代に、各メーカーが次々に作る端末と向き合っていたので、端末ごとにインタラクションモデルを考えることなどは得意です。ハードウェアのプロダクトデザイナーとUIデザイナーが一緒にデザインを考えたり、インタラクションモデルをちゃんと考えたりと、楽しかったですね。
当時、アプリ市場は群雄割拠の戦国時代で、その中で勝ち抜くための力が UIUX デザインだと思われていたような雰囲気でした。自分のキャリアやスキルは「実装以外、全部やる」でやってきたので、プレイドに入って「実装をするデザイナーの価値」みたいなものを初めて現場で見て圧倒されました。
どちらが良い、悪いという話ではなく、デザイナーにも（開発者にも）それぞれ個性として強み・弱みがあり、その多様性を互いに把握して共創することが重要ですよね。
一緒に同じものを作っている Progress 感を出す
トークテーマ：メンバーを「デザイナーさん」「エンジニアさん」と呼ばない関係づくり
私はこのトークテーマ、結構ハッとしました。「デザイナーさん」とか「エンジニアさん」って呼んだ瞬間に、主語が大きくなりすぎてそれ以上理解しようとせず、ラベリングが始まってしまうという…。
自分がコードを書かないデザイナーだからっていうのもあると思うんですけど、コードを書かないからこそエンジニアさんと一緒に仕事をするときは一人一人どういう方なんだろうとすごく見るようにしています。
それぞれやはり特性があるじゃないですか。コード書くのはすごく早いけど、コミュニケーションが苦手な方だなと思ったら、PdMとの橋渡しをすることで、スピード感を落とさずに補い合いながら動ける。一緒に同じものを作っている Progress 感を出すというのを大事にしています。相手が苦手なところは自分で補いたい。自分の中で重要視している、働く時の大切なマインドだと思ってます。
福嶋さんが「デザインはデザイナーに任せるには重要すぎる」という有名な言葉があると話されいて、とても印象に残りました。デザイナーが作るアウトプットは感性的に「可愛い」とか「素敵」ということよりも、それを持ってチームが同じ方向に進む為のたたきであることが重要ですよね。
デザイナーができる範囲で材料を持ってきてるだけだから、それに対してプロダクトをもっと一緒に成長させていきたいメンバーがいれば、「その設計こうした方がいいかも」とか「このユーザーだったら、こういうインタラクションがいいよ」とか、そういう意見があってもいいですよね。
「1px は重要か」
トークテーマ：デザインの再現度について、普段の業務の中でどう考えていますか？
たとえば SaaS プロダクトの MVP 検証のシーンでは正直 1px の美しさってあまり重要じゃないんです。「State が正常か」「正常に違和感なく動いているか」「タスクが完了できるか」といった基本的な挙動に違和感がないか、の方が遥かに大切です。
Loading が実装されてない、クリックしたら真っ白でした、とか基本的な操作性が担保できていないと初期ユーザーは落ちちゃうので、美しさよりも挙動の方が大事ですね。それで、”勝ち確”になったら綺麗にしたい（笑）。
デザインシステムで担保しようとはしつつ、プレイドではデザインエンジニアの力に助けられています。「これ実装してやってみたんですけど、ここの状態おかしくないですか」って指摘してくれたり、言わずとも直してくれているケースも多いです。
私が入社した時にはもうデザインエンジニアのメンバーが State 全般は見てくれていて。デザインシステムで改めてルールとして定義して、広く汎化しているという感じでした。
質問：State についてどう考えていますか？
デザイナーが State のことをよく知らない場合、「私わからないです！」と言うところから始めた方がよいと思っています。多少の知見があったら自分の書いた絵で把握できている箇所を可視化する、把握できていない箇所を議論の上で可視化して、素直に教えや協力を求めることができれば、完璧にデザイナーが考慮できなくてもいいと思っています。
そもそもですが、「State が UI デザインを実装していく上で重要だ」ということがデザイナー側の意識にないと、デザインエンジニアとデザイナーの間にある仕事なので、お見合いになってしまいますしね。
デザインシステムを通じて、設計意図の共通認識をつくる
トークテーマ：デザインシステムの構築と運用のなかで、悩んでいることは？
現在 Sour（サワー） というデザインシステムを作っています。
そもそもプレイドではデザインシステムを固く作らないというカルチャーがありまして…これまでは「デザインシステムを固く作ると負債になるんじゃないか」という視点もあり、新しいもの作る時にデザインシステムが制約にならないよう、あえてシステム化を強めずに最低限のルールで運用するという「柔らかいデザインシステム」をやってきた背景があります。
とはいえ KARTE も単体プロダクトからマルチプロダクト化へと進化していく過程の中で、検証を早く回した方が良い段階になってきました。個々にUI を発明するよりは、デザインシステムがあり、コンポーネントライブラリを組み合わせて、速やかに検証できる状態に持っていく。
今の仮説でお客様の要望は叶うのか、タスクが完了できるのか、といった初期検証を早めることが重要になってきました。
こうした経緯で今はデザインシステムを以前よりは固めに作ってはいるんですけども、やはり先に話したような創造性、探索と保守のバランスが非常に難しい…。
トップスピードでプロダクトを作ることがカルチャーにあるので、システム化が追いつかないという問題も。
デザインシステムって最初からゴールデンルールがあるのではなく、実例から共通化できそうなパターンをルール化していく、と言うのがデザインシステムの良いパターンだと思ってます。
理想論でパラシュート的にデザインシステムを作って現場に落としても、結局現場で使われないというケースを沢山見てました。ただ、泥臭い実践知を重ねようとすると、実践した後にデザインシステムに還元するためどうしてもスピード感が合わなかったり…。
課題に悩まされながらも、デザインシステムを作ったことですごく良いこともありました。
デザインシステムでルール化するにあたり「なぜこのデザインなのか？」「なぜこの色なのか？」といったデザインの一つ一つを強制的に言語化したことですね。
ルールがないと、他のデザイナーが読んでもわからないし、開発者も設計意図が分からない。ロジックがわかれば応用がきくじゃないですか。デザインシステムできちんと言語化することで、border の色の明度の理由をデザイナー以外にも分かりやすく伝えることができるようになりました。
そうすると実装する方も「ここはエリアを強調したくないから薄いグレーなんだな」と、デザイナーが絵で指示をしなくても自発的に修正をしたり、一緒に走りやすい環境が作れる。
デザイナーが「どういう狙いでこのようなデザインになってるのか」という背景を、デザインシステムを作る機会以外でももっと話せれば、チームの再現性及び合目的性みたいなものは上がるのかなと実感しております。
以上、「UI＋FE合流点 - UIデザイナーから見た実装の話」についてのイベントログでした！
プレイドからは会場提供も行わせていただき、当日は座談会後にオフィスの芝生スペースにてイベントにご参加いただいた方との懇親の場も設けさせていただきました。
デザイナー、フロントエンドエンジニアの方をはじめ、そのほかの職種の方も交えた“合流点”という機会がつくれたことをひとえに嬉しく思います。
最後に、イベントを通じての鳥越のコメントを掲載し、記事を締めさせていただきます。
イベントを通じて by tori
社内のデザイナーやデザインエンジニアと対話する機会は多いですが、「それぞれのスタンスについて」「再現性について」「ステートの実装について」など話す機会がなかったテーマについて社外の方も含めて改めて議論できてとても実りのある時間となりました。今後は社内でも改めて実務以外の合流点となるディスカッションや対話を増やしていきたいと思いました！
この記事が気に入ったらサポートをしてみませんか？