プロジェクトをよりクリエイティブに進めていくためには、問題定義の文章などを学術論文や裁判資料のようにガチガチに固めるのではなく、可能な限りやわらかな表現にすることが重要なこととされている。しかし報告書的なビジネス文章を作成することに慣れてしまった頭で、柔らかな表現を考えだすことは容易ではない。d.Schoolのテキストではそんな時に役立ついくつかの手法についても触れている。
■Why use a Point of View(POV) Want Ad
/ どうして着眼点の広告を使うのか
問題定義文を可能な限り実用的な表現にすることで、課題再解釈のためのアイディエーション(アイデア創造過程)をよりクリエイティブに行うことができる。たとえば、発見した着眼点を新聞の求人広告的な文章に例えて書くことで、より魅力的で興味をそそる文章になってくる。また求人広告的フォーマットは特定のユーザーやそのユーザーの重要なキャラクターを強調するのにも適している。
■How to use a POV Want Ad
/ どのように着眼点の広告を使うのか
ユーザー、ユーザーのニーズ、発見されたインサイトを求人募集広告を作るつもりで広告フォーマットの形に当てはめていく。このやり方で着眼点を表現すると、「ユーザー+ニーズ+インサイト」のようにただシンプルに要素を並べただけの着眼点のマドリブ(前回参照)方式と比較して、こまかなニュアンスまでより楽しそうに表現することが可能になる。しかしどのように課題を再構成したのか、明確にしておくことも忘れてはいけない。
では実際にこのフォーマットを試してみる。
*ユーザーのキャラクターを表現する。
*暗示されたユーザーニーズを満たすための曖昧な方法を、求人文で使う「~を募集しています」という言い方で表現する。
*良い結果が得られるように、少しだけ遊びの要素も加えると良い。
たとえば、このようになる。
「エネルギーの有り余っているティーン・エイジャーが社会とのネットワークを探しています。社会的に重要とされる課題(例:親というものがどうしてこんなに退屈な存在なのか、ベジタリアンになることがなぜクールなのか、などなど)にも興味があります。ただし、学校にいる時間での継続的コミュニケーションのためにIM(インスタントメッセージサービス)の使用はマスト!」
■Why use a Critical Reading Checklist
/どうしてクリティカル・リーディング・チェックリストを使うのか
このチェックリストは、チームが発見した着眼点が十分に意味を持つユニークな着眼点なのかどうかを確認するために使われる。オリジナルバージョンはスタンフォード教育大学院のデイビッド・ララビー教授によって開発されているが、それをデザインプロセスにおける着眼点の評価という文脈に沿うように転用している。
このチェックリストを使用して、チームの発見した着眼点が有効であり、同時にインサイトに富み、活用可能でユニーク、さらに十分に内容が絞りこまれており、有意義で、エキサイティングであることを確認する。ただしこのリストだけで、発見された着眼点に不足している部分が補えるわけではないことに注意が必要だ。そのような意識を持ちつつ、着眼点の価値を考えたり、有用性を考えるために役立つものだ。
■How to use a Critical Reading Checklist
/どのようにクリティカル・リーディング・チェックリストを使うのか
自分たちの着眼点に対して、以下のように4つの基本的な質問を行う。
1.ポイントは何か(観点はどこにあるのか)
*着眼点について語る際のチームのフレームワークは?
*ユーザーを中心に据えた、ニーズに基づいた、インサイトドリブンな試みか?
2.誰が言っているのか(チームの着眼点は有効か)
*あなたの発想の立ち位置はユーザーの発見でサポートされているか?
*それは発見されたものから抽出されているか?もっとも成功したインタビュー以外にも適応可能なものか?
3.何が新しいのか(チームの着眼点の付加価値はあるか)
*新しい方法で発見したものは明確に表現できているか?
*ユーザーの文脈にそって配置できているか?
*もし発見した着眼点に新鮮味を感じられなかったら、より具体的な形に作りなおす
4.誰が気にかけているのか(着眼点は重要な意味を持つか)
*チームはここでエキサイトしているべき
*この仕事に価値を感じられるか?もし感じないのであれば、それはなぜなのか自問する
*気にかけているのが誰か理解できるまで、フレームとフレーズの作りなおしを行う
■Why use Design Principles
/ どうしてデザイン原理を用いるのか
デザイン原理は、わかりやすい解決策に陥りがちな場合にも、チームが果敢にデザインチャレンジに取り組んでいくための戦略だ。あなたはデザイナーとして、発見したニーズやインサイトをデザイン原理に則ってディレクションできるように翻訳し、それをチームに明確に示していかなくてはならない。この原理は解決策へとチームを導いてくれる、抽象的ではあるが実行可能なガイドラインを確実に捉えるためのフォーマットとして、チームにデザイン意図を伝えるのに大いに役立つ。
■How to use Design Principles
/ どのようにデザイン原理を用いるのか
デザインソリューションにおける基本的なアウトラインとなるように、命令調のフレーズを使ってステートメントリストを開発する。このガイドラインはデザイン分野とユーザー理解の両方を洗練していくものでなければならない。共感観察において、何が解決策への有意義なチャレンジとなるのか、さらに成功に至るために必要となるものは何か、そうしたものがすべて明快に示されたデザイン原理を開発する。
デザイン原理の開発にはいくつかの方法がある。ユーザー中心のニーズやインサイトにフォーカスしつつも、ユーザーではなく、むしろ解決策の観点からあなたの発見について語ることによって、着眼点、ニーズ、そしてインサイトをデザイン原理として翻訳することもできる。
たとえば、ギフトの開発を考えた時、送る相手の役に立ちたいというユーザーニーズはデザインにおけるひとつの方向性を示すものであり、解決策としては「ユーザー自身を最終段階でギフトの中に組み込んでいく」ということになる。またあなたやユーザーが強制されていると感じてしまうような解決策は、デザイン原理からあらかじめ取り消しておくことも可能だ。解決策のどのような局面がユーザーの共感を得たのか、自問自答してみる。そのような局面は十分に抽象的であり、デザイン原理として形作っていくことができるかもしれない。
デザイン原理は(有効なガイドラインであるにしても)特定の解決策からは完全に独立した存在となるべき。しかしながら、デザインの原理を開発する手助けとして、解決策の文脈を広範囲に設定することは有益だ。たとえば(前述の)ギフトを開発するような時、それが物理的なものなのか、デジタルなのか、あるいは実験的なものなのか、まだ何も明確に決まっていないような段階でも、「送り手をギフト開発の最終段階において取り込む」というデザイン原理をはっきり表現することは可能だ。
Hasso Plattner Institute of Design at Stanford University
d.School
The D.SCHOOL BOOTCAMP BOOTLEG