Athletes

SAP RealSpend: Adoption Through ML

UX Design, AI, Mobile, Research

_

© 2018

Nanda Dias Design

© 2026

Nanda Dias Design

SAP RealSpend: exploring machine learning to drive adoption

SAP RealSpend: exploring machine learning to drive adoption

SAP RealSpend, one clear goal: grow manager adoption. Smarter integration into SAP's wider product suite, Concur among them, and early machine learning experiments got us there, well before the GenAI hype.

Chapter One: SAP RealSpend Anomaly Detection (2018 - Q1)

Managers approving cost center spending usually weren't trained in finance, so the real workflow was to find a controller and ask. That dependency was the actual problem: SAP wanted these managers using RealSpend directly, and adoption depended on making that possible. We had three months to find out whether machine learning could simplify that workflow, starting from a genuinely open brief where ML could have meant almost anything applied to budget monitoring. A structured exploration phase, scored against user pain, technical feasibility, business value and SAP's strategy, narrowed that field to three concepts by vote: anomaly detection, expense forecasting and smart tagging, not because we started there but because the team chose them. Only then came the harder question, the one we actually had three months for: which of the three was worth shipping. Neither side was on familiar ground: it was the first time our engineers had built with ML, and the first time our users had seen ML-generated content at all.


As Senior UX Designer, I worked alongside a Product Owner, a junior visual designer, and a team of backend engineers evaluating ML feasibility in parallel. My scope ran end to end: framing the problem, running ideation and paper prototyping (that is true, way before Gen-AI was around we used to paper prototype :)) designing and moderating every validation round, and synthesising what we learned back to the room, including the engineers who weren't in the sessions themselves.

Decisions and Actions

  • Ran that exploration as a structured ideation workshop, not an open brainstorm, so the four criteria did the narrowing rather than whoever argued loudest.

  • Built paper prototypes with the engineers directly, so feasibility debates and design decisions happened in the same room instead of getting lost in translation.

  • Designed and moderated three rounds of validation: an internal round measuring desirability, a second internal round with the same persona-matched experts measuring task completion and reaction to the concept, then external testing at SAP Sapphire / ASUG 2018 combining qualitative feedback with a formal SUS score.

Decisions and Actions

  • Facilitated co-creation workshops for ideation and problem-definition, so feasibility debates and design decisions happened with stakeholders in the room, not after the fact.

  • Built paper prototypes with stakeholders first, then moved to a high-fidelity interactive prototype in Axure once the direction held up, not before.

  • Wrote the validation questionnaires and moderated contextual inquiry sessions with manager-experts, to learn how approval decisions actually got made under time pressure, not how we assumed they did.

  • Once live travel data entered the prototype, our visual designer led the redesign of the master detail view and the line item table around that real data, not placeholder content.

  • Synthesised findings with our Product Owner before handing off a development-ready concept, so engineering inherited validated decisions, not open questions.

Every one of those decisions served one test: could a manager judge whether a travel request was risky at a glance, without being a finance expert? Integrated data visualisation and Co-Pilot's conversational help did that judging for them, while travellers got faster responses and better rebooking options whenever a request crossed budget. The flow that shipped: receive request, check current budget, ask clarifying questions, request extra budget if needed, approve.

Chapter One: SAP RealSpend Anomaly Detection (2018 - Q1)

Managers approving cost center spending usually weren't trained in finance, so the real workflow was to find a controller and ask. That dependency was the actual problem: SAP wanted these managers using RealSpend directly, and adoption depended on making that possible. We had three months to find out whether machine learning could simplify that workflow, starting from a genuinely open brief where ML could have meant almost anything applied to budget monitoring. A structured exploration phase, scored against user pain, technical feasibility, business value and SAP's strategy, narrowed that field to three concepts by vote: anomaly detection, expense forecasting and smart tagging, not because we started there but because the team chose them. Only then came the harder question, the one we actually had three months for: which of the three was worth shipping. Neither side was on familiar ground: it was the first time our engineers had built with ML, and the first time our users had seen ML-generated content at all.


As Senior UX Designer, I worked alongside a Product Owner, a junior visual designer, and a team of backend engineers evaluating ML feasibility in parallel. My scope ran end to end: framing the problem, running ideation and paper prototyping (that is true, way before Gen-AI was around we used to paper prototype :)) designing and moderating every validation round, and synthesising what we learned back to the room, including the engineers who weren't in the sessions themselves.

Men Red BG
Men Red BG

