Edited at

煮詰まった時に使える!チームを助けるデザインレビュー

More than 1 year has passed since last update.

こんにちは。デザイナーのヤマザキです。現在、私はグロービスで「グロ放題」のUIデザイナーとして参加させていただいてます。「グロ放題」はビジネススキルを学習できる動画サービスです。こちらでは、UXデザイナーとして参加してくれる方を絶賛募集中です。くわしくはこちら


目次


  1. はじめに

  2. デザインレビューの型

  3. メンバー構成

  4. 仕組み化

  5. まとめ


はじめに

aleks-dorohovich-26.jpg

デザインレビューは、一緒にサービスを構築する仲間をチームで助ける作業のことです。使い所としては、企画→基本設計→プロトタイプ→詳細設計→モック開発といった設計のプロセスで使用します。

煮詰まったり、ある程度複数のアイディアが固まってきたタイミングでデザインレビューを設定し、関係者を集めます。満たすべき項目をそれぞれの観点からフィードバックし、ある一定の基準を超えている事をチームで確認してから次のステップに進みます。また、後工程からの手戻りを防止するのに有効です。


デザインレビューの型

デザインレビューは、企業において様々なフローが存在します。

はっきり言って決まった型はありません。

今回のレビュー項目はモバイル向けアプリの改修・新規開発を想定した初・中級者向けに作成しており、あくまで経験上での個人的観点から列挙していますので、参考程度に捉えていただけると幸いです。


メンバー構成

どんなレビューをしたいかによって、多様な人材を揃えたり、人数を決定します。レビュー依頼側は大抵1〜2名なので基本レビュー側も2〜3名ほどが良いように感じています。たまに大規模な開発になると依頼者の他に見学者という名目で10名ほど追加で参加するケースもあります。

また、エキスパートレビューのように高い専門スキルを持った方にレビューを依頼する場合は、今回のようなデザインレビュールールは必要ないかもしれません。


仕組み化

patrick-perkins-350622.jpg

今回は、デザインレビューの仕組みを構築する上で最低限必要になってくる4つの観点を箇条書きで書き連ねてみます。


代表的な4つの観点


1. プロジェクト全体


  • 全体設計
    ビジネス視点の観点で考慮したい項目を洗い出す
    ユーザー視点の観点で考慮したい項目を洗い出す

  • デザイン、開発、ビジネス要件の視点

  • バリューの確認


2. UX


  • 時間軸でサービス全体の利用体験を確認

  • フロー毎(マーケティング、各チャネル、サービス品質、カスタマーサービスなど)の利用体験を確認

  • 他にエクスペリエンスを確認する上で欠かせない条件を設定


3. APP


  • 企業、事業のAPPサービスとして外せない項目を設定

  • APPサービスとして外せない項目を設定


4. その組織においての厳守したいデザインルール


  • デザイン原則を引用または設定

  • ガイドラインの設定


まとめ

レビュー項目が多いと大変ですし、最初はルールとにらめっこしながら客観的にサービスをチェックする時間が億劫になるかもしれません。しかし、レビューする側も慣れてくると、本質にたどり着くスピードも速くなっていきます。

私もそうですが、サービスを作っていると近視的になっていくことが多いです。そんなとき、気軽にデザインレビューできる仕組みがあれば、チームも自分も助けることができると考えています。特に、サービスの規模が大きくなっていけばいくほどデザインレビューは必要不可欠な第三の目になってくれるはずです(。・ε・。)