What is Design Thinking? A Guide for SAP and Enterprise Teams

Design thinking is a structured, human-centred approach to innovation and problem-solving that starts with the people who will use a solution and works backwards to the solution itself. Rather than beginning with technology and asking what it can do, design thinking begins with people and asks what they actually need. The result is solutions that work in the real world rather than ones that satisfy the specification but fail the user.

In SAP and enterprise software environments, design thinking is the methodology behind the development of SAP Fiori, the SAP AppHaus network, and an increasing share of how SAP implementations and extensions are designed before they are built. This guide covers what design thinking is, why bad design is such a costly problem in enterprise software, how the design thinking process works in practice, and what the SAP AppHaus approach looks like when applied to a real project.

What is Design Thinking?

Design thinking can sound like one of those vague, aspirational terms that belongs in a workshop alongside words like “synergy” and “blue-sky.” It is worth being clear about why it is not.

The best way to explain it is through an example. 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 solutions are to train more copyists, improve the quality of the ink, or pay existing scribes to work faster. All of these address the symptom: not enough copies being produced.

A design thinker looks at the problem differently. The real constraint is not the number of copyists. It is the speed at which text can be replicated. That shift in problem definition leads to a completely different solution space, and eventually to the printing press. That is design thinking: reframing the problem until you find the one worth solving, rather than building better versions of an inadequate solution.

In practical terms, design thinking is a structured methodology that combines user empathy, rapid prototyping, and iterative testing to generate solutions that are genuinely useful rather than technically complete. It is used when a team or organisation needs to create something new, solve a complex problem, or improve an existing experience in ways that standard requirements-gathering and waterfall delivery approaches do not surface.

 

Why Bad Design Is a Bigger Problem Than You Think

Good design is invisible. When a product, tool, or process works the way you expect it to, you do not notice the design. You simply get on with the task.

Consider the objects around you right now. A desk has to account for average user height, chair height, the weight and footprint of items typically placed on it, material durability, and adjustability. A keyboard has to match average finger size and handspan, key spacing, actuation force, and compatibility requirements. A water bottle has to hold enough liquid, be easy to grip, open easily while remaining watertight, and survive being thrown into a bag. None of these decisions are visible when they are made correctly. You simply use the thing.

Bad design makes itself felt. The desk at the wrong height. The key that sticks. The lid that leaks. You notice, you adapt, you work around it. The workaround costs time and attention, every single time you use the thing.

Now consider the software that enterprise users interact with daily. The SAP transaction that requires eight screens to complete a task that should take two. The workflow that forces a user to re-enter data that the system already holds. The report that can only be run by someone who knows the right transaction code. These are not edge cases. They are the daily reality for a significant proportion of SAP users in organisations that have never applied design thinking to how their systems are configured and presented.

The costs are practical and measurable. Users who find a system difficult to navigate restrict themselves to the narrow set of transactions they know well, missing functionality that would improve their work. Data entry errors increase when users are uncertain about which field applies to their task. Training costs are higher when the interface requires explanation rather than being self-evidently task-oriented. Shadow systems, spreadsheets, and email-based workarounds proliferate when the official system is harder to use than the informal alternative. None of this shows up clearly on a project budget, but all of it costs money, every day.

Design Thinking in SAP and Enterprise Software

SAP systems are particularly susceptible to the bad design problem. They were built for transactional completeness, not task simplicity. A single end-to-end business process can span multiple screens, each presenting a broad set of fields regardless of whether they are relevant to the specific user completing the specific task. The system is correct. The experience is not.

Design thinking addresses this by shifting the design question. Instead of “what can the system do?” the question becomes “what does this user need to do, and what would make it as straightforward as possible for them to do it?” That shift produces different outcomes: Fiori applications that are role-specific and task-focused rather than transaction-complete, Screen Personas flavours that simplify existing transactions without modifying the underlying code, and BTP applications designed around real user workflows rather than technical capability.

The measurable impact is real. When users can complete their daily tasks in a system that works the way they expect it to work, adoption is higher, error rates are lower, training costs are reduced, and the organisation stops paying for shadow systems and workarounds. SAP research consistently shows that user adoption is one of the most significant variables in realising the business value of an SAP implementation. Design thinking is the primary mechanism for improving it.

