こんにちは、アドベントカレンダー3日目を担当させていただきますカウシェデザイナーのKana Kikuchiです。

突然ですが、デザイナーとひとくちに言っても会社やプロダクト/プロジェクトによって責任範囲ややることが様々ですよね。他の会社さんの採用ページなどを見ていても、この会社さんはこんな風になってるのか！と驚くこともしばしば・・・。

カウシェはスタートアップでリソースも限られているので、各職種の領域も広く、今までよりも1.5倍ぐらい広いような気がしています。
※領域が広いだけで業務量はコントロールされています

そこで、今回はカウシェのUI/UX Designerの責任範囲と、クォーターごとのデザインプロセスについてご紹介できればと思います！

菊池 佳奈 / kana金沢美術工芸大学卒業後、総合広告代理店2社を経てDeNAでヘルスケア事業部に配属される。その後在職中にカウシェで複業を始め、2022年3月に正社員としてジョイン。趣味は映画とペットと遊ぶこと。

目次

目次

デザイナーの責任範囲
クォーターのデザインプロセス
OKRの策定
　Product Unit OKR
　Design Group OKR
課題の分析 / 調査
　分析
　調査
企画
　なぜユーザーストーリーマッピングか？
要件定義
　開発チケット
　他サービスの分析
　MVPと理想を行き来する
プロト / 調査
　クイックな社内テスト
設計・UI・仕様策定〜デザインQA
まとめ
:speaker: そして宣伝 :speaker:

デザイナーの責任範囲

カウシェ Design Groupには以下の３種類のロールが存在しています。

• Product Unit
  UI/UX Designer
  UX Researcher
• Promotion Unit
  Communication Designer

デザイナーの責任範囲の定義は各社様々かと思いますが、カウシェではプロセスにおいて以下の範囲を担えるように定義しています。

• UI/UX Designer
  プロダクトにおけるユーザー体験とそのインターフェースの開発に責務を持つ
• UX Researcher
  プロダクトにおけるユーザー体験のための企画や戦略策定の元となる示唆を得ることに責務を持つ
• Communication Designer
  マーケティングにおける生活者体験とそのクリエイティブの開発に責務を持つ

現状正社員はUI/UX Designerの私1人しかいないため、その他のロールは稼働時間の範囲で複業の方々が担当してくださっています。
今回は私のロールであるUI/UX Designerのデザインプロセスを中心にお話ししていきたいと思います。

クォーターのデザインプロセス

クォーターのデザインプロセスとしては以下のようなことを行なっています。
まずはクォーターが始まる前にPdMと一緒に期中の全体方針を策定し、その後施策ごとに要件定義〜デザインQAまで行なっていきます。

OKRの策定

カウシェはOKRで目標設定しています。
全社OKRは事業計画に基づいてCXOや代表者によって協議され、その後Unit OKR・Group OKRを定めていきます。

Product Unit OKR

Product Unit OKRは基本的にはCPOとPdMが主導となって協議されます。その後その内容がPdMからデザイナーに共有されるので、その背景を理解したり、気になる点についてコメントしたりします。（そのため、全社員が事業上のKPI状況や計画を理解している必要があります）

Design Group OKR

全社OKR・Product Unit OKRが策定されると、Design Group OKRも策定します。全社・UnitのKRに対してデザイナーの方々がどのようなことをやるべきかを定めます。
また、中長期的に事業に必要なこと、例えばペルソナの再定義やブランドガイドラインの改善などもこの目標に含めたりします。（ブランドデザイン領域はカウシェでは現状UI/UX Designer・というか私が兼務しています）
主には以下のような分類となります。

• サービスデザイン全体に関わるOKR
  例：ブランドガイドラインの策定・改善
• UXデザインやプロダクト戦略に関わるOKR
  例：UXリサーチの強化・ペルソナ再定義
• 開発に関わるOKR
  例：デザインシステムの開発・改善
• デザイン組織に関わるOKR
  例：デザイナー採用

課題の分析 / 調査

OKRの策定と並行して、前期中に行なった分析やUXリサーチの内容も踏まえ、課題を特定し、課題に対して打つべき施策を検討していきます。ここで行なった検討が期中の施策の素案となり、Backlogに蓄積されていきます。
分析や調査は主にアナリストやUX Researcherが主導となって実施しますが、デザイナーも以下のようなことを実施しています。

分析

カウシェにはLookerという分析ツールがあるので、足りない情報は自分でLookを作って見ています（あまり強くはありませんが...）
その他、アナリストの方が作ってくれたボードや、以下のようにPromoion Unitの方がSlackに毎日数値のレポートを投稿してくれているので、それらをウォッチしたりしています。

調査

分析によって課題が見えてきた課題に対する仮説立案をし、その検証と深掘りのための調査を実施します。

調査企画・設計
カウシェではUX Researcher以外もユーザー理解のために調査を企画/参加することが多く、以下のような項目の調査企画・設計のテンプレートが用意されています。そのため、これらを埋めていくだけなので、UXリサーチに明るくない人でも調査企画・設計ができるようになっています。（複業UX Researcherの方が作ってくれました！）
私が作ったものをUX Researcherにレビューしてもらったりもします。

• 調査目的
  課題 / テーマ・仮説
  調査内容
• テスト設計
  確認ポイント
  準備
  当日
  事後
