こんにちは、LITALICOでデザイナーをしているyusukeです。
未経験からデザイナーになりもうすぐ2年が経とうとしています。

ここ最近の私はWebサービスのグロースに関わり、半年ほどで大中小様々な施策を40回ほどアウトプットしてきました。

なかなか価値を発揮できなかった1年目から抜け出すために、どうしたらチームに貢献できるのか、事業の成果につながったと自信を持って言えるのかを日々考え続けていました。

その中で自分なりに考え、行動して学んだことを今回まとめています。

もちろん、事業フェーズや自分のスキルセット、置かれている状況次第では別のやり方で価値を発揮できると思いますので、あくまで私の経験に基づいた話として読んでいただければと思います。

少しでも似たような境遇で同じ悩みを持つ人の参考になれば幸いです。

👤この記事の対象者
事業会社で働く1〜3年目のUI/UXデザイナー

✏️記載した内容
施策を企画から具体に落とし込むプロセスの中で、思考していること、進め方、立ち回り方などをまとめています

はじめに. チーム状況と自分の役割

私は自社のWebサービスに関わり、1→10のグロースフェーズにメンバーの1人としてアサインされています。

メンバーは基本デザイナーの私以外に、PM1人とエンジニア3人です。

施策案をインパクトとタイミング、工数を踏まえて優先度を決め、順々に施策が具体化されていく形です。

私の役割は、PMがこんな目的でこの施策をやりたいと考えた企画を受け取り、要件整理からUI設計までを担当しています。

1. 幅出しのポイントはUIではなく企画の再設計

PMから企画化された施策を渡されるわけですが、ここで意識すべきは
意図を汲み取るだけでなく、背景から理解に務め、時には企画方針の再検討案を提言することです。

意図を汲み取って具現化するだけだと、PMの考えに100%を目指して答えれるが期待以上の結果を出すには至らないと思っています。

大事なのはPMと同じ目線で捉え、自分だったらどうやってこの目的を達成するか考えること。

そう考えられると、そもそも解決策は一つだけでない可能性に気づき、よりインパクトの高い施策を自分の力で創出することができます。

施策を一つ例にとって普段の進め方をご紹介します。
( ※ここから少し具体の話になるので、飛ばしたい方は下へ )

＝＝＝＝＝

最近手がけた施策です。

上の企画を整理するとこんな感じです。

『バイト求人サービスの応募』『ウエディングサービスの問い合わせ』あたりもファネルは似ているのでそちらの方がイメージしやすいかもしれません。

駆け出しの頃の私ならこのように作ってたと思います。

①問題点は、「日程調整に時間がかかってしまって、ユーザーの離脱が発生してしまう」ことだな
②その解決策として「問い合わせフォームで見学日時を聞く」ということか
③ユーザーには直接入力してもらうか、セレクトボックスの方がいいかUIどうしよう...ベスト案はこれかな

しかし、これではベスト案として不十分です。前提を理解しているように見えますが、断片的に捉えてしまっている印象があります。

ここから私の普段の進め方をご紹介します。

まず「見学誘導率をあげたい」という目的に対して「日程調整に手間取っている」という問題定義は合っていそうと自分の中に落とし込みます。（もし問題が不十分なら再定義をおこないます）

解決策ですが抑えておきたいポイントは2つです。

・日程調整のコストを抑えたい
・Webフォームの離脱率をできるだけ抑えたい

これを踏まえると、日程を取得すればいいだけの話ではなく、2つの比重のかけ方でパターンが出せることに気づきます。

今回は上記のポイントから解決策をこのように出しました。

①フォーム上で日程を確定させて調整という概念をなくす。
→ただし、施設側のスケジュール入力・更新ハードルが高い。

②複数の日程を聞いて確認の連絡だけで済ませる。
→ただし、ユーザーの入力ハードルが少し高い。

③抽象度の高い候補日で入力ハードルを下げる。
→ただし、施設側から希望日時を確認する作業が少し発生する。

