Reading Time: 9 minutes

Last Thursday and Friday, I had the opportunity to participate in the Alexa Challenge. This hackathon at the HCSC Blue Innovation Lab focused on ways that Alexa could help Blue Cross customers use their insurance.¹  

None of us had ever built an Alexa skill before. So luckily, some folks from Amazon and Slalom showed up to help us! We had all of Thursday, plus a little time on Friday, to build our solutions before the judging. I’d like to share some of the things we learned about building Alexa skills as well as some things I’m still wondering about.

First, a little context: my team built a skill for Blue Cross members to find out what benefits they had not yet used for the year, then select from nearby providers to book appointments. Our long-term vision was to make it easier for members to use their preventive care benefits so they could stay healthier and have higher quality of life. Our team won the challenge (and received Echo Dots—so now we can keep building Alexa skills!) but all of the teams had fantastic projects, and I’ll talk more about those projects later in this post.

These are some decisions that our team made that I think helped us:

1. Keeping logic on the server

In addition to our Alexa skill (which was a node.js app based heavily on Amazon’s QuizGame example), our team built a Spring Boot application to collect and format information about benefits and nearby providers. This kept our Alexa piece very lean; it focused only on routing the user’s questions and comments to the correct responses.

This approach had two advantages. First, we could get more work done faster because we already understood Spring apps, whereas we were less familiar with apps for Alexa. Second, this approach gives our software more flexibility as we scale to more users. If we wanted our skill’s information to be more robust or we wanted to change the way we fetched it, we could redeploy the Spring Boot app without changing the user interaction with Alexa.

2. Focusing on one skill

Some of the teams wanted to go broad and enable Alexa to respond to several different questions. We went deep instead: we focused on one initial question (‘Do I have any {insert type here} benefits?’) and drive out a full conversation with Alexa, from finding out what kind of visits the user had left, to choosing from several nearby providers, to calling the provider on the phone. Again, this allowed us to get as far as possible with as little understanding of Alexa as we did. It also allowed us to focus on making our use case robust…see next bullet :).

3. Making her robust to different speech patterns

You have to prepare Alexa for every prompt you want her to understand. For example, if you only program a response for “Tell me if I have benefits,” Alexa will not respond to “Tell me whether I have benefits.” So it’s important to think through all of the ways that a user might ask for the same thing and make sure Alexa understands them all. That way, talking to her feels like a conversation and not like trying to guess a secret passcode.

We wanted to make sure that, if one of the judges wanted to talk to our app, she would respond regardless of which phrases the judge used to talk to her. So our team spent some time identifying different phrases people would use to ask our skill for help. When other developers, or first time users, popped over to try her out, we would listen to what they said and add it to the phrases that she could respond to. There are a lot of future possibilities here, from coming up with Alexa thesaurus tokens to incorporating natural language processing. For our challenge, we got to a point where someone who knew the general flow wouldn’t throw off the app with a wording misstep.

Some places where we might have come up with a better solution:

1. Managing context during conversations.

In order for Alexa to carry on a proper conversation, she needs to know what happened earlier in the conversation. For example, our skill required her to know what kind of benefits the user had asked for so she could look up the correct type of providers to offer appointments. We stored these pieces of state in instance variables in our javascript class—not ideal, and not robust. This solution certainly wouldn’t work for helping Alexa learn things about the user over a longer period of time.

I want to explore better solutions for context management with Alexa. A separate object for holding state would be a start.Over the longer term, maybe we make a context endpoint on the server that lets Alexa pull down information about the current conversation and her conversation partner. This would mean that any interaction with her would take longer, though, as she made the network call. I’d love to hear others’ ideas on this.

2. Getting everyone’s ideas in.

Our product team, Marshall and Charles, had some great ideas about questions we could ask our Alexa skill and how we could enter the conversation flow at different points. Our team captain, Ryan, had some great ideas about passing provider data, like the location, through to the conversation interface. Another developer, Mark, wanted to make sure that we handled error cases gracefully. And another developer, Rodolfo, had some ideas for how we could help users choose the right kind of provider for their needs. How do we fit it all into nine hours?! Sometimes we can’t. But it’s sad to look at a good idea and say ‘not enough time.’

In agile development, we have the concept of a backlog of work that a product manager keeps in priority order. That way, no matter what, the most important features that the team could complete in any given time period are in the app. Would this same approach work for an eight-hour challenge, though? Are there too many unknowns to come up with a roadmap like that? I don’t know. Maybe it’s worth a try. Or maybe folks with more hackathon experience have some other ideas about how to manage all the possibilities for a brand new app.

3. Coordinating with other teams.

I don’t compete in hackathons because I don’t like divisive competitions held under the false pretense of identifying who ‘pwns’ who at things. First of all, the idea of finding ‘the best’ developers is meaningless because the range of developer skills is too broad and multifaceted to support a metric. Since winning a very specific hackathon is a laughably poor proxy for what is a fundamentally meaningless metric to begin with, in my view hackathons mostly just pit developers against each other who really should be helping one another.

This hackathon in particular didn’t face a problem with that; folks were willing to swap over to other teams and help each other out when needed. But at the end of the presentations, all of the Alexa skills we had built clearly had a common theme. I wonder in what ways teams could coordinate to get their skills to leverage each other, so together we could create a robust, cohesive app that allows users to discover all kinds of things about their health insurance through Alexa. Again, an effective attempt at this might be outside the scope of a hackathon. It’s worth a look for a longer term project, though.

Everyone made useful things

As I watched the presentations, I had no idea who would win. Some of the other teams did some really cool things with their projects.

One team tapped into a symptom severity API, for example, to help Alexa determine what kind of care a user needed based on their complaint. What a smart use of an external resource.

Another team wrote an app that answered user questions like ‘What is open enrollment?’ and ‘What is the difference between a bronze and a silver plan?’ As a programmer who, once upon a time, knew very little about health insurance, I would have loved an app like this to help me make sense of everything.

Another team developed an app to schedule appointments for you. She could even call 911 when needed—like life alert, but without the geriatric-specific reputation.

In Conclusion:

I’m not much of a hackathon person (see above). But my experience with the Alexa Challenge has warmed me up to the idea of organizing more hackathons like it: small ones, held among colleagues, with low stakes and a well-defined problem set with a circumscribed tech stack. And of course, events like this have the positive effect of pushing us outside our comfort zones and reacquainting us with just how much we can learn in a short period of time.

Most of all, I’m excited about my newfound knowledge of building Alexa skills, so I can hook up my Echo Dot and program her to do things for me. I wonder, can she sign into my gym classes for me? Can she remind me when it’s time to pay my bills? Can she email me cute pictures of owls on days when I ask her to play sad songs in the house?

I mean, who can argue with these owls?

1 Earlier this year I had the privilege of working with the lab to build HCSC’s dual platform mobile app. HCSC and Pivotal Labs worked side-by-side (literally—we pair programmed the whole time), using agile methodologies like test-driven development and continuous integration to build apps that quickly delivered customer value.