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”
- 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, it 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.
In Figma, created simple and easy to look over with all components of the email.
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
TESTING & ITERATING:
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.
The final confirmation screen:
- Provides the user an easy way to review all the settings that were set
- If default filters weren’t changed, then there’s a warning message. While it’s possible that’s the intention, it’s unlikely in practice.
- A detailed list of who exactly is receiving the email (right). For example, in the image above, we see that this email should go to “both parents” for those in the selected seasons. The additional information is in the recipient list that explicitly identities the family and names that are getting it, and households where no emails are available. This is important information that was previously not provided to users.
Unfortunately no metrics were taken before and after to quantify the results of adding the review screen, but when the Director of Operations was asked about the impact of this feature, they 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.
This feature also showed great opportunity to utilize the Reporting team/Jaspersoft for new features in the software that required data to be pulled that was otherwise too expensive to do by developers/code. This became the beginning of more collaboration between me (UX) and the Reporting team to identify more places where we could provide more information for users to make better decisions and actions.
- To not so quickly accept what the problem is as presented by others. While the 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”
- This was one of my earlier features that I led and one that ended up involving a lot of people cross-functionally.
- 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. However, I/UX had to push for changes that we knew would be impactful. It was effective to prototype and show it to people for them to understand things more; and being willing to compromise on certain things to be able to achieve the key goal.