UIXHERO

UI検品の観点「Action(行動)」とは — 押す前に結果が分かるかを確かめる3つの手順

Actionは、UI検品で使う6つの観点のうちの3つめです。主な行動が1つに定まっているか、入力が最小限で済むか、押した結果が予測できるかを見ます。AIが作った1画面を材料に、Actionが何を見る観点なのかと、自分の画面で確かめる3つの手順をまとめます。

2026年8月12日
更新: 2026年8月27日
8
by Dengen Yosho(DGYS)

この記事の要点

  • Action(行動)は、検品で使う6つの観点のうちの3つめです。主な行動が1つに定まっているか、入力が最小限で済むか、押した結果が押す前に予測できるかを見ます
  • AIが作った1画面では、12体のレビュアー全員が「押した後に何が起きるか書かれていない」を指摘しました
  • 押せるかどうかが分からない印も、この観点で見ます。実例ではハートのアイコンが、押すボタンなのか、すでに付いている状態の表示なのか判別できませんでした

Action(行動)とは何を見る観点か

UI検品では、1つの画面を6つの観点に分けて見ます。(明瞭さ)、Flow(導線)、Action(行動)、Trust(信頼)、Friction(摩擦)、Feasibility(実装性)の6つです。

このうち Action が見るのは、押す・入力する・送るといった行動が、迷わず実行できるかです。確かめるのは3つ。

  1. 主な行動が1つに定まり、迷わず実行できる形になっているか
  2. 入力・登録が、必要最小限の手数で終わるか
  3. 行動の結果(成功、失敗、次に何が起きるか)が、押す前に予測できるか

前の2つとの関係はこうです。Clarity(明瞭さ)は1枚の画面の中を、Flow(導線)は画面と画面のつながりを見ました。Action はその中間で、画面の中にある操作そのものを見ます。

何の画面か分かり、どこへ進むかも分かったうえで、目の前のボタンを押せるかどうか。そこが Action の範囲です。

自分の画面のActionは、自分では判定できない

またこの壁が出てきます。今回の理由は、いちばん単純です。

作った人は、押した後に何が起きるかを知っています。 自分で作ったのだから当然です。ボタンを押せば台帳ができることも、この丸いアイコンが押せることも、この入力欄が任意であることも、全部わかっています。

しかしそれは画面に書かれていません。 頭の中にあるだけです。

初めて開いた人は、押す前に結果を知る方法がありません。だから押すのをためらうか、押してから驚くかのどちらかになります。業務画面では前者が起きやすく、「これ押していいんですか」という確認が発生します。

Action でも、覚えていることを使わずに済む確かめ方に置き換えます。

実例:AIが作った施工写真台帳のAction

材料は前回までと同じ、 群青(GUNJO) で作られた画面です。群青を一度も見たことのないAIに、公開ドキュメントとnpmで配っている中身だけを渡して組ませた、建設業の施工写真台帳です。

6観点で検品した結果のうち、Action は 3/5 でした。

観点スコア
Clarity(明瞭さ)2/5
Flow(導線)3/5
Action(行動)3/5
Trust(信頼)3/5
(摩擦)3/5
Feasibility(実装性)静止画では非採点

指摘はこうでした。

「台帳を作成」を押した後に何が起きるか書かれていない(12/12)。必須/任意・入力形式の表示も無い(11/12)

押した後に、何が起きるのか

この画面の主な仕事は「絞り込む、選ぶ、台帳を作る」です。その最後の行動が、右上にあります。

施工写真台帳のヘッダ右側。白い「取り込み」ボタンと、黒い「台帳を作成」ボタンが並んでいるタップして拡大表示 ヘッダの右側にある2つのボタン。黒いほうが主な行動です

ボタンとしては、よくできています。黒く塗られているのは「台帳を作成」だけなので、2つのうちどちらが主役かは見て分かります。ここは通っています。

問題は、押した先です。

台帳が作られたあと、何が起きるのでしょうか。別の画面に移るのか。この画面のまま完了の表示が出るのか。作られた台帳はどこで見られるのか。選んでいる写真が0枚でも押せてしまうのか。

