UIデザイン みんなで考え、カイゼンする。

はじめに・CH1改善の起点は、誰のどんな価値か

CH1は、見た目の変更や新機能から入る改善が問題だ、と始まる。例は食事記録のサービス。毎食の撮影と入力を強いると続かないが、一操作で記録できれば続く。サービスはデザイン・技術・ビジネスの3領域でできていて、ECの操作感はデザインで直せても、推薦やセキュリティは技術、物流や販路は事業の課題。まず、それがデザインで解ける課題かを見極める。ここ、地味に大事です。

施策先行じゃなく、仮説先行。目的を数値と期限で具体化し、調査、仮説、検証を重ねる。課題の優先度は、緊急度×重要度で並べると急ぎが重要に見える錯覚が起きるので、有効性×実現可能性で並べ、両方高いものから着手して、両方低いものは捨てる。改善プロセスは、PDCAは計画起点で現場の反応が遅れて入るため、新規開発や成長（What）にはOODA（観察→判断→決定→実行）、工程の決まった業務改善（How）にはPDCA、という使い分けです。

体制の話も具体的。ログ、アンケート、施策リストの定番は、続けるうちに打ち手が枯れる。定性データを足して、小チームを複数並行で速く回す。失敗は一定確率で起きるので、回転数が効く。営業の文面やエンジニアの性能調整も体験を左右するから、全員がデザインしている、と言い切る。

思考の見える化にはダブルダイヤモンド（英デザイン協議会・2005年）で、広げて絞るを2回。開発後半の変更は高くつくので、XDやFigma、Prott、InVisionなどで早めに完成像を共有し、完成品扱いせず、確認してほしい箇所を明示する。デザインも「運用」する、という項では、担当交代や技術の変化で見た目もコードも寄せ集めになるから、経緯と理由を記録したデザインシステムで揃える。ツールはルールとセットで、導入目的を決める、同じ用途で併用しない、使う場面を決める。

両方低いものは捨てる。この「捨てる」をはっきり書いているところが、俺はいちばん好きです。

CH2UIデザイナーの仕事は、解像度を上げること

「デザインする」とは、混沌から課題を定め、解決策を目に見える形で考えて示す、解像度を上げる行為だ、と定義される。UIは人とシステムの接点で、裏のデータを扱いやすい姿に整えるもの。情報設計と視覚表現で、美しさと機能を両立させる。何を・なぜ作るかを定義する対話力と、どう見せるかを形にする力の、両方が要る。解像度を上げる、という言い方は、俺にはいちばんしっくりくる定義です。

仕事の流れは、要件定義、画面設計、ビジュアル、レビュー。レビューでは、PMはゴール、デザイナーは規約の順守、エンジニアは再現度を見る、と役割が分かれる。肩書の境界は曖昧なので、全部背負わず、得意分野で補い合う。

情報を整理してUI要素に翻訳する手順がいい。運用で情報が膨らんで混沌化するのは、散らかった部屋を、探し物が見つかる収納に直す感覚。利用場面を6コマで描く6up Sketchesやジャーニーマップで、時系列の漏れや感情に気づく。サイトマップとUIフロー（画面ごとに見るもの・することを分ける。分岐の多いログインや決済に有効）で全体を捉えて、ナビ、部品、文言、状態（空、エラー、読み込み中）に落とす。

プロトタイプの戒めは、かなり刺さる。中身が決まる前に見た目を作り込むと、色や余白の指摘で会議が終わる。いや、ほんまにそれ。笑　欲しい反応に合わせて忠実度を選び、粗いほど要件と情報設計向き、精細なほど見た目と操作の確認向き。初期は紙やホワイトボードで描いては壊す。説明するときは、ゴール、背景、仮説、手順、影響範囲を添える。

スタイルガイドは、画面と人が増えると同じ役割のボタンでも見た目や文言が揺れて、正解が分からなくなる問題への道具。色、書体、ボタン、フォームを明文化すれば、共通の呼び名で話せて、新メンバーが早く馴染み、利用者の学習コストも下がる。ただし、ガイドラインも使われなければ負債になる、とも書いてあります。

CH3定量は結果、定性は理由。両方を往復する

