SalesForce Marketing Cloud Journey Builder

From summer 2016 to early 2017 I worked as the design lead for SalesForce Marketing Cloud Journey Builder canvas interactions. Journey Builder is a marketing automation tool that visualizes customer interactions as branching paths. Users build journeys with an intuitive drag and drop interface.

DesignMap had worked with SalesForce Marketing Cloud for around 8 years, when they had became the design firm of record for a young startup named ExactTarget, who were acquired in 2013. In the intervening years the challenge was to balance the increasing demand for fast-paced incremental improvements while securing time to solidify future facing but less clear feature ideas.

SalesForce was also preparing to bring all design work in-house, and I was one of the last external designers on the project. This is a “highlight reel” of my experience.

Journey Builder Canvas

A journey in draft state with the left panel open.

Marketers were building immense, complex journeys that were brittle and difficult to understand. To fix this, users were demanding the ability to link a series of smaller journeys in a linear fashion. They also wanted the ability to set create criteria that would eject customers from a journey once they met it (wherever they were in the journey). These ideas made intuitive sense, and seemed simple on the surface.

Exit Scenario

A scenario we wrote to help us process the problem. This was the way-too-complicated to produce version.

When thinking about linked journeys we stepped back and approached the problem by writing scenarios and building models illustrating the potential flow of a user’s customers. As we did this, we discovered that any solution would move complexity upstream and would require us to build complex tools to help a user guide customers through their journeys. We decided to focus on a simplified version for v1 and focus on the exit criteria needed to move customers between journeys.

Simple Exiting

A (relatively) simple version of daisy chaining.

As for exit criteria, we saved time and dev cycles by unifying the experience with another feature, goals. Users could already set data attribute-based goals for their customers to gauge Journey success. We realized that a “goal” and  “exit criteria” were nearly identical, and went about simplifying and reusing the existing pattern with slight modifications as a v1.

Goal Redesign

A v1 redesign of goals which we also used for exit behavior.

We also sketched a concept called “trigger paths”. A trigger path would be a configurable mini-journey that could exist system wide and provide a more rich interaction than simply ejecting a user or moving them into a new journey. For example, if a high value customer suddenly made a huge purchase, a sales rep could be notified to make contact before the customer exited out of the “sales” Journey. 

Trigger Paths

An idea we had for an advanced version of exit creation.

Our work paved the way for simple short-term solution that could be developed quickly, while pointing towards a more industrial strength version later on.

Next, Journey Builder was about to get a flood of new options for inserting customers into Journeys. This came as a direct result of the being integrated into SalesForce’s massive data pipeline. Our concise kit of tools in the left column was going to be swarmed with new options. This would affect both my work and another designer who was working on data integrations, so we collaborated on the solution.

Research

An overview of the research we conducted.

We decided first to get ahead of the issue by experimenting with various models of interpreting the sources of data. We started with a marathon session where we “sketched” sorting methods. From there, we proposed the most promising concepts to leadership and pushed for user research to validate our ideas.

Though limited to internal users and not clients, soliciting feedback from internal experts helped us form an opinion about how users perceived Journey Builder. Hearing from others within the organization helped us form consensus and gain credibility with our project managers, and we were able to build a framework that both limited complexity and provided clear sorting logic as options expanded.

Repositioning

We considered abandoning the left column and placing entry sources on the canvas. We rejected this idea as it introduced an unfamiliar pattern and hid necessary information.

Channels Concept

A categorization concept we proposed and adopted. Dragging the green circle on to the canvas reveals the child options in a modal.

Finally working on Journey Builder was an exercise in managing complexity, as an active dev pipeline, work that overlapped with other designers, and new feature demands all had to be actively coordinated. I worked heavily on improving my project management techniques in response.

I also read Essential Scrum cover to cover. It wasn’t riveting by any means, but it helped me empathize with my product managers. 

During the project I created three different tools with distinct purposes. The first was a spreadsheet that tracked dev and design completeness. It was very granular and was used during weekly meetings with the my immedidate team. The second was a trello board, which we attached mockups and links to and provided way for project managers and devs alike to find what they needed without interruption. Third was a rather attractive poster of all the upcoming features, which helped non-team members understand our team’s feature roadmap.

Prioritization

The top third of a poster I’d regularly make and distribute.

 

Trello

Our (my) meticulously maintained trello board.

If all of this seemed like a lot of work, it ultimately saved me time by being able to coordinate transparently across teams and locations. Much of what I created here has become templated and regularly reused to help me sort through the nitty gritty of managing my workload.

Journey Builder was, in the end, an exercise in designing incrementally while pointing the way towards the future. The demands of the users made it necessary to produce a steady stream of useful if incremental updates while making sure they didn’t get in the way of larger initiatives.