どれも画面には書かれていません。12体のレビュアー(AIと人間がまざっています)が、互いの指摘を見ない状態で検分し、全員がここを指しました。

押せるのか、押せないのかが分からない

もう1つ、審査担当が足した指摘があります。写真のサムネイルを見てください。

施工写真台帳のサムネイル2枚。左は「★4.0」の評価バッジと右上の白い丸、右は青いハートのアイコンと右上の白い丸が付いているタップして拡大表示 サムネイルに付いている印。★の評価、ハート、右上の白い丸

3つ写っています。★4.0 の評価バッジハートのアイコン、そして右上の白い丸です。

まず ★ から。工事写真に点数を付ける業務はありません。 これは写真共有サービスの語彙で、施工写真台帳の語彙ではありません。

次にハート。青く塗られています。これは、押すボタンでしょうか。それとも、すでに付いている状態の表示でしょうか。 見た目からは判別できません。押せるものだと思って押した人は、何かを取り消してしまうかもしれません。

右上の白い丸も同じです。何も描かれていないので、何をするものか分かりません。

押せるかどうかが見た目で分かる状態をアフォーダンス、その手がかりをシグニファイアと呼びます。ここで足りていないのは後者です。「重要」「要確認」のような業務の言葉にすれば、押せるかどうかも、何のためのものかも、同時に伝わります。

自分の画面で確かめる3つの手順

最初に挙げた Action の3つを、自分の画面で確かめます。手順はその3つに1つずつ対応しています。

手順確かめること
手順1主な行動が、1つに定まっているか
手順2入力が、必要最小限で終わるか
手順3押した結果が、押す前に予測できるか

道具は要りません。いま作っている画面を開いて、順に試してください。

手順1 いちばん強いボタンを、1つだけ指差す

画面の中でいちばん強く見えるボタンを1つ指差します。 塗りつぶされている、大きい、色が付いている、といった見え方のものです。

  • 1つに絞れたなら通過です
  • 2つ以上を同じ強さで指差したなら、そこが直し先です

同じ強さのボタンが並ぶと、見る人は「どちらが本命か」を自分で判断することになります。施工写真台帳では、黒いのが「台帳を作成」だけだったので、ここは通っていました。

絞り方は主要導線を先に決めるにまとめてあります。要点はFlowの記事と同じで、押してほしい1つを決めて、それ以外の強さを落とすことです。

手順2 入力欄を数えて、1つずつ「今これが要るか」と聞く

入力欄がある画面なら、ここを見ます。

  1. 入力欄の数を数える
  2. 1つずつ、「この操作を終えるのに、いま本当に要るか」と聞く
  3. 残った欄に、必須か任意かが書かれているかを見る

要らない欄は、あとから聞けます。その場で全部埋めさせる必要があるのは、いま処理するために欠かせないものだけです。

必須と任意の表示は、欄が2つ以上あるなら要ります。書かれていないと、見る人は全部埋めようとするか、送信して怒られるまで分かりません。入力形式(半角、日付の書き方、桁数)も同じです(入力の負担を減らす)。

施工写真台帳では、11体がこの点を指摘しました。

手順3 ボタンのラベルを読んで、押した後を口に出す

最後に、いちばん強いボタンのラベルを読んで、押した後に何が起きるかを口に出します。

言えなければ、見る人にも言えません。

  • 「送信」「OK」「実行」 は、何が起きるかを説明していません
  • 「台帳を作成」 は動作までは書けていますが、作られた台帳がどこに出るのか、この画面に残るのかまでは分かりません

ラベルだけで足りないときは、ボタンの近くに一文足します。「作成後、台帳の一覧に移ります」で済むことがほとんどです(マイクロコピー期待値を揃える)。

押せない状態のボタンも同じです。 グレーになっているなら、なぜ押せないのかを書きます。「写真を1枚以上選ぶと押せます」と書いてあれば、見る人は次に何をすればいいか分かります。

3つ通っても、Actionの入口です

ここまでは、道具なしで1人でできる範囲です。実際の検品では、Action だけでもう少し細かく見ます。押せる場所が押せると分かる見た目か、入力の途中で失敗したときに何が起きるか、といった設問です。

採点基準は全項目を公開しています。 6観点62項目で、Action の設問もそのまま読めます。

