発想を実現し確からしさを高める「デザインエンジニアリング」

企業が抱える課題解決のためのプロセスとして有効な「デザインエンジニアリング」。
第3回では発想を実現し確からしさを高める「デザインエンジニアリング」と題して、デザイナーとエンジニアの役割や共創により発揮される効果などを解説します。

目次

• デザインプロセスの欠点と、それを補うデザインエンジニアリング
• 製品やサービスの本質的な要件/ 目的を捉えて具象化する
• 上流工程の成果を「開発で使える」ものとするには
• 中流工程があることを認識し、開発に必要なアイテムを作り試し組み立てる
• デザイナー・エンジニア双方で要件/ 目的をしっかりと捉える為に
• デザイナーの観点とエンジニアの観点①：思考法の違い
• デザイナーの観点とエンジニアの観点②：アブダクション

こんな方にお勧めです

• IoT改革やDX推進担当者
• 製品、サービス企画、開発担当者
• デザイン思考・UXデザインに興味がある方
• 提供している製品やサービスのユーザビリティに課題をお持ちの方
• 企画・デザインと実装・開発の連携に課題をお持ちの方

バックナンバー

Design Engineering vol.1 【企業、開発者、ユーザーの未来に喜びをもたらす「デザインエンジニアリング」とは？】 

Design Engineering vol.2 【「デザインエンジニアリング」は、なぜ必要か？】 

Design Engineering vol.3

発想を実現し確からしさを高める「デザインエンジニアリング」

デザインプロセスの欠点と、それを補うデザインエンジニアリング

デザインエンジニアリングの中でも重要な工程の１つとして、定めた要件や要求の中でも、実現可能性や課題に対して技術検証が必要な要件や描いたユーザー体験が狙い通りに体験できるか、これらを考察し、その効果が発揮できる工程があります。
ユーザーとシステムのインタラクションを実際の運用環境を想定して試すことが大切です。プロトタイプや実利用が想定される環境の上で、早期に試せることは試し、疑似的にでも相互のインタラクションを評価することで、要件や課題の抜け漏れを発見することが多々あります。

デザインプロセスの中でも、「ラピッドプロトタイプ」「紙芝居的モックアップでの基本的、正常系のフローの確認」「OZ 法によるフィードバックの再現、課題発見」「デザインツールやそこから出力されたプロトタイプによるユーザーインターフェースの評価」等の評価ツールを構築し、試すことで、確からしいシナリオの流れを把握し、ユーザ体験を評価することは可能です。
しかし、システムや運用環境、そのシステムを取り巻く実際の運用状況を考えると、限られたテスト環境の中では発見できないシステムの課題が残されてしまう、というのがデザイナー主体で進むデザインプロセスの欠点です。

具体的には、「インストラクションメッセージの必要度合」「通信から取得する情報の表示までのタイムラグ」「操作の流れを考慮した上で
の適切な情報量」「実際の運用環境を想定した場合の課題」（例えば、会員登録やログイン周り、セットアップ手順など、ここは既に用意されたフローがあるので試す必要が無いとされて、ユーザーテスト段階ではスキップや省略されてしまうことがある。）など、それらを表層的なプロトタイプによる評価や観察だけではシステムも含めた想定するユーザー体験の確からしさは高められないという欠点です。

このあたりのシステム開発時や運用環境上の蓋然性は、想定していたことよりもギャップがを多いことが後工程で明らかになるケースは多く、実際に使う環境に近いシステム上で試作し評価を行うには、デザイナーだけでは準備、実施することができませんが、エンジニアが関わることで、近い環境を想定した作りの上で試すことができ、抜け漏れ、考慮漏れに気付かされることが多いことが実態です。

続きをご希望の方は、フォームにご記入頂き「資料をダウンロード」からご覧ください。＊は必須項目となります。

© 2015-2023 sdtech Inc. All Rights Reserved.