Variable Improvements
Keep pushing small improvements
🔖 A little bit of background…
What is Variable
Variable is the key object to bridge the gap between raw data and the world of business. With rich and flexible transformation functions, marketing analysts could turn discrete and abstract columns (e.g. item_price, total_cart_item, order_status)to digestible business definitions (e.g. Valid Order Price) ready for marketers to use.
Current solution cannot scale as user base grows
However, as the user base ( ~2 → ~10/ per customer) and Variable usage (50+ →500+/per customer)grow, clutter appears.
Analysts find it hard to organize the Variables they’ve created in a flexible way and marketers struggle to find the Variable (or worse, have no idea whether it exist or not)they want when building Audiences and configure export settings.
It became urgent for us to understand current problem space and make improvements progressively .
👉 Understand the problem space
The big picture
In order to better understand the problem space, I asked 3 questions:
What’s the ultimate goal of this connected system?
What are the core elements involved in the Variable workflow
What are the connections/interactions between elements
For the Variable clutter problem in specific, the goal is to help analysts better manage the list and, ultimately, make it easier for marketers to find the variables they want when defining Audiences or configuring export settings.
Now let’s look at the elements and connections…
If we only consider the elements in the Variable, it’s simple.
But if we take a step further and ask how Variable interacts with different user groups and product layers (e.g. Audience definition, Export settings), what looks like a straightforward problem at the outset becomes much more complex :
System mapping
Detailed analysis: User Journey Map
After having a clear high-level understanding of the scope and direction, I created a more detailed user journey map that tied together the desired outcomes and qualitative insights from customers for each touch point within the workflow, creating a full understanding of how customers are creating/using variables and how we want them to be doing it.
The journey map is useful in 2 ways:
Keep teams on the same page when talking about variable experience
Uncover new possibilities and inspire creative ideas
✏️ Draw a roadmap
Tag and identify themes
I tagged and grouped the potential projects based on their end goal as well as dependency and identified 3 major themes:
Better browse, search and filtering experience for both analysts and marketers
Avoid Variable duplications at first place
Encourage archiving
One interesting thing I learned from the tagging process is that, while there were projects dedicated to address certain user challenge in one specific touch point, some projects across different touch points (for different pain points) need to be merged as one bigger initiate to be valuable. This “value dependency” could potentially change the project scope and impact the its priority on the roadmap.
Prioritize projects with cross-functional teams
After shuffling projects under different themes and merging relevant ones, I collaborated with Product, Engineering and Customer Engagement teams to evaluate and draw our roadmap by asking following questions:
How urgent is the pain that this improvement is tackling?
Do they have an alternative?
Can we re-use existing AIQ patterns or we need to create a new flow?
What’s the estimated design scope?
What’s the estimated implementation scope?
In order to better organize the roadmap, we put possible improvements into 3 categories.
Usability & Product consistency
New capability, high customer value & medium
Backlog (for various reasons)
Usability & Consistency
Projects related to Usability or product consistency. If good patterns already exist, then it’s relatively low implementation effort and we’d like to prioritize the project. If it’s a pattern we want to improve globally (aka. we know we want this change but it requires more research and validation), we will put it on the roadmap as initiatives for later.
New capability, high value, medium level effort
Some projects require adding new capability to the platform. While it’s no trivial effort to make it happen (full-cycle), we will still prioritize some high-impact, medium-sized ones.
Backlog
Projects will be put into backlog for various reasons. Backlog means they are not on the roadmap yet, but could be promising candidates.
💪 Execution and Impact
With the project roadmap, Full-stack Engineering team started to loop it into the sprint planning and tried to fit those small projects into their busy schedule.
Design team also started to practice this method on other projects at hand(e.g. provide suggestions on “next action” after Audience creation).
Now even though we’ve only launched a handful of improvements (e.g. “specify Variable purpose” “show Variable usage” etc.), we’ve already seen a good amount of usage, a less cluttered UI, a more consistent product and more importantly, happier customers! This really makes us look forward to measuring the impact of all the projects going forward.
💡Reflections
Uncover new possibilities: A system in place can help spot gaps and inspire creative ideas to make the connections
Re-use existing patterns: Always consider whether we can re-use existing patterns first before crafting a new one (although it is tempting and exciting)
Collaboration: Keep involving Product, FS and Field to help merging, scoping, and prioritizing small improvements
Last updated