定量データは「使われたか」という結果で、定性は理由と価値観が分かる。定量は過去と現在しか示さず、次の手は教えてくれない。だからインタビューや行動観察で意味を補って、両方を往復する。データにもとづく改善の失敗は、見ていない、誤読、分析の目的化。調査→課題（事実）→仮説→施策の順で、仮説ごとに複数案を出し、定性的に確かめる。データは課題を示すけど、解決策は示さない。そこがデザイナーの出番だ、という整理です。

自社の事業理解で問題になるのは、作り手が強みだと思っている点が利用者に響いていない「認識のずれ」。SWOTで強みを棚卸しし、他社比較や利用者の評価から、見落としていた強みを探す。確認は「機能として実装済みか」「実際に使われているか」の2段。アイデアとロジックは対で育てる。ロジックは「なぜやるか、何が変わるか」に答える行動の根拠で、初見で分かる簡潔さと、数字や図が要る。

プロトタイピングの効用は、意思疎通、限界の早期発見、誰でも触って評価できること、体験の共有。用途は、探索、理解、利用者との検証、社内外への売り込みの4場面。デザイナーが実装難度を見ずに描いて、エンジニアが差し戻して遅れる「工程の分断」も、全員が初期から試作物を囲めば解消する。段階で粒度を変え、社内なら議論できれば十分。投資家や経営層には見栄えが効くけど、ウケても事業の視点は忘れるな、と。

チームの意識統一では、上意下達の「グループ」と、決定過程を共有する「チーム」を対比し、進捗と目標（KGI/KPI）の共有を要にする。着手前に、やる価値は？誰にどんな価値？全員理解している？と問う。コラムでは、会話（親しくなる）、議論（結論を出す）、対話（相互理解と新しい発想）を区別して、Howの前にWhyを対話せよ、と言う。

Howの前にWhy。この一行を守るだけで、会議の半分は短くなると思う。

CH4ユーザーインタビューの準備と質問の作法

リサーチは、作り手の思い込みと実態の差を埋める学習の場。企画期は探索型（行動観察、インタビュー）、設計〜実装期は検証型（ユーザーテスト）、データ分析は前後、専門家レビューは中盤、という対応表がある。集めた生データを、操作対象、利用文脈、体験、開発仕様の観点で構造化してUIへ落とすのが、UIデザイナーの役割だ。

インタビューの形式は、半構造化、1対1の深掘り（1〜2時間）、5〜6人の座談会で、時間と募集コストが違う。流れは計画、準備（募集、仮説と質問の設計、備品）、実施、考察、共有。募集経路は自社サイトやSNS、営業やCS経由、外部サービス。当日は時間配分付きの台本を作ってリハーサルし、質問役と記録役の2名が基本で、見学者は別室へ。同意書や録画の許可は冒頭で取る。

質問の作法がかなり実践的です。誘導や二択を避け、オウム返しで信頼をつくり、「なぜ」と問い詰めず、「いつ・どこで・誰が」などで具体的な過去の行動を引き出す。記録は「発言」と「記録者の解釈」を列や記号で分ける。分析は、書き起こし、要点抽出、グループ化、図解、考察の5段で、報告書は凝りすぎず、記憶が新しいうちに出す。

「なぜ」と問い詰めない。これはインタビューに限らず、人の話を聞く場面全部に効くと思う。

CH4ユーザーテストは5人、ほかに使える4つの手法

ユーザーテストは、使いやすさを効果・効率・満足度で測る。目的が「操作させて確かめる」でなければ、インタビューのほうが向く。タスクは優先度の高いものに絞り、利用者目線で場面設定を付ける。当日は、事前の聞き取り、課題の実施、事後の聞き取りの順。「試しているのは画面で、あなたの能力ではない」と伝え、考えを口に出してもらい、こちらは口を挟まず観察に徹する。

ニールセンの知見として、5人で問題の大半（約85%）が見つかり、1回15人より5人×3回のほうがいい、と紹介される。課題は、質（効果＞効率＞満足度）×発生頻度で優先順位を付ける。

