As an Interaction Designer at Campbrain for over three years, I have designed in many parts of the software. Campbrain’s flagship product is camp management software used by camp administrators, registrars and other team members (e.g., financial, medical) to make camp, school, and auxiliary programs run. For this case study, I will showcase the process for improving the Auto-Emailer feature—which is the camps’ communication tool with their clients and staff.
One of the projects I owned was solving a fairly frequent mistake that clients would make, sending mass emails to everyone or the wrong people in their database when they only intended to contact certain subgroups (e.g., parents of Program A only).
The initial user flow was:
- The user selects who they want to send the email to, composes email
- Clicks on “Send” (this then launches the actual mass email job)
- Taken to the Outbox to then realize the email has been sent to everyone in their database. Panic ensues. Oops.
Our support team would often receive frantic calls from clients to stop emails when it was too late. Frustrating and embarrassing for clients; awkward for our staff.
- Leading and coordinating this feature and liaising between various teams involved
- I interviewed managers from our Operations team to get more insight into this issue since they’re the recipient of panicked clients on the phone, as well as other members of the company that have been affected like Engineering and Product.
- Competitive Analysis of other products that specialize in mass emails
- Ideation, and many many mockups and iterations of the solution
- Testing and iterating
I started the research with of course looking at the screen and flow as it was and identified some issues from Product and opportunities.
Part of the reason why many clients mistakenly send emails to their whole database is due to the way our filters are set up so that they are robust in what they can query, but can be hard to understand for new or light users. Because by default, no filters are set which essentially means “everyone in database” is selected which can feel counterintuitive.
However, because the filters are used and integrated throughout multiple areas of the software, redesigning the filters was out of scope for this project.
That constraint helped to set the boundaries around the feature, I explored other ideas through doing an audit of the email flow, talking to others on the team, as well as a competitive analysis.
Some initial ideas:
- Adding an icon indicator on the button to warn users when no filters have been selected
- this could help reduce sending to all, but not for when it’s the wrong group of people selected
- Adding a checkbox or a skill-testing question—something to make them pause
- similar issue as above, but from a UX perspective and creating enjoyable experiences, it feels frustrating and condescending to make people do this
- Providing more information about recipients on the email configuration screen
- related to the filter, this was too expensive/complicated from engineering perspective
- Breaking the screen up into multiple like a wizard
- too much engineering effort on a big screen, and wouldn’t quite solve the problem
While some of those were easy and small fixes, my UX manager and I didn’t feel these were enough.
I also did some Competitive Analysis of mass-emailers like Mailchimp, MailerLite, etc., to see how they allow users to select recipients, and what they did to set their users up for success.
A key thing that they had that Campbrain didn’t have was a confirmation or review screen.
This felt like the key for the solution because sending mass emails is one instance when the focus shouldn’t necessarily be to complete as quick as possible. Adding more screen to force friction on the user to pause and check if the action that is about to be taken is what they had intended to do. If not, then they can simply go back and fix it. Providing some forgiveness to the user is important as it helps build trust for the software and confidence that what you think you’re doing is what you’re actually doing.
The solution that I and the UX team thought would be best is to add a review/confirmation modal between attempting to send and actually sending the emails off. Most if not all mass-email services include a confirmation screen. This is where we’d want to provide users with more information and warning of what is being sent and to who.
I started off my design with sketching and breaking down sections of the email settings page to the review modal that I would design:
I continue with more notes, lo-fidelity sketching to understand what information is given, missing, and how to present it clearly:
At this point, I moved things into Figma, to keep refining what is included and how
The focus here was also showing how to represent Recipients in a clear, easy-to-understand, and useful way. This was most challenging, to find balance between too much info and too little.
As I delved more into it and the different configuration that Recipients can be, it felt critical to show Recipients in a more detailed way if needed (e.g., as a popover). I prototyped this initially with Google Doc
I consulted and tested the screens and mockups from various teams (i.e., Engineering, Product, Operations/Support), and it was received well overall, although there were some limitations and compromises that came up as well as an increasing scope as we discovered more things that needed to be considered:
- Engineering said presenting the recipient list was too much effort and expensive to do through code
- Being able to present this previously unseen data and information in an easy-to-consume way sold its importance
- So the compromise was to pull/display this as a Jaspersoft Report
- So Reporting team then became involved
- There was a big learning curve from Reporting, and trying to make it look integrated, but it ended up being unstyled HTML, which didn’t look great, but a compromise
- The other change was where this list is accessed. There was a discussion of technical limitations of if we can show a report as a popover, so we ended up doing a tab and iframe
Continued testing, consulting, and iterating until what to include on the Review modal and Recipient List report and how to show it were at a good place.
With the feedback from both Ops team and Engineering team, I went back to iterating on the designs, more specifically on how to display:
- Which filters were applied:
2. Number of actual recipients (and who):
What We Shipped:
The EMAil REVIEW confirmation screen
Provides an easy-to-skim summary of all email settings that were set
Recipients area simplified to just show the Recipient type selected and list of filters selected and no recipients numbers here
Alert messaging if no or default filters set
Recipient list tab to view more details
recipient list details
A simplified summary at the top to show the recipient type, highlighting actual recipients and visually flagging # households that cannot be reached
Table provides a clean, quick, but comprehensive way to see all intended and actual recipients at a glance
Shows who will be getting an email; who doesn’t have an email, and which households have no emails at all
Ideally there were more robust processes to measure metrics for this feature before and after to see what the quantitative impact is.
Having more robust ways to measure work and impact would have been helpful to see how much the solution helped to cut down on the panicked calls.
Unfortunately we didn’t have that, but qualitatively, the Ops team said:
Very anecdotal, but I think it’s made a big difference. It used to be a fairly regular occurrence that we would get a call from a client who made a mistake and was hoping we could cancel the e-mail. That doesn’t seem to happen nearly as often anymore!
This Email Review screen has since become part of the pattern for other Emailers we have in Campbrain.
LESSONS I LEARNED
|Initial problem was defined as “how do we stop people from sending emails to everyone in their database”, it was really “how do we empower users to be clear on what email they are sending and to who”||To not so quickly accept what the problem is as presented by others, and to approach problems holistically to get to the root of the problem. Ask lots of questions.|
|Felt overwhelmed when I was iterating and under covered some of the complexity with balancing how to display what where, and if at all. Went through many iterations only to have the final product be pared down||More specifically, this may have been avoided if I had the foresight to this earlier on the in the process (i.e., before ideating); more generally though, sometimes less is more, and easier to pare down than up.|
|As I delve deeper into the problem, I saw opportunity to make the whole flow better, which in turn increased the scope from what was initially predicted by other teams||Importance of advocating and pushing for better solutions even if it means having to compromise on certain things for the final design|