現状の組織課題
UIデザイナーから見た、組織課題と対策についてまとめる
事業戦略立案の段階
UIデザイナーの責任範囲の定義
競合他社がUXを取り入れている以上、最低限のUXの知識を入れる必要はあるのではないだろうか？UXの知識の有無。それは競争力と直結するのではないのか？
私の責任としては、それを分かるように説明することである。理解した上でUXについて、検討するしないを判断をできる状態にする所までが、私にできることだ。
第一の障壁
デザイナーが、UIの話”だけ”をしてるんじゃないと理解してもらう必要がある。また、「ユーザーの話を聞いた上で戦略を立てなさいと言われた」という話を聞いたが、その目的・粒度も再度確認する必要がある。
噛み砕いて説明するならば、企画の段階で作り手だけでなく、ユーザーが嬉しいと思う体験を予想して進めることで、その企画を売れる角度の高いものにしようという試みである。
それは、歴史的な文脈で言えば製品開発を中心にした話になるが、現代においては製品だけでなく、例えばユーザー同士の交流や、製品の外のメールやSNS・LINEなどのコミュニケーション・デザインについても考慮する必要があろう。そのビジネス的なエコシステムを形成する上で、本当にユーザーがそれに乗って来てくれるのか？という課題が、飽和した情報の海を自由に行き交うユーザーに対し、サービスを提供しようとする者には課せられる。
↓
製品開発決定後
各階層のファシリテーション・ディレクションの能力不足
方向性を固めるのに、プロジェクトメンバーが多すぎて進まない。アサインの仕方（マネジメント層）にも問題があるし、アサインされたメンバー（リーダー層・プレーヤー層）にも問題がある。
立場・前提の共有
ここでの学びは、発言する前に、自分の立場ややり方を明らかにすること。「私は、誰に何の目的でアサインされているので、こういう立場で意見を述べます。反対意見を言うこともあるかもしれませんが、こういう仕事なので言っているだけで、あなたと敵対したい訳ではありません。」そのことを申し伝えておくことの重要性を改めて認識している。しつこい位言わないと、お互いストレスを感じることになる。
デザイナーは特に、プロジェクトによって、どこまで上流へ遡るべきか判断をしていかないといけないので、この前提をスキップすると「口出しして来て煩い」と思われるだけで、何の成果も出せなくなる。
↓
設計段階
リリースサイズと人間中心設計
小さく確実に進める。過去5年間の経験を通して、これに勝る方法はないと思う。
成果の観点：
スコープが大きすぎると学習コストが大きくなり、Slackのような固定ユーザーが多いサービスなら良いのかもしれないが、ユーザーが流動的な場合、活動が停滞し、成果へ悪影響を及ぼすおそれがある。
ユーザーが理解できる・操作できることが成果に直結するサービスでは、人間中心設計のプロセスをなぞり、ちゃんと使えているのかを定性・定量的に確認しながら進む必要がある。
計測体制
「このプロジェクトを完遂したので、評価を上げてください」そういう人事評価基準になっているため、終わったプロジェクトについて、誰も計測していないという事態が発生している。
これについて、デザイナーは事業部と話し合わなければならない。デザイナーはUIの美的な部分しか見ていない訳ではない。成果を産み続ける鶏を育てることが目的なのだ。鶏が病気であれば、治療をしなければ、長期に渡り金の卵の生産性が落ちる。
自分たちが追おうとしている数値と、トレードオフされるKPIを把握する。
許容できる範囲リスクであれば、一旦出しても良いが効果計測の体制をデザイナー側でもしっかりと把握する必要がある。
リスクが許容できるか不明な場合、ユーザビリティテストを実施し、どの程度のリスクがあるかを事業部と擦り合わせる。この場合も、事業部が効果計測を怠らないか監視する。
リリースサイズと開発コスト
リリース単位が大きくなると、「開発コストを掛けたのに、成果が出ませんでした」となるリスクも比例して大きくなる。小さいスコープで成果を出し、行けるぞと確証を持ってからグロースしていくことが必要である。
そのためには、敏腕ディレクターかPdMが必要なのかもしれない。そんな人材を確保する難しさを、採用活動を少ししただけの自分でも理解できる。
では、どうするか？エンジニアが「技術的に可能か」だけでなく、「本当にそのコストを掛ける必要があるのか？」を問い直す必要がある。デザイナーの役割は、事業部の要望を聞くだけでなく、開発を担うエンジニアから、この情報を引き出すことだ。
設計を専任にしているのであれば、その設計が費用対効果が最大になった状態であるということに、責任を持たなくてはいけない。内製なら尚更だ。
当然、事業部の求める”効果”は、事業部の指示通りやれば最大になるケースばかりではないので、検証をする必要がある。
この記事が気に入ったらサポートをしてみませんか？