Decisions and Actions

  • Ran that exploration as a structured ideation workshop, not an open brainstorm, so the four criteria did the narrowing rather than whoever argued loudest.

  • Built paper prototypes with the engineers directly, so feasibility debates and design decisions happened in the same room instead of getting lost in translation.

  • Designed and moderated three rounds of validation: an internal round measuring desirability, a second internal round with the same persona-matched experts measuring task completion and reaction to the concept, then external testing at SAP Sapphire / ASUG 2018 combining qualitative feedback with a formal SUS score.

Men Red BG
Men Red BG

Design Iterations & Learnings

We designed the anomaly chart assuming the algorithm's flags were simply right or wrong: a solid mustard fill on anything flagged, which looked certain. Validation proved otherwise. Machine learning anomaly detection doesn't always return true positives, and a confident-looking chart was overstating certainty nobody had. We redrew it as a thinner mustard line instead of a solid fill, a hint to investigate, not a verdict to trust.

Reporting had the same problem from a different angle. The first version let managers flag a false anomaly back to the system over conventional email, which worked, technically, but validation told us plainly they didn't want to leave the tool to do it. It took three rounds of iteration to move that reporting into the in-app digital assistant instead, with a confirmation that the report had been read, and external experts at SAP Sapphire confirmed people wanted to investigate inline, not switch tools to act on what they saw.

The same validation data cut our own scope. Smart Tagging tested weaker than the other two concepts on both desirability and feasibility, so rather than defend it, we dropped it, freeing the final round to test Anomaly Detection and Forecasting more rigorously instead of stretching thin across three. Anomaly Detection won that round on technical feasibility and business viability, and shipped. The call was made on data, not on which idea the room liked best.


Woman Greyscale
Woman Greyscale

Decisions and Actions

SAP strategically asked for more integration between its own products, a direct response to what customers had been asking for. Looking for new technology and new ways to connect products in meaningful ways was part of this design challenge. My approach was to agree with the PM and PO on testing three strategic bets at once. Their vision, which also required prior cross-team agreement on the technical aspects, was to connect Concur's travel data into RealSpend so two well-known SAP products worked as one. My idea was to verify whether our hypothesis held:


  • were we applying machine learning to the right problem?

  • Would SAP's own digital assistant (then Co-Pilot, now SAP Joule) make conversational UX genuinely useful rather than merely delight as a novelty?


We chose travel requests as the proving ground, frequent enough to matter and tied directly to expense control. The managers approving them were already stretched thin: several disconnected tools, reports built by hand every month, and rarely a live number to work from.


As Senior UX Designer, I facilitated co-creation workshops for ideation and problem-definition, built paper prototypes with stakeholders, designed the interactive high-fidelity prototype in Axure, wrote the validation questionnaires, and moderated contextual inquiry sessions with manager-experts to understand how approval decisions actually got made under time pressure. Our visual designer led the redesign of the master detail view and the line item table once we had live travel data in the prototype, and together we synthesised findings with our Product Owner before handing off a development-ready concept.


Reflections

It's hard to picture doing a paper prototype these days, but I'd like to highlight that good team collaboration builds momentum and usually saves us rework time: building a shared understanding of the problem, and of where a feature sits in the bigger picture, before jumping to solutions. That willingness pays for itself even faster in today's fast-paced AI era, where misalignment compounds quickly once building starts.. Team collaboration and DesignOps have always mattered to me, and both these projects show a strength I want to keep carrying forward as roles keep blurring.

Outcomes

Anomaly Detection: Usability Benchmark at SAP Sapphire

Combined qualitative feedback with a formal SUS score during live testing at SAP Sapphire | ASUG 2018, selected among hundreds of applicants, giving the team its first comparable usability baseline instead of opinion alone.

Travel2Budget: Validated Before It Cost Developer Time

Two rounds of user testing turned three early explorations into one development-ready concept, catching friction like missing trip dates and the microphone problem before any of it competed for a spot on a busy developer backlog.

design iterated
Man Dancing

Evolving as a team

testimonials

workshop

Raja A.

Director Product Development, Wikimedia Deutschland

Raja A.

Director Product Development, Wikimedia Deutschland

Raja A.

Director Product Development, Wikimedia Deutschland

Questions people usually ask

Expand all

What does complex, large-enterprise B2B SaaS experience actually give me, and would I still move fast enough for a smaller team?

How do I work when the brief isn't clear yet, and what part of the job do I enjoy most?

How do I actually strengthen a team, and will I get hands-on or mostly direct from a distance?

What did I do with the time between roles, where do I stand on AI, and what am I looking for next?

How has living abroad shaped me, both as a person and as a principal design lead?

Nanda Dias | Staff Designer

© 2026

Nanda Dias | Staff Designer

more works