チームコミュニケーションを円滑にすることを目指すSlackは、2016年のはじめには60万人を超える有料ユーザーを抱え、時価総額300億ドルの評価額となりました。
Slackは仕事をできるだけシンプルに捉え、組織全体で向き合うことで生産性を上げており、デザインプロセスに関してもこれは例外ではありません。
Slackでは400名以上の従業員が働いていますが、彼らは開発者であると同時にSlackのテスターでもあります。全従業員がユーザーとして毎日8時間以上もSlackを使っているので、デザインチームは今までにないほどコンスタントにユーザーからのフィードバックを受け、製品への知識を深めることができています。
つまり、Slackのデザインプロセスは、オープンで継続的なコミュニケーションを反映したものとなっているのです。
１．「曖昧な問題」から企画書へ
Slackのサンフランシスコ本社におけるデザイナー兼エンジニアのディオゲネス・ブリトーは、Slackのアイデアと追加機能のほとんどが「曖昧な問題」からスタートすると言います。
この「曖昧な問題」とは、カスタマーサポートやソーシャルメディアに寄せられた意見であったり、社内チームのフィードバックによるものです。
Slackデザイナー兼エンジニア ディオゲネス・ブリトー
プロジェクトを形にしていく最初の一歩として、プロダクトマネージャーとデザイナーが一堂に会し、アイデアをまとめていきます。
この最初のドキュメントは、続くキックオフミーティングにおいてメンバーが正しい文脈を把握するための企画書となります。ディオゲネス曰く、企画書は「製品の支柱となるもので、ゴールと問題の微妙な感覚を定めるもの」です。この企画書はプロセス全体を通し発展していきます。
企画書はプロジェクトの中心
プロジェクトの詳細が一度決まってしまえば企画書のコアの部分は変更されず、デザインレビューにおける基準となるほか、プロジェクトが完了した時の記録として役に立ちます。また、企画書は役員らのレビューにおける資料としても使われるのです。
企画書にはアイデアだけでなく、プロダクトにおける制限・制約もまとめられており以下のような問いも含まれます。
・チームが最も気にすべき点は何か？
・何をスコープに含み、含まないのか？
・何が成功と言えるのか、どのようにそれを測定するのか？
ディオゲネスによると、「企画書は処方箋ではありません。企画書は問題の範囲を把握し、正しい方向に向かうために正しい問いかけをするためにあるものです。」ということです。
２．キックオフミーティング
企画書の準備ができると、リードデザイナーとプロダクトマネージャーがキックオフミーティングを実施します。この時点では、暫定的なアイデアも含まれます。（また、デザイナーも視覚的な一助として製品のラフデザインやモックアップを作ることもあります。）
キックオフ段階でも、メンバー全員が製品を完全に理解し、コアとなるアイデアや懸念を共有できるように、必ず企画書全体のレビューをします。
キックオフミーティングは、アイデアを議論することでチーム全員がデザインの問題点とゴールを理解することに役立ちます。キックオフミーティングは単なる自由なブレインストーミングではありません。
３．ペアデザイン
キックオフミーティングが終わると、デザイナーと開発者がSlackを使いながら調査と仕様化を始めます。
デザイナーは常に二人一組で行動し、一人がリードデザイナーとして動くのがここでのスタイルです。
「ペアデザインはアイデアを深めるパートナーを用意してくれます。同じか補い合える能力の二人なら互いのいいところを真似し合えますから。それに人間が二人いれば、躓いた時に早く軌道修正してくれるでしょう。」
オープンなブレインストーミング
二人のデザイナーは異なるデザイン上の問題を担当しますが、コンセプトについて意見を言い合い、アイデアを交換します。
他のチームメンバーがその場でいきなりブレインストーミングに参加することもあります。
４．ポスト・キックオフ
デザイナーがコンセプトを模索する一方で、開発者は既存のコードからプロジェクトに関係のある部分を探し、技術的制約となることを調査します。
技術的制約に関して調査ができたら、チーム全体で「ポスト・キックオフ」を実施し、製品と技術的要件についてレビューをします。
ポスト・キックオフが終わると、週に２回の間隔でデザインレビューが行われます。準備が整ったら、次はより大きな製品チームからフィードバックをもらいます。
５．自由なプロトタイピング
Slackのデザイナーは、その問題解決に適したツールを使いながらスケッチとプロトタイプを繰り返します。
「試作品、モックアップ、素晴らしいプロトタイプを作ることは我々にとって重要ではありません。問題点を考え、最小の作業で解に至るために最適なツールを用いることが大事なのです。」
例えば、ディオゲネスがオートコンプリート機能の開発に携わっていたとき、彼は課題を解決するためにいくつものやや雑なプロトタイプを作りました。そして、難しい問題にぶつかった時は、実際に動くプロトタイプを作成しました。
「製品をよく知っていれば、ラフスケッチからデザインに一足飛びしてしまうときもあります。紙やKeynote、HTMLからコラボレーションツールまで、自分たちが最速で作れるものなら何だって利用します。」
６．社内テストとユーザビリティテスト
Slackでは、ユーザビリティテストはデザインプロセスと切り離されたものではありません。自社に400人を超える従業員という巨大なユーザーベースを持つので、ユーザーテストは常に実施されています。
例えば音声通話機能の追加を決定した時は、チームはまず社内向けにその機能をリリースしました。社内向けのテストを経て、次に外部向けのベータ版としてリリースをして、それからようやく全ユーザーに機能を開放します。
「ここは直感的なところになってしまうのですが、毎日何時間も使うので最終的にはかなり精度の高いものとなっていきます。それに加え、ユーザーフィードバックは常時社外から入ってくるようになっていますし、お客さんの気持ちを理解するために毎週全員がカスタマーサポートのシフトにつきます。」
実際、Slackのサンフランシスコ本社では、デザインチームが異なるユーザーシナリオを自分の部署でテストしています。各部署が大きなカスタマーベースの中で小宇宙となる役割を果たしているのです。
フィードバックを集め優先順位付け
例えば、デザイナーは自社の経理部門からのフィードバックを集めて見直すことで、Slackを経理部門で使う場合にどの点を改善するべきか学ぶことができます。
継続的な社内テスト（ドッグフーディング）に加え、カスタマーサポートにもたらされるフィードバッグにも優先順位がつけられます。つまり、Slackが新機能の開始や大きな顧客を取り込む際には、デザインチームはフィールドリサーチとユーザーテストを行うことで知識を深めます。
「弊社は24時間営業の研究所のようなものです。いつでも製品にかかりっきりですから、問題を布団の下に隠してしまうことなく解決できるのです。」
７．仕上げに向けた開発スプリント
デザインが完成すると、チームはスプリントによる開発を開始します。スプリントによる開発は、予期できない変更に柔軟に対応することができます。製品チームがスプリントを開始する時までに、ほとんどのデザイン作業は終了しており、デザイナーはサポートと品質管理に徹します。
Slack経由のコミュニケーションと並行して、チームはチーム自身のチャンネルやメンバー間のチャンネルを立てます。
「透明性こそが弊社の製品と企業文化の鍵となります。これらのコアバリューはデザインプロセスに影響を与え、そのプロセスを組織的かつ効果的にするものです。またSlackを自分たちでも日常的に使うことで、新しいアイデアも毎日生まれてくるのです。これは非常に競争力の高い利点です。」
まとめ
Slackの組織的なデザインプロセスは、体系化されたデザイン体制が必ずしもスタートアップや企業にとって必要ではないことの一例を見せてくれました。
リサーチやユーザーテストが製品の品質向上を担保し、コンセプトを追求するための柔軟なプロセスと体系化された開発体制が成功を生む製品を生み出すのです。
Slackにおけるデザインプロセス
終わりに、以下の点をまとめておきます。
・企画書では、答えを書かない。問題にまつわる文脈と多様な戦略へ示す。
・キックオフ以降は、オープンなチームでコンセプトの追求と制約の発見にあたらせる。制約を明らかにするポスト・キックオフが実施される時点までに開発とUXの視点を合わせておく。
・チームが許すのであれば、より豊富なアイデアだしと迅速な問題解決のためにペアデザインを検討する。
・会社の従業員がターゲットとなるユーザーでもあるならば、ゲリラ的なリサーチのために試験運用をしてみる。社内におけるフィードバックと試験運用は、より広範なフィールドリサーチへと応用可能なユーザビリティの基礎知識を形成する。
この記事はUXPinが提供する無料のE-book『Real-Life UX Design Processes』からの抜粋です。
Slackのほかにも、実際の事例や取り組みを紹介しているので、興味がある方はぜひダウンロードしてみてください。
