理想のデザインチームの作り方「一元管理」

Source

社内のデザイン組織の構築法について著者が唱える「一元化されたパートナーシップ」という概念は、会社の各チームがそれぞれビジネスの違う側面に従事していても、デザインは完全に一元管理されているという概念だ。デザインチームを構築する上で、すばらしい方法をいくつか共有したい。

プロダクト別の組織や事業部をそのままコピーしない

あなたのチームが他のチームとうまく協調するためには、自分の会社の他部署について理解することが重要だが、単に組織階層を反映したデザインチームでは不十分だ。組織は時間と共に成長し進化するもので、現在の構造になった理由は千差万別であり(例えば買収、解雇、イニシアチブの失敗など)、あなたのチームにとっては意味を為さないかもしれない。全社的な組織構造から独立しているデザイン組織があれば、不可避の組織変更が起こった時も安定したユーザーエクスペリエンスを保っていくことができる。

可能な限りユーザーのタイプ別にチームを組み立てる

従事するプロダクトやサービスごとにデザイナーを張り付けるのは間違った考えだと心得よう。プロダクトとサービスの機能とは、ただ単に会社とユーザとの関係性の一部を表したものに過ぎないからだ。そうではなく、デザイナーはユーザーエクスペリエンス全般と紐付けるべきだ。ユーザのタイプごとにチームを編成しよう。多くの企業では明確にユーザーを区別している。つまり市場では買い手と売り手であり、銀行では個人とスモールビジネス、法人などだ。例えば教育機関では教師、経営者、生徒、そして親に区別できる。ユーザのタイプに重点を置いてデザインチームを編成すれば、ユーザを深く理解し、共感を持てるので、ユーザの事情や技術に適合した優れたデザインが導かれる。つまり、市場の場合は「買い手デザインチーム」と、「売り手デザインチーム」を用意するのだ。

このような組織体系は、一定の企業では非常にすばらしいことが証明されるはずだ。銀行や金融機関では、よくプロダクトやビジネスの系列など(一般銀行業務、クレジット/デビットカード、貸付、住宅ローンなど)によってチームを編成している。サイロ型組織になっていて、お互い協調することは少ない。しかし、1人のユーザーが複数のサービスにまたがって取り引きしていれば、デザインがバラバラであることを不満に感じる可能性もある。製品をまたがる「最終消費者」向けデザインチームを持てば、より良いユーザーエクスペリエンスが推進される。しかし、特定の製品の成功を通じて事業部を奨励するタイプの企業の顔を維持するのは難しいかもしれない。上層部が後押しして、まとまりのあるユーザーエクスペリエンスが会社全体にとってどれほど大切かという点について示すのがいいだろう。

カスタマージャーニーごとにチームを組み立てる

会社の業績が良ければチームを拡大する必要があるだろう。どのチームも最大7名までと心にとどめ、それ以上になったらカスタマージャーニーに応じてチームを分割することを考えよう。例えば、旅行会社なら「旅行の計画」「旅行の予約」「旅行の実行」「旅行の後」といった具合にチーム分けができる。覚えておいてほしいのだが、このようなチーム分けはプロダクトやビジネスに関わらず可能だ。カスタマージャーニーによって組織編制すると、機能(検索、ブラウズ、予約)から、ユーザーエクスペリエンスへと重点がシフトし、これらの機能に対するデザインすべてが全社的なデザインとしっくりくるようになる。

これらのチームは、より大きな「旅行者デザインチーム」にまとめられる。たとえ週に一度のミーティングであっても、接触を持ち、各サブチームの作業状況を共有することが重要だ。

この手法で予想外の影響があるとすれば、別のタイプのユーザーが関わる1つの機能に、2つの違うチームのデザイナーが従事してしまうかもしれない点だ。一例を挙げると、市場で、買い手が売り手とのミーティングを予約することがあるかもしれない。プロダクトマネジメントとエンジニアリングの観点から、「予約する」というのは1つの機能チームの責任になると思われがちだ。一元化されていない組織では、1人のデザイナーが買い手と売り手のユーザエクスペリエンスに従事しているだろう。しかしカスタマージャーニーに基づいて組織編成していれば、この機能が買い手と売り手のそれぞれのワークフローにどうフィットするか、ということを解明する方に心配はシフトする。より広い買い手のエクスペリエンスのコンテクストで、買い手のチームに予約機能をデザインしてもらい、売り手の方も同様にすればいい。非効率なオーバーヘッドのように感じられるかもしれないが、コンテクストに留意したデザインのおかげで、コンバージョンは向上するはずだ