デザイナーLT＆交流会に行ってきた！（BASE×ノハナ×マネーフォワード×みんなのウェディング）

先日、渋谷で開催されたデザイナーLT＆交流会に行ってきました。

マネーフォワード、nohana、BASE、みんなのウェディング…の４社から、それぞれのデザイナーさんが「サービスの成長」をテーマに登壇されるということで、とても豪華なラインナップでした。

実はLTイベントというものに初めて参加してみたのですが、本当に素晴らしい内容で、こうしてブログを書きながら「行ってよかったな〜（しみじみ）」と思った次第です。

そこで今回は、会場で取っていたメモを元に、わたしが特に印象に残っているところをご紹介したいと思います。

イベント概要

「サービスを成長させる！インハウスデザイナー４社のお仕事トーク」ということで、 

• マネーフォワード
• nohana
• BASE
• みんなのウェディング

の４社から、各社のデザイナーさんが「サービスの成長」をテーマに開発現場での取り組みについて紹介するイベントでした。

『デザイナーのための自分サービス開発のススメ』（BASE/早川宗亮さん）

最初の登壇者は、BASEの早川さんでした。

早川さんは、『デザイナーのための自分サービス開発のススメ』についてお話されていたのですが、とても共感を覚えたLTでした。

デザイナーが技術を学べばコミュニケーションが円滑になる

まずテーマの背景として、BASEのデザイナーさんはビジュアルデザインだけにとどまらず、フロントエンドからWebサービスの構造の把握まで幅広く手がけられています。

例えば、普段はRedmineでユーザーからの要望やバグ等をまとめて管理していますが、チケットの粒度が小さいものなどはデザイナーが実装するところまでやってしまう。

あるいはデザイナーだけで手に負えないような案件は、エンジニアにAPI側の実装を簡単に仕様をまとめて提案します。

このとき、自分で実装するにせよエンジニアに依頼にするにせよ、デザイナーがDB構造等も理解していればエンジニアに提案もしやすいし、話がスムーズに進むのだそうです。

そこで、デザイナーもフロントエンドの実装やDB構造といったWebサービスの仕組みについて学ぶために手っ取り早いのが「自分で何かサービスを作ってみることではないか」ということにつながります。

ビジュアルデザインだけでは「絵に書いた餅」になりかねない

このお話は、わたしにとってかなりドンピシャでした。

というのも、わたしも最近「やっぱり技術側のことをもう少し分かっていないと、Webサービスのデザインするのにつらみがあるな…」と思っていたからです。

例えば、最近わたしが携わったアプリ制作の仕事でも、「こういうときのレイアウトはどうなる？」「こういうときはエラー文言をどこに表示する？」といった必要なパターンが、デザインの段階で拾えていないことが多くありました。

往々にしてデザイナーがSketchなどで作るビジュアルデザインは、「一番キマってるときの状態」しか表現できていません。

プロダクトとして成立させるために必要なパターンも考慮できるようになるためには、技術の理解も必要だと、そのとき実感したことを覚えています。

自分でWebサービスを作ることで得られるメリット

最後の方で、Webサービスを作ってみて実際に感じたメリットを３つ紹介されていました。

• Webアプリの構造が分かるようになる → 自社プロダクトへの理解が深まる
• 自分のサービスだから失敗しても怒られない → 得た知見を会社にいかせる
• 自由にデザインを楽しめる！

なるほど、こうしてみるとプライベートでの開発でも、会社の業務に活きてくることが分かりますね。

わたしも、自分でWebサービスを作ってみたくなりました。

『サービスが成長できる環境にするための取り組み』（ノハナ/高橋愛未さん）

続いてノハナの高橋さんは、『サービスが成長できる環境にするための取り組み』についてお話されていました。

高橋さんのお話の中でわたしが印象に残ったのが、「チームの構成」と「ドッグフーディング」についてです。

職能部制と事業部制、どちらが良い？

ノハナさんは、以前は職種横断的な組織だったのですが、最近はプロダクトチーム制（事業部制）になったのだそうです。

高橋さんは、プロダクト単位でメンバーを分けた方が、皆が同じ方向を向いている感覚を持ちやすいので好きだとおっしゃられていたのが印象的でした。

わたしも、職能部制よりは事業部制の方が好きです。

理由としては、やはり連帯感が出やすいということと、事業部制の方が「ヒトよりモノ」に意識が向かいやすいのかなと思っています。

例えば、職種で分けてしまうとスケジュール等の利害関係が対立したり、複数の仕事を掛け持ちするので、他の人がどんな仕事をしているのかが見えにくくなりがちではないでしょうか。

その点、プロダクト単位でチームを分ける事業部制なら、デザイナーやエンジニアといった職種に関係なく「このプロダクトを作るぞ！」と同じ方向を向いて密に連携を取りやすくなります。

そのため、働いていて楽しいのはこっちかな…と思っていました。

しかし、実際にはリソース不足で複数のプロジェクトを掛け持ちせざるを得ない場合も会社によってはあるのかなと思うと、なかなか難しい問題ですね。

