あるSaaSをデザインしたら、デザインツールのデザインだった！？7つのノウハウをシェア
「デザインツールをデザインする」そんな仕事をやってみたいと思ったことはありませんか？ デザイナーにとってデザインツールを作るのは興味深く、また高い難易度を予感させます。実際何に気をつけるべきなのでしょうか？ノウハウは？ 今回は、あるSaaSのウェブエディター開発から学んだ、SaaSやデザインツールをデザインする具体的なノウハウ7選。プロパティ選定からUI決定まで、具体的な検討ノウハウをシェア！
Introduction
こんにちは、2024年初のニュースレター配信です。最近AI開発の現場にいて毎日がとても楽しい吉永です。
さて先日、ある種のデザインツールをデザインする機会に恵まれました。
デザインツールを設計することはデザイナーにとって楽しいものです。私も嬉々として取り組み、その中には多くの学びがありました。
未来の自分へ、そしてこれから似た仕事をする方々へ向けて、その学びを備忘録として残します。
ノウハウ編と反省編の2つに分けてシェアします。両方を一緒くたにすると焦点がぼやけてしまうので。今回はノウハウ編です。
もくじ
プロパティを取捨選択する
ノウハウ1. プロパティの多さについて認識する
ノウハウ2. オブジェクトを特定しよう
ノウハウ3. オブジェクト資料, プロパティ資料を使ってプロパティについて議論
UIの検討
ノウハウ4. プロパティをどこで編集させるか検討
対象ユーザーの慣習を理解しよう
ノウハウ5. 想定される顧客の利用頻度を考慮すべし
ノウハウ6. 対象ユーザーが慣れているツールから慣習的操作を想定すべし
ノウハウ7. タスク処理速度にこだわろう
プロパティを取捨選択する
ノウハウ1. プロパティの多さについて認識する
デザインツールの設計における最初の関門は、プロパティ数です。
この種類と数の多さが多ければ多いほど、ツール内でより自由な作業や操作を行うことが出来るようになります。
“デザイン”に類される大抵のことはその業務において一定の自由を求めるため、プロパティを膨大にしがちです。しかし、どのくらいの自由度であるべきかはドメインやコンセプトによって異なります。
ちょうどいい塩梅を見つけなければ、ネガティブな事態を引き起こします。
例えば、
フリーキャンバスの上での作業が求められるのに、デザイン編集をGUIパネルでの入力・選択によってのみ出来るようにしてしまい、ユーザーの作業工数が無駄に増えてしまった。
テンプレートや所与のアセットを操作できれば十分なのに、要素1つ1つをパズルのように組み立てられるようにしてしまい、ユーザーの作業工数が無駄に増えてしまった。
といった具合です。
よって、必要なものを整理し最適なプロパティ数を見極めなければなりません。
ノウハウ2. オブジェクトを特定しよう
インターフェースの設計に紐づけてプロパティを特定するには、オブジェクト指向に則ってモデリングしてみるのが適しているでしょう。UI Flowsでも構いませんが、ビュー単位のCRUDを表記できない1点で最適ではありません。
例として、架空のプロダクトのモデリングをお見せします。
以下は「生成AIを使って4コマ漫画を作れる」という機能を持つ、4コマ漫画のデザインプロダクトのモデリングです。
(使用したOOUIテンプレートはこちら)
ノウハウ3. オブジェクト資料, プロパティ資料を使ってプロパティについて議論
上記はOOUIモデリングによって行われており、1枚目の画像でプロパティを明らかにし、2枚目でUIの論理を構成, 可視化されているのが分かります。
これら資料により、あるべきプロパティについてUIを作り始める以前から開発者間で議論することが出来るようになります。
ただし必ずしもOOUIモデリングでなくともよいです。ER図を使っても似たような効能があるでしょう。
デザイナー間で話す際はOOUIモデル, エンジニア間で話す際はER図、といった風に資料を使い分けるのが最適だと考えています。要はドメインモデリングがしっかりしていれば、OOUIでもER図でもよいのです。
UIの検討
ノウハウ4. プロパティをどこで編集させるか検討
モデリングとそれに続く議論によってプロパティを決めたら、次はそのプロパティをどこで・どのように編集, 操作できるようにするかを決めます。
“デザインツール”と総称できるプロダクトの場合、一般的なパターンとしては次のような選択肢があるでしょう。
サイドペイン
ツールバー
インラインエディター
モーダル類(Dialog, Popover, Drawerなど)
以前私が担当したSaaSのケースでもこの4案から検討し、初期案ではサイドペインを採用していました。しかしユーザビリティテストの結果、改善の余地があると思われたため、よりこだわるべき箇所として、ある時点でインラインエディターへ変更しました。
対象ユーザーの慣習を理解しよう
ノウハウ5. 想定される顧客の利用頻度を考慮すべし
UIを決める際、私たちは普段自分が使っているツールに発想を引っ張られがちです。
例えば、
「SlackやNotion, Asanaのようにサイドバーにコンテンツを並べよう」
「Figmaのようにサイドペインで編集できるようにしよう」
「FigJamやMiroのようにツールバーにツールを格納しよう」
「Googleカレンダーのようにダイアログで詳細を見れるようにしよう」
といった具合です。
参考にするのはよいですが、この考え方には欠点があります。
それは、自分が普段使っているツールに比べて自社プロダクトがさほど高頻度で使うものでない場合、それらをマネしても望ましい設計にならない可能性が高いという点です。
ユーザーには高頻度で使ってほしいですし、またそうなるよう努めるべきですが、高頻度で使うことを前提とした設計をすることは努力とは違うのです。ここを履き違えないようにしましょう。
現時点で予想される利用頻度が高くないならば、素直に別の発想を一度探索してみることです。発想はいつでも柔軟に。
ノウハウ6. 対象ユーザーが慣れているツールから慣習的UIを想定すべし
別の発想にたどり着くためのコツの1つは、対象ユーザーが普段使っているツールを知っておくことです。人のメンタルモデルは日常生活から形成されるからです。UIへのメンタルモデルも例外ではありません。
ユーザーが普段使うツールを知るには、商談の録画を鑑賞・分析したり、カスタマーサクセスやセールスへヒアリングすればすぐに分かります。
例えば最近よくあるのは、SalesforceもしくはHubspot、PowerPoint、Zoomあたりがユーザーに共通するツールでした。
このようなユーザー像であれば、ツールバー案(PowerPointやZoom寄り)や、タスク指向的な導線設計(Hubspot寄り)を採用しても良い結果になる可能性が高いです。
ノウハウ7. タスク処理速度にこだわろう
デザインツールの場合、その性質上toCであれtoBであれ大なり小なり業務システムとなります。よって、そのタスク処理速度にこだわることがユーザーの幸福(提供企業目線では満足度)に繋がります。
マウス移動量, 視線移動量, クリック数, ユーザビリティテストでのタスク処理速度などにこだわりましょう。
一例として、以前私が担当したケースでは、社内外で複数のUI案に対し繰り返しユーザビリティテストを行い、最も成果がよいものを選択することでUIを決定しました。
SaaS, デザインツールのデザインのチェックリスト
プロパティの数とその重要さについて理解した
OOUIモデリングやドメインモデリングを行った
望ましいプロパティについて議論した
プロパティをどこで編集させるか検討した
想定される顧客の利用頻度を理解した
対象ユーザーが普段使っているツールを理解した
ユーザーのタスク処理速度にこだわって設計した
次回予告
反省編
あるデザインツールのデザインが一区切りして少し経ったいま、こうして振り返ってノウハウを言語化してみると、ノウハウだけでなく多くの反省点があることにも気づきます。
楽しかった で終わらせることも出来ますが、それではつまらない。しっかり反省することが私らしいムーブであるように思われます。
来週は「反省編」と題し、今回紹介したノウハウのもとになった仕事から得た8つの反省点をシェアします。
Substackアプリを使うと読みやすいのでおすすめです。
UI Flowsで表記するCRUDは画面単位。