UI/UXとは？UIはUXの一部——規格の定義と、発注で決める成果物・見積もり・権利【2026年版】

「UIとUXは、結局どう違うのか」——開発の発注を担当することになった方から、こうした質問をよく受けます。見積書には「UI/UXデザイン」という項目が当たり前のように並び、会社によって金額は数倍違う。社内では「UIよりUXが大事だ」といった言い方が飛び交う。それでいて、誰も範囲をはっきり説明してくれない。もやもやしたまま判断を迫られている、という状態ではないでしょうか。

結論から言うと、UIとUXは対になる概念ではありません。UI(ユーザーインターフェース)は画面・操作・表示を指し、UX(ユーザーエクスペリエンス)は利用前・利用中・利用後に生じる知覚と反応の全体を指します。UIはUXを形づくる要素の1つであって、「UIではなくUXを重視する」という言い方は、そもそも成り立ちません。この一点を最初に正しておくと、あとの話がすべてつながります。

そして発注の現場で「UI/UX」と1語で書かれているとき、それが指しているのは「画面を作る一連の作業」です。決まった範囲を持つ言葉ではありません。だから、見積もりを比べる前に、どこからどこまでを頼むのかを発注側が定義する必要があります。ここを相手任せにすると、金額の比較もできず、あとで「含まれていると思っていた」が起きます。

本記事では、UIとUXの違いを規格の定義で確かめたうえで、「UI/UX」が実務で指す範囲、ワイヤーフレーム・デザインカンプ・プロトタイプという成果物の違いと作る順番、ユーザビリティテストの最小構成とアクセシビリティ、見積もりの内訳・実装との分かれ目・著作権とデータの納品、そして外部チームに任せるときの分担の順に解説します。デザインツールの使い方は扱いません。発注する側が判断するための話に絞ります。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。デザインで揉める相談は、不思議なほど同じ2か所に集中するのが実情です。この記事を読み終えるころには、自社の案件でデザインを誰が持ち、何を成果物として受け取り、どこを契約に書いておくべきかが決められるはずです。

UIとUXの違い——UIはUXの一部であって、対義語ではない

UIとUXは、並べて比べるものではありません。UI(User Interface)は利用者が触れる画面・操作・表示のことで、UX(User Experience)は利用者がそのサービスに関わる過程で生じる知覚と反応の全体を指します。両者は同じ階層にある2つの選択肢ではなく、UXという大きな枠の中にUIが含まれるという関係です。まずこの一点を正しておくと、見積もりの読み方も、デザイナーとの会話も、すべて噛み合うようになります。

先に誤解を1つ正す——「UIではなくUXを重視する」という言い方は成り立たない

社内の企画書でよく見かけるのが、「UIよりもUXを重視した設計にする」という一文です。相談の場でもこの言い方をよく耳にします。しかし、UIはUXを形づくる要素の1つなので、「UIではなくUXを」という対比は、「タイヤではなく自動車を重視する」と言っているのと同じ構造になってしまいます。

書き手が言いたかったのは、たいていの場合「見た目の装飾に予算を割く前に、利用者が目的を達成できる流れを設計したい」ということでしょう。それなら「ビジュアルよりも導線の設計を優先する」と書けば、誰にも誤解されません。用語の正確さは細かい話に見えますが、発注の場では致命的です。「UI/UXデザインをお願いします」という一言が、相手には「画面の装飾」と伝わり、こちらは「利用者調査から」と思っている——この食い違いが、後の追加費用の火種になるのが実情です。

規格の定義で確かめる——UXは利用前・利用中・利用後の知覚と反応(JIS Z 8521:2020)

感覚の話にしないために、規格の定義を見ます。JIS Z 8521:2020「人間工学－人とシステムとのインタラクション－ユーザビリティの定義及び概念」は、ユーザエクスペリエンスを次のように定めています(3.2.3)。

システム，製品又はサービスの利用前，利用中及び利用後に生じるユーザの知覚及び反応。