あらためて、チームのあり方について考え直すきっかけになりました。

UXを体感するためのドッグフーディング

もう１つ興味深かったのが、ドッグフーディングランチという取り組みでした。

ノハナはスマートフォンで簡単にフォトブックを作成し、注文までできてしまうサービスなのですが、ドッグフーディングランチでは、外でランチを食べながら皆さんでフォトブックを作られているのだそうです。

ここで高橋さんがおっしゃられていたドッグフーディングの良いところとして「UIの良し悪しではなく、UXとして体感できる」という点がとても印象に残りました。

ノハナさんのような「フォトブックが実際に届く」という、サービス全体を通した体験がアプリだけに留まらないような場合、UIだけを近視眼的に見るだけでは、確かにサービス全体の質を上げることはできないのでしょう。

とても納得しました。

『サービスを成長させるためにデザイナーが取り組んでいること』（みんなのウェディング/今泉歩美さん）

３人目にご登壇されたのは、みんなのウェディングの今泉さんでした。

今泉さんのLTの中で最も印象に残ったのは、既存ページの改修でA/Bテストを行ったというお話でした。

仮説を立てて新しいデザインを試す仕組み

みんなのウェディングの既存ページ改修の例で、式場を探し始めたばかりのユーザーは、雰囲気から直感的に好みに合うかどうかで式場を選ぶのではないか…という仮設が持ち上がりました。

そのため、今までテキストメインだった式場一覧の画面を写真が見やすいデザインに変更してみたのだそうです。

このときは、表示率10~20%程度で新しいデザインパターンをA/Bテストにかけたとのこと。

もちろん１回の施策で数値が改善するとは限らないので、様々なデザインパターンをテストしながらPDCAを回していきます。

• 既存の効果を下げないように、新デザインを試す仕組み
• １回で勝てる確率は低いので、デザインパターンはたくさん用意して試す

といった２つの観点は、これから自社プロダクトでUIデザインのA/Bテストを試したいと考えているチームにとっては非常に参考になるのではないでしょうか。

わたしも、この「表示率10~20%」という数値は、ぜひとも覚えておきたいと思います。

アプリの画面遷移は少なくすべき

もう１つ、「LINEで相談する」ボタンについての失敗談をお話いただいたことが印象に残りました。

経緯としては、みんなのウェディングで新しい取り組みとして、LINEで相談できる…という施策を試すべく、「LINEで相談する」というボタンを実装しました。

その際、ユーザーが「このボタンを押したらどうなるの？」というのが分かりづらいのではないか…という仮説が持ち上がり、モーダルで詳しい説明文を出してみたものの、結果的にはすぐに閉じられて離脱されてしまったのだそうです。

こうした失敗を経て、改めて画面遷移はできるだけ少なくすべきなんだな…という気づきをお話くださいました。

これはとても参考になりますね…！

モーダルウィンドウというものは、基本的にはユーザーの操作のコンテキストを遮断してしまうので、ユーザーに何か特定の操作に集中してもらいたいときに使うものなのですが、多用したり間違った使い方をしてしまうと、ユーザーはモーダルから先に進んでくれなくなります。（参考：モバイルデザインパターン）

モバイルデザインパターン 第2版 ―ユーザーインタフェースのためのパターン集

やはり、こうした実際の事例をお話いただけることはすごく貴重なことなので、ありがたいなと思いました。

『メディアリニューアルまでのあしあと』（マネーフォワード/大橋瑞生さん）

最後にご登壇されたのは、マネーフォワードの大橋さんでした。

大橋さんは、マネーフォワードの運営するマネープラスというメディアについてお話くださいました。

UI改善で回遊率が3.2倍に！？

マネーフォワードには以前から自社メディアはあったそうなのですが、これまでのリニューアルの段階ではPVが伸び悩んだままだったのだとか。

しかし、今回のリニューアルによって定量・定性両方の効果を出すことができたのこと。

例えば、UIと表示速度の改善により、

• 回遊率3.2倍
• 離脱率10%以下に

といった効果が得られたのだそうです。すごすぎる…！

プロセス可視化の重要性

大橋さんのLTで印象に残ったのは「プロセスの可視化」という言葉でした。

というのも、以前までは「誰にどんな価値やサービスを提供するのか」といった認識がバラバラだったのだそうです。

しかし、今回のリニューアルを行う段階で、例えばサービス価値の可視化を行うためのワークショップを開いてみたり、配色ルールといったデザインのプロセスを共有することで、皆が認識を合わせることができ、リニューアルの成功につながったというお話がとても参考になりました。

プロセスを可視化することは、チームビルディングにもつながるのかもしれませんね。

おわりに

LTイベントには初めて参加したのですが、改めて本当に素晴らしいイベントだったと思いました。

４名のご登壇者の発表はとても洗練されていましたし、様々な知見が凝縮されていたので、発表中はメモを取るためのタイピングの手が止まりませんでした。

またこうしたイベントがあったら、参加してみたいと思います。