Campbrain Enterprise Software Emailer

Overview:

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.

Problem:

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:

1. The user selects who they want to send the email to, composes email
2. Clicks on “Send” (this then launches the actual mass email job)
3. 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.

Role:

• 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

DEFINE

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.

IDEATE

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:

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.

Solution:

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.

Before

After

DESIGN

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

TESTING

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.

ITERATION

With the feedback from both Ops team and Engineering team, I went back to iterating on the designs, more specifically on how to display:

1. Which filters were applied:

2. Number of actual recipients (and who):

What We Shipped:

The EMAil REVIEW confirmation screen

---

recipient list details

IMPACT

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

What Happened	Lesson
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