The SAP AppHaus Design Thinking Process: Five Stages

The SAP AppHaus approach to design thinking follows five stages. Unlike the generic design thinking frameworks widely taught in academic and creative contexts, the AppHaus model is specifically built for enterprise technology projects: it accounts for the architectural constraints of SAP systems, the governance requirements of enterprise IT, and the need to deliver functional solutions rather than conceptual ones.

The five stages are not always executed in strict sequence. Information gathered in later stages often informs a return to earlier ones. The process is iterative by design.

1. Explore

The Explore stage establishes the innovation opportunity. The team identifies the business problem or improvement area, sets the scope of the design thinking engagement, and defines the user populations whose experience is at stake. This is not yet about solutions. It is about making sure the right problem is being addressed before any design work begins.

A manufacturing company noticing that its inventory management process generates frequent errors has a symptom. The Explore stage investigates what the actual cause is. Is it data entry, system navigation, missing information, or a process design problem? The answer determines what the design effort should address.

2. Discover

The Discover stage develops a deep understanding of the users involved in the process: their daily tasks, their responsibilities, their frustrations, their workarounds, and the moments where the system fails them. This is done through structured methods: questionnaires, observational sessions, interviews with a representative cross-section of users, and the creation of user personas that translate real user data into named, humanised profiles.

Personas are not fictional characters. They are aggregations of real information gathered from real users, presented in a format that keeps the design team focused on the human dimension of the problem throughout the rest of the process. A well-constructed persona represents a genuine user type with genuine needs, and is referenced at every subsequent stage to sense-check whether the solution being developed actually serves the people it is being built for.

3. Design

The Design stage takes the understanding gathered in Discover and translates it into a visible, testable solution. It begins with low-fidelity tools: sketches, wireframes, and collaborative boards that allow ideas to be generated and discarded quickly without the overhead of full development. These prototypes become progressively higher-fidelity as the design stabilises, with clickable prototypes that users can interact with and provide feedback on before any production code is written.

In SAP projects, the Design stage typically involves prototyping in SAP Business Application Studio using SAPUI5, so that the prototype is not a design artefact but a functional representation of what the final application will do and feel like. Specialist UX tools, including eye-tracking software, can be used to observe how users interact with a prototype at a granular level: whether they find the right element, whether the workflow makes sense to them, whether there are edge cases that the design has not accounted for.

The principle is that it is faster and cheaper to discover problems in a prototype than in a delivered system. Every design decision validated by a user before the build phase is a rework avoided after it.

4. Deliver

The Deliver stage is where the validated design becomes a functional solution. Development proceeds in short sprints, allowing different areas of the project to be worked on simultaneously and progress to be tracked and adjusted continuously. Testing is thorough before handover to deployment: the goal is a solution that works correctly for the user scenarios established in Discover, not a solution that passes a technical acceptance test and fails in daily use.

5. Run and Scale

The Run and Scale stage deploys the solution to the live environment and extends it across the organisation. The value of the design thinking investment is realised at this stage: a solution built for real user needs with continuous user input is one that people actually use, and a solution that people use delivers the adoption and productivity improvements that justified the investment.

Running and scaling also includes aftercare: responding to change requests that emerge as users encounter edge cases in production, and evaluating whether the solution should be extended to additional user populations or additional processes.

A Design Thinking Project in Practice

The five stages above are clearer with a concrete example. The following scenario illustrates how a design thinking engagement 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 given time. That information lives in individual spreadsheets, updated monthly and reconciled into a master version. Leave and sick day requests arrive via email, require manual approval, and then require a further manual update to the spreadsheets. The process is slow, error-prone, and does not account for drivers based in different countries with different national and religious holidays.

Explore: The design team establishes that the problem is not a lack of information. The information exists. The problem is that it is fragmented, manually maintained, and inaccessible in real time to the people who need it. The design scope is set: a resource visibility and leave management solution for drivers and managers.

