You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Inbox design patterns for mail or notifications are common in commercial applications. The most pervasive patterns are a three-panel fluid layout for large & medium-sized screens and tabbed navigation with card components representing discrete messages for mobile.
We're testing the possibility of a cross-government inbox pattern to enable more rapid communication between departments and citizens.
Several components within the design system could be used to build an inbox-type experience. Modern inbox patterns are quite complex, setting a high standard for user interaction. Similar to driving a car—which is complex but, once mastered, offers significant benefits—these inbox patterns may not be easy or intuitive at first (or even accessible). However, their continuous development and widespread use have made them the standard way to manage complex tasks.
Why
Design System
Even though this will not be a reusable component it could be a keystone design pattern that connects to, possibly impacting, other patterns within the design system. This needs consideration from the design system community and input from other research and experiences.
Depending on the level of service integration into the inbox, many of the existing Design system components will be used including form design components and general service interactions.
There may also be existing inbox patterns that have been designed and tested internally for civil servants and gov departments that we can learn from when designing for a wider group of users.
Needs
The primary need is for citizens to receive communications from government departments that cover legal and functional requirements to implement policy. The government needs an official way to send these communications to individuals and organisations. Currently, this is done through physical letters sent to a mailbox at the person's residence, which is verified to be connected to their identity.
Although we have not yet researched the specific needs, we have a few initial assumptions that we will test during our work:
Persistent and Recoverable Communication: Citizens need a reliable way to receive government communications that won't be lost, destroyed, or missed (e.g., when moving). Physical letters can fail to meet this need.
Control Over Communication Preferences: Citizens should be able to manage their communication preferences with the entire government, rather than dealing with each department individually. This is especially important for those who need assistance or special accommodations.
Timely Action on Important Matters: Citizens need to act quickly on important issues. Physical mail can take up to a week for a round trip, delaying responses and potentially causing anxiety or stress for citizens. For the government, this leads to longer service delivery and issue resolution times.
Confirmation of Receipt: Government departments need to confirm that citizens have received communications, as this could affect their responses.
Anything else
Denmark has had a citizen mailbox since 2007 using a standard inbox design pattern and currently, the paradigm is being tested in Scotland.
What
Inbox design patterns for mail or notifications are common in commercial applications. The most pervasive patterns are a three-panel fluid layout for large & medium-sized screens and tabbed navigation with card components representing discrete messages for mobile.
We're testing the possibility of a cross-government inbox pattern to enable more rapid communication between departments and citizens.
Several components within the design system could be used to build an inbox-type experience. Modern inbox patterns are quite complex, setting a high standard for user interaction. Similar to driving a car—which is complex but, once mastered, offers significant benefits—these inbox patterns may not be easy or intuitive at first (or even accessible). However, their continuous development and widespread use have made them the standard way to manage complex tasks.
Why
Design System
Even though this will not be a reusable component it could be a keystone design pattern that connects to, possibly impacting, other patterns within the design system. This needs consideration from the design system community and input from other research and experiences.
Depending on the level of service integration into the inbox, many of the existing Design system components will be used including form design components and general service interactions.
Some related patterns would be
And has the potential to impact some existing patterns changing them altogether
There may also be existing inbox patterns that have been designed and tested internally for civil servants and gov departments that we can learn from when designing for a wider group of users.
Needs
The primary need is for citizens to receive communications from government departments that cover legal and functional requirements to implement policy. The government needs an official way to send these communications to individuals and organisations. Currently, this is done through physical letters sent to a mailbox at the person's residence, which is verified to be connected to their identity.
Although we have not yet researched the specific needs, we have a few initial assumptions that we will test during our work:
Anything else
Denmark has had a citizen mailbox since 2007 using a standard inbox design pattern and currently, the paradigm is being tested in Scotland.
This would connect and need to work with other Gov platforms
Additional related components and issues
Generalised patterns such as cards and lists will be relevant in this work
Mobile inbox patterns
Design History
A design history based on this work
https://github.com/alphagov/gov-mailbox-design-history
Figma file exploring the pattern
Figma file examining the inbox pattern
https://www.figma.com/design/zOdvURuLtLklNjP2f7zun0/GDS-Inbox-design-pattern-proposal?node-id=0-1&t=YTftxtJJQa2NG28c-1
GDS Inbox pattern.pdf
The text was updated successfully, but these errors were encountered: