Introduction
Marketing is a high risk, high reward career. As one of the industry leaders in marketing tools, Salesforce tasked us with “increasing marketer confidence at the time of pressing send” within their Journey Builder application on the Salesforce Marketing Cloud (SFMC).
Their reasoning was simple. In order to stay competitive, Salesforce must not only facilitate marketer success, but must also build trust in its functionality. In its current state, however, we found that while the Salesforce Journey Builder application is a cornerstone experience for marketers around the world, what cannot be overlooked is the amount (and variety) of frustration surrounding the experience of using the tool itself.
As we discovered over the course of the semester, the primary issues surrounding Journey Builder include (but are not limited to): an immensely difficult learning curve; slow load times; inexplicably limited functionality, and incomprehensible/limited data analytics functionalities.
What is Journey Builder, Anyway?
Any time you get an email offering discounted concert tickets, or a text announcing a sale, you are being targeted by a marketing campaign. Such campaigns are carefully crafted to maximize your experience as a consumer, with the logic being that the nicer your experience is, the higher likelihood of you buying something.
According to Salesforce, Journey Builder “deliver[s] cross-channel personalized experiences at every step of the customer lifecycle with campaign management.” (Translated into English, the Journey Builder application helps marketers do their jobs better.) Journey Builder helps marketers assemble their campaigns through visual representations of a campaign (called “journeys”), and empower marketers to “create seamless customer experiences across every touchpoint including email, mobile, advertising, the web, direct mail, sales, commerce, and service.”
At a Glance
9 Weeks | UXR, UXD, Prototyping, Testing, Presentation
Team: Ries Murphy, Clara Bradford, Jingyao Liu, Xinning Zhang
Sponsors: Salesforce
A Compounded Problem
As we discovered through research, the problem space we were working in was highly unusual. This was not just because of the sheer size of the problem space (which was also an issue) but because of the compounded nature of the problem space itself.
While we might be tempted to consider each pain point as a discrete node in a larger constellation, our research revealed that marketer anxieties, work challenges, tool inconveniences, metrics for success/failure, and even how they diagnose the success/failure of past campaigns, all overlap and interact within one massive, dynamic problem space, exacerbated by an archaic data analytics functionality that doesn’t offer basic filtering functionality.
Furthermore, each of these components is influenced from outside the application itself by elements such as: personality; job experience; the nature/intimacy of the campaign itself; and maturity (both in the sense of using Journey Builder and running a marketing campaign in general). Any failure is exponential, and exponential failure leads to a lower chance of success. To successfully increase marketer confidence at the time of hitting send, we needed a solution that either simultaneously tackles as many of these issues as possible, or tackles one of these issues very, very well.
Design Process (Overview)
Meet Switchboard
Switchboard is an ecosystem solution that lives inside the Journey Builder application as an expansion to the existing journey testing functionality.
Enabled by Einstein, Switchboard allows users to launch simulated campaigns against demographic, data sourced profiles in order to see predictive results that indicate how different campaigns might fare against various customers. Marketers can interpret both these results (and subsequent real campaign results) via an updated analytics page.
Profiles vs. Personas
Active vs. Passive
With Switchboard, we re-imagined the Marketing persona as a Switchboard profile: a persona-like artifact built from client data and meant to be used actively, inside the Journey Builder application.
Switchboard Profiles have names, faces, hobbies, interests, hopes, and dreams. They’re also built from the data which arose from pre-existing, client specific marketing campaigns.
Switchboard Profiles are therefore almost entirely tailored to a Marketer’s specific audience - and can be targeted via simulated campaigns to generate simulated results.
Let’s talk a little bit more about tailored Profiles, and why it matters.
Tailored vs. Generalist
One way profiles differ from personas is in their specificity and nuance. Consider: a customer who shops a lot at Nordstrom is different than a customer who shops a lot at Macy’s (in a few significant ways).
Consider the Venn diagram to the left: with a traditional persona, Nordstrom Customers and Macy’s Customers would probably be represented by a persona which captures their common denominator (the blue overlap).
While a generalist persona might smooth over such nuances, a Switchboard Profile is tailored specifically with such nuances in mind, aiming to capture the qualities exclusive to the green and purple areas of the diagram.
Meaningful Analytics
Filter Your Data Inside Journey Builder
In our interviews, we found that current SFMC users are burdened with a clumsy, limited data analytics functionality within the Journey Builder application.
One participant went so far as to tell us that, following a campaign, one of her full-time co-workers had to download their campaign result data, and then spent four weeks, eight hours a day, parsing their data in Excel.
“I’m told Salesforce Marketing Cloud can do everything. So I expect it to everything. Yet it can’t even do this basic functionality.”
High Granularity, Out of the Box
The best way for Salesforce to provide Karen with the tools she needs to better understand her previous campaigns is to give her the power to sculpt her data as she sees fit.
Our interviews revealed that different marketers will live very different professional lives, with different goals and different KPIs (key performance indicators).
Rather than try and account for every type of KPI that might exist, as part of the Switchboard overhaul, Salesforce could provide Karen and other marketers with the ability to manipulate, filter, scope, and examine her data (both real and simulated) without ever leaving the Journey Builder application.
High Granularity + Broad Scope = Valuable Data
Design Process (Focus)
Exploratory
Design Collections
Literature Review
Mental Modeling
Stakeholder Interviews
Journey Mapping
Generative & Evaluative
Design Fiction
Rapid Ideation
Experience Prototyping
Testing (Concept)
Primary Constraints & Considerations
As part of the design prompt we were intentionally given very limited access to Journey Builder and the Salesforce Marketing Cloud.
In accordance with the Salesforce Design Prompt, we designed our solution around a pre-existing Marketing Specialist Persona named Karen.
Since none of the people in our group were familiar with the Marketing profession, we were faced with the need to learn as much as possible as quickly as possible.
As part of the academic rigor befitting a graduate program, we were required to motivate our design arguments with Mihalyi Chikzentmihayli’s theory of flow and Abraham Maslow’s theory of self-actualization.
Triangulation
To help mentally position ourselves as we began to imagine a solution space in a foreign career, we collected other pre-existing, industrial, multi-faceted, large scale, broad reach designs for an exemplar analysis.
Collection 4 Direction
Our early design collections revealed a constellation of emergent exemplary themes which we diluted down to a primary group of eight shared aspects.
Eight Aspects of Good Design
As we familiarized ourselves with the reality of Karen’s experiences as a marketer, we articulated eight potential aspects of good design to try and bring forward into our final solution.
First Frame: Marketer as salesman
What are the differences between a marketer in 2019 and a door-to-door salesman from the 1950s? What might we learn by exploring these differences?
Second Frame: Marketer as storyteller
When asked why they loved their jobs, marketers indicated that they loved telling the story of a product or experience.
Tribulation
After a literature review and early interviews with stakeholders, we generated a “Mini-Mental Model” visualizing how Karen mentally experienced the various steps involved in running a marketing campaign.
MINI-mental model (OVERVIEW)
The Mini-Mental Model is a scrappy variation of the Mental Model method attributed to Indi Young by Marc Hassenzahl in his book, User Experience Design.
Early sketches were less interested in chronological order; for the purposes of understanding, however, we represent the mental towers in chronological order here.
MINI-mental model (insights)
To elicit insights from the Mini-Mental Model, we simplified and reframed the mental towers as a series of questions in coordination with interview participants. We framed our questions from the perspective of how these stages interacted with a marketer’s state of flow.
Our hope was that by reframing each of these towers as a question, we might keep a better grip on Karen’s experiences.
Mini-Mental Model (Focus)
Following our first round of formal interviews (to confirm the accuracy of the Mini-Mental Model), our participants were able to isolate the portion of the Marketer’s journey that gave them the most anxiety - an insight which would circle back around as we built our Confidence Experience Map.
It was at this point that stakeholders informed us that to assume they were able to efficiently analyze their results (know whether their campaign was successful) was a big assumption.
Invigoration
Building on our insights from our Mini-Mental Model - and in conjunction with stakeholder interviews - we built a Experience Map within which we visualized the trajectory of Karen’s confidence at various points in a Marketing Campaign, including pre- and post- campaign launch.
Among the Confidence Valleys were four primary pain points:
Trying new features is daunting (fear of failure)
Technology cannot yet check for contextual, non-binary problems
Building a journey is tedious and difficult to learn
Parsing data and deriving meaning from completed journeys is difficult
And a fifth pain point (not mapped) that came up in multiple interviews -
Variations on a Theme
Now equipped with clearer insights and pain points, we conducted rapid ideation exercises as a group around the idea of addressing pain points by framing the marketer as a storyteller.
Three primary solutions emerged from this exploration.
The Glamogram
The Double-Triple Checker
The Testing Lab
Idea 1: The Glamogram
If we imagine a marketer as a storyteller, and what they’re selling as a story they’re telling, then current marketing campaigns have no real endings.
No endings means that the climax (launching a campaign) has no falling action, no denoument (no closure). What if we could add punctuation to a the never ending sentence that is 21st century marketing?
With the Glamogram, Karen is able to “meet” her customers after successful campaigns via mixed media photoessays called Glamograms filled with stories of their experiences that she made possible.
Source Method: Design Fiction, Stakeholder Interview
Primary Pain Points Addressed: 4, 5
Idea 2: The Double-Triple Checker
Launching a campaign is daunting - especially when Karen is reaching out to millions of clients via their cell phones. What if there was a way for Karen’s team to more easily vet and check her campaigns prior to launch?
With an embedded vetting system, we envision a Journey Builder functionality which allows Karen to seek feedback on campaigns from her teammates prior to launch.
This allows Karen to feel that her team has her back, frees her up to try new features, and gives her the confidence that as many people have had eyes on her work as possible.
Source Method: Stakeholder Interviews
Primary Pain Points Addressed: 1, 2
Idea 3: The Testing Lab
Using new tools that might help you be successful is a hard sell when the cost of failure might be your job. What if you could test out every step of a journey (as well as new features) in a safe sandbox environment?
With the Testing Lab, we envision an enhanced Journey Builder’s testing functionality that shows real-time changes to predicted KPIs as Karen changes Journey nodes within a sandbox. This allows Karen to engage with the full portfolio of what’s on offer from the Salesforce Marketing Cloud.
Source Method: Stakeholder Interviews, Journey Map
Primary Pain Points Addressed: 1, 4, 5
Experience Prototyping
To test our concepts, we had to get creative as to ways we might test the “experience” of using them, rather than simply putting digital prototypes in front of our stakeholders.
For the first Glamogram, we walked our testers through a scenario wherein she was a marketer using the Glamogram tool itself.
For the Testing Lab, we developed an experience prototype using a labyrinth.
Revelation
To effectively test our Experience Prototypes, we had to conduct our tests in a risky and carefully executed fashion - effectively running two tests simultaneously, by running one test within the other.
Test 1: The Glamogram
Unlike the Testing Lab - which required us to get a bit more creative in our approach - to convey the idea of how a Glamogram worked we leaned on our storytelling and graphic novel roots. (A special thanks to my teammate, Jingyao Liu, for her wonderful illustrations.)
What We Did
Participants were told to imagine that they were at the very end of a new campaign launch. To commence this scenario, they were given thirty seconds to navigate an Unmarked Labyrinth before they had to press “send”. (See Below)
Participants were then told that time passed, and that over the duration of that time, things were happening with the customers to whom they had sold some concert tickets.
As we walked them through the scenario (shown right, click in to see the entire progression) we provided them a mix of illustrations and high fidelity wireframes.
At scenario’s end, we asked for unguided feedback - and then asked, “do you believe this would this would make you feel better about hitting send?”
What We Learned
Our participants thoroughly enjoyed the idea of a Glamogram.
One of the primary issues with the Glamogram, however, was that it assumed a certain distance from/isolation in regards to the customers themselves.
If a marketer is overinundated with their customer base and interfaces with them on a regular basis, therefore, the Glamogram risks backfiring.
Other participants voiced concern that even the incentive of free tickets would not be enough to convince customers to participate.
Test 2: The Testing Lab
One of the biggest challenges we faced during our Experience Prototyping stage was finding a way to communicate the impact of our Testing Lab solution.
What We Did
We made two labyrinths: one with no markers or indicators of how to reach the center.
We put the labyrinth with no markers in front of the participant and asked them to find the center.
We then presented them with our Glamogram Scenario, and asked for feedback to the Glamogram concept. (e.g. Would you say your confidence is higher?)
Finally, we presented participants with a labyrinth with routes marked to indicate likelihood of reaching the center.
We asked, “Would the labryinth without markers and the Glamogram, or just the labyrinth with markers give you a greater sense of confidence in your job?”
What We Learned
Participants were able to follow the implication of the labyrinth test.
Participants did feel that the use of a labyrinth oversimplified the complexity of the challenge, but felt that the oversimplification highlighted issues they didn’t know they had.
By “pushing against” the prototype, participants were able to speak more clearly to the reality of their jobs.
Testing an Experience Prototype is harder than testing an interactive digital prototype!
The problem isn’t what we thought
Our primary finding over the course of our experience testing was that one of the primary pain points currently plaguing Journey Builder was an inability to adequately parse data from campaigns in the native Journey Builder application’s analytics page.
Our goal, therefore, of offering marketers the ability to run simulate campaigns had run into an unforeseen complication: it doesn’t matter how good the simulated data is - if a marketer cannot parse said data, it is useless.
“It makes absolutely no sense to me. I had the very very very basic assumption . . . [that I would be] able to slice and dice [my data].”
- SFMC User (CRM Marketer), Interview 2
Lessons & Reflection
Lesson & Constraint No. 1: We’re Gonna Need a Bigger Boat
Given the complexity of the Salesforce Marketing Cloud, the size of Salesforce’s audience, and the scope of the problem space itself (flagging confidence), we realized very quickly that our best chance was to either try and do one thing very well, or do several things simultaneously as part of an “ecosystem solution”. While at first we were inclined to “aim small, miss small,” this approach changed as we came to better understand the problem space and the stakeholders involved.
Sometimes, the best way to solve a compounded problem is with an ecosystem of small solutions.
Lesson & Constraint No. 2: No Tool For You!
Our partners at Salesforce (which included UX Designers and UX Researchers) was adamant that our solution should be an experience design, and as such might incorporate screens, but should not be driven by or dependent on screens to function. As part of the challenge, therefore, we were given very limited access to Journey Builder and the Salesforce Marketing Cloud.
“Find your answers out there, not in here.” - Salesforce UX, when asked to see a demonstration of the journey builder application
Lesson & Constraint No. 3: Not One Company, But Several
Fun fact: Salesforce is not one company, but a confederation of companies all bound together under the Salesforce logo. While at the beginning of our project, we had the idea that Salesforce representatives would know what had already been attempted in our problem space, in reality, this simply wasn’t the case. With a company this large and dynamic, it’s not uncommon that solution efforts die without ever breaking out of their silos.
Learning to discover pre-existing efforts is a vital skill for any UX designer; ask questions! Dig deep, and find out what work has already been done at your organization.
Reflection
I’m going to be blunt: telling the story of Switchboard - the prompt, the shape of the problem, the story of our voyage - has been, for some reason, one of the most difficult tasks I’ve undertaken.
Why is this?
Why does the story of Switchboard prove so difficult to recollect and to share? As best as I can tell, its because a story wants to be linear, and this one happens to go in loops.
Yet that’s UX design for you - dynamic, shifting set of looping recursions which (somehow) end up looking like a real product. Switchboard, for what it’s worth, proved compelling enough to our sponsors that they’ve requested an additional meeting to learn more about it.
That meeting will happen sometime this January.
Would You Like To Know More?
While there won’t be a Longform for the Switchboard project like there was for Eclipse, there will be a Retrospective (such as the one I’ve been assembling for HPE) for the work I will be doing this semester with Salesforce via the 2020 Salesforce x IU Externship.
This will be presented as Retrospective No. 2., and will include:
Non-NDA Method Practice
Non-NDA Development of the work done on Switchboard
Lessons Learned/Reflections