中途入社者目線でみるSansanの体験設計の違い

はじめまして！インボイス管理サービス「Bill One」のプロダクトデザイナーをしている則松です。

2021年にSansanに入社し、今年で3年になります。
現在は、「Bill One」のワークフローや仕訳といった汎用的に利用される領域を主に担当しています。
この記事では、Sansanに入社してまず驚いた体験設計の文化を自身の経験と比較しながらシェアしたいと思います。

はじめに

まず、私の簡単なキャリアをご紹介します。

前職とSansanの働き方を比較

私自身、過去どのように働いていたのかを簡単に振り返ってみました。

前職の働き方

当時の役割は以下のようなものでした。

1. 要件をPdMとエンジニア含めて定義する（リサーチ、評価、再検討など）

2. デザインの作成

3. ユーザビリティテストの実施

4. フロントエンドの実装および運用

関わりかたの濃淡はあれど、前半の1〜3はどの企業でも似たような働き方ではないでしょうか？

4については、フロントエンドが苦手なエンジニアが多かったのでHTML/CSS/JSなどのコーディングや運用を担当し、そのつなぎ込みをエンジニアが行なっていました。デザイナーの意図通りに実際の画面を設計できるのは良い面もありますが、その反面、自身で実装できない設計を避けるように制限してたことは、ユーザーに向き合う本質的な考え方とは相反しているという課題感を抱いていました。

Sansanの働き方

改めて以前と比べると、4の実装以外はほぼ同じような業務フローだなと思いました。
ここで終わらせてしまうと残りの記事が不要になってしまうので、きちんと違いを説明させていただきます（笑）。

設計とは何か？をいきなり突きつけられた

当時の私はプロダクトデザイン = 設計だと思ってました。
ユーザビリティテストは、プロトタイピングを使ってタスクを達成できたか否かを確認し、改善する手法と捉えていました。
改善するのは主にUIで、配置やより良いコンポーネントを選択するのがプロダクトデザイナーの仕事だと考えていたからです。

Sansanではじめて任せていただいた案件では、今まで通り利用状況を踏まえた上でプロトタイピングを行い、フィードバックを得るという流れで画面を設計しました。

当時のSansanでは、ウォークスルー（以下、WT。ユーザー本人になったつもりで、体験を検証する手法。WTを行う側がユーザーになりきれるように状況を設定し、作成したプロトタイプを実際に操作して検証する）を毎週2-on-1で行なっており、私も初めてその場に参加しました。

プロトタイプをつくるのは当然ですが、WTをする側がリアルなユーザーになりきれるようデザイナーが詳しく状況設定を行なってました。もちろん私も同じようにWTを行いましたが、リアルなユーザーになりきれるほどユーザーのことを知らなかったため、結果は散々でした。

ユーザーのために設計していたつもりが、実はユーザーのことを何も知らなかったんだと気づかされました。
Sansanがどれだけユーザーのことを深く理解してプロダクトに向き合っているのかを実感した瞬間でした。

WTの難しさに悩む

当時の私はユーザーを理解するため、何度もヒアリングを行い状況を必死に理解しようとしていましたが、やはりリアルなユーザーになりきれず、WTをうまく進めることができませんでした。

「どうやったらうまくいくのかな？」と悩み、状況設定やプロトタイプの作り方など、繰り返し改善していきました。

見えてきた課題

1. ユーザーを点（利用状況）でしか理解していなかった

2. ユーザーを事実とは異なる想像で捉えていた

3. テストに使うプロトタイプが現実的ではなかった

「ユーザーを理解する」とは、提供する価値に関わる全てのコンテキストを理解することだと今なら答えますが、この時はまだ理解できていませんでした。

見えてきた課題にどう向き合ったのか

ユーザーを点で理解していることが一番の課題だと考え、案件に向き合う際には利用状況だけでなく、その前後の流れも含めてユーザーを知ることで、線の体験を作ることができると考えました。
これにより品質が上がったので間違ってはいなかったものの、WTをする側の反応は今ひとつでした。

次に、プロトタイプが思ったように動かない（想定されない動き）ことが、リアルな体験に至らない原因ではないかと考え、プロトタイプの作り方にも注意を払うようになりました。

具体的には以下のプロセスを取り入れました。

1. プロトタイピングの前にヒアリングした事実をもとに状況設定を行う

2. 設定した状況のユーザーになりきってプロトタイピングを自身で行う

3. 課題点を修正し、最低でも1回以上は繰り返す

このプロセスを実施することで、WTをする側もリアルな体験を得られ、より良いフィードバックを得られるようになりました。

