2024年3月にDIGGLE1人目のプロダクトデザイナーとして入社し、プロダクト成長をデザイン面から支えられる体制にしていくため、PdMの本田と共にデザインプロセスの構築に取り組んできました。
このようなデザインプロセスの構築に、入社直後から取り組んだ理由は以下の2点です。
予実管理SaaSとして求められる機能はある程度揃ってきており、使いやすさや体験が選ばれる理由として優先度が高まっていた
デザイン組織を拡大するために、成果の生まれるプロセスを実践を通して型化していく必要があった
具体的な背景や取り組みをまとめることで、同じようなフェーズでプロダクト改善に取り組むデザイナーにとって参考になればと思います。
DIGGLEは2016年に創業した、予実管理SaaSを提供する企業です。 2022年にシリーズAでの資金調達、2023年にはデットファイナンスによる資金調達を実施し、累計調達額は約10億円に到達。「DIGGLE」導入企業の拡大とともに社員数も1年で約2倍となるなど、事業・組織ともに拡大を続けています。
DIGGLEを含めた経営管理ドメインでは、2020年頃から様々なサービスが登場しています。競合が続々と出てくるフェーズでは「何ができるか(機能の多さ)」が導入の決め手として重視される傾向があります。
そのため、DIGGLEでも2022年頃までは意図的に「できることを増やす」ことに注力してきました。
ただし、予実管理SaaSとして求められる機能がある程度揃い、他のサービスも同様に機能が充実してきたことで、「何ができるかよりも、どうできるか」といった体験の質が導入の決め手として重視されるようになりました。
このようなプロダクトフェーズの変化に加え、今まで機能を増やすことに注力してきた結果、使いづらさが目立ったり、認知コストが高くなっている課題感もあり、全社的にデザインを重視し始めます。
また、機能拡充が優先されるなか、デザインプロセスも下請け構造になりやすい状態にありました。
本来は「〇〇な顧客体験を実現する」という視点から始まるべきだと思いますが、リリースすべきものが先にあり、それらをいかに素早く提供するかが重視されていました。その結果、細かなユーザビリティや体験が後回しにされやすくなっていました。
また、以前デザイナーが所属していた時期もありましたが、デザインプロセスに型化されたものはなく、製品価値を確実に高めるための再現性のあるデザインプロセスを構築する必要性を感じました。
そこで、プロダクトデザイナーとして入社したタイミングから、PdMと0からデザインプロセスを構築していくことになります。
設計の視点としては、以下の2点を意識しました。
①プロダクト改善手法として最適か DIGGLEはすでにPMFを終え、グロースフェーズにあるプロダクトです。ただし、使いづらさが顕在化している箇所も多数ありました。 この段階でどこから手を付けるべきかを考えた結果、UX5階層の戦略から着手し、コストも不確実性も高い進め方をするより、表層から素早く改善しながら徐々に深い階層の課題を探索していくほうが良いと判断しました。 つまり、徹底的に表層を改善しながら探索していくサイクルを繰り返すことが重要だと考えました。
② オンボーディング手法として最適か 私が入社直後だったこともあり、顕在化している表層面の課題を高速で改善しながら価値を生み、徐々に影響度を高めていけるような流れを辿るのが良いと考えました。 加えて、私はDIGGLEのプロダクトに深く共感して入社しており、DIGGLEがもたらす価値は非常に大きいと信じています。その前提に立つならば、進化の回数は多いほうが良い。 例えば月に20件、Qで60件、年で240件改善ができたら、大きく状況が変わるのではないか。とすると、表層から高速で改善していくことで、1年後には私が信じるDIGGLEの価値が「伝わる」ようになるのではないかと思いました。
このような視点からPdMと議論した結果、以下のプロセスを実践することにしました。 具体的には、2週間をスプリントしたサイクルで、エキスパートレビューによる課題の洗い出し、ストーリーとして改善案を可視化、振り返りを通した中長期の改善方針の具体化を行っていきました。
それぞれのステップで、具体的に取り組んでいたことをまとめます。
エキスパートレビューでは、ユーザビリティ面の違和感を洗い出していきます。
DIGGLEのすべての機能、ページを対象としてプロダクトを触りこみ、次のような視点から大小様々な違和感を見つけてリストアップしていきました。
一般的な業務ツールとして良いとされる体験と比較した違和感を探る
予実管理における理想の業務フローと比較した違和感を探る
違和感を持った後に、その原因を言葉にする時に意識しているのは「今ここでDIGGLEは何をさせたいんだろう?」と、伝えたいことを理解しようとすることです。
もし、何をさせたいのか読み取れない、または読み取れるけれど認知負荷が高いならば、ユーザーにとっても負担が大きくなってしまいます。
リストアップした違和感をもとに、ストーリーという単位で改善案を可視化していきます。具体的なフォーマットは以下です。
タイトル
問題点
対象者
効果
スコープ
UIのBefore / After
全ての違和感に対して作成するのではなく、一定効果が見込まれる点に絞って作成しており、特にエンジニアメンバーが一目見ただけで、なぜ・何を・どう改善したいのか分かることを心がけています。
実際に作成していたストーリーの例をピックアップしていきます。
スプリントを4週ほど回していく中で、合計40個以上のストーリーを作成し、ストックしていきました。
さらに、これらを基にPdMやエンジニアと議論し、効果を見込めるストーリーについては、随時開発ラインに載せてリリースを重ねていきました。
スプリント最終日では、作成したストーリーやプロセスに関する振り返りをPdMと共に行っています。
個別具体のストーリーや発見したことを俯瞰しながら、現象→抽象化→転用というフレームに則ってディスカッションしていくことで、細かな論点の奥にあるクリティカルな課題を明らかにしていきます。
このプロセスをスプリントで繰り返すことで、目先の課題解消はもちろんのこと、中長期の目線でDIGGLEでどんな体験を作っていくべきかというロードマップが生まれ、より大きな価値づくりのためのプロジェクトが進み始めています。
このような取り組みを入社してから3ヶ月ほどコミットしていった結果、冒頭に示したデザインプロセスとして型となり、現在もプロダクト改善が進められています。
さらに、前述の通りすでに表層面でのプロダクト改善が随時進んでいくとともに、探索の結果としてロードマップが生まれて中長期のプロダクト改善にも取り組めています。
これによって、当初の課題感であった「下請け構造になってしまっていたデザインプロセス」を払拭し、DIGGLEの体験の質を高めることに主眼を置いたデザインプロセスへと変化できていることが、大きな進化だと考えています。
このような変化に対して、PdMからも次のような声をもらっており、引き続きDIGGLEをよりよいプロダクトに磨いていくために取り組んでいきたいと思います。
DIGGLEが挑戦している「予実管理」という領域は、業務も複雑であり、まだまだ確固たる手法が確立されていないため、カスタマイズ性の高い領域です。
そんな領域で「これがベストな予実管理だ!」と言える仕組みを圧倒的な使いやすさと共に届けようとしているDIGGLEでは、デザイナーが活躍できる余白が非常に大きいと考えています。
今回は、プロダクトが急成長してフェーズも変わっていく状況で、1人目デザイナーとして、今後の成長を加速させられるプロセスはどのようなものか?を探索し、実践してきた流れをまとめてきました。
このプロセスはあくまで現時点での最適解であり、今後さらに組織を拡大させながらより良いプロセスへアップデートしていきたいと思います。