Simplexのデザイン組織である『Alceo』では、クライアント企業から依頼を受け、アプリやWebサービスの体験のリサーチ、プロダクト改善を一緒に進めています。
例えばこれまでにも、大手証券会社など、大規模なクライアントのアプリやWebサービスのリニューアルといった案件に取り組んでいます。
サービスデザインから開発、そしてグロースハック、運用保守までを一貫して扱うAlceoで、リサーチした情報をどのようにプロダクトの開発に反映しているのかについてまとめてみます。
Alceoに依頼をいただき、2022年5月にリリースされた野村證券様の資産運用アプリ「NOMURA」のリニューアルに取り組みました。
アプリ自体は以前からリリースされていたのですが、アクティブになっているユーザーは、金融資産運用にもともと積極的なユーザーがほとんどでした。
そこで、今は金融資産運用をしていないアクティブではない層のアクティブ化を課題として、Alceoがリニューアルに関わることになりました。
体制としては、Simplexからデザイナー（Alceo）が3名、エンジニアが15名、先方からプロダクトオーナーの方が1名、他数名、という大規模なチームでスクラム開発を進めています。
先方のプロダクトオーナーと、Alceoのデザイナー3名、エンジニアが15名という体制で進めた
アプリリニューアルまでは、大きくは以下のようなステップで進めていきました。
==
1. 企画フェーズ
ヒアリング
プロトタイピング
ユーザーインタビュー
アプリのコンセプト・MVPの検討
プロトタイプのアップデート
ユーザーテスト
アプリのコンセプト・MVPの決定
UIデザイン作成・開発用デザインリソース整理
開発範囲の決定(ユーザーストーリーマッピング)
2. スクラム開発フェーズ
開発準備
リファインメント→プランニング→レビュー→レトロスペクティブ→…
プロダクト振り返り
3. グロースフェーズ
行動データ分析
定性コメント分析
２週に１回 リリース
==
ここからは特に、何を開発するかを決定する企画フェーズでの、リサーチや、開発との連携部分で行っていることを具体的にまとめてみます。
まず、開発範囲を決定するための動きとして、短い期間でプロトタイプとユーザーテストを高速で行っていきました。
Alceoでは、1人のユーザーテストの結果をもとにすぐプロトタイプを改良・変更して、また次のテストを行う、スピーディーなリサーチを行うことが多いです。
今回のプロジェクトでは、最初の提案時に20アイデア、40画面案をつくり、そこから3案に絞ってユーザーテストを行いました。
1人のテストの結果を受けて、別のプロトタイプをつくって、また別の人にテストして、改変して、、という流れで進めていきました。
20以上のアイデアから絞ったプロトタイプを、1人のユーザーにテストして、その結果を受けてすぐにまた改善し、別の人にテストしてまた改善して、、という素早い改善を繰り返していく
このようなプロセスは、とにかく速く正しいUIに辿り着くために行います。
例えば、複数人に対して同じプロトタイプを見せてみて、また改良して複数人にテストして、、というやり方もあると思いますが、どうしても時間がかかり過ぎてしまいます。
なので、速く実験を行い、具体物ベースでどんどん前に進めていけるように、このようなプロセスを取っています。
この段階でのテストの結果をもとに、最初のリニューアル範囲を決めていきます。
リサーチの結果をもとに施策の方向性をまとめます。
関わる人数がかなり多く、一つ一つのリサーチ情報を丁寧に伝えてもあまり浸透しない一方で、背景が伝わった状態でなければ、体験と実装を一貫させることができません。
そこで、Alceoでは「コンセプトシート」「リサーチ情報を見返すしくみ」という2つのしくみを取り入れています。
開発チームに対して開発範囲を共有する時は
アプリとして目指すこと
そのために必要な体験
そのために必要な機能
そのために必要な最低限の体験
を一つの資料にまとめた、コンセプトシートというものをつくるようにしています。
アプリ全体で目指すこと、そのために必要な体験、そのために必要な機能、という流れで論理立てて全体観を伝え、「なぜこれをつくる必要があるのか？」が開発メンバーに伝わるようにしている
ただ機能の仕様だけ伝えるのではなく、なぜこれをつくるのか？を解像度高く伝えることで、実装段階でも「ここはもっとこういう実装の方が良いのでは？」「こういう方が実装コストが軽くて、価値も落とさなくてコスパいいと思います！」という声が開発メンバーから起こるようになります。
「これをつくってください」とトップダウンに進めるのではなく、アプリ全体でつくりたい感情や、機能を通して届けたい体験をつなげて伝えることが、早くユーザに価値を届けて検証するために重要だと考えて、コンセプトシートという形で伝えています。
資料の中では、コンセプトに対して、MVPはこのような機能を想定している、というところもまとめています。
ある体験に対して、どういうMVPで満たそうとしているか、なぜこの機能をつくるのか、を丁寧に論理立てて伝える
コンセプトシートの中では、具体的なユーザーテストの情報はあえて載せていないのですが、もし知りたい時には誰でも過去のリサーチ情報を見返すことができるように、蓄積のしくみも整えています。
例えば、以下のようにMiro上で、ユーザーテストの結果を、人別・項目別に見れるように整理しています。
人ごと、項目ごとにユーザーテストの情報を整理した
開発メンバーとしては、必要としていないタイミングで、一気にすべてのリサーチ情報を伝えられても解釈が難しいはずなので、コンセプトシートで抽象化して伝えた上で、もし具体的な情報が必要になったら見返しやすいように整理をしています。
コンセプトをもとに、具体的な開発範囲をすり合わせていきます。
アプリのフルリニューアルのような大きなプロジェクトになると、ユーザー側・開発側・クライアント側と、それぞれの要望が入り混じってしまい、開発範囲が膨大になりがちです。
そこでユーザーストーリーマップをつくりながら、ユーザー目線での必要な体験、開発目線でのコスト部分、クライアントの要望、のそれぞれを踏まえて第一開発スコープを決めるようにしています。
最小限で、確実にユーザーに使われる、最初の開発範囲を決定する
Alceoでは今回のようなプロセスを意識して、初期段階からユーザーへのテストを繰り返し、そのリサーチの結果を開発メンバー、クライアントにも高い解像度で共有することで、ユーザーが求める体験・実装・クライアントにとっての価値を一貫させることに取り組んでいます。
例えば、他にも複数の案件を、今回のようなアジャイルでユーザーを中心とした開発プロセスで進めています。
クライアントの方からも、アプリリリース後にAlceoでの進め方に対して共感する声をいただいています。
良い意味でクライアントワークらしくない、アジャイルな開発プロセスを、Alceoのらしさとしてより強めていきたいと思っています。