• リクルーティング条件
  人数
  カウシェ利用経験
  年代
  性別　等
• インタビューフロー設計
  デプスインタビューを行う場合、各ヒアリング項目の目的やスクリプトを記載
• アンケート設計
  アンケートを行う場合、各項目の目的や質問内容を記載
• 調査結果

その他
最近では、調査実施をスムーズにすることと、お客様の声を定常的に収集していくことを目的に、サービスのメルマガにインタビュー募集の窓口を設けたりしました。

企画

企画の際に使用するフレームワークがユーザーストーリーマップです。
以下のようなmiroのテンプレートを使い、課題となる箇所の体験を改善する企画を策定していきます。

ユーザーストーリーマッピングとは？ストーリー（ユーザーにとっての価値）を付箋紙などに書き出し、ユーザーの体験順に時系列で左右に整理、似た機能は上下（基本機能を上、派生的な機能は下）に整理して壁などにマッピングしていく手法です。 二次元の表に整理することでストーリーの抜け漏れに気づくことができるだけでなく、会話を通してプロダクトオーナーがストーリーに込めた思いを理解することができたり、複数のストーリーを分割する線を左右に引くことでリリース計画を表現することもできます。

https://dev.classmethod.jp/articles/user_story_mapping/

なぜユーザーストーリーマッピングか？

カウシェではスクラム開発を採用しており、よりクイックな改善が行える体制を整えていますが、一方でユーザー体験の”フランケンシュタイン化”が起こっていた時期がありました。
機能はつくれているが断片的な機能の集まりになり、体験としての一貫性が損なわれる危険性がありました。そこで、四半期に一度、PdMと一緒に改修の必要がある箇所のユーザーストーリーマッピングを実施しています。ここで必要な機能や施策を策定し、それらに優先度を付けていきます。

要件定義

期中に入ると企画した施策や機能開発 / 改善を開発していきます。

開発チケット

カウシェでは、以下のような大枠の要件が書かれたチケットが渡されるので、より詳細なものはデザイナーが主導となって定義していくこととなります。
（ただし、簡易な開発ではチケットレベルでほぼ要件定義や画面設計が完了しているので、全ての工程をすっ飛ばしてUIデザインを行うだけで済む秒タスクもあります）

他サービスの分析

他社や競合に類似の機能がある場合はそれらを調査します。
他社のECに当たり前に存在する機能を開発する時は、メジャーなものから海外のものまで収集し、パターン分けしていきます。

逆に全く関係のないようなサービスも参考にしたりします。カウシェはお客様同士が相互に作用する体験を作ることが重要なサービスなので、SNSはもちろん、ライブ配信サービスや動画サービス・口コミサービス・ファンコミュニティサービスなども参考にすることがあります。

MVPと理想を行き来する

基本的にはなるべく最小工数でoutcomeを生み出せるものを定義しますが、ユーザーのコアな体験に関わる機能を作る際は、未来の理想形も見据えて、そのどこまでをスコープにしているかを意識しながら作ります。
そして、膨らみすぎた妄想のまま、大きすぎるスコープを出し、PdMにバッサリ切られることもしばしば（涙）

プロト / 調査

前述の要件定義や後述の設計・UIデザインと並行して、プロトタイピングを元にテストを実施することもあります。
中長期的に変更が難しい機能を開発する場合は、大規模にユーザビリティテストを行う場合もありますが、よりクイックな方法として、社内のメンバーにテストに協力してもらうこともあります。

クイックな社内テスト

開発に関わりのあるメンバーや、カウシェ歴が長いメンバーはバイアスがかかりまくっているので、カウシェに入社したばかりの複業の方や、メンバーの親族・ご友人にお願いします。近頃はリクルーティングに困り、個人のチャンネルで募集したところ、早急にメンバーのみなさんが返信をくれたりもしました。

ただし、社内でテストする場合は他の予定に支障が出ないよう、調査のスコープを絞り込み、テキストベースで5分以内で終わるものを実施しています。

設計・UI・仕様策定〜デザインQA

要件が固まったら画面設計やUIデザイン・仕様の策定を行います。PdMとあーでもないこーでもないと修正していきながらFIXさせていきます。開発版のアプリのデザインQAも忘れずに行います。（よく忘れる！）

また、開発中はFigma上に仕様を置いておいて、デザインと仕様書を行き来しないで済むようになっています。仕様はFigmaのウィジェットであるMarkdown Notesを使ってPdMが書いてくれています。

余談ですが、こういうCaption用のコンポーネントを作り、自分や他のメンバーが見やすいように作っています。パターンが地獄のように多い開発では便利。

まとめ

以上がカウシェのUI/UX Designerが期中に行なっているデザインプロセスです。あなたの会社と比較して、違うところ・共通するところなどあればぜひTwitter等で教えてください💡

🔈 そして宣伝 🔈

そんなカウシェでは現在、UI/UX Designer・UX Researcherを大募集しています！

• 巨大な市場を狙うサービスを自分の手で成長させていきたい！
• スタートアップでより広範囲な領域を経験したい
• PdM・エンジニアとチーム一体となって開発したい！

と思っているそこのあなた、
是非カジュアル面談から気軽にお話ししませんか？

UI/UX Designerのご応募はこちら

UX Researcherのご応募はこちら

Design Groupの採用情報はこちら