決定的なのは「利用前」と「利用後」が入っている点です。広告を見て期待を持った瞬間、アカウントを作る前に料金表を読んで迷った時間、使い終わったあとに届く請求書、解約しようとして電話がつながらなかった経験——これらはすべてUXの範囲に入ります。画面の外で起きることを含む、という理解がないままUXを語ると、話が「配色とボタンの角丸」に収束してしまいます。

この規格は、ユーザビリティの国際規格である ISO 9241-11:2018 に対応するもの(MOD)です。UXという語を最初に規格へ持ち込んだのは人間中心設計の規格 ISO 9241-210 ですが、その現行版である ISO 9241-210:2019(対応JISは JIS Z 8530:2021、2021年3月22日改正)は有償規格で、本記事では本文を直接確認できませんでした。そのため、定義の根拠としては本文を確認できた JIS Z 8521:2020 の条文を用いています(日本産業標準調査会(JISC)のJIS検索で規格本文を閲覧して確認。確認日: 2026年9月21日)。

UIとUXの対応表——扱うもの、成果物、測り方、担当者

2つの語の違いを、発注側が扱う項目で並べます。

規格の本文をどこまで確認できたか——有償規格の扱いと、本記事が根拠にしたもの

規格を引用する記事には、原文を読まずに孫引きしているものが少なくありません。本記事では確認できた範囲を明示します。ISO 9241-210:2019 については、日本規格協会の書誌情報(2019年7月4日発行、33ページ、対応JISは JIS Z 8530:2021 でMOD)までを確認し、本文は有償のため未確認です。定義の引用は、日本産業標準調査会のJIS検索で本文を閲覧できた JIS Z 8521:2020 に限っています。ここを曖昧にしたまま「ISOの定義によれば」と書くのは、発注の判断材料としては危ういと考えています。次章では、この2語が「UI/UX」と1語にまとめられたとき、実務で何を指しているのかを見ていきます。

「UI/UX」と1語で書かれているとき、実務が指しているもの——UXの範囲とUIの範囲

ここまでで、UIとUXが別の階層にある語だと分かりました。では、なぜ実務では「UI/UX」とスラッシュでつないで1語のように使われるのでしょうか。結論を言えば、これは職種名と発注項目名として定着した省略語で、規格にも辞書にも根拠がありません。指している中身は現場ごとに違います。だからこそ、発注側が範囲を決める必要があります。

「UI/UX」は範囲を持たない省略語——見積書では「画面を作る一連の作業」の意味で使われる

見積書に「UI/UXデザイン 一式」と書かれているとき、多くの会社はそれを「画面を作る一連の作業」の意味で使っています。ただし、その一連に何が入るかは会社によって違います。競合サービスを調べて利用者に話を聞くところから始める会社もあれば、こちらが渡した画面一覧をもとにデザインを作るだけの会社もあります。同じ項目名で金額が数倍違うのは、腕の差ではなく範囲の差であることがほとんどです。

なぜこんな曖昧な語が定着したのかというと、UIとUXで「発注できるかどうか」が非対称だからです。UIは画面という具体物なので、枚数を数えて見積もれます。一方のUXは、利用前から利用後までの知覚と反応なので、そのものを納品できません。納品できないものを発注項目にするために、発注できるUIにくっつけて「UI/UX」という1語が生まれた——現場を見ている限り、そう理解するのが一番しっくりきます。

UXが扱う範囲——広告・登録・利用・サポート・請求書・解約まで

UXの範囲を具体的に並べると、発注の会話が変わります。利用者の時間軸に沿って書き出すと、だいたい次のようになります。

この表を見ると、UXの大半が「画面の外」にあることが分かります。請求書の様式や、解約フォームの場所や、問い合わせの返信にかかる日数は、デザイン会社に発注する対象ではありません。それでも利用者の知覚と反応には確実に含まれます。つまり、UXの改善は外注しきれない仕事であって、発注側が持ち続ける部分が必ず残るということです。

UIが扱う範囲——画面、操作、表示。そして「状態」

