Coffee with Coworkers

I was initially contacted by the product owner on this project because of a similar internal employee-matching iOS app I created a few years earlier called Munch.

As a huge proponent of cross-team and cross-disciplinary intermingling, I jumped at the opportunity to contribute to this project in a big way in my free time. Who doesn’t love meeting smart, talented people over a good cup of coffee?

There’s an incredible amount of interesting work going on in Capital One’s San Francisco 4-floor office, but with people’s busy work schedules and constant deadline pressures, happenstance mingling with people on other teams doesn’t always happen. Inevitably, that means that there’s lot of skill and project overlap across teams (and office floors) that goes un-noticed.

There have also been some concerns recently about the declining culture of Capital One’s San Francisco office. Introducing people to other employees within the company is an easy way to help make them feel more connected to others at the office. It’s also a fun opportunity for people to get out of the office and explore new coffee shops in the area. Not only are people happier when they have opportunities like this, but these coffee dates also tend to make them more productive when they return to work. Although it’s not explicitly a work-related meeting, the topic of work inevitably comes up during these coffee dates.

Coffee with Coworkers is a win-win for the company in terms of productivity and culture.

During my initial kick-off meeting with the back-end developers, they informed me that they were hoping to leverage Beans, Yelp’s open-source software for coffee date matches, to limit the amount of back-end work they would have to do. The front-end UI of Beans consists of a simple website and a few short email templates with the website hosting basic profile information and scheduling preferences and the email template functioning as a reminder to update the website preferences on a weekly basis.

I had a good conversation with the back-end developers and agreed that with some minor branding and content updates, making use of the Beans infrastructure could be a good first step to get the product up and running quickly. I requested that they send me screenshots of the current Beans implementation so that I could take a first pass at the website and email UI templates as well as the content for each of the emails.

What I realized as I was going through the Beans UI flow is that there were a number of glaring UX issues. For example, after receiving the weekly reminder email, users were required to update their permanent preference settings on the website each week. That meant that if a user was out of the office on vacation that week, they would have to unclick all of their permanent preference settings to opt-out for that week – and those options would be permanently saved. Good luck getting your users back on the coffee train (and back to your website, where they have to effectively sign up all over again) when they come back from vacation… That also meant that if your user forgot to untoggle their preference settings (or worse, imagine if they had already left for vacation and didn’t even see the email!), they would get matched up for a coffee date they wouldn’t be able to attend. Sucks for the ghostee.

This is one of the many reasons I wanted to move the weekly opt-in interfacing to the email touchpoint. That way, by default, we can automatically opt users who don’t respond to the email out of the match-making process. Furthermore, by allowing the user to select ‘yes’ or ‘no’ right from the email instead of sending them to a website, we are effectively reducing a click, and therefore minimizing the drop-off points.

Because the email templates represented a large percentage of the experience touch-points, content was more important than anything. I decided that the content should have a casual, friendly voice, but also be straight-forward and have a clear objective and action, even when users scanned the email quickly (as they probably would). In addition to using a direct, to-the-point email subject line, I made sure to use casual introduction language like “Hey [name],” provide context under buttons for better scannability, and bold section title elements. 

My product partner and back-end development team were pleased with my designs, so I started coding up the email templates and web page in HTML and CSS.

After I handed off the five HTML files for the email templates and the associated CSS file, the lead developer reached out to me to inform of a few back-end implementation problems with the Match email template. He said that due to some internal restrictions, we wouldn’t be able to pull the matched users’ profile pictures from the internal Capital One server or embed meeting event invites directly to their Outlook calendars for MVP.

Additionally, the lead developer suggested having the matched pair meet in the office to walk to their coffee venue together. I thought it was a fair point since it allowed the matched pair to spend more time together, but I can’t help but think that the suggestion was a little bit of a ploy to hard-code the meeting place instead of creating a randomized location function 😉

Being a very particular coffee connoisseur himself, he also recommended that we allow the matched pair to mutually select their coffee venue rather than assigning one, with the assistance of a list of near-by coffee venues to choose from in case they were feeling indecisive. I was happy to make these updates to decrease his workload to get the MVP version up and running as fast as possible. I knew that these were the types of things we could easily iterate on later based on real user feedback.

After creating the new designs, I handed off the updated HTML file for this MVP match email template and the developers were ready to go again.

Unfortunately, Yelp’s Beans infrastructure didn’t have a number of features we needed and didn’t allow us to implement a number of the UX flow changes we wanted to incorporate, including sending multiple emails at specific intervals and allowing people to set custom time and date preferences. Because of this, the back-end development team is now in the process of transitioning this project to a new back-end system, created from scratch.

Because of this unanticipated extension in the development timeline to get to an MVP version, my product partner suggested gaining support and proving interest in the Coffee with Coworkers project through a manual pilot. We met as a team to discuss the details, and landed on a 6-week pilot involving 40 employees, all based in the San Francisco office and chosen at random from our combined contacts. Per my suggestion, we solved the complicated budgeting and expensing issues of compensation by promising a gift card with $5 per attended coffee date at the end of the pilot. We also decided to send out 2 short Typeform surveys – one at the half-way mark (3 weeks) and one at the end – to track people’s thoughts about the pilot’s usefulness, timing of the coffee dates, etc.. Additionally, we opened up a Slack channel for pilot members to provide constant feedback throughout.

The “back-end system” consisted of a manual randomized email match and scheduling process. More specifically, each week, our incredible admin would send out an opt-in email to all pilot participants for a coffee date that week. Then, with the opt-ins’ time preferences (which they would have marked on a shared Google Doc), the admin would selectively match employees up and send a new email out to the matched participants confirming their coffee date.

Because of some development road blocks, this 6-week pilot turned into a 14-week pilot that’s still going strong. Positive meet-ups and word-of-mouth throughout the company have translated to us slowly adding new employees to the pilot as the weeks go on. According to our admin, more candidates also makes the matching assignment process easier.

Because of the positive feedback even in the early, pilot-stage, we received a lot of executive buy-in for continuing Coffee with Coworkers, which means a weekly coffee will likely be included in every employee’s budget as soon as the automated pilot is up and running.