How We Defined the Design Principles for the Salesforce Developer Experiences

Anyone who has worked in an enterprise company knows that products sometimes take on lives of their own. With thousands of people around the world working in silos on specific parts of the experience, products can feel like they’re patched together. To help create alignment, we of course rely on meetings and develop design systems. In a perfect world, these practices would minimize a disjointed experience.

But, badly planned meetings can be time- and energy-consuming — especially for distributed workforces. Meetings also aren’t necessarily the best way to address some of the challenges that come with designing at scale. Using design systems helps with alignment and consistency for a product’s user interface, but it’s less effective for defining what the product should be.

What can help teams is having a shared set of principles that define the type and quality of experience they want to provide their users. The principles need to be clear, practical, and specific enough to help teams align with their shared experience north star without having to improvise or meet for every little decision.

Recently, I led the creation of a new set of design principles for the Salesforce Developer Experience. We needed to set standards for our teams to drive product, engineering, and design decisions, and lead to consistent experiences across touchpoints that “feel like” the Salesforce Platform. We felt it was particularly important in making a developer platform, for which we have to create and connect experiences from graphical user interfaces (GUI), command-line interfaces (CLI), integrated development environments (IDE), technical documentation, and more. Most of our users switch between all those different interfaces while interacting with our tools and it’s important for us that they have a great cohesive experience.

Our new principles allow us to be explicit about our knowledge of how to create great developer experiences and share that knowledge with others.

Now, from the other side of a successful project, I can share all the details and tips that helped us along the way. But before we get into practical tips, let’s review what we mean by design principles and their benefits.

What are design principles?

Design principles articulate essential aspects of a product or service to help teams build great coherent experiences. These essential aspects are the reasons your users love your product and what sets it apart from your competitors. Design principles serve as the team’s north star and inspire a consistent vision across product areas. They guide decision-making, the feedback process, team alignment, and they strengthen product differentiators. Importantly, design principles help designers connect brand values with the product experience.

Good design principles should be grounded in the needs of the user, business, or any relevant stakeholder. Develop principles that are clear, unambiguous, practical, actionable, and easy to remember. They also should be specific enough to help you differentiate your product from competitors yet broad enough to apply to diverse aspects of your product. Avoid overused descriptors such as “beautiful” or “intuitive” which can leave too much room for interpretation.

How to define design principles

What helped me the most in this project was to think first about all of the necessary steps and then visualize the materials and preparation for each step. What follows summarizes my process and I offer it as an example that you can use for inspiration.

Process

1. Plan: Create a design brief and project plan. Review the plan with approvers.
2. Recruit: Recruit participants and send invites.
3. Research: Gather existing principles across our developer experience teams and meet with product leaders to understand what worked or didn’t. Gather any relevant information from recent research projects on developer users and developer-focused products.
4. Define: Plan and hold cross-functional workshops to define design principles.
   – Diverge: multiple sessions with a wide range of team members.
   – Converge: a session with key stakeholders to prioritize.
   – Polish: an even smaller session to synthesize the final principles.
   – Finalize: individual sessions to refine the descriptions.
5. Draft: Create a draft with the final design principles and descriptions.
6. Get Feedback: Share draft with key stakeholders and DX org and request feedback. Revise as needed.

Notes on the process:

• The participants were all internal and recruited via Slack. I used a Google form to collect pertinent information, including their disciplines (to ensure a diverse representation of teams), time zones (to facilitate scheduling), and referrals for other potential participants.
• I researched and compiled existing reference materials that would help inspire the participants during the workshops. People could access this information in the FigJams we used and they didn’t have to rely exclusively on experience and opinion. Citing existing resources was a great way to acknowledge our colleagues for their work and draw them to participate.

Workshops

Each workshop had its own plan for creating the session groups, defining activities and duration, developing materials, and more. Take a look at our blog post about How to Design a Collaborative Experience (Instead of a Virtual Workshop) to learn more tips that are applicable to these exercises.

At a glance, it seems like there’s an excessive amount of workshops in my plan. But this reflects the size of Salesforce and what it takes to make sure everyone feels included, heard, and has a sense of belonging. In order for design principles to be successful, they have to be accepted, embraced, and applied. Getting people involved in the process of defining the principles gives them a sense of ownership and pride in the final output.

Anyone interested was eligible to participate. We communicated the process via Slack and Quip, which made asynchronous collaboration straightforward and inclusive.

Divergence workshop

We held three divergence workshops that were 100 minutes each and included six or seven participants.

The workshop agenda:

1. Introductions and Icebreaker (15 min): I asked the participants to think about one of their favorite experiences or interactions from our products. We then shared these stories as a way to begin to relate to one another and get into the right mindset for the first exercise.

In this FigJam section, we asked participants to introduce themselves and share what they hoped to learn from the workshop and their responses to the icebreaker question.