一方、UIが扱うのは画面・操作・表示です。ここで発注者が見落としやすいのが「状態」です。1つの画面には、通常の表示のほかに、データが1件もない状態、読み込み中の状態、入力を間違えた状態、権限がなくて見られない状態、通信が切れた状態があります。同じ「一覧画面」でも、状態を数えると5枚になることがあります。

見積もりの画面数が会社によって違うのは、この状態を数に入れているかどうかが大きな理由です。状態が描かれていないまま実装に入ると、実装側が「このときはどう表示しますか」と1つずつ確認することになり、そのたびに判断待ちが発生します。私が見てきた範囲では、デザインで揉める相談の半分はここから始まっています。なお、混同されやすい語にCX(顧客体験)がありますが、こちらは購買や来店を含む企業との関係全体を指し、UXより広い概念として使われます。本記事では扱いません。

ワイヤーフレーム・モックアップ・デザインカンプ・プロトタイプ——違いと作る順番

デザインの打ち合わせで飛び交う成果物の名前は、慣れないうちは区別がつきません。しかし、この4つは「何を決めるためのものか」がはっきり違います。名前を覚えるためではなく、レビューのときに何を見て何を見ないかを決めるために、違いを押さえてください。順番を飛ばすと、後ろの工程で必ず手戻りが起きます。

4つの成果物の比較表——何を決めるもので、何を決めないものか

モックアップとデザインカンプは、日本の制作現場ではほぼ同じ意味で使われます。厳密にはモックアップが「実物大の模型」全般を指す語で、デザインカンプは印刷業界から来た「完成見本」に近い語です。発注の場面では、どちらの語を使っているかより、「静止画なのか、押して動くのか」「実データで確認できるのか」を相手に確かめるほうが実用的です。

作る順番と、各段階で発注者がレビューで見るもの

順番は、情報設計 → ワイヤーフレーム → デザインカンプ → プロトタイプ、です。この順番には理由があります。色や写真が入った完成形を見せられると、人は配色や写真の好みに意見を言いたくなり、情報の順番という本質の議論が飛んでしまうからです。白黒のワイヤーフレームの段階で導線を固めておくと、カンプのレビューは「実データで崩れないか」に集中できます。

発注者としてレビューに時間をかけるべきなのは、ワイヤーフレームの段階です。ここでの修正はほぼ無料ですが、カンプ完成後の構成変更は作り直しになり、プロトタイプ完成後なら実装のやり直しまで波及します。当社が関わった求人プラットフォーム(ATS)やヘッドレスCMSを使ったWebサイトでも、ワイヤーフレームの段階で画面一覧と権限の入口を確定させた案件ほど、後半の変更が少なく済みました。

レビューのときに発注者が必ず聞くべき質問は3つです。「この画面に実際の最長のデータを入れたらどうなりますか」「データが0件のときは何が表示されますか」「エラーのときの文言は誰が決めますか」。この3つを聞くだけで、状態の抜けは相当減ります。

要件定義・基本設計との関係——画面設計はどちらの工程の成果物か

ここで混乱しやすいのが、画面設計が開発工程のどこに属するのかという点です。実務では、画面一覧や画面遷移図、画面項目定義といった文書が基本設計(外部設計)の成果物として扱われることが多く、デザイン会社が作るワイヤーフレームやカンプと内容が重なります。同じものを2回作る、あるいはどちらも作られないまま実装に入る、という事故はここで起きます。

どの工程で誰が何を作るかは、発注前に一度すり合わせておいてください。工程そのものの定義は「要件定義とは」の記事、基本設計書に含まれる文書の一覧は「基本設計とは」の記事で扱っています。本記事では踏み込みません。1つだけ持論を書いておくと、デザインカンプに状態が描かれていないまま実装に渡すのは失敗のもとです。名前の違いより、この一点のほうがずっと効きます。

使いやすさをどう確かめるか——ユーザビリティテストの最小構成と、アクセシビリティ

