ホーム自己紹介ブログ
NO.180
DATE2025. 11. 28

具体的なデータで議論しよう

Web のフロントエンド開発や、Figma でデザインを議論するときに、
よく「ここにテキストが入ります」といったモックデータを配置して進めることがあります。

しかし、 想像力を高めて気づきを得る という意味では、
そこに「実際に入りそうな具体的なデータ」を置いて会話した方が、
議論の精度もスピードも上がりやすいと感じています。

なぜ具体的なデータを使うべきか

たとえば、管理画面のブログ記事一覧ページを設計するとします。

  • ブログタイトル
  • PV 数
  • 公開日
  • 著者情報

といった項目が並ぶ典型的な一覧画面です。
このとき、タイトルに

  • 「ここはタイトルが入ります」
  • 「サンプルタイトルです」

PV 数に

  • 「9999」

のような架空データを入れるよりも、

  • タイトル: 「CSS の技術 Tips 集」
  • PV 数: 652

といった “実際にありそうな数値や文言” を入れた方が、
画面のリアリティが一気に高まり、議論が自然と深まりやすいと感じています。

具体的なデータを使うことで得られるメリットは次のとおりです。

  • 議論のベースラインが揃う
    • 参加者全員のイメージが自然と一致しやすい。
  • 会話が発散しにくい
    • 特定データに縛られすぎないことは前提としても、方向性が定まりやすい。
  • ユーザー体験のイメージが明確になる
    • 不要な要素を削ぎ落としやすく、文言や動線の妥当性にも気づきやすい。

もちろんデザインでは最大・最小サイズなどのケースを考慮する必要がありますが、
UX や仕様の議論では「具体的なデータ」の方が向いているかと思います。

時系列も一緒に考えると、より深い設計になる

さらに、データそのものだけでなく、時系列(過去・現在・未来)を想定して会話すると、
設計の精度は格段に上がります。

  • 「初期はデータが少ないけれど、将来的に増える可能性は?」
    • → 並び順や表示件数、ページングの必要性が見える。
  • 「セミナーなどを申し込んだ後、画面はどう変化する?」
    • → 状態遷移やステータス表示の設計が明確になる。
  • 「処理中にキャンセルをしたい場合は?」
    • → 戻り動作やエラーハンドリングの検討につながる。

また、どのロールのユーザーがどのような状況で使うのかも合わせて考えると、
仕様の抜け漏れが減り、議論の解像度も高まります。

可能なら、自分がその画面のユーザーであるかのように想像して話すと、
さらに現実的な議論がしやすくなると思います。

終わりに

私はこの考え方で、プランニングやデザインの議論を進めていました。
ぜひ、皆さんも試してみてください。

仕事

-

読者になる

|

シェアする

|

silverbirders

silverbirder

Webソフトウェアエンジニア
個人ブログキュレーション こぶりー 運営

ブログを応援する

この記事がよかったら、お布施という形で応援してもらえるとうれしいです。

おふせぼたん

※ ログイン不要で投稿できます。

※ 同じブラウザから投稿を削除できます。

0

読み込み中...

次の記事へ前の記事へ

関連する記事

タグ「仕事」の記事

貴重なアイデア

今日はお仕事(Web関連)のことでも書こうと思います。 今の時代、アイデアがあれば 形にするまでの道のりは比較的楽になりました。 昔だと、形にするためには技術的な調査や設計方法について下調べをした上で、せっせと作っていました。 それがいまだ

2026年10月30日

仕事
Design Doc, ADR, RFC

趣味レベルの開発であっても、最近では DesignDocやADRを書き残すようにしています。 ナイモノは読めないから Design Doc のような機能に関する仕様や、 ADR のような全体のアーキテクチャに関する仕様など、 意思決定は山ほ

2026年10月09日

仕事
個人開発
Codex, Claude のピン留めがお気に入り

Codex や Claude のデスクトップアプリにあるピン留め機能が気に入っています。 ピン留めというメタファ 髪の毛を束にしてまとめるためのピン留めや、 コルクボードに紙を止めるためのピン留めなど、 何かを固定するというメタファがピン留

2026年10月05日

仕事
AI
← ブログ一覧へ