2. Goals and Design Principles Presentation (10 min): I reviewed the goals of the session and the definition of design principles. Over the course of the project, we learned that not every designer fully grasps the concept and value of having design principles. Don’t assume people have internalized the concept; it’s good to reinforce the explanation.

3. Keywording (30 min): Each participant had to come up with a list of principles relevant to our products and ideas for how to build great developer experiences. We shared our thoughts with the group and then we each voted on the keywords we believed were essential to our products and organization. The keywords with the most votes advanced to the next round.

Be clear about the instructions for each activity so that participants understand what’s expected of them.

4. Break (10 min)

5. Mind Mapping (30 min): In the second exercise, the participants had to define what the keywords mean for them and what the keyword might mean for users’ needs and the product experience. Mind mapping helped reveal multiple interpretations of the keywords. After reflecting on the responses, everyone got 10 votes to select the ideas that resonated the most for them.

Provide some starting words for this exercise so that the answers follow a similar pattern and are easier to compare.

6. Wrap-up (5 min): Leave a few minutes at the end of the exercise to explain how you will use the participants’ work, next steps, and to share gratitude for their time.

Formulation

After each workshop, the facilitator synthesized the keywords, phrasing, and votes. They wrote a draft of the principles, which then became the focus of the subsequent convergence workshop.

Example of a draft principle.

Convergence workshop

This session took us an hour with 12 participants. The structure was similar to previous sessions, but the goal was different: we wanted key stakeholders to help us identify and prioritize the most important design principles.

Like in the previous workshops, we used FigJam’s stamp tool to vote and prioritize.

Synthesis

For this session, a small group of designers met to synthesize a first draft of the design principles based on the results from all the previous workshops. We split into break rooms and each group took turns drafting descriptions for the chosen principles.

The workshops yielded many ideas for us to consider.

Wordsmith

It’s important to review, edit, and revise the draft principles. You want to make sure the words accurately convey the intent of the design principles before finalizing the document and sharing.

Socializing

It’s crucial to socialize the final set of design principles. Share the document widely, refer to the principles in conversations, draw attention to their existence. I felt particularly lucky because our leadership so appreciated the principles that they presented them during Dreamforce, our largest event of the year. Watch the segment on Salesforce+

Gail Frederick, SVP of Engineering for Developer Experiences, presented our new design principles at Dreamforce 2021.

Outcome: The new Salesforce DX Design Principles

The following are the final formulations of the output of our multiple workshops. These are the principles that define what our product should be and feel like. The expectation is for these principles to inspire the type of product we want to build, setting a new guiding light for our developer experiences. Take these as a reference or example to help your team build your own set.

Magical

We make complex things simple and simple things automatic. Complex capabilities are made available to all users in a way that is intuitive, consistent, and easy to use. Easy, yet powerful. While behind the scenes our technology is incredibly complex, we rally in creating an end-user experience that’s magically easy. Users feel smart because they know they’re being productive, and the complexity of our organizational boundaries and underlying systems are handled for them. Everything just works and fits together. The experience is so delightful that it almost feels like magic.

Opinionated

Building on Salesforce is an easy and fast experience, whether you’re using clicks, code, or both. Salesforce enables its users to achieve fast results without requiring them to make dozens of decisions at every layer of their project. We can execute sophisticated workflows on behalf of our users and provide smart defaults that require little to no configuration from them. We steer them to the right way of doing things. Every interaction either has an immediate feedback loop or keeps users informed of the current state of the process. The product feels alive, responsive, and helps users achieve quick wins.

Progressively Powerful

As users get more comfortable and begin looking for more flexibility, they gradually discover more sophisticated and complex features that can help them get their job done. Users have the ability to change our defaults where it makes sense for them. We help them by providing sensible guardrails, clear documentation, and guidance to help them make the right decisions. Whether they’re working in clicks or code, they’ll never run into a blocker or dead-end — they can always go a little deeper to get to the right level of power and abstraction they need. Their full journeys are thought out from beginning to end. This engenders trust and understanding, as users can develop an intuition for how the magic works, and build in modifications and overrides for their individual use cases.

Impact

It’s still too early to measure the full impact of the design principles on our teams and products. But they’ve sparked lots of interesting conversations and feedback, reinforcing their value and validity. They’ve also started to influence the vision and planning of future projects. For me, I most appreciated getting feedback from workshop participants about how much they enjoyed the process. They valued the time to reflect as a team and it created a lovely moment of connection at a time we desperately needed it.

Hopefully, our experience and process will inspire you and help you feel more confident and prepared to define your products’ own design principles. Good luck!

Acknowledgements: Thanks to Kathryn Murrell, Marcelino Llano, Matt Graham, and Peter Chittum for your feedback and to Hsiao-Ching Chou for the draft edits!

Salesforce Design is dedicated to elevating design and advocating for its power to create trusted relationships with users, customers, partners, and the community. We share knowledge and best practices that build social and business value. We call this next evolution of design Relationship Design. Join our Design Trailblazers community, become a certified UX designer, or work with us!