みんなではじめるデザイン批評
読み始める前に
発売時に買った(2016)が、何回か読んでは止めてを繰り返して2021年になってしまった。
デザインに関するレビューや、批評が下手だという自己認識があり、うまくやれるようになりたいなと思っている。
何を下手かと思っているか
無意識に言葉が強くなってしまう(気がする)
自分の判断を押しつけてしまっている(気がする)
レビューの場での場回しをどうしていいかがわからない
今、自分ができている思っていること
そのデザインを作られた背景を理解しようとする
レビューイーが何に対してのレビューを求めているのかを理解しようとする
---
読んでる
まえがき
デザインを皆で考える機会を作るべき
啓蒙のためのデザイン
デザインを、承認を求めるだけではなく、協力を求めるために見せる場合もある
序文
批評はデザインスキルではなくライフスキル

批評のファシリテーションの項目もあるので、求めているものが書いてありそうな期待
第1章 批評を理解する

デザインに関する会話は散々な結果を招くおそれがある・・・わかる・・・
だんだんイヤになって、モチベーション下がって、下がったモチベをもつ自分がイヤになることもある
それを回避できる確率を高くできるのならその方法存分に知りたい
フィードバックとは何か
提示されているものに対する直感的反応にすぎない可能性
何についてのフィードバックが欲しい?なぜフィードバックが欲しい?

指示型、自分がよくやりがちなやつかも
理由や背景を同時に説明しても、デザイナーの作った問題の対処にとってどう有効か(or NOT)の役には立たない。この時点では場違い。改善する上での有用性が欠けている。
そうなの・・・なぜ・・・?第5章で書かれているらしい。すぐ知りたい・・・
批判的思考
とは: 意見を聞いてそれが正しいか間違っているかを判断するプロセス
批評

指示型と批評の違いがわからない
選択が効果的でないことを伝え、具体的な指示はしない?
デザインが望まれる目的を達成すると思われるかどうかを判断する分析方法
デザインの選択が製品の目的のために正しく機能するかを理解する。理解を重視する。
批評によって共通の語彙が確立される

ユビキタス言語・・・

デザインが強化されるプロセスいいな。こんなチームになりたい
どのアイディアがより説得力があるか、ないかを巡って意見の一致が見られるようになり、その結果デザインは強化される

コンセプトがチームの身になっていく感じがする
意見の一致が見られるっていうのめちゃいいな
適切な批評は、共通の語彙の確立、適切な意見の一致の実現、効果的なイテレーションの促進のためのメカニズムとして機能する

たしかに、指示型ではこれは生まれなさそう。なんとなく感じる
批評とはじっくり考える行為であり、学習プロセスの一部
批評、この本では自分がどう思ったかを伝えるのではなくて、どうしてそうなったかをチームで醸成していくような行為ということなのか批評のスキルを身につける。ツールやミーティングの種類を追加するのではなく、今持っているものに、デザインしたものについての話し合いのやり方を変える。
「優れたデザインの原則は求めていないアイディアを排除するのに役立つものでなければならず、また具体的で『楽しい』といった過度に主観的であいまいなことばの仕様を避けなければならない」

「コンセプトとは判断基準だ」って習った。それと同じだ。決めることに迷ったとき、コンセプトに照らし合わせて○×を判断することができる。それができないコンセプトは未熟なコンセプト。
批判的思考の結果得られた見識を他の人とどんな方法で共有するかについても重要

よい批評をやっていきたくなった
第2章 批評とはどのようなものか
批評を受ける側: デザインの各要素が、製品の目的を果たすのに機能するかどうかを理解しようとすることが大事
批評を与える側: デザインの各要素が、製品の目的達成能力に及ぼす影響についてデザイナーが理解できるように、力を貸そうと思うことが大事
批評を与える

デザイナーが製品を産みだすのではなく、製品が実態を持とうとしているのをデザイナーやチームが補助する、みたいな考え方をするとスッキリするのかな。製品が頑張って形を持とうとするので、デザイナーがその補助をリードし、批評者が製品の声を聞きながら、その補助が正しいのかを見ていく。そんなイメージ?
批評を(批評者の)アイディア共有の場にすると問題が起きる。批評は新しいアイディアを探すための場ではない。詳細は5章で。
グループの思考を分析から探索へとシフトさせるには、周到なファシリテーションが必要
よい批評は問題解決をしない
批評は、どんな変更を加えるべきかをデザイナーに命じてはならない
批評の場でのデザイナーに対する質問には2つの役割がある「より多くの情報を得る」「デザイナーに自分の考えやプロセス、決定についてもっと気楽に話をさせる」

会話をしよう、コミュニケーションを取ろうとする場の空気をつくる?
思ったことをすぐ言葉にしない、その場で話すのが適切な内容、タイミングか、自分の中で一度反芻させてから発する

