デザインとエンジニアリングは異なる問題を解決する——AIはそれを忘れている
組織がエンジニアリングのワークフローを通じてAIを導入すると、デザイン作業はパイプラインに引き込まれ、コードのプロンプト生成器や成果物を高速に生み出す手段の一つにされてしまう。デザイナーはそれらのワークフローに適応せざるを得ないが、その適応によって本来デザインが担うべき意思決定から焦点がずれてしまう。本稿では、AIが速度だけでなく意思決定の質を向上させるために、エンジニアリング、デザイン、プロダクトの共同リーダーシップの必要性を論じる。
組織がエンジニアリングのワークフローを通じてAIを導入すると、デザイン作業はパイプラインに引き込まれ、コードのプロンプト生成器になったり、成果物を高速に生み出す手段の一つになったりします。デザイナーはそれらのワークフローに適応せざるを得ませんが、その適応によって本来デザインが担うべき意思決定から焦点がずれてしまいます。
デザインとエンジニアリングの重なりは重要であり、双方の意思決定を改善することができます。デザイナーがエンジニアの構築、コーディング、テストの方法を理解すれば、より良いデザイン判断ができます。エンジニアがデザイン思考を理解すれば、より思慮深く構築できます。しかし、その重なりは同じ作業を行うことや同じワークフローを使うこととは異なります。
AIからの初期の恩恵は、エンジニアリングにおいてコード生成の高速化、パイプラインの自動化、システム効率の向上として現れています。これは驚くべきことではありません。エンジニアリングの仕事はすでに速度とアウトプットのために最適化されており、AIはその両方を加速します。エンジニアリングが組織全体のAI探求をリードすると、そのワークフローと最適化目標がプロセス全体を形作ります。組織はエンジニアリングパイプラインに適合するツールを選択し、チームは速度とアウトプットで成功を測定し、開発者はコードの出荷を中心にワークフローを設計します。デザイナーがそれらのツールを採用すると、焦点は速度とデリバリーに移り、本来デザインが行うべき意思決定から離れてしまいます。その機能をそもそも構築すべきか? これによって誰が除外されるか? ハッピーパスが失敗したときに何が壊れるか? これらの問いは、これらのワークフローが余地を残していない作業です。
デザイン作業はエンジニアリングのワークフローが始まるところから始まるわけではありません。それはもっと早く、曖昧さ、競合する制約、まだ明確な答えがない問いの中で始まります。解決策にコミットする前に問題空間を理解するのです。それには異なるプロセスが必要であり、エンジニアリングプロセスの高速版ではありません。デザイナーにエンジニアリングワークフローが渡されると、作業は変化し始めます。ツールの学習に多くの時間が費やされ、実際の作業に割く時間が減ります。チームは意思決定の質ではなくアウトプットを最適化し始めます。デザインが生み出す価値(リスク低減、問題の枠組み、共有理解)は見えにくくなり、削減されやすくなります。これは組織が明示的にデザインをエンジニアリングのように機能させることを決定したからではなく、単一の分野だけがツールとワークフローを形作ると、システムが自動的にその結果を生み出すからです。
デザイン作業が実際に行っていることは、何かを構築する前に優れた意思決定を行うことです。何を構築すべきでないかを特定し、リスクが高額になる前に表面化させ、チームが自信を持って正しい方向に構築できるよう共有理解を創り出します。これは、デザイナーが不慣れなユーザーのためにナビゲーションパターンを選択する場合、スクリーンリーダー向けにコンテンツ階層を構造化する場合、または新機能のデザイン前にどのリサーチ質問を尋ねるべきかを決定する場合でも同様です。これらの初期の意思決定を遅らせることは、しばしば、やり直しや後期の失敗を防ぐことで全体的な納期を加速します。これはアクセシビリティ作業で最も明確に見えます。チームはUIを素早く生成できます。自動チェックやスキャンに合格するものを生成できます。テストに合格することは、スクリーンリーダー、スイッチデバイス、またはツールがモデル化もコーディングもしていないコンテキストでの音声制御を使用している人にとって機能することと同じではありません。それらの失敗はコードエラーとして現れません。後で実際の人々にとっての壊れた体験として現れます。それらの失敗を見つけるには、判断力、パターン認識、ドメイン知識が必要です。相互作用とその向こう側にいる人の両方を理解する必要があります。より高速なアウトプットはその問題を解決しません。間違った部分を加速しても役に立たず、間違った場所に早く到達するだけです。
これはデザインでAIを使うことへの反論ではありません。それは、デザインが実際どのように機能するかに合った方法でAIを使うことへの主張です。AIを使ってコードをより速く生成しても、結果がよりアクセシブルになるわけではありません。AIを使ってインタラクションをプレッシャーテストすることは効果的です。その疑問——キーボード専用ユーザーにとって何が壊れるか? フォーカスオーダーはどこで崩れるか? スクリーンリーダーは何をアナウンスするか?——は、すでに行われている思考を拡張します。これはAIが思考パートナーとして機能しているのであり、生産ツールとしてではありません。適切に使用されれば、AIはリスクを早期に表面化させ、仮定に挑戦し、エッジケースを探求し、リサーチを統合することで、デザインに必要な思考を支援できます。アクセシビリティ作業では、インタラクションパターン、コンポーネント構造、コンテンツ階層に関するプロセス初期の決定が、下流のツールでは決して捕捉できない失敗を防ぐことができます。そのように使われる場合、AIは判断を置き換えるのではなく支援します。
AIイニシアチブにとってより重要な問いは、「どうすれば速くなるか?」だけではありません。「仕事のどの部分がAIによって改善されるか——そしてどの部分が遅いままである必要があるか?」です。デザインとアクセシビリティの実践者はそれに答えるのに適した立場にあります。ただし、質問が行われるときに彼らが部屋にいる場合に限ります。多くの組織で欠けているのは、デザイナーが異なるアプローチをもたらすことの認識です。それはユーザビリティ、理解可能性、アクセシビリティに関するリスクを表面化し、アウトプット速度だけでなく意思決定の質によって成功を測定するアプローチです。それはソフトスキルではありません。インフラです。それはコストのかかる失敗を防ぎ、構築されるものが実際に人々にとって機能することを保証する基盤的思考です。
目標はAIをエンジニアリング主導からデザイン主導にシフトすることではありません。それは別の不均衡を生み出します。エンジニアリングのみのアプローチは速度に過剰最適化し、デザインのみのアプローチは自由な探索に偏りすぎることがあります。プロダクト開発は意思決定の共有システムであり、単なる実行ではありません。AIの導入はエンジニアリング、デザイン、プロダクトの共同リーダーシップを必要とします。実際には、それは以下を意味します。ツールの評価をエンジニアリング、デザイン、プロダクトのワークフロー全体で行う。意思決定の質を含む形で成功を定義する。どの思考を保護する必要があるかを明示する。両方の分野がツールとワークフローを選択・定義するプロセスに関与する。AIはチームを速くするだけではなく、より良い意思決定を支援すべきです。それはデザイン、エンジニアリング、プロダクトがどのようにAIを使うかを共同で形作る場合にのみ実現します。一方が他方の働き方に適応するだけでは実現しません。