Helping Others Shine

A look into our principles and process for crafting human-centered tools at SAP

We’re a multidisciplinary product team at SAP Labs in Silicon Valley, following a human-centered design process to tackle thorny enterprise challenges. We’re a healthy mix of designers, engineers, data scientists, writers, and product managers who love tough problems. We incubate and accelerate new ways to blend Silicon Valley ideas and innovations to solve problems at an enterprise scale. Pretty much every day is different. We’re on a journey and want to share with you what we’re learning, and connect with our community to learn from you.

Helping others shine

Like any very large enterprise, SAP is a complex organization with its challenges. As much as we love to design and develop software — in all its forms — we also have to navigate a complicated global system to be successful. In this blog, we’re going to focus on what we’re doing and building, and also how we’re tackling the organizational challenges we face. Our purpose as a team is to help others shine through our products and services. Our purpose with this blog is to hone our thinking, share our experiences, and learn from other teams facing similar hurdles.

What do we work on?

We operate as a fairly autonomous team within SAP, designing and building a variety of products and services; some for internal use, some for external use. We focus on many topics that support current software and product development best practices, including data science and engineering. We’re a standalone team, but we frequently partner with others to amplify topics. Our goal is to share and scale; to not be an island.

Everything we create is purposeful and needs-based, designed to tangibly support individual contributors and teams. We look for opportunities to empower people in many ways and at different scales. We might seek to simplify a process, extend a capability, empower a specific role, or fundamentally re-imagine the company’s approach to software development. In these efforts, we always view the products and services we design as potential catalysts for organizational transformation.

From Humantific’s design geographies and complexity scale.

When we say design, what do we mean?

We use Humantific’s model to help us articulate what we mean when we say “design.” We’re motivated by the role of design to drive positive change at any scale. We scaled GitHub from a handful of us to 12,000 internal users. We could have used it ourselves regardless, but we wanted the whole development organization to have the opportunity to benefit from a highly collaborative and transparent approach to software development. We didn’t force anyone to use it, we just advocated for its availability and approval. At a startup or more “top-down” organization this kind of decision and change may take days or weeks. At SAP, and other very large distributed enterprises, this kind of change can take years. We need to be patient, persistent and resilient.

Principles and Process

Our work is guided by principles and process. Principles help guide our team throughout the design process, and describe the standards we aspire to. Our process is human-centered, and helps guide how we work.

Principles

We crafted our design principles as a team, over time. We want them to be experiential and more user-centered than product-centered. When we talk about experience, we emphasize the practical as well as the emotional and social qualities of experiences. We want the experiences we create and support to be reliable, relevant, unified (rather than uniform), and balanced. We want to enable our users and customers with our products and services. We must also support their need to connect to the information and people they need to perform their work successfully.

We’ve written a separate post about our principles, and how we created them, if you’d like to learn more.

Process

Our process is informed by research and is highly iterative; we call it “continuous design thinking.” SAP practices design thinking extensively, and we want to leverage and extend that institutional knowledge. Because we’re focused on solutions that take the form of products, services, or experiences, we need a way to keep the focus on our users or customers throughout ongoing development — that’s our biggest challenge.

We try to keep our processes as light as possible, and constantly strive for the right balance of methods that achieve the best outcomes. Desirable outcomes for us are helping people be more successful by using the product or service, maintainable software (we operate everything we build), plus a sound business model. It’s also just as important that our work is fun, challenging, and that the process helps way more than it hinders. We’re a pretty strong-willed bunch, so we only keep processes that genuinely benefit the work.

To describe our process, we use the double diamond model from the UK’s Design Council.

Double Diamond model from the UK’s Design Council.

We like that the model places as much emphasis on up-front problem identification and definition, as it does on the more typical execution phases. It’s really important to us that our process emphasizes solving real problems for people, rather than building features.

We go into a bit more detail on our process in a separate post if you’d like to learn more.

We’re currently working on data science and engineering topics, software development (at scale) challenges, machine learning, and — as always — wrestling with enterprise communication and workflows. These are the things we’ll be writing about, from all perspectives: product, design, and engineering. We’re looking forward to connecting with other teams facing similar challenges so we can learn from each other.Ÿ


Authors: Rachel Reynard and Kursat Ozenc. Many thanks to Leslie MacKay for editing, and Alex M. Wu for photography and illustrations. Thanks to Michael Spindler, Ben Boeser, Dominik Tornow, David Farr, Ingo Sauerzapf, and Lars Karg for their support & contributions.