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.
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
- Ai Output JudgementCritique generated UI, copy, or code when the user requests a quality review of AI output.
- Android Native UIBuild or review Android interfaces in Compose or Views, including Material conventions, accessibility, adaptive layout, and state.
- Apple Native UIBuild or review native Apple interfaces, including platform controls, accessibility, state, navigation, and macOS window behavior.
- Design EngineeringTranslate design intent into production components or improve collaboration between design and engineering.
- Design For RepetitionImprove workflows used repeatedly by examining recurring effort, waiting, setup, interruption, context retention, and expert paths. Use when an experience works once but may become tiring or inefficient in regular use.
- Design System EvolutionDecide how an existing design system should evolve: reuse a component, add a variant, change its API, or introduce a new pattern. Use when real design or code consumers expose a mismatch and a bounded compatibility or migration decision is needed.