「デザインを良くしてほしい」と言われたとき

制作の仕事をしていると、よくこんな依頼があります。

「この資料、もう少しデザインを良くしてもらえますか？」

多くの場合、その意味はこうです。

・見た目をきれいにする
・レイアウトを整える
・イラストを追加する

つまり

デザイン＝見た目

という理解です。

しかし、実際にはここに大きな誤解があります。

デザインの本質は
見た目ではありません。

見た目を良くしても、理解は良くならない

例えば、こんなプレゼン資料を見たことはないでしょうか。

・色はきれい
・アイコンも入っている
・図もある

それなのに

何を言いたいのか分からない。

このとき、多くの人はこう考えます。

「まだデザインが足りない」

しかし本当の問題はそこではありません。

問題は

構造が見えていないこと

です。

人は「構造」で理解する

人は情報量で理解するわけではありません。

人は

・関係
・順序
・因果

を認識したときに理解します。

つまり理解とは

構造の認識

です。

例えば、次のような説明があります。

機能Aがあります
機能Bがあります
機能Cがあります

これでは理解できません。

しかし、次のようにするとどうでしょう。

課題
↓
解決方法
↓
得られる成果

同じ情報でも
構造が見えた瞬間に理解できます。

ここで初めて
情報に意味が生まれます。

デザインとは理解のための装置

本来のデザインは

・色をつけること
・イラストを描くこと
・見た目を整えること

ではありません。

本当の役割は

構造を見える形にすること

です。

例えば

・図解
・フレームワーク図
・関係図
・プロセス図

これらはすべて

構造を視覚化するためのデザイン

です。

文章では理解が難しい内容でも
図にすると一瞬で理解できることがあります。

それは

見た目が良くなったからではありません。

構造が見えたからです。

腹落ちする具体例

例えば、SaaSサービスの紹介資料を考えてみます。

多くの資料はこうなっています。

機能一覧

・自動化機能
・分析機能
・レポート機能
・通知機能

しかし、この説明では

「だから何なのか」

が分かりません。

一方、構造を見せるとこうなります。

企業の課題
↓
業務が分断されている

↓

このサービス
↓
業務データを統合する

↓

結果
↓
意思決定が早くなる

この構造を図解すると

一瞬で意味が理解できます。

これが

デザインの力です。

CODE視点

CODEフレームワークでは
Designを次のように定義しています。

Design
構造を視覚化するプロセス

つまり

デザインとは

美しさではなく
理解のための設計です。

そして重要なのは順序です。

Cognitive
問題を認識する

Organize
情報構造を整理する

Design
構造を視覚化する

この順番が崩れると
デザインはただの装飾になります。

まとめ

デザインとは何でしょうか。

それは

見た目を整えることではありません。

デザインとは

構造を視覚化すること

です。

人は

・関係
・優先順位
・流れ

が見えたときに理解します。

デザインとは
その理解を助ける

思考のインターフェース

なのです。

次回予告

ここまでで

Cognitive
Organize
Design

の3つを見てきました。

しかし、構造を視覚化しても
それだけでは理解は完成しません。

最後に必要なのが

Explain（説明）

です。

説明とは

情報を伝えることではありません。

説明とは

相手の頭の中で理解を再構成するプロセス

です。

次回は
CODEの最後の要素である

Explain

について考えます。

著者プロフィール
金井雄三。ゼブラクリエイト代表。複雑な情報を整理し、相手の理解と判断を支えるための設計と表現に取り組む。ホワイトボードアニメーション制作や説明設計の実務を通じて、CODEフレームワークを提唱。