テキストコミュニケーションのレビューだと、反射神経で書き込んでしまうことがある。コミュニケーションのキャッチボールがないから、思ったら忘れないようにすぐ書いちゃおうとするんだろうな。一旦、手元のメモ帳に書いてPOSTしないをやってみよう。
思い込みをしない。デザインについて制約がなかったかどうかを聞く
肯定的なフィードバックは、デザインが製品にどのように作用しているかを理解するためにも必要。製品を理解するための情報の1つ。
デザインプロセスには、アイディアを解体、抽象化し、その後異なるやり方で、または別のところから得たアイディアによって組み立て直すプロセスがある
今製品が構成されている要素、それはよい要素も悪い要素も含んでいる
どの視点からのフィードバックか「ユーザーの視点から考えると〜〜だが、インタラクションデザインの観点からすれば〜〜〜〜」
ある視点からの理解と、また違う視点からの理解。1人が複数の視点を持つこともできる。
「今はプロセスのどの段階ですか?」「どうしたら一番あなたの役に立てますか?」

これほんとうにうまくいくの?と懐疑的な気持ち
批評の重要な3つの要素「分析しているのは、デザインに含まれるアイディアのどのような側面または判断かを具体的に明らかにしている」「その側面または判断を、目的あるいはベストプラクティスに関連付けている」「その側面、または判断が、目的あるいはベストプラクティスをサポートする機能をいかにして果たしているか、いないか、その理由は何かを説明している」
デザインの目的は何か?
チームの意見が一致した、製品またはデザインの目的はなんだろうか
目的に関連しているのはデザインのどの要素か?
そうした要素は目的を達成するのに効果的か?
それらの選択が目的達成のために機能するかどうかを尋ねよう
それはなぜか?
批評とは目的に照らして何かを分析することである
目的とは: ペルソナ、シナリオ、目標、原則 → 第3章で
批評を受ける
受けるときには、デザインをその後どう進めていけばいいかをよりよく理解しようとする気持ちでいる必要がある
目的を互いに理解しあうことは、批評のみならず製品やチームの成功にとっても重要
オンラインでフィードバックを行うのはほとんど不可能に近い。選択肢がなくそうしたツールを使うのであれば、できる限り焦点のあった、会話的なやりとりにするよう、最大限努力する必要がある
オンラインツールをつかって批評を行う際には、何についてのフィードバックなのかを詳細に書く。可能な限りたくさん質問し合う。
第3章 文化と批評
よい批評を生み出す組織文化の育成
チーム文化の重要な特徴「協業」「イテレーション」
協業
「調整」「合意」
調整に偏ったチーム、合意(全員の意見が一致しない限りチームは何も実行しない)に偏ったチーム、どちらもうまくいかない
合意
批評の目的は全員を納得させることではない
批評は、チームがプロジェクトの最重要事項に焦点を当て、個人的な好みに動かされないようにするための有用なツール
すべての人の意見を一致させることは目的としていない
折り合いをつける
プロジェクト全体を通して、調整と合意のバランスは変化する
イテレーション
インクリメンタル(漸増型)、イテレーティブ(反復型)
インクリメンタル: 完成形を分解して段階ごとにデザインし、作り上げていく
効果的なデザイン/開発プロセスは、インクリメンタルであり、イテレーティブである
批評が生まれるには、イテレーションが可能なプロセスでなければならない
分析、考え直し、有効でないものをそぎ落とすプロセス
チーム、組織の中のポジティブな影響を与える人を見つけ、関係を築こう
製品、ユーザーのためを思い、製品によい結果をもらたすよりよいプロセスを支持してくれる人
批評のための基盤を作る
文化を変化させるのに、即効性のある方法はない。文化は浸透させていくもの。グループの行為や行動によって強化されていく。
効果の持続する小さな変化を探し、実行していく
最初の1つとして(製品の)目的を詳細なところまで明確にするのが有効
ペルソナ、シナリオ、原則、目標
背景: ペルソナ、シナリオ
ペルソナは、ヴィジュアルデザインのディスカッションにも役に立つ

思い当たるところがあってキュッとした
大詰め: 原則、目標
作ろうとしている未来と、そのための方法の概要
目標は、製品を使用した結果生じる、望ましい、測定可能な成果のこと
よい原則は、ある程度の具体性を持つ
これらを、チームで共通の認識とできること
ミニクリエイティブブリーフの活用
デザインのディスカッションを行う前に見直す
見えないものは忘れて当然
批評の障壁となるもの
HRTを大事に

