Design-Led Development in S/4HANA, ICD, and DSC
Discover / SAP Products / SAP S/4HANA Only / Design-Led Development in S/4HANA, ICD, and DSC
Intro
The design-led development (DLD) process for S/4HANA, S/4HANA Industries (formerly known as ICD), and Digital Supply Chain (DSC) aims to equip every design project with appropriate user research and interaction design support. It serves to improve collaboration between application UX, product management (PM), product owners (PO), development teams, and SAP UX.
The new process strengthens the role of the project teams in UX related activities. It is also more flexible, and can cater for different development constellations, such as monthly delivery.
Basic Setup
The DLD process centers on design projects with a defined design project charter. The design project team is responsible for the UX quality, which is reviewed in a mandatory UX quality check.
Members of the application design teams in the product organization walk the product teams through the DLD process and perform design activities for clearly-prioritized design projects.
- Design project
Design projects focus on a cluster of UX backlog items, rather than single apps. Each design project is categorized as an A, B, or C project, depending on its reach and importance. Design projects take a more holistic view of end-user roles and processes. - Design project charter The purpose of the design project charter is to gain a common understanding of the functional scope, user research needs, interaction design needs, project budget, and staffing.
- Design project team The design project team consists of members from the product area (PO, PM, UX advocate, user assistance developer, etc.) and from application design teams (application designer, design lead/hub lead, and user researcher). The members of the project team can vary depending on the design project category.
- UX quality check
All design projects are subject to a mandatory design review, known as a design gate (or D-Gate). Members of the application design teams are responsible for carrying out the D-Gates.
Process Overview
The DLD process involves the following main steps:
- A design project is planned and categorized as an A, B, or C project.
- Fill out the project charter and request the mandatory Design Project Charter Meeting (see details).
- As soon as your design project is fully staffed and ready to start, continue with Discover / Design / Implement phases.
- Request the mandatory D-Gate (see details).
- Implement any necessary changes.
- Ready for delivery! (responsible application UX sets “sign-off” flag in OAM).
Planning, Project Setup, and Commitment
During the planning and setup phase, design projects are identified and categorized. Every design project creates a design project charter and agrees on it during the Design Project Charter Meeting.
Design Project
After the regular portfolio and release planning meetings, all UX-related backlog items are grouped into coherent design projects. Items can be clustered based on affected end user roles, along end-to-end processes, or by functional area (for smaller renovation topics or app improvements).
Every design project identified needs to be categorized as an A, B, or C project.
A-projects
If one or more of the criteria below apply, the project is a potential candidate for category A.
The solution/functionality:
- Will be used by multiple roles or many end-users
- Is the primary solution for at least one role (“8h usage”)
- Addresses complex functionality to realize a key business process not yet supported
- Is often mentioned in sales pitches (“lighthouse app”)
- Is a critical differentiator in the market
- Is intended to replace a solution that important customers complain about
- Constitutes a unique selling point
C-projects
If one or more of the criteria below apply, the project is a potential candidate for category C.
The solution/functionality:
- Is seldom used by only a small number of end users
- Is used to configure the SAP product
- Is a minor enhancement to an existing app that does not substantially change the end user flow
- Is very similar to an existing app or function with only minor differences.
B-Projects
Projects that don’t fall under A or C are handled as B-Projects.
The category of a design project mainly affects the staffing of UX personal and the time and effort for user research. A design project with category A is supposed to do extensive user research and will be assigned an application designer, a user researcher (if resources permit) and a personal contact in SAP UX Design to address directly any emerging new design patterns or guideline conflicts. In contrast, a design project with category C is unlikely to do extensive research. The design project charter caters for these differences.
Project Charter and Design Project Charter Meeting
As soon as your design project is defined and categorized, create a new issue with the type “DLD Design Project” in the Jira project DLDUXPLAN, representing the project charter. Follow the detailed how-to guide. In the Design Project Charter Meeting,the project charter is signed off by application UX, product management, and the product owner. A UX coach will schedule the meeting and participate to ensure consistent quality across the project charters. To request a meeting, set the corresponding status for the DLD Design Project in Jira.
To prepare for the meeting, we recommend:
- Collecting and reviewing all available design artifacts up front (persona, use cases, user stories, and so on)
- Gathering as much information as possible about the project in order to agree on the necessary user research investment
As soon as all stakeholders have agreed on the project charter, and the design project is staffed, you can start with the discovery phase and request a Fiori ID (if needed). Before you request a Fiori ID, create an entry in the Fiori App portfolio to register your app. Follow the guidance provided in the wiki. After registering your app, use the email template provided in the DLD repository to request a Fiori ID.
Explore
As described in the general Design-Led Development Process article, this phase focuses on understanding business challenges and exploring innovation opportunities. These activities are part of the product roadmap definition. In order to closely collaborate with customers in this phase, EMMI (Exploratory Multidisciplinary Method for Innovation) provides a proven methodology. Usually, the explore phase is only relevant for A-projects.
Discover
As described in the general Design-Led Development Process article, this phase is all about understanding the customer and their end users’ needs. Document the insights you gained and use them in the design phase. This is extremely important to ensure a high-quality user experience. Your product and your end users will benefit hugely from the effort you invest at the beginning of your project.
Research Checklist
As soon as the team has a a coherent, documented, and up-to-date understanding of the end users and their context, your research has been successful and you can start the project. The proof point for this understanding is your ability to give documented answers to the following questions:
- What are the tasks and working context of the users? (Which steps does the user have to perform in what sequence? What does the data flow look like? What is the working environment like?)
- What pain points do the users have?
- How do your end users interact with other users?
- What quality goals and deadlines do users have to meet? When are they satisfied with the outcome?
Your knowledge has to be based on direct contact with end users. Several customer contacts for different industries and/or countries increase the data quality significantly.
For documentation purposes, we recommend using best practice templates for personas, use case diagrams, user stories, and so on.
Consider the following additional questions during your research:
- Are there ideas on how to integrate innovative solutions for this role (such as AI, ML, or the Situation Handling framework)?
- Do you know of any functional gaps?
- Are there any interaction breaks within the app or process?
- Do you know the corresponding E2E process, and how your end users are involved in it?
- Are you aligning with other teams working on this role?
Take a look at our user research method cards to find the best method for your user research activities.
For more information on user research, see:
- User Research @ SAP (SAP Jam)
- User Research-Led Design (SAP Jam)
Step
01
Prepare
Collect any existing material available (personas, use cases, previous user research reports, and so on). This will help you to find out which questions from the research checklist you can answer and which need more user research.
Step
02
Conduct
Plan and conduct user research with end users at different customers. Make sure to plan and organize well ahead.
Common methods for conducting research in the “Discover” phase are observations of the user workflows at their workplaces, contextual or remote user interviews to uncover any unknown end user needs and pain points, and/or workshops.
In the current situation, where no customer-facing events are possible, Mural can be a helpful tool to support interviews and/or workshops. If you lack access to end users, consider using the recruiting tool Respondent.io, if applicable in your area.
Step
03
Understand
Document your insights using best practice documents, such as persona, use case diagram, or other templates, depending on your needs (find all templates here). Store those documents in the Role Repository. All existing role documents from BUILD are going to be exported to this repository.
Step
04
Handling New Roles (optional)
If your research results indicate that you need a new business role, you have to request a new role. The minimum set of documents required to create a new business role are a persona description and documentation of the end user involvement. Feel free to use the document templates provided. Store the documents on the Role Repository in a new folder and name it according to this pattern “<role ID> <role name>”, e.g. “R006 Accounts Payable Manager”. Full guidance on how to request a new role is provided in this wiki.
With this knowledge base, you are well-prepared for the design phase. If you believe that user research is not being conducted to the extent it should be in your project, address this to your assigned designer or design lead.
Design
The goal of the design phase is to produce an initial design based on the findings from the discovery phase. For best practices and templates, see the general Design-Led Development Process article. Make sure that your designs are aligned with the SAP Fiori design guidelines and the product consistency rules.
To facilitate collaboration with Fiori design concepts team, SAP UX offers support via the Fiori design community, as well as consultation hours for design projects.
Implement
The goal of the develop phase is to implement the design and create a desirable product. A design project can include the implementation/extension of one or more apps.
In this phase, we conduct a mandatory D-Gate for the design project to ensure compliance with the SAP Fiori design guidelines and UX product consistency standard. The major part of the review is a product demo by the product owner or substitute from the development team.
Flow of the Development Phase
Step
01
Deliver
Complete the implementation of your design project. If you use SAP Fiori elements, check out the info box above.
Step
02
Prepare a demo
Be prepared to demo your product to the reviewers and provide a URL to a working system in advance.
Step
03
Request D-Gate
First, check if the DLD repository contains specific instructions for your design hub. If there are none, clarify with your design lead (hub lead) who is responsible for organizing the D-Gate meeting: it’s either the person responsible for the product or the person responsible for the design (UX designer or UX advocate). Feel free to use the templates provided to ask for a meeting via email or to create a meeting request directly. Either way, add the URL to the “demo” system you have prepared.
Step
04
Meet and Review
Regardless of who sets up the meeting (see step 3), the person responsible for the product presents the applications developed in your design project. Two application designers conduct the review and give feedback. The review results are documented during the meeting.
Step
05
Decision Based on Review Results
Depending on the outcome of the review, the reviewers set a D-Gate status:
- Signed Off: No issues were identified, or any issues have been fixed.
- Corrections Pending: Issues were identified during the review, but are expected to be fixed for the current release.
- Signed Off with Mitigation Plan: Issues were identified that are primarily due to current technical limitations. In this case, backlog items must be created to ensure the issues are resolved in upcoming releases.
- Rejected Sign-Off: In the unlikely event that there is no mitigation plan in place for the identified issues, the reviewers set the status to Rejected Sign-Off. In this case, exception handling for shipment without UX sign-off is with the CPO.
- Run and Scale: During this phase we collect feedback from end users based on real-life usage as an input for further improvements.
FAQ
What is a design project?
After the regular portfolio and release planning meetings, all UX-related backlog items are grouped into coherent design projects. Items can be clustered based on affected end user roles, along end-to-end processes, or by functional area (for smaller renovation topics or app improvements). We recommend to consider which functionalities you would like to see together in a D-Gate later in the process.
Every design project identified needs to be categorized as an A, B, or C project. Find some guiding questions in the Planning, Project Setup, and Commitment section.
When do I fill out the project charter?
In general, you can fill out the project charter after the portfolio or release planning as soon as design projects are defined. Create a new issue of type DLD Design Project in the Jira project DLDUXPLAN representing the project charter. Follow the detailed how-to guide. Be aware that projects with bigger open research questions (mainly A and sometimes also B category projects) should be considered already at least one release before planned development to allow for planning and organizing customer visits to conduct user research with end users.
How to request a design project charter meeting?
As soon as your design project is defined and categorized, create a new issue of type DLD Design Project in the Jira project DLDUXPLAN representing the project charter. Follow the detailed how-to guide.
To prepare for the meeting, we recommend:
- Collecting and reviewing all available design artifacts up front (persona, use cases, user stories, etc.)
- Gathering as much information as possible about the project in order to agree on the necessary user research investment.
After this preparation you can request a Design Project Charter Meeting by setting the Jira issue into the corresponding state. You will be invited to a meeting by the UX coaches.
As soon as all stakeholders have agreed on the project charter and the design project is staffed, you can start with the discovery phase and can get a Fiori ID assigned (if needed). To request a Fiori ID, use the email template also provided in the DLD repository.
How do I get a Fiori ID?
As soon as all stakeholders have agreed on the design project charter in the Design Project Charter Meeting and the design project is staffed, you can start with the discovery phase and can get one or several Fiori IDs assigned (if needed). To request a Fiori ID, use the email template also provided in the DLD repository. Please also visit the wiki page “How to request Fiori IDs” to get details on exceptions for certain UI technologies.
Can I review my designs before starting implementation?
If you have just a few questions regarding applying the guidelines, reach out to the Fiori design community. We encourage you to also consider doing informal reviews with your peer designers and within your product areas.
How and when do I request a mandatory D-Gate?
As the D-Gate is conducted on the implementation, it should be scheduled well before development close, so that you can adapt according to the reviewer’s feedback. To request a D-Gate, contact your design hub lead or application UX contact and provide a links to the implementation and to your project charter. The hub lead / application UX will set up a meeting accordingly. You can use the templates provided in the DLD repository.
For which UI technologies (e.g. reuse components) does the DLD apply?
Please find all corresponding information here.
What is the difference between DLD and EMMI?
EMMI provides a proven methodology for conducting category A projects within the design-led development process, putting an explicit focus on end-to-end multi-customer collaboration and a multidisciplinary project team.