FORCAS UIデザインのお仕事紹介

こんにちは。株式会社ユーザベースでFORCASのUIデザインを担当している大久保です。

FORCASは「未来のマーケティングを共創する」をビジョンに掲げ、B2Bに特化したABMプラットフォームを提供しています。
https://www.forcas.com/

FORCASは生まれてからもうすぐ４年。まだまだ道を模索しながら日々機能開発をしています。
B2Bサービスはプロダクトに直に触れられないことも多く、身近に感じにくいですよね。今回は少しでもリアルに感じていただけたらと思って、FORCAS UIデザインのお仕事の進め方を紹介をさせていただくことにしました。

案件のはじまり

案件のはじまり方は一定ではありません。毎日社内メンバーやユーザーさんから上げていただく課題から始まる場合、リサーチや合宿から始まる場合など様々です。
決定した案件はチケットに分解されてエクセルのバックログで管理されます。

FORCASのバックログ

例えばWeb名寄せ機能の開発はGoodpatchさんとのユーザーリサーチプロジェクトを受けて始まった案件ですし、ターゲットフラグ機能は社内メンバーが作成していたエクセルを基に開発されました。

大きな案件では、その機能が解決するユーザーの課題はなにか？他のプロダクトや他の機能と違う部分はどこか？といったエレベーターピッチを用意して目的がずれないようにして始めます。

エレベーターピッチのテンプレート

私がB2Bサービスのよいところと思っているものの１つに、ユーザーさんとの距離がとても近いことがあります。名前を聞いてお顔の浮かぶユーザーさんが何人もいてくれます。AさんとBさんからこういった声があがっていて、FORCASとしても作っていくべき機能だからやろう！という会話が度々発生しています。ユーザーさんの声から始まる機能開発は少なくありません。

ちなみに、ユーザーリサーチには担当のリサーチャーがいるわけではなく、その時々で必要なメンバーが行っています。新しいプロダクトをつくるとき、プロダクトの方向性に迷った時などなど。つまりデザイナーも必要とあらばいつでもユーザーさんの声を聞きにいくことができます。

仕様とUIの策定

プロダクトオーナー、PdM、エンジニアメンバーと一緒に仕様を策定します。オブジェクトを整理するところから始めたり、いきなり画面を作るところから始めたり、スタートは規模によっていろいろです。

進め方も人それぞれですが私の場合を紹介します。

まずPdMと関係するエンジニアメンバーで仕様案をまとめます。
私は見えるものをみんなで叩いて直していくのが好きなやり方なので、抽象的なところから始めても、会議には画面を持っていくようにしています。
理想案を作って持っていき、課題を解決できているか、実現可能か、工数はどれくらいかなど解像度を高めて案にまとめます。

オブジェクトを整理する

そのあとはプロダクトオーナーと仕様を決める会議で仕様を確定します。ここでフィードバックがあった場合は１つ上の段落の作業に戻ります。
こちらの会議はグループのSaaSプロダクトであるSPEEDA、FORCAS、FORCAS Salesの共同開催なのでプロダクト横断でどんな機能が開発されているのか、どんなフィードバックがあったのかなどの知見もたまります。（やり方はどんどん改善されるためこの記事がアップされる時にはすでに変わっているかもしれませんが！；）

弊社にはCS（カスタマーサクセス）というお仕事のメンバーがいます。FORCASを導入してくださったユーザーさんがFORCASを活用してご自身のお仕事の成果を上げられるよう、3ヶ月の導入支援プログラムやサポートを行なっています。
仕様を考える際、CSメンバーがユーザーさんにご案内する方法、導入支援プログラムへの影響はどれくらいあるのかという視点でも会話をしています。

実装

FORCAS担当のデザイナーは２人ともコーディングをするので、実装以降にも関わります。

エンジニアメンバーと相談しながら同じブランチで作業します。FORCASはまだページ数が少ないこともありコンフリクトが怖いので（何度かやらかして迷惑をかけました、、、）どの範囲をどの期間触るか朝会などで共有してから始めます。
CSSや軽い変数の追加などは１人で作業しますが、複数のコンポーネントに渡ったり、ちょっとでも不安に思ったらエンジニアにペアプロをお願いして一緒に作業します。私はPHPさえ堅めに感じるゆるめのｼﾞｬﾊﾞｽｸﾘﾌﾟﾀｰなので勘所を教えてもらうことも多くてとても楽しい時間です。

CSSコーディングはコーディングルールを基に行います。（なお先日作ったばっかりの出来立てほやの初期版です）コンポーネント設計、ディレクトリ構成、命名規則、CSS・Sass記述時の注意事項を盛り込んでいます。

コーディングルール

テスト

テストエンジニアが用意してくれたテストケースを確認してテストをお願いします。
テストエンジニアも案件のはじまりから関わっていて、ケース作りは先んじて行なってくれているのでおんぶにだっこです。（いつもありがとうございます、、、）

テストエンジニアからバグや想定外の挙動があがってきたら、対応するかしないか相談して、要対応の場合は再度実装の手順に戻ります。

リリース

リリース作業自体はエンジニアに担当してもらいますが、エンジニアのほぼ関わらないデザインだけのブランチの場合はこちらから声をかけ、リリース予定に組み込んでもらいます。
その際、リリースノートの作成や、事前にユーザーさんへのお知らせが必要か否か、どこかのリリースに混ぜ込むべきか、単独でリリースすべきかなどの観点で相談します。

実際にリリースした際には、提案をしてくれたユーザーさんからありがとうの声を聞くこともできてとても嬉しいです。逆に使いにくくなっていないかハラハラする瞬間でもあります。

おわりに

まとめてみるとなんだか整然と行われているような書き口になってしまいましたが、緊急性の高いチケットの差し込み、仕様の検討漏れなどはやはり発生します。そういう時はとにかく会話です。ほぼリモート勤務となっている現在では、Discordに集まってはわちゃわちゃと認識合わせをやっています。

みんなでわいわい相談しながら、案件のはじまりから終わりまで関わってデザインしたい方、よければこちらのページをチェックチェック。お会いできる時を楽しみにしております。

ところで先日、私の所属する株式会社ユーザベース SaaS Design Division はDESIGN BASE というデザイン組織名を作りました。
DESIGN BASE MAGAZINEには他のメンバーの記事もたくさんあります！ぜひご一読ください。