「このデザインで使いやすいのか」という問いに、非デザイナーの発注担当者が自信を持って答えるのは難しいものです。しかし、使いやすさには規格の定義があり、確かめる手順もあります。専門家に頼まなければ何もできない、という話ではありません。ここでは、発注者が自分で回せる最小構成と、法令が絡むアクセシビリティの位置づけを整理します。

ユーザビリティの定義——効果・効率・満足の3つで測る(JIS Z 8521:2020)

ユーザビリティは、JIS Z 8521:2020(対応国際規格 ISO 9241-11:2018、MOD)3.1.1で次のように定義されています。

特定のユーザが特定の利用状況において，システム，製品又はサービスを利用する際に，効果，効率及び満足を伴って特定の目標を達成する度合い。

同じ規格は、効果を「ユーザが特定の目標を達成する際の正確性及び完全性」(3.1.12)、効率を「達成された結果に関連して費やした資源」(3.1.13)、満足を「システム，製品又はサービスの利用に起因するユーザのニーズ及び期待が満たされている程度に関するユーザの身体的，認知的及び感情的な受け止め方」(3.1.14)と定めています。さらに「利用状況」は「ユーザ，目標及びタスク，資源並びに環境の組合せ」(3.1.15)です(日本産業標準調査会のJIS検索で規格本文を閲覧して確認。確認日: 2026年9月21日)。

ここから発注者が持ち帰るべきことは1つです。使いやすさは「誰が」「どんな状況で」「何をするとき」を決めないと測れない、ということ。「使いやすくしてください」という発注は、測定できない要求なので、そのまま検収条件にはなりません。

ユーザビリティテストの最小構成——5人・1人40分・3タスク

測る方法は、思っているより簡単です。最小構成は次のとおりです。

人数を5人とするのは、ヤコブ・ニールセン氏が2000年3月18日にNielsen Norman Groupで公開した記事の知見に基づきます。同記事は、5人の参加者による最初の調査でユーザビリティ上の問題の85%が見つかるとし、「5人目のあとは、同じ発見を繰り返し観察するだけで時間を無駄にしている」と述べています。大規模な調査を1回行うより、5人の調査を作り直しながら何度も回すほうが効率がよい、という主張です。

この規模なら、外注しなくても社内で回せます。プロトタイプができた時点で1回、リリース前に1回。それだけでも、実装後に発覚する致命的な作り直しはかなり防げます。

ニールセンの10原則は「テストの前に潰す」ためのもの

UIの解説記事によく出てくる「ユーザビリティの10原則(10ヒューリスティック)」は、同じくヤコブ・ニールセン氏が1990年にロルフ・モーリック氏と考案し、1994年に改訂したものです(Nielsen Norman Group、記事の最終レビューは2024年1月30日)。内容は「システム状態の可視性」「システムと実世界の一致」「ユーザーによる制御と自由」「一貫性と標準化」「エラーの防止」「記憶より認識」「柔軟性と効率性」「美的で最小限のデザイン」「エラーからの回復支援」「ヘルプとドキュメント」の10項目です。

これはテストの代わりではなく、テストの前に明らかな問題を潰すためのチェックリストとして使うのが実務的です。5人に見てもらう貴重な機会を、「保存したのかどうか分からない」といった初歩の問題の発見に使うのはもったいない、という順序の話です。

アクセシビリティとの関係——WCAG 2.2、JIS X 8341-3:2016、合理的配慮の義務化

アクセシビリティは、ユーザビリティの一部というより「利用できる人の範囲を広げる」という別軸の観点です。基準はW3Cが定める WCAG(Web Content Accessibility Guidelines)で、WCAG 2.2 は2023年10月5日にW3C勧告となり、2024年12月12日に更新されています。知覚可能(Perceivable)、操作可能(Operable)、理解可能(Understandable)、堅牢(Robust)の4原則で構成され、適合レベルはA、AA、AAAの3段階です。

