見出し画像

BtoBのUIデザイナーってぶっちゃけどうなん？

BtoB SaaSのデザイナー たなか

こんにちは。
物流や金融系のSaaSを経て、現在は製造業向けSaaSのUIデザインに従事している、たなかです。

わたしは、BtoBの領域が自分のスキルセットや志向にもマッチしていて、楽しんで取り組んでいるのですが、世の中的にはあえてBtoBのUIデザイナーを志望する人は非常に少ないようです。

わたし自身も、過去に採用活動を行う中で、多くのデザイナーの方とお話をする機会がありましたが、「最悪、BtoBでもいいか」くらいのテンションの方が主で、「BtoBチャレンジしてみたいです！」と強く志望されている方はほぼゼロに近かった肌感です。

この背景には、BtoB SaaSの開発というものが、圧倒的にイメージが持ちづらい、というのがあると思いますので、自分自身が、toCサービスの開発を経て、BtoBにチャレンジしてみようと思った時に感じた不安・疑問に対する答えをシェアしていきたいと思います。

わたし自身の経験は、いずれもフェーズが若めで、かつ、どんな会社でも汎用的に使えるhorizontalなSaaSというよりかは、特定の業界に向けたverticalなSaaSに寄っているので、偏りがあるという点はご留意ください。

ぜひ、良いところも悪いところも知っていただいたうえで、「あれ、もしかしてBtoBもありかも？」と思っていただけたら、一緒にBtoB SaaS界隈を盛り上げていきましょう！


BtoBのデザインで発生する可能性がある仕事

まず、デザイン業務としてどういうものが発生する可能性があるかをあげていきます。

どこまでを担当することになるかは、会社、チームの体制や個々人のスキルセットにもよると思うので、ここでは特に区別をつけないでおきますが、もちろん、ひとりですべてをカバーできる必要はありません！

  • 顧客の課題整理

  • プロダクトの仕様検討

  • サービスブループリントなどの作成

  • 顧客インタビュー / ユーザビリティテスト

  • デザイン原則、コンポーネントの使用ルールなどの策定

  • 画面のデザイン

  • storybookなどのコンポーネントライブラリの運用

  • QA

  • リリースメールの作成

  • 施策の振り返り、効果分析

  • ヘルプサイトの運用

  • コーポレートサイト / サービスサイトの運用

  • サービス紹介動画の作成

  • 営業資料、オンボーディング資料のブラッシュアップ

  • ホワイトペーパーの作成

  • セミナーのサムネイル作成

  • 展示会用の装飾、チラシ作成

  • 業界誌に載せる広告の作成

  • VC向けのプレゼン資料 / 株主向け資料のブラッシュアップ

toCのサービスと大きく変わらないところも多いと思いますが、展示会や業界誌などが絡んだ仕事があるのが特徴的ですね。


ここからは、BtoBの世界に飛び込むにあたって、自分自身が不安・疑問に思った点と、それらに対する回答を挙げていきます。

🤔 〇〇業界の知識がないと難しそう

企業で経理の方が使うようなシステムであれば簿記・会計の知識、建設業界で使うようなシステムであれば建設業界での業務経験など、業界の知識がないとまったく仕事についていけないのではないか…？という不安があるかと思いますが、この心配はまったく不要です！

デザイナーやエンジニアはもちろん、営業などビジネスサイドの方であっても、対象となる業界出身の方はむしろ少ない印象です。

入社後、間もないころは洪水のように情報を浴びることにはなりますが、1ヶ月もあれば、かなり知識の武装はできてくると思います。

ただ、入社後オンボーディングでお客様の業務フローやプロダクトの説明はPMなどからしてもらえるとはいえ、その後ただ待っているだけではなかなか、知識がついていかないので、

  • プロダクトをいろいろ触ってみた上で質問会を開いてもらい、仕様の不明点や、なぜこういう画面になっているのか（業務フローとどう関連しているのか）などを、根掘り葉掘り聞く機会を設ける

  • 営業やCSの方々と挨拶がてら1on1をしつつ、導入前のお客様との商談や、導入後のお客様との定例・振り返りMtgに同席させてもらえないかお願いする

  • 社内での、商談中のお客様にどのように運用フローを提案するか、を相談するMtgに同席させてもらう

