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