Lifecycle of a component

This section covers the ideal life cycle of adding a new component or improving an existing component - from specification to its release in GDS.

1. Verify necessity

There are plenty of different possibilities for the need of a new component (or improvement of an existing component) in George Design System (GDS). Usually – but not necessarily always – this need is discovered by a designer or business analyst (BA).

HINT Obviously, the earlier the need for a new component is discovered, the better!
It is the duty of a squad’s BA, to check (with the help of the squad’s designer, if necessary) any new user-facing squad ticket for needed GDS components as missing components might increase the complexity of the squad’s ticket.

1.1 Cross-check for existing (planned) components

Before specifying a new component, cross-check if an existing component is similar or even meets your requirements or if there is already a Jira ticket for the same component.

2. Align design

Before a component can be specified in a Jira ticket, alignment within the Design Chapter has to take place to guarantee consistency and reusability for other squads.

2.1 Alignment for George designs

A squad designer has to align their designs with their cluster lead designer and in case of new requirements for a(n existing) GDS component with the web design lead of George.
HINT Take a closer look at the processes around design alignment and GDS.

2.2 Alignment for country-designed George features

A country designer has to align their designs for George with the responsible cluster lead designer at George Labs.

2.3 Alignment for George Store designs

A store designer has to align their designs with the George store designer of George Labs.

2.4 Alignment for any other topic using GDS components

If you are designing any other feature using GDS components, please reach out to the central design team at George Labs for alignment and approval of your designs.

3. Specify

Usually, it is the task of a squad’s designer to specify a component (responsive behaviour, accessibility, …). Find out more under Issue Tracking.

4. Prioritise

Every second sprint (=every four weeks) the Design System squad has a prioritisation meeting with the Design Chapter to decide on the priority of component related tickets and commits to implementing a number of tickets within the next sprint based on priority and available capacity.
All other tickets stay in the backlog or have to be implemented by the individual feature squads.

4.1 Prepare for the prioritisation meeting

Every Monday the Design System Squad estimates recently added Jira tickets. Only tickets that have been fully specified by the individual squad designers can be taken into account.

5. Develop

If a component is developed by a developer of a feature squad, it might make sense to align upfront with a developer of the Design System Squad to avoid unnecessary steps.

6. Open pull request

Once a component is considered by its developer as ready, the developer makes a PR against the GDS.

7. Merge

Once a pull request gets approved by the Design System Squad, it gets merged to GDS.

8. Release

Usually, every two weeks, the Design System Squad releases a new version of the GDS that includes recently merged components.
The changelog of every release is available in the GDS itself.

9. Upgrade George Web

Once a new version of the GDS is released, it gets (manually) picked up by a feature squad developer and merged to the George Web repository to make it available for all web developers of George. This is usually handled by the Impressions Squad.