Discover: Questionnaires and interviews surface the user reality. Drivers want to check their remaining leave, submit requests quickly from mobile, and receive prompt notification of decisions. Managers want a single current view of their team’s availability, an efficient approval workflow, and automatic communication of approved leave to the wider scheduling function. A driver persona is created: Paul, 45, HGV driver with two children, who needs to book leave around school holidays but cannot afford to wait weeks for approval as prices increase with late booking. Paul has previously had approved leave not communicated to the scheduling team, resulting in him being scheduled to work on booked days. He finds the process frustrating and the lack of explanation for denials demoralising.

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

Deliver: The application is built in sprints and tested against the scenarios established in Discover. The delivered solution gives Paul instant visibility of his remaining leave, a one-step mobile submission process, and push notification of approval decisions with the reason stated. Managers get a real-time team availability dashboard and an automated workflow that communicates approved leave to scheduling without manual intervention.

Run and Scale: Following successful deployment for the initial driver population, the solution is extended across the full operation. Paul tells other drivers how much easier the process is. Adoption is self-reinforcing because the solution was designed for Paul, not for a generalised user type that does not quite match anyone’s actual experience.

The Business Case for Design Thinking

Design thinking is a worthwhile investment with measurable return, and the return compounds over time. The most direct measures are adoption rate, error rate, and training cost: a system that users find easy to navigate is adopted faster, used more correctly, and requires less training to onboard new users into.

The less visible but equally significant measures are the costs it removes. Every workaround a user implements to compensate for a poorly designed system represents time, attention, and organisational knowledge diverted away from productive work. Every shadow spreadsheet maintained in parallel with the official system is a source of data inconsistency and a compliance risk. Every process that runs on email because the system makes it too cumbersome to run inside SAP is a process that generates no audit trail, no reporting visibility, and no governance.

Design thinking does not just improve user satisfaction. It removes the costs that accumulate invisibly when systems are designed for technical completeness rather than human use.

Design Thinking and the SAP AppHaus

Bluestonex is a member of the SAP AppHaus Network. The AppHaus is SAP’s innovation methodology framework, combining Design Thinking and Architecture Thinking to ensure that solutions are both user-centred and technically grounded in the SAP landscape. AppHaus Network members are qualified to facilitate design thinking engagements using SAP’s methodology, in SAP’s framework, with access to the full AppHaus toolset.

In practice, Bluestonex runs AppHaus design thinking workshops both at our own AppHaus space and virtually, depending on the team’s location and preferences. A workshop takes an organisation from problem definition through to a tested, validated prototype of a solution, without the risk of building the wrong thing first.

Frequently Asked Questions

How is design thinking used in SAP projects?

In SAP projects, design thinking is used to ensure that extensions, Fiori applications, and BTP solutions are designed around real user needs before any development begins. The typical approach follows the five-stage AppHaus process, from user research and persona creation through to prototype testing and iterative delivery. The result is higher user adoption, fewer post-go-live change requests, and solutions that deliver the business outcomes they were designed for.

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

Traditional software development begins with a requirements specification and builds to that specification. The user’s needs are captured at the start and tested at the end. Design thinking integrates users throughout the process: needs are validated continuously, prototypes are tested before the build begins, and the design is adjusted based on what real users say and do. The primary difference is when problems are discovered: with design thinking, during the design phase at low cost; with traditional approaches, after delivery at high cost.

How long does a design thinking workshop take?

A focused design thinking workshop covering the Explore and Discover phases can be completed in one to two days and produces a validated problem definition, user personas, and a clear scope for the design phase. A full engagement covering all five stages runs over a longer period depending on the complexity of the solution and the number of user groups involved. Contact Bluestonex to discuss what is appropriate for your specific project.

Final Thoughts

The printing press was not the obvious answer to the problem of selling more books. It required a fundamental reframing of what the actual problem was. That is what design thinking does, in enterprises and in SAP projects: it forces a pause before the build, ensures the right problem is identified before a solution is designed, and produces outcomes that users adopt because the solutions were designed for them.

If your organisation is planning a SAP implementation, extension, or UX improvement programme and wants to apply the AppHaus design thinking methodology from the outset, Bluestonex can facilitate the process from initial problem framing through to validated solution design.

Believe it or not, the origins of modern design thinking goes back hundreds of years. Check out our tribute one of the origins of design thinking here.