一見①が良さそうですが、飲食や旅行と違い、施設やブライダルなど見学・相談の対応を業務の一部としておこなっている場合、施設側のスケジュール更新ハードルが高かったりします。

結果は、中期的には①の方法も検討余地はあるが、現状運用難易度が高いと判断して見送り。ですので今回は②の検証を先に行い、予想より離脱が多ければ③を行う流れになりました。

ここでようやく利用者と施設両方の視点からUIのベスト案を考えます。

・入力方法は「記述型」「セレクトボックス型」「タップ型」どれがいいか
・日時候補は第◯希望まで聞くか
・候補日は追加できるようにすべきか　...etc

このように、企画から再設計することでより最適解に近づきやすくなります。さらに今回は、複数案を出したおかげで②の検証結果が悪かった時の③への切替がスムーズに運べる結果となりました。

また、企画を再設計すると別の施策アイデアも生まれやすくなります。

【今回の場合】
・日程調整が問題なら施設側へのアプローチもありそうだ
・見学まで検討していないユーザーには別の分岐を作ってそっちでは解決策③の方法が良いかもしれない　...etc

＝＝＝＝＝

この考え方を身に着けると、企画以上の提案も出しやすくなります。その結果、自分のアイデアが数値に良い影響を与え、見込み以上の結果にもつながります。

それが期待を超える方法の1つと私は考えています。

2. デザイナーも数値感を持つ

視点の一つとして数値感を持つことは大事にしています。
特に意識している点は2つです。

・KPIの現状と目標値を常に把握する
・施策の企画段階で検証効果を予想し、結果がどうかを常に確認する
　例）一覧ページの遷移率5%上がるとして問い合わせ100CV増の見込み

それに対するメリットはこうです。

①なぜこれがベスト案なのか数値を踏まえた事実ベースで提案ができる

幅出し大事と話した一方で、闇雲に出せばいいわけではありません。

リソースは無限ではないのでインパクトの高い施策を１つでも多く検証するためにその押し引きは考える必要があります。その検討材料として数値が必要になってきます。

・重要なKPIに直結するなら複数パターン検証する
・パターンを複数出せても伸び代がないなら仮説でベスト案を決めきる

また、デザイン案を複数出したとして、IMP・CTR・ CVRそれぞれメリデメがあって、仮説的に一番良いのはどれか判断する時も数値感が必要になってきます。

先ほどの問い合わせフォームもそうです。
問い合わせ数を増やすだけなら見学日時なんて聞かない方が良いですが、その先の見学誘導率を高めるなら問い合わせ数下げてでも取得する価値があると判断していました。

タイミングや状況に応じて何がベスト案なのか判断するためには数値感が非常に重要になってきます。

②自らインパクトの高い施策を生み出すことができる

自分も数値にコミットしたいなら、どう作るかだけでなく何を作るかにも関わっていくことが重要かなと思います。

ただし、施策が思いついたとしても「これインパクト高そうなのでやりましょう！」という提案では最終意思決定者に響かず後回しになってしまいます。

そこで使えるのが数値感です。

先ほどあげた『検証効果を予想し、結果がどうかを常に確認』を続けていれば、アイデアの伸び代を感度高く予想できるようになってきます。

どこがボトルネックとなっていて、どんな問題が潜んでいるのか考える。そして、数値で見込み効果を示せれば効率よくインパクトの高いアイデアをチームに提言できます。

＊＊＊

余談ですが、私は数値状況を覚えるのが苦手です。それを補うために、私はKPIツリーを画面遷移図のような形でFigma上に整理しています。（参考までに）

数値は見せられないのでイメージこんな感じです。自分が視覚的に理解できるレベルで整理しています。

先日クラシルの坪田さんが数値感についてツイートされているのをお見かけしました。

