My Role
Role: Senior Product Designer
Team: Collaborated with PM, Developers, Technical Writer, and Implementation Engineers.
Responsibilities:
• Led end-to-end product design from discovery to delivery.
• Collaborated with Product Manager on product strategy, scope, and roadmap.
• Collaborated with Lead Developer on feasibility and stress testing logic
• Planned and conducted user research and usability testing.
• Created UX artifacts, prototypes, wireframes, and userflows
• Facilitated cross-functional workshops and design critiques.
Role: Senior Product Designer
Team: Collaborated with PM, Developers, Technical Writer, and Implementation Engineers.
Responsibilities:
• Led end-to-end product design from discovery to delivery.
• Collaborated with Product Manager on product strategy, scope, and roadmap.
• Collaborated with Lead Developer on feasibility and stress testing logic
• Planned and conducted user research and usability testing.
• Created UX artifacts, prototypes, wireframes, and userflows
• Facilitated cross-functional workshops and design critiques.
The Problem
Making the Easy Difficult
For enterprise marketing and data analyst teams, event tracking on their apps and websites is a key component into gaining insights into their user base. This enables customized experiences, detailed usage metrics, and the ability to connect to downstream services in the data pipeline. However, there were a few key problems derailing Event setup:
• The creation and management of these Events within the Tealium application was very complex and technical.
• This led Marketers to rely on development and engineering resources to implement even basic click tracking events like button clicks and video plays.
• The creation and management of these Events within the Tealium application was very complex and technical.
• This led Marketers to rely on development and engineering resources to implement even basic click tracking events like button clicks and video plays.
The Challenge
Breaking Down Technical Barriers
Breaking Down Technical Barriers
The objective of the project was to remove these technical barriers and simplify the process of creating and managing Events.
A central theme from our early research was:
"How might we make Event creation and setup easy enough for Marketers to not depend on Developer resources?"
Given that creating events is such an important aspect of customer data management, we felt that this core workflow should be as quick and intuitive as possible.
Look, Listen, and Learn
Insights from Interviews and Metrics
We started our discovery phase by conducting interviews and gathering data around usage of the product to better understand the existing process and pain points involved.
Insights from Interviews and Metrics
We started our discovery phase by conducting interviews and gathering data around usage of the product to better understand the existing process and pain points involved.
Identifying Participants for Qualitative Interviews
To identify participants for qualitative customer interviews, we used metrics to determine the top accounts in terms of event usage within our platform. Our Product Manager then reached out to contacts for these accounts to schedule qualitative interviews with 8 of the top 10 accounts.
Findings from Qualitative Interviews
• Lack of Developer Support: Marketers and Data Analysts were heavily dependent on development teams and in smaller teams they lacked the support needed to implement.
• Too Technical: Less technically savvy users were frustrated with the JavaScript knowledge needed to create and support Events.
• Confusing Workflow: Users were confused by the existing workflow as it dead-ends and doesn’t provide a clear link to dependencies or next steps.
User Metrics
We also took a closer look at some of the usage metrics around the existing Event creation and management within the platform. Some of the highlights of these metrics we found were:
• High JQuery Dependency: Close to 50% of all Tealium Accounts used at least one JQuery Events Extension.
• High Volume of Support Requests: Customer Success teams were getting a high number of support requests for setting up basic events.
• Negative Feedback on Events: We were getting a high volume of votes from users in our Product Idea user board around improvements needed for Events.
• High Workflow Dropoff: There was a high volume of drop off in user funnels around creating and editing in workflows.
Journey Mapping the Existing Experience
As a result of customer interviews, feedback from CS teams, and internal conversations, we created an in-depth Journey Map. This helped map out the existing process, pain points, and areas of the product involved to create and implement Events.
Definition
Setting our design goals
Before diving too deep into solutions and to help bring clarity and simplification, we broke down the major design needs into three key areas:
• Introduce Events by bringing Events into the forefront as a standalone reusable element in the product.
• Create a Simplified Event Creation Process with a redesigned event creation process, user experience improvements and enhanced capabilities.
• Create a Simplified Event Creation Process with a redesigned event creation process, user experience improvements and enhanced capabilities.
• Integrate Events into existing workflows so it works for existing and new customers while limiting the scope of the redesigns.
Establishing Success Metrics
We also established benchmarks to define success metrics around event usage, adoption and level of support customers need:
• Decrease in usage of existing jQuery events.
• Adoption of new Event Types in the product.
• Less support tickets to Customer Success teams around basic Events
• Decrease in usage of existing jQuery events.
• Adoption of new Event Types in the product.
• Less support tickets to Customer Success teams around basic Events
Design Process
Introducing Events as a Reusable Element
Armed with these discoveries and insights, we sought ought to answer an important question:
"How might we help Marketers and Analysts configure and manage events using an intuitive, code-free workflow?"
Events were originally a subset of a larger feature called Extensions. The first step was to brainstorm how Events would fit in as a main element within the product.
Events would need to be easily accessible but how?
Events would need to be easily accessible but how?
After several iterations we decided it should be a standalone element with it’s own tab in the main navigation. Events could then be individually created, managed, and easily associated to other elements such as Rules and Tags. Leveraging our existing Design System components, we were able to quickly land on a design for the Events tab and table that would serve as the hub to create and manage Events.
An improved, robust rule builder for Event conditions and Tag application
The next step was to design a logic builder that now included Events AND rules that could be used in combination to fire tags. After analyzing customer account metrics, we found that could customers could have hundreds of rules and often up to 10 rules were used in the logic statement.
The next step was to design a logic builder that now included Events AND rules that could be used in combination to fire tags. After analyzing customer account metrics, we found that could customers could have hundreds of rules and often up to 10 rules were used in the logic statement.
Taking this in to account, we had to design a logic builder where users could quickly select from large amounts of existing Events and Rules to pull into the logic statement to build complex conditions.
Starting with low fidelity wireframes, we began to block in the major components and user needs of the logic builder:
• Canvas area for logic building
• Canvas area for logic building
• Detail view of individual Rule or Event in use
• Summary of logic statement
One of the key problems in the initial designs was selecting the the rules and events to pull into the logic:
Users could have large volumes of rules and events, making a dropdown selection pattern cumbersome.
Users could have large volumes of rules and events, making a dropdown selection pattern cumbersome.
As a potential solution, we explored an alternate interaction pattern:
Instead of using dropdowns to select from large amounts of Rules and Events, we created a drag-and-drop pattern as a method to pull them into the logic.
Instead of using dropdowns to select from large amounts of Rules and Events, we created a drag-and-drop pattern as a method to pull them into the logic.
Our finished redesigned Rule Builder provided several improvements:
• Bigger and more intuitive UI dedicated to building complex logic statements
• Insights and context for the Rules being used.
• Better searching and filtering options while expanding on the condition logic and nesting.
• Expanded logic capabilities with nested condition blocks.
• Bigger and more intuitive UI dedicated to building complex logic statements
• Insights and context for the Rules being used.
• Better searching and filtering options while expanding on the condition logic and nesting.
• Expanded logic capabilities with nested condition blocks.
Integrating Events into Existing Workflows
To help understand how Events fit into existing workflows within the product, we created userflow scenarios with a different order of operations to visualize how Events could be configured in any order necessary in a bi-directional workflow.
Validating our Ideas
Testing The Designs
After initial rounds of low fidelity wireframes, we wanted to validate that the main components of the design were understood and fit the most common scenarios of logic combinations. We were looking to answer key questions including:
• Does the logic builder handle complex combinations of rules and events?
• Is there enough information provided to understand the elements being used?
• Is the new interaction pattern of dragging and dropping rules and events intuitive?
After initial rounds of low fidelity wireframes, we wanted to validate that the main components of the design were understood and fit the most common scenarios of logic combinations. We were looking to answer key questions including:
• Does the logic builder handle complex combinations of rules and events?
• Is there enough information provided to understand the elements being used?
• Is the new interaction pattern of dragging and dropping rules and events intuitive?
We used a hypothesis driven method of establishing a theory and hypothesis, creating an experiment to validate it, and coming to a conclusion based on the findings.
Example user test giving a scenario for the user to walk-through and subsequent feedback and surveys as they progress.
Testing Findings
Feedback and Insights
Between user testing the designs, internal interviews, and stress testing the logic we were able to confirm that were on the right track. Our summarized findings found that:
• Users understood what the Rule Builders is, how it works, and the steps involved
• The nested conditions and order of operations were well understood
• The drag-and-drop pattern on the right was intuitive and easy to quickly find and add selections to logic statement on the left
Between user testing the designs, internal interviews, and stress testing the logic we were able to confirm that were on the right track. Our summarized findings found that:
• Users understood what the Rule Builders is, how it works, and the steps involved
• The nested conditions and order of operations were well understood
• The drag-and-drop pattern on the right was intuitive and easy to quickly find and add selections to logic statement on the left
Delivery
Final Designs and Implementation
To help communication with developers and other team members, I provided designs showing the different potential interaction and pages states as well as annotation of key details. The goal was to not get too heavy on specs but help provide clarity to help the implementation process.
To help communication with developers and other team members, I provided designs showing the different potential interaction and pages states as well as annotation of key details. The goal was to not get too heavy on specs but help provide clarity to help the implementation process.
Before and After Comparisons
To visualize the changes and impact, here's a direct comparison of some of the key redesigned screens in the workflow.
Before
After
Launch and Impact
More Events, Less Code
• The release exceeded the goal of an adoption rate of 15%. Within 90 days of releasing the feature, 27% of available accounts had saved an event.
• 768 Events were created in the first 90 days of release.
• A post launch survey poll revealed that the majority of users had a favorable experience using Tealium IQ Events (59% rated the new experience either a 4 or 5 out of 5.)
“TiQ Events let me stand up one of our properties a lot more quickly than I would have been able to otherwise. I’ve just used the functionality and so far it's great!"