ユーザー向けのハイファイなビジュアルに全力を注ぐデザイナーは、戦略に影響を与える最も強力なツールを放棄しています。
これは、ソフトウェアデザインプロセスに参加するすべての人が、プロダクトそのものにではなく、チームを編成し、仕事を計画し、プロダクトを構築する方法にデザイン意思決定手法を適用する方法を探る記事シリーズ（ここからどうぞ）の一部です。もし私が説明していることがあなたの経験に合わないのであれば、遠慮なく私に連絡してください。
Extended Danish Design Ladderは、私がプロダクトとデザインの実践を構築する際の考え方を変えたコンセプトを紹介しています。
オリジナルのラダーの4つの段は、より良いプロダクトを作る方法をカバーしていましたが、最初に追加された「変化としてのデザイン」は、私たちがプロダクトを作ることで、より良い組織をデザインできることを示唆しています。
しかし、直線的な梯子は、より高いデザイン成熟度に向かう旅が直線的であることを暗示しています。そうではありません！より良いプロダクトに向かう反復の旅が一本の直線ではないように、実践の構築には多くの分かれ道があります。
デザインプラクティスは、洗練されたビジュアルを提供するためにプロセスを最適化し、ある顧客を別の顧客よりも優先してきました。
そうすることで、ベースよりも上部構造を受け入れ、Design-as-Change（変革としてのデザイン）を可能にするまさにそのメカニズムから離れてしまったのです。それを取り戻すために、デザイナーは成果物ビジネスから手を引き、問題フレーミングのためのローファイのデザインを取り戻す必要があります。
アウトプット文化、インパクト文化
考える暇はない、シェイクしなければ！」 -ロシア軍隊のことわざ
この問題を説明するのに使いたい、私のキャリアの初期の頃の逸話があります。あるクライアントが、新プロダクト（0->1フェーズ、AmazonでいうところのMinimum Lovable Product）のスコーピングと構築について私に助けを求めてきました。顧客ペルソナの開発、現在のユーザー・ジャーニーのマッピングなどです。顧客ペルソナの開発、現状のユーザージャーニーのマッピングなどなど。私は自分が成し遂げたことを誇りに思っていました。
しかし、その週の終わりには、プロマネは不満を抱いていました。彼は私に言いました： 「この5日間、よくやった。しかし、実際に1週間分の進歩があったの？」
その質問は私を驚かせました。私はできる限り潔くそのミーティングを終え、プロセスへの信頼を求め、私たちがどれほど前進したかを示す方法を考える時間を作りました。
このプロダクト・マネージャーは、他の人よりも率直でしたが、異常ではありませんでした。私のチームが仕事をするクライアントの大半は「レガシー」な企業で、開発チームはまだ「IT」と呼ばれ、アジャイルはそのうちに検討する価値のある斬新なアイデアでした。当然のことながら、彼らのプロダクト部門はアウトプット文化の典型でした。X時間の生産ライン作業でYトンの鋼鉄やY回分の薬が工場で生産されるように、X時間のオフィスワークでYの機能要件、モックアップ、コード行が生産されることが期待されていました。
しかし、それはアマゾンの仕組みではありません。
4週間のリサーチとデザインのプロジェクトに1週間参加したからといって、画面の1/4がデザインされ、共有する準備が整うわけではありません。実際、最初の1週間はチームの足並みを揃え、正しい方向性を示すためのもので、私たちはまだユーザーと話すこともなく、エグゼクティブスポンサーや専門家とつながり、ビジネス上の問題や土地を定義するだけでした。
デザインは曖昧さを破壊する機械
すべてのシステムは、その結果を得るために完璧にデザインされている。-W. エドワーズ・デミング
私はそのプロダクト・マネージャーと、これはこれまでとは違うものになる、これまでとは違うものになるから会社は私たちを雇ったのだ、という期待を持たせなかったのが間違いでした。
ソリューション提供の顧客(ユーザー)に焦点を当てすぎ、問題定義の顧客(構築チーム)に十分に焦点を当てなかったため、私が望んでいたインパクトを与えることができませんでした。クライアントのプロダクト決定を支配する意味環境を変えなければ、私のチームは牽引力を発揮するのに苦労し続けるでしょう。
ジャレド・スプールのいつまでも驚かない幹部と同じように、これらのPMは、共有された問題の枠組みが必要とされず、期待されず、必ずしも望まれない、曖昧性の高い意味論的環境の出身でした。彼らはデザイナーが 「成果物 」を作ることに慣れており、私が出している仕事がその型に当てはまらないため、すぐに 「進展 」と認識することができなかったのです。
私は、このような状況でも意味を持ち、かつ問題定義を前進させるために必要な忠実度まで引き上げることができるものを見つけなければなりませんでした。
次のお客さんでは、その質問をされるまで待つことなく、その質問に対して何かしました。顧客がどのようにその問題に遭遇するのか、何が今日その問題の解決を妨げているのか、この機能はどのようにその問題を克服するのに役立つのか、そしてなぜビジネスがその問題に関心を持たなければならないのか。
私はそのシナリオをストーリーボードに落とし込み、チームが描いている体験を視覚化し、尋ねました： 「このアイデアは重役の賛同を得られるものですか？」
答えは「ノー！」。参加者はすぐに何が足りないかを指摘し始めました。問題が漠然としすぎています。利益が少なすぎる シナリオが既存のワークフローに合っていない 皆、頭の中では望ましい体験について異なる考えを持っていて、私が何かを見て 「これは違う 」と言えるようになるまで、それに気づかなかったのです。
デザインを、下流のデリバリー・エンジニアのために生み出されるアウトプットの観点から組み立てるのではなく、プロダクトが提供するインプットを説明するために使いました。誰もが見ることができる共通のビジュアルを作成することで、インプットが不十分であることが即座に明らかになり、欠けている部分を枠にはめることができました。視覚的な忠実さが存在しないことは問題ではありませんでした。概念モデルという、はるかに重要なものを伝えるために使っていたのですから。
その週の終わりに、私は 「5日間、進歩できたか？」とは聞きませんでした。私が聞いたのは、「私たちはスタート地点からここまで来た 」ということでした。
ローファイこそ、バリューチェーンに戻るための答え。
手は心の窓。- イマヌエル・カント
Figmaやデザイン・システムの時代において、ローファイ・デザインは評判が悪いです。私がそれを擁護すると、利害関係者はローファイ・ビジュアルに悪いフィードバックを与え、ストーリーボードやワイヤーフレームをスキップすることで時間を節約できると言われることがよくあります。確かに、時間対アウトプットが主な測定方法であるならば、デザインの貢献度を向上させる唯一の方法は、デザインの量を減らすことです。
しかし、デザインの最大の価値は、何かしらのものをより速く提供することではありません。正しいものをより速く提供することです。
ローファイで作業することに価値を見出さないデザイナーは、彼らが貢献することを許された領域に集中しています。しかし、ローファイデザインは概念定義のためのツールです。成熟度の低い組織では、デザインはそのプロセスに貢献することから除外されているので、一見したところ、価値を見出せないデザイナーは正しいのです。非常に抽象的なスケッチや漠然とした「テキストはここにあります」というプロンプトに不満を表明するとき、彼らは正しいようです。
しかし、ローフィデリティの段階をスキップすることは、自分たちが関与すべきであると主張するための最高のツールを放棄することでもあるのです。
なぜなら、ハイファイビジュアルは、実際には明快さを生み出さないからです。むしろ、スケッチと同じくらい偽りのディテールで、作業が行われていないという事実を隠すのですが、アウトプットを求める利害関係者を満足させるには十分なのです。
ローファイの成果物は、曖昧さが隠れる場所を残しません。それは、私たちが答えを持っていないすべての質問を呼び出すための非常に速い方法です。さらに重要なのは、その答えがどのようなものであるべきかという構造を提供することで、答えやすくなり、「場合による 」を繰り返すのではなく、デザイナーが何を求めているのかを知っている人物として、デザイナーの専門知識と権威を確立することができるのです。
デザインの正しいやり方には、厳密なルールはありません。あなたの最終的な真実の源は、常にユーザーであるべきです。しかし、彼らはあなたの唯一の顧客ではありませんし、ローファイ・デザインよりも速いフィードバック・ループを提供できる成果物はありません。唯一の問題は、あなたの実践がそれを利用するためにどれだけうまくセットアップされているか、そしてステークホルダーがそれに参加するためにどれだけ準備できているかということです。
