Salesforce Design Research | Part 2
This is part two of a four part series about a research study Halibut Flats Research conducted for Salesforce Design in 2021. In part one we established the context of this research, defined design and the design process, and spoke to the importance of design. Here in part two we will discuss how Architects, Admins, Developers, and Designers in the Salesforce ecosystem think about and practice design. In part three we’ll outline three Salesforce Designer archetypes. Finally, in part four we’ll introduce a paradigm for how Salesforce can support design and Designers in the Salesforce ecosystem, along with some reflections on where design may be heading in the future.
Introduction
Now that we have established the context for this study as well as a definition of design and the design process, we can unpack insights from our research. We’ll begin by sharing insights gleaned from interviews conducted with Architects, Admins, Developers, and Designers. The following are high level reflections for how these personas think about and practice design. Knowing how design is understood and practiced in the work of building products in the Salesforce ecosystem is a critical step in empowering design and Designers working with Salesforce products and tools.
How Salesforce Architects Understand and Practice Design
Salesforce Architects are big picture thinkers who are naturally interested in the relationships between nodes in the system. They are integrators and process-oriented, typically wearing several hats. As business-minded people, they operate on cross-functional teams. Architects find themselves as liaisons between product owners, developers, internal customers or clients, and in some cases, external customers — there is felt obligation to “keep all sides of the business talking to each other.” Architects are higher-order thinkers and tend to engage with the Salesforce ecosystem holistically.
While a few spoke to their Salesforce learning journey as “trial by fire,” most of the Architects we interviewed learned on the job. They found learning in the flow of work to be a comfortable way to acquire new skills and knowledge. Documentation and user generated content such as blogs were often cited as the primary sources of learning information for Architects. Some came from Developer backgrounds and became Architects as they found “more interest in solving business problems” than in writing code.
Architects were consistently problem oriented — they considered problem definition to be the most important aspect of their job.
As system thinkers, it is no surprise that architects define design in systemic terms — good design is a “system [that] is beautifully orchestrated… humming.” Good design considers “how the whole project is going to be put together” and has good “structure, symmetry” and “consistency.” Architects were also able to connect this holistic system to the end user as good design was about “actually addressing the need, not just applying a bandaid,” “making people’s lives easier, efficient, and effective.”
Architects unsurprisingly were very articulate when it came to their design process. Architects consistently articulated human-centric approaches to problem definition, understanding user and business needs, and ultimately understanding the ‘why’ behind their customer’s or client’s ask. Many were adept workshop facilitators and walked their customers and clients through rigorous “discovery sessions.” Architects were naturally curious, attentive listeners, and had familiarity with design language related to process — service design, user journeys, and UX. Architects worked from a toolbox that was mostly dialectic and conversational in nature. In Salesforce, they gravitated towards “process automation tools, not design tools.” When it came to user interfaces, they left this to others and limited their work to higher level system design that solved for the business problem.
Architects’ greatest challenges exist in relation to client engagement and education. “I can’t send clients to Trailhead.” “The language gap for clients new to Salesforce is high.” There is a strong desire for “better ways to communicate with new people who don’t understand the system and aren’t going to take a trailhead course.” Especially when it comes to those working in legacy systems, Architects’ desire resources for educating others on the value of business and process design with less focus on the technical aspects of Salesforce.
How Salesforce Admins Understand and Practice Design
Salesforce Admins are strategic thinkers often holding multiple priorities in hand simultaneously. They often operate with a holistic view of the system within which they are working, but unlike architects their emphasis lies more in the tactical day to day. Admins are oriented towards processes and “mitigating what users go through.” They find satisfaction in making the complex “seem simple and seamless” for their end users and customers.
Admins have diverse backgrounds, but many are familiar with data and the basic heuristics of making data accessible and applicable. Many admins informally interface with end users as they are the go-to person for end users when help is needed. While not formal user research, this engagement with end users gives admins an acute knowledge regarding the needs, challenges, and aspirations of end users.
Some Admins define design as “look and feel,” but more often refer to notions of presenting the right information or resources to users at the right time. They often spoke of design as a way to eliminate frustration and friction. There was also an admin who spoke of design as “conceiving and creating new business processes.” Generally, admins have an intuitive sense of design inasmuch as it implicates the “experience users have in the system.”
Most often the work of admins is triggered by a user request. Through informal discovery, Admins define the problem that needs to be solved. Savvy admins use more formal engagement methods such as user interviews and “screen shares” to understand the needs of users. As they partner with others they will use visualization tools to develop solutions and ultimately will “build solutions in sandbox.” They typically do not write code.
Like many other Salesforce roles, Admins enjoy connecting with others who have their role in other organizations for the sake of connecting and learning. They enjoy “brag sessions” to learn “how someone else solved a problem I may have run into in the past.” In terms of community, bringing admins and architects together would be beneficial for each audience group, especially as they begin a learning journey to adopt design-based tools and processes.
How Salesforce Developers Understand and Practice Design
Salesforce Developers have formal computer science backgrounds and are intimately familiar with the underlying technologies that make Salesforce cloud products possible. They come from startups as well as Fortune 100s, and some have built CRM systems from scratch before working on Salesforce. Unlike Architects and Admins, they don’t often interface with end users and are driven by “understanding what the business folks need” except in the cases where Developers take on an Admin role in their organization. Likewise, one Developer shared how he was “slowly turning into an Architect” as he enjoyed interfacing with end users and solving system-scale problems.
A characteristic question of Developers is “is this in the requirements?” This sentiment shapes their attitude towards design — they “translate to technical” and often see “user friendly features” as “more work for developers.” Developers typically default to design specifications provided by Salesforce and will resist custom components that do not align with the Lightning Design System. “Trust Salesforce. Whatever they are designing, use the same design.”
Despite this, Developers do understand design as the “first impression” and “customer branding.” While a minority of developers we interviewed were more savvy and could effectively speak to the nuance and diversity of design as both a process and an outcome, most defined good design as a “flexible and adaptable system, [that is] easy to change, with minimal technical debt.”
While Architects and Admins often engage with end users, Developers spoke mostly of engaging with product owners and “stakeholders across business lines.” By the time developers are invited into the design process, the solution has been mostly defined and the developer’s job is to validate the technical feasibility rather than the usability. Often their projects are determined for them far in advance, and they use agile methods with varying degrees of rigor to work towards project delivery. More and more developers however are embracing user testing to ensure technical feasibility and usability go hand in hand, though some noted time and budget constraints to conduct these kinds of activities. Likewise, some noted that managers perpetuated these constraints and are a barrier to developers adopting more design practices.
Developers had much to say about design. They felt that the best digital designers would be those who did not come from a Salesforce Developer background as they could “bring outside perspective” and were more likely to have a “beginners mindset.” Some Developers lamented that Lightning “kinda looks like every other web interface out there” and Salesforce could support design and designers by “thinking outside the box.” Additionally, Developers continually brought up challenges building well-designed mobile interfaces — “[mobile] is too much extra work, so we end up neglecting the mobile experience.”
While the developers we interviewed were the most vocal in their critiques of design across the Salesforce ecosystem, they were also quick to acknowledge the need for design and their own aspirations to grow in a designer’s skillset.
How Salesforce Designers Understand and Practice Design
At the time this research was conducted, Designers were not yet a formal role designation for Salesforce. Though the designers we interviewed all had experience working with Salesforce designing user interfaces and experiences. A few started their careers as front-end developers or working in unrelated fields, but most began with formal education in a specific design discipline (i.e. UI/UX, industrial, architecture). If they did not have formal design education, they had received training through their employer. Designers were consistently oriented towards “solving problems for users” through visual interfaces. A common sentiment was that as designers, they sat at the “intersection of design strategy and technology.”
Designers are disciplinarily ambidextrous — they find themselves conducting many of the discovery activities that an architect would conduct, as well as partnering with developers to develop and deliver solutions. In addition to “pushing pixels and designing interfaces,” they often find themselves doing “product strategy, storyboards, [or] whatever they ask me to do.” This diversity of work is enjoyable for designers, and they find the best work to be done on multidisciplinary teams.
Designers expectedly had the most esoteric definitions of design, as well as the most technical and acute. All designers spoke to the idea that “design is more than making beautiful things… [design] is a form of changing behavior, it can solve your problem and bring joy to you.” Additionally, “design is continuously making improvements on human life through visuals and experience.” Most designers also echoed the notion that design starts with defining the problem to be solved, rather than solving the problem — “Most of my time is trying to identify the right problem to solve.” Designers spoke to these ideas as being the domain of “design consultants.” Acute notions of design such as visual hierarchy and aesthetics were attributed to “craft designers.” These craft designers were said to “more likely sweat the details.”
All Designers we interviewed had a very clear picture of their process and could articulate it with an unparalleled level of sophistication. In addition to the emphasis on end user engagement upfront in the design process, many designers spoke to the success found in engaging developers earlier than later. “If you’re not talking with your dev a couple times a day, you’re going to miss things.” This approach to the design process “makes the handoff less problematic,” and negates technical debt and “design debt.”
Designers lamented that creating custom solutions was difficult given the technical constraints of Salesforce, and this inhibits their potential. Other design systems were said to be “more modular and flexible.” This highlighted the aspiration among designers that “what is custom today, [Salesforce should] make configurable.” Additionally, custom design should be empowered in a manner that it can be easily maintained technically. Finally, designers collectively desire to see more mobile resources — Sketch templates, documentation, and publishing tools.
We continue in part three where we’ll outline three Salesforce Designer archetypes.