digdir · mrosvik · Feb 5, 2026 · Feb 5, 2026 · Feb 5, 2026 · Feb 6, 2026
@@ -1,7 +1,7 @@
 ---
 title: Button placement and order
 sidebar_title: Button placement
-category: Upcoming
+category: Upcoming patterns
 description: How can we create a more predictable and inclusive experience by standardizing button placement and order?
 partners: Digdir, Nav, Skatteetaten ++
 search_terms: placement, order

@@ -0,0 +1,29 @@
+---
+title: Consent banner
+sidebar_title: Consent banner
+category: Upcoming patterns
+description: How can we ensure a holistic and accessible approach to managing consent for cookies and tracking technologies?
+partners: Digdir, Nav, Skatteetaten ++
+search_terms: consent banner, cookie banner, cookies, consent, privacy
+date: 2026-02-16
+order: 75
+---
+
+A consent banner should give users genuine control over their own data. At the same time, it must be clear, understandable and accessible to everyone. Today, this is handled differently across public services, both in terms of language, design, equal presentation of choices and technical implementation.
+
+A shared pattern for consent banners can contribute to:
+
+- A more consistent and recognisable user experience  
+- Equal presentation of choices, without manipulative design  
+- Improved accessibility and inclusive design  
+- Clearer distinction between necessary and optional technologies  
+- A shared understanding of recommended interaction and behaviour  
+
+<Card
+  data-color='warning'
+  variant="tinted"
+>
+**Work in progress** \
+A cross-agency working group is developing common guidelines and recommendations for this topic during spring 2026. We greatly appreciate input from anyone with relevant experience, insights or results from user testing. You are welcome to contribute in the related [GitHub discussion thread](https://github.com/digdir/designsystemet/discussions/1671).
+
+</Card>
@@ -0,0 +1,15 @@
+---
+title: Ask users for date and time
+sidebar_title: Date and time
+category: Ask users for...
+description: Date and time can often be solved more simply than many people think.
+partners: Digdir, Brønnøysundregistrene
+date: 2026-02-05
+order: 10
+---
+
+Asking users for date and time is often solved in a more complex way than necessary. In many situations, a simple [`Textfield`](link) is both faster to use and easier to understand than more advanced solutions.
+
+## Ask users for date of birth
+
+Example....
@@ -1,7 +1,7 @@
 ---
 title: User-triggered error messages
 sidebar_title: Error messages
-category: Completed
+category: Basic patterns
 description: How to tell users that something has been filled in incorrectly or is missing in a form.
 partners: Digdir, Nav, Skatteetaten ++
 search_terms: validation

@@ -1,7 +1,7 @@
 ---
 title: Labeling Links
 description: How should we label links, and which language and design principles should we follow?
-category: Completed
+category: Basic patterns
 partners: Digdir, Nav, Skatteetaten ++
 search_terms: linktext, target, navigation, url
 date: 2025-05-12

@@ -1,7 +1,7 @@
 ---
 title: Sign-in and representation
 sidebar_title: Representation
-category: Upcoming
+category: Upcoming patterns
 description: How do we handle switching between actors across services?
 partners: Digdir, Nav, Skatteetaten ++
 date: 2025-12-03

@@ -1,7 +1,7 @@
 ---
 title: Required and optional form fields
 sidebar_title: Required fields
-category: Completed
+category: Basic patterns
 description: To help users understand which fields must be completed, required fields must be clearly and consistently labelled.
 partners: Digdir, Nav, Skatteetaten ++
 date: 2026-02-02

@@ -1,7 +1,7 @@
 ---
 title: System notifications
 sidebar_title: System notifications
-category: Completed
+category: Basic patterns
 description: How to help users understand situations in the service that are not caused by their own actions.
 partners: Digdir, Nav, Skatteetaten ++
 search_terms: alert, modal

@@ -1,5 +1,3 @@
-## Common patterns
-
 If we can establish common patterns, it becomes easier for a user who has done something in one place to recognize and understand how to do it elsewhere. This way, we can help include more people digitally. It is also one of the measures in the "[Action Plan for Increased Inclusion in a Digital Society, measure 26](https://www.regjeringen.no/no/dokumenter/handlingsplan-for-auka-inkludering-i-eit-digitalt-samfunn/id2984233/)", which states that we should work towards more similar interaction patterns across services.
 
 Common patterns can, for example, contribute to:
@@ -10,36 +8,14 @@ Common patterns can, for example, contribute to:
 
 In the report "[Digital throughout life with better user experience](https://www.digdir.no/sammenhengende-tjenester/digital-hele-livet-med-bedre-brukeropplevelse/4405)", several [concrete usability problems](https://github.com/digdir/innsiktsbibliotek/issues/3) have been identified that can be improved if we collaborate on establishing similar patterns across public services. We can collaborate on patterns even if we don't use the same technical components or design elements.
 
-<Image
-  src="/img/felles-retning.png"
-  alt="Illustration with arrows pointing in the same direction"
-  boxShadow={false}
-  caption="Collaboration on patterns gives us a common direction for user experience, providing increased recognition and security for users, and contributes to the public sector delivering high-quality services across organizations."
-/>
-
-## Cross-agency collaboration
-
-To establish common patterns across services, the design system teams from **Digdir, Nav, Norwegian Tax Administration, Brønnøysund Register Centre, and Oslo Municipality**, among others, have formed a cross-agency working group to develop common guidelines for interaction patterns.
+To establish shared patterns across organisations, we have created a cross-agency pattern collaboration. You can read more about this in the [Collaboration model](/en/intro/collaboration#3-tverretatlig-mønster-samarbeid).
 
-We gather insights from our own organizations, review them, identify differences, and arrive at a common approach through regular work meetings.
-
-The patterns established through this collaboration are published as articles:
-
-- [Required and optional form fields](required-and-optional-fields)
-- [User-triggered error messages](errors)
-- [System notifications](systemnotifications)
+We gather insights from our respective organisations, review them together, identify differences, and agree on a shared approach through regular working sessions. Anyone can influence the work through open discussions in [Slack](https://www.designsystemet.no/slack) and [GitHub](https://github.com/digdir/designsystemet/discussions/categories/samarbeid-m%C3%B8nster-for-innbyggertjenester). If you would like to be more closely involved, there is also room for additional participants in the working groups. [Get in touch by email](mailto:designsystem@digdir.no).
 
 ## Planned patterns
 
-The patterns that need to be addressed across agencies are documented in [this overview on Github](https://github.com/digdir/designsystemet/discussions/categories/samarbeid-m%C3%B8nster-for-innbyggertjenester). The main group for pattern collaboration prioritizes which patterns to work on and initiates working groups. If you have suggestions for other patterns, you are welcome to [create a new discussion thread](https://github.com/digdir/designsystemet/discussions/new?category=samarbeid-m%C3%B8nster-for-innbyggertjenester). We also appreciate all insights shared in the various topic threads for each pattern.
-
-## Join the collaboration
+Patterns that require cross-agency collaboration are documented in [this GitHub overview](https://github.com/digdir/designsystemet/discussions/categories/patterns-for-public-services?discussions_q=is%3Aopen+category%3A%22Patterns+for+public+services%22+sort%3Atop).
 
-Anyone who wishes can influence the work through open discussions on [Slack](https://www.designsystemet.no/slack) and [Github](https://github.com/digdir/designsystemet/discussions/categories/samarbeid-m%C3%B8nster-for-innbyggertjenester). If you want to be more closely involved in the collaboration, we also have room for more participants in the working groups. [Contact us (email)](mailto:designsystem@digdir.no)!
+The main group for the pattern collaboration prioritises which patterns to work on and initiates working groups as needed. If you have suggestions for additional patterns, you are welcome to [start a new discussion thread](https://github.com/digdir/designsystemet/discussions/new?category=samarbeid-m%C3%B8nster-for-innbyggertjenester).
 
-<Image
-  src="/img/logo-monstre.png"
-  alt="Logos of Digdir, Oslo Municipality, Nav, Norwegian Tax Administration, Brønnøysund Register Centre"
-  boxShadow={false}
-  caption="Digdir, Nav, Norwegian Tax Administration, Oslo Municipality, and Brønnøysund Register Centre are among those participating in the work to establish common patterns across services"
-/>
+We also appreciate any insights shared in the topic threads for each pattern.
@@ -1,7 +1,7 @@
 ---
 title: Plassering og rekkefølge på knapper
 sidebar_title: Plassering av knapper
-category: Kommende
+category: Kommende mønstre
 description: Hvordan kan vi skape en mer forutsigbar og inkluderende opplevelse ved å standardisere plassering og rekkefølge på knapper?
 partners: Digdir, Nav, Skatteetaten ++
 search_terms: button, knapperekkefølge, knappplassering
@@ -17,7 +17,7 @@ Ulik plassering og rekkefølge på knapper, særlig navigasjonsknapper, kan skap
   variant="tinted"
 >
 **Arbeid pågår** \
-En tverretatlig arbeidsgruppe arbeider høsten 2025 med å utvikle felles retningslinjer og anbefalinger for dette temaet. Vi setter stor pris på innspill fra alle som har erfaringer, innsikt eller resultater fra brukertester. Bidra gjerne i den tilhørende [diskusjontråden på github.com](https://github.com/digdir/designsystemet/discussions/1671).
+En tverretatlig arbeidsgruppe arbeider med å utvikle felles retningslinjer og anbefalinger for dette temaet. Vi setter stor pris på innspill fra alle som har erfaringer, innsikt eller resultater fra brukertester. Bidra gjerne i den tilhørende [diskusjontråden på github.com](https://github.com/digdir/designsystemet/discussions/1671).
 
 </Card>
 

@@ -0,0 +1,29 @@
+---
+title: Samtykkebanner
+sidebar_title: Samtykkebanner
+category: Kommende mønstre
+description: Hvordan kan vi sikre helhetlig og tilgjengelig håndtering av samtykke til informasjonskapsler og sporingsteknologi?
+partners: Digdir, Nav, Skatteetaten ++
+search_terms: consent banner, cookie banner, cookies, samtykke, personvern
+date: 2026-02-16
+order: 75
+---
+
+Et samtykkebanner skal gi brukeren reell kontroll over egne data. Samtidig skal det være tydelig, forståelig og tilgjengelig for alle. I dag løses dette ulikt på tvers av offentlige tjenester, både når det gjelder språk, utforming, likeverdige valg og teknisk implementering.
+
+Et felles mønster for samtykkebanner kan bidra til:
+
+- Mer konsekvent og gjenkjennelig brukeropplevelse
+- Likeverdig presentasjon av valg, uten manipulerende design
+- Bedre tilgjengelighet og universell utforming
+- Tydeligere avgrensning mellom nødvendige og valgfrie teknologier
+- Felles forståelse av anbefalt interaksjon og oppførsel
+
+<Card
+  data-color='warning'
+  variant="tinted"
+>
+**Arbeid pågår** \
+En tverretatlig arbeidsgruppe arbeider våren 2026 med å utvikle felles retningslinjer og anbefalinger for dette temaet. Vi setter stor pris på innspill fra alle som har erfaringer, innsikt eller resultater fra brukertester. Bidra gjerne i den tilhørende [diskusjontråden på github.com](https://github.com/digdir/designsystemet/discussions/1671).
+
+</Card>
@@ -0,0 +1,135 @@
+---
+title: Spør brukeren om dato og klokkeslett
+sidebar_title: Dato og klokkeslett
+category: Spør brukeren om...
+description: Å spørre brukeren om dato og klokkeslett blir ofte løst mer komplisert enn nødvendig. I mange situasjoner er vanlige input-felt både raskere å bruke og lettere å forstå enn egenbygde datovelgere. 
+partners: Digdir, Brønnøysundregistrene
+date: 2026-02-05
+order: 10
+---
+
+Hvordan du ber brukeren om dato og klokkeslett, bør ta utgangspunkt i hvilken informasjon du faktisk trenger. Noen datoer er enkle å huske, som fødselsdato, mens andre må leses fra dokumenter eller kort. I noen situasjoner holder det med en omtrentlig dato, som «desember 2017», eller en dato i forhold til i dag, som «4 dager fra nå». Andre ganger skal brukeren velge en dato eller et tidspunkt fra et forhåndsdefinert utvalg.
+
+Unngå å gjøre oppgaven mer komplisert enn nødvendig. Egenbygde datovelgere gir ofte lavere tilgjengelighet og mer friksjon enn enkle tekstfelt. De kan være vanskelige å bruke med tastatur, gi dårlig støtte for skjermleser og kreve unødvendig navigering når brukeren allerede kjenner datoen.
+
+## Kjente datoer
+
+Når du spør om kjente datoer, som fødselsdato eller bryllupsdato, fungerer enkle tekstfelt godt. Brukeren vet allerede svaret og ønsker ofte å skrive det direkte, uten å måtte navigere i en kalender.
+
+Del gjerne datoen opp i separate felt for dag, måned og år. Det gjør det enklere å skrive inn datoen korrekt og gir bedre støtte for hjelpemidler.
+
+<Image
+  src='/img/date-and-time/example1.webp'
+  alt='Tre separate felt for dag, måned og år'
+  boxShadow={false}
+/>
+
+<Story story="KnownDates" />
+
+Når du ber brukeren om en dato slik den står i et bankkort, pass eller annet dokument, bør feltene samsvare med formatet i dokumentet. Det gjør det enklere å overføre datoen korrekt og reduserer risikoen for feil.
+
+## Konkret dato i nær fremtid eller fortid
+
+I noen tilfeller skal brukeren velge en konkret dato tett opp mot dagens dato, for eksempel ved bestilling av time eller valg av frist. Da kan det være nyttig med visuell støtte. En [`Input`](/no/components/docs/input/overview) med `type="date"` lar brukeren enten skrive datoen direkte eller bruke nettleserens innebygde datovelger. Dette gir ofte en god balanse mellom fleksibilitet og støtte. Støtten varierer mellom nettlesere og enheter, både når det gjelder funksjonalitet, utseende og interaksjon, men løsningen er ofte mer tilgjengelig og robust enn egenbygde alternativer.
+
+<Image
+  src='/img/date-and-time/example2.webp'
+  alt='Tekstfelt med innebygd datovelger'
+  boxShadow={false}
+/>
+
+## Start- og sluttdato
+
+Når brukeren skal oppgi en periode, bør startdato og sluttdato vises tydelig sammen. Bruk to separate felt, og gjør det klart hvilken dato som er hvilken.
+
+Plasser feltene i logisk rekkefølge, og valider at sluttdato ikke er før startdato. Hvis datoene avhenger av hverandre, bør feilmeldinger forklare hva som er galt og hvordan brukeren kan rette det.
+
+<Image
+  src='/img/date-and-time/example3.webp'
+  alt='Tekstfelt for startdato og sluttdato'
+  boxShadow={false}
+/>
+
+## Klokkeslett – start og slutt
+
+Når brukeren skal oppgi et tidsintervall, som åpningstid eller varighet på et møte, fungerer en [`Input`](/no/components/docs/input/overview) med `type="time"` godt. Det lar brukeren skrive klokkeslettet direkte, samtidig som nettleseren tilbyr støtte.
+
+Bruk separate felt for start- og sluttid, og vis dem tydelig sammen.
+
+<Image
+  src='/img/date-and-time/example4.webp'
+  alt='To tekstfelt for start- og sluttid'
+  boxShadow={false}
+/>
+
+## Omtrentlig tidspunkt
+Hvis brukeren bare trenger å oppgi måned og år, bør det være mulig å gjøre nettopp det. Dette er særlig relevant når hendelsen ligger langt tilbake i tid, og brukerne ikke nødvendigvis vet nøyaktig tidspunkt. 
+
+For eksempel kan du la brukeren oppgi omtrentlig tid i et fritekstfelt, eller tilby egne felt for kun måned og år slik som i eksempelet under.
+
+<Image
+  src='/img/date-and-time/example5.png'
+  alt='Felt for måned og år'
+  boxShadow={false}
+/>
+
+
+## Dato relativt til en annen dato
+
+I noen situasjoner er det mer naturlig å spørre om datoer relativt til i dag eller til en annen dato, for eksempel når brukeren setter opp en påminnelse. Da kan det være bedre å bruke en [`Select`](/no/components/docs/select/overview) for å gi brukeren valg om «i morgen», «om 3 dager» eller «1 dag før». Hvis ukedag er viktig for oppgaven, bør denne vises tydelig i tillegg.
+
+<Image
+  src='/img/date-and-time/example6.png'
+  alt='Valg av relative datoer'
+  boxShadow={false}
+/>
+
+## Dato fra et forhåndsdefinert utvalg
+
+Hvis du vet at brukeren skal velge en dato eller et tidspunkt fra et begrenset utvalg, for eksempel ledige timer den kommende uken, kan det være mer effektivt å tilby disse som ferdige valg.
+
+Når utvalget er svært begrenset, for eksempel noen få datoer eller tidspunkter, kan [`Radio`](/no/components/docs/radio/overview) være et godt valg. Det gjør det raskt og enkelt å velge et alternativ uten å måtte skrive noe selv.
+
+<Image
+  src='/img/date-and-time/example7.webp'
+  alt='Forhåndsdefinert utvalg datoer eksempel 1'
+  boxShadow={false}
+/>
+
+Når antall valg øker, kan en [`Select`](/no/components/docs/select/overview) være nyttig for å begrense utvalget. Da kan brukeren for eksempel først velge en uke, og deretter velge blant de tilgjengelige tidspunktene i den uken. Du bør kun vise uker som har ledige tidspunkt, og unngå å deaktivere uker som ikke har det, da det kan skape forvirring. Forklar i forkant at det kun er uker med ledige tidspunkt som vises, slik at brukeren forstår hvorfor noen uker ikke er tilgjengelige å velge.
+
+<Image
+  src='/img/date-and-time/example8.webp'
+  alt='Forhåndsdefinert utvalg datoer eksempel 2'
+  boxShadow={false}
+/>
+
+Finnes det mange ledige tidspunkt den uken, bør valget kunne begrenses ytterligere, for eksempel ved å la brukeren velge en dag, og deretter velge blant de tilgjengelige tidspunktene den dagen.
+
+<Image
+  src='/img/date-and-time/example9.webp'
+  alt='Forhåndsdefinert utvalg datoer eksempel 3'
+  boxShadow={false}
+/>
+
+Når brukerne har valgt en dag, bør de se alle tilgjengelige tidspunkter på den dagen. [`Radio`](/no/components/docs/radio/overview) fungerer godt for dette, da det gjør det raskt og enkelt å velge et tidspunkt uten å måtte skrive noe selv.
+
+<Image
+  src='/img/date-and-time/example11.webp'
+  alt='Forhåndsdefinert utvalg datoer eksempel 5'
+  boxShadow={false}
+/>
+
+## Oppsummering
+
+Start med behovet, og velg den løsningen som lar brukeren løse oppgaven raskest mulig. Ofte er vanlige tekstfelt mer tilgjengelige og raskere å bruke enn avanserte datovelgere. 
+
+- Vis ferdige valg når alternativene er begrensede
+- La brukeren skrive når svaret er kjent
+- Spør bare om så presis dato og tid som situasjonen krever
+- Bruk innebygd nettleserstøtte fremfor egenbygde løsninger
+
+## Kilder og relevant informasjon
+- [Who needs a JavaScript date picker? (dbushell.com)](https://pikaday.dbushell.com/)
+- [Maybe You Don’t Need a Date Picker (adrianroselli.com)](https://adrianroselli.com/2019/07/maybe-you-dont-need-a-date-picker.html)
+- [Ask users for dates (gov.uk)](https://design-system.service.gov.uk/patterns/dates/)
@@ -0,0 +1,28 @@
+import { Fieldset, Textfield } from '@digdir/designsystemet-react';
+
+export const KnownDates = () => {
+  return (
+    <Fieldset>
+      <Fieldset.Legend data-size='lg'>Når ble du født?</Fieldset.Legend>
+      <Fieldset.Description>For eksempel 24 7 1987</Fieldset.Description>
+
+      <div style={{ display: 'flex', gap: 'var(--ds-size-4)' }}>
+        <Textfield
+          label='Dag'
+          style={{ maxWidth: '3.5em' }}
+          autoComplete='bday-day'
+        />
+        <Textfield
+          label='Måned'
+          style={{ maxWidth: '3.5em' }}
+          autoComplete='bday-month'
+        />
+        <Textfield
+          label='År'
+          style={{ maxWidth: '6.5em' }}
+          autoComplete='bday-year'
+        />
+      </div>
+    </Fieldset>
+  );
+};
@@ -1,7 +1,7 @@
 ---
 title: Brukerutløste feilmeldinger
 sidebar_title: Feilmeldinger
-category: Ferdig
+category: Grunnleggende mønstre
 description: Slik forteller du brukeren at noe er fylt ut feil eller mangler i et skjema.
 partners: Digdir, Nav, Skatteetaten ++
 search_terms: validation, validering, feil