などの動きを積極的にしていくのがオススメです。


🤔 成果がわかりにくそう

例えばECサイトであれば、カートページのUIを少し改善しただけでも、購入・離脱率などの数値に分かりやすく、ダイレクトに影響してくると思いますが、業務上必要に迫られて使うBtoBの業務システムでは、細かいデザイン変更の成果というのは、確かに数値ではわかりにくい印象です。

企業との面談時に「効果分析をしながらデザインの改善ができるか」と聞けば「お客様の反応をちゃんと分析しながら改善進めてますよ」という回答が返ってくると思いますが、実際に精緻な分析ができているケースはまれで、toCのサービスと比べると、数値分析の仕組み導入の優先度が低いことも少なくないと思います。

機能によっては、あるタスクをはじめてから完了するまでにかかった時間をイベントの発生日時などから算出して分析、みたいなことはできると思いますが、日常的な施策の評価としては、リリース後のお客様からのフィードバックや、特に課題が大きかったお客様へのヒアリング、状況設定した上でのロールプレイなどの、定性情報をよりどころにすることが多いと思います。

もう少し大きい単位で見ると、

  • 自分たちのプロダクトがどうあるべきで、いま現在地がどこであるか

  • 各セグメントやカバーすべき業務領域に対して必要な機能がこれだけあって、いまどこまでをカバーできているか

  • 競合他社のプロダクトに対して、どのようなメリットが訴求できる状態であるか

  • 単なる費用削減だけでなく、より本質的な業務改善のインパクトを出せているか

などを確認しながら、開発を進めていきます。


🤔 気軽にインタビューがやりづらそう

toCのサービスを利用する個人へのインタビューと比べて、企業で働く人へのインタビューとなると敷居が高いのではないか？気軽に応じてもらえないのではないか？と思っていましたが、この心配はまったく不要です！

お客様への打診の一手間はかかるので、ビジネスチームの方々との間で気軽に相談し合える関係性は構築しておく必要がありますが、むしろお客様からは「意見を言う機会ができてラッキー」と喜んでいただけることも多いです。

プロダクトの使い勝手はもちろん、普段の業務の話など、勉強になることばかりなので、積極的にお願いしていきましょう。

ただし、お客様にももちろん業務がありますので、

  • 繁忙期などを考慮して計画すること

  • こちらから聞きたいことを聞くだけでなく、「あえて問い合わせはしなかったけど、実はいまお客様が困っていること」などがあれば、その場で解決案を提示する、などお客様側にもGiftをお返しすること

などは意識した方が良いですね。


🤔 現場への訪問や業務観察って本当にできるの？

できます！のでどんどん行きましょう！ただし…

  • 待っているだけではチャンスが得られない可能性があるので、ビジネスチームの方と積極的にコミュニケーションを取っていきましょう。

  • どのくらいの頻度で実施できるかは、ターゲットとしている業界や提供しているサービスによって異なる可能性があります。

さまざまな業種で日々使われるようなサービスであれば問題ないですが、例えば、

  • 対象となる業務が月初、月末など、特定のタイミングでしか行われないケース

  • お客様の現場が近くになく、移動にかなり時間がかかるケース

  • トラックドライバーの方々に運行への同乗をお願いするなど、ある程度の関係性ができていないと、立ち入るのが難しいケース

などでは、高い頻度で実施するのは難しい可能性があります。

ただし、これらのケースに該当するような場合であっても、例えば、業務のタイミングが限られるようなパターンであれば、ロールプレイをお願いするとか、現場が遠いパターンであれば、近隣の数社まとめて実施できるようにスケジュールを立てる、などカバーの仕方はいろいろ考えられると思います。

現場観察から得られるものは非常に大きく、BtoBの醍醐味でもあるので、関係者と相談しながら、自社に合った計画の立て方、訪問頻度などを模索していきましょう。


🤔 1つの共通システムで、多くの会社の業務をカバーできるの？

SaaSである以上、個社開発は良しとしていないものの、実態としては、特定の企業に向けた機能、特定の企業しか使っていない機能というものは、大なり小なりあり得ると思います。

