このところ、Webデザイナーさんが作ったXDのデザインスペックに対してのレビューをする機会が多くあります。 デザインスペックの粒度は大小まちまちで、個人的なバイオリズムでレビュー時の観点がブレることがあり、観点のブレ防止のために、個人的にレビュー時に気を付けていることをまとめておきます。
環境、文脈
レビューは以下のような環境、文脈で実施しています。
- デザインスペックの対象プロダクトには直接的に関与していない。
- デザイナーが持っていないフロントエンド、バックエンドのスキル、知識のフォローという役割、責務はある。
- 困り事、知りたい事などの関心事がありその関心事に関するデザインスペックのレビューと、成果物としてのレビューがある。
気を付けていること
-
責務以外の領域の指摘を控える
責務以外の領域の指摘はあからさまな間違い以外はしないようにしています。 責務外と考えるのは以下のような領域です。※他にもありそうです。- ライティング
- カラーリング
- レイアウト
-
扱うオブジェクト（データモデル）の理解が進むようにする。
デザイナーのオブジェクト（データモデル）への理解が促進するような質問、指摘をします。
場合によっては、ER図のようなものをアドホックに作成することもあります。 画面のUI操作でオブジェクトの状態がどのように変化するのかを議論しています。 -
ブラウザのデフォルトUIや、コンポーネントライブラリのUIから外れる場合のスペックの言語化、仕様化
ブラウザや、コンポーネントライブラリで提供されていないUIに利用するケースは、フォーカス時の動作、マウスオーバー、エンターキークリック時の動作等の細かいスペックを確認して言語化、仕様化を促します。これは、仕様化しないと実装されないケースが多いためです。 ブラウザのデフォルトUIや、コンポーネントライブラリのUIは挙動がある程度担保されるため、そこまで気にする必要はないと考えています。 -
関心事がある場合は、関心事に対する回答を最優先で返す
関心事があるケースは、まず関心事に対する回答を最優先で答えるように意識はしています。- デザイナーがデザインスペックレビューに対して、ネガティブイメージを持たないようにするため
- そもそも自分自身の関心事はあまり他人は興味はないであろうという経験則があるため
-
質問をしてデザイン選定の言語化、思考整理を促進させる
レイアウトなどデザイン自体を作成を実施できませんが、質問により壁打ち役にはなれると考えています。
何故そのようにしなかったのか？何故そうしたのか？の質問は積極的に行って、思考整理を促すことがあります。
個人的な興味から聞いていることも多いですが、自分が知らない領域でも質問であればできます。 -
効果測定が計画されていて、測定方法が検討されているか？
画面UIの変更など使い勝手に関わる変更を主眼とした対応の場合、変更前、変更後の効果測定が計画されていて、測定方法が検討されているかを確認するようにしています。計測記録が必要な場合は、デザインスペック上への注釈記載を促しています。 -
新機能作成時に確認すること
新規機能作成時には以下の文書を参考にチェック項目を確認するようにしています。 よく抜けるところが網羅されていて助かっています。
以上です。
コメント