Cómo diseñar una (buena) Skill de Alexa

¿Cualquier persona puede crear una Skill de Alexa? Mi respuesta sería “Si y No”.

Cualquier persona con conocimientos de desarrollo puede crear una Skill, pero hay que tener en cuenta diversos aspectos dentro del desarrollo de una Skill para poder crear una Skill de calidad y que sea atractiva al usuario, en definitiva, se trata de realizar una Skill que haga que el usuario quiera volver a usarla, si la usa y se aburre, no la volverá a usar.

Os voy a numerar ciertas características y/o detalles que, en mi opinión, deben tener una Skill para que sea de calidad y atractiva al usuario final.

Internacionalización

Al igual que en los desarrollos de páginas web, las Skill de Alexa podemos publicarlas en diferentes idiomas, siempre y cuando el caso de uso sea válido en esas regiones.

Además, debemos ofrecer (diría que obligatoriamente) variedad en las respuestas de las Skill. Una Skill debe ser dinámica y parecer natural, las personas no hablamos siempre igual, no siempre decimos buenos días usando las mismas palabras y por lo tanto, las interfaces de voz, tampoco deberían hacerlo.

WELCOME_MSG: [
    "Bienvenido a teléfonos de interés, ¿Qué teléfono quieres consultar?.",
    "Hola, gracias por usar teléfonos de interés, ¿Qué teléfono quieres consultar?.",
    "Hola de nuevo, ¿Qué teléfono quieres saber?",
    ],

Si quieres saber mas sobre internacionalización te recomiendo i18n Alexa Skill (Typescript)

Persistencia de datos

Es algo increíblemente sencillo de implementar y que puede marcar la diferencia en una Skill. Pongamos de nuevo el ejemplo entre dos personas que se saludan, hay mucha diferencia entre como saludas a una persona que acabas de conocer y un amigo. Pues con las interfaces de voz ocurre algo parecido. La primera vez que una persona usa una Skill está un poco perdido y es muy recomendable dar recomendaciones sobre como usar la Skill en el mensaje de bienvenida, de esta manera guiamos al usuario desde un inicio. Pero claro, no podemos ofrecer el mismo mensaje de ayuda a un usuario nuevo que a uno que ha usado la Skill varias veces, ya que ese usuario ya no necesita esa información de ayuda durante la bienvenida.

La persistencia de datos nos permite controlar esta situación guardando en una tabla de DynamoDB un atributo que nos indique si el usuario que está invocando la Skill es un nuevo usuario o no. Incluso podríamos afinar un poco más modificando los mensajes dependiendo si es un nuevo usuario, un usuario ocasional o un usuario habitual.

Atributos de sesión

Otra forma de mejorar la experiencia de usuario en una Skill es almacenando atributos de sesión. Estos atributos nos permitirán almacenar los datos recogidos durante la conversación y mantenerlos almacenados mientras dure la sesión. Un ejemplo podría ser una Skill donde preguntas el horario del colegio de uno de tus hijos, la primera vez te preguntará sobre que hijo quieres consultarlo, pero si haces mas preguntas siempre te responderá sobre ese hijo, que tendrá almacenado en memoria.

Personalización de los mensajes

Una opción para dirigirnos al usuario sería decir su nombre, por ejemplo:

“Bienvenido Javi, ¿Cómo estás?”

Es un texto personalizado y que al cliente le resulta mucho mas cercano. Para poder obtener el nombre, deberemos activar uno de los siguientes permisos.

Full Name alexa::profile:name:read
Given Name (First Name)alexa::profile:given_name:read

Permisos

Os recomiendo enormemente que reviséis la lista de permisos que se le pueden conceder a la Skill, ya que es posible que vuestra Skill pueda mejorar enormemente si obtenéis cierta información a la hora de ser lanzada.

Los permisos que existen actualmente son:

• Device Address
• Customer Name
• Customer Email Address
• Customer Phone Number
• Lists Write
• Lists Read
• Amazon Pay
• Reminders
• Location Services: Si queréis ver como se usa: Localización con Alexa
• Skills Personalization

Integraciones con APIs externas

Todo depende del objetivo de vuestra Skill, no todas necesitan una integración con una API, pero en muchos casos sí podéis beneficiaros de información adicional para ofrecerla al usuario final. Un ejemplo sería una Skill donde se pregunta por el horario de visita de un evento o monumento en un día en concreto, podemos darle una vuelta de tuerca conectando con una API meteorológica que nos diga el tiempo del día que estamos preguntando.

Los datos de una API externa aportarán mas información y mejorará la experiencia de usuario.

APL y/o APL-A

Debemos tener en cuenta aquellas personas que lancen nuestra Skill con dispositivos con pantalla, sabemos que no todos disponen de una, pero los que si la tienen cuando lancen una Skill sin APL se quedarán con ganas de mas. No es necesario ni recomendable que muestre demasiada información, y sobre todo, no podrá (o debería) mostrar más información de la que se ofrece por voz.

APL será la capa visual que servirá de apoyo al mensaje de voz, pero nunca deberá sustituir a la voz. Debéis crear vuestras Skills preparadas para aquellos dispositivos que dispongan de interfaz de voz pero que sean perfectamente válidas para aquellas que no lo tienen. Esto podéis conseguirlo comprobando antes si el dispositivo soporta APL dentro de vuestro Backend.

Muy importante es tener sentido del diseño, no vale poner una imagen que no permitan visualizar las letras correctamente, o un diseño desorganizado.

Recientemente ha salido a la luz Alexa Presentation Language for Audio que nos permite reproducir audio en el mismo instante que Alexa habla y da un toque de calidad a la Skill muy interesante. Os dejo un enlace por si os interesa aprender un poco mas sobre APL-A:

• Alexa Presentation Language for Audio

FallbackIntent

O como yo lo llamo, atar cabos sueltos :) . A este intent llegarán todas aquellas peticiones que nuestra Skill no sepa manejar, con esto conseguiremos dar un mensaje menos “drástico o brusco” al usuario.

No es lo mismo decirle al usuario, “Lo siento ha habido un error” (o pero aún, que lo diga en inglés si la Skill es en español) que diga, “Perdona, aún no puedo responderte a esa pregunta” o “Disculpa, no te he entendido, ¿podrías repetir?”

Además nos permite recopilar la información que no hemos sabido capturar en otros intents.

Interceptores

De cara al usuario final no tiene afectación, pero si es muy interesante el uso de interceptores para unificar código que nos permita por ejemplo loggear el evento que nos llega para analizarlo posteriormente, limpiar las dynamic entities, etc..

Entonación y diálogos

Es muy importante que Alexa cuando habla, parezca los mas humana posible, las personas no hablamos de forma plana, sino que introducimos expresiones, entonaciones y emociones en nuestras frases.

Con Alexa podemos conseguir el mismo resultado, pero debemos jugar con las opciones de SSML (Speech Synthesis Markup Language).

Con los tags de SSML podremos variar la velocidad con la que Alexa habla, hacer pausas, cambiar voces, etc. Lo que le dará a nuestra Skill un toque mucho más natural.

Un ejemplo sería sí queremos que nuestra Skill diga un número de teléfono, por ejemplo 123 456 789, Alexa dirá ciento veintitrés millones…, y claro, muy natural no es. Sin embargo si usamos SSML con el tag interpret-as=”telephone”

<say-as interpret-as=”telephone”>123 456 789</say-as>

Alexa podrá interpretar el número como un teléfono.