企業との面談時に「個社ごとのカスタマイズとかはしてないですか？」と聞けば「SaaSなので、個社開発しなくていいように慎重にヒアリングして仕様を検討して進めています」という回答が返ってくると思いますが、実態としては「完全に個社のカスタマイズ」ではない、あるいは「個社のカスタマイズのつもりで作ってはいない」としても、そう見えてしまうような機能は一部あるでしょう。

  • 汎用性は低いかもしれないが、今後の展開のためにどうしても機能要望を取り入れて、目の前の受注をとっておきたい

  • 他社でも十分に通用する機能だと思っていたが、狙っているセグメントでは実は需要がかなり限られる機能だったことがあとから分かった

など、理由はさまざまですが、100社あれば100社それぞれに、業務フロー、導入している基幹システム、他社との情報のやり取り、などの違いがある中で、すべてを「このシステムを導入するなら運用フローを変えてください」で通すのは難しい面もあるので、一定は仕方のないものとして受け入れる必要があります。

ただし、もちろん、くる要望くる要望をすべてそのまま受け入れるわけではありません。

CSと連携しながら最適な業務フローを提案することで「この機会に運用フローも一部見直してみるか！」と受け入れていただけるケースもありますし、開発が必要であれば、いかにして汎用的な仕様に落とし込むかを考え抜く、というのも、PMとデザイナーの腕の見せ所となります。


🤔 管理画面のデザインだし、大してやることないのでは？

あんしんしてください、やることめっちゃあります！

管理画面というと、一度ルールを定めたら、そのルールの中で要素を積み木していくだけで完結しそうなイメージがあるかもしれません。

ですが、日々さまざまな要望やイレギュラーなユースケースに向き合っていく中で、常にルールをアップデートして、最適な形を模索していく必要がありますので、一度ルールを作ったらそれでおわり、なんてことは全然ありません。

また、業務で使うシステムである以上、一定の複雑さがあるため、初回の利用でどのように学習してもらうか、利用中に迷った時にどのように自己解決を促すかなど、プロダクト外（例えばヘルプサイト、オンボーディング資料、チャットボット、管理者から作業者への教育など…）にまで視野を広げて、全体の利用フローをデザインしていく必要があります。

デザイナーの仕事を、ただ画面のビジュアルをデザインするだけ、と狭めて考えず、顧客の利用体験のデザインと広く捉えられる方であれば、この複雑さを楽しんでいけると思います。


まとめ

個人的には、toCのサービスに取り組んでいたデザイナーにとって一番ギャップになりやすいのは、効果測定のしづらさかと思います。

お客様が業務で使うものである以上、勝手にABテストで画面を出し分ける、というのも難しいので、日々Redashなどで数値を見て、ABテストなども活用しながら、爆速でPDCAを回していくような動き方に重きを置いている場合、マッチしづらい側面があります。

一方で、ドメインエキスパートへのヒアリングや業務観察を通じて、複雑な業務を解きほぐしていき、「これがないと仕事にならない」と思ってもらえるようなプロダクトを作り上げていく面白さは、BtoBならではのものがありますし、定性的な評価は非常に得やすいです。

ただ単に画面の要素をデザインするだけにとどまらず、CSやPMの領域にも踏み込みながら、プロダクトの利用体験全体をデザインしていく、そんな働き方に興味があれば、マッチする可能性は非常に高いと思います。

ご両親が〇〇業で〜とか、実はむかし〇〇業に興味があって〜、とかそういった背景があるに越したことはありませんが、まったく触れたことがない業界向けのサービスであっても、なんら問題なく取り組んでいけますので、少しでも興味があれば、ぜひ一度BtoB SaaSの企業とカジュアル面談してみてはいかがでしょうか？（まだまだ志望者少ないので、めっちゃ喜ばれると思います！）

さまざまなサービスが普及している現在でも、多くの業界で「本当はもっとシンプルにできる」業務が山ほど残っています。

ぜひ一緒に、BtoB SaaSを盛り上げて、日本を元気にしていきましょう！



いいなと思ったら応援しよう！