Ripple
[Project Goal] Enable users to create, size, and allocate audiences for hundreds of email campaigns a month more efficiently and effectively than before.
[Responsibilities] Leading and executing user research, product management, system conceptualization, UX, and UI (Aka sole and lead designer).
[Collaborated with] End-users, developers, and stakeholders.
[Result] Adopted by users immediately, praised for how enjoyable it is to work with, and used as an example amongst upper management for the strategic value of user-first design thinking and processes.
Summary
Spiceworks relies on a complex system of internal tools and databases to deliver email ad campaigns bought by large tech companies to the millions of IT pros using Spiceworks. I worked as the lead UX and UI Designer on an internal tool that would enable the Spiceworks ad team to take millions of email addresses, efficiently create targeted audiences from them, and allocate them strategically to each of the hundreds of email campaigns we had sold for that week.
The result of this project was a system that was praised internally by its users as one of the most intuitive and enjoyable internal Spiceworks tools they have ever used, and praised by management for how quickly and willingly users adopted it.
My Role
Conducted contextual inquiries on how the Spiceworks Client Services team created email audiences and allocated them to email campaigns
Worked with existing users to reach an understanding of what was broken with the current system based on what we observed in the user research, and map out the ideal system
Mapped out flows of the UX and UI, while collaborating with Devs to ensure that the backend would support the UX and UI I had in mind
Created low, mid, and high fidelity prototypes and mockups, testing them with our findings from user research and with internal users
Collaborated with devs on what features needed to be implemented (we did not have a PM, so managed it ourselves)
Collaborated with devs throughout the implementation process to make sure the final product met the needs of the user and the business goals of the company
Results
The system was released in increments over a period of a few months in 2015 and 2016, and is still being used internally in Spiceworks to this day. Upper-management cited it as the easiest transition they’ve seen getting internal users over to a new internal tool. I received a spot bonus as well for how successful it was.
The Challenge
Spiceworks sells a large amount of email campaigns to tech companies who would like to advertise to the millions of IT pros using Spiceworks. Each of these email campaigns are tied directly to a dollar amount, so it is in the best interest of Spiceworks to deliver as many of these campaigns as possible. However, in order to ensure that the email campaigns perform well for clients and to prevent email subscriber fatigue, there had to be a system or human being who could make intelligent decisions on how to best optimize which email campaigns were allocated with which audiences.
The challenge for me was to build a system that would allow the Spiceworks campaign delivery team to build custom audiences for each email campaign, prioritize which campaigns were allocated emails first, and optimize the process to generate the most success for clients and revenue for Spiceworks.
The Discovery
I led efforts for Contextual Inquiries where we spent time observing and listening to people on the campaign team who were responsible for delivering email ad campaigns for clients, and would be the users of our tool. The goal was to understand as much as possible their current workflow, and the tools they used, so that we could see what wasn’t working, was working, and any integrations our tool would need to have with other tools like Salesforce.
What was interesting and challenging for me in this process was that the work our client services did was completely foreign to me. I had to learn words like “re-targeting”, “audience-sizing”, and “CTR”, and familiarize myself with the tools they used like DFP. (To me it was almost like the equivalent of visiting a new country and immersing myself in a new culture.)
The Synthesis
As I continued to immerse myself in the complex world of email ad campaign delivery and audience sizing at Spiceworks, I sketched and iterated on flow diagrams to help me to check whether I had a right understanding of what was the current way of doing things, so that I could look for ways to make the work easier, more efficient, and enjoyable for client services in the new system we were building. I specifically focused understanding the parts in the workflow where I saw unnecessary, repetitive actions, and user error and frustration, so that I could in the future invest time in brainstorming solutions for them.
Also, one thing that I did that I actually ended up finding very useful was mapping out the questions that the user is asking at any time in the process, because to me those were the questions I needed to answer in my UI to best help them with their work. I also included questions in parenthesis that I personally had that I knew would impact the design. Here’s an excerpt:
User begins work. They start by asking:
Are the upcoming campaigns for any of the days of this week ready to send?
If not, what is the most urgent one I need to get ready?
Which campaigns don’t have audiences yet?
What is the salesforce ID so I know what audience needs to be built for this campaign and for what client?
(Can we link this automatically?)
Which of these campaigns are higher priority to get an audience for?
(How does a user know what is higher priority? Is it the dollar amount of the campaign? Does the relationship Spiceworks has with the client matter?)
If there are campaigns that we don’t have enough emails for, is there something I can do to rearrange how the emails are allocated for each campaign?
If so, has it been sent to mailbrain (another internal tool) yet?
Has anyone started “cutting lists” for a specific day’s worth of campaigns yet?
Building a System
As I was internalizing what I was learning from the client services team, I was also beginning to diagram out the system that would work to facilitate the workflow. My mental model was similar to the mental model I had when I was doing object oriented programming or building relational databases, in that I was trying to figure out the best way to chunk out the system in a way that facilitates the user’s workflow as efficiently and simply as possible. Here’s a simplified version of what I was mapping out:
Client Services is in charge of delivering on one or more campaigns
Clients have one or more campaigns
Each calendar day has one or more campaigns that need to be delivered
Each campaign may have one or more audiences
The parameters of an audience may be reused in one or more campaigns
Ricardo and I would also spend a lot of time making sure that the workflow that best equipped our user to be successful was one that we both agreed on and were building. This meant many whiteboarding sessions like the one below.
Here's a flow diagram Ricardo and I hashed out so we'd both be on the same page on how the system would work, based on what we observed in user research. It's not pretty, but it is effective :)
Prototyping and Iterating
After I was reasonably confident that I did have a good grasp of the problem, what tasks the users had to accomplish, and in general, the constraints of the system, I began to sketch out and build prototypes of the system. I was especially grateful at this time to be working with Ricardo, since his expertise in frontend and backend development made him a perfect teammate to brainstorm and debate about potential solutions with.
For prototyping I used a tool called Axure, since I knew that the system had a lot of complexities and nuances that would be difficult to capture in a tool like Sketch or Principle. I also knew from the Contextual Inquiries we conducted that a lot of user pain came from having to do repetitive tasks in inefficient ways, so I chose to iterate on several small but detailed interactive prototypes that focused on the tasks we noticed were the most common and likely to produce friction for users.
Below are a few screenshots from the prototype I built. (You can read explanations of a few of the UX/UI decisions I made in the next section "High-fidelity".)
High-fidelity
At some point, the list of things I could do to optimize the user workflow while still keeping in mind constraints on time and resources dwindled. It also became clear that any justifications for changes to the system were more about subjective preferences from users rather than for reasons such as “increased clarity” or “speed to complete task”. That is when I decided to try moving to higher fidelity prototypes and mockups. During this time, much of my efforts were towards optimizing my design to answer all the potential questions and reduce the moments of hesitation a user may have at that given point in their workflow. Below are a few of the mockups with the rationale behind several of the design decisions I made. Thematically, there were several UX heuristics I prioritized due to the pain points I observed users experiencing:
At all times, communicate in very clear language to the user the status of any object in the system. (You will see this exhibited in the many blocks of blue, green, and grey below, as well as the variation of icons showing the status of each campaign.)
Display very clearly the CTA of the next step the user is most likely to take, and minimize or hide all other CTAs. The user should not have to waste mental energy on scanning for the next “action” they want to take when it is something that the system and UI can anticipate.
Make it easy for users to undo actions and separate costly actions so they don’t bottleneck the rest of the process. Users are constantly readjusting audience lists and campaigns as new campaigns get scheduled in or taken out. In addition to that, estimating audience sizes for complex queries can be costly. So I made it easy in the UI to undo any action, and worked with the developer so that different types of calculations can be initiated separately from each other as well as in parallel.
The user starts their day or session looking at what remains to be done. This page should answer questions like "What email campaigns are scheduled to go out today? Which ones aren't ready to go out and why? Which ones are the most urgent to work on?"
Once a user has picked a day's email type to work on (in this case, the user has chose to work on "3rd party email campaigns going out on June 18th"), this is where the user can see what email campaigns already have audiences cut (in other words, which email campaigns already have users allocated from the "pool" of emails available for the day, since a user can't receive too many emails from Spiceworks in one day), which ones still need audiences, and which ones are "sent to mailbrain" (or in other words, queued up to be sent).
If the user picks a specific email campaign to work on, he or she can use the interface to do the equivalent of an "SQL query" (without needing to know SQL) to predict the size of the audience available for the email campaign. This is important, because clients will ask for a certain size of audience (ex. "10,000 android tablet users in North and South America") and users need to be able to tell the client if there are enough emails in the "pool" for the day to fulfill that. If not, then they can renegotiate with the clients, or possibly rearrange the email campaigns that are pulling from the same "pool". For example, there may be another campaign with emails "allocated" to it that has more flexible constraints, and therefore can be prioritized lower when audiences are cut for it.
Future Improvements
There were several things that looking back, I would have changed in my design if I was given more time to iterate on my design even further.
Experiment with more versions of the UI to see if clarity and efficiency can be increased.
Even though the tool was meant only to be used on desktops, I noticed that as more and more functionality got added, it required more and more precise mouse-clicking for users to do their tasks. I would have liked to study that further, and test what the ramifications would be if I increased the sizes of the most frequently clicked targets, at the expense of less horizontal space for data manipulation. I would have also tested out potential UI improvements to see if users found it easier to comprehend, especially the query section (see below) because a large part of the user's interactions are concentrated in this area.
Version 1
Could be easier to read as sentences because of the lack of extra boxes and lines.
Version 2
Could be easier to see what is a click target and what is not, as well as what row the user is hovering over. Has fewer visual indicators of the interactions that will take place when clicking on a target.
Consider more of what information on each page can be hidden from view.
I am learning over time that much of what is important to user is influenced by the exact point in their workflow that they’re in. There was some information that I showed in the tool that ended up cluttering up the interface because I had not understood enough at the time what the user was using the information for, how often they’d need to look at it, and why. So looking back, if given more time I would have done more testing and specifically paid more attention to what information the user is glancing at and when, and which parts of the prototype they were ignoring and when.