そのリニューアルの対象は本当に正しい?見過ごされがちなユーザー体験と業務プロセス(2/3)
事件はWebで起きているのではなく、コミュニケーションの現場で起きている
あまり大きな声では言えませんが、Webのデザイン(見た目)を良くすることと問題を解決することは異なります。
見た目が良くなっても、使い勝手やユーザーがそのWebサイトを使ってできる体験そのもの変わっていなければ、現場(=ユーザー体験)で起きている問題は解決していません。
ユーザー体験(UX)については古典書籍の紹介とあわせて執筆した記事をご参照いただければと思いますが、階層的な構造の一番上に見た目のデザイン(表層)があることを認識しておくことが重要です。
そして見た目に現れた問題が階層構造のどの段階に起因しているか、を見極めることが解決への近道となります。
「犯人探し」的アプローチの落とし穴
リニューアルに向けて問題を特定するためのフェーズである「現状分析」「要件定義」。
正しい手順ではありますが、気をつけなければならない点もあります。
問題の棚卸しや洗い出しをする過程でいつのまに「犯人探し」のような状態に陥ってしまうことがあります。
「◯◯さんが担当の時に作成したサイトだ!」
「◯◯さん肝いりのプロジェクトで制作したコンテンツです…」
問題点を誰かのせいにした時点で思考停止になり、部門の壁や組織上の立場の問題から解決の糸口が見えなくなってしまいます。
リニューアルしたいと思った直接的な問題(たとえば、デザインが古臭いなど)に対して、どういう経緯でその問題が生まれ、放置されてきたか?というプロセスに着目するほうが問題を構造的にとらえることができます。