Updated October 2026.

Design thinking is a structured, human-centred approach to problem-solving that starts with the people who will use a solution and works back to the solution itself. It begins with what people actually need, then asks what technology can do to help. The result is solutions that work in daily use as well as on paper.

In SAP, design thinking is the methodology behind SAP Fiori, the SAP AppHaus Network, and a growing share of how SAP implementations and extensions are planned before they are built. In this guide we cover what design thinking is, how it changes the way an SAP project runs, the five stages in practice, how it pairs with Architecture Thinking, and when it adds the most value.

What is Design Thinking?

Design thinking can sound like one of those vague workshop terms that sits alongside “synergy” and “blue-sky”. It is more concrete than that, and an example shows why.

Imagine you are a 14th-century German craftsman. You want to sell more books, but there are not enough literate people to copy the text for you. The obvious answers are to train more copyists, improve the ink, or pay existing scribes to work faster. All of them treat the symptom: not enough copies being made.

A design thinker looks at the problem differently. The real constraint is the speed at which text can be replicated. That shift in how the problem is defined opens up a completely different set of solutions, and eventually leads to the printing press. That is design thinking: reframing the problem until you find the one worth solving.

In practical terms, design thinking is a structured method that combines understanding users, quick prototyping and repeated testing to produce solutions people find useful. It is used when a team needs to create something new, solve a complex problem, or improve an experience in ways that standard requirements-gathering tends to miss.

Why SAP Projects Can Go Live on Time and Still Fall Short

Most SAP projects run in a familiar order: gather requirements, configure, test, train, go live. End users often meet the new system for the first time in training, a few weeks before go-live. By then the design is fixed, and anything that does not suit how they work becomes a change request or a workaround.

The project can hit every technical milestone and still struggle on adoption, because the people who use the system every day had little say in how it works.

Design thinking changes the order. Users are involved from the first week. The problem is agreed before any solution is designed. Prototypes are tested with real users before anything is built. Problems surface while they are cheap to fix, well before go-live.

Design Thinking in SAP and Enterprise Software

Enterprise systems like SAP are built to cover every step of a business process completely and correctly. A single end-to-end process can span several screens, each showing a broad set of fields so that every possible case is covered. For any one user doing one task, most of those fields are irrelevant.

Design thinking changes the question. Instead of “what can the system do?”, it asks “what does this user need to do, and what would make it as simple as possible?” That produces different outcomes: Fiori apps that are role-specific and task-focused, Screen Personas flavours that simplify existing transactions without changing the underlying code, and BTP apps designed around how people actually work.

The impact is measurable. When users can complete their daily tasks in a system that works the way they expect, adoption goes up, error rates come down, training costs fall and the organisation stops paying for workarounds. User adoption is one of the biggest factors in whether an SAP implementation delivers its business value, and design thinking is the most direct way to improve it.

The SAP AppHaus Design Thinking Process: Five Stages

The SAP AppHaus approach to design thinking follows five stages. Generic design thinking frameworks are taught widely in academic and creative settings. The AppHaus model is built specifically for enterprise technology projects: it accounts for how SAP systems are structured, the governance needs of enterprise IT, and the need to deliver working solutions as well as ideas.

The stages do not always run in strict order. What you learn in a later stage often sends you back to an earlier one. The process is meant to repeat.

1. Explore

The Explore stage establishes the opportunity. The team identifies the business problem or improvement area, sets the scope of the work and defines the groups of users whose experience is at stake. The focus here is making sure the right problem is being tackled before any design work begins.

A manufacturer noticing that its inventory process produces frequent errors has a symptom. The Explore stage finds the cause. Is it data entry, system navigation, missing information or the process itself? The answer decides what the design effort should address.

2. Discover

The Discover stage builds a deep understanding of the users involved: their daily tasks, responsibilities, frustrations, workarounds and the moments where the system lets them down. This is done through questionnaires, observation sessions, interviews with a representative mix of users and, for some teams, hands-on techniques like LEGO Serious Play. The findings are turned into personas: named, human profiles that summarise real user data.