ただ、それを知らない人に覚えてもらう、感じてもらうのって大変よね
読む?
過去の批評にまつわる嫌な経験
コミュニケーション能力の育成
チームの中に理解者をつくり、一緒に広めていく
一人でやるのはつらい
批評の練習をする
少人数からスタートする
ライバル(製品)のデザインの批評をする
リモートでどうやるか
ノンバーバルなコミュニケーションが欠けている。ビデオ会議を使おう
ただ、ツールよりアプローチのほうを重視するべき
リモートワークになって、廊下での何気ないやりとりが、楽な気持ちで批評を受け、与えるためにいかに大事なのかをわかっていなかった
ミーティングの何分かを無駄にする。廊下での立ち話を行う
適度に発信する
個別に絆を結ぶ
変化は一夜では生まれない。正しい変化を起こすには時間がかかる。
第4章 批評をプロセスの一部にする
批評は分析ツール
チームに批評プロセスを取り込む、改善しようとするときに気をつけること
少人数でスタートする。2人とか。
チームのスキル向上のためには、話しやすく、受け止めやすい環境からはじめた方がよいため
しっかり聴き、理解し、話す前に考える
聴くことには集中力が求められる
誰を参加させるかを考える
グループ全体のスキルを最大限向上させる目的を持つ人をどうやって、なぜ批評に参加させるのかを考える必要がある
批評の機会3種類「スタンドアロン型の批評」「協働活動」「デザイン・レビュー」
スタンドアロン型
イテレーションプロセスを更に続けるために作成物を批評する。1つの目的のためだけに行う。
毎日の批評が、デザインの決定事項について話をし、その決定を目標に垂らして互いに評価するのに役立った
会うたびに互いの作業についての質問をしていた
週に1, 2回はプロジェクトマネージャーも加えて、共通の理解を確立した
チームが批評スキルを練習し、向上させようとしているときにも非常に効果的
安全でコントロールされた場をつくる
過去にフィードバックで嫌な経験をしたメンバーに、安全な経験を教えてあげる
場の作り方
批評のルールを定める
チームメンバーを選ぶ
セッションリーダーの役割を交代して、チーム全員ができるようになる。スキル向上
分散型チームのコミュニケーション、交流、および関与を活発にする

モブレビュー会だ
批評のペースを決める
公式か、非公式か
会議のような定められたものか、ランチをとりながらコーヒーをのみながらされるものか

朝会をその場にすることもできる
回数が増えるので、練習の場、スキル向上の場にすることができる
いつ批評すべきか
批評の準備が必要
アイディアを伝えるための準備をする
批評から得られたフィードバックを処理し、アイディアのイテレーションを行う時間を確保する
アイディアのひらめきから最終製品になるまでのタイムライン上で、批評のタイミングはどこにあるか・・・
まず、アイディアのひらめきが他人に伝えられる状態になったとき
そこから、出荷前最後のイテレーション終了時(その時点におけるアイディアを提示して先に進む状態)まで
この2地点の間で批評を行うことができる。効果がすぐに発揮できる批評を行うことができる期間。
デザインをリーンの検証に組み込む
デザインはしばしば、フィードバックを繰り返しているうちに、どうすればいいかわからなくなってしまう

わかる
小さなチームでの例
PM1名、エンジニア2名、デザイナー1名、
このチームでのデザインインプットの手段が「作る→評価する→学習する」だった
チームはデザインが行き詰まっていると感じるようになった
デザイナーを増やした
デザインの責任を2人で負えるようになった
2人の熟練者の間で戦術的な会話を行うことができるようになった
作業結果についてじっくり考え、互いに、またはクライアントからフィードバックを求める時間をえられるようになった
ここからわかること
デザイナーの批評を求める能力が制限されないように徹底する
1人のデザイナーに多岐にわたる領域のタスクを課してしまうと、フィードバックをとりいれるばかりでデザイン作業にリソースが割けなくなる
作業を分担し、熟練者レベルの批評をして、細部に目が行き届くようにする
いつどれくらいの頻度で批評をするか、期待値を擦り合わせる
できていない状態でこまめに見せても、意図したフィードバックが得られない
最初は幅広いディスカッションをする
最初は製品全体のディスカッションを
徐々に細部に移行していく

批評の対象である目的が、何に照らして分析されているか
協働活動
skip
デザインレビュー
関門。承認を目指すイベント
デザインレビューで得られるのは指示型のフィードバックなので、批評にとっては問題
レビューをコントロールする: 場をコントロールし、ステークホルダーの承認を得るためだけの場ではなく、参加者にデザインを目的と比較することに注力できるようにする
デザインレビューを批評を得るための場にしない:
---

2ヶ月くらい間があいた。ここまでのメモを読み直してみて、チームをどう作っていくかを話している本だと改めて感じている。自分だけのスキルを伸ばすための本ではなく、みんなで成長していくための本。3章、4章は少し具体例に寄った章だったので、その場をイメージできないと少し読み込みにくいかもしれない(だから、自分の所感が少し少なめ。所感中心のメモにしていきたい)
--
第5章 批評のファシリテーション
ファシリテーション: 会話のコントロール。場の舵取りをするスキル
誰もが平等
批評の場で我々が知りたいのは、異なる専門領域をもつ人からの様々な見解。

そこで意思決定は行われない。デザインレビューと批評は違う。デザインレビューってどう扱えばいいんだっけ?
全員参加
問題解決を避ける
人間の脳は分析的思考と創造的思考の両方を行うことができない
その場にいる人全員の脳みそは同じではないので、分析的思考の脳みそと創造的思考の脳みそがバトってしまう
チームが全員同じプロセスにいることが大事。

ファシリテーションスキルによって、分析フェーズの場なのか、創造フェーズの場なのか、脳みそのむき方をコントロールする