humane-functionalism
Back to list

kemiljk/humane-functionalism

Humane Functionalism

GitHub

Improve UI and UX through Danish functionalism. Use for a Danish functionalist design pass on a screen or flow, grounding hierarchy, interaction, human fit, and craft in actual use.

29 installsCraftInteractionVisual0 demos

Real-world examples not captured yet

This skill shows a gallery of live HTML demos (CDN libraries welcome — GSAP, Three.js, etc.) rendered inline via srcdoc.

Skill markdown
# Humane Functionalism

Apply Danish functionalism to the way an interface is organised, used, and experienced. Let human needs, context, construction, and perception guide its form.

The foundation is Danish architectural and product functionalism, with relevant lessons from Danish Modern furniture. These are contemporary UI applications, not a historical manifesto or rules those designers wrote for software. Read [research and sources](references/research.md) when explaining an attribution or exploring a particular designer's contribution. The working guidance below is self-contained.

## Start from use

Infer the primary task, audience, frequency, input methods, platform, and constraints from the request and available design or code. State the intended improvement briefly. Ask only when a missing decision would materially change the work.

Inspect the named screen or flow, existing tokens and components, realistic content, and relevant states. A screenshot supports visual observations; source supports implementation observations; neither proves task success. Distinguish observed friction from a hypothesis that needs testing.

Review requests produce findings. Requests to improve, redesign, or implement authorize scoped changes. Preserve product requirements, brand identity, useful density, and working conventions. Fit this lens to the requested task rather than expanding a local correction into a complete redesign.

## Design through the Danish references

These connections are an editorial synthesis. Use the relevant lenses to make decisions; do not force a finding or an edit for every designer.

### Human fit — Kaare Klint

Klint's studies of proportions and existing furniture suggest a method: examine use before choosing form.

Size and arrange controls around reading, reach, dexterity, and the input method. Test real content, long labels, text scaling, and varied abilities. Preserve recognisable controls and useful shortcuts while correcting their weaknesses. A single assumed average user is insufficient.

**Check:** can the intended task be completed with the relevant inputs and content variations without clipping, precision targeting, or hidden essential actions?

### A coherent whole — Arne Jacobsen

Jacobsen's integration of architecture and interiors suggests treating the flow and its details as one designed experience.

Connect navigation, terminology, hierarchy, components, and feedback. Use the same language and state meanings from entry through completion. Check the relationship between screens before polishing an isolated component. Coherence does not require replacing platform conventions with bespoke controls.

**Check:** follow one task across screens; do labels, action priorities, focus, and state transitions remain intelligible?

### Perceptual comfort — Poul Henningsen

Henningsen's work on directing light and controlling glare makes the experienced effect a useful starting point.

Give attention a clear destination through type, spacing, grouping, and selective emphasis. Reduce competing accents and unnecessary motion. Preserve readable contrast and visible focus; a quieter screen must still communicate. Choose colour for content, identity, and conditions of use rather than a prescribed Scandinavian palette.

**Check:** can people distinguish content, actions, status, and focus at the intended viewing size? Physical glare and screen contrast are different phenomena; this is a perceptual analogy, not a lighting formula for UI.

### Organisation from activity — Vilhelm Lauritzen

Lauritzen's arrangement of buildings around their functions suggests deriving information architecture from the activities it must support.

Map the user's sequence and the decisions at each step. Place controls and information where they are needed. Separate incompatible activities; keep related ones connected. Expose location, next actions, and routes back. Include interruption, errors, and recovery in the flow.

**Check:** walk from entry to completion and through a failure. Can the user understand what happened and continue without losing work?

### Everyday usefulness — Børge Mogensen

Mogensen's work for ordinary living and production suggests investing quality in repeated, practical use.

Prioritise frequent and consequential tasks. Make defaults useful, common actions discoverable, and recovery forgiving. Support modest devices, slow connections, keyboard navigation, and assistive technology. Keep essential tasks usable without optional media or effects. Low feature count is not inherently more useful.

**Check:** repeat the common task under a relevant constraint. Does the interface still work comfortably without extra setup or avoidable waiting?

### Fit to context — Kay Fisker

Fisker's functional tradition suggests adapting useful conventions and materials to their setting.

Work with the product's existing system, platform, audience, and content. Set density and layout by the work: an expert compa

…

More from kemiljk