Principles to design by

Kursat Ozenc
Shaping the new enterprise
9 min readNov 23, 2016

--

Our group at SAP is responsible for more than 50 tools that support a broad range of product and software development activities. We work as discrete teams around the world, but we share a common goal of creating top-notch experiences for our internal customers and users. We’ve long recognized that while we share values and principles in theory, it’d be very helpful to codify them. Having our principles in black and white helps us to be more considered and intentional in applying them on a day-to-day basis. Principles should not be a theory, their value lies in how they’re lived.

Being part of a global company with offices around the world from Shanghai to Bangalore, and Palo Alto to Walldorf makes us more cognizant to cultural differences across teams. With that in mind, we included our international colleagues in designing our principles. Their input has been critical since they bring perspectives from Asia and Europe.

One parallel effort that helped us frame the principles is our customer journey project, which aims to bring a holistic understanding of how our users (in this case product owners and program managers) experience our tools ecosystem. As we were mapping out the touchpoints of our users during their product development cycle, we identified issues around connectedness, consistency, and context-awareness. These themes provide a strong rationale for our principles. Moreover, specific pain points led us to articulate some of the principles in a more grounded manner.

What others have done

The use of design principles is not new, in fact it goes back to ancient times with the famous architectural principles of Vitruvius: durability, utility, and beauty. In more recent times, the Bauhaus movement brought us form follows function, and Dieter Rams, whose principles are very well-regarded at SAP, brought us his 10-point manifesto.

We studied historical principles and the current principles that companies like Apple and IBM follow. We also reflected on the implicit principles we’re following as a team, and give them form.

We synthesized all this along with the needs of our global team, and ultimately selected principles that both deeply reflect our practices, inspire us to continually work to make our designed experiences better, and are easy to understand and act on for everyone on the global team.

Our design principles

Our design principles are defined in a spectrum of human-centeredness. They are developed with scalability and depth of experiences in mind. We believe products and services should enable and connect with reliability. They need to foster a balanced, relevant, and unified experience.

Let’s look at the principles in detail. When defining the principles, we surveyed not only our offerings, but also industry best practices. This is reflected in the examples that demonstrate the principles in action.

1. Reliable

Courtesy of Gopro, Image taken from Gopro

The expectation for any product or service experience is to provide its functionality consistently in a dependable, predictable, and responsive manner. In the software industry, where cloud is becoming the new normal, reliability is also measured by the downtime performance.

Reliability in our tools paves the way for two things. First, it creates trust in people; they get more confident in forming a deeper relationship with the tool. Second, reliability acts as a building block for other principles, such as relevance and enabling.

2. Relevant

Courtesy of Google, Image taken from Google

Relevant means providing the right functionality to the right person at the right time and location. In the late 2000s, as companies like Google and Apple were moving from single touchpoint products to creating their own ecosystems, they realized the power and importance of context. Parallel to increasing their capability of harvesting big data, they turned context into an advantage and an offering to their customers. We strive for a similar path where our product teams begin to shift from single product to ecosystem, and contextless to context-aware offerings. Context in our particular situation means that tools are aware of the roles, processes, and products that they are serving, and provide relevant and meaningful experiences.

3. Unified

Courtesy of Apple, Image from Apple.com

As products evolve into a family of products, consistency becomes challenging, and pushes designers to act more deliberately in aligning the design elements across products. Our tools landscape is not an exception! We strive for a unified experience for our users. Unified means sharing a common language, without losing the contextual richness of a product.

We are still learning how to shape a design language inside our tools ecosystem. When shaping a design language however, we find defining a user experience framework extremely useful. The UX framework (explained nicely in About Face ) helps us to think of design language as a system that consists of service design, interaction design, and visual design frameworks.

We also want to make a distinction between unified and uniform design, since it’s easy to fall into the trap of uniformity. Uniform design means homogeneity without considering the context of a product. One great example that our team refers to is Microsoft’s Excel and Xbox products. You wouldn’t expect these two products to have uniformity, since they live in very different worlds. The unified principle however means that they can share a design language for interaction and visual design as long as it’s appropriate for their respective contexts.

4. Balanced

Mailwave is an internal tool that we are developing for our employees. Tool crunches lots of data points, and provides a balanced experience for reading information.

Living in the enterprise world means living in an ocean of complexity, which in itself is not a bad thing. Traditionally, users are distinguished between novices and experts. Novices are infrequent users and beginners, who would be confused by complex interfaces. Experts on the other hand would be frustrated by overly simple interfaces. We believe in finding a balance between the two, giving more control for expert users, while maintaining a less complex experience for infrequent users and beginners.

