UI/UXデザイナーのフリーランス案件で求められるスキルと経験

UI/UXデザイナーのフリーランス案件では、利用者を調べる力、情報設計とUI設計、試作を使った評価、デザインシステムの整備、アクセシビリティへの対応、開発との連携が問われます。どれも完璧である必要はありませんが、どこまでを自分で担えるかが、任される範囲と評価を分けます。

この記事では、案件でよく問われるスキルを分野ごとに整理し、経験の段階によって何が見られるかを解説します。

公的な整理で見るUI/UXデザイナーのスキル

IPA（情報処理推進機構）が2026年4月に公開したデジタルスキル標準ver.2.0のデザイナー編では、UX/UIデザイナーに特に高い実践力が求められるスキルとして、次の3つを挙げています。発注側が人材の要件を考えるときの参考にもなっているため、自分の経験を整理する物差しとして使えます。

あわせて、テクノロジーやプライバシー保護についても、エンジニアなどと協働して試作を作れる程度の知識が求められるとされています。以下では、この整理を実際の案件の言葉に置き換えて説明します。

利用者を調べる力

調査の力は、UI/UXデザイナーが画面の制作者と区別される一番の点です。案件では、次のような力が問われます。

• 聞き取りの設計：何を確かめたいかを決め、対象者の条件と質問を組み立てる
• 行動の観察：利用者が実際にどう操作し、どこで迷うかを見て記録する
• 数字の読み取り：アクセスの記録や問い合わせの内容から、問題が起きている場所の見当をつける
• 結果のまとめ：調査で分かったことを、設計の判断に使える形で関係者に共有する

業務システムの案件では、利用者が社内の別部門であることが多く、業務の流れを聞き取って整理する力が特に見られます。一般の利用者向けのサービスでは、調査の対象者をどう集め、謝礼や個人情報をどう扱うかまで考えられると、任せられる範囲が広がります。

情報設計とUI設計

調査で分かったことを、画面の構造に落とす力です。見た目の前に、何をどの順で見せるかを決める工程が評価の分かれ目になります。

• 機能と情報の分類、ナビゲーションの構造を決める
• 画面遷移とワイヤーフレームで、利用の流れを関係者と確かめる
• 読み込み中、エラー、データが空のとき、権限がないときなど、画面の状態を漏れなく描く
• 入力の誤りを防ぐ設計と、誤ったときに戻れる設計を考える

デジタル庁の「DS-670.1 ユーザビリティガイドライン」（2026年6月12日改定）は、利用者の行動が想定と異なる結果を引き起こす「使用エラー」への対策を、使いやすさと並ぶ柱として扱っています。業務システムや手続きの画面では、見た目の整い方よりも、誤操作を起こしにくいかどうかが重く見られます。

試作と評価の力

設計が利用者に合っているかを、実装の前に確かめる力です。デジタル庁の「DS-671.1 ユーザビリティ導入ガイドブック」は、評価の方法として、実際の利用者に操作してもらうユーザビリティテストと、専門家が原則に照らして確かめるヒューリスティック評価を紹介しています。同じガイドブックでは、主要な課題を見つけるために、少なくとも5人以上の利用者にテストを行うことを目標にするとよい、という目安も示されています。

案件では、次のような点が問われます。

1. 確かめたいことに合わせて、試作の粗さ（紙、静止画、操作できる試作）を選べるか
2. テストの課題と進め方を組み立て、利用者を誘導せずに観察できるか
3. 見つかった問題に優先順位をつけ、直す範囲を開発と合意できるか

デザインシステムを作り、運用する力

画面が増えるほど、部品や色、文字の決まりをそろえる仕組みが必要になります。デザインシステムの整備は、長く関わる案件で任されやすい仕事です。

公開されている例として、デジタル庁デザインシステムがあります。2026年10月時点ではβ版のv2.18.2で、デザインの考え方、UIの部品、使いやすさとアクセシビリティのガイドラインをまとめ、Figmaのデザインデータと、HTMLやReactのコード例を公開しています。部品ごとに使い方の説明を書き、更新を重ねている点は、民間の案件でデザインシステムを作るときの参考になります。

案件で問われるのは、作る力だけではありません。

• 部品の単位と名前を、実装の部品と対応づけて決められる
• 使い方の説明を書き、デザイナー以外も迷わず使える状態にできる
• 新しい部品の追加や変更を、誰がどう決めるかの進め方を作れる

アクセシビリティに対応する力

年齢や障害の有無にかかわらず使える画面にする力は、公共性の高いサービスだけでなく、民間の案件でも求められることが増えています。

ウェブのアクセシビリティの基準として、国内にはJIS X 8341-3があり、国際的にはW3CのWCAG（Web Content Accessibility Guidelines）があります。DS-671.1では、JIS X 8341-3:2016はWCAG 2.0と互換性があること、WCAGの最新版は2.2であり、デジタル庁デザインシステムがWCAG 2.2に対応できるよう整備されていることが説明されています。

案件では、色のコントラストや文字の大きさだけでなく、キーボードだけでの操作、読み上げソフトでの読まれ方、フォームのエラーの伝え方など、設計の段階で決めるべき点を押さえているかが見られます。

開発と連携する力

デザインは実装されて初めて利用者に届きます。開発チームとの連携では、次の力が問われます。

• デザインデータを、開発者が迷わない形で渡せる（部品・状態・余白の決まりが読み取れる）
• 実装を確認して、デザインとのずれを具体的に伝えられる
• 実装の制約を聞いて、使いやすさを保った代案を出せる

フロントエンドの技術を知っていると、この連携が速くなります。開発側の視点はReactエンジニアのスキルの記事が参考になります。

経験の段階ごとに見られる点

同じスキルでも、経験の段階によって問われる深さが違います。

PdM（プロダクトマネージャー）が何を作るかを決める役割であるのに対し、UI/UXデザイナーは、決めたことを利用者が使える形にし、その使いやすさを確かめる役割です。境界は案件ごとに違うため、面談で役割の分担を確かめましょう。PdMのスキルはPdMのスキルの記事にまとめています。

よくある質問

デザインツールは何を使えればよいですか？

案件では、発注側のチームが使っているデザインツールに合わせることがほとんどです。特定のツールの操作より、部品の作り方やデータの整理の仕方が見られます。参画前に使用するツールと、アカウントを誰が用意するかを確かめておきましょう。

コードが書けないと不利ですか？

コードを書くことが条件になる案件は一部です。ただ、HTMLやCSSの基本と、実装の部品の考え方を理解していると、開発との会話が速くなり、評価につながりやすくなります。独立の準備はUI/UXデザイナーがフリーランスになるにはをご覧ください。

アクセシビリティの経験がない場合、何から始めればよいですか？

まず、ご自身が関わった画面を、キーボードだけで操作できるか、読み上げソフトで内容が伝わるかを確かめてみることをおすすめします。基準の全体像は、デジタル庁のガイドブックやWCAGの公開資料で確かめられます。基準に照らして直した経験は、案件で説明できる材料になります。