One of the things I have learned from working on Dev Tips is that a great skill isn’t created and run by one single person. Sometimes it takes a team. For the Dev Tips skill, we have a graphic designer who creates the icons and artwork that we use in cards and display templates. We also have a writer from our marketing team who contributes new content on a weekly basis so that the skill is delivering latest and greatest topics on Alexa development.

As I was building Dev Tips, I wanted to make sure that non-technical content creators like writers and designers could easily make their contributions to the skill. I also didn’t want to be the gatekeeper to all future changes. This inspired me to find a better way to include my team as I enhance and maintain the skill. This post summarizes the things I learned about including non-technical contributors in the skill development process.

Start with an External Data Source

The first step, for me, was to take much of my content out of my Lambda function, and move it somewhere that could be more easily manipulated by my team. My first effort took me to the obvious choice: Amazon DynamoDB. DynamoDB is fantastic, flexible, and fast. The one thing that it lacked for me, however, was an interface that non-technical individuals would be comfortable with. For those that are familiar with databases, the interface is incredibly useful:

For my team of non-technical individuals, however, this seemed like it would require training to ease the transition into using this tool. Also, because much of the storage of the data would be done using JSON, this introduced opportunities for human error.

In my search for something more compatible with my goals, I stumbled upon AirTable, an independent company that makes data tools. Their primary interface looks and acts like a familiar and accessible spreadsheet.

In addition to a familiar interface, AirTable also offers a wide variety of data types to choose from. This makes it easy to save data in a format that makes sense for your application. Behind the scenes, there is an entire API that allows you to create, read, update, and delete records directly from your code. All of the data travels as JSON objects, making it easy to consume.

Make HTTP Calls to Your Data

Instead of relying on a pile of data objects inside your code, you can just as easily make direct calls to your external database to retrieve that data. I rely on a combination of entity resolution and HTTP to grab the answers for Dev Tips. (For more information about making HTTP calls, check out this post.)

When entity resolution confirms that a user has matched one of my slot values, I can confidently make a call to my data to retrieve the record for that slot. Once I have retrieved that data, I can respond to my user with the answer they were looking for.

This is also handy for all of the other kinds of data I keep in the skill. I have an array of responses for welcome messages, goodbye messages, “I didn’t understand your request” messages, and others. By extracting and externalizing these, it makes it incredibly simple to add more responses to the list as we continue to improve the skill.

Continuous Improvement

One of the immediate benefits of using an easily editable external data source is that when your team identifies that an answer is out of date or includes a typo, they can easily fix it. As soon as the data changes, our skill is updated—no code changes, no schema updates, and no technical intervention necessary.

In the cases where we need to add new “answers” to the skill, they can add them to our database, and I update the schema with the new slot values every week.

Access Creates Ownership

This process means content creators can add fresh content to the skill immediately without any technical barriers. This has also allowed them to take ownership over the skill’s quality because when they find something that doesn’t work, they can fix it themselves.

Think about the non-developers on your team who are tasked with helping you make your skill great. Think about the tools they are being asked to use. Are they the right ones? And as a developer, think about how empowered you feel to make changes to your code. Wouldn’t it be great if your whole team felt that way about their contributions to the skill?

Ultimately, you want to create an engaging skill that keeps customers coming back. But a great skill starts with a team of people who care passionately about the skill and its mission. Follow these tips to make it easier for your teammates to be as passionate as you are about building great voice experiences.

Build Engaging Skills, Earn Money with Alexa Developer Rewards

Every month, developers can earn money for eligible skills that drive some of the highest customer engagement. Developers can increase their level of skill engagement and potentially earn more by improving their skill, building more skills, and making their skills available in in the US, UK and Germany. Learn more about our rewards program and start building today. Download our guide or watch our on-demand webinar for tips to build engaging skills.