日本ではJIS X 8341-3:2016が対応する規格で、ウェブアクセシビリティ基盤委員会(WAIC)は、WCAG 2.0、ISO/IEC 40500:2012、JIS X 8341-3:2016の3つが技術的に同じ内容になったと説明しています。また、2024年4月1日に改正障害者差別解消法が施行され、事業者にも合理的配慮の提供が義務づけられました(内閣府)。ウェブサイトそのものへの適合義務を直接定めたものではありませんが、発注仕様に「WCAG 2.1 レベルAA相当」などと書く企業が増えている背景はここにあります。行政機関や事業者向けの実務解説としては、デジタル庁の「ウェブアクセシビリティ導入ガイドブック」があり、2025年10月16日にデジタル社会推進標準ガイドライン群へInformative文書として位置づけられました。では、こうした観点を含めて発注すると、見積もりはどう変わるのでしょうか。

発注者の実務——見積もりの「UI/UXデザイン」に何が含まれるか、実装との分かれ目、権利とデータ

ここからが、発注担当者にとって本題です。デザインの発注で起きる問題は、好みの相違ではなく、範囲・分界点・権利の3つが決まっていないことから生まれます。逆に言えば、この3つを先に決めておけば、相見積もりは比較できるようになり、検収でも揉めません。順に見ていきます。

見積もりの内訳——5つのブロックに分けて、含む/含まないを自分で決める

「UI/UXデザイン 一式」と書かれた見積もりは、そのままでは比べられません。次の5ブロックに分け、各社に「どれが含まれますか」と同じ表で聞いてください。

金額差の正体はほぼここにあります。調査を含む会社と、こちらが渡した画面一覧に沿ってカンプだけ作る会社では、同じ項目名でも作業量が何倍も違います。どちらが良いという話ではなく、自社の案件にどのブロックが必要かを先に決めることが先決です。

金額の妥当性を測るには、工数に割り戻すのが手っ取り早い方法です。当社は単価を公開しており、実務3年目安で月額1,500USD(1USD=150円換算目安で約22.5万円)、5年で2,000USD、10年・ブリッジSEで3,000USDです。国内のデザイン会社の単価はこれより高いのが通例ですが、「この金額は何人が何か月分か」と聞けば、根拠のない一式見積もりかどうかはすぐ分かります。

デザインカンプとHTML実装の分かれ目——抜けるのは「状態」と「レスポンシブの規則」

デザインが終わったら、あとは実装するだけ——そう思われがちですが、カンプと実装の間には必ず隙間があります。実務で抜けるのは、次の5つです。

誰がどこまで担うのかという線引きも、契約前に決めてください。デザイン会社がHTML/CSSまで納品する場合と、カンプまでを納品して実装は開発会社が行う場合があり、後者では「カンプ通りに実装されているか」の判定責任が宙に浮きがちです。判定する人と、判定の基準(ピクセル単位で合わせるのか、規則が守られていればよいのか)を決めておくと揉めません。画面側と処理側の境目そのものについては「フロントエンドとバックエンドの違い」の記事、画面遷移の作り方で実装方式が変わる話は「SPA開発」の記事で扱っています。

デザインの著作権とデータの納品——著作権法61条2項と、元データの引き渡し

見落とされやすいのが権利です。デザインの成果物は著作物になり得ます。制作を外部に委託した場合、作った側に著作権が発生するのが原則で、発注して代金を払っただけでは自社に移りません。移すには契約で譲渡を定める必要があります。

ここで注意が要るのが、著作権法第61条第2項です。条文はこうなっています。

著作権を譲渡する契約において、第二十七条又は第二十八条に規定する権利が譲渡の目的として特掲されていないときは、これらの権利は、譲渡した者に留保されたものと推定する。

第27条は翻訳・編曲・変形・翻案する権利、第28条は二次的著作物の利用に関する原著作者の権利です。つまり、契約書に「著作権を譲渡する」とだけ書いて第27条・第28条を明記(特掲)しないと、デザインを作り替える権利は相手に残っていると推定されます。あとから別の会社に改修を頼めない、という事態はここから起きます。また、著作者人格権は第59条により著作者の一身に専属し譲渡できないため、実務では不行使の合意を併せて定めるのが通例です。

