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