my roles: Strategy, User Research, Interaction Design, Visual Design
Automations based on customer feedback
In this project, I worked with our Director of Product Management to design a canvas experience for Admins to build automation "Workflows" using triggers and actions available from a platform we would build over time.
BACKGROUND
DESIGN PROBLEMWe observed that we lose customers due to cost (they have to pay for our professional services team or partners to implement their feedback programs), perception that it’s costly, and an inherent desire to control and configure this themselves.
MEASURES OF SUCCESSHow might we allow Admins to configure their own automations and inner-closed-loop processes, such that:
|
I started design explorations in low fidelity in order to maximize creative options before narrowing down on a design direction. I included Product and Engineering stakeholders in the process, which helpe validate my understanding of the user needs and the problem space early.
The exploration facilitated customer interviews and I identified several open questions. Inspired by Lean methodology, I advocated to get answers to the riskiest of those open questions early. If we get it wrong, how bad would it be? If bad, let's test now to ensure efficient delivery with as few pivots as possible. As such, I advocated testing the following open questions:
Is it more natural for users to configure automations in a form or visually?
One concept or two?
Do admins want both a simple (If this, then that) rule builder for most automations and a complex (if this, then that, and that...) automation builder for the rest?
If visually defined, what should each box represent?
If visually defined, what interaction flow is more intuitive for building an automation?
I created 3 low fidelity prototypes that incorporated one or the other factor. Distributing experienced and first-time users across tasks, I moderated an A | B | C between-user test.
Research Findings:
|
From these findings, I came up with a single flow in medium-fidelity, combining interactions and paradigms that tested the best with users.
The result was a single concept, a Workflow, that users could build in the product suite's first canvas experience. The canvas started with placeholder atomic elements, giving users a way to intuitively discover what they can build in context.
The result was a single concept, a Workflow, that users could build in the product suite's first canvas experience. The canvas started with placeholder atomic elements, giving users a way to intuitively discover what they can build in context.
As the user builds their Workflow, they'll be able to continue to build and update in context.
When interaction design was about 80% close, I partnered with our in-house visual designer while completing the more complex interaction designs.
I went through a similar iterative exploration to come up with a visual design that matched our brand and would scale to a growing set of triggers and actions.
I went through a similar iterative exploration to come up with a visual design that matched our brand and would scale to a growing set of triggers and actions.
Switching our team from UXPin to Figma mid-project, my prototyping skills transferred in less than a month. As I worked through high-fidelity options, I created Figma components to ensure efficiency in the design process and improve quality (AKA efficiency in development).
Throughout the process, I held design reviews with Product, Engineering, Leadership, Design, Visual Design, Content and more. We kept an eye on the goals, our timelines, and how we can iterate towards this vision in increments. As such I made sure to "park" representative mockups for future iterations.
While we couldn't contain complex forks in the logic in our MVP, I still wanted to make sure the design would scale to future iterations. I created a mockup of the idea using our latest in high-fidelity to make sure our design decisions would scale and track the improvement for later.
We also knew that our technology limited customers from being able to create multiple cases from the same trigger, and would not be possible in in our MVP. I made sure to spec that once a "Create Case" action was added to the Workflow, the action was no longer an option to add. Then I created this mockup of the future state for us to track and remove this limitation in a future increment.
The first triggers for the MVP we decided would be either on a schedule or when a Medallia Survey is completed by a user of our customer (when feedback comes in). This mockup is to track the next iteration of the platform, a new trigger for when information is updated on a Salesforce.
We learned early from our user research that Admins wanted a starting point to be able to build a best-practice automation with confidence. While users found the canvas experience intuitive, they had trouble thinking on their own of what they should configure in the first place. In particular, once the initial case was created for closing the loop, what's the best way to automate an escalation path if the frontline employee had not taken action yet? How long should the delay be? What actions should we take?
I proposed the idea of creating out-of-the-box templates as a starting point for well-known use cases. We agreed this would need to be a future increment. I made sure that the build-from-scratch MVP would scale to providing Templates in the future and created this mockup to track the idea.
Without this user research, engineering may not have made sure an "invalid" item could be saved. Partnering with engineer, we figured out how to display a partially completed element upfront, which gave us our zero-state for a new Workflow in the MVP and set us up for Templates later.
I proposed the idea of creating out-of-the-box templates as a starting point for well-known use cases. We agreed this would need to be a future increment. I made sure that the build-from-scratch MVP would scale to providing Templates in the future and created this mockup to track the idea.
Without this user research, engineering may not have made sure an "invalid" item could be saved. Partnering with engineer, we figured out how to display a partially completed element upfront, which gave us our zero-state for a new Workflow in the MVP and set us up for Templates later.