Personas are built from real information gathered from real users. They keep the design team focused on people throughout the rest of the process. A well-built persona represents a genuine user type with genuine needs, and the team checks back against it at every later stage to make sure the solution still serves the people it is for.

How personas shape what users see in SAP

In a Fiori project, personas also decide how the launchpad is built. Each persona maps to a business role. Each role gets the apps, tiles and pages its tasks need, and nothing else. A warehouse operative and a finance controller log in to the same system and see two different, focused workspaces. Skipping this step is one of the most common reasons a Fiori rollout feels cluttered, because users see every app they have access to instead of the handful they actually use.

3. Design

The Design stage turns what was learned in Discover into a visible, testable solution. It starts with simple tools: sketches, wireframes and shared boards where ideas can be tried and dropped quickly without the cost of full development. The prototypes become more detailed as the design settles, ending in clickable versions that users can try and comment on before any production code is written.

In SAP projects, this usually means prototyping in SAP Business Application Studio using SAPUI5, so the prototype behaves like the final application. Specialist UX tools, including eye-tracking software, show exactly how users interact with a prototype: whether they find the right element, whether the workflow makes sense, and whether there are cases the design has missed.

The principle is simple. Finding a problem in a prototype is faster and cheaper than finding it in a live system. Every design decision a user validates before the build is rework avoided afterwards.

4. Deliver

The Deliver stage turns the validated design into a working solution. Development runs in short sprints, so different parts of the project can progress at the same time and be adjusted as they go. Testing is thorough before deployment, and it measures the solution against the user scenarios set out in Discover as well as technical acceptance criteria.

5. Run and Scale

The Run and Scale stage puts the solution live and extends it across the organisation. This is where the value of design thinking shows: a solution built around real user needs, with users involved throughout, is one people actually use. And a solution people use delivers the adoption and productivity gains that justified it.

Running and scaling also includes aftercare: handling change requests as users meet new situations in live use, and deciding whether to extend the solution to more users or processes.

A Design Thinking Project in Practice

The five stages are easier to picture with an example. This scenario shows how a design thinking project might run from start to finish.

The situation: A logistics and delivery company is struggling with resource management. Managers cannot easily see which drivers are available at any time. That information sits in individual spreadsheets, updated monthly and combined into a master version. Leave and sick day requests arrive by email, need manual approval, and then need another manual update to the spreadsheets. The process is slow, error-prone and does not account for drivers in different countries with different national and religious holidays.

Explore: The team establishes that the information exists. The problem is that it is fragmented, maintained by hand and out of reach in real time for the people who need it. The scope is set: a resource visibility and leave management solution for drivers and managers.

Discover: Questionnaires and interviews show what users need. Drivers want to check their remaining leave, submit requests quickly from their phone and hear back promptly. Managers want one current view of their team’s availability, an efficient approval workflow and automatic updates to the scheduling team. A driver persona is created: Paul, 45, an HGV driver with two children, who needs to book leave around school holidays and cannot wait weeks for approval while prices rise. Approved leave has previously not reached the scheduling team, so he has been rostered on days he had booked off. He finds the process frustrating, and refusals with no explanation demoralising.

Design: Paul’s persona and matching manager personas are used to design a role-specific app. Prototypes are built in SAP Business Application Studio and tested with Paul and his colleagues before any production build begins. Eye-tracking sessions show that a key navigation element is not where Paul expects it. The design is adjusted before the build starts.

Deliver: The app is built in sprints and tested against the scenarios from Discover. Paul can now see his remaining leave instantly, submit requests in one step from his phone and get a push notification of the decision with the reason. Managers get a real-time team availability dashboard and an automated workflow that passes approved leave straight to scheduling.

Run and Scale: After a successful rollout to the first group of drivers, the solution is extended across the whole operation. Paul tells other drivers how much easier it is. Adoption spreads on its own because the solution was designed around Paul and the people like him.

For a real example of this approach, see our case study on simplifying warehouse management with SAP UX.

When Design Thinking Adds the Most Value

Design thinking is worth the most where the risk sits with people more than technology:

• Large S/4HANA moves with many users. The more people whose daily work changes, the higher the adoption risk.
• Custom apps on BTP. There is no standard SAP screen to fall back on, so the design has to come from the users.
• Processes being redesigned. If the way the work is done is changing, users need to shape the new process along with the screens.

For a purely technical change, such as a database upgrade with no visible change for users, a light touch is usually enough.

The Business Case for Design Thinking

Design thinking pays back in measurable ways, and the return builds over time. The most direct measures are adoption rate, error rate and training cost. A system users find easy to navigate is adopted faster, used more correctly and takes less training for new starters.

The less visible measures matter just as much: the costs it removes. Every workaround a user creates to cope with a hard-to-use system takes time and attention away from productive work. Every spreadsheet kept alongside the official system is a source of inconsistent data and compliance risk. Every process that runs on email because it is easier than running it in SAP has no audit trail, no reporting and no governance.

Design thinking improves user satisfaction and also removes the costs that build up quietly when a system is hard to use. The day-to-day cost of systems that are hard to use is covered in our guide to why enterprise UX matters.

Design Thinking and the SAP AppHaus

Bluestonex is one of 19 SAP AppHaus Network partners worldwide, and one of two in the UK. The AppHaus approach pairs Design Thinking with Architecture Thinking, so every solution is built around users and grounded in the SAP landscape it has to run in. As a network member, we run design thinking engagements using SAP’s methodology and the full AppHaus toolset.

Design Thinking and Architecture Thinking

A design that users love but cannot be built does not help anyone. That is why our projects pair design thinking with Architecture Thinking from the start.

While the design team works with users, our architects check each idea against the real landscape: which data the app needs and where it lives, which SAP APIs can provide it, whether the logic belongs in S/4HANA or as an extension on BTP, and how it stays within clean core principles. The two run side by side, so the prototype users test is one we already know we can deliver.

Our SAP workshops

We run SAP workshops at our AppHaus in Oswestry and virtually, depending on where your team is. The line-up covers BTP discovery, AI use cases, app development, Integration Suite discovery and process discovery, with bespoke workshops for anything else. Design thinking and UX are built into all of them. You go from a defined problem to a tested prototype, so any build starts from something your users have already tried.

Frequently Asked Questions

What is SAP design thinking?

SAP’s version of design thinking, used by SAP and the AppHaus Network to plan SAP projects around users. It runs in five stages, from Explore to Run and Scale, and is paired with Architecture Thinking so ideas stay buildable.

How is design thinking used in SAP projects?

Design thinking makes sure extensions, Fiori apps and BTP solutions are designed around real user needs before development begins. The typical approach follows the five AppHaus stages, from user research and personas through to prototype testing and delivery in sprints. The result is higher adoption, fewer change requests after go-live and solutions that deliver the outcomes they were designed for.

Is design thinking only for UX projects?

No. We use it for integration, automation and AI use cases as well, because each of them changes how someone works.

What is the difference between design thinking and traditional software development?

Traditional development starts with a requirements specification and builds to it. Users’ needs are captured at the start and tested at the end. Design thinking involves users throughout: needs are checked continuously, prototypes are tested before the build, and the design changes based on what real users say and do. The main difference is when problems are found. With design thinking, they surface during design, when they are cheap to fix.

How long does a design thinking workshop take?

A focused workshop covering the Explore and Discover stages can be done in one to two days. It produces an agreed problem definition, user personas and a clear scope for the design stage. A full engagement covering all five stages takes longer, depending on how complex the solution is and how many user groups are involved. Our SAP workshops page sets out each workshop and what it covers.

Final Thoughts

The printing press was not the obvious answer to selling more books. It took a complete reframing of the real problem. Design thinking does the same in SAP projects: it puts a pause before the build, makes sure the right problem is found before a solution is designed, and produces systems people adopt because they were designed with them.

If you are planning an SAP implementation, extension or UX programme, an SAP workshop is the simplest place to start. We will frame the problem with you, meet the people it affects and agree a tested direction before any build begins.

Modern design thinking has roots that go back hundreds of years. Read our tribute to one of its earliest pioneers.