The main value add of the Magnetic acquisition was its proprietary targeting and decisioning technology, which would become an integral part of a larger suite of products and services, collectively referred to as Deloitte Human Experience or Hux.
The goal of Hux is to help companies connect disparate data sources, automate targeting and decisioning, and enable seamless audience delivery to orchestration and BI tools with the aim of fostering better experiences for their customers at scale.
Role - Head of Product Design
As Head of Product Design for Hux, I had the privilege of leading design for Hux Audience, a stand-alone self-serve audience-building tool that helps marketers get better performance out of their media buying campaigns. My team consisted of myself, a Technical Designer, and three Tableau Developers.
The concept of Hux Audience is fairly simple. A tracking pixel is placed on the client’s website which collects data about the traffic that visits that site and converts. The conversion URL’s from that site and targeting parameters are specified on the Hux Audience Setup screen. Then a look-a-like model consisting of similar audience profiles is constructed. Finally, the audience is broken down into segments, which are eventually delivered to DSP’s like TradeDesk where they do wonderful things like increasing conversion rates.
The basic premise of Hux Audience is nothing new. I.e. Targeting & Segmentation, Conversion optimization, etc. Just about every major ad-tech tool out there has some kind of answer for this. So why did we build it?
Before my team was acquired by Deloitte, we offered a similar product at Magnetic as an alternative to our media buying tool. At the time, we had a lot of conversations with clients that went something like, “…we’d love to use your DSP, but we already have one. Is there any way you can help our current DSP get better performance without us really having to do anything?” That was the beginning of Hux Audience.
After our acquisition, Hux Audience served as the perfect proving ground for the technology we would use in our larger CDP offering. So even if we couldn’t sell it, we could still use it to validate the decisioning tech we would use for the rest of the Hux platform.
Hux Audience was designed and developed for three different types of clients:
Companies with in-house adtech and martech teams
Companies that rely on agencies for advertising and marketing
In order to build a scalable product, we had to focus on use cases that could accommodate personas and their varying needs across all three client categories.
Because we were leveraging existing technology, and we wanted to minimize backend work, the deliverables for Hux Audience were largely driven by technical constraints. Over the course of my 15+ year design career, I had never come across as a set of technical constraints as bizarre as those for the segmentation component of Hux Audience, which were as follows:
Users need to be able to view the following predictive insights in a table as they configure their segments: Reach (uniques), Predicted # of Conversions, Predicted Conversion Rate, and Conversion Propensity (the likelihood of someone from a segment converting, compared to likelihood of the average audience member converting).
Audiences are comprised of deciles that can be combined into segments, each with their own predictive analytics. This means predictive analytic totals and averages must be displayed at the decile, segment, and audience level.
Segments CANNOT be comprised of non-sequential deciles.
Audiences CANNOT be comprised of non-sequential segments.
The 10th decile (made up mostly of worthless profiles) must be visible, but must not be available for segmentation.
There were about a hundred more constraints, but you get the idea. After countless hours of stakeholder interviews, white-boarding, wire-framing (the artifacts of which I’ll spare you), and running around the office asking people “what do you think of this,” I arrived at a solution 18 of 20 user testers preferred, which we’ve affectionately come to refer to as “The Spreader”.
The other big piece for this project was Predictive Insights, which would provide users a more comprehensive picture of how their audiences are composed, how they should perform, and BI intel they could use to guide future marketing strategy.
The big challenge here was that the final deliverable would have to be rendered in Tableau. Why Tableau? The assumption was that many of our client users (who wouldn’t be using our self-serve setup interface) already used Tableau, did all their BI work in Tableau, and wouldn’t want to switch to a different UI if they didn’t have to.
My only problem was I didn’t have the first clue how to use Tableau, let alone hack its design. After-all, I’m a product designer, not a Tableau dashboard developer. Fortunately, we had done some mockups for an in-house build. And my new task became learning the ins and outs of Tableau, so we could successfully translate the design to our Tableau dev team.
Insights Version 1
We all knew there would be some constraints regarding Tableau’s capabilities, but no one (not even the Tableau developers) knew what we were up against until we set out to build.
Tableau didn’t have any kind of switch or toggle functionality, both of which we relied on heavily in our initial designs. To compensate we had to replace toggles and switches with dropdowns that couldn’t be styled. We then had to design around that. Because Tableau couldn’t do dynamic layout or resizing, we had to split demographics and segments into two separate tabs, which I was okay with because it cut down on information overload.
Because Tableau development took way longer than anticipated, we had to cut insights for actual performance out of our MVP entirely, which meant all traces of it had to be cut from the UI. Oddly enough, I’ve found this often to be the case in design that later iterations often have the least amount of features.
Insights Version 2 - Tableau (Segments)
Insights Version 2 - Tableau (Demographics)
Hux Audience was my first project for Deloitte Digital. Over the course of my career I’ve mostly worked at smaller companies that built tangible products with clear UI needs. Here, for the first time in my career I found myself working for a giant company that focused on selling managed services (as opposed to products). Anything UI-related seemed secondary, and there was a constant push against building anything in-house, which made it difficult to figure out where I fit in.
In order to make a valuable contribution, I had to change my role a bit, learn more about service design and solutions architecture. Interestingly enough, I found that a lot of the same values I used for product design were just as applicable. In the end, the job is still learning about the client needs, collaborating with stakeholders, and making sure you’re delivering the right thing.
As of spring 2019, we were just gearing up for pilot testing and going into discovery for performance actuals insights. Check back soon to see how it all turned out. :)