もしかしたら認識が違うかもしれませんが、私は上記で述べたようなメリットを感じていますし他にも活用する場面はあるのでデザイナーでも数値感を持って損はないと思っています。

ただ注意点を上げるなら、数値にたとえクリティカルヒットしないとしても体験を磨き込むことも大事にしています。

スピードだけを追い求めると小さな負債がどんどん溜まってしまい、中長期では使いたいと思われないサービスになってしまうので、そこはチームと相談しながらスピードと質両方を担保しています。

3. プロセスを合理的に進める

打てる施策の数を増やせばそれだけ目標に早くたどり着けます。それを実現する要因の1つにアウトプットまでのスピードも大事かなと考えています。

余計な手戻りやコミュニケーションコスト、必要以上に自分一人で考えてしまわない進め方を模索しました。

この半年間経験を積んで、私がしっくりきた小中規模施策のプロセスはこちらです。

①要件整理
②ラフ案作成
③企画懸念点の吸い上げ(PM)
④実装懸念点の吸い上げ(エンジニア)
⑤UI設計
⑥チーム共有&FB
⑦修正
⑧開発

もちろん絶対この流れということはないため、状況や文脈に応じて追加したり減らしたり。

進め方に無駄がなければ、具体までのスピードが高まるのでアウトプットの生産性を底上げできます。

また、チームへの共有方法も2点意識しています。

①MTGかSlackどちらで共有するかはコミュニケーションコストを払ってまで共有の場を作るべきissueなのかで判断

私の使い分け基準はこんな感じですね。

MTG
・認識のずれにより大きな手戻りが発生しそうな場合に合意形成をとりたい
・チームでプロトタイプを触りながらFBをもらいたい

Slack
・ちょっとしたFBをもらいたい
・開発落とす前の最終チェック

周りも忙しく、MTGが明日とかになるとその間停滞するリスクもあるのでSlackで済ませられるならSlackを選択します。

②なぜこのようなデザインにしたのか先に伝えない

わかっていることを指摘されると、それもわかった上でこのデザインにしてますと言いたくなりますよね。

しかし、そこは我慢しましょう。先に伝えた方が話がスムーズだなと思いがちですがそこは言わない方が良いと考えています。

先に余計な情報を与えると、変なバイアスがかかってしまうので素直な意見を引き出しにくくなります。チームに見せるときはユーザーと同じ目線でみてもらえるように配慮することを心がけています。

4. 問題解決に本質的に向き合う

最後は特にデザイナーになったばかりの頃の自分に欠けていたものです。

自分のデザインに自信がなかった頃は、心のどこかで自分のデザインに説得力がない感じが拭いきれずにいました。

では、説得力のあるアウトプットができるようになったきっかけはなんだったのか？

私の場合は、やっていることは問題解決であると強く認識したことです。

どんな問題があるからこの施策をやるのか。そこが根幹であり、じゃあ問題を解決するために仮説としてどんな解決策・体験価値が有効かを考え、それを形としてデザインにどう落とし込むか考える。

そうすれば一貫した捉え方ができるので表層のUIしか考えていなかった自分とはおさらばです。

もう１つお伝えするなら目先の手法に頼らないということ。

手法というのはあくまで手段の１つであり、そこに依存すると何を解決したいかよりも先行して使ってしまう恐れがあり、小手先での対応となりがちです。

どんな問題をどう解決すべきか考えた上で使えそうな手法があれば使うという癖をつけると本質的な問題解決になるかなと思います。

まとめ

事業に貢献できているのか不安な一年目から少しでも活躍するために考えてきたことを紹介させていただきました。

今回はビジネス寄りの話でしたが、テック側では実現性を加味したデザインであったり、デザインシステム的なことも日々試行錯誤しているのでまたの機会に。

上からの指示を作るのに必死だったところから脱却して、自分の言葉で自分の考えで成果を出すためにおこなったものです。

ぜひ考え方の１つとして参考になれば幸いです。

最後まで読んでいただきありがとうございました！