humane-functionalism について
デンマーク機能主義の考え方を、インターフェースのレビューや改善に応用するデザインスキルです。デザイナーやコーディングエージェントが、利用者のニーズと状況に基づいて変更範囲を定め、根拠を確認しながら改善できます。
主な機能
- 01タスクと利用状況を起点にする
- 026つのデンマークデザインの視点
- 03有用な情報密度と慣例の維持
- 04課題を最小限の変更に結び付ける
- 05タスクに応じた検証
活用シーン
- 01画面やユーザーフローのレビュー
- 02多様な入力方法に合わせた操作部品の調整
- 03フィードバックとエラー回復の改善
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ kemiljk/ skills --skill humane-functionalismインストール後、Claude Code で/humane-functionalismを入力して読み込まれたか確認します。
同梱ファイルreferences/research.md
詳細
人間中心の機能主義
インターフェースの構成、使い方、体験にデンマークの機能主義を取り入れます。人間のニーズ、利用状況、構造、知覚を指針として、その形を決めます。
基盤となるのは、デンマークの建築およびプロダクトにおける機能主義と、デンマークモダン家具から得られる関連する教訓です。これらは現代のUIへの応用であり、歴史的な宣言でも、当時のデザイナーがソフトウェア向けに定めたルールでもありません。特定のデザイナーの貢献について説明したり、詳しく調べたりする場合は、調査と出典を参照してください。以下の実践的な指針だけで利用できます。
使い方から始める
依頼内容と利用可能なデザインやコードから、主なタスク、対象ユーザー、利用頻度、入力方法、プラットフォーム、制約を推測します。意図する改善を簡潔に述べます。不足している判断材料によって作業内容が大きく変わる場合に限り、質問してください。
指定された画面やフロー、既存のトークンとコンポーネント、現実的なコンテンツ、関連する状態を確認します。スクリーンショットは視覚的な観察を裏付けます。ソースコードは実装に関する観察を裏付けます。どちらもタスクの成功を証明するものではありません。観察された使いづらさと、テストが必要な仮説を区別します。
レビューの依頼では、問題点を報告します。改善、再設計、実装の依頼では、範囲を定めた変更を行います。製品要件、ブランドアイデンティティ、有用な情報密度、既存の作業慣行を維持します。この視点を依頼されたタスクに合わせ、局所的な修正を全面的な再設計へと広げないでください。
デンマークのデザインを参考にする
以下のつながりは、編集上の統合です。関連する視点を使って判断し、すべてのデザイナーについて無理に問題点や修正点を見つけないでください。
人に合った設計 — Kaare Klint
Klintがプロポーションや既存の家具を研究したことから、形を選ぶ前に使い方を調べる方法がうかがえます。
読みやすさ、手の届きやすさ、手先の器用さ、入力方法を考慮して、コントロールのサイズと配置を決めます。実際のコンテンツ、長いラベル、テキストの拡大、さまざまな能力を想定してテストします。認識しやすいコントロールや便利なショートカットを維持しながら、その弱点を改善します。平均的なユーザーを一人だけ想定するのでは不十分です。
**確認事項:**想定するユーザーは、切り取り、精密な位置合わせ、重要な操作の隠蔽なしに、関連する入力方法やコンテンツの違いに対応してタスクを完了できますか?
一貫した全体 — Arne Jacobsen
Jacobsenが建築とインテリアを統合したことから、フローと細部を一体となった体験として扱う視点が得られます。
ナビゲーション、用語、階層、コンポーネント、フィードバックをつなげます。開始から完了まで、言葉遣いと状態の意味を統一します。単独のコンポーネントを磨く前に、画面同士の関係を確認します。一貫性を保つために、プラットフォームの慣習を独自のコントロールに置き換える必要はありません。
**確認事項:**一つのタスクを画面間で追跡したとき、ラベル、操作の優先順位、フォーカス、状態の遷移は理解しやすいままですか?
知覚的な快適さ — Poul Henningsen
光を導き、まぶしさを抑えたHenningsenの仕事は、体験される効果を有用な出発点にします。
タイポグラフィ、余白、グループ化、選択的な強調によって、注意を向ける先を明確にします。競合するアクセントや不要な動きを減らします。読みやすいコントラストと見えるフォーカスを維持し、画面を落ち着かせても必要な情報は伝わるようにします。色は、規定の北欧風パレットに従うのではなく、コンテンツ、アイデンティティ、利用条件に合わせて選びます。
**確認事項:**想定する表示サイズで、ユーザーはコンテンツ、操作、状態、フォーカスを見分けられますか?物理的なまぶしさと画面のコントラストは別の現象です。これは知覚に関する類推であり、UI向けの照明公式ではありません。
活動に基づく構成 — Vilhelm Lauritzen
Lauritzenによる機能に合わせた建物の配置からは、支援すべき活動を起点に情報アーキテクチャを組み立てる考え方が得られます。
ユーザーの手順と、各段階での判断を把握します。操作部と情報は、必要な場所に配置します。両立しない活動は分け、関連する活動はつなげます。現在地、次の操作、戻るための経路を明示します。中断、エラー、復旧もフローに含めます。
確認: 開始から完了まで、そして失敗した場合の流れをたどります。ユーザーは何が起きたのかを理解し、作業を失わずに続けられますか?
日常での実用性 — Børge Mogensen
日常生活や生産のために作られたMogensenの作品からは、繰り返し使う実用的な場面の品質に力を注ぐ考え方が得られます。
頻繁に使われ、重要なタスクを優先します。初期設定を使いやすくし、一般的な操作を見つけやすく、復旧しやすい設計にします。性能が控えめなデバイス、遅い接続、キーボード操作、支援技術にも対応します。必須のタスクは、オプションのメディアやエフェクトがなくても使えるようにします。機能が少なければ、それだけで使いやすいとは限りません。
確認: 関連する制約の下で、一般的なタスクを繰り返します。追加の設定や避けられる待ち時間がなくても、インターフェースを快適に使えますか?
コンテキストへの適合 — Kay Fisker
Fiskerの機能主義の伝統からは、有用な慣例や素材を、それらが使われる環境に適応させる考え方が得られます。
製品の既存のシステム、プラットフォーム、対象ユーザー、コンテンツを活用します。作業内容に合わせて情報密度とレイアウトを決めます。たとえば、専門家向けの比較表では多くの値を一度に表示する必要がある一方、タッチ操作のフォームでは広めの間隔が必要な場合があります。実績のあるパターンは、置き換える前に改善します。見た目のスタイルだけでは、使い勝手に適しているとは言えません。
確認: 提案した変更はその場の問題を解決しますか? また、その変更によってどんな有用な知識や機能が失われますか?
ものづくりとしてのクラフト — Hans J. Wegner and Poul Kjærholm
二人のデンマークモダンの関連作品からは、快適さ、接合、構造、素材の特性について具体的な示唆が得られます。
セマンティクス、レスポンシブレイアウト、コンポーネントの境界、状態遷移を、インターフェースを構築する要素として扱います。プラットフォームの強みを活用します。問題の原因となっているコンポーネントを修正し、ほかの箇所での使われ方も確認します。読み込み中、保存済み、失敗、無効の各状態を、実際の動作に対応させます。コンポーネントが組み合わさる箇所は、通常時の見た目と同じくらい注意深く確認します。
確認: 長いコンテンツ、サイズ変更、フォーカスの移動、操作の失敗を試します。構造は、ビジュアルデザインが約束することを実現できていますか?
使用を通じてトレードオフを解消する
| トレードオフ | 判断基準 |
|---|---|
| シンプルさと発見しやすさ | ユーザーの操作に役立つラベル、境界、常に表示される必須操作は維持します。フィールドが消えることは改善ではありません。 |
| 落ち着きと情報密度 | 比較に必要な情報を維持します。有用なコンテンツを追加のクリックの先に隠す前に、配置やグループ化を改善します。 |
| 一貫性とコンテキスト | 意味やパターンは共有しつつ、タスクやデバイスに合わせてレイアウトや情報密度を変えられるようにします。 |
| 抑制と表現 | 意味、アイデンティティ、快適さ、楽しさを支える色、個性、表現豊かな形は残します。Finn Juhlは厳格な機能主義の形に対する、関連するデンマークモダンの対比であり、普遍的なスタイルの根拠ではありません。 |
| 速さと慎重な操作 | 重複する手順は省きます。重大なミスを防ぐために役立つ確認は残します。クリック数だけではタスクの質は測れません。 |
改善を実施し、検証する
重要な問題ごとに、確認された状態 → ユーザーへの影響 → 効果的な最小限の変更 → 検証を結び付けます。たとえば、リクエストの完了前に保存済みの表示が現れる → ユーザーが未保存の作業を残したまま離れる可能性がある → 保存中、保存済み、失敗の状態を区別する → 保存の失敗と再試行を、入力を失わずに実行できるか確かめる、という流れです。
まず、タスクの完了、アクセシビリティ、信頼できるフィードバックを優先し、次に理解しやすさと復旧しやすさ、その後に視覚的な調整に取り組みます。適合する場合は既存のシステム値を使います。問題が体系的であれば、トークンを見直します。
代表的なコンテンツ、異なるレイアウトサイズ、関連する入力方法を使って、影響を受けるタスクを再確認します。変更した読み込み、成功、失敗、復旧の各状態を試します。変更に関係する場合は、フォーカスの視認性、読みやすいコントラスト、テキストの拡大、モーションの低減を確認し、数値要件には現行のプラットフォームガイダンスを使用します。
主張に合った根拠を示します。階層には視覚的な比較、操作には入力手順、復旧には失敗のシミュレーション、パフォーマンスにはネットワークまたは実行時の測定を用います。確認できない項目があれば、未検証の内容を明記します。見た目からアクセシビリティを推測したり、使いやすさの結果を捏造したりしないでください。
依頼されたデザイン、コード、レビューを、重要な変更点、維持した強み、実施した確認、残る制約とともに提出します。それ以上変更してもタスクや体験が改善されなくなった時点で終了します。