もう1つが元データです。書き出された画像やPDFだけを受け取っても、次の改修はできません。編集可能な元データ一式、フォントの扱い(ライセンスは譲渡できないことが多い)、写真やアイコンの利用許諾の範囲、そして納品の形式と期限を、契約書か発注書に書いてください。私が2018年からホーチミンで約100社の相談に乗ってきた中で、デザインで揉める相談は「状態が描かれていないカンプ」と「解約時に元データをもらえない」の2つに集中するのが実情です。後者は、契約書1行で防げたはずのものばかりでした。知的財産条項の作り方そのものは「システム開発の著作権・ソースコードは誰のもの」の記事で詳しく扱っています。なお本記事は法的助言ではありません。契約書の文言は弁護士にご確認ください。

デザインを外部チームに任せるか、分けるか——分担の決め方と当社の体制

最後に、実務でいちばん迷う論点です。デザインを開発会社にまとめて任せるのか、デザイン会社に分けて出すのか。どちらが正解ということはなく、決め方の問題です。ここでは3つの持ち方を並べ、先に書き出しておくべき4項目を示したうえで、当社の体制についても正直に書きます。

3つの持ち方——発注者が持つ、デザイン会社が持つ、開発会社がまとめて持つ

判断の目安を1つ挙げるなら、「画面の美しさが売上に直結するか」です。一般消費者向けで第一印象が勝負を分けるサービスならB、業務で毎日使うシステムで操作の速さが価値になるならCが噛み合うことが多い、というのが現場での感覚です。開発会社そのものの選び方は「アプリ開発会社の選び方」の記事に譲ります。

分担を決めるときに書き出す4項目——誰が持つか、レビュー回数、修正の範囲、データの権利

どの持ち方を選んでも、次の4項目を発注前に書き出してください。これを決めずに走ると、必ず後半で止まります。

MVPのように作りながら決めていく進め方では、レビュー回数を固定しにくくなります。その場合は回数ではなく「週1回の定例で決める」という時間の枠で縛るほうが機能します。進め方そのものは「MVP開発」の記事で扱っています。

当社の体制——UI/UXデザインの専任体制があります

当社(TALENTBASE VIETNAM)は、UI/UXデザインを担う専任の体制を持っています。開発の体制はパターンA(日本人PM/ブリッジSE+エンジニア・推奨)とパターンB(エンジニアのみ)の2つで、2,000名以上のIT人財データベースから直接アサインする形です。デザインを含めてご相談いただく場合は、5つのブロックのどこまでを当社が担うのかをお聞きしたうえで、体制をご提案します。

上の表でいうBやCの形における実装側や「画面仕様のレビューと実装」はもちろん、デザインを含む形にも対応できます。日本人PMが設計レビューを行い、Gitのプルリクエストによるコードレビューを標準化し、リリース前にダブルチェックをします。ベトナムとの時差は2時間なので、デザインレビューは日本の午前中にそのまま設定できます。介護記録SaaS「CareViewer」では、日本語対応のブリッジSE1名とフルスタック2名の体制で、週次の優先順位判断を回しながら継続開発を進めています。

デザインを誰が持つかを決めるところから相談したい、という段階でもお話を伺えます。大切なのは、5つのブロックのどこまでを当社が担い、どこを御社が持ち続けるのかを、契約の前に文字にしておくことです。ここを曖昧にしたまま契約すると、双方が損をします。

UI/UXに関するよくある質問

UIとUXについて、発注担当者の方から繰り返し聞かれる質問を5つにまとめました。社内説明や、開発会社との打ち合わせの前の確認にお使いください。

Q1. UI/UXデザイナーとWebデザイナーは何が違いますか?

