SaaSアプリUI/UX
こんな課題ありませんか
- 画面を作り直したいが、どこから手を付ければ効くのかが決まらない
- 機能を足すたびにルールが増えて、前からある画面と揃わなくなっている
- Figma で決めたはずのものが、リリースされると別物になっている
- 社内にデザイナーがいない、または開発担当が兼任していて、判断の基準がない
- 無料登録は増えているのに、最初の設定を終える前に消えている
- ローンチ日が先に決まっていて、画面を全部つくりきる時間がない
- 外注すると提案書とデザインカンプは出てくるが、触れるものは最後まで出てこない
humbulls の特徴
図面を承認する前に、触れるものを出します
対応する課題: 「どこから手を付ければ効くのか決まらない」「最初の設定を終える前に消えている」「触れるものが最後まで出てこない」
デザインカンプは、見て良し悪しを判断できる範囲が限られます。押した後に何が起きるか、データが1件も無いときにどう見えるか、エラーが出たときにどこへ戻るのかは、動かさないと分かりません。humbulls は先に触れるモックをつくり、仮公開の URL で渡します。社内の誰でも自分の端末で操作できるので、「どの画面から直すか」を、実際に触った実感で決められます。モックの作成には AI を併走させるので、捨てる前提で複数案を出せます。
決めた値が、そのまま実装に入る形で渡します
対応する課題: 「前からある画面と揃わなくなっている」「Figma で決めたものが別物になる」「判断の基準がない」
画面の決定をスクリーンショットと口頭の申し送りで渡すと、実装との差は毎回のリリースで開いていきます。humbulls は色・余白・文字サイズ・角丸を数値のトークンとして定義し、そこから CSS を生成する形で引き渡します。実装側が値を手で書き写す工程が無くなるので、次に機能を足す人も同じ値を使えます。この構成は humbulls が自社の Web アプリで運用していて、トークンを経由せず生の値を書いた箇所は自動チェックで落ちるようにしています。
引き受ける範囲を、先に区切ります
対応する課題: 「ローンチ日が先に決まっていて、全部つくりきる時間がない」
画面の設計は、humbulls の代表が自分で手を動かしてきた領域です。自社では watchOS アプリを App Store の公開まで、Web アプリを管理画面とトークン基盤まで、設計から実装まで通してつくっています。その前提で引き受けるのは、範囲を区切った画面の設計と実装です。プロダクト全体のデザインの責任を預かる形は取りません。期限が決まっている場合は、期限までに出せる範囲を先に切り出します。力になれないと判断したら、その場でそう言います。
humbulls は画面を、利用者の用事で5つに分けています
SaaS の画面は、どれも同じ基準で良し悪しを測れません。同じ製品の中でも、利用者が何をしに来た画面かで、直すべき場所も、測る数字も変わります。この5つは外部調査にもとづく分類ではありません。
1 開始の画面（登録・初期設定・最初の1回）
登録数が伸びないとき、最初に手が入るのは登録フォームです。項目を減らし、ソーシャルログインを足し、ステップを分割します。フォームの完了率は上がります。それでも有料契約が増えないことがあります。
この画面で見るべき数字は、登録した人が最初の1回を終えた割合です。登録の完了率だけを追いかけても、この割合は動きません。そして開始の画面の標準状態は、データが1件も入っていない状態です。設計はデータが揃った画面を見ながら進むので、空の状態は後回しになりがちです。登録した人が最初に見るのは、その後回しにされた画面です。
空の状態の画面を、いちばん先に設計します。何も入っていないときに何が表示され、次にどこを押せばいいかを決めてから、データが揃った状態の画面をつくります。最初の1回に必要のない設定項目は、後から出す場所へ移します。フォームの項目削減は、この順番の後で検討します。
用事: 登録して、この製品でやりたかったことを一度だけ終えに来る。
2 反復の画面（毎日ひらいて同じ作業をする）
「使いにくい」と言われた画面は、分かりやすさの方向に直されます。ボタンを大きくし、説明文を足し、階層を浅くします。初めて触る人には親切になります。毎日触っている人の作業時間は変わりません。
毎日使う人は、じきに画面の場所を覚えます。その人にとっての使いやすさを決めるのは、1回の作業で何回画面を往復するかです。初めて触る人向けの親切さは、その頃には効き目を失っています。一覧から詳細へ入って戻る、絞り込みを毎回かけ直す、別のタブで開き直す。この往復は説明文を足しても減りません。
改修の前に、担当者の1日の作業をそのまま並べて、1タスクあたりの画面遷移とクリックの回数を数えます。減らす対象は往復の回数です。絞り込み条件の保存、一覧の中での編集、直前の状態への復帰を優先します。初回向けの説明は、初回だけ出す形にして、2回目以降の画面からは外します。
用事: 決まった作業を、今日も終わらせに来る。
3 設定の画面（一度決めて、あとは忘れる）
設定画面は使用頻度が低いので、優先度も低く置かれます。項目を縦に並べ、保存ボタンを下に付けて完成とします。頻度が低いのだから、多少分かりにくくても影響は小さいと考えます。
頻度が低い画面ほど、来る人は毎回はじめての状態で来ます。前回どう設定したかは、たいてい覚えていません。設定画面で詰まった人は、自力で解決せずに問い合わせます。詰まる場所は、毎日使う画面より、年に数回しか開かない画面のほうに残ります。
設定項目を「変えると他の人に影響が出るか」で2つに分けます。影響が出る項目には、保存する前に結果を確かめられる表示と、元に戻す経路を付けます。項目名と説明文は、画面を設計した人がそのまま書きます。設計と文言の担当を分けると、画面の中で言葉が食い違い、その食い違いがそのまま問い合わせになります。
用事: 決めに来る。決めたら二度と来ない。
4 持ち出しの画面（数字を見て、社内の誰かに渡す）
分析画面の価値は、指標の数とグラフの種類で決まると考えられています。要望を聞くと項目は増え続け、ダッシュボードは長くなります。作り込むほど、画面の中で意思決定してもらえるはずだと考えます。
この画面で最後に押されるのは、たいてい書き出しのボタンです。利用者はその数字を上長への報告や別のツールへ持っていきます。持ち出された先で数字の定義が食い違うと、「このツールの数字は合っていない」という評価だけが残ります。グラフの数は、その評価に影響しません。
画面をつくる前に、誰がその数字を誰に見せるのか、何を判断するのかを1枚に書きます。そこに登場しない指標は画面に載せません。指標の定義は画面の中に書き、書き出しと共有 URL を最初から設計に入れます。humbulls は自社サイトの計測を Google アナリティクスと Search Console から内製して運用しています。出す数字を先に決めて組んだので、同じ形を別サイトで再現するのにかかったのは1週間でした。
用事: 数字を見に来るのではなく、数字を持ち出しに来る。
5 代行の画面（自分ではなく、他人のために触る）
管理者向けの画面は、契約者側の内部処理なので後回しにされます。招待、権限、請求、利用状況を1つずつ足していき、それぞれ別の画面に置きます。実際に触るのは少人数なので、影響も小さいと考えます。
更新や解約の稟議を書くのは、多くの場合この画面を触る人です。その人が見るのは、席がいくつあり、そのうちいくつが使われているかです。使われていない席の数しか出せない画面は、更新の場で契約を減らす材料だけを差し出すことになります。
管理の画面には、席の数と一緒に「誰が何に使ったか」を並べます。招待・権限の変更・退職者の処理を1つの画面で終えられるようにし、いつ誰が変更したかの履歴を残します。履歴が残っていると、セキュリティの確認を求められたときに製品の中だけで答えられます。
用事: 席を足す、権限を外す、請求を確認する。自分の仕事のためではない。
5つのうち、どこから手を付けるか
同時に直せるのは1つか2つです。登録直後に消えているなら開始の画面、解約が続いているなら代行の画面、問い合わせが多いなら設定の画面から入ります。反復の画面は要望がいちばん集まる場所ですが、そこから始めても契約の数字は動きにくいので、humbulls は後ろに回します。
進め方
進め方は案件ごとに変わります。標準の形は次の6ステップです。
相談
対象のプロダクトと、いまどの画面で何に困っているかを聞きます。上の5つの用事のどこの話なのかを、この場で切り分けます。登録直後の離脱と、毎日の操作の遅さと、管理者からの不満は、同じ「使いにくい」という言葉で報告されますが、直す場所が違います。切り分けずに見積もると、要望の多い画面から着手することになり、契約の数字は動きません。
- 主な成果物: 切り分けメモ（対象の画面と、いま触らない範囲）
- 所要: 60分・無料
動くモックの提示
聞いた内容から、触れるモックをつくって仮公開の URL でお渡しします。画面は1〜2枚に絞ります。この段階でお渡しするのは、社内で「これで合っているか」を確かめるための材料です。ここで方向が違うと分かることに意味があるので、モックを見て発注しない判断もできます。
- 主な成果物: 動くモック（仮公開 URL）
- 所要: 1週間以内・無料（月5社まで）
範囲と優先順位の確定
どの画面から着手し、どこまでを humbulls が引き受けるかを決めて見積もります。実装まで含めるのか、設計とコンポーネントの引き渡しで終えるのかも、ここで決めます。期限が決まっている場合は、期限までに出せる範囲を先に切り出し、残りを次の区切りに送ります。
- 主な成果物: 対象画面リスト・見積もり・スケジュール
画面設計
対象画面の構造・状態・遷移を決めます。ここでの状態とは、空・読み込み中・エラー・権限が足りないときのように、画面が取りうる形のことです。正常系だけを設計すると、実装の段階で判断が開発側へ降り、画面ごとに違う答えが入ります。設計と並行してモックを更新するので、確認は動くもので行います。
- 主な成果物: 画面設計（構造・状態・遷移）／更新したモック
デザイントークンとコンポーネントの整備
色・余白・文字サイズ・角丸を数値として定義し、そこから CSS を生成する形に整えます。対象画面で使うコンポーネントを実装し、どの値をどこで使うかを一覧にします。実装側が値を手で書き写す工程が無くなるので、次に機能を足す人も同じ値を使えます。
- 主な成果物: デザイントークン（JSON と、生成した CSS）／コンポーネント一式／使い分けの一覧
引き渡し、または実装
開発チームに引き渡す場合は、開発側が読める粒度の指示書と、更新の手順書を渡します。humbulls が実装まで引き受ける場合は、この工程で実装します。どちらにするかは契約の時点で決めます。繰り返し発生する作業は AI スキル（.md ファイル）にして渡し、その場で一度実行してもらいます。
- 主な成果物: 開発指示書／更新手順書／AI スキル（.md）／または実装したコード
成果物
進め方の各ステップで、次のものが手元に残ります。
| # | 成果物 | 中身 |
|---|---|---|
| 1 | 切り分けメモ | どの用事の画面の問題か、いま触らない範囲はどこか |
| 2 | 動くモック（仮公開 URL） | 触れる画面。工程ごとの版が URL に残る |
| 3 | 画面設計（構造・状態・遷移） | 空・読み込み中・エラー・権限不足を含む状態の一覧 |
| 4 | デザイントークンと生成後の CSS | 決めた値と、実装に入った値の対比 |
| 5 | 更新手順書と AI スキル（.md） | 同じ作業を、担当者が指示1つで再現できる状態 |
無料相談
まず、どの画面で困っているか聞かせてください 相談は60分。上の5つの用事のどこで起きていることなのかを、その場で切り分けます。売り込みはしません。話した内容から1週間以内に動くモックをつくってお渡しします（無料・月5社まで）。フォームからのご連絡には3営業日以内に返信します。
関連ナレッジ
画面と実装のあいだで humbulls が実際に使っている手順は、記事で公開しています。
FAQ・価格・完了後の道
費用の目安
対象の画面数と、実装まで含めるかどうかで変わるので一言では答えられませんが、考え方は先に出します。
予算が決まっている場合は、その範囲でできることを切り出して提案します。
工程ごとの内訳
| 工程 | 内容 |
|---|---|
| 切り分け・モック | 用事の切り分け、触れるモック1〜2画面 |
| 設計 | 対象画面の構造・状態・遷移の設計 |
| トークンとコンポーネント | 値の定義、CSS 生成、対象画面ぶんの実装 |
| 引き渡し または 実装 | 開発指示書と手順書の作成、または実装 |
工程を切り出しての依頼も受けます。設計だけ、トークンの整備だけ、という形でも構いません。
よくある質問
金額は何で決まりますか。
対象の画面数と、実装まで humbulls が担当するかどうかの2つで決まります。工程ごとの内訳は上の「費用の目安」に出しています。設計だけ、トークンの整備だけ、という形でも受けるので、予算が決まっている場合は先に伝えてください。その範囲でできることを切り出して提案します。
引き渡しまでにかかる日数を教えてください。
最初の相談は60分、そこから動くモックまでが1週間以内です。そこから先の期間が決まる条件は、画面数と実装の有無です。
いますぐ着手してもらえますか。
相談そのものはいつでも受け付けます。ただし動くモックを無料でお出しするのは月5社までで、同時に進める案件数にも上限を置いています。1件あたりの手数を落とさないために上限を置いています。着手時期は相談のタイミングで前後します。
SaaS プロダクトの UI/UX を請けた実績はありますか。
画面設計は代表が自分で手を動かしてきた領域ですが、サイトに掲載している事例はまだありません（準備中）。自社では watchOS アプリを App Store の公開まで、Web アプリを管理画面とデザイントークンの基盤までつくっています。どちらも設計と実装を分けずに通しているので、実装の見込みが立たないものを設計に置きません。掲載事例で判断できない段階なので、まず動くモックをお出しします。それを見て判断してください。
業務システムのUI/UX とは何が違いますか。
対象にしている画面の性質が違います。SaaS は社外の顧客が使う画面で、契約前の評価対象になり、使いにくければ解約につながります。業務システムは社内の担当者が使う画面で、すでに回っている運用を止めないことが優先されます。同じ「使いにくい」でも、直す順番の決め方が変わります。
設計には触らず、ビジュアルの仕上げから入ってもらえますか。
この形では受けていません。設計の意図を聞かずにビジュアルを整えると、実装の段階で判断が開発側へ降り、画面ごとに違う答えが入ります。設計の見直しを含む形であれば受けます。すでに社内で設計が固まっている場合は、一度見せてください。手を入れる必要が無ければ、実装とトークンの整備から引き受けます。
デザインシステムの構築と運用まで頼めますか。
範囲を区切る形なら受けます。トークンの定義と、対象画面ぶんのコンポーネントの整備までです。プロダクト全体のデザインシステムを継続的に運用する役割は、このメニューでは引き受けません。継続的に見る必要がある場合は、その体制を持っている会社を紹介します。
実装は社内の開発チームがやります。どこまでを渡してもらえますか。
その形が前提です。渡すのは画面設計と、トークン（JSON と、そこから生成した CSS）、それに対象画面ぶんを実装したコンポーネントです。開発チームはそれを参照しながら残りを進められます。引き渡しの後に仕様が変わった場合の修正も、別の見積もりで受けます。
相見積もりに出すので、まず提案書をもらえますか。
提案書は出していません。契約前に無償で出すのは、打ち合わせと見積もり、それに動くモックまでです。比較の材料にはモックを使ってください。設計の中身を書面に起こすところからは有償になります。
AI をどこまで使いますか。プロダクトのデータは学習に使われませんか。
モックの生成、設計案の作成、コンポーネントの実装、繰り返し作業のスクリプト化に AI を使います。データの扱いは要件に合わせて選べます。機密度が高い場合は、実データを AI に渡さず、AI にはコードを書かせ、データの処理はそのコードが実行する構成にします。この形では、AI がデータに触れる経路が設計として存在しません。アカウントや保存先を顧客名義にする運用にも対応します。
完了後の道
引き渡しの時点で、社内で直せる範囲と、humbulls に戻す範囲を線で分けて書き出します。トークンと手順書が手元に残るので、次の機能を足すときも同じ値を使えます。
画面の外側（獲得・登録後のフォロー・解約の防止）まで続けて見る必要が出てきた場合は、伴走の Growth Partner（月額30万円〜）に接続できます。社内向けの画面が対象になる場合は、業務システムのUI/UX に接続します。