コーチングプラクティス： 試作を検証する―デザイン思考

取り組んでいることをほぼ何でも入力すると、IX Coach が現実に最も合うプラクティスを見つけます。「試作を検証する―デザイン思考」については、現在のプラクティスライブラリからの最適な一致をご覧ください。

役立つかもしれないプラクティス

1. テスト——ユーザーに壊させる
   プロトタイプを実際のユーザーの前に置き、その混乱をデータとして扱う。
   デザイン思考、ステップごとに
2. 置き換える前に、サンドイッチがなぜ失敗するのかを理解する
   サンドイッチは一度に三つの矛盾した信号を送るために失敗する。
   フィードバック・サンドイッチ:なぜ機能しないのか、代わりに何をすべきか
3. 同意ではなく理解を確認してフィードバックを締めくくる
   「同意しますか?」ではなく「そこから何を受け取りましたか?」と尋ねる。
   フィードバック・サンドイッチ:なぜ機能しないのか、代わりに何をすべきか
4. 聞いたことを反映して返す
   話し手の感情と内容を映し出し、彼ら自身の声を正確に聞けるようにする。
   アクティブ・リスニングを実践する
5. 信頼できる情報源からの具体的な言語的肯定を使う
   自分のパフォーマンスを見た人から、具体的でスキルに言及したフィードバックを求める — 一般的な励ましではなく。
   マスタリー体験
6. 洗練された結果だけでなく、雑然としたプロセスも普通のこととして示す
   成功した結果の背後にある試行錯誤や行き止まりを人に見せる。
   実践的なプラットフォール効果
7. SBIを訂正だけでなく肯定的なフィードバックにも使う
   誰かが正しいことをしたとき、状況、行動、影響を名指しする。
   SBIフィードバックモデルを実践する
8. 称賛を批判と同じくらい具体的にする
   曖昧な称賛はほとんど無価値である。何が良かったのか、なぜ良かったのかを正確に名づける。
   ラディカル・キャンダーを実践する
9. SBIに未来志向の依頼を加える
   影響の陳述に、次回に向けた具体的で実行可能な依頼を組み合わせる。
   SBIフィードバックモデルを実践する
10. 発表の前にタップテストを行う
    実際にメロディーをタップで叩き出し、それが自分にはどれほど明白か――しかし聴き手には見えないか――に気づく。
    知識の呪い:なぜ専門家は教えるのに苦労するのか

自分の言葉で状況を説明する でプラクティスライブラリ全体を検索できます。