デザインツールと私

この記事はデザイナーのnaoがどのようにデザインツールという存在と向き合っているかを書き記した短編集になります。中には個人的な意見も含まれるため参考程度にご一読ください。

高機能なソフトウェアデザインツールに縛られる日々

昨今のソフトウェアデザイン業界では、効率的かつ自由なUI設計ができるFigmaやSketchなどの高機能なデザインツールを使うのが主流です。またソフトウェアの規模が大きくなるにつれ、Design Systemという概念も生まれ、それらを管理するためのソフトウェアや機能も生まれてきています。

デザインツールの進化に伴って私達の作業は大幅に効率的になりました。ですが時折、デザインツールに対する違和感を感じるところがあります。

例えばFigmaのAuto Layoutという機能があります。この機能のおかげで速く簡単に高品質なレイアウトを組めるようになりましたし日々恩恵を受けています。しかし、Auto Layoutは自由度が高すぎるあまり他人が作成したデザインファイルが触りづらいという課題が生まれてしまいます。

またディスカバリー時に安易にAuto Layoutを多用すると、変更容易性が失われイテレーションを回す速度も遅くなるという課題も出てきます。今後ソフトウェアデザインツールがより高機能になるたびに、この現象に遭遇する機会は多くなっていくでしょう。

Figmaからの脱却

ここ数か月で私は「手描き8割、Figma2割でUIの設計をする」という結論に至ってます。

この度合いはプロジェクトの状況によって変動しますが、基本的には手描きが多いです。過去多くのデザイナーがSketchやFigmaのようなベクターベースデザインツールが成熟するまでは手描きでUI案を描いていたように思いますし、今でも最初期の一部分は手描きだという人もいると思います。

私の場合は考慮すべきUIの全体図を手描きで表すようにしています。（厳密に言えば、紙とペンではありません）。

ではどこまでが手描きなのでしょうか。ここでは有名な「デザインの5段階モデル」を用いて具体的に説明します。結論今取り組んでいるプロジェクトにおいて、骨格と表層の間に至るまではすべて手描きで終えました。

なぜ手描きなのか、手描きのメリットとデメリットは詳細に後述しますが、デザイン工程の大部分を手描きで行なうことは形を見出すデザイナーとしての本来の役割を再定義してくれる行為として大いに役に立ちました。

デザイン工程における手描きとは

ここで私がなぜ手描きがデザイン工程において相性が良いのかを考えます。

まず、デザイン工程が線形であるというのは間違いです。また特定のフレームワークを使う必要があるというわけでもありません。終始不確実性との戦いを通して抽象度の高い概念から最終的な形を見出すプロセスです。5段階モデルを使って図で表すと、戦略から表層まで具体度を高めつつ必要に応じて各段階から各段階へとジャンプすることになります。

（このプロセスがデザインというものを取っ付きにくくしているのですが、これについては仕方がないと考えます。この現象が持つ属人性の是非についてはまたどこかで想いを巡らせます）

またそのなかでアブダクションという言葉が非常に重要になっていきます。デザイナーは日々最終的な形に責任を持つので、制作する段階でも最終的な形に注目します。思考のプロセスとしてはプロジェクトのなかで考慮できる制約や今までの経験則からもっともらしい形を先に見出して、なぜその形が成り立つのかを言語化するという感じです。

また工程のなかでもう1つの重要なポイントは「いかにどれだけのパターンを出せるか」です。デザインの5段階における構造以降ではメインのユーザーストーリーやユースケースが大分固まっていることが多いですが、それ以前はそれすらも固まっていませんし不確実なことが多いです。

この段階でUIを考えることについて賛否両論ありますが、私は積極的にこの時点で手描きでパターンを量産します。なぜなら不確実性に向き合うということは、1つの最も正解に近いと思われる可能性を除き他の可能性を潰していくということになるからです。それをするためにはあらかじめあらゆる可能性を見出さなければなりません。

そこで手描きが役に立ちます。手描きであることで、可能性のある形を見出しそれが成り立つ論理を考えるという一連の行為を高速で反復できます。

SmartHRは手描きが成り立つ環境にある

手描きというデザインツールは高速でイテレーションを回すことができて非常に有用なツールですが、すべての状況において有効なわけではありません。手描きは色々な情報を削ぎ落としてしまうため、チーム内で形に対する共通認識が一定以上である状況下でのみ力を発揮します。

SmartHRではSmartHR Design SystemやSmartHR UIといった多くの資産があります。これらの資産を用いて開発を行なうので、各原則やコンポーネントに対する共通認識がチーム内で持てていれば、わざわざデジタルデザインツールを使って可視化する必要がないのです。

逆に、形に対する共通認識がチーム内で持てていない場合は、戦略や要件以降の段階で手描きを積極的に使うべきではありません。チームに対してUIの設計の意図を伝えにくくなることも考えられるので手描きを使う際には十分状況を見極めましょう。

私がデザインファイルを詳細に設計しない理由

私はUI設計の意図を周囲に説明するたびに常々「この設計はまだまだ変更の余地があります」と付け加えます。そうすることでチームがUI設計に参加できる余地があるという印象を与えることができると考えるためです。チームが設計に参加することは必須ですし、SmartHRのような大規模なソフトウェアのUIを1人で設計することはほぼ不可能です。

同じような理由で私はデザインファイルをあえて詳細に作りません。状況にもよりますが、基本的にデザインファイルを整えるということには時間を費やしません。私が最低限可視化する必要があるのは大まかな構造です。細かいUIの状態や振る舞いは、デザインシステムによって規定されていたり、もしくはデータの流れが絡むこともありエンジニアのほうが優れた設計に対する知見を持っていることも多々あります。

