Intro

This guide focuses on the InnerSource process of contributing or requesting components or features to the SAP Design System, specifically for CX. The SAP Design System evolves through collaboration. For CX teams, contributing to or requesting changes is not just a formal step, it is a way to ensure that CX-specific needs are considered early, consistently, and sustainably into our SAP Design System.

This guide explains what you need to consider when:

• Requesting new requirements to existing UXC components, or
• contributing new components (including ownership)

This guide helps UX designers navigate the process early, intentionally, and with the right expectations.

Request vs. Contribution

Before starting, decide which path applies:

Beforehand: Always Check First

Before creating a request or contribution, always follow the steps below:

Check Whether the Component or Request Already Exists

• Check the internal Design System components (it is important that the internal design system is checked)
• Look for similar patterns or foundations
• Check open tickets in Jira
• Avoid duplicates and consolidate where possible
  
  Design System Jira Board
  
  Design System Components

Review Ownership

• Identify which team owns related components
• Understand whether extension is possible
  
  Ownership List

Timing Is Critical: UXC Components

For requesting updates to UXC components, timing is critical.

Golden Rule: Submit requests at least 6 months before the next UXC planning cycle!

Why:

• Design owning teams plan capacity well in advance
• Late requests are often deprioritized. Not because they are not important, but because they arrive too late

Who Can Request or Contribute

Before submitting a request, we recommend first consulting with the CX Design System Expert (CX: to be hired). Discuss your ideas together and get input. This step is important to ensure product-area alignment by aligning with allowed requestors, that keep the perspective across the area. Without the confirmation from the expert, a request can’t be processed. If the expert agrees with your assessment, you can proceed to create your request.

Ensure product-area alignment by:

• Check the allowed Requestors List
• Align with your UX Design Lead and Design System Expert (CX: to be hired)
• Make sure to get confirmation from your expert

Well-aligned requests move faster and have higher chances of success! ^_^

How to Request (Updates To Existing Components)

What A Good Request Focuses On

A strong request explains:

• The problem statement in context of a user’s (or customer’s) perspective
• Why existing components are insufficient
• Use Case and Product's demo system
• Potential impact if not addressed

Avoid:

• Product-specific hacks framed as system needs
• Requests without broader relevance
• Only sending a proposed solution for the issue itself

Here you can find an example of a good request.

Checklist: Requesting A Component Change

Before submitting:

• Check if an existing component already solves the need
• Review similar requests in Jira
• Confirm you are an allowed requestor or aligned with one
• Align with Design Lead and CX Design System Expert

Submitting the request:

• Create a request via the InnerSource process in Jira
• Provide a clear problem statement of a user’‚ perspective and CX context
• Product area defined
• Stakeholders identified
• Impact and urgency explained
• Optional: early concepts or references

How to Contribute (A New Component)

Contributing a component is a long-term responsibility, not a one-time request. With contributing a component, you’ll be the Owner of that component.

What Ownership Means

• Maintaining and evolving the component over time, which usually spans years and includes all future theme updates and new themes
• Ensuring quality, accessibility, and documentation
• Responding to future change requests
• Aligning with system-wide updates

Ownership Does Not Mean

• You control the component in isolation
• You design it once and walk away

Checklist: Contributing a New Component

Before proposing:

• Confirmed that no existing component, pattern or concept fits
• Validated reuse beyond a single product
• Aligned with the CX Design System Expert
• Team is willing to take ownership

Contribution phase:

• Create a contribution via the InnerSource process in Jira
• Follow the Step-by-Step Instruction
• Document specifications (Figma) by following the article on Design Quality
• Consider accessibility, globalization, and UX quality from the start
• Clarify and list ownership

Roll-out of component:

• Design guidelines updated or written
• Component published and communicated
• Ownership maintained over time

Temporary Ownership

You can also assume temporary ownership if you request a feature from an element that has no owner. Instead of being blocked or hoping for someone else to pick up your request, you can step up and take responsibility.

You will specify and implement the specific feature together with the UI technology team and respond to any follow-up questions that are specifically tied to that feature.

Design Quality, Sign-Off & Standards

All requests and contributions must meet SAP Design System quality expectations, including:

• Design Quality
• Accessibility
• Globalization
• UX consistency
• User Assistance standards

Design sign-off is mandatory and confirms:

• Quality
• Completeness
• Compliance with standards

Find more information check out Product Standards and Design Quality Checklist.

Full Process & Status

While this guide focuses on decision-making and expectations, the detailed workflow lives in the official tools. Use the following resources as operational tools:

• Process Flow Graphic
• Jira Kanban Board
• InnerSource Dashboard
• InnerSource Sharepoint

Final Guidance for UX Designers in CX

• Submit early and thoroughly explain the problem to be solved, the context, and the entire product use case
• Only contribute new components if ownership is manageable