Asking for information plays a key part in our customers’ experience with British Gas. All functional journeys include elements of data capture and asking a customer to make a choice. Grouping questions, information, and choices together in logical and relatable sections can make our experiences as intuitive as possible.
lakeside variant of the
ns-landmark, is ideal for introducing and framing your pages. It is non-decorative, therefore reducing the distraction. It supports a sub-heading and heading, along with a single paragraph. You can use this to signpost the journey, and frame the context of the information you are asking the customer for.
Further research: We are currently researching the use of
labels as headings, with the view that you would not need to use an
ns-landmark to start each page.
ns-form component is a wrapper used to contain all your form controls. It’s primary purpose within the design system is to manage the validations of your form controls. Semantically it sits at the top of the hierarchy.
ns-form-group component is an element that sits directly in an
ns-form. We use the
ns-form-group to help group form controls such as inputs, radios, and checkboxes. Within the
ns-for-group there is a
legend attribute - this can help describe the form controls and provide context to the customer.
It is unnecessary to use the
legend when presenting the customer with a single input field relating to one piece of information.
As expressed in the journey patterns documentation we advise that you approach each functional journey in the same way - breaking down the journey into smaller sections, asking the customer a single question or group of questions at a time. The idea is to reduce the cognitive load and help a customer complete what they need to do as efficiently as possible.
Grouping questions together thematically can help a customer understand the context and objective of what you are asking.
Radio buttons and checkboxes should be grouped in their own respective form groups. The
legend attribute should be used to provide context to the choice(s) a customer is being asked to make. Each form control should use their own label as the answer.
ns-inputter component is a multi-purpose wrapper component for displaying form controls such as text inputs, radio buttons, and checkboxes. The component has a number of features that allow for things such as validation, masking, and formatting.
ns-inputter component is capable of supporting the following common types of information you might ask a customer for:
- Telephone numbers
- Email addresses
Along with these, you can use a combination of validation, mask, and separator to ask the customer for more complex information such as:
- Meter reads
- Sort codes
- Reference numbers
Further research: We are currently developing pattern documentation for the use of these patterns, by doing this we look to ensure that there is a consistent approach to asking customers for this information across customer journeys.
These are extremely common form control elements used to ask customers to make choices from a small list of options, or to answer simple yes/no questions, or to toggle a single option on or off.
Radio buttons and checkboxes are usually the answers to a question asked in the
heading attribute of the
ns-inputter - such as "Are you a British Gas customer?" or "Which British Gas services would you like to choose?".
- Do you have insights or concerns to share? You can raise an issue via Github bugs.
- See all the issues already raised via Github issues.
💩 🎉 🦄 If you have any questions, contact us on Microsoft Teams in the Nucleus Design System channels.