伝わりやすいデザインデータと名前の関係 第1回 名前をつけることの重要性

デザインデータを元に実装するとき、デザイナーがなにを意図しているのか読み取れずやり取りが増えてしまうことがあります。デザイナーと実装者がより効率的に進められるためにはどうしたらいいか、その一歩として「名前」に注目してみましょう。

発行

著者 小原 司 UIデザイナー
伝わりやすいデザインデータと名前の関係 シリーズの記事一覧

伝わりやすいデザインデータって?

このシリーズでは「伝わりやすいデザインデータを作るための名前」をテーマに、さまざまな視点からより良いデザインデータを作成するための方法を解説します。まず今回は「名前をつける」に着目し、なぜ名前が必要か、そもそも名前とはなにかを考えてみます。次回以降は、名前を意識することで、より伝わりやすいデザインデータを作る例を実践的に解説します。

デザインデータを作るデザイナーとそのデザインデータを受取る実装者が、より良いやり取りをできるようなヒントがあるかもしれません。

伝わりやすいデザインデータとは、デザインデータ閲覧者がデータ上で迷子にならないことです。データの全体像が比較的低コストで把握でき、欲するデータの所在が明確で、未知のコンテンツについては類推が可能な状態を目指します。こちらについては以前記事にしたものがありますので、そちらも参照してください。

なぜ名前?

まず、なぜ「名前をつける」に着目したかについてですが、デザインデータを作成していると、形がそこに先に存在してしまうがゆえに、無名のオブジェクトがとても生まれやすい状態になるということがあるからです。名前がついてない状態の要素、すなわち無名のオブジェクトは、伝わりやすいデザインデータの大敵になります。

無名のオブジェクトとは、何でしょう。

  • 画面
  • 機能
  • 部品
  • 部品の各種状態
  • etc...

ここでは、上記のようなデザインデータに配置されるほとんどの要素のことです。普段、デザインデータを作成していると、ページや画面といった大きな単位のオブジェクトには名前がつけられることが通常でしょう。しかし、それが機能や部品というような小さな構成要素となってくるとどうでしょう。途端に怪しくなってきます。画面上に要素としては確かに存在していて、繰り返し使われている様子もあるが、なんて呼んだら良いか定かではありません。これが無名のオブジェクトです。名前がついてないので、閲覧者はそれぞの呼び名で認識し始めてしまいます。

無名オブジェクトが生まれる原因は、実際のデータ上にはデザインデータとしてのオブジェクトが存在しているからです。デザインデータを作る作業は、どうしてもオブジェクトを配置する行為に集中してしまいがちです。一旦デザインデータ上に何かしら形が存在してしまえば、実態として目に見えるものができ上がってしまうため、名前は必須ではなくなります。特に主な情報を視覚に頼って得ている場合は、目に映る何かがあれば、パッと見た部分で要素の理解が進んでしまうため、取り立てて問題がなくなってしまい、名前がないことが見逃されやすくなってしまいます。

しかし、名前はデザインデータの内容を他者に共有するという目的にとって、とても重要な役割を持っていると筆者が考えています。それは、ファイル名や画面名という大きな単位の名前に限らず、機能や要素といった小さな単位のデザインデータとなっても同様で、名前というものが、対象を正確に把握しようとする行為の大きな手助けとなるからです。

デザインデータの読み取り側は、名前を手掛かりにして対象を理解するきっかけにします。もちろん形から対象を理解することも可能ではあるのですが、そこには解釈の仕方による理解の幅が広くあって、読み取り側全員が同じ認識になるとは限りません。ですが、そこに名前があれば、それが何であるかをデザインデータ提供側から誘導することが可能ですし、名前から得た情報をもとにしてもらうことで、対象を正しい予見を持った状態で見てもらうことが可能になります。

これはデザインデータを共有する場合に限ったことではありませんが、名前というものは、あらゆる場面で登場します。データのファイル名しかり、ファイルを構成しているページのページ名しかり、デザインデータのコンポーネント名などにも名前をつけています。あまりに身近すぎて無意識に認識している場合も多いですが、意識のある無しに関わらず、すべての名前は、名前がつけられた対象が何者であるかを外側に伝えるために存在しています。

これだけ頻繁に名前というものが登場するのですから、それが重要な意味を持っていないはずはありません。そして、名前を上手に使いこなすことができれば、より伝わりやすいデザインデータが作れるようになると筆者は確信しています。

すべての要素に名前をつける?

この記事に書いてある内容は、「細かい要素にも名前をつけていきましょう」というものではあるのですが、「あらゆる要素に名前をつけましょう」という趣旨ではありません。単なる矩形や罫線単体に名前をつける必要は、もちろんありません。

