レビューや評価機能を持つサービスを設計するとき、多くの人が「星の数」と「テキストボックス」を置けば完成だと思っている。私もそう思っていた。
Google Stitch でレビューUIを設計し始めてすぐ、この認識が甘かったことを痛感した。ユーザーにレビューを書いてもらうことは「フォームを用意すること」ではなく「行動を起こさせるデザイン」だ——この気づきから、レビューUI設計の難しさが見えてきた。
結論から言うと、レビュー・評価UIの設計で最も重要なのは「書く心理的ハードルを下げること」だ。星評価だけなら気軽にできる。でもテキストのレビューを書いてもらうには、「何を書けばいいか」「どれくらい書けばいいか」「書く価値があるか」という3つの問いにUIが答えている必要がある。Stitchでその設計を試行錯誤した経験を、この記事で書く。
レビュー・評価UIとは何か——「書く行動」を設計するUI
レビュー・評価UIとは、ユーザーが商品・サービス・場所・コンテンツなどへの評価や感想を投稿できるUIコンポーネントの総称です。星評価（レーティング）・テキストレビュー・写真投稿・タグ選択・いいねボタンなど、様々な形式がある。
レビューUIはサービスにとって二重の価値を持つ。一つは「既存ユーザーの声を集める」というデータ収集の価値。もう一つは「他のユーザーへの購買・選択の参考情報を提供する」という社会的証明の価値だ。
しかしこの二つの価値を得るためには、ユーザーが実際にレビューを「書く」という行動を取る必要がある。この行動を促すUIの設計が、レビュー機能の設計の本質だ。
Stitch でレビューUIを設計した手順
最初のプロンプトは「ECサービスの商品レビュー投稿画面。星評価・テキストレビュー・写真追加の機能を持つ」。
生成された画面は機能的だった。星が5つ並び、テキストエリアがあり、写真アップロードのボタンがあった。しかし見た瞬間に感じたのは「書きたくならない」という感覚だった。
何が足りないのか考えた。テキストエリアのプレースホルダーが「レビューを書いてください」という指示だけで、「何を書けばいいか」のガイドが一切なかった。文字数の目安もない。どれくらい詳しく書けばいいかわからない。この「書き出しの難しさ」がレビュー投稿の最大の心理的ハードルだと気づいた。
「書くハードルを下げる」設計の3つのアプローチ
Stitchでレビュー投稿画面を複数生成・比較しながら、「書くハードルを下げる」設計として有効だったアプローチを3つ特定した。
一つ目は「構造化された質問形式」だ。「商品の良かった点は？」「改善してほしい点は？」「どんな人におすすめですか？」のように、質問に答える形式にすることで「何を書けばいいか」の不安が消える。Stitchでこの形式を生成すると、テキストエリア一つより明らかに「書き出しやすい」UIになった。
二つ目は「タグ選択の併用」だ。テキストを書く前に「良かった点に当てはまるタグを選んでください（品質・デザイン・コスパ・配送速度など）」という選択式を設けることで、「テキストを書く前の取り掛かり」が生まれる。タグを選ぶことで「書くべき方向性」が見え、続けてテキストを書く心理的ハードルが下がる。
三つ目は「文字数インジケーター」だ。「あと〇文字で★を一つ追加」「〇文字以上で詳細レビューとして表示されます」という指標を加えることで、「どれくらい書けばいいか」の基準が生まれる。Stitchでこのインジケーターを含む画面を生成すると、テキストエリアが「ゲーム的な達成感」を持つUIに変わった。
星評価だけ・テキスト評価だけの使い分け
星評価のみで完結させるべき場面
全てのレビューがテキスト入力を求める必要はない。Stitchでの設計比較から、「星評価のみで完結」が適切な場面を整理した。
頻繁に使うサービスの都度評価（配達員の評価・Uberのドライバー評価など）は、毎回テキストを求めると「評価疲れ」が起きる。星1〜5だけで完結させ、任意でコメントを追加できる形が最適だ。
また「ちょっとした感想」を集めたい場合——読んだ記事への評価、見た動画への反応——は、テキスト入力より「絵文字反応」や「いいね」の方がレスポンス率が高く、ユーザー負担も低い。Stitchで絵文字リアクション型の評価UIを生成したとき、星評価より「使ってみたくなる」印象があったのが興味深かった。
テキストレビューを増やすためのUI工夫
ECサービスや飲食店レビューのように「詳細なテキストレビューが価値を持つ」場合、テキスト投稿を促す追加の工夫が必要だ。
Stitchで試して効果的だったのは「レビューのメリットを明示する」設計だ。「詳細レビューを書くと、次回購入時に10ポイント付与」「レビューが採用されると、あなたの名前が商品ページに掲載」といったインセンティブをUIに組み込むことで、「書く価値がある」という動機付けが生まれる。
また「写真付きレビューの優先表示」という設計も有効だ。「写真を追加するとレビューが上位に表示されます」という説明をUIに加えることで、写真投稿＝より詳細なレビューへの誘導ができる。写真があるレビューはテキストも充実する傾向があるため、写真投稿の促進がレビューの質向上につながる。
レビュー表示側の設計——「読む体験」も同時に考える
レビューUIの設計は「書く側」だけでなく「読む側」も同時に設計する必要がある。
Stitchで商品詳細ページのレビュー表示セクションを設計したとき、「どのレビューを最初に見せるか」の順序設計が重要だと気づいた。
「最新順」で表示すると、書いたばかりの短いレビューが先に来る場合があり、商品の良し悪しが伝わりにくい。「参考になった順」で表示すると、他のユーザーが「役に立った」と評価した詳細なレビューが上位に来る。
さらに「ネガティブなレビューを隠さない」設計も重要だ。良いレビューだけを見せると「フィルタリングしているのでは」という不信感が生まれる。Stitchで「ポジティブ・ネガティブのバランスを見せる表示設計」を複数パターン生成した結果、「総合評価の分布（星5が何件・星1が何件）を最初に見せる」設計が最も信頼感を生む形になった。
失敗したこと・気をつけるべきこと
1. レビュー投稿のタイミングを後から設計した
レビュー投稿画面のUIは作ったが、「いつユーザーにレビュー投稿を促すか」を後から考えた。購入直後・商品到着確認後・使用から1週間後——タイミングによってレビューの質と量が大きく変わる。UIだけでなく「投稿促進のタイミングと方法（メール・プッシュ通知）」も含めた設計が必要だったが、後回しにしてしまった。
2. 匿名性の設計を忘れていた
レビュー投稿時の「名前の表示設定」を設計していなかった。「本名で投稿するのか」「ニックネームか」「匿名可能か」という選択肢は、特に批判的なレビューを書く際の投稿ハードルに大きく影響する。匿名投稿を許可するかどうかはサービスポリシーの問題だが、UIとして設計する段階から考慮すべき要素だった。
3. レビュー投稿後の「ありがとう」画面を省略していた
レビュー投稿完了後の画面設計を省略していた。「投稿ありがとうございます。あなたのレビューは〇〇人の役に立ちました」のような完了画面は、「また書こう」という動機付けになる。投稿完了をただのトースト通知で終わらせず、レビューへの感謝と次回への動機付けを含む画面として設計すべきだった。
4. 画像レビューのアップロード上限を決めずに設計した
写真付きレビューを設計したが、「何枚まで添付できるか」を決めずにUIを作った。後から「ストレージコスト」の観点でエンジニアと話すと上限が必要だとわかった。UIのデザイン段階で「添付可能枚数の上限と、それを超えたときの表示」まで設計しておくべきだった。
5. 不適切なレビューへの対処UIを考えていなかった
ユーザー生成コンテンツであるレビューには、スパム・誹謗中傷・競合サービスの宣伝などの不適切な投稿が混在するリスクがある。「通報ボタン」「不適切コンテンツのフラグ機能」をレビュー表示UIに含めることは、コンプライアンスとコミュニティ管理の観点から必須だったが、最初の設計では省略していた。
よくある質問（FAQ）
Q1. レビューを書いてもらうために最も効果的なUIの工夫は何ですか？
「何を書けばいいか」の迷いを取り除くことが最も効果的です。質問形式（「良かった点は？」「改善点は？」）やタグ選択（事前に当てはまる点を選ぶ）を用意することで、「書き出しの難しさ」という心理的ハードルが大幅に下がります。テキストエリアに「どれくらい書けばいいかわからない」状態を作らないことが基本です。
Q2. 星評価だけとテキストレビュー、どちらが重要ですか？
サービスの目的によります。「量のデータが必要」なら星評価のみが投稿率を高めます。「質のフィードバックが必要」ならテキストが必要です。現実的な設計は「星評価は必須・テキストは任意」にしつつ、テキストを書いた場合のインセンティブ（ポイント付与・優先表示など）で詳細レビューを促す組み合わせが最もバランスが良いです。
Q3. レビューの表示順序はどう設定するのが最適ですか？
「参考になった順」をデフォルトにしつつ、「最新順」「高評価順」「低評価順」に切り替えられる構成が一般的です。重要なのは低評価のレビューを隠さないこと。全体の評価分布（星5〜1の各件数）を先に見せることで、サービスへの信頼感が高まります。
Q4. レビュー投稿を促す最適なタイミングはいつですか？
「サービスを使って価値を感じた直後」が最も投稿率が高いです。ECなら商品受け取り確認後2〜3日、飲食なら来店翌日、サービスなら利用完了直後が一般的な最適タイミングです。「まだ使っていない段階」や「使用から時間が経った後」は投稿率が下がります。UIとしては投稿導線（メール・プッシュ通知）のデザインも含めて考える必要があります。
Q5. 写真付きレビューを増やすにはどうすればいいですか？
「写真を追加するメリット」をUIで明示することが効果的です。「写真付きレビューは上位に表示」「写真付きで追加ポイント獲得」のような情報を投稿画面に表示するだけで、写真添付率が上がります。また、写真アップロードのUIを「ドラッグ&ドロップ」や「ギャラリーから選択」など操作しやすくすることも、添付率向上に貢献します。
Q6. 匿名レビューと実名レビュー、どちらを許可すべきですか？
サービスの性質によります。批判的な意見が集まりやすい（医療・飲食・宿泊など）サービスでは匿名を許可する方が投稿率が上がります。コミュニティ形成が目的（趣味・専門職など）のサービスでは実名・ニックネームの方が信頼性が高まります。どちらにするかはポリシーの問題ですが、UIとして「どの名前で投稿するか選択できる」ことをユーザーに明示することが重要です。
Q7. 不適切なレビューへの対処をUIに含める必要はありますか？
必要です。ユーザー生成コンテンツを扱う全てのサービスで、「通報ボタン」は最低限必要です。表示位置はレビューの右上や「…」メニューの中が一般的です。「何が不適切か」の基準（スパム・誹謗中傷・広告など）をユーザーが通報時に選べると、運営側のモデレーション効率も上がります。
Q8. Google Stitch でレビューUIを設計するときの効果的なプロンプトは？
「レビューを書く人の心理的ハードル」を下げることを明示したプロンプトが効果的です。例：「ECアプリの商品レビュー投稿画面。星評価（必須）＋テキスト（任意・質問形式で何を書けばいいかガイド）＋写真添付。書くハードルを下げる工夫を含めて。投稿後には感謝と次回への動機付けメッセージを表示」のように、設計の意図を含めると生成精度が上がります。
まとめ
「星とテキストボックスを置けばいい」と思っていたレビューUI設計が、「ユーザーに書く行動を起こさせるための設計」だと気づいてから、全ての判断が変わった。
Google Stitch でレビューUIを設計してみてわかったのは、このUIが「フォームを作ること」ではなく「行動を設計すること」だということだ。何を書けばいいかわからせない、どれくらい書けばいいか見えない、書く価値があるかわからない——これらの心理的ハードルをUIが取り除くことで、初めてレビューが集まる。
- 「何を書けばいいか」の迷いを取り除く——質問形式・タグ選択が有効
- 星評価は必須・テキストは任意＋インセンティブが現実的なバランス
- レビュー表示側も設計する——参考になった順・評価分布の提示が信頼感を高める
- 投稿完了後の「ありがとう画面」が次回投稿への動機付けになる
- 不適切コンテンツへの通報ボタンは必須の設計要素
ユーザーに「評価を書かせる」UIは、ユーザーへの敬意を持った設計が必要だ。「書かせる」ではなく「書きたくなる」設計——その違いが、レビューの量と質を決める。
