00:06
はい、7月3日月曜日ですね。
僕は朝9時35分になりました。
えー、今日からまた7月のスタートっていう感じですね。
まあ、いろんな会社さんも今日から後半戦スタートみたいなところがあると思いますし、
僕の一旦のタイムラインを見ましたところですね。
6月30、まあ先週末、金曜日か、ところで、
まあ最終出社日だってところで、
なんかまあ転職をされた方とか、
今月からまた違う職場でスタートを切るみたいな方も結構ちらほら見かけましてですね。
はい、まあ後半戦ってところでいろんな人の切り替えの時期なんだろうなと思いますけど、
はい、まあ今日から頑張っていきましょう。
はい、おはようございます。ひめめのkeethこと桑原です。
では本日も朝月を始めていきたいと思います。
今日の読もうと思っていただいた記事ですけど、
Creative is 10% Structure and systems are the restということで、
まあクリエイティブは10%しかなくて、残りは構造とシステムだと。
逆に言うと9割、構造とシステムがあればクリエイティブにいけるよという話ですね。
デザインの規律とは優れたアイデアを構造化し大気化することに取り組むことであるみたいなお話が今日は入っていますというところで読んでいきたいと思います。
今日の参加者ですけど、ヒロさんって読むんですかね。
はい、おはようございます。ご参加いただきありがとうございます。
今からダラダラと読んでいきたいと思います。
まあちょっと技術的な記事じゃないんであれですけども、気に入っていただければと思います。
あと見えてないけどツーさんも参加されてますね。おはようございます。
ありがとうございます。
ではでは早速本題に行きたいと思います。
アイデアっていうのはそれだけでは成り立ちません。
良いアイデアが良いものに変わるにはそのアイデア以前に存在していた構造とかシステムがそれを実現させたからになります。
創造的な空間にはシステムは良いアイデアを死に追いやる場所だという風な神話があります。
イノベーションとはほとんどの場合、創造からの脱却を意味します。
これは真実から遠く離れたのではありません。
これはデザイナーがいかに仕事における斬新さの役割を誤解しているかを知るためには必要なすべてというものがとっている有害なフレーミングなのであります。
しかしそれについてはまた今度話していきたいと思います。
構造やシステムっていうのは創造性を潰したりすべてを同じように見せたりはしません。
美や技巧から効率や利益を絞り出すこともありません。
そういったことはでもやろうと思ったらできます。
しかしそれは実際の目的でもありません。
構造とシステムというのはデザイナーにとって最も重要なツールであるだけでなく、究極的にはデザインそのものになります。
新しいアイディアが理解され、経験され、そして作られることを可能にするものなんですよ。
デザイナーはデザインを起こすとき、デザインツールを使ってやると思いますが、結局は構造の話をしているような気がします。
しかしそれらは適切なタイミングで適用されなければ機能もしません。
私のキャリアの現時点ではおよそ120人のデザイナー、150人のプログラマー、開発者、エンジニアと仕事をしてきました。
彼らの誰もが良いアイディアを持っていました。
しかしそのような良いアイディアを彼らが作るために雇われたものの、立ち上げ続け持続させることができた人はほとんどいませんでした。
03:03
20年間このような状況を観察し、それを克服するために人々を支援した結果、私は根本的な原因を理解することができたと思います。
理解しなければならないということが2つあります。
1つ目は良いアイディアが良いものになるのを妨げているのはほとんどのデザイナーが仕事におけるアイディア構造システムのバランスを誤解しているということになります。
もう一つは構造とシステムを適切なタイミングで統合できていないということになります。
つまり適切なことを適切なタイミングで行うという概念そのものがシステム化された構造になります。
構造から独立して存在する考えなどはない。
どんな物事もどんな経験もどんな現実の断片も本当に本当に大きなシステムの構造化された一部ではないんですよと。
一応これが冒頭の話でした。
ではここから次のセクションに入っていきたいと思います。
より少ないものからより多くのものを生み出すことは、より少ないものからより多くのものを生み出すことよりもずっと簡単であると。
同じこと言ってる気がするけど。
これは多分翻訳がミスってる気がしますね。
More can come from less, much easier than less can come from moreなので。
少ないものから多くのものを生み出すことは、多くのものから少ないものを生み出すことよりずっと簡単だと。
多くのものから少ないものを生み出す方が簡単に見えますけど、どういう背景とか生み出すものとかのクオリティとか質とかっていう話は出てくると思うんで。
パッと聞きは逆に聞こえますけど、でも少ないものから多くのものを生み出す方が簡単だっていうのはこのヒッシャーのおっしゃってることらしいですね。
はい、戻ります。
アイディアを生み出すために費やされる価値とか、仕事、時間の割合というのは、私が一緒に仕事をしてきたデザイナーたちによってほとんどの場合は過大評価されています。
彼らは何日も、時には何週間も可能性のある幅広い方向性を生み出すことに時間を費やし、最終的におそらく一つか二つは追求する価値があるというふうになります。
結局のところ良いものを作るには多くのものを作ることだと私は信じています。
しかし私が何度も何度も観察してきたのは、最初の創造的な活動が一段落して方向性が決まると、同じような焦点の定まらない創造的な生成というのがさらに続くということです。
このようなことが起こると、私は最初のレイアウトやコンポジションのレビューで、なぜこれまで多くの新しいアイディアが存在するのか。
つまり、これほど多くの異なる視覚的要素、視覚言語に対するこれほど多くの異なるファセット、あるいは多くの異なるタイプのイメージが存在するのかというふうに問いかけ、デザイナーにビジュアルとかシステム全体を担うのに十分な強度を持つ一つか二つを絞るように促しています。
毎回毎回それだけ多くのアイディアがでも生み出されているというのはすごい悲しいです。
ビジュアル言語がアイディアに富んでいればいるほど、それを体系化して理解するのは難しくなります。
これをレスイズモア、少ないことは多いことというよく知られた格言に否決させるのはちょっと簡単すぎます。
06:00
これは重要なニュアンスの違いであり、アイディアの体系化がいかに重要であるかというのを物語っています。
それを理解しているデザイナーは作品のエレガンスを称賛されると。
まあ難しい話ですねこれはでも。
ただ言ってることはでもなんとなくはわかります。
はいでは続いて、アイディアと構造の比率という話ですけど。
次画像が1枚ペッと貼られていまして、アイディアと構造の比率をグラフで貼られているんですけど。
10%はアイディアジェネレーションというところで、まあその創造の話ですね。
で20%がストラクチャー構造ですね。
で40%がサブストラクチャーってことで結局は構造ですね。
で残り20%にビジュアルシステムがあって最後10%がドキュメンテーションですというので。
実に60%が構造の話だというふうに記者の方がおっしゃっていると。
なかなか面白いですね。
はいそしてグッドアイディアっていうのはおそらくこのストラクチャーの中の10%、
20%の中のうちの10%に含まれているよというふうな話をしています。
まあそれの話が今から続くんだと思います。
まずはそのアイディアジェネレーションの10%の話ですね。
良いアイディアはデザインプロジェクトの労力の10%程度を占めるそうです。
たった10%になります。
インタラクションデザインのプロジェクトでは最初のデザインの方向性は通常要素のコラージュで表現されます。
これは守備一貫した視覚言語の要素を意図的に分解して提示するものです。
色、形、タイポグラフィ、イメージなどこれらの要素が様々な異なる方法でどのように組み合わされるかを示し、
特定のレイアウトを承認してもらうことなく、視覚言語に対する構成因の快適さを確保することです。
過剰に労力をかけず、単級と制限のバランスを反映させるべきです。
ここで重要なのは一貫性であり、特定のランドマークを示すような特別なものではなくとも、
全てが同じ世界の一部であると感じられるものなければならない。
なるほどね。
アイディアとかジェネレーション、クリエイティブなところの話は実は一貫性というところが重要だというふうにおっしゃってますね。
一貫性を求めるのであれば確かに構造とかがしっかりしていないと、
制限とか制約がないと、一貫性というのは保たれないと思うので、そういう話をここでし始めるんですね。
続いて構造20%の話です。
それらを支える構造を作ること、つまり注意と使用のための一貫した景観を提供するページ、スクリーン、シーンというものを作ることが約20%になります。
これは私たちが外に向けて発信する情報アーキテクチャを体系化するところです。
インタラクションデザインではこれをプロトタイピングやワイヤーフレーミングと呼ぶことが多い。
私たちはここで構造にコミットしているが、その構造がどのように見えるかというものにはコミットしておりません。
私は20年のキャリアの中でこの部分を全く同じ方法で始めてきました。
ツールは変わってもポイントは変わりません。
プロトタイプを作る前に私は意図する体験が理にかなっていることを確認します。
誰がこれを使うことを想定しているのか、そして情報と行動という点でそれがどのように展開されるということを期待しているのかを考えなければなりません。
09:01
インタラクションデザインのプロジェクトでは、私は常に極めて一般的な画面でプロトタイプを事前に作成します。
私はこれをブロック化と呼んでいます。
大きなブロックになりますけれども、ブロックというのは形やエッジにこたわることなく、情報やインタラクションのポイントを分散させるのに十分なほど画面の風景を分割し始めるはずですよ。
ブロックが意味を成したのであれば、スペースの情報アーキテクチャを示すと同時に、情報の優先順位と可能なアクションというのを視覚的に示すのに十分なディテールで大きな領域を埋めていきます。
カラムベースのグリッドを確立することは既存のマークアップフレームワークから始める開発者にとっては便利ですけど、要素が他のルールに従わないのであればそれを使う意味というのはほとんどありません。
なるほどね、構造の話でしたけども。
なんか分かりやすいというか、ブロックという例え方がこの秘書の語る独自の言葉ですけど、やっていることは本当、情報と構造と設計の話もちょっと近い気がしますけどね。
フロントエンドエンジニアでいうとコンポーネントの設計とか流動との話だと思います。
ということが結構語られていて、それを言語化されたのが結構面白かったですね。
はい、なんだかんだこの辺の話は僕らフロントエンドエンジニアとまだデザイナーとかっていうのは結構近しい感覚というか思考をするんだろうなという気はしましたので。
ある意味でやっぱデザイナーさんがデザインを起こす時ってフロントエンジニアも一緒にやった方がいいんじゃないのってたまに思ったりはしますけど。
もちろん時間とか作業が完全に分断されるところもあったりするので、そういう最初のアイディア出しのところからやるんだったらありかもしれないなとちょっと思いました。
続いてサブストラクチャーですね。40%を占めるサブストラクチャーの話です。
情報の分類法、要素間のつながり、機能的なものと概念的なものの両方ですね。
ユーザーエクスペラレンスの管理レイヤーを考慮したデザインにおけるサブ構造の統合というのは実際には40%を占めますと。
これはデザイナーが完全に忘れていたり誤解していたりすることが多いステップです。
例えばウェブサイトをデザインする場合、何がモジュール化され何がモジュール化されないのか、コンテンツタイプはデータベースでどのように構造化されるのか、
情報は既存の社内外のシステムと同等に統合されるのか、コンテンツマネジメントシステムっていうのは他の人が作ったものを維持するためにどのように使われるのかなどをデザイナーが検討する段階になります。
これは物事の包括的な体系化になります。どれだけ詳細でどれだけ多くのコラボレーションを必要とし、最終的な製品の強度、拡張性、全体的なエレガンスにどれだけ影響を与えるかという点で労力と価値の最も大きな部分を占めます。
サブと言ってますけど、もうちょっと包括した構造化って話なんですね。さっきの20%の構造化よりさらに広い構造化の話をしているように聞こえますね。
インタラクションデザインのプロジェクトでは設計されたコンポーネントがシステムモジュールになります。
ここで覚えておくと良いのは、フィグマでコンポーネントにしたからといって、開発者が同じように、例えばシステムコンポーネント、コンテンツタイプ、モジュール、ワードプレスで言うところのグーテンバーグ、ブロックとして扱うことに意味があるとは限らないということです。
12:06
デザインツールでコンポーネントを作成することで、デザインプロセス内で簡単に更新することができます。
また、デザイナーはデザインにおける固定的な要素、つまりハードコードと流動的な要素、つまり管理されたコンテンツを継続的に区別することがここでも不可欠になります。
最終的なドキュメンテーションの一段階としてのこのことを示すだけでは十分ではありません。
流動的なデザイン要素が固定されているかどうかに関わらず、他の要素の形状、サイズ、エクスペリエンスをどのように変化させるかというのを十分に考慮するためには、早い段階で十分に考え抜かなければなりません。
というのがサブストラクチャーの話でした。
続きまして、ビジュアルシステムの話ですね。
最終的なビジュアルシステム、つまり最初のアイディアと外部構造及び内部構造を結合した結果である完全なビジュアル言語とパターンライブラリの作成が次の20%になります。
ファイアフレーム、プロトタイプ、タクソノミー、コンテンツプランなど、システムの完成度が高ければ高いほどビジュアル言語はより早く自然にまとまってきます。
私はデザイナーがスタイルのないシステムの洗練に多くの時間を費やすと、
ダイポグラフィや形、色、画像処理、組み合わせた要素、カードなど、インタラクションの詳細など様々な視覚的要素を試す時間が減るということを観察してきました。
ほとんどのデザイナーはこのような結果を忠実度の高いデザインと呼んでいたりします。
この段階は前の2つがうまく処理されていないと不必要な新しい創造物がたくさん出てきて進捗を妨げたり、システムが止まったり、残ったりするのを妨げたりします。
なるほどね。前段階の構造とかの話がしっかりされていなければ不必要なものがどんどん生まれる。確かにそうかもしれないですね。
本質じゃないものがどんどん生まれてきたりしますし、いわゆるアトムズ的なものが生えてきたりするので、それはあるかもしれないですね。
とはいえ、要件がしっかり決まっているのであれば、マストになるものとか必要最低限のものは決まってくると思いますけど、ただそれが生まれたところでちゃんと構造化していないと結局カオスになるというのはよくある話ですね。
戻って、繰り返しになりますけど、私の個人的なプロセスは20年前から変わっていません。何かをレイアウトする前に私はブロックに戻ります。
第2段階のワイヤーフレームではなく、以前のシンプルなブロックになります。
様々な要素間のグラフィカルな関係をいかに面白いと感じるかだけに基づいて選択することで、画面の構造を複雑にしすぎないようにするためです。
このような一般的な境界線がなければ、そしてより詳細なワイヤーフレームをガイドとして使わなければ、テキストだったり色だったり、形、イメージの誘惑というのは奥深い。
構造やビジュアル言語における矛盾というのは、ほとんどの場合、基本的な構造へのコミットメントから始めず、それを維持せず、より美しく、より斬新にするためにレイアウトをカスタマイズしすぎた結果です。
画面やテンプレートを見直してみて、見出しやリスト、カードといったものが、明確な理由もなくほとんど全てで異なる扱いを受けていることに気づいたら、大抵はそれが原因ですよと。
15:04
なるほどね。極論によってはシンプルにしましょうという話に尽きる気がします。
情報設計をしっかりしたり構造を考えているのであれば、そこはほとんど自然に集約する気はしますけど、それができていないと、結局はぐちゃぐちゃしたりカオスになっていくって話だと思うので。
なんだかんだその構造20%って話は、割と真実だなっていう。今回のブロッキージを読んでいるとそういう風に感じますね。
じゃあラスト10%で、ドキュメンテーションですね。最後にビジュアルシステムのドキュメンテーションが最後の10%になります。
本の導入やメンテナンスに必要なドキュメントはますます膨大になっていきます。
しかしあらかじめ構造やシステムが適切に活用されていれば、そのドキュメントを作成する労力は比較的最小限に済むはずだと。
そうすれば基本的にはドキュメントを作りながら進めることになります。
もしあなたが作曲ファイルの整理に膨大な時間を費やし、プロセスを通してうまくいかなかったというたくさんの素材をファイルから取り除いているとしたら、
それはおそらくアイデア発想の作業を広げすぎて構造に十分な重点を置かなかった結果になりますでしょう。
同様にもしあなたがこの段階で初めて他の人からフィードバックをもらうという理由で自分の構造ファイルを修正し、
使用状態の詳細を追加していることに気づいたとしたら、それはおそらく完全に省略したわけじゃないにせよ。
サブ構造の作業を十分に行わなかった結果でしょうということですね。
この段階において初めてレビューをもらうのは相当個人プレイしすぎな感はありますけどね。
続いてあらゆる段階で体系化しましょうという話ですね。
このエッセイ全体から何か一つでも得るものがあるとすれば、それは体系化こそがデザインの厳密さであるということです。
いやこれいい言葉ですね。体系化こそがデザインの厳密さである。
どんなにクリエイティブで有名なデザイナーでもカオスに甘んじる余裕などはありません。
そしてもっと哲学的なレベルで言えば、どんなアイディアもそれ自体がそれ以前に存在したアイディアの常部構造の要素でなければ存在しません。
つまりどのようなアイディアも織り込まれることなく経験の織物の一部となります。
既存の織物の構造を無視すると引っかかりや穴が生じる。それは悪いデザインですよと。
なるほどね。たとえが面白いというかわかりやすいですね。
特に日本人は和服文化が強いので、織物と言われたらかなりイメージはしやすいなと思いました。
ラスト、PS、推進ですね。
人に見せ始めて初めてわかることがあるという話です。
アイディオのデビット・ケイリーはそう言いました。
フィードバックを得ることはデザイン作業の最終段階だけでなく、できるだけ頻繁に起こるべきことです。
私が上記の内訳に別の要素として含めなかったのは、それが少なくとも私の考えではデザイン作業の要素としては遥かに低量化しにくいから今回は含めませんでした。
フィードバックは同僚から、レビューのディレクターから、クライアントから、ユーザーから、あるいは十分な距離を取れば自分自身から来ることもあります。
おそらくこの特別な構造とシステムからは目に余るような脱落のように見えるので、私はこのことに言及する必要性を感じました。
18:01
完全に今回言及しないと穴空きすぎるって話ですね。
構造化されたフィードバックは品質保証、いわゆるQAのシステムという形をとります。
優れた品質保証はプロジェクトの重要な段階で行われるものであり、特に作られるものの種類とそれを作るために変われる技術の種類によって決定されます。
最良のQAは想像的なプロセスから意図的に距離を置いています。
つまり欠陥を最もよく見抜き暴くためには隔離され、遮断されていなければならないと。
私はこれまで数人の優秀なQAスペシャリストと仕事をしてきましたが、我らに共通していたのは、厳格で耐えがたいほど詳細で構造化されたシステムに何度も何度も従う能力でした。
それが自分でできるデザイナーにはあったことがでもありません。
デザイナーは仕方ないですかね。いかに深く理解して、いかにそれ中傷的なものを具現化するっていうところに入るから、難しいですね。
デザイナーこそ一番離れるという行為が苦手かもしれないですね。ある意味ね。
QAについて語ることは、優れたアイディアを構造によって生きるか死ぬかという点を指摘する最も簡単な方法になるでしょう。
しかし、デザイナーは自分自身の作品の経験豊かなクオリティを完全に保証することはできないので、
可能な限りそれに近づくために自分の技術に沿った構造とシステムを使うことを学ぶことがより重要になります。
という言葉で締められておりました。
はい、いかがだったでしょうか。
タイトル的にはアイディアのお話だと思ったんですけど、結果アイディアの話もしてましたけど、
どちらかというとデザイナーの行為というか活動の話をより構造化して体系化したっていうような感じでしたけどね。
でもすごくデザイナーだけに当てはまる言葉じゃないなと思いますし、僕普通にこれデザイン、エンジニアも当てはまると思いました。
いわゆるデザイナーがデザインを起こす作業と、エンジニアが最初に設計をするっていうところですね。
この弊社の方はブロック化っていう言葉を使われてましたけど、
僕らが最初の基本設計、もしくは詳細設計までいくのかな。
サブ課程これまでいったら詳細設計入るかな。順番的に普通逆ですけど。
サブ構造ってやつはより包括というか、一段上の目線で見てますけど。
僕らでいうと詳細設計は一段下に潜ることですからね。
とはいえ、基本設計と詳細設計の話でも同じようなものが伝わるなと思って。
ここを最初にサボると、やっぱり後でシワ寄せだったり、うまいこと肉付けをしようとして、
結果なんかハウルの動く城ができちゃうので。
本当に設計ってすごく大事で、そこに10%しっかり、
種となる構造とかってのをしっかり決めておいて、
そこからあと、枝葉のものをどう組み合わせるかみたいなところに
持っていけたらいいんだろうなっていうのがつくづく感じましたので。
いや、とてもでもいいドキュメントだったなと思います。
というとこで、今日の朝活はこれで終了していきたいと思います。
もう10時近くですかね。
はい、というところで本日の参加者は、
キョウさんとケンジさんと、見えてないけどスウさんですね。
ご参加いただきありがとうございました。
じゃあまた今日からですね、1週間月曜日ですし、
7月が今日からスタートというところで、
また皆さん後半戦も頑張っていけたらなと思います。
それでは終了したいと思います。
お疲れ様でした。