In our experience with expert users, we observe two behavior threads. 1. They take pride in their handling of complexity and don’t mind dealing with it. 2. They see and use consumer-grade applications and expect similar conventions and simplicity when they use our tools. There’s an obvious conflict between the two. Keeping these conflicts in mind, we strive for a balanced design that explores simplicity within complexity.

The principle of Balanced is also inspired by another pair in conflict: novelty and familiarity. The legendary designer Raymond Loewy from the early 1930s coined a term in called MAYA — Most Advanced Yet Acceptable — to convince his stakeholders. Any design effort is an attempt to challenge the status quo. In so doing, the designer has to find a balance between novelty and familiarity to keep users as well as clients grounded. We strive for a similar balanced act in our tools.

5. Connect

Courtesy of Slack, Image taking from Verge

One of the things we observed in our experience mapping exercise was the lack of or loose connections between our tools. This causes strong discontent among our users. One big ramification for this is overhead and slowing down of decision-making. We strive for tools that connect people, data, and processes. This principle will also reinforce other principles like Relevant and Unified when it drives product development.

Slack is a growing tool within our ecosystem and exemplifies the principle of connect very well. Slack can be seen as any other chat tool, but its core is ingrained with connecting. It’s a platform to connect people, applications, and processes. Its bots also hint at the future of connection. Applications begin to have their own bots which listen to states and events, and respond them in context.

6. Enable

Courtesy of Github, Image taken from Github open source projects

Our ultimate goal is to enable. We strive to provide transformative capabilities to our product teams. Samuel Hulick talks about products giving users superpowers — that people don’t buy products, they buy better versions of themselves. We seek to deeply understand the needs of our users, so that we can support them in sometimes radically new ways. We introduced GitHub to Sap developers, not only for improved version control, but to support a positive transformation in how we develop software as a company. Enablement doesn’t mean a de facto new tool however, it guides us to think broadly and with open minds about opportunities to exponentially enhance the product team experience.

Orders of Principles

Orders of d.principles

While crafting principles, one strong insight emerged. Not all principles are created equal. They differ in scale and undertaking. This led us to dig deeper into their nature and lay some groundwork on how to make them more graspable for our teams.

Reliability and Unified are the first order of principles. It’s hard to talk about the other principles when the product is not providing its basic functionality promise. Reliability acts as a building block and base for a positive product experience. The next challenge after functionality is consistency of design elements across channels, devices, and platforms. The principle of Unified covers that aspect of the user experience.

Connect and Relevant belong to the second order of principles, meaning that they require a deeper and more human-centric understanding of the use cases. Thinking of the user not only at one point in time, but also in her surroundings define the characteristic of a contextual product. In a way, the principles of Connect and Relevant envisage a holistic person instead of an isolated persona or user. From a technical perspective, the principles of Connect and Relevant present a bigger undertaking for product teams.

Balanced emerged from the need to address the living-with-complexity challenge. This principle is critical when the designer begins to shape an ongoing relationship between the individual and the system. The user can be a novice or expert, the system can be new or familiar. The designer needs to balance these dimensions when making design decisions.

Enable is the ultimate expression of a human-centered approach. Enabling can be as straightforward as completing a task, and as aspiring as transforming the user’s life for the better. Such a lens requires a systems mindset, where the product team cares about the target audience from beginning to end — onboarding to navigation, and ongoing use to leaving a product.

Rolling out the principles

While crafting our principles, one of our goals is to make them livable within the organization. This is possible when we have a buy in from the product owners. Recently we got the perfect venue for that, and presented them in our annual strategy retreat for product owners. During the retreat, we wanted to to get their feedback, and encourage them to pick up and apply in their daily work. After presentation, we asked product owners to assess their own tools with a principles lens. We picked the Relevant principle for the occasion and provided them a cheat sheet to help them in their assessment. Each product owner identified one to three action items to enhance the relevance of their tools. The engagement from the product owners showed a clear appetite and willingness to apply design principles.

We also decided to make the principles more present in our workplaces. We are currently designing posters for each principle so that they can live across our offices from Shanghai to Walldorf.

In 2017, we will be running more advocacy efforts for each of the principles across teams. One idea we are currently playing with is dedicating a principle for every 2 months (months of Connect), and running light weight engagements with product teams. We are also planning to revisit them in a year or so, and refining them based on the feedback we receive.

Authors: Kursat Ozenc and Rachel Reynard. We thank Alex M. Wu for the illustrations, Leslie MacKay for editing, and Ben Boeser. We also thank Nikola Freudensprung and Roman Kostka for their collaboration, and helping to drive the project globally.

--

--