またSmartHRの他プロダクトの知見を持っているメンバーもいます。それらに関する会話をチーム内で引き出し、よりよいUIを設計するためには、私の方で設計しすぎない = 他メンバーが考えられる余地をあらかじめ持っていくことが重要だと考えます。

現在のソフトウェアデザイン業界では「デザイナーだけでやるにはデザインは重要すぎる」や「チームでデザインする」という考え方が主流になってきています。それを考えるとデザイナーがデザインファイルを詳細に設計する行為はチームがデザインに介入する余地をなくし、ひいてはチームでデザインする文化から遠ざかってしまうのではないでしょうか。私はデザインファイルからの脱却を提唱します。

それでもソフトウェアデザインツールが必要

私はエンジニアから「ユーザーへの解像度を高めたい」という声を時折聞くことがあります。それに対して私は、SmartHRではユーザーに触れる機会は多くあるのにも関わらず、なぜそのような要望が出てくるのが不思議になることがありました。ですがSmartHRに入社して以降、公私でコードを書くようになり、コードを書くうちに今書いているコード以外のことに目を向けられなくなっているということに気づきました。これは構造上仕方のないことなので、特に是非については考えませんが、これでは確かにユーザーの解像度が高まることはありませんし、ユーザーの行動にどう影響するのかを考えながらコードを書くのは難しいと思いました。

そこでデジタルデザインツールを操作することが解決策の1つになると考えます。デザインツール上では常にユーザーが操作するすべてのUIを俯瞰できます。また操作するフローのなかで前後の文脈を想定しながら、それらをユーザーのゴールと照らし合わせることができるのでユーザーへの解像度が高く保った状態でUIを設計できます。

Illustratorなどのグラフィックデザインツールを使用しているときの様子を考えると、グラフィックの詳細を確かめたいときは顔を画面に近づけ、他の要素との全体的なバランスを確かめたいときは顔を画面から遠ざけるといった画面と顔を遠ざけたり近づけたりする行為がよく見受けられます。

この構図はソフトウェアデザインツールとエディターとの関係に似ています。グラフィックデザインツールのなかで全体と一部を行き来するように、ソフトウェアデザインツールでもユーザーがUIを使用する様子や他プロダクトとの辻褄などを確かめ、エディターでUIの詳細やデータの流れを考えることを交互に行なうことで、統一されていて詳細も細かく考慮された優れたソフトウェアができるのではないでしょうか。

また視覚的に構造を把握できるという点でソフトウェアデザインツールは大きく役に立ちます。今担当しているプロジェクトでは、設計の経緯、オブジェクトの概念図、さらにはDBのテーブル設計図までFigmaに集約しています。こうすることで視覚的にDBからUIまで一気通貫して整合性を確かめることができます。これはソフトウェアデザインツールにしかできません。

あとがき: AI大航海時代におけるデザインツールのあり方

今までは、現在のソフトウェアデザインをとりまく環境という前提で書きましたが、これからはAIがより革命的な進化をすることが目に見えているため、今後のソフトウェアデザイン業界がどうなるかはわかりません。ですがある程度の未来予想はできます。

数日前にこのようなツイートを見かけました。

AIアシステッドな工程を経た制作物に誇りや自尊心を持てるかといった類の話は、20年以上前にPhotoshop等のデジタルツールで(楽をして)作ったものは作品と呼べるのかみたいな議論やSAIの線補正で描いたイラストは自分で引いた線と言えるのかといった議論が散々あった事実だけで十分な説明になってそう

— sabakichi (@knshtyk) March 11, 2023

このツイート自体の内容の是非については特に何も考えていませんが、このツイートがデザインツールにおいてアナログからデジタルの変化が、非AIからAIへの変化とどう違っていくのだろうかということに想いを馳せるきっかけになりました。

結論、当面デザイナーは今まで通りのデザインツールを主に使っていくと思っています。それを考える上で重要になっていく考え方が「オブジェクトの直接操作」になります。UI設計にも同じような考えがありますが、少し意味合いが違います。

手描きでは自分が描きたい形を自分の手でペンを通して表現します。この直接性というのはデジタルになっても変わりませんでした。効率的にはなっても、結局は自分が操作したいオブジェクトを作成、編集、複製をします。これらの行動を反復して抽象から具体へと自由度高く、最終的に自分が思う理想的な形へとつなげていくわけです。

一方、今のAIへの入力方法はプロンプトという自然言語をベースにしたコマンドです。もちろん、色や形への言及はプロンプトのなかでできますが、そこに形への直接操作はありません。あくまでAIを介して成果物に手を加えるという工程になります。

また現状のAIはプロンプトエンジニアリングを極めない限り再現性が低い状態です。AIが出力するのは学習されたデータと入力されたプロンプトからはじき出された最もありえそうなものですが、これでは非現実的や創造的なアイデアを出すためにAIが補助になることはあっても最終的な成果物の責任を追わせることはできません。

以上の理由から当面はデザイナーの手や経験が重要だろうと考えます。前述したとおりAIが想像もつかないくらい進化した場合、この通りではないでしょう。

おわり

デザインツールは非常に便利で効率的にUIを設計できます。ですがチームでデザインすることが求められる現況で、デザインツールの進化はコラボレーションの枷になりえるという何とも皮肉な状況を生み出します。これを防ぐにはツールを使うデザイナーのリテラシーに委ねられる以外には現状解決策がないように感じます。私の考えはあくまで一例ですが、このコラムがデザインツールとの付き合い方に向きあうきっかけになれば幸いです。

著者

Nao Enomoto