そのほかの手法は4つ。街頭で声をかけるゲリラインタビュー（安い、潜在層に届く、アンケートの体裁で2人1組）。長時間付き添うシャドーイング（仮説を持ち込みすぎず、まず写真や動画で記録し、分析はあと）。ユーザー同士の事例発表や懇親会で本音を拾うミートアップ（利用者との距離が遠いBtoBやSaaSに有効）。業界の有識者や他のデザイナーに見てもらうエキスパートレビュー（安くて速い）。

コラムは、SNSの声や競合事例など手近なところから始め、テストも社内の近くの人で小さく試せばいい、と背中を押す。完璧な調査を待って何もしないより、5人に触ってもらうほうが、ずっと前に進む。

CH5デザインシステムは、育て続ける判断基準

処方する問題は、職種ごとに判断基準がばらついて、デザイナーの意図が他職種に伝わらないこと。「良いデザイン」の解釈が人によって違い、営業やマーケも含めて同じものを指せない。原則、スタイルガイド、部品集、ブランド資産などを「唯一の拠り所」としてまとめ、全員の共通言語にする。必須構成はなく、部分導入でもいい。

形のある部品（ボタンやフォーム）と、色・書体・動きなどブランドらしさの約束の2種に分け、デザイン原則で結ぶ。肝は部品より、共有して育てる運用です。損得も正直に書いてあって、一貫性、効率、話の通じやすさを得る代わりに、部署横断の対話、更新し続ける運用費、学習費がかかる。一人では作れない。

DMM動画の事例が詳しい。スピード優先の継ぎ足しで、カートボタンの高さ、文言、色が時期ごとにばらばら。100画面超なので作り直しは無理。根本は、企画→デザイン→フロント→システム→テストの一方通行の分業で、画面単位のPhotoshopと別管理のHTML/CSSの間で知識が途切れていたことだった。

手順は、職種横断のチームで、①UIの棚卸し（全画面のスクショから部品を並べた一覧）、②分類を決めて当てはめ、複数人で確認し、コードと照合、③文字サイズや色を集めて似たものを統合しルール化、④部品集をコードと同期、⑤Storybookで部品を資産化し、小さい範囲で調査→実装→公開を繰り返して置き換える。

構築のきっかけづくりは、体験は劇的には変わらないので、時間や人数の数字で価値を示す。提案準備が2営業日から1日以内に、属人化が解けて3人がかりの改修が1人でできるように。成功の型を言語化する「パターン・ランゲージ」も、組織づくりに使う。

作って終わりにしない。作ったあとに育てる人がいるかどうか。デザインシステムの話は、結局そこに尽きると思う。

CH6UXを並走させ、試作と小さなテストを回す

スマートスピーカーから家電を動かす連携のように、接点が多様化して、一人では体験を設計しきれない。従来のUX作業は専門家の密室になり、アジャイルの短い周期に重い調査が合わなかった。そこで「パラレルトラック方式」。UX/UI設計を開発の少し前に並走させ、テストの気づきを次の設計に戻す。

UXは、モノと人が関わる状況全体。時間で4つ（使う前の予想、最中、使用後の振り返り、利用期間全体）に分けると、使う前の問題も見えてくる。全体像は「UXハニカム」と、それを3段にした「UXピラミッド」（土台が使える、中段が安心、頂点が満足）です。

戦略的プロトタイピングは、利用の流れ全体を物語で俯瞰する。簡易ペルソナ（通常は数週間のところ1時間程度、手書き可、更新前提）、文章のシナリオ、現状のジャーニーマップ、ストーリーボードの順。体験的プロトタイピングは、スケッチ、紙、見た目見本、コードから、目的に合わせて忠実度を選ぶ。紙は誰でも作れて捨てやすく、機能の本質に意見が集まる。要望を全部入れると、何にも向かない化け物になる。試作は検証の道具で、完成品じゃない。

ユーザーテストの設計は、目的をチームで先に合わせ、設備なしの「必要十分」で小さく何度も回す。被験者は同僚や知人でもよく、対象に関わっていない人ほど率直。失敗例は3つで、完成後にテストする、狙いと違う属性の人で試す、被験者に「どこが悪い？」と聞く。コラムは、ツールは増えて学習費も重い、紙とペンで足りる場面は多い、と締める。

要望を全部入れたら、化け物になる。UIに限らず、企画会議のたびに思い出したい一文です。