職種名に統一された定義はありません。実務上は、Webデザイナーがサイトの見た目と制作を中心に担い、UI/UXデザイナーは画面の構造や操作の流れ、場合によっては利用者調査までを担うことが多い、という程度の区別です。肩書きで判断せず、過去の成果物(ワイヤーフレームを作っているか、状態まで描いているか)を見せてもらうほうが確実です。

Q2. デザインだけ先に発注できますか?

できます。画面一覧とワイヤーフレームまでを先に固め、それを付けて開発会社に相見積もりを取る進め方は有効です。画面数が確定するため、見積もりの精度が上がります。ただし、実装の制約を知らないまま描いたデザインは作り直しになることがあるため、ワイヤーフレームの段階で一度、実装側に見せて実現性を確認してください。

Q3. 生成AIで画面案は作れますか?

たたき台としては作れます。ワイヤーフレームや配色の候補を短時間で複数出す用途では実用的です。一方で、誰がどの状況で何をするかという利用状況の判断や、業務のルールを画面に落とす作業は人が引き取る必要があります。当社もAIを活用した開発体制を取っていますが、生成物をそのまま仕様にはしません。

Q4. アクセシビリティ対応はどこまで必須ですか?

民間事業者のウェブサイトに一律の適合義務を課す規定は、本記事の確認範囲では見当たりませんでした。ただし2024年4月1日の改正障害者差別解消法の施行で事業者にも合理的配慮の提供が義務づけられており、公共性の高いサービスや自治体案件では WCAG／JIS X 8341-3:2016 のレベルAA相当が要求されることがあります。発注前に、対象範囲と適合レベルを仕様として決めておいてください。

Q5. デザインの良し悪しを、非デザイナーが判断する方法はありますか?

好みで判断しないことです。「実データの最長値で崩れないか」「空・エラー・読み込み中の状態が揃っているか」「主要な操作が最初の画面にあるか」の3点を確認し、そのうえで5人に触ってもらって手が止まる箇所を数える。センスではなく、確認手順で判断できる作業。

まとめ: UIはUXの一部。「UI/UX」は範囲を持たない省略語だから、発注側が範囲を決める

UI(ユーザーインターフェース)は画面・操作・表示を指し、UX(ユーザーエクスペリエンス)は利用前・利用中・利用後に生じる知覚と反応の全体を指します。JIS Z 8521:2020(ISO 9241-11:2018のMOD)3.2.3の定義がそう定めており、UIはUXを形づくる要素の1つです。「UIではなくUXを重視する」という対比は成り立ちません。そしてUXの大半は画面の外——広告、登録、サポート、請求書、解約——にあるため、外注しきれず発注側が持ち続ける部分が必ず残ります。

発注の場で「UI/UX」と1語で書かれているとき、それは「画面を作る一連の作業」を指す省略語で、決まった範囲を持ちません。だから発注側が、調査・設計・ビジュアル・検証・引き渡しの5ブロックで含む/含まないを決めてから相見積もりを取ってください。成果物は情報設計→ワイヤーフレーム→デザインカンプ→プロトタイプの順に作り、レビューに時間をかけるのはワイヤーフレームの段階です。実装との分かれ目で抜けるのは「状態」と「レスポンシブの規則」。権利は、著作権法第61条第2項により第27条・第28条を特掲しないと作り替える権利が相手に残ると推定されるため、元データの引き渡しとあわせて契約に書いてください。使いやすさは効果・効率・満足で測り、5人・40分・3タスクのテストから始められます。

当社はUI/UXデザインを担う専任の体制を持っています。決まったデザインを正しく実装し、画面仕様の抜けを実装側から指摘することもできます。日本人PMの設計レビュー、Gitプルリクエストによるコードレビュー、リリース前ダブルチェックで品質を仕組みにし、時差2時間なので日本の午前中にレビューを設定できます。デザインのどこまでを当社が担うかは、要件をお聞きしたうえで決めます。開発工程の位置づけは要件定義とは、画面設計が属する工程は基本設計とはもあわせてご覧ください。現在の体制と要件をお聞かせいただければ、デザインを誰が持つ形が合うかの判断と概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。