Umbel Segment Comparison Mode
Umbel is a platform created to help marketers in the sports, media, and entertainment industries grow their fanbase, target their fans, provide them with better in-venue experiences, and sell more tickets. Umbel achieved this by allowing marketers to import all of their fan data from disparate systems and consolidate that data down to the single fan level providing a rich profile about each fan.
In the product, marketers could view how segments differed or compared to their audience as a whole to find cohorts of people to market to on Facebook, email or other social networks and then view any Facebook campaign results in the app. Umbel also helped marketers acquire new fan data via our hosted “Activations” we called Activators (later referred to as “Engagements”). These were micro-sites we hosted for our clients usually consisting of enter-to-win contests or giveaways our users could launch in just a few minutes with a goal of collecting a users information for the chance to win or receive a prize.
A common pattern began emerging early on while testing and watching our clients use the product. There was an inherent need to look at one segment(s) versus another in order to make a decision on the best way to target a cohort of fans. I would watch them open additional tabs, take screenshots, or save custom segments (multiple segments saved as one) to access later to do this and some would become more frustrated than others. The more I witnessed this behavior the more it became apparent we needed to provide them a better way to do this.
I presented my case for some version of this feature to the higher ups and eventually got it on the product roadmap once we improved more of the core features of Umbel.
Primary
Secondary
I began by collecting all my previous notes, videos, and any additional research in one place to get my thoughts organized. After that synthesis, I would need to determine whether more user testing would be needed or if I had enough to get started on some rough sketches once I created some design priorities. I felt I had enough data, I could start free writing some potential ideas, sketching, and looking for inspiration so I could move into testing wireframes quickly.
Through this process it was important to bounce ideas off of client services, development, and product to get a feel for the direction to head towards and make sure others feel included. Then the plan was to create a handful of low-fidelity wireframe prototypes and test with client services to try to whittle the prototypes down to 2 or 3 to start to test with our clients. Once I tested some of the low-fidelity wires I planned to make changes and start to move into higher fidelity screens after each round of feedback. Once a direction we felt confident about was reached we could start to get development more involved and begin building out the core components of the new feature. As the feature got into a staging environment, I could then begin to test with our clients again to uncover any bugs or general usability issues that prototypes simply don’t uncover.
After multiple rounds of user testing, we thought one option would be great for one set of users and the other would be good for the other set. The decision was between a modal with multiple tabs with the data in rows and columns that we thought would appeal to our Business Intelligence users and the other option being a more visual approach where we split the main segment screen into a column A and column B. The second version seemed to appeal more toward an average user, however. So, after a good amount of discussion with our head of product, head of Client Services, and the developer who would be implementing the feature, we made the call to go with the more visual option, since we believed it would be more helpful for a larger portion of our users.
RESULTS
SCREENS
