「ここ、ちょっと使いにくいんですけど」
SaaSを公開して初めてユーザーからもらったフィードバック。正直に言います。
最初はちょっとヘコみました。
「え、そこわかりにくい？ 自分ではめちゃくちゃわかりやすく作ったつもりだったのに」
でも、冷静になって考えると、それは当たり前のことでした。
作った側と使う側では、見えている景色がまったく違う。
今日は、ユーザーからのフィードバックで気づいた「自分では見えなかった改善点」について、正直に話します。
自分で使っていると「盲点」が増える
開発中、私は毎日このツールを使っています。
機能を追加するたびに自分でテストする。動作を確認して、「よし、これでOK」と判断する。
でもここに罠がある。
自分は「全機能を知っている状態」で使っている。どのボタンを押せば何が起きるか、頭に入っている。エラーが出ても、何が原因かわかっている。
初めてログインしたユーザーは、その「前提知識」がゼロの状態で触り始める。
ここのギャップが、想像以上に大きかった。
実際にもらったフィードバックと改善
フィードバック①：「どこから始めればいいかわからない」
状況： ログイン後のダッシュボード画面。複数の機能ボタンが並んでいたが、「最初に何を押すべきか」が不明だった。
自分の認識： 「左から順番にやれば良いことは明白でしょ」
ユーザーの認識： 「ボタンが6つあるけど、どれを押したら何が起きるの？ 怖くて押せない」
改善： 初回ログイン時に「まずはここから」というステップガイドを表示するように変更。ボタンには説明テキストを追加。
気づき： 開発者にとっての「明白」は、ユーザーにとって「不明」であることが多い。
フィードバック②：「処理が終わったのかどうかわからない」
状況： バッチ処理を開始した後、画面に変化がない。裏側では処理が進行しているのに、フロント画面が静止状態。
自分の認識： 「ターミナルのログを見れば進行状況はわかるし」
ユーザーの認識： 「ボタン押したのに何も変わらない。壊れた？ もう一回押すべき？」
改善： 進行状況をリアルタイムで表示するプログレスバーを追加。「処理中です。完了まで約10分かかります」というメッセージも表示。
気づき： 「何も起きていないように見える」ことは、ユーザーにとって最大のストレス。
フィードバック③：「エラーメッセージの意味がわからない」
状況： サーバーとの接続エラーが発生したとき、「Error 500: Internal Server Error」と表示された。
自分の認識： 「500エラーか、サーバー側の問題だな。ログ見よう」
ユーザーの認識： 「Error 500って何？ 自分が何か間違った？ データ消えた？」
改善： エラーメッセージを日本語化。「サーバーとの接続に問題がありました。数分後にもう一度お試しください。問題が続く場合はお問い合わせください」に変更。
気づき： エラー表示は「何が起きたか」ではなく「何をすればいいか」を伝えるべき。
フィードバック④：「設定画面が多すぎて迷う」
状況： 記事のカスタマイズ設定。文体、キーワード密度、記事の長さ、画像スタイル、CTA配置……細かい設定項目が20以上あった。
自分の認識： 「細かく設定できた方が親切だよね。選択肢は多い方がいい」
ユーザーの認識： 「設定項目が多すぎて、どれをいじればいいのかわからない。全部デフォルトでいいの？」
改善： 「おすすめ設定でワンクリック」ボタンを追加。細かい設定は「詳細設定」タブに隠す。ほとんどのユーザーはデフォルトで十分動作するように設計し直し。
気づき： 選択肢が多いことは「自由度が高い」ではなく、「何を選べばいいかわからない」になりうる。
フィードバックから学んだ3つの原則
原則1：「自分目線」を捨てる
開発者は開発者視点でしか見られない。ユーザーの目線は、ユーザーにしかわからない。
だから、フィードバックは宝。「使いにくい」と言ってもらえることは、改善のチャンスをもらっているのと同じ。
原則2：「わかりやすさ」は機能より大事
高度な機能を10個追加するより、既存の3つの機能を誰でもわかるように改善する方が、ユーザー満足度は上がる。
これは建築の仕事でも同じでした。すごいデザインの家より、動線がわかりやすい家の方が、施主さんは喜ぶ。
原則3：フィードバックは「即」反映する
「検討します」と言って3ヶ月放置するのと、「直しました！」と3日で反映するのでは、ユーザーの信頼感が天と地。
個人開発の強みは、フィードバックから改善までのスピード。大企業にはできない速さで改善できる。これは最大の武器。
フィードバックをもらいやすくする仕組み
ただし、フィードバックは放っておいても集まりません。
私がやっていること：
- LINEで気軽に送れる環境を用意する。フォームやメールは面倒すぎる
- 「使いにくいところがあったら教えてください」と定期的にメッセージを送る
- フィードバックをくれた人に感謝のメッセージを返す。次も送ってもらいやすくなる
- 改善したら「〇〇さんのフィードバックで改善しました！」と報告する
フィードバックの循環を作ることが、プロダクト改善の最短ルートです。
「一緒に作っていく」という関係
最終的にたどり着いた考え方は、「ユーザーと一緒にプロダクトを作っていく」というものです。
完成品を売るのではなく、未完成品を一緒に育てる。
バグがあれば教えてもらう。使いにくいところがあれば改善する。「こういう機能が欲しい」と言われたら、できる限り実装する。
これは大企業のSaaSではなかなかできないこと。個人開発だからこそできる、距離の近さが強みだと思っています。
一緒に走ってくれているユーザーの皆さん、本当にありがとうございます。
こちらの記事もあわせてどうぞ：
【無料】LINE登録で2大特典を配布中
「AIで記事を書いてみたいけど、どう指示すればいいかわからない」
そんな方のために、私が97記事を量産する中で実際に使い込んだ12のプロンプトをまとめました。
コピペでそのまま使えます。
受け取り方はカンタン：LINEに友だち追加するだけ。
🎁 特典① AIブログ記事作成プロンプト集（12本）
✔ キーワード選定からリライトまで、記事作成の全工程をカバー
✔ ChatGPT・Claude・Gemini、どのAIでも使える
✔ コーチ→建築→AI副業と渡り歩いた筆者が実際に成果を出したプロンプトだけを厳選
🎁 特典② 中古ドメイン取得 完全マニュアル（PDF） ← NEW!
✔ 良い中古ドメインの見分け方（5つの判断基準）
✔ 有料サービスの比較と購入手順（おすすめはコレ）
✔ 自分で探す方法＆Xserverへの設定手順まで完全網羅
さらに、LINE登録者には「素人SaaS開発の裏側レポート」も近日配信予定です。