見出し画像

グロースチームデザイナーの挑戦:デザインフロー明確化とコミュニケーション改善への一歩

ChatworkプロダクトのUIデザインを担当しているsatocaです😀
今回はグロースチームのデザインフローの課題とその解決策、そしてその過程で意識したことをまとめてみました😊


グロースチームのデザインフローの課題

グロースチームでのデザインフローには、主に2つの課題がありました。

1つ目は、【デザイナー自身が施策内容に合わせて動きづらい状態】であること。2つ目は、【他職種から見てデザイン作業が把握しづらい状態】であることです。

【デザイナーが動きづらい状態】とは、以下2つを指します。

1つは、グロースチームの動きがすぐに把握できず、施策に合わせたデザイン作業の対応順序や、必須・任意の判断が難しく、属人化していた状態です。

特に新規メンバーや開発に慣れていない人は、次のステップがわからず立ち止まってしまったり、グロースチームに新しくアサインされた人はフローの把握に時間がかかったりすることが課題でした。

もう1つは、グロースチームの開発における考え方の"前提"が明確に言語化されていなかったため、デザインの進め方に戸惑う状態です。

私の場合は約5年Chatworkで大規模な新機能開発を対応してきたこともあり、「丁寧に・手戻りなく進める」を強く意識した動き方が染み付いていました。
しかし今年からは、グロースチームでアジャイル開発に参加することになりました。そのためグロースチーム特有の「スピード感」や「作成と検証(改善)」を"繰り返すことが前提"であることを意識しづらかったという課題がありました。

この前提のズレが施策のスムーズな進みを阻害することになっていて、もっと早く気づけたらよかった…と反省し、前提をアサイン初期やデザイン作業の過程でも意識できる工夫が必要だと考えました。

2つ目の課題、【他職種から見てデザイン作業が把握しづらい状態】とは以下を指します。

「レビューのタイミング」や「タイミングに合わせたレビュー視点」がデザイナーからPdMに対して明確に提示できていなかった状態

これはデザインフローの属人化も影響しており、PdMがレビューし辛い状況になっていました。


デザインフローの改善とその結果

これらの課題を解決するために、グロースチーム用のデザインフローを整えました。
ざっくり、フローは以下の通りです。

  1. PRDの確認

  2. UXUI要件整理〜機能要件整理

  3. PdM・エンジニアレビュー

  4. ワイヤーの作成

  5. PdM・エンジニアレビュー

  6. 詳細デザイン作成

  7. PdM・エンジニアレビュー

  8. UIチームレビュー(UIデザイナーによるFigmaデータや仕様書の確認)

  9. UX毀損回避チェックリスト対応

各デザイン作業とその流れを矢印を利用してまとめた縮尺図
miroで作成したフロー図

このフローは⁨⁩、Chatworkの開発を担うプロダクトデザイン部で活用している『MONDRIAN』という独自デザインプロセスを基盤にしています。
『MONDRIAN』は初心者デザイナーにも分かりやすく、UIデザインの手順を丁寧に踏めるようになっています。
これを基盤とし、グロースチームの課題解決に特化させつつ、ポイントを抑えた短縮版フローを設計しました。

『MONDRIAN』自体の詳細は別記事にまとめていますので、興味がある方はそちらを参照ください😀


デザインフロー改善における意識点

デザインフローを変更する上で、意識したことは3つあります。

まず1つ目の課題にあった「グロースチームの動きがサッと把握できずスムーズに動きにくい」に対し、必須・任意を色やテキスト情報からパッと見て把握できるように変更しました。以前は色分けしかなかったため、色の意味を覚えたり都度確認する必要がありました。

例として必須作業はFigmaで詳細デザイン作成をすること、任意作業はプロトタイプの作成を並列させた図
色とテキスト情報で分かるように

また「 グロースチームの開発における考え方の”前提”が言語化されておらず、進め方に戸惑う場面があった」課題に対しては、デザインスプリントのような「作成と検証(改善)」を繰り返すことを図で表現しました。
加えて、この前提が重要である点は認識漏れにならないよう、口頭でチームメンバーに伝えました。

必須作業であるワイヤーフレームの作成とPdMのレビューやエンジニアレビューを繰り返す図
ステッカーを使うことでフロー全体の情報量を調整


最後に「他職種視点でデザイン作業が把握しづらい状態」の課題に対しては、デザイン作業の現在地や「いつどのようなレビュー確認があるのか」「何のためのレビューか」が誰でも分かるようにしました。

具体的には、デザイン作業だけでなく、レビュータイミングをステップとして明確にフロー図へ反映したり、それに対する目的を言葉にしました

レビューにおいては、デザイナーがレビュー依頼時に意識することをTipsとして明記し、知見がチームに広がることを意識しました。
(Tipsの例:現在のデザイン作業の状況や、今回のレビューで確定しておきたいポイントを依頼時に伝えること…etc.)

必須作業のPdMレビューやエンジニアレビュー、任意作業のデザイン部レビューの目的やTipsを記載したフローの縮図
各デザイン作業に目的やTipsを記載した様子


これらの改善により、デザイナー間でも・チーム間でも「同じものを指差し確認できる」状態となり、チーム内の認識を合わせやすい環境作りが整いました。
これで、ようやくスタートラインに立てた気がします😤
ここからは定期的にメンバーへヒアリングし、新たな課題が出てきたら、グロースチームらしく作成・検証(改善)を繰り返していく予定です✨💪


おまけ:フロー改善に挑戦してみた感想

今までの私は施策対応に全集中してきましたが、今回は施策対応を最優先としつつ、時間を見つけてフロー改善に対応する必要がありました。
スムーズに進捗を出せるだろうか…と不安を抱きながら対応していましたが、振り返ってみるとフロー改善の動きはシンプルでした。

やることの確認(要件)・スケジュール立てしたのち、課題やフロー改善で期待されていること(要求)の把握・解決案の検討….
改めて書いてみると、施策を進めるときと同じ流れでした👀

また、最初から綺麗に作り込む…よりはラフに作って関係者に見せる、を意識して進めていました。
これもデザイン作業で「こまめに進捗を見せる・レビューに出す」ことで、期待に応えたアウトプットを作成していく事と同様です。

実はnote記事の作成でも、私はデザインフローに則って要件・要求整理をしています(その方が、伝えたいことを最後まで漏れなく書き切れるので…)。

デザインフローは、デザイン以外の作業でもスムーズに進める手段として、可能性を持ってそうですね😃🌷



全職種OK/聞き専OKなオンライン会社説明もあるそうです😮
直近の開催は以下の通りです。
5月16日(木)19:00~20:00
5月27日(月)19:00~20:00