合意形成のデザイン
こんにちは。
シンプレクスのデザイン組織AlceoでUXデザイナーをしている亀山です。
私はかねてから、UXデザイナーとは、「企業とユーザとの間に立つ翻訳家」であるというのが持論です。
プロダクト、サービスに関わる人の分だけ、それぞれのミッションがあり、思いが違います。
「こんなサービスがあってよかった」と思ってもらえるサービスを作りたい、成功したいとは、誰しもが思っていることです。
ただコンセプトからそのUIの細部に至るまでの合意形成を図っていくプロセスは、一筋縄ではいかないドラマがあります。
ただここって、UXデザインの本を見ても、「共感からはじまる」や「アイディエーション」という便利な言葉もあったりして結構ぼやけがちになっていると思っています。
「関係者全員の思いが細部にわたって一致しています！」というプロジェクトスタートであれば合意形成のデザインは必要ないのかもしれませんが、たいていは探り合いから始まります。特に最近は、オンライン会議のみでデザインプロセスが進むこともほとんどなので、なかなか腹の底が探りにくい状況です。
私が普段のクライアントワークでのデザインプロセスで意識している7つのことを書いてみようと思います。
1. 勇気をもって前提の踏み込みをする
プロジェクトがスタートするときに、概要やゴールはRFPなどでも示されていますが、安心できません。たいていそれを受けて認識したことはクライアントと微妙にずれていることが多いです。
ここで確認を怠ると、クライアントは当たり前と思っていても私が認識していない、必要な情報が抜けていた、会議を進めているとなんだか嚙み合わないことが続き気まずい雰囲気が流れる、などの事態が起きます。
プロジェクト序盤やご提案時にはいったん、もらった情報とできる限りの周辺情報をつぎ足しながら、間違っていてもいいので一歩踏み込んだことまでテキストで書ききってみると、結構クライアントもそれは違う、こういった意味であったと明確に伝えてくれることがあります。
「間違っていてもいい、勇気をもって踏み込んだことを定義してみる」は意識していることです。（粒度が細かい情報ばかりであれば、思い切って抽象度を上げる、抽象度が高すぎるのであれば、かなり細部まで仮で設定するなど)
2. 誰の何を解決しようとしているのか
ここも10人いたら10人が微妙に違うゴールやシナリオを描いています。
文字で表現してもイメージがすり合わないこと多々あるので、ストーリーボードという絵コンテのようなものでシナリオを描いていきます。ストーリーにして初めて、細かい機能意図がわかり、そのシナリオごとのゴールの違いも見えてきます。
ここでは「目線がステークホルダー間でずれていた」を明らかにすることが重要で、無理に統合する、合意させることはこの段階ではしなくていいと思っています。ここで議論しても所詮は空中戦であり、仮説であるため（空中戦で意見が割れたりした場合は、仮説であるのでユーザ検証で明らかにしましょうというご説明をします）。
3. 空中戦になる前に「モノ」をつくる
ここまで資料ベースですが、だいたい認識が合ってきたなと思ったら、すぐにプロトタイプに移ったほうが早いことが多いです。
よく「コンセプトダイアグラム」「カスタマージャーニー」なども聞くと思いますが、これらは思考の整理には非常に重要だと考えています。しかし、ステークホルダーやプロジェクトの性質によっては、空中戦を助長させてしまうことも…
前提が揃えば、ひとまず仮で「えいや！」でプロトタイプを作るとより指摘の精度が上がってくるので、そこからスピードアップしていきます。そしてプロトタイプを作ったあとにユーザ調査を挟むと一気に目線が揃ってきます。
4. 「発散しきる」を意識する
いくらそのデザインが優れていても、自分の意見が反映されていないと感じると攻撃をしたくなる心理があると思っています。
そのため、どれだけステークホルダーが腹落ちをしているかも意識しないといけません。ここをおろそかにすると、重要な局面で大どんでん返しとなります…
いったん意見を吐き出したあとは収束に向かう意識が強まります。自分の思いがすべて受け入れられなかったとしても、いったん吐き出したうえで取捨選択されたデザインだからです。
デザインプロセスでの要所となるセッションではプチワークを混ぜながら、適度に「思いのガス抜き」をする場も設けるようにしています。
ただここで、全員の意見を取り入れすぎることを意識するあまり、味の薄まった味噌汁みたいなデザインにしてはならないと思います。ステークホルダーの思いの吐き出しは促すものの、UXデザイナーとして、ユーザ体験、ビジネスゴール、システム上の制約を見たうえでの判断が迫られます。吐き出された意見を取捨選択した理由の整理、説得もまたデザイナーのスキルの１つだと思います。
一番やっかいなのは、意思決定する人（グループ）が１つの会議に集まっていないときです。
前提として、意思決定権を持つメンバーを（無理やりにでも）体制に組み込む必要がありますが、それが難しい場合は、グループを渡り歩きます。グループごとに気になっているポイントが違うので、前提の再整理・伝え方のチューニングなど、ときには変化しながら立ち居振る舞うタフさも必要になるときがあります。
5. 会議のアイスブレイクとファシリテーション力
特にオンラインだと、誰が発言の口火を切るのかや、しゃべりすぎることへの遠慮などが発生します。
毎回はしんどいかもしれませんが、プロジェクト初回、議題の節目、月またぎなど、アイスブレイク（会議の前の雑談）を入れるようにしています。「お休み中にこんなことしました～」など独り言をみんなが揃うまでしゃべってみる、「最近見たこんなサービス素晴らしかった」、「Figmaのアップデートについて」など、一人でしゃべります。
オンラインなので反応が見えなくて怖いときもありますが、その日の会議に少し盛り上がって入ることができ、この場はくだらないことでもしゃべっていいんだという雰囲気を出す効果があります。
あと会議中も、発言が少ないなと思ったら、発言することより「Miro」に付箋で書き込んでもらうと意見やアイデアを引き出せたりします。5分くらい時間を取って書き込んでもらうようにします。
その間、「しーん」となるのを防ぐため、Alceoチーム内のデザイナー同士でテーマの活性化につながるような話題について会話を垂れ流すこともします。ラジオみたいに。
6. 「文脈クリック」で思いをもう一段深く引き出す
クライアントの発言が出てきやすくなった状態でも、まだ十分ではありません。なぜその発言に至ったのか、腹の底の考えは1回の表現では出てきません。
そこでユーザインタビューのスキルの1つである「文脈クリック」が有効です。発言のとある1つの文や単語に着目して、その発言がでてきた背景を掘っていく手法です。「これなんか、しっくりこなくて、もっと違うシーンで活用されると思うんだよね」と発言があったらどこに着目しますか？ この場合、「しっくり」「違うシーン」です。具体的にどこがしっくりこないと感じるのか、しっくりくるとは例えるとどんな感じなのか？どんなシーンがイメージとして頭に浮かんだのか？など、3～4回ほど掘ると真意に行き着くことが多いです。
7. ゴールまでのプロセスを明確にして、毎回今どこにいるのかを意識させる
「今、このプロセスをなぜ行っているのか」がわからないと、議論が発散しすぎてしまう傾向があると感じます。
2～3か月先までのデイリーの予定を組んで、「今はこのことを明らかにするためのステップである」と指差しをして、「今日のMTGのゴールはここを決めることです！」と宣言してから会議を始めます。
クライアントも、「ここはちょっと脱線するけど」など前置きをしたうえで、議論の発散・収束を意識して発言してくれるようになります。（自分は強く意識しているので大丈夫と思っていても、クライアントは意外に今どこのプロセスにいるかがわからず集中できないこともあるので、毎回しつこいくらい指差しをします。デザインプロセスの説明が必要であれば丁寧になぜこのプロセスが必要なのかも伝えるようにしています。）
まとめ
ということで長くなりましたが、「合意形成のデザイン行為」というテーマで意識していることを書いてみました。
いろいろ書きましたが、個人的には5つ目の「会議のアイスブレイクとファシリテーション力」が大事かなと思っています。その人となりが見えること、会議自体が楽しいと感じること、いろいろな発言をしても許される場であるという心理的安全を提供すること、がプロジェクトの成功可否を左右するんじゃないかなと思うのです。
クライアント自身が自信をもってプロダクトを語り始め、ユーザ目線での機能要否やUIが活発に議論されれば、健全な意見のぶつかり合いが生じるのでよい状態だなと判断しています。
自分自身まだまだ「まじめすぎる」性格な故、5つ目の「会議のアイスブレイクとファシリテーション力」も含め勉強中です。アイスブレイクで氷が解けなくても、めげずに次の手をだせるように、ネタ探しをしています。
積極採用中です！
Alceoという組織はまだ立ち上がって3年くらいの組織で、デザイナー25人、フロントエンジニア15人といった規模感です。
UXデザイナー、UIデザイナー、フロントエンジニアを積極採用中です！
カジュアル面談も可能ですのでぜひ！