Review Framework(6観点62項目)を見る — design-qa.com/frameworkdesign-qa.com を新しいタブで開く

Actionは、業務の語彙が出るところ

3つの観点を見てきて、Action には他と違う特徴があります。業種の言葉が、いちばん露骨に出ます。

施工写真台帳に付いていた ★ の評価とハートは、写真共有サービスなら自然な部品です。組み方が下手だったのではなく、別の業種の語彙がそのまま入っていたという話です。

これは、AIに作らせた画面で特に起きます。AIは「写真が並ぶ画面」の一般的な形を知っていて、そこから持ってくるからです。現場監督が撮影記録に点数を付けることはないという業務の知識は、画面の形からは出てきません。

だから Action を見るときは、こう聞くのが効きます。

この操作を、実際の担当者は業務の中でやるだろうか。

やらないなら、その操作は消せます。消すと、残った操作が強くなります。 手順1でやったことと同じ結果になります。

実物を見る

判定の材料と、実際の画面はどちらも公開しています。


この記事は、UIXHEROがAI(Claude)と協働で制作しています。検品の設計・判断・公開前の事実確認は人間が行い、実作業と下書き執筆はAIが担っています。

GunjoUI by UIXHERO

更新のお知らせ

サイトに載せていない実例や、新しい記事のお知らせはこちらで出しています。

読んだ内容を、自分の画面に当てるとき

UIXHEROは、記事を書くほかに、画面の検品・判定、デザインシステムの構築、実装と改善の伴走を受けています。何を頼めばいいか決まっていない段階の相談も、同じ窓口で受けます。

UIXHEROに頼めることを見る

※ 記事の内容についての質問や、書いてほしいテーマの要望も同じ窓口で受けています

関連する用語 (Glossary)

記事をシェア

メールでお知らせを受け取る

最終更新: 2026年8月27日

この記事を書いた人

Dengen Yosho(DGYS)

Dengen Yosho(DGYS)

UI/UXデザイナー兼デザインエンジニア デザイン歴25年以上 情報設計〜UIデザイン〜React/TypeScriptによる実装までを一気通貫で担当 大手企業のDXプロジェクトや決済アプリ領域で、デザインリードとして改善と構築を経験 現在はフリーランスとして、プロダクトのUI/UX改善とデザインシステム構築を支援 長年の実務の中で感じてきたのは、 「良いUI」はセンスではなく、再現可能な判断の積み重ねであるということ UIXHEROは、 心理学や行動科学の知見を、現場で使える設計言語に翻訳するための場所 関心領域は「ユーザーの行動が変わるUI」 人の認知・注意・意思決定の構造を理解し、 “なぜそのUIが機能するのか”を言語化することを目指している

あわせて読みたい

この記事に関連する記事をご紹介します

UI検品の観点「Trust(信頼)」とは — 画面の数字が信じられるかを確かめる3つの手順

Trustは、UI検品で使う6つの観点のうちの4つめです。主張に根拠が添えてあるか、お金や個人情報に安心材料があるか、表記が事実と釣り合って一貫しているかを見ます。AIが作った1画面を材料に、Trustが何を見る観点なのかと、自分の画面で確かめる3つの手順をまとめます。

2026年8月12日
10

AIを「忖度しない検査役」にする方法論 — 手組みの跡は、足りないコンポーネントの地図

AIにUIを作らせるのではなく、AIに「何が作れなかったか」を書かせる方法論です。予備知識ゼロのAIの「無い」が強い証拠になる理由、手組みの跡を次に作るコンポーネントの仕様として読む手順、AIが正直に書ける環境の作り方をまとめます。

2026年8月18日
10

AIが作った画面で、実際に起きた29の失敗

自分たちがAIに作らせた業務画面175枚を検品し、実際に起きた失敗を29個並べました。すべて画面の番号つきです。動く画面が出てくることと、出してよいことは別です。各項目に、手元の画面で確かめるための目安を1行添えています。

2026年8月16日
42

もっと深く知りたいですか?

ここに掲載されていないトピックについても、リクエストがあれば解説記事を追加します。 わかりにくい点や、具体的な事例について知りたいことがあれば教えてください。

リクエストを送る