デザインデータは、複数の図形やテキストを組み合わせることで意味のある要素を作っていきますが、組み合わせが発生しないオブジェクト単体に名前をつけたとしても、膨大な手間が発生するだけで旨味はありません。たとえば、罫線に「罫線」と名前をつけたとしてもデータ上に問題は発生しませんが、閲覧者がそこから得られる情報はないですし、閲覧者がそこまで深い要素の名前を意識する必要はないでしょう。

名前をつけるべきは、図形やテキストの組み合わせが発生して、デザインされた要素としての最小単位となってからです。単なる四角や単体のテキストには名前は不要です。四角とテキストが組み合わさって、仮にこれを「ボタン」として定義したときに名前が必要になってきます。

名前ってなんだろう?

名前は重要だ! と書きましたが、ところで名前ってなんでしょう……? なんとも捉え所のない感じですが、筆者にとって名前は、情報を入れるための無色透明な袋のようなものに見えています。

この無色透明な袋の中には、どんなものでも入れることができます。無限に大きくなりますし、破れることもありません。袋の中身は量が少なければパッと見て内容を確認することが可能ですが、逆に量が多いとぼんやりとした印象になってきます。袋の中にさらに袋を入れるということも可能だったりします。場合によっては中身を空のままで放置することも可能です。とても自由な袋です。

ただ、この袋には重要な機能が一つあって、シールのようなものに文字を書いて、袋の表面にペタリと貼り付けることができます。書く文字に細かいルールはありません。自由になんでも書いて貼り付けることができます。

たとえば、大量に中身が入っていてパンパンに膨らんだ袋があったとします。量が多いので中身はぼんやりとしか見えません。その雰囲気からは、中身がすごく魅力的に見える感じもしますし、そうでもない感じもします。この時点ではどちらとも判断できません。それを判断するには袋を開けて中身を確認するほかなさそうです。

ところが、ふと見るとそこに「ごみ袋」と書かれたシールが貼られているのを発見しました。するとどうでしょう? パンパンに膨らんだ袋の中身が急激に色褪せてしまいました。がっかり。魅力ゼロです。不思議ですね、中身を実際に確認したわけでもないのに、名前を確認して内容を把握できてしまいました。

さて、この魅力がゼロになってしまった袋ですが、もしこれに違うシールが貼ってあったらどうなるでしょう? そうですね、たとえば「宝石箱」だったらどうでしょう。これは、ちょっと魅力的に見えてきました。キレイなものが入ってそうですよね。しかも複数個。実際の中身は確認してませんが、中に入っていそうなものをいろいろと想像できてしまいます。

このように、名前は付与された対象を知るためのきっかけを与えてくれる貴重な情報です。名前を認識すると、それに紐づいた自身の記憶との参照が行われ、関連する情報も引き出すことができます。ですので、前の例にあるように「ごみ袋→いらないものが入っている」や「宝石箱→キラキラしたものが入っている」といったことが可能になります。

ただ、これは前の例にあるように、実際には中身の確認をしていません。もしかしたら実際には違うものが入っているのかもしれません。でもそれで良いのです。中身を確認をする手間を省き貴重な時間を節約できました。工夫すべきは名前の付け方です。中身が想像しやすくて、情報量が多く、的確な名付けができるように常に意識をすることが重要です。

次回は、名前の効果と用途について具体的な例を上げて解説します。

小原 司
PixelGrid Inc.
UIデザイナー

紙媒体をメインに制作しているデザイン事務所で広告デザインの基礎を学ぶ。2000年に独立。化粧品関連媒体の販促物を中心に、店頭グラフィック、パッケージ、POP、グッズ立案など多岐にわたるデザインを担当。2007年頃からWeb媒体へのデザインにも積極的に取り組み、クロスプラットフォームアプリのデザイン、画面設計、実装に携わる。2013年にピクセルグリッドに入社。現在では利用者にストレスを与えず迷わないユーザーインターフェースの設計とデザインに励んでいる。 著書に『ノンデザイナーズ・デザインブック[第4版]』(日本語版補足解説:マイナビ出版、2016年6月30日)などがある。また、マンセル色相環とムーン&スペンサー配色理論を採用した配色アプリ『HUE360』を1人でデザインから開発まで行い公開している。

Xにポストする Blueskyにポストする この記事の内容についての意見・感想を送る

全記事アクセス+月4回配信、月額880円(税込)

CodeGridを購読する

初めてお申し込みの方には、30日間無料でお使いいただけます