not simple

デザインと言葉の実験です

SketchやPhotoshopにおける美しいデザインデータと陥りがちな罠の話

この文は自分のブログ更新滞っていると、デザイナーの同僚にブログ書いて発信しなよ!と促す時の説得力が無になるため、神の強い要請により半ば強制的に書かされているものです。なので、完全にUIデザイナー向けの話になります。

美しいデザインデータ

SketchやPhotoshopなど、デザインの作業用データについては、レイヤーやページやアートボード、シンボルやアセットなど、作業を効率化するための手段がいくつも用意されています。これらを適切に用いることで作業の効率化を図ることができます。

例えば、レイヤーやページやアートボードが適切な命名・設計をされている場合、チームメンバーに共有も無駄なくスムーズでしょうし、シンボルやアセットを活用すれば、急なUIデザインの変更や複数ページにまたがる調整・共有も効率的に行えます。

「可読性に優れ、修正変更に対応力のあるデザインデータ」というのが、ここでいう「美しいデザインデータ」です。

なぜ美しいデザインデータをつくるのか

理由としては経験上ふたつあり

  • 案件に対しての瞬発力があがる
  • デザイナーの考える時間をふやす

というのがあります。

前者に関しては、

「バナーの画像差し替え、明日までに80本どうにか」 「ページ内モジュールのレイアウト調整、明日の会議までにどうにか」 「ロゴの差し替え、今日午後一の会議までにどうにか」

というあるあるに対応できる、というのがあります。「可読性に優れ、修正変更に対応力のあるデザインデータ」があれば、少なくとも数人デザイナーがいる組織なら対応はできます。例にあげたような事案を引き起こす根本的な問題には目をつぶってください。

後者に関しての方が大事なのですが、効率的に「作業」ができることでデザイナーは「考える時間」を相対的に増やすことができます。また、適切な設計をされたデザインデータはデザイナーとエンジニアのコミュニケーションコストを下げるので「可視化されないタスク」を減少させることができます。

案件に対して、求められている明確な意図や目的を理解しないまま、大きなデイスプレイの前であれこれツールをこねくり回す、つまり盲目的に作業してしまうのは壮大な無駄である、という派閥にいるので「何がユーザーに求められ、最適解はなんなのか?」それを考える時間を確保するために、効率化されたデザインデータが整理され美しい状態が担保されているのが良いと思っています。

陥りがちな罠

ここが本題です。

ここでいう「美しいデザインデータ」を作ることがデザイナーの目的になってしまうことが往々にしてあります。手段の目的化案件です。

少なくともBtoB・BtoC問わず、サービスを利用してくれている人にとって、優先されるべきはサービスの改善とそのスピードです。雑な「汚いデザインデータ」の有用性が「美しいデザインデータ」のそれを超えてしまうこともあります。デザインデータをきちんと保つことはデザイナーの大きな仕事の一つですが、そこに「なぜそれをやるのか」という意識は必要です。

  • シンボルを多用しすぎて可読性が悪くなり共同作業が逆に辛い
  • 一元管理のため1ファイルのデータ容量が重すぎ、開いた瞬間落ちるor誰も開きたがらない
  • 効率化のためプラグイン入れまくっているのでチームメンバーが同一環境作るのに半日取られる
  • 外部参照しすぎているためファイルの階層構造を読み解くことから作業が始まる
  • デザインデータのメンテナンスがアウトプットより優先され、悲しみが生まれる

地獄のような様ですが、往々にしてあります。逆に非効率になり、時間を浪費することもままあるので注意が必要です。効率化のために複雑化しすぎないように注意を払う必要があります。

なんか書いていて、以前Fireworksという今は無きデザインツールで一元管理されていたプロジェクトを思い出しました。がんばってPhotoshopへの移行を画策・実行しましたが、あの時Sketchがあれば...

まとめ

デザインデータを美しくするのは「デザイナーの考える時間を増やし最終的なアウトプットの品質を担保するため」という意識が必要なのかなと思います。ちなみに僕の作るデザインデータは雑の極みです。