ユーザーを知り、そのユーザーになりきってプロトタイプを作ることは密接に紐づいています。もっと「ユーザーを理解する」ために、業務フローをヒアリングし、メンバーと共に詳細なカスタマージャーニーマップを作りました。

当時の私はデザインのことを設計と呼んでいましたが、この辺りから体験設計と呼ぶようになっていった気がします。

他にも「ユーザーのことを理解する」ための取り組みを行なっていますが、今回はご紹介のみとさせていただきます。

取り組み

1. プロダクトデザイナーが簿記3級を取得する（詳細はこちらの記事）

2. 書籍「経理業務の基本」を使った勉強会の開催

3. ステークホルダーマップの作成

体験設計にはタスクの完了ではなくユーザーになりきるWTがおすすめ

私が入社して、前職との最も大きな違いはWTという文化でした。
WTは一般的なタスクベースと比べて難易度が高いのがデメリットですが、より使いやすいものを作るには効果的な手法だと思います。

タスクベース

タスクを具体的に指示するため、誰もがテストを行えることがメリットですが、リアルな体験ではないため得られるフィードバックの判断に迷うことがあります。

例

• 取引先を登録してください

• 請求書をアップロードしてください

• 仕訳を行ってください

WT

背景と状況のみ伝えるため、自発的な行動を促すことができます。しかし、WTする側はリアルなユーザーか、そのユーザーに近い知識が必要になるため、より具体的な背景と状況を設定します。

例

• 取引を開始した取引先担当者から、請求書の送り先を尋ねられた状況です

• 取引先から郵送（自社宛）で請求書を受け取った状況です

• 今月計上予定の請求書のチェックが完了した状況です

なぜWTがおすすめなのか？

WTは難易度が高いと述べましたが、より使いやすいものをつくるだけではなく、デザイナー自身も成長できるメリットがあります。

改めて説明すると、状況設定を行うにはユーザーを深く理解する必要があります。そのため、デザイナーは必然的にユーザーについて深く学ぶことになり、結果としてより使いやすいものを設計できるようになります。
また、フィードバックについても優先度がユーザー体験に影響がある・なしで判断しやすくなります。

タスクベースで行っていた時は、「色が好みじゃない」や「ボタンがでかい」といったUIのフィードバックも混り、論点が広がってしまい困ることもありました。

SansanではWTをどのように運用しているのか

案件にアサインされたデザイナーは、WTを行う前にもやることがあります。

案件にアサインされたデザイナーがやること

• 利用するユーザーの業務環境を知る

• 何が課題なのかを知る

• 状況設定を行う（事実をもとにした状況を設定する）

• プロトタイプをつくる

• WTを行う★

• 改善する

• エンジニアと連携する

WTは実際のユーザーか、なるべく近いユーザーに行うことが望ましいです。実際のユーザーに依頼するとコストがかかるため、Bill Oneの場合は社内の経理や受領者などにヒアリングします。
実際に利用する状況を設定し、WT→改善を繰り返します。この時、同じユーザーばかりに依頼すると記憶によって影響を受けることがあるため、なるべくユーザーを変えつつ行うのがポイントです。

また、要件がずれそうな場合はプロジェクトに関わるPdMやエンジニアと話し合って、改善の方向性を決定していきます。

運用上の注意点

特にデザイナー同士やプロジェクトに関わるメンバーで発生する問題ですが、以下のようなフィードバックは別で考える必要があります。

例

• この仕様はどうなっているのか

• なぜこの機能を流用しなかったのか

• この機能は本当に必要なのか

• デザインシステムの定義に合っていない

上記のようなフィードバックに応じてしまうと、WTをする側は実際のユーザーから遠ざかってしまいます。
（実際のユーザーは仕様や機能的なフィードバックはしないため）

Sansanでは、こうしたフィードバックはデザインレビューで吸収するか、必要に応じてその場で「仕様やデザインに関するフィードバックです」と明確に伝えるようにしています。

Sansanの体験設計は似て非なるものだった

振り返ると、当時の私はプロダクトを利用する先のユーザーにまで意識が向いてなかったんだと思います。

「体験を設計すること」の本質に気づけたのはSansanのWTという文化がきっかけだったので、私の体験談を交えておすすめさせていただきました！

最後に

中途入社した私の視点から違いをお伝えさせていただきました。
この記事を最後まで読んでくださった皆様のお役に立つ内容になっていると幸いです。

また、このnoteでも引き続きデザイナーとPdMが情報を発信